greybus-dev February 2026

greybus-dev@lists.linaro.org

22 participants
41 discussions

[PATCH] greybus: match `GREYBUS_DEVICE` drivers to vendor class bundles

by Yacin Belmihoub-Martel

The Greybus specification defines the Vendor Specific bundle class[1]. Using this class allows vendors to avoid defining a custom generic class, simplifying driver development. Currently, drivers can register to either match on a bundle class or a Vendor & Product ID with `GREYBUS_CLASS` and `GREYBUS_DEVICE` respectively. However, when matching to a vendor specific driver, the current implementation does not check the bundle's class. This has the effect of matching the vendor specific driver to ANY bundle found in the device's manifest, regardless of its class. This is incorrect as only vendor class bundles should be considered. For instance, a driver registered for `GREYBUS_DEVICE(0xCAFE, 0xBABE)` would be matched to a Camera class bundle found on that device. Instead, only a `GREYBUS_CLASS_VENDOR` class bundle should get matched to the driver. [1] https://github.com/projectara/greybus-spec/blob/149aa4a8f4422533475e0193ece… Signed-off-by: Yacin Belmihoub-Martel <yacin.belmihoubmartel(a)gmail.com> --- drivers/greybus/core.c | 12 ++++-------- include/linux/greybus.h | 10 +++------- include/linux/greybus/greybus_id.h | 6 ------ 3 files changed, 7 insertions(+), 21 deletions(-) diff --git a/drivers/greybus/core.c b/drivers/greybus/core.c index 313eb65cf..4cd218d29 100644 --- a/drivers/greybus/core.c +++ b/drivers/greybus/core.c @@ -60,16 +60,12 @@ static int is_gb_svc(const struct device *dev) static bool greybus_match_one_id(struct gb_bundle *bundle, const struct greybus_bundle_id *id) { - if ((id->match_flags & GREYBUS_ID_MATCH_VENDOR) && - (id->vendor != bundle->intf->vendor_id)) + if (id->class != bundle->class) return false; - if ((id->match_flags & GREYBUS_ID_MATCH_PRODUCT) && - (id->product != bundle->intf->product_id)) - return false; - - if ((id->match_flags & GREYBUS_ID_MATCH_CLASS) && - (id->class != bundle->class)) + if ((id->class == GREYBUS_CLASS_VENDOR) && + (id->vendor != bundle->intf->vendor_id || + id->product != bundle->intf->product_id)) return false; return true; diff --git a/include/linux/greybus.h b/include/linux/greybus.h index 4d58e27ce..1f1b3cb5c 100644 --- a/include/linux/greybus.h +++ b/include/linux/greybus.h @@ -37,18 +37,14 @@ #define GREYBUS_VERSION_MAJOR 0x00 #define GREYBUS_VERSION_MINOR 0x01 -#define GREYBUS_ID_MATCH_DEVICE \ - (GREYBUS_ID_MATCH_VENDOR | GREYBUS_ID_MATCH_PRODUCT) +#define GREYBUS_DEVICE_CLASS(c) \ + .class = (c), #define GREYBUS_DEVICE(v, p) \ - .match_flags = GREYBUS_ID_MATCH_DEVICE, \ + GREYBUS_DEVICE_CLASS(GREYBUS_CLASS_VENDOR)\ .vendor = (v), \ .product = (p), -#define GREYBUS_DEVICE_CLASS(c) \ - .match_flags = GREYBUS_ID_MATCH_CLASS, \ - .class = (c), - /* Maximum number of CPorts */ #define CPORT_ID_MAX 4095 /* UniPro max id is 4095 */ #define CPORT_ID_BAD U16_MAX diff --git a/include/linux/greybus/greybus_id.h b/include/linux/greybus/greybus_id.h index f4c844009..e33ed0061 100644 --- a/include/linux/greybus/greybus_id.h +++ b/include/linux/greybus/greybus_id.h @@ -11,7 +11,6 @@ struct greybus_bundle_id { - __u16 match_flags; __u32 vendor; __u32 product; __u8 class; @@ -19,9 +18,4 @@ struct greybus_bundle_id { kernel_ulong_t driver_info __aligned(sizeof(kernel_ulong_t)); }; -/* Used to match the greybus_bundle_id */ -#define GREYBUS_ID_MATCH_VENDOR BIT(0) -#define GREYBUS_ID_MATCH_PRODUCT BIT(1) -#define GREYBUS_ID_MATCH_CLASS BIT(2) - #endif /* __LINUX_GREYBUS_ID_H */ -- 2.52.0

2 weeks, 4 days

[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…

3 weeks, 1 day

[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

3 weeks, 5 days

[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

3 weeks, 5 days

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

by kunal km

3 weeks, 6 days

[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

3 weeks, 6 days

[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

3 weeks, 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

3 weeks, 6 days

[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

3 weeks, 6 days

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

4 weeks

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev February 2026