Re: [RFC] greybus: support combined Host + SVC
From: Ayush Singh
Date: Fri Mar 27 2026 - 23:35:57 EST
On 3/3/26 11:55 AM, Ayush Singh wrote:
On 3/3/26 3:27 AM, Damien Riégel wrote:
On Sat Feb 28, 2026 at 8:47 AM EST, Ayush Singh wrote:
2. SVC per nodeWe discussed internally at Silicon Labs of this solution to get rid of
Each node implements its own SVC. Since an I²C slave cannot initiate
communication, the AP must already know the address of each SVC/module.
This also seems inefficient when chaining multiple nodes.
[...]
3. SVC/Bridge functionality inside the AP
For this use case, this seems to be the most practical option.
To clarify, I am not proposing any new data paths in the Greybus
pipeline. The idea is to have a reusable an SVC/bridge implementation
similar to what exists in greybus-zephyr [2][3], but hosted within the AP.
the SVC on the device but haven't actually implemented it, good to know
that we were not alone. I think it's a great avenue to explore because
it keeps existing SVC code as is, so we keep a single data path in
Greybus' core while offering the capability to handle SVC requests on
the host.
Just to help me get a better mental picture, in hd->message_send you
would either handle the message immediately if cport_id == 0, or convert
that cport_id to an (interface, intf_cport_id) and pass the message to
that interface's cport, something like that?
static int message_send(..., u16 cport_id, struct gb_message *msg, ...)
{
if (cport_id == GB_SVC_CPORT_ID) {
return svc_bridge_handle_msg(msg);
} else {
struct connection *connection = svc_bridge_get_connection(cport_id);
// ... or you could directly look up in hd->connections,
// the whole list of connections is already there, so
// no need to maintain another one separately
// somewhow convert connection->intf to an i2c address
// and use connection->intf_cport_id to address the cport
i2c_transfer(adap, msgs, 1);
}
}
Yes, that's the basic idea. The APIs will probably look a bit different, but let me see how much info linux greybus module already has.
```You mention in point 2 that i2c slaves cannot initiate communication, so
+-------------+ +-----------+
| AP / SVC | <--- I2C ---> | Module |
+-------------+ +-----------+
|
| +----------+
`-- I2C ---> | Module |
+----------+
```
I wonder how you would emulate the "MODULE_INSERTED" that flows from SVC
to the AP. Would your HD poll the bus for connected modules and "send" a
MODULE_INSERTED for each of them?
Besides that, I think it would work fine. I'll be happy to test and
review your patch when ready.
Regards,
damien
I am currently thinking of having a debugfs entry to manually add and remove modules for the demo I am working on. Generally, I would prefer not doing continuous polling on linux. But I am thinking of doing the polling based discovery on the driver probe.
Best Regards,
Ayush Singh
I do have a working SVC kernel module now [0]. Need to brush up some things on I2C transport side, but the svc node code seems to be in good state. Tested with BeagleConnect Freedom running Greybus-Zephyr over I2C.
Best Regards,
Ayush Singh
[0]: https://github.com/Ayush1325/linux/blob/b4/gb-i2c-transport/drivers/greybus/svc_node.c