Message-Id: <DFZNI1DOAZDK.H9BJA23QFFSG@silabs.com>
Date: Tue, 27 Jan 2026 15:23:44 -0500
From: Damien Riégel <damien.riegel@...abs.com>
To: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Damien Riégel <damien.riegel@...abs.com>
Cc: <greybus-dev@...ts.linaro.org>, <linux-kernel@...r.kernel.org>,
        "Johan
 Hovold" <johan@...nel.org>, "Alex Elder" <elder@...nel.org>,
        <linux-devel@...abs.com>
Subject: Re: [PATCH 0/8] greybus: support point-to-point topology

On Fri Jan 16, 2026 at 10:09 AM EST, Greg Kroah-Hartman wrote:
[...]

>>
>> The SVC doesn' really serve a purpose here, as there is no bus to
>> manage, and adding its support only increase the complexity and the code
>> size needed on memory-constrained devices.
>
> Exactly how much memory does a "single point" SVC driver take, vs.
> adding new P2P functionality everywhere in the code like you just did?
> Finding that out would be good first before worrying about adding
> another type of "bus" here please.

Sorry for not giving numbers in the cover letter. We measured 10kB of
code size difference (which may be on the higher end of the spectrum)
and in Zephyr [1] they measured a 2kB difference (which is probably on
the lower end considering the implementation is pretty barebone).

>> The goal of this patchset is to let a single module expose some Greybus
>> protocols without requiring the module to also implement SVC protocol.
>> We call this mode "Point-To-Point". There are three main notable facts
>> with the implementation of this patchset:
>>
>>   - most of the time, what this patchet does is just skipping calls that
>>     issue commands to the SVC, as they are not applicable without an SVC
>
> Great, make a SVC that just ignores them :)

We can't really *completely* ignore them, we need to respond in a way
that lets Linux think this is a legit SVC, or it will stop probing. But
that's mostly what we already do and what they do in Zephyr [2], only
connection create/destroy really matters to map CPort ID between AP and
Interface.

>>   - CPort ID allocation is a bit different as there is no SVC/Bridge to
>>     do translation between AP address space and interface address space,
>>     so the patchset forces allocation of AP CPort IDs that matches the
>>     ones found in interface's manifest
>
> Again, a simple SCV would make this not needed.
>
>>   - enumeration of a module is normally started by a "Module Inserted"
>>     event issued by the SVC. As the SVC is absent, the host device
>>     driver must manually call a function to start the enumeration
>
> I'd prefer again, to have that in the SVC you are using.
>
>> We tested this patchset with the gb-beagleplay driver, slightly tweaked
>> to only keep the HLDC over UART part of the driver, connected over UART
>> to an EFR32MG24 running BeagleBoard's implementation of Greybus-Zephyr [1].
>>
>> In the discussion to integrate this module into Zephyr [2] (it's
>> currently as separate module not part of the main Zephyr code base),
>> there seems to be interest in being able to have a single-node
>> device on the bus without SVC [3]. If some features that were
>> implemented by the SVC are missing, we can consider adding more
>> callbacks to the gb_hd_driver structure at a later time, and let drivers
>> decide how they want to support these features.
>
> I can understand if you want to be a greybus host running zephyr that
> this might make sense, as it lets you not even have to write any SVC
> logic, but for Linux here, I think the simplicity makes more sense (i.e.
> everything goes through the same data paths, no multiple test paths that
> need to always be exercised.)
>
> So I'd prefer not to do this, just try to make a simple svc module and
> see if that works instead.

That's what we currently have and it works, but it comes at the cost of
more flash usage. That being said, I understand the concern of wanting
to keep the current implementation simple and have only one data path. I
think the benefits are not big enough in terms of code size savings to
justify pushing this patchset further, so I will just leave it as is.
It's out there if someone wants to try and improve it to be less
intrusive :)

thanks,
damien

[1] https://github.com/zephyrproject-rtos/zephyr/issues/98259#issuecomment-3774577266
[2] https://github.com/beagleboard/greybus-zephyr/blob/main/subsys/greybus/svc.c

Powered by blists - more mailing lists