lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251223183142.31897-1-damien.riegel@silabs.com>
Date: Tue, 23 Dec 2025 13:31:34 -0500
From: Damien Riégel <damien.riegel@...abs.com>
To: greybus-dev@...ts.linaro.org
Cc: linux-kernel@...r.kernel.org, Johan Hovold <johan@...nel.org>,
        Alex Elder <elder@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-devel@...abs.com,
        Damien Riégel <damien.riegel@...abs.com>
Subject: [PATCH 0/8] greybus: support point-to-point topology

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ