On Tue, Dec 23, 2025 at 01:31:34PM -0500, Damien Riégel wrote:
In a classic Greybus topology, there is an application processor, an SVC, and one or more modules, all connected to a UniPro bus. Most of the time, as the application processor doesn't have a UniPro interface, it is actually connected to a device acting as a bridge with the bus, and this bridge also acts as the SVC.
Sometimes, there is no UniPro bus at all, like for the BeaglePlay, which has the following topology:
+----+ +------------+ +--------+ | AP | <--- UART ---> | SVC/Bridge | <--- 802.15.4 ---> | Module | +----+ +------------+ +--------+ | | +--------+ `------------ 802.15.4 ---> | Module | +--------+There are two main interesting aspects with Greybus:
- the SVC protocol to monitor and configure the bus
- other protocols, to expose module peripherals to the host
When the bus has a single module connected directly to the AP, then this module must also implement the SVC protocol:
+----+ +------------+ | AP | <--- bus ---> | SVC/Module | +----+ +------------+The SVC doesn' really serve a purpose here, as there is no bus to manage, and adding its support only increase the complexity and the code size needed on memory-constrained devices.
Exactly how much memory does a "single point" SVC driver take, vs. adding new P2P functionality everywhere in the code like you just did? Finding that out would be good first before worrying about adding another type of "bus" here please.
The goal of this patchset is to let a single module expose some Greybus protocols without requiring the module to also implement SVC protocol. We call this mode "Point-To-Point". There are three main notable facts with the implementation of this patchset:
- most of the time, what this patchet does is just skipping calls that issue commands to the SVC, as they are not applicable without an SVC
Great, make a SVC that just ignores them :)
- CPort ID allocation is a bit different as there is no SVC/Bridge to do translation between AP address space and interface address space, so the patchset forces allocation of AP CPort IDs that matches the ones found in interface's manifest
Again, a simple SCV would make this not needed.
- enumeration of a module is normally started by a "Module Inserted" event issued by the SVC. As the SVC is absent, the host device driver must manually call a function to start the enumeration
I'd prefer again, to have that in the SVC you are using.
We tested this patchset with the gb-beagleplay driver, slightly tweaked to only keep the HLDC over UART part of the driver, connected over UART to an EFR32MG24 running BeagleBoard's implementation of Greybus-Zephyr [1].
In the discussion to integrate this module into Zephyr [2] (it's currently as separate module not part of the main Zephyr code base), there seems to be interest in being able to have a single-node device on the bus without SVC [3]. If some features that were implemented by the SVC are missing, we can consider adding more callbacks to the gb_hd_driver structure at a later time, and let drivers decide how they want to support these features.
I can understand if you want to be a greybus host running zephyr that this might make sense, as it lets you not even have to write any SVC logic, but for Linux here, I think the simplicity makes more sense (i.e. everything goes through the same data paths, no multiple test paths that need to always be exercised.)
So I'd prefer not to do this, just try to make a simple svc module and see if that works instead.
thanks,
greg k-h