greybus-dev February 2026

greybus-dev@lists.linaro.org

22 participants
41 discussions

[RFC] greybus: support combined Host + SVC

by Ayush Singh

Hello everyone, I’ve recently been experimenting with chaining multiple Greybus nodes to a single host over I²C (QWIIC port [0]). This general idea is not new (see MicroMod Qwiic Pro Kit [1]), although those setups do not use Greybus. Since I²C does not allow a slave to initiate transfers, it is not well suited for node-initiated events (e.g. interrupts, SVC-initiated control). However, for my current use case I am primarily interested in polling-based functionality, so this limitation is acceptable. In a typical Greybus topology, an Application Processor (AP), an SVC, and one or more modules are connected via UniPro. In practice, because most application processors lack a native UniPro interface, they connect through a bridge device that also implements the SVC. For the I²C-based setup described above, I have considered the following topologies: 1. Separate co-processor (SVC/Bridge) This approach is reasonable on SoCs such as TI AM6254, which include an M4F core that can serve as the SVC/bridge and control the I²C bus. However, on devices like TI AM62L, which lack such a core, introducing an additional processor solely for Greybus does not seem justified. Also, this would make the above much less portable, since it expects a hardware component, not all BeagleBoard.org boards have. ``` +----+ +---------------+ +----------+ | AP | <--- bus ----> | SVC / Bridge | <--- I2C ----> | Module | +----+ +---------------+ +----------+ | | +----------+ `----------- I2C ----> | Module | +----------+ ``` 2. SVC per node Each node implements its own SVC. Since an I²C slave cannot initiate communication, the AP must already know the address of each SVC/module. This also seems inefficient when chaining multiple nodes. ``` +----+ +----------------+ | AP | <--- I2C ---> | SVC / Module | +----+ +----------------+ | | +----------------+ `---- I2C ----> | SVC / Module | +----------------+ ``` 3. SVC/Bridge functionality inside the AP For this use case, this seems to be the most practical option. To clarify, I am not proposing any new data paths in the Greybus pipeline. The idea is to have a reusable an SVC/bridge implementation similar to what exists in greybus-zephyr [2][3], but hosted within the AP. ``` +-------------+ +-----------+ | AP / SVC | <--- I2C ---> | Module | +-------------+ +-----------+ | | +----------+ `-- I2C ---> | Module | +----------+ ``` Before proceeding further, I would appreciate feedback on this approach—particularly whether there are concerns with option 3, or if there are alternative designs I should consider. Best regards, Ayush Singh [0]: https://www.sparkfun.com/qwiic [1]: https://www.digikey.in/en/maker/projects/micromod-qwiic-pro-kit-project-gui… [2]: https://github.com/beagleboard/greybus-zephyr/blob/main/subsys/greybus/svc.… [3]: https://github.com/beagleboard/greybus-zephyr/blob/main/subsys/greybus/apbr…

1 day, 1 hour

[PATCH 1/2] staging: greybus: uart: fix style issues

by Shubham Chakraborty

Fix checkpatch.pl warnings by adding comments to mutex and spinlocks, and fixing alignment to match open parenthesis. Signed-off-by: Shubham Chakraborty <chakrabortyshubham66(a)gmail.com> --- drivers/staging/greybus/uart.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c index 7d060b4cd33d..1d2c4ef70865 100644 --- a/drivers/staging/greybus/uart.c +++ b/drivers/staging/greybus/uart.c @@ -50,12 +50,12 @@ struct gb_tty { unsigned int minor; unsigned char clocal; bool disconnected; - spinlock_t read_lock; - spinlock_t write_lock; + spinlock_t read_lock; /* protects read operations */ + spinlock_t write_lock; /* protects write operations */ struct async_icount iocount; struct async_icount oldcount; wait_queue_head_t wioctl; - struct mutex mutex; + struct mutex mutex; /* serializes port operations */ u8 ctrlin; /* input control lines */ u8 ctrlout; /* output control lines */ struct gb_uart_set_line_coding_request line_coding; @@ -318,7 +318,7 @@ static int gb_uart_wait_for_all_credits(struct gb_tty *gb_tty) return 0; ret = wait_for_completion_timeout(&gb_tty->credits_complete, - msecs_to_jiffies(GB_UART_CREDIT_WAIT_TIMEOUT_MSEC)); + msecs_to_jiffies(GB_UART_CREDIT_WAIT_TIMEOUT_MSEC)); if (!ret) { dev_err(&gb_tty->gbphy_dev->dev, "time out waiting for credits\n"); -- 2.53.0

4 days, 22 hours

[PATCH] staging: greybus: audio_manager_module: make envp array const

by kunal km

From 630a0c3367818fa30032b85df71fbb03eaefb1b4 Mon Sep 17 00:00:00 2001 From: Kunal <kunalkmr9717(a)outlook.com> Date: Thu, 26 Feb 2026 11:31:47 +0000 Subject: [PATCH] staging: greybus: audio_manager_module: make envp array const Signed-off-by: Kunal <kunalkmr9717(a)outlook.com> --- drivers/staging/greybus/audio_manager_module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/audio_manager_module.c b/drivers/staging/greybus/audio_manager_module.c index e87b82ca6d8a..7a25af3421d8 100644 --- a/drivers/staging/greybus/audio_manager_module.c +++ b/drivers/staging/greybus/audio_manager_module.c @@ -159,7 +159,7 @@ static void send_add_uevent(struct gb_audio_manager_module *module) char ip_devices_string[64]; char op_devices_string[64]; - char *envp[] = { + char * const envp[] = { name_string, vid_string, pid_string, -- 2.43.0

5 days, 19 hours

[PATCH] staging: greybus: audio_manager_module: make envp array const

by kunal km

5 days, 19 hours

[PATCH] staging: greybus: arche: use sysfs_emit() instead of sprintf()

by Ruslan Valiyev

Replace sprintf() with sysfs_emit() in state_show() sysfs attribute callbacks in arche-platform.c and arche-apb-ctrl.c. sysfs_emit() is preferred over sprintf() in sysfs show functions because it is aware of the PAGE_SIZE buffer limit, preventing potential buffer overflows. This addresses checkpatch warnings about the use of sprintf() in sysfs show callbacks. Signed-off-by: Ruslan Valiyev <linuxoid(a)gmail.com> --- drivers/staging/greybus/arche-apb-ctrl.c | 10 +++++----- drivers/staging/greybus/arche-platform.c | 10 +++++----- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/staging/greybus/arche-apb-ctrl.c b/drivers/staging/greybus/arche-apb-ctrl.c index 33f26a65f..19a6e59b6 100644 --- a/drivers/staging/greybus/arche-apb-ctrl.c +++ b/drivers/staging/greybus/arche-apb-ctrl.c @@ -300,16 +300,16 @@ static ssize_t state_show(struct device *dev, switch (apb->state) { case ARCHE_PLATFORM_STATE_OFF: - return sprintf(buf, "off%s\n", + return sysfs_emit(buf, "off%s\n", apb->init_disabled ? ",disabled" : ""); case ARCHE_PLATFORM_STATE_ACTIVE: - return sprintf(buf, "active\n"); + return sysfs_emit(buf, "active\n"); case ARCHE_PLATFORM_STATE_STANDBY: - return sprintf(buf, "standby\n"); + return sysfs_emit(buf, "standby\n"); case ARCHE_PLATFORM_STATE_FW_FLASHING: - return sprintf(buf, "fw_flashing\n"); + return sysfs_emit(buf, "fw_flashing\n"); default: - return sprintf(buf, "unknown state\n"); + return sysfs_emit(buf, "unknown state\n"); } } diff --git a/drivers/staging/greybus/arche-platform.c b/drivers/staging/greybus/arche-platform.c index f669a7e2e..de5de59ea 100644 --- a/drivers/staging/greybus/arche-platform.c +++ b/drivers/staging/greybus/arche-platform.c @@ -374,15 +374,15 @@ static ssize_t state_show(struct device *dev, switch (arche_pdata->state) { case ARCHE_PLATFORM_STATE_OFF: - return sprintf(buf, "off\n"); + return sysfs_emit(buf, "off\n"); case ARCHE_PLATFORM_STATE_ACTIVE: - return sprintf(buf, "active\n"); + return sysfs_emit(buf, "active\n"); case ARCHE_PLATFORM_STATE_STANDBY: - return sprintf(buf, "standby\n"); + return sysfs_emit(buf, "standby\n"); case ARCHE_PLATFORM_STATE_FW_FLASHING: - return sprintf(buf, "fw_flashing\n"); + return sysfs_emit(buf, "fw_flashing\n"); default: - return sprintf(buf, "unknown state\n"); + return sysfs_emit(buf, "unknown state\n"); } } -- 2.43.0

5 days, 23 hours

[PATCH] staging: greybus: arche-platform: Use sysfs_emit instead of sprintf

by Shubham Chakraborty

Refactor sprintf to sysfs_emit in the show function of the arche platform driver. This follows the standard kernel practice of using sysfs_emit for sysfs attributes, ensuring consistent output formatting and newline handling. Signed-off-by: Shubham Chakraborty <chakrabortyshubham66(a)gmail.com> --- drivers/staging/greybus/arche-platform.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/greybus/arche-platform.c b/drivers/staging/greybus/arche-platform.c index f669a7e2eb11..de5de59ea8ab 100644 --- a/drivers/staging/greybus/arche-platform.c +++ b/drivers/staging/greybus/arche-platform.c @@ -374,15 +374,15 @@ static ssize_t state_show(struct device *dev, switch (arche_pdata->state) { case ARCHE_PLATFORM_STATE_OFF: - return sprintf(buf, "off\n"); + return sysfs_emit(buf, "off\n"); case ARCHE_PLATFORM_STATE_ACTIVE: - return sprintf(buf, "active\n"); + return sysfs_emit(buf, "active\n"); case ARCHE_PLATFORM_STATE_STANDBY: - return sprintf(buf, "standby\n"); + return sysfs_emit(buf, "standby\n"); case ARCHE_PLATFORM_STATE_FW_FLASHING: - return sprintf(buf, "fw_flashing\n"); + return sysfs_emit(buf, "fw_flashing\n"); default: - return sprintf(buf, "unknown state\n"); + return sysfs_emit(buf, "unknown state\n"); } } -- 2.53.0

6 days

[PATCH v3 0/2] staging: greybus: audio: remove dead code and clean up

by Hardik Phalet

This series cleans up dead code in the Greybus audio manager. gb_audio_manager_get_module() has no in-tree callers. The previously reported NULL dereference is therefore unreachable. Per review feedback, the unused function is removed to avoid carrying dead code. Patch 2 performs a small cleanup in the same area. Changes in v3: - Replaced the NULL-deref fix with removal of gb_audio_manager_get_module() since there are no in-tree callers (per Greg KH). - No functional changes otherwise. Thanks for the review. Signed-off-by: Hardik Phalet <hardik.phalet(a)pm.me> Hardik Phalet (2): staging: greybus: audio: remove unused gb_audio_manager_get_module() staging: greybus: audio: drop stale TODO comment drivers/staging/greybus/audio_manager.c | 12 ------------ drivers/staging/greybus/audio_manager.h | 7 ------- drivers/staging/greybus/audio_manager_module.c | 1 - 3 files changed, 20 deletions(-) -- 2.53.0

6 days, 16 hours

[PATCH] staging: greybus: Use guard(mutex) in receive_data()

by Matvey Oborotov

Replace manual mutex_lock/unlock with guard(mutex) in raw.c receive_data(). This automates lock release on function exit, ensures that lock is released on early returns, and makes the code cleaner. Signed-off-by: Matvey Oborotov <oborotovmatvey(a)gmail.com> --- drivers/staging/greybus/raw.c | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/drivers/staging/greybus/raw.c b/drivers/staging/greybus/raw.c index 3027a2c25bcd..6c31bae0d8ea 100644 --- a/drivers/staging/greybus/raw.c +++ b/drivers/staging/greybus/raw.c @@ -59,34 +59,28 @@ static int receive_data(struct gb_raw *raw, u32 len, u8 *data) { struct raw_data *raw_data; struct device *dev = &raw->connection->bundle->dev; - int retval = 0; if (len > MAX_PACKET_SIZE) { dev_err(dev, "Too big of a data packet, rejected\n"); return -EINVAL; } - mutex_lock(&raw->list_lock); + guard(mutex)(&raw->list_lock); if ((raw->list_data + len) > MAX_DATA_SIZE) { dev_err(dev, "Too much data in receive buffer, now dropping packets\n"); - retval = -EINVAL; - goto exit; + return -EINVAL; } raw_data = kmalloc_flex(*raw_data, data, len); - if (!raw_data) { - retval = -ENOMEM; - goto exit; - } + if (!raw_data) + return -ENOMEM; raw->list_data += len; raw_data->len = len; memcpy(&raw_data->data[0], data, len); list_add_tail(&raw_data->entry, &raw->list); -exit: - mutex_unlock(&raw->list_lock); - return retval; + return 0; } static int gb_raw_request_handler(struct gb_operation *op) -- 2.43.0

6 days, 16 hours

Re: [PATCH] staging: greybus: camera: add comment for mutex

by Jose A. Perez de Azpillaga

Thank you for the honest feedback. I'm a new contributor and I was trying to resolve the checkpatch.pl CHECKs to get familiar with the process, but I see now that vague documentation can be worse than none at all. I'll withdraw this patch. Since I'm looking to make my first meaningful contribution to staging, do you have any suggestions on what types of issues in Greybus are actually helpful for a beginner to tackle? regards, jose

6 days, 20 hours

[PATCH] staging: greybus: camera: add comment for mutex

by Jose A. Perez de Azpillaga

Add a comment to the mutex definition in struct gb_camera to describe what it protects, satisfying a checkpatch.pl CHECK. Signed-off-by: Jose A. Perez de Azpillaga <azpijr(a)gmail.com> --- Hi, I noticed a CHECK for alignment in this file on line 267. However, fixing it pushed the line over 100 characters. I felt that adding extreme indentation might add more noise than value, so I've only included the mutex comment fix here. I'd appreciate your guidance on whether you prefer strict alignment even if it breaks the 100-column rule in these specific cases. --- drivers/staging/greybus/camera.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c index 62b55bb28408..a6f3637b8871 100644 --- a/drivers/staging/greybus/camera.c +++ b/drivers/staging/greybus/camera.c @@ -53,7 +53,7 @@ struct gb_camera { struct gb_connection *data_connection; u16 data_cport_id; - struct mutex mutex; + struct mutex mutex; /* Protects camera state */ enum gb_camera_state state; struct { -- 2.53.0

6 days, 20 hours

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev February 2026