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

[Ayush Singh <ayush@beagleboard.org>]

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


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