In a classic Greybus topology, there is an application processor, an
SVC, and one or more modules, all connected to a UniPro bus. Most of the
time, as the application processor doesn't have a UniPro interface, it
is actually connected to a device acting as a bridge with the bus, and
this bridge also acts as the SVC.

Sometimes, there is no UniPro bus at all, like for the BeaglePlay, which
has the following topology:

    +----+                +------------+                    +--------+
    | AP | <--- UART ---> | SVC/Bridge | <--- 802.15.4 ---> | Module |
    +----+                +------------+                    +--------+
                                |
                                |                           +--------+
                                `------------ 802.15.4 ---> | Module |
                                                            +--------+

There are two main interesting aspects with Greybus:
  - the SVC protocol to monitor and configure the bus
  - other protocols, to expose module peripherals to the host

When the bus has a single module connected directly to the AP, then this
module must also implement the SVC protocol:

                 +----+               +------------+
                 | AP | <--- bus ---> | SVC/Module |
                 +----+               +------------+

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.

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

  - 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

  - 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

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.

[1] https://github.com/beagleboard/greybus-zephyr
[2] https://github.com/zephyrproject-rtos/zephyr/issues/98259
[3] https://github.com/zephyrproject-rtos/zephyr/issues/98259#issuecomment-3561347045

Damien Riégel (8):
  greybus: add P2P interface type
  greybus: let gb_interface_create take additional p2p argument
  greybus: force CPort ID allocation in P2P mode
  greybus: split module creation function
  greybus: add function create module in P2P mode
  greybus: make host API work without SVC
  greybus: add function to create SVC-less host device
  greybus: add function to probe p2p module

 drivers/greybus/connection.c      | 15 ++++--
 drivers/greybus/hd.c              | 80 +++++++++++++++++++++++++++----
 drivers/greybus/interface.c       | 72 ++++++++++++++++++++--------
 drivers/greybus/module.c          | 55 ++++++++++++++++++---
 include/linux/greybus/hd.h        |  6 +++
 include/linux/greybus/interface.h |  4 +-
 include/linux/greybus/module.h    |  1 +
 7 files changed, 193 insertions(+), 40 deletions(-)

-- 
2.49.0

On Tue, Dec 23, 2025 at 01:31:34PM -0500, Damien Riégel wrote:
> In a classic Greybus topology, there is an application processor, an
> SVC, and one or more modules, all connected to a UniPro bus. Most of the
> time, as the application processor doesn't have a UniPro interface, it
> is actually connected to a device acting as a bridge with the bus, and
> this bridge also acts as the SVC.
> 
> Sometimes, there is no UniPro bus at all, like for the BeaglePlay, which
> has the following topology:
> 
>     +----+                +------------+                    +--------+
>     | AP | <--- UART ---> | SVC/Bridge | <--- 802.15.4 ---> | Module |
>     +----+                +------------+                    +--------+
>                                 |
>                                 |                           +--------+
>                                 `------------ 802.15.4 ---> | Module |
>                                                             +--------+
> 
> There are two main interesting aspects with Greybus:
>   - the SVC protocol to monitor and configure the bus
>   - other protocols, to expose module peripherals to the host
> 
> When the bus has a single module connected directly to the AP, then this
> module must also implement the SVC protocol:
> 
>                  +----+               +------------+
>                  | AP | <--- bus ---> | SVC/Module |
>                  +----+               +------------+
> 
> 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.

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

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

thanks,

greg k-h

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

On Tue, Jan 27, 2026 at 03:23:44PM -0500, Damien Riégel wrote:
> 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).

Please submit your "empty" SVC driver, 10kb seems too big to me, I think
we can slim it down, or at the very least, see what is making it "large"
and potentially work to reduce that.

For Zephyr, I thought it was 1kb in the github comments, but still 2kb
seems reasonable :)

thanks,

greg k-h

On Wed Jan 28, 2026 at 1:04 AM EST, Greg Kroah-Hartman wrote:
> On Tue, Jan 27, 2026 at 03:23:44PM -0500, Damien Riégel wrote:
>> 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).
>
> Please submit your "empty" SVC driver, 10kb seems too big to me, I think
> we can slim it down, or at the very least, see what is making it "large"
> and potentially work to reduce that.

The comparison I did originally was pretty naive. When I tested without
the SVC, the C files were not even compiled. What I didn't account for
is that our SVC currently logs pretty extensively, and guess where these
log strings are stored...

After removing the logs, I could compare apples to apples:
 - with SVC: 59,272 B
 - without SVC: 57,556 B

So not even 2kB difference.

> For Zephyr, I thought it was 1kb in the github comments, but still 2kb
> seems reasonable :)

The last comment in the thread says 2kB, but it's in the same ballpark.

So I think we have our number, an empty SVC would be in the 1kB to 2kB
range.