greybus-dev

greybus-dev@lists.linaro.org

8 participants
866 discussions

Re: [PATCH] greybus: cap: bound IMS/auth memcpy to ioctl size

by Greg KH

On Fri, Sep 04, 2026 at 11:26:48AM +0530, Suraj Theekshana wrote: > Hi Greg, > > Sorry about that. I have switched Gmail to plain-text mode and am > > resending with replies inline below. > > > How was this found and tested? > > I found it while reviewing authentication.c. I then manually reviewed > the affected calculations and exercised them > using a userspace ASan harness based on the Greybus structures. > > The harness demonstrated the 2047-byte and 1983-byte copies into the > 1600-byte and 320-byte destinations, respectively. It did not exercise a > live CAP ioctl or Greybus transport and did not produce an in-kernel > KASAN report. > > I also built drivers/staging/greybus/authentication.o with W=1 on arm64, > and the submitted patch passed checkpatch without warnings. I do not > have access to real Greybus hardware, so it has not been tested on a > physical device. How well does the userspace harness actually exercise the code? Can you turn it into a valid kselftest test that we can add to the kernel tree to test the kernel code? > > And doesn't this info come from the hardware itself? Is it not trusted here? > > Yes, the response length comes from the Greybus endpoint hardware or its > firmware. My assumption was that a faulty or compromised endpoint should > not be able to cause an out-of-bounds copy, especially during component > authentication. > > However, I did not establish that hostile Greybus hardware is within the > kernel's intended threat model. If the endpoint is considered fully > trusted here, then I agree that this would be defensive hardening rather > than a demonstrated security-boundary issue. Our documentation (which your LLM should have read), says that we trust hardware :) > > Did you forget an Assisted-by: tag? > > Yes. That was my mistake. I used OpenAI Codex while preparing, > and validating the patch. Please read: https://lore.kernel.org/r/2026080354-skater-urgent-31b2@gregkh thanks, greg k-h

12 minutes

Re: [PATCH] greybus: cap: bound IMS/auth memcpy to ioctl size

by Greg KH

On Fri, Sep 04, 2026 at 10:54:49AM +0530, Suraj Theekshana wrote: > Hello Greg, Sorry, but the mailing list rejects html emails, please fix your email client and try again? Also, please try to not top-post. thanks, greg k-h

54 minutes

Re: [PATCH v2 7/7] greybus: Add Rust UART node driver

by Ayush Singh

On 9/4/26 2:19 AM, Markus Probst wrote: > On Thu, 2026-08-27 at 13:24 +0530, Ayush Singh wrote: >> Add a driver for Greybus nodes attached over a plain serial port. The >> node is registered with the software SVC (gb-softsvc), which handles the >> SVC protocol on behalf of the AP, so no dedicated coprocessor running >> SVC firmware is needed. >> >> Greybus messages are carried over HDLC framing on the wire. Each frame >> carries a one-byte address (0x01 for Greybus) and control byte, followed >> by the 16-bit CPort ID and the Greybus message itself. >> >> Port parameters are taken from the firmware node: "baudrate" if >> present, otherwise 115200, with flow control and parity disabled. >> >> Since gb-uart-node imports types from gb-softsvc, Rust to Rust calling >> setup from nova-core [0] is being used. >> >> [0]: https://lore.kernel.org/all/20260622-nova-exports-v5-0-6191773fc977@nvidia.… >> >> Signed-off-by: Ayush Singh <ayush(a)beagleboard.org> >> --- >> MAINTAINERS | 1 + >> drivers/greybus/.gitignore | 1 + >> drivers/greybus/Kconfig | 15 +++ >> drivers/greybus/Makefile | 48 ++++++++ >> drivers/greybus/gb_uart_node.rs | 245 ++++++++++++++++++++++++++++++++++++++++ >> 5 files changed, 310 insertions(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index d047090be5f4..49c6dac72748 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -11339,6 +11339,7 @@ M: Ayush Singh <ayush(a)beagleboard.com> >> L: greybus-dev(a)lists.linaro.org (moderated for non-subscribers) >> S: Maintained >> F: Documentation/devicetree/bindings/beagle/beagle,beagleconnect-freedom.yaml >> +F: drivers/greybus/gb_uart_node.rs >> >> GREYBUS SUBSYSTEM >> M: Johan Hovold <johan(a)kernel.org> >> diff --git a/drivers/greybus/.gitignore b/drivers/greybus/.gitignore >> new file mode 100644 >> index 000000000000..ff9c4a3539b4 >> --- /dev/null >> +++ b/drivers/greybus/.gitignore >> @@ -0,0 +1 @@ >> +exports_gb_softsvc_generated.h >> diff --git a/drivers/greybus/Kconfig b/drivers/greybus/Kconfig >> index 381d1a6ee135..34de913af287 100644 >> --- a/drivers/greybus/Kconfig >> +++ b/drivers/greybus/Kconfig >> @@ -60,5 +60,20 @@ config GREYBUS_SOFTSVC >> To compile this code as a module, choose M here: the module >> will be called gb-softsvc.ko >> >> +config GREYBUS_UART_NODE >> + tristate "Greybus UART node transport" >> + depends on RUST >> + depends on GREYBUS_SOFTSVC >> + depends on RUST_SERIAL_DEV_BUS_ABSTRACTIONS >> + select RUST_CRC_CCITT_ABSTRACTIONS >> + help >> + Select this option if you have a Greybus node connected over a >> + serial port. The node is registered with the software SVC, which >> + handles the SVC protocol on behalf of the AP, so no dedicated >> + coprocessor running SVC firmware is required. >> + >> + To compile this code as a module, choose M here: the module >> + will be called gb-uart-node.ko >> + >> endif # GREYBUS >> >> diff --git a/drivers/greybus/Makefile b/drivers/greybus/Makefile >> index e6f594128802..81151963c01e 100644 >> --- a/drivers/greybus/Makefile >> +++ b/drivers/greybus/Makefile >> @@ -28,3 +28,51 @@ obj-$(CONFIG_GREYBUS_ES2) += gb-es2.o >> obj-$(CONFIG_GREYBUS_SOFTSVC) += gb-softsvc.o >> gb-softsvc-y += gb_softsvc.o gb_softsvc_exports.o >> >> +obj-$(CONFIG_GREYBUS_UART_NODE) += gb-uart-node.o >> +gb-uart-node-y += gb_uart_node.o >> + >> +# Export Rust symbols from gb-softsvc only if gb-uart-node actually references them. >> +gb-softsvc-export-deps := $(if $(CONFIG_GREYBUS_UART_NODE),$(obj)/gb_uart_node.o) >> + >> +rust_needed_exports = \ >> + { $(if $(strip $(2)),$(NM) -u $(2);,) echo "__DEFINED_RUST_SYMBOLS__"; \ >> + $(NM) -p --defined-only $(1); } | \ >> + awk -v fmt='$(3)' ' \ >> + /^__DEFINED_RUST_SYMBOLS__$$/ { defs = 1; next } \ >> + !defs { if ($$NF ~ /^_R/) needed[$$NF] = 1; next } \ >> + defs && $$2 ~ /(T|R|D|B)/ && $$3 ~ /^_R/ && \ >> + $$3 !~ /_(init|cleanup)_module$$/ && \ >> + $$3 !~ /__(pfx|cfi|odr_asan)/ && \ >> + $$3 in needed { printf fmt, $$3 } \ >> + ' >> + >> +quiet_cmd_exports = EXPORTS $@ >> + cmd_exports = \ >> + $(call rust_needed_exports,$<,$(gb-softsvc-export-deps),EXPORT_SYMBOL_RUST_GPL(%s);\n) > $@ >> + >> +$(obj)/exports_gb_softsvc_generated.h: $(obj)/gb_softsvc.o $(gb-softsvc-export-deps) FORCE >> + $(call if_changed,exports) >> + >> +targets += exports_gb_softsvc_generated.h >> + >> +$(obj)/gb_softsvc_exports.o: $(obj)/exports_gb_softsvc_generated.h >> +CFLAGS_gb_softsvc_exports.o := -I $(objtree)/$(obj) >> + >> +ifdef CONFIG_MODVERSIONS >> +# The C export shim declares Rust symbols as `extern int`, so reuse its export >> +# list but generate symbol CRCs from the Rust object instead of the shim's DWARF. >> +$(obj)/gb_softsvc_exports.o: private cmd_gensymtypes_c = \ >> + $(call getexportsymbols,\1) | \ >> + $(objtree)/scripts/gendwarfksyms/gendwarfksyms \ >> + $(if $(KBUILD_GENDWARFKSYMS_STABLE), --stable) \ >> + $(if $(KBUILD_SYMTYPES), --symtypes $(@:.o=.symtypes),) \ >> + $(obj)/gb_softsvc.o >> +endif >> + >> +# Output nova-core's crate metadata for use by nova-drm at compile time. >> +RUSTFLAGS_gb_softsvc.o += \ >> + --emit=metadata=$(objtree)/$(obj)/libgb_softsvc.rmeta >> + >> +# Allow nova-drm to import nova-core's types. >> +$(obj)/gb_uart_node.o: $(obj)/gb_softsvc.o >> +RUSTFLAGS_gb_uart_node.o := -L $(objtree)/$(obj) --extern gb_softsvc >> diff --git a/drivers/greybus/gb_uart_node.rs b/drivers/greybus/gb_uart_node.rs >> new file mode 100644 >> index 000000000000..3eb4f8ab3655 >> --- /dev/null >> +++ b/drivers/greybus/gb_uart_node.rs >> @@ -0,0 +1,245 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> + >> +//! Greybus UART Node driver >> + >> +use kernel::{ >> + alloc::Flags, >> + crc_ccitt::crc_ccitt, >> + device::{ >> + AsBusDevice, >> + Bound, >> + Core, // >> + }, >> + error::code, >> + new_spinlock, of, >> + prelude::*, >> + serdev, >> + sync::{ >> + aref::ARef, >> + Arc, >> + SpinLock, // >> + }, >> +}; >> + >> +use zerocopy::little_endian; >> +use zerocopy_derive::{FromBytes, Immutable, KnownLayout}; >> + >> +const HDLC_MAX_FRAME_LEN: usize = 256; >> + >> +const HDLC_FRAME: u8 = 0x7E; >> +const HDLC_ESC: u8 = 0x7D; >> +const HDLC_XOR: u8 = 0x20; >> +const HDLC_EXPECTED_CRC: u16 = 0xf0b8; >> + >> +const ADDRESS_GREYBUS: u8 = 0x01; >> + >> +#[repr(C, packed)] >> +#[derive(FromBytes, Immutable, KnownLayout)] >> +struct GreybusFrame { >> + cport: little_endian::U16, >> + msg: [u8], >> +} >> + >> +struct HdlcRx { >> + rx_buf: KVec<u8>, >> + rx_in_esc: bool, >> + sdev: ARef<serdev::Device>, >> + node: gb_softsvc::Module, >> +} >> + >> +impl HdlcRx { >> + fn new(sdev: ARef<serdev::Device>, node: gb_softsvc::Module) -> Result<Self> { >> + Ok(Self { >> + node, >> + sdev, >> + rx_buf: KVec::with_capacity(HDLC_MAX_FRAME_LEN, GFP_KERNEL)?, >> + rx_in_esc: false, >> + }) >> + } >> + >> + fn frame_finish(&self) -> Result<()> { >> + if self.rx_buf.len() < 4 { >> + return Err(code::EFAULT); >> + } >> + >> + let crc = crc_ccitt(0xffff, &self.rx_buf); >> + if crc != HDLC_EXPECTED_CRC { >> + dev_warn!(self.sdev.as_ref(), "CRC failed {}", crc); >> + return Ok(()); >> + } >> + >> + let addr = self.rx_buf[0]; >> + let _ctrl = self.rx_buf[1]; >> + let payload = &self.rx_buf[2..self.rx_buf.len() - size_of::<u16>()]; >> + >> + match addr { >> + ADDRESS_GREYBUS => { >> + let frame = GreybusFrame::ref_from_bytes(payload).map_err(|_| code::EINVAL)?; >> + self.node.submit_message(0, frame.cport.into(), &frame.msg) >> + } >> + _ => Err(code::EINVAL), >> + } >> + } >> + >> + fn rx(&mut self, data: &[u8]) -> usize { >> + for i in data.iter() { >> + match *i { >> + HDLC_FRAME => { >> + if !self.rx_buf.is_empty() { >> + if let Err(e) = self.frame_finish() { >> + dev_warn!(self.sdev.as_ref(), "bad frame: {e:?}\n"); >> + } >> + } >> + >> + self.rx_buf.clear(); >> + self.rx_in_esc = false; >> + } >> + HDLC_ESC => self.rx_in_esc = true, >> + _ => { >> + let c = if self.rx_in_esc { *i ^ HDLC_XOR } else { *i }; >> + self.rx_in_esc = false; >> + >> + if self.rx_buf.push_within_capacity(c).is_err() { >> + dev_warn!(self.sdev.as_ref(), "buffer overflow. Dropping frame"); >> + >> + self.rx_buf.clear(); >> + self.rx_in_esc = false; >> + } >> + } >> + } >> + } >> + >> + data.len() >> + } >> +} >> + >> +struct GbNode { >> + sdev: ARef<serdev::Device>, >> +} >> + >> +impl GbNode { >> + const fn new(sdev: ARef<serdev::Device>) -> Self { >> + Self { sdev } >> + } >> + >> + fn fill_buf(mut crc: u16, data: &[u8], buf: &mut KVec<u8>) -> Result<u16> { >> + for i in data { >> + crc = crc_ccitt(crc, &[*i]); >> + if *i == HDLC_ESC || *i == HDLC_FRAME { >> + buf.push_within_capacity(HDLC_ESC)?; >> + buf.push_within_capacity(i ^ HDLC_XOR)?; >> + } else { >> + buf.push_within_capacity(*i)?; >> + } >> + } >> + >> + Ok(crc) >> + } >> +} >> + >> +impl gb_softsvc::InterfaceOps for GbNode { >> + fn write(&self, data: &[u8], cport: u16, gfp_mask: Flags) -> Result<()> { >> + // SAFETY: `GbNode` only exists while its serdev driver is bound, so the device is in the >> + // `Bound` state for the duration of this call. >> + let bound: &serdev::Device<Bound> = >> + unsafe { serdev::Device::from_device(self.sdev.as_ref().as_bound()) }; >> + >> + let mut buf = KVec::with_capacity(HDLC_MAX_FRAME_LEN, gfp_mask)?; >> + >> + let mut crc = 0xffff; >> + >> + buf.push_within_capacity(HDLC_FRAME)?; >> + >> + crc = Self::fill_buf(crc, &[ADDRESS_GREYBUS, 0x03], &mut buf)?; >> + crc = Self::fill_buf(crc, &cport.to_le_bytes(), &mut buf)?; >> + crc = Self::fill_buf(crc, data, &mut buf)?; >> + >> + crc ^= 0xffff; >> + Self::fill_buf(crc, &crc.to_le_bytes(), &mut buf)?; >> + >> + buf.push_within_capacity(HDLC_FRAME)?; >> + >> + bound.write_all(&buf, 0)?; >> + >> + Ok(()) >> + } >> +} >> + >> +#[pin_data] >> +struct GbUartNode { >> + #[pin] >> + rx: SpinLock<Option<HdlcRx>>, > (add me to CC please) > > Instead of using a lock here, it might be a better idea to > synchronize/stop the receive callback before unbind is called in the > serdev rust abstraction. This would allow the abstraction to provide > mutable references to the driver data in `receive` and `unbind`. It > would also remove the Sync requirement. > > I will send a patch soon. > > Thanks > - Markus Probst That sounds great. The lock here was basically only for getting a mut ref. I will base the next version on top of your patches. I have added your email for the next patch version. Best Regards, Ayush Singh

1 hour, 22 minutes

Re: [PATCH] greybus: cap: bound IMS/auth memcpy to ioctl size

by Greg KH

On Fri, Sep 04, 2026 at 03:46:28AM +0000, Suraj Theekshana wrote: > cap_get_ims_certificate() and cap_authenticate() derive copy > lengths from response payload sizes without checking the response > header size or destination capacity. How was this found and tested? And doesn't this info come from the hardware itself? Is it not trusted here? > Reject responses smaller than their headers with -EMSGSIZE. Reject > certificate and signature data larger than their fixed ioctl buffers > with -E2BIG. > > Signed-off-by: Suraj Theekshana <surajtheekshana1111(a)gmail.com> Did you forget an Assisted-by: tag? thanks, greg k-h

2 hours, 20 minutes

Re: greybus: CAP IMS/auth memcpy not capped to ioctl buffer

by Greg KH

On Thu, Sep 03, 2026 at 11:35:13PM +0530, Suraj Theekshana wrote: > Reproduce (no Greybus hardware) > =============================== > > git clone --depth 1 https://github.com/torvalds/linux.git > # tree used: 8ab1afb > > gcc -fsanitize=address -g -O0 -fno-builtin -U_FORTIFY_SOURCE \ > -I gb-poc \ > -I linux/drivers/staging/greybus \ > -I linux/include/linux/greybus \ > gb-poc/poc_cap_headers.c -o poc_cap_headers > > ./poc_cap_headers > ./poc_cap_headers auth That's not a reproducer if you don't have the hardware, right? > Files in the attached zip > ========================= As Willy said, please just provide a patch, like the documentation asked for, that you have tested with your reproducer. thanks, greg k-h

2 hours, 42 minutes

Re: greybus: CAP IMS/auth memcpy not capped to ioctl buffer

by Willy Tarreau

Hello, On Thu, Sep 03, 2026 at 11:35:13PM +0530, Suraj Theekshana wrote: > Hello, > > I am reporting an unbounded memcpy in the Greybus CAP driver. Note, there's no need to Cc security@ since you're also reporting to public lists. > Product: Linux kernel > File: drivers/staging/greybus/authentication.c > Header: drivers/staging/greybus/greybus_authentication.h > include/linux/greybus/greybus_protocols.h > Tree: torvalds/linux 8ab1afb > > Observed > ======== > > cap_get_ims_certificate() and cap_authenticate() do: > > *size = op->response->payload_size - sizeof(*response); > memcpy(dest, src, *size); > > The response buffer is allocated with gb_operation_get_payload_size_max() > and GB_OPERATION_FLAG_SHORT_RESPONSE. > > The ioctl destinations are fixed: > > certificate[CAP_CERTIFICATE_MAX_SIZE] /* 1600 */ > signature[CAP_SIGNATURE_MAX_SIZE] /* 320 */ > > There is no check that payload_size >= sizeof(*response) > and no cap to 1600 / 320. > > A 2048-byte payload therefore copies: > > IMS: 2048 - 1 = 2047 bytes into certificate[1600] > AUTH: 2048 - 65 = 1983 bytes into signature[320] > > A payload shorter than the response header wraps the unsigned subtract and > memcpy uses a huge length. > > Expected > ======== > > Reject payload_size < sizeof(*response) (-EMSGSIZE). > Reject copy length > CAP_CERTIFICATE_MAX_SIZE / > CAP_SIGNATURE_MAX_SIZE (-E2BIG). > > Reproduce (no Greybus hardware) > =============================== > > git clone --depth 1 https://github.com/torvalds/linux.git > # tree used: 8ab1afb > > gcc -fsanitize=address -g -O0 -fno-builtin -U_FORTIFY_SOURCE \ > -I gb-poc \ > -I linux/drivers/staging/greybus \ > -I linux/include/linux/greybus \ > gb-poc/poc_cap_headers.c -o poc_cap_headers > > ./poc_cap_headers > ./poc_cap_headers auth > > ASan excerpt (IMS) > ================== > > CAP_CERTIFICATE_MAX_SIZE=1600 CAP_SIGNATURE_MAX_SIZE=320 > [IMS] payload=2048 dest=1600 mode=ims > ================================================================= > ERROR: AddressSanitizer: stack-buffer-overflow > WRITE of size 2047 > #0 memcpy > #1 cap_get_ims_certificate poc_cap_headers.c:18 > #2 main poc_cap_headers.c:61 > Address is located in stack of thread T0 > This frame has 2 object(s): > [48, 481) 'a' > [560, 2173) 'ims' <== overflows certificate[1600] > SUMMARY: AddressSanitizer: stack-buffer-overflow in memcpy > ABORTING > > ASan excerpt (AUTH) > =================== > > CAP_CERTIFICATE_MAX_SIZE=1600 CAP_SIGNATURE_MAX_SIZE=320 > [AUTH] payload=2048 dest=320 > ================================================================= > ERROR: AddressSanitizer: stack-buffer-overflow > WRITE of size 1983 > #0 memcpy > #1 cap_authenticate poc_cap_headers.c:26 > #2 main poc_cap_headers.c:54 > Address is located in stack of thread T0 > This frame has 2 object(s): > [48, 481) 'a' <== overflows signature[320] > [560, 2173) 'ims' > SUMMARY: AddressSanitizer: stack-buffer-overflow in memcpy > ABORTING > > The PoC includes greybus_authentication.h and > greybus_protocols.h from this tree. It is not a live > CAP_IOC_* ioctl and there is no in-kernel KASAN frame. > > Impact > ====== > > Local overflow in the CAP ioctl path if a CAP connection exists and a > module answers GET_IMS_CERTIFICATE or AUTHENTICATE with an oversized or > truncated payload. > Not unauthenticated remote RCE. Same trust model as a malicious or buggy > Greybus module. > > Files in the attached zip > ========================= Please avoid sending binary files, as developers are unlikely to open them. > poc_cap_headers.c > ktypes.h > asan_ims.txt > asan_auth.txt As requested in the doc where you found the security list's email, please always try to propose a working patch so you can get full credit for finding and fixing issues and you can save maintainers' time. Please also see Docuemntation/process/submitting-patches.rst. > Regards, > Suraj Theekshana Thanks, Willy

4 hours, 1 minute

Re: [PATCH] staging: greybus: audio_codec: fix stack overflow in stream name parsing

by Greg KH

On Wed, Sep 02, 2026 at 10:17:00AM -0500, Yudi Yang wrote: > I found this with an internal program-analysis tool that I cannot disclose > yet, then manually verified the finding. intf_name and dir are 32-byte > arrays, while the unbounded %s conversions allow tokens from w->sname > longer than 31 characters to overflow them. Using %31s limits each > conversion to 31 characters. Please read our documentation which describes how you need to identify when you use tools like this. > I do not have Greybus hardware, so testing was limited to building the > affected object and running checkpatch.pl That's not really testing the code :( Please resubmit based on the documentation requirements. thanks, greg k-h

1 day, 2 hours

[PATCH] greybus: operation: fix out-of-bounds write in message allocation

by Adriano Cordova

The incoming message size from the device header (header.size) is trusted without checking that it is at least the size of the message header itself, but a value smaller than sizeof(struct gb_operation_msg_hdr) underflows request_size in gb_operation_create_incoming(), wraps around in gb_operation_message_alloc(), and results in a tiny buffer that is then written past its end in gb_operation_message_init(). Reject undersized messages before parsing the message header. Fixes: d37b1db13f8b ("greybus: refactor gb_connection_recv()") Reported-by: syzbot+2fd6aefc361af86911d5(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=2fd6aefc361af86911d5 Cc: stable(a)vger.kernel.org Signed-off-by: Adriano Cordova <adrianox(a)gmail.com> --- drivers/greybus/operation.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/greybus/operation.c b/drivers/greybus/operation.c index 7e12ffb2dd..df6daee4fb 100644 --- a/drivers/greybus/operation.c +++ b/drivers/greybus/operation.c @@ -1047,6 +1047,14 @@ void gb_connection_recv(struct gb_connection *connection, /* Use memcpy as data may be unaligned */ memcpy(&header, data, sizeof(header)); msg_size = le16_to_cpu(header.size); + if (msg_size < sizeof(header)) { + dev_err_ratelimited(dev, + "%s: malformed message 0x%04x of type 0x%02x received (%zu < %zu)\n", + connection->name, + le16_to_cpu(header.operation_id), + header.type, msg_size, sizeof(header)); + return; + } if (size < msg_size) { dev_err_ratelimited(dev, "%s: incomplete message 0x%04x of type 0x%02x received (%zu < %zu)\n", -- 2.51.0

2 days

[PATCH] staging: greybus: audio_codec: fix stack overflow in stream name parsing

by Yudi Yang

intf_name and dir are 32-byte buffers. Parsing a module-provided AIF stream name with unbounded %s conversions can cause buffer-overwrites. Limit each conversion to 31 characters. Fixes: 60e7327d54b2 ("greybus: audio: Find data connection based on id") Cc: stable(a)vger.kernel.org Signed-off-by: Yudi Yang <2000jedi(a)gmail.com> --- drivers/staging/greybus/audio_codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/audio_codec.c b/drivers/staging/greybus/audio_codec.c index 6daa4e706792..c3fefe1414f9 100644 --- a/drivers/staging/greybus/audio_codec.c +++ b/drivers/staging/greybus/audio_codec.c @@ -311,7 +311,7 @@ int gbaudio_module_update(struct gbaudio_codec_info *codec, } /* parse dai_id from AIF widget's stream_name */ - if (sscanf(w->sname, "%s %d %s", intf_name, &dai_id, dir) != 3) { + if (sscanf(w->sname, "%31s %d %31s", intf_name, &dai_id, dir) != 3) { dev_err(codec->dev, "Error while parsing dai_id for %s\n", w->name); return -EINVAL; } -- 2.43.0

2 days

[PATCH] staging: greybus: remove unused loopback macro

by André Moreira

The gb_loopback_attr macro is no longer used in the Greybus loopback driver. Remove the unused macro to avoid keeping dead code in the driver. Signed-off-by: André Moreira <andrem.33333(a)gmail.com> --- drivers/staging/greybus/loopback.c | 26 -------------------------- 1 file changed, 26 deletions(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index ea57b1f5d156..2a623fc2e99b 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -167,32 +167,6 @@ static DEVICE_ATTR_RO(name##_avg) gb_loopback_ro_stats_attr(field, max, u); \ gb_loopback_ro_avg_attr(field) -#define gb_loopback_attr(field, type) \ -static ssize_t field##_show(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - struct gb_loopback *gb = dev_get_drvdata(dev); \ - return sysfs_emit(buf, "%" #type "\n", gb->field); \ -} \ -static ssize_t field##_store(struct device *dev, \ - struct device_attribute *attr, \ - const char *buf, \ - size_t len) \ -{ \ - int ret; \ - struct gb_loopback *gb = dev_get_drvdata(dev); \ - mutex_lock(&gb->mutex); \ - ret = sscanf(buf, "%"#type, &gb->field); \ - if (ret != 1) \ - len = -EINVAL; \ - else \ - gb_loopback_check_attr(gb, bundle); \ - mutex_unlock(&gb->mutex); \ - return len; \ -} \ -static DEVICE_ATTR_RW(field) - #define gb_dev_loopback_ro_attr(field) \ static ssize_t field##_show(struct device *dev, \ struct device_attribute *attr, \ -- 2.43.0

2 days, 18 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev