Add a new virtio backend to support SCMI VirtIO devices (type 32) as
defined by the VirtIO specification since version v1.2.
https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.pdf
Sponsored by: Arm Ltd
Differential D43047
vtscmi: Add a virtio-scmi driver cristian.marussi_arm.com on Dec 13 2023, 6:38 PM. Authored by Tags None Referenced Files
Subscribers
Details
Add a new virtio backend to support SCMI VirtIO devices (type 32) as https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.pdf Sponsored by: Arm Ltd
Diff Detail
Event TimelineComment Actions Just a few minor comments. Note though that I only have time to do a brief review of this and haven't read the relevant section of the spec.
Comment Actions Thanks for the review @bryanv.
I was thinking exactly the same while doing this, but being a first time contributor to freeBSD, I was not sure how easily acceptable would have been to post a change related to some core system (like virtio) inside this series, Comment Actions Removed needless checks on malloc, using mallocarray Using mallocarray() and dropping the retval check since invoked as M_WAITOK Comment Actions I'm a bit late to the party, but is there a reason why this module wasn't hooked into the build system? see https://cgit.freebsd.org/src/tree/sys/modules/virtio/Makefile Comment Actions It's not very useful as a module as it provides infrastructure other devices need, e.g. their clock, or a reset line. If it was a module these drivers would fail to attach if they were built into the kernel. |