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

[Ayush Singh <ayush@beagleboard.org>]

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

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