Message-ID: <2026011606-qualified-dental-bef0@gregkh>
Date: Fri, 16 Jan 2026 16:09:20 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: 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 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

Powered by blists - more mailing lists