This patch series contains two minor cleanups for the arche-platform driver:
Patch 1: Clarifies an unclear TODO comment to make the intent more obvious
to future developers.
Patch 2: Fixes a simple spelling mistake in a comment.
These are low-risk changes that improve code readability.
Get Outlook for Android<https://aka.ms/AAb9ysg>
This patch series contains two minor cleanups for the arche-platform driver:
Patch 1: Clarifies an unclear TODO comment to make the intent more obvious
to future developers.
Patch 2: Fixes a simple spelling mistake in a comment.
These are low-risk changes that improve code readability.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari(a)suse.com>
Reviewed-by: Johan Hovold <johan(a)kernel.org>
---
Changes in v2:
- updated commit log removing two paragraph not strictly related to
the work.
- subject changed removing "drivers/" before the actual prefix.
---
drivers/greybus/operation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/greybus/operation.c b/drivers/greybus/operation.c
index 54ccc434a1f7..7e12ffb2dd60 100644
--- a/drivers/greybus/operation.c
+++ b/drivers/greybus/operation.c
@@ -1238,7 +1238,7 @@ int __init gb_operation_init(void)
goto err_destroy_message_cache;
gb_operation_completion_wq = alloc_workqueue("greybus_completion",
- 0, 0);
+ WQ_PERCPU, 0);
if (!gb_operation_completion_wq)
goto err_destroy_operation_cache;
--
2.51.1
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-3561…
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