On 3/3/26 3:27 AM, Damien Riégel wrote:
On Sat Feb 28, 2026 at 8:47 AM EST, Ayush Singh wrote:
SVC per node
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.
[...]
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.
We discussed internally at Silicon Labs of this solution to get rid of 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.
``` +-------------+ +-----------+ | AP / SVC | <--- I2C ---> | Module | +-------------+ +-----------+ | | +----------+ `-- I2C ---> | Module | +----------+ ```You mention in point 2 that i2c slaves cannot initiate communication, so 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