Re: [RFC] greybus: support combined Host + SVC

["Damien Riégel" <damien.riegel@silabs.com>]

On Sat Feb 28, 2026 at 8:47 AM EST, Ayush Singh wrote:
> 2. 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.
>
> [...]
>
> 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.

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);
    	}
    }

>     ```
>         +-------------+                +-----------+
>         | 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