A Greybus network needs an SVC (Supervisory Controller) to bring interfaces up, assign device IDs and connect CPorts to the AP. On a UniPro network the SVC is a real entity on the bus. On transports that merely carry Greybus messages - a UART, an I2C bus, a network link - nothing on the wire plays that role, so the SVC has to be emulated somewhere: in a user-space bridge (gbridge), in coprocessor firmware (cc1352p7 in gb-beagleplay), or open-coded inside the host driver itself.
This series moves the emulation into the kernel and makes it shared. This was discussed in a prior RFC as well [2], but to keep things short, removing the need for an external SVC greatly simplifies the greybus network setup when nodes are directly connected over common transports such as UART, I2C etc.
gb-uart-node gb-softsvc greybus core (transport, serdev) <-> (SVC + host device) <-> (bundles, protocols) NodeOps module_insert() submit_message() module_remove()
gb-softsvc registers itself as a Greybus host device and answers the SVC-side operations the core expects during interface bring-up and teardown. A host driver implements the NodeOps trait to push data towards its node, calls module_insert() to announce a new node, submit_message() to hand incoming Greybus messages back to the core, and module_remove() on disconnect.
The first user is gb-uart-node, a driver for Greybus nodes attached over a plain serial port. Framing is HDLC, with a one-byte address (0x01 for Greybus) and control byte, followed by the 16-bit CPort ID and the Greybus message. No SVC firmware is required on the far end, so the node can be a bare microcontroller speaking Greybus - a BeagleConnect Freedom over its serial link, in this case. The testing is performed with greybus-zephyr [0] implementation.
Both drivers are written in Rust, which is why the middle of the series is abstractions rather than drivers. Only the APIs these two drivers need are covered: protocols.rs abstracts the SVC-facing parts of greybus_protocols.h, and types such as Greybus Interface do not implement AlwaysRefCounted yet. The intent is to grow this as more Rust host drivers appear rather than to abstract the whole subsystem up front.
Patches 1 and 2 are small C-side preparations to the Greybus core: exporting gb_connection_get()/gb_connection_put() and adding gb_connection_hd_find_by_intf(), a lookup by remote interface and CPort id for callers that only know the far end of a connection. Patch 3 adds a CRC-CCITT abstraction, needed for HDLC frame checks. Patch 4 adds the Greybus abstractions, patches 5 and 6 the two drivers, and patch 7 the device tree binding for BeagleConnect Freedom.
Open questions ***************
- gb-uart-node imports types from gb-softsvc, so the series carries the Rust-to-Rust cross-module calling setup from nova-core [1]: gb_softsvc_exports.c plus the Makefile plumbing that emits crate metadata and generates the export list. This is a workaround for the build system not supporting Rust cross-module dependencies natively, and it should go away once that lands.
- Connection create/destroy and interface activate/resume in gb-softsvc currently just acknowledge the request. Callbacks into NodeOps can be added when a transport actually needs to act on them; I did not want to invent an interface without a user.
- Zerocopy is currently not being used in grebeybus/protocols.rs. They cannot be derived yet since types generated by bindgen do not have them, and it seems explicitly forbindden to manually impl the traits. So using old traits from transmute.
- The bindings are supposed to be created for actual device, but any MCU that supports Zephyr, can run the greybus-zephyr firmware with UART transport. So not sure if adding a beagle,beagleconnect-freedom compatible is the correct choice here.
- The individual patches can be spun off into independent patch series if required. The reason for this single patch series is to provide a complete picture of usage.
- Since gb-softsvc currently is not being used from a C driver, no C API is provided. However, if required, it can be added.
- Writing to UART from gb-uart-node is currently a bit broken. I am not quite sure what the safe way is to go from a non-bound device to a bound device. Any suggestions on this front are welcome.
- I am not sure if Rust abstractions should have a seperate entry in MAINTAINERS with me as the maintainer, or if they should just be added to the respective subsystem entries.
[0]: https://github.com/beagleboard/greybus-zephyr [1]: https://lore.kernel.org/all/20260622-nova-exports-v5-0-6191773fc977@nvidia.c... [2]: https://lore.kernel.org/all/ecca8eb2-8e5a-4770-bcf6-3fb49773088b@beagleboard...
Signed-off-by: Ayush Singh ayush@beagleboard.org --- Ayush Singh (7): greybus: connection: Export gb_connection_get() and gb_connection_put() greybus: connection: Add gb_connection_hd_find_by_intf() rust: crc_ccitt: add CRC-CCITT abstraction rust: kernel: Add greybus abstractions drivers: greybus: Add software SVC implementation greybus: Add Rust UART node driver dt-bindings: beagle: Add BeagleConnect Freedom
.../beagle/beagle,beagleconnect-freedom.yaml | 30 ++ MAINTAINERS | 15 + drivers/greybus/.gitignore | 1 + drivers/greybus/Kconfig | 27 ++ drivers/greybus/Makefile | 50 +++ drivers/greybus/connection.c | 28 +- drivers/greybus/gb_softsvc.rs | 472 +++++++++++++++++++++ drivers/greybus/gb_softsvc_exports.c | 15 + drivers/greybus/gb_uart_node.rs | 231 ++++++++++ include/linux/greybus/connection.h | 6 + lib/crc/Kconfig | 7 + rust/bindings/bindings_helper.h | 2 + rust/kernel/crc_ccitt.rs | 26 ++ rust/kernel/greybus/hd.rs | 315 ++++++++++++++ rust/kernel/greybus/mod.rs | 230 ++++++++++ rust/kernel/greybus/protocols.rs | 392 +++++++++++++++++ rust/kernel/lib.rs | 4 + 17 files changed, 1849 insertions(+), 2 deletions(-) --- base-commit: 6b8c8af514d739d0335f5579b585e02babe8a727 change-id: 20260810-gb-uart-transport-9255d6557c4c
Best regards,