greybus-dev

greybus-dev@lists.linaro.org

20 participants
783 discussions

Fwd: [PATCH v2 3/4] staging: greybus: resolved checkpatch checks for raw.c

by Rachit Dhar

---------- Forwarded message --------- From: Rachit Dhar <rchtdhr(a)gmail.com> Date: Tue, Feb 3, 2026 at 6:02 PM Subject: [PATCH v2 3/4] staging: greybus: resolved checkpatch checks for raw.c To: Cc: Rachit Dhar <rchtdhr(a)gmail.com>, Johan Hovold <johan(a)kernel.org>, Alex Elder <elder(a)kernel.org>, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Added comment to mutex declaration, to resolve checkpatch.pl check. Signed-off-by: Rachit Dhar <rchtdhr(a)gmail.com> --- drivers/staging/greybus/raw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/raw.c b/drivers/staging/greybus/raw.c index 71de6776739c..4f217f20f1c0 100644 --- a/drivers/staging/greybus/raw.c +++ b/drivers/staging/greybus/raw.c @@ -20,7 +20,7 @@ struct gb_raw { struct list_head list; int list_data; - struct mutex list_lock; + struct mutex list_lock; /* protects gb_raw->list and gb_raw->list_data */ dev_t dev; struct cdev cdev; struct device *device; -- 2.43.0

3 months, 3 weeks

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

by Rachit Dhar

---------- Forwarded message --------- From: Rachit Dhar <rchtdhr(a)gmail.com> Date: Tue, Feb 3, 2026 at 6:02 PM Subject: [PATCH v2 2/4] staging: greybus: fixed styling issue in fw-management.c To: Cc: Rachit Dhar <rchtdhr(a)gmail.com>, Viresh Kumar <vireshk(a)kernel.org>, Johan Hovold <johan(a)kernel.org>, Alex Elder <elder(a)kernel.org>, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> 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

3 months, 3 weeks

[PATCH 1/3] staging: greybus: resolved checkpatch checks for fw-management.c

by Rachit Dhar

Resolved two checks highlighted by checkpatch.pl: - added comment to mutex declaration - fixed styling issue Signed-off-by: Rachit Dhar <rchtdhr(a)gmail.com> --- drivers/staging/greybus/fw-management.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/fw-management.c b/drivers/staging/greybus/fw-management.c index 152949c23d65..cf917ddb79c4 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; @@ -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

3 months, 3 weeks

[PATCH 3/3] 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

3 months, 3 weeks

[PATCH 2/3] staging: greybus: resolved checkpatch checks for raw.c

by Rachit Dhar

Added comment to mutex declaration, to resolve checkpatch.pl check. Signed-off-by: Rachit Dhar <rchtdhr(a)gmail.com> --- drivers/staging/greybus/raw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/raw.c b/drivers/staging/greybus/raw.c index 71de6776739c..4f217f20f1c0 100644 --- a/drivers/staging/greybus/raw.c +++ b/drivers/staging/greybus/raw.c @@ -20,7 +20,7 @@ struct gb_raw { struct list_head list; int list_data; - struct mutex list_lock; + struct mutex list_lock; /* protects gb_raw->list and gb_raw->list_data */ dev_t dev; struct cdev cdev; struct device *device; -- 2.43.0

3 months, 3 weeks

Hire SAFEGUARD RECOVERY, a Bitcoin recovery specialist, to retrieve stolen or lost coins.

by sophia fourest

I invested $320,000 in Tether (USDT) on a fraudulent website after falling for a romantic scam. I felt completely helpless and in need of assistance after realizing I had been duped. I started looking for a hacker online and found SAFEGUARD RECOVERY. I had optimism because of his professionalism and knowledge. I'm happy to report that SAFEGUARD RECOVERY successfully recovered my stolen money after working relentlessly to do so! I am immensely appreciative of their help and heartily urge anyone in a comparable circumstance to use their services. I'm grateful Email: safeguardbitcoin(a)consultant.com WhatsApp: +44 7426 168300 Website: https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

3 months, 3 weeks

[PATCH 0/8] greybus: support point-to-point topology

by Damien Riégel

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

4 months

[PATCH v2 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. This 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. +----------------------------------------------------+ | 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. 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 | 22 ++ 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 | 55 ++++ drivers/greybus/cpc/host.c | 313 +++++++++++++++++++ drivers/greybus/cpc/host.h | 63 ++++ drivers/greybus/cpc/protocol.c | 168 +++++++++++ drivers/greybus/cpc/sdio.c | 533 +++++++++++++++++++++++++++++++++ 13 files changed, 1496 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

4 months

[PATCH] staging: greybus: remove completed GPIO conversion task from TODO

by Archit Anant

The task to convert the Greybus subsystem to the GPIO descriptor interface has been completed. A grep of the directory confirms that no consumer drivers include <linux/gpio.h> or use the legacy integer based GPIO API (gpio_request, gpio_set_value, etc). Remove the stale entry from the TODO file. Signed-off-by: Archit Anant <architanant5(a)gmail.com> --- drivers/staging/greybus/TODO | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/greybus/TODO b/drivers/staging/greybus/TODO index 6461e0132fe3..43fb6dc3dff0 100644 --- a/drivers/staging/greybus/TODO +++ b/drivers/staging/greybus/TODO @@ -1,5 +1,2 @@ -* Convert all uses of the old GPIO API from <linux/gpio.h> to the - GPIO descriptor API in <linux/gpio/consumer.h> and look up GPIO - lines from device tree or ACPI. * Make pwm.c use the struct pwm_ops::apply instead of ::config, ::set_polarity, ::enable and ::disable. -- 2.39.5

4 months

[PATCH] staging: greybus: audio: Limit scope of jack-related variables

by Lee Yongjun

Move jack-related variable declarations inside the CONFIG_SND_JACK conditional block. These variables are only used when CONFIG_SND_JACK is enabled, so limiting their scope improves code clarity and avoids unused variable warnings when the option is disabled. No functional changes intended. Signed-off-by: Lee Yongjun <jun85566(a)gmail.com> --- drivers/staging/greybus/audio_codec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/audio_codec.c b/drivers/staging/greybus/audio_codec.c index 444c53b4e08d..f752d5fbd685 100644 --- a/drivers/staging/greybus/audio_codec.c +++ b/drivers/staging/greybus/audio_codec.c @@ -935,8 +935,6 @@ static void gbaudio_codec_cleanup(struct gbaudio_module_info *module) void gbaudio_unregister_module(struct gbaudio_module_info *module) { struct snd_soc_component *comp = gbcodec->component; - struct gbaudio_jack *jack, *n; - int mask; dev_dbg(comp->dev, "Unregister %s module\n", module->name); @@ -948,6 +946,8 @@ void gbaudio_unregister_module(struct gbaudio_module_info *module) mutex_unlock(&gbcodec->lock); #ifdef CONFIG_SND_JACK + struct gbaudio_jack *jack, *n; + int mask; /* free jack devices for this module jack_list */ list_for_each_entry_safe(jack, n, &module->jack_list, list) { if (jack == &module->headset) -- 2.34.1

4 months, 1 week

← Newer
1
...
8
9
10
11
12
13
14
...
79
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev