greybus-dev

greybus-dev@lists.linaro.org

15 participants
700 discussions

[PATCH v3 2/4] staging: greybus: fixed styling issue in fw-management.c

by Rachit Dhar

Fixed a styling issue highlighted by checkpatch.pl. Signed-off-by: Rachit Dhar <rchtdhr(a)gmail.com> --- drivers/staging/greybus/fw-management.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/fw-management.c b/drivers/staging/greybus/fw-management.c index 07a0e6b63cf3..cf917ddb79c4 100644 --- a/drivers/staging/greybus/fw-management.c +++ b/drivers/staging/greybus/fw-management.c @@ -434,7 +434,8 @@ static int fw_mgmt_ioctl(struct fw_mgmt *fw_mgmt, unsigned int cmd, return -EFAULT; ret = fw_mgmt_load_and_validate_operation(fw_mgmt, - intf_load.load_method, intf_load.firmware_tag); + intf_load.load_method, + intf_load.firmware_tag); if (ret) return ret; -- 2.43.0

9 hours, 47 minutes

[PATCH v3 1/4] staging: greybus: added comment to mutex declaration in fw-management.c

by Rachit Dhar

Added comment to mutex declaration, to resolve a checkpatch.pl check. Signed-off-by: Rachit Dhar <rchtdhr(a)gmail.com> --- drivers/staging/greybus/fw-management.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/fw-management.c b/drivers/staging/greybus/fw-management.c index 152949c23d65..07a0e6b63cf3 100644 --- a/drivers/staging/greybus/fw-management.c +++ b/drivers/staging/greybus/fw-management.c @@ -28,7 +28,7 @@ struct fw_mgmt { /* Common id-map for interface and backend firmware requests */ struct ida id_map; - struct mutex mutex; + struct mutex mutex; /* protects fw_mgmt->disabled, and serializes ioctl */ struct completion completion; struct cdev cdev; struct device *class_device; -- 2.43.0

9 hours, 59 minutes

How To Recover From Fake Cryptocurrency / Usdt Investment Scam Digital Light Solution

by brouwerspatrick81＠gmail.com

I’ve always believed that sustainability begins at home—not just in how we recycle or conserve energy, but in the very structures we live in. For years, I dreamed of building a zero-waste neighborhood where every house functions like a living ecosystem: solar-powered, water-wise, and crowned with rooftop greenhouses that feed families and filter air. It wasn’t just architecture—it was my vision for a quieter, cleaner future. To make it real, I turned to Bitcoin. Not as a speculative bet, but as a long-term store of value aligned with my values—decentralized, transparent, and independent of broken systems. Over seven years, I poured savings, side income, and relentless discipline into building a $680,000 crypto portfolio. Every coin had a purpose: permits, materials, and community partnerships. My dream had a balance sheet. Then, in one exhausted, distracted moment, it all collapsed. It was November 2025. I was juggling contractor delays, city inspections, and endless design revisions. My nerves were frayed, my coffee pot never empty. When a “Ledger Live Update” notification popped up, I didn’t think twice. The interface looked identical—same logo, same layout. I entered my credentials… and within seconds, the app disappeared. My wallet balance dropped to zero. I sat frozen. My stomach dropped. All that work—years of sacrifice—gone in a blink. The days that followed were dark. I scoured forums, filed reports, and replayed my mistake on loop. Guilt ate at me. How could I have been so careless? My greenhouse renderings sat untouched. My dream felt like a cruel joke. Just when I was ready to walk away, I stumbled upon a newsletter about green innovation. Tucked between articles on carbon-neutral cities and next-gen solar panels was a short feature on *Digital Light Solution*—a specialized team that helps victims of crypto theft recover stolen assets. Skeptical but desperate, I reached out. What followed wasn’t magic—but it was close to it. Their team treated my case with urgency and compassion. They traced the transaction trail, identified the laundering path, and worked with exchanges to freeze what they could. Within weeks, they’d recovered a significant portion of my funds—enough to restart. Today, I’m not just rebuilding my portfolio—I’m breaking ground on my prototype greenhouse. And every beam, every pane of glass, carries the lesson I learned: that even in our most vulnerable moments, there’s still light to be found. Email:support@digitallightsolution.com Telegram ——digitallightsolution website https://digitallightsolution.com/ WhatsApp https://wa.link/989vlf

1 day, 20 hours

[PATCH v3 00/14] greybus: introduce CPC as transport layer

by Damien Riégel

Hi, This patchset brings support for Silicon Labs' CPC protocol as transport layer for Greybus. CPC stands for Co-Processor Communication and currently exists as a userspace daemon [1] that enables multiple applications on a coprocessor to share a single physical link to a Linux host, using a protocol loosely based on HDLC [2]. While the userspace implementations serves its purpose, it has some redundancies with Greybus that makes it not very suitable for kernel integration as-is, and so the protocol has been modified to better fit with Greybus. Even though kernel and userspace implementations share the same name, they are not the same protocol and are not compatible. The kernel integration with Greybus is intended to superseed the userspace implementation. CPC is introduced as a module that sits between Greybus and CPC Host Device Drivers implementations, like SDIO or SPI. This patchset includes SDIO as physical layer but the protocol is not final and might change, it's mostly there to showcase all the elements. +----------------------------------------------------+ | Greybus | +----------------------------------------------------+ /|\ | \|/ +----------------------------------------------------+ | CPC | +----------------------------------------------------+ /|\ /|\ /|\ | | | \|/ \|/ \|/ +----------+ +---------+ +-----------+ | SDIO | | SPI | | Others | +----------+ +---------+ +-----------+ CPC implements some of the features of Unipro that Greybus relies upon, like reliable transmission. CPC takes care of detecting transmission errors and retransmit frames if necessary, but that feature is not part of the RFC to keep it concise. There's also a flow-control feature, preventing sending messages to already full cports. In order to implement these features, a 4-byte header is prepended to Greybus messages, making the whole header 12 bytes (Greybus header is 8 bytes). This RFC starts by implementing a shim layer between physical bus drivers (like SDIO and SPI) and Greybus, and progressively add more elements to it to make it useful in its own right. Finally, an SDIO driver is added to enable the communication with a remote device. [1] https://github.com/SiliconLabs/cpc-daemon [2] https://en.wikipedia.org/wiki/High-Level_Data_Link_Control Changes in v3: - addressed Jerome's review comments, mostly for SDIO driver - rewrote cover letter and commit messages across the series Changes in v2: - addressed review comments and errors reported by kernel bot - for SDIO driver, remove padding between headers and payloads when aggregating packets together Damien Riégel (13): greybus: cpc: add minimal CPC Host Device infrastructure greybus: cpc: introduce CPC cport structure greybus: cpc: use socket buffers instead of gb_message in TX path greybus: cpc: pack cport ID in Greybus header greybus: cpc: switch RX path to socket buffers greybus: cpc: introduce CPC header structure greybus: cpc: account for CPC header size in RX and TX path greybus: cpc: add and validate sequence numbers greybus: cpc: acknowledge all incoming messages greybus: cpc: use holding queue instead of sending out immediately greybus: cpc: honour remote's RX window greybus: cpc: let host device drivers dequeue TX frames greybus: cpc: add private data pointer in CPC Host Device Gabriel Beaulieu (1): greybus: cpc: add CPC SDIO host driver MAINTAINERS | 6 + drivers/greybus/Kconfig | 2 + drivers/greybus/Makefile | 2 + drivers/greybus/cpc/Kconfig | 24 ++ drivers/greybus/cpc/Makefile | 9 + drivers/greybus/cpc/cpc.h | 75 ++++++ drivers/greybus/cpc/cport.c | 112 ++++++++ drivers/greybus/cpc/header.c | 136 ++++++++++ drivers/greybus/cpc/header.h | 52 ++++ drivers/greybus/cpc/host.c | 319 ++++++++++++++++++++++ drivers/greybus/cpc/host.h | 63 +++++ drivers/greybus/cpc/protocol.c | 170 ++++++++++++ drivers/greybus/cpc/sdio.c | 480 +++++++++++++++++++++++++++++++++ 13 files changed, 1450 insertions(+) create mode 100644 drivers/greybus/cpc/Kconfig create mode 100644 drivers/greybus/cpc/Makefile create mode 100644 drivers/greybus/cpc/cpc.h create mode 100644 drivers/greybus/cpc/cport.c create mode 100644 drivers/greybus/cpc/header.c create mode 100644 drivers/greybus/cpc/header.h create mode 100644 drivers/greybus/cpc/host.c create mode 100644 drivers/greybus/cpc/host.h create mode 100644 drivers/greybus/cpc/protocol.c create mode 100644 drivers/greybus/cpc/sdio.c -- 2.52.0

2 days, 16 hours

PATCH 1/1: greybus/usb: handle unspecified lengths in hub_control

by Jose A. Perez de Azpillaga

From 1e099b581fe475905509b9d600015ea2500b8cf8 Mon Sep 17 00:00:00 2001 From: "Jose A. Perez de Azpillaga" <azpijr(a)gmail.com> Date: Wed, 11 Feb 2026 22:54:40 +0100 Subject: [PATCH] greybus/usb: handle unspecified lengths in hub_control Fixes the FIXME in hub_control where response length was not handled correctly. Signed-off-by: Jose A. Perez de Azpillaga <azpijr(a)gmail.com> --- drivers/staging/greybus/usb.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/staging/greybus/usb.c b/drivers/staging/greybus/usb.c index 475f24f20cd4..f5f5a4863ddc 100644 --- a/drivers/staging/greybus/usb.c +++ b/drivers/staging/greybus/usb.c @@ -105,8 +105,10 @@ static int hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, u16 wIndex, size_t response_size; int ret; - /* FIXME: handle unspecified lengths */ - response_size = sizeof(*response) + wLength; + /* Calculate expected response size */ + response_size = sizeof(*response); + if (wLength) + response_size += wLength; operation = gb_operation_create(dev->connection, GB_USB_TYPE_HUB_CONTROL, @@ -127,9 +129,13 @@ static int hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, u16 wIndex, goto out; if (wLength) { - /* Greybus core has verified response size */ - response = operation->response->payload; - memcpy(buf, response->buf, wLength); + size_t actual_size = operation->response->payload_size - sizeof(*response); + size_t copy_size = min(wLength, actual_size); + + if (copy_size) { + response = operation->response->payload; + memcpy(buf, response->buf, copy_size); + } } out: gb_operation_put(operation); -- 2.51.0

3 days, 20 hours

[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

5 days, 14 hours

[PATCH] staging: greybus: remove unused apb_ctrl_fw_flashing() and apb_ctrl_standby_boot()

by Bruno Martins

These functions were left behind when commit 921dbe52b40b ("greybus: arche-platform: Add support for SPI bus sharing for Mihi") removed their only callers in 2016. Signed-off-by: Bruno Martins <ehanoc(a)protonmail.com> --- drivers/staging/greybus/arche-apb-ctrl.c | 10 ---------- drivers/staging/greybus/arche_platform.h | 2 -- 2 files changed, 12 deletions(-) diff --git a/drivers/staging/greybus/arche-apb-ctrl.c b/drivers/staging/greybus/arche-apb-ctrl.c index 90ab32638d3f..6a50b79bb787 100644 --- a/drivers/staging/greybus/arche-apb-ctrl.c +++ b/drivers/staging/greybus/arche-apb-ctrl.c @@ -230,16 +230,6 @@ int apb_ctrl_coldboot(struct device *dev) return coldboot_seq(to_platform_device(dev)); } -int apb_ctrl_fw_flashing(struct device *dev) -{ - return fw_flashing_seq(to_platform_device(dev)); -} - -int apb_ctrl_standby_boot(struct device *dev) -{ - return standby_boot_seq(to_platform_device(dev)); -} - void apb_ctrl_poweroff(struct device *dev) { poweroff_seq(to_platform_device(dev)); diff --git a/drivers/staging/greybus/arche_platform.h b/drivers/staging/greybus/arche_platform.h index 9d997f2d6517..5d0692af2533 100644 --- a/drivers/staging/greybus/arche_platform.h +++ b/drivers/staging/greybus/arche_platform.h @@ -21,8 +21,6 @@ void __exit arche_apb_exit(void); /* Operational states for the APB device */ int apb_ctrl_coldboot(struct device *dev); -int apb_ctrl_fw_flashing(struct device *dev); -int apb_ctrl_standby_boot(struct device *dev); void apb_ctrl_poweroff(struct device *dev); #endif /* __ARCHE_PLATFORM_H */ -- 2.47.3

1 week, 1 day

[PATCH v3] [PATCH v3] staging: greybus: gbphy: Replace sprintf() with sysfs_emit()

by Neel Bullywon

Replace sprintf() with sysfs_emit() in the protocol_id_show() sysfs attribute function. This code is safe as-is, but replace sprintf() with sysfs_emit() because we are trying to get rid of calls to sprintf() as part of kernel hardening; sysfs_emit() is more appropriate in this context. Signed-off-by: Neel Bullywon <neelb2403(a)gmail.com> --- This was compile-tested only (no VM/hardware used) Changes in v2: - Subject: change to imperative "Replace" (was "Replaced"). - Wording and line breaks adjusted in the commit body for clarity. Changes in v3: - Clarify what "safe" means (buffer is PAGE_SIZE) per Dan Carpenter's suggestion. - Reflow lines to avoid awkward breaks. --- drivers/staging/greybus/gbphy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/gbphy.c b/drivers/staging/greybus/gbphy.c index 60cf09a302a7..55f132b09cee 100644 --- a/drivers/staging/greybus/gbphy.c +++ b/drivers/staging/greybus/gbphy.c @@ -31,7 +31,7 @@ static ssize_t protocol_id_show(struct device *dev, { struct gbphy_device *gbphy_dev = to_gbphy_dev(dev); - return sprintf(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id); + return sysfs_emit(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id); } static DEVICE_ATTR_RO(protocol_id); base-commit: de0674d9bc69699c497477d45172493393ae9007 -- 2.44.0

1 week, 2 days

[PATCH] staging: greybus: uart: migrated from IDR to XArray API

by Neel Bullywon

Replaced the IDR API with the XArray API for managing TTY minor numbers. This addresses the checkpatch warning about DEFINE_IDR being deprecated. Following changes include: - Replaced DEFINE_IDR with DEFINE_XARRAY_ALLOC - Replace idr_find with xa_load - Replace idr_alloc with xa_alloc - Replace idr_remove with xa_erase - Replace idr_destroy with xa_destroy - Updated the include to use xarray No core functional changes, just modernized the code to a new API. Signed-off-by: Neel Bullywon <neelb2403(a)gmail.com> --- drivers/staging/greybus/uart.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c index 5cece0a6606f..8bd6bf0a57a8 100644 --- a/drivers/staging/greybus/uart.c +++ b/drivers/staging/greybus/uart.c @@ -22,7 +22,7 @@ #include <linux/serial.h> #include <linux/tty_driver.h> #include <linux/tty_flip.h> -#include <linux/idr.h> +#include <linux/xarray.h> #include <linux/fs.h> #include <linux/kdev_t.h> #include <linux/kfifo.h> @@ -67,7 +67,7 @@ struct gb_tty { }; static struct tty_driver *gb_tty_driver; -static DEFINE_IDR(tty_minors); +static DEFINE_XARRAY_ALLOC(tty_minors); static DEFINE_MUTEX(table_lock); static int gb_uart_receive_data_handler(struct gb_operation *op) @@ -342,7 +342,7 @@ static struct gb_tty *get_gb_by_minor(unsigned int minor) struct gb_tty *gb_tty; mutex_lock(&table_lock); - gb_tty = idr_find(&tty_minors, minor); + gb_tty = xa_load(&tty_minors, minor); if (gb_tty) { mutex_lock(&gb_tty->mutex); if (gb_tty->disconnected) { @@ -362,7 +362,7 @@ static int alloc_minor(struct gb_tty *gb_tty) int minor; mutex_lock(&table_lock); - minor = idr_alloc(&tty_minors, gb_tty, 0, GB_NUM_MINORS, GFP_KERNEL); + minor = xa_alloc(&tty_minors, &minor, gb_tty, XA_LIMIT(0, GB_NUM_MINORS - 1), GFP_KERNEL); mutex_unlock(&table_lock); if (minor >= 0) gb_tty->minor = minor; @@ -375,7 +375,7 @@ static void release_minor(struct gb_tty *gb_tty) gb_tty->minor = 0; /* Maybe should use an invalid value instead */ mutex_lock(&table_lock); - idr_remove(&tty_minors, minor); + xa_erase(&tty_minors, minor); mutex_unlock(&table_lock); } @@ -984,7 +984,7 @@ static void gb_tty_exit(void) { tty_unregister_driver(gb_tty_driver); tty_driver_kref_put(gb_tty_driver); - idr_destroy(&tty_minors); + xa_destroy(&tty_minors); } static const struct gbphy_device_id gb_uart_id_table[] = { -- 2.44.0

1 week, 2 days

[PATCH v3 4/4] staging: greybus: resolved checkpatch checks for light.c

by Rachit Dhar

Added comment to mutex declarations, to resolve checkpatch.pl checks. Signed-off-by: Rachit Dhar <rchtdhr(a)gmail.com> --- drivers/staging/greybus/light.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index e509fdc715db..1f2faa6d545d 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -37,7 +37,7 @@ struct gb_channel { bool releasing; bool strobe_state; bool active; - struct mutex lock; + struct mutex lock; /* protects gb_channel->active */ }; struct gb_light { @@ -59,7 +59,7 @@ struct gb_lights { struct gb_connection *connection; u8 lights_count; struct gb_light *lights; - struct mutex lights_lock; + struct mutex lights_lock; /* protects gb_lights->lights */ }; static void gb_lights_channel_free(struct gb_channel *channel); -- 2.43.0

1 week, 4 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev