* Re: [PATCH v8 0/2] staging: rtl8723bs: Fix error handling in _rtw_pktfile_read()
From: Andy Shevchenko @ 2026-06-03 14:06 UTC (permalink / raw)
To: Bitterblue Smith
Cc: Minu Jin, gregkh, dan.carpenter, abrahamadekunle50,
zxcv2569763104, milospuric856, karanja99erick, weibu,
linux-staging, linux-kernel
In-Reply-To: <fa16641f-d6b2-47e8-b1a9-08d63387c733@gmail.com>
On Wed, Jun 03, 2026 at 04:40:45PM +0300, Bitterblue Smith wrote:
> On 03/06/2026 03:48, Andy Shevchenko wrote:
> > On Sun, May 24, 2026 at 09:30:01PM +0300, Bitterblue Smith wrote:
> >> On 27/01/2026 17:38, Minu Jin wrote:
> >>> This series improves error handling in _rtw_pktfile_read() and cleans up
> >>> the code style to comply with kernel standards.
> >>>
> >>> 1. The first patch combines the logic change and caller updates.
> >>> The function change and the caller updates must be in the same
> >>> patch. If they are separated, the code will not work correctly
> >>> or will cause errors at that specific point in the history.
> >>>
> >>> 2. The second patch focuses purely on code style cleanup (changing uint
> >>> to unsigned int) as requested by Andy Shevchenko.
> >>>
> >>> Regarding the logic change in _rtw_pktfile_read():
> >>>
> >>> The original code used a ternary operator to read whatever data was
> >>> available, even if it was less than requested. This could lead to
> >>> callers processing incomplete data without knowing it.
> >>>
> >>> I have changed this to return -EINVAL when the remaining data is insufficient.
> >>> This is safer because most callers expect the exact amount of data and
> >>> should not proceed with a partial read.
> >>>
> >>> Testing and Verification:
> >>>
> >>> I do not have access to the physical RTL8723BS hardware. However, I have
> >>> performed a rigorous manual audit of the data path and verified the
> >>> changes using Smatch static analysis. The analysis confirmed that no
> >>> new warnings or logical regressions were introduced in the modified files.
> >>
> >> I have some bad news:
> >>
> >> https://bbs.archlinux.org/viewtopic.php?id=313401
> >
> > It's unclear that this patch made it happen. See below.
>
> It looks pretty clear to me, but okay. I forwarded your request for bisection.
I don't know how it does. There is no information about from which kernel one
upgrades to which. I assumed someone bumps from v7.0 to v7.0.3, but there no
such patch. If we take v6.19..v7.0.3 range, there are dozens of patches.
I.o.w. it is semi-poorly written bug report: some of useful information and
some crucial that is missing...
> >> [quote]
> >>
> >> Hey everyone,
> >>
> >> I recently upgraded my system, and now I’m having a strange issue with my
> >> WiFi (Realtek RTL8723BS).
> >>
> >> now I can no longer connect to any WiFi networks as a client. however,
> >> creating an Access Point (AP) still works fine, but whenever I try to connect
> >> to an existing network, the connection fails.
> >>
> >> dmesg logs:
> >> Every time I attempt a connection, dmesg gets spammed with this error:
> >>
> >> [ 1083.925640] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> >> [ 1084.921217] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> >> [ 1085.921434] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> >> [ 1086.922320] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> >> ....
> >>
> >> Has anyone encountered this specific "coalesce" error with the rtl8723bs
> >> driver? I'm looking for advice on whether this is a known bug in recent
> >> kernels or if there's a specific module parameter I should try to bypass
> >> this.
> >>
> >> System Info:
> >>
> >> Chipset: RTL8723BS (SDIO)
> >>
> >> Kernel version: 7.0.3-zen1-2-zen
> >>
> >> update: I fixed the issue after kernel downgrade
> >>
> >> [/quote]
> >
> > That guy should bisect and find the culprit. It will help a lot to understand
> > what's going on.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: axis-fifo: remove driver
From: Denny Lin @ 2026-06-03 13:47 UTC (permalink / raw)
To: linux-staging
Cc: dogestad24, Dan Carpenter, ovidiu.panait.oss, Greg Kroah-Hartman,
jacobsfeder
> I could not find any user-space applications that depend on this driver.
While searching GitHub for userspace applications, I found a couple
of public projects that appear to use /dev/axis_fifo_* devices:
- strijar/brass_gui
- ppoolad/uoft_lidar_test_system
Thanks,
Hungyu Lin
^ permalink raw reply
* Re: [PATCH v8 0/2] staging: rtl8723bs: Fix error handling in _rtw_pktfile_read()
From: Bitterblue Smith @ 2026-06-03 13:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Minu Jin, gregkh, dan.carpenter, abrahamadekunle50,
zxcv2569763104, milospuric856, karanja99erick, weibu,
linux-staging, linux-kernel
In-Reply-To: <ah955alcKpjMXYXy@ashevche-desk.local>
On 03/06/2026 03:48, Andy Shevchenko wrote:
> On Sun, May 24, 2026 at 09:30:01PM +0300, Bitterblue Smith wrote:
>> On 27/01/2026 17:38, Minu Jin wrote:
>>> This series improves error handling in _rtw_pktfile_read() and cleans up
>>> the code style to comply with kernel standards.
>>>
>>> 1. The first patch combines the logic change and caller updates.
>>> The function change and the caller updates must be in the same
>>> patch. If they are separated, the code will not work correctly
>>> or will cause errors at that specific point in the history.
>>>
>>> 2. The second patch focuses purely on code style cleanup (changing uint
>>> to unsigned int) as requested by Andy Shevchenko.
>>>
>>> Regarding the logic change in _rtw_pktfile_read():
>>>
>>> The original code used a ternary operator to read whatever data was
>>> available, even if it was less than requested. This could lead to
>>> callers processing incomplete data without knowing it.
>>>
>>> I have changed this to return -EINVAL when the remaining data is insufficient.
>>> This is safer because most callers expect the exact amount of data and
>>> should not proceed with a partial read.
>>>
>>> Testing and Verification:
>>>
>>> I do not have access to the physical RTL8723BS hardware. However, I have
>>> performed a rigorous manual audit of the data path and verified the
>>> changes using Smatch static analysis. The analysis confirmed that no
>>> new warnings or logical regressions were introduced in the modified files.
>>
>> I have some bad news:
>>
>> https://bbs.archlinux.org/viewtopic.php?id=313401
>
> It's unclear that this patch made it happen. See below.
>
It looks pretty clear to me, but okay. I forwarded your request for bisection.
>> [quote]
>>
>> Hey everyone,
>>
>> I recently upgraded my system, and now I’m having a strange issue with my
>> WiFi (Realtek RTL8723BS).
>>
>> now I can no longer connect to any WiFi networks as a client. however,
>> creating an Access Point (AP) still works fine, but whenever I try to connect
>> to an existing network, the connection fails.
>>
>> dmesg logs:
>> Every time I attempt a connection, dmesg gets spammed with this error:
>>
>> [ 1083.925640] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
>> [ 1084.921217] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
>> [ 1085.921434] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
>> [ 1086.922320] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
>> ....
>>
>> Has anyone encountered this specific "coalesce" error with the rtl8723bs
>> driver? I'm looking for advice on whether this is a known bug in recent
>> kernels or if there's a specific module parameter I should try to bypass
>> this.
>>
>> System Info:
>>
>> Chipset: RTL8723BS (SDIO)
>>
>> Kernel version: 7.0.3-zen1-2-zen
>>
>> update: I fixed the issue after kernel downgrade
>>
>> [/quote]
>
> That guy should bisect and find the culprit. It will help a lot to understand
> what's going on.
>
^ permalink raw reply
* [linux-6.6.y 3/3] HID: core: Fix size_t specifier in hid_report_raw_event()
From: Lee Jones @ 2026-06-03 13:31 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, Sasha Levin,
linux-input, linux-kernel, greybus-dev, linux-staging, bpf
Cc: stable, Nathan Chancellor, Miguel Ojeda, Linus Torvalds
In-Reply-To: <20260603133140.3069226-1-lee@kernel.org>
From: Nathan Chancellor <nathan@kernel.org>
[ Upstream commit 4d3a2a466b8d68d852a1f3bbf11204b718428dc4 ]
When building for 32-bit platforms, for which 'size_t' is
'unsigned int', there are warnings around using the incorrect format
specifier to print bsize in hid_report_raw_event():
drivers/hid/hid-core.c:2054:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ~~~
| %zu
2054 | report->id, csize, bsize);
| ^~~~~
drivers/hid/hid-core.c:2076:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ~~~
| %zu
2076 | report->id, rsize, bsize);
| ^~~~~
Use the proper 'size_t' format specifier, '%zu', to clear up the
warnings.
Cc: stable@vger.kernel.org
Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event")
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/20260516020430.110135-1-ojeda@kernel.org/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 3ab135238832446399614e7a4bb796d620717806)
Signed-off-by: Lee Jones <lee@kernel.org>
(cherry picked from commit 76606eed6cb62ec97afcc270948ef8335d02e944)
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/hid-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c6d98634b97e..2de4d831c526 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2003,7 +2003,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
return 0;
if (unlikely(bsize < csize)) {
- hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
+ hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %zu)\n",
report->id, csize, bsize);
return -EINVAL;
}
@@ -2025,7 +2025,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
rsize = max_buffer_size;
if (bsize < rsize) {
- hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %zu)\n",
report->id, rsize, bsize);
return -EINVAL;
}
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [linux-6.6.y 2/3] HID: pass the buffer size to hid_report_raw_event
From: Lee Jones @ 2026-06-03 13:31 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, Sasha Levin,
linux-input, linux-kernel, greybus-dev, linux-staging, bpf
Cc: stable, Benjamin Tissoires, Jiri Kosina
In-Reply-To: <20260603133140.3069226-1-lee@kernel.org>
From: Benjamin Tissoires <bentiss@kernel.org>
[ Upstream commit 2c85c61d1332e1e16f020d76951baf167dcb6f7a ]
commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
bogus memset()") enforced the provided data to be at least the size of
the declared buffer in the report descriptor to prevent a buffer
overflow. However, we can try to be smarter by providing both the buffer
size and the data size, meaning that hid_report_raw_event() can make
better decision whether we should plaining reject the buffer (buffer
overflow attempt) or if we can safely memset it to 0 and pass it to the
rest of the stack.
Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Acked-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Stable-dep-of: 206342541fc8 ("HID: core: introduce hid_safe_input_report()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 509c2605065004fc4cd86ee50a9350d402785307)
[Lee: Backported to linux-6.12.y and beyond]
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++-
drivers/hid/hid-core.c | 35 +++++++++++++++++++++---------
drivers/hid/hid-gfrm.c | 4 ++--
drivers/hid/hid-logitech-hidpp.c | 2 +-
drivers/hid/hid-multitouch.c | 2 +-
drivers/hid/hid-primax.c | 2 +-
drivers/hid/hid-vivaldi-common.c | 2 +-
drivers/hid/wacom_sys.c | 6 ++---
drivers/staging/greybus/hid.c | 2 +-
include/linux/hid.h | 4 ++--
include/linux/hid_bpf.h | 4 ++--
11 files changed, 41 insertions(+), 25 deletions(-)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index 7903c8638e81..e0c03942ff7c 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -47,7 +47,7 @@ __weak noinline int hid_bpf_device_event(struct hid_bpf_ctx *ctx)
u8 *
dispatch_hid_bpf_device_event(struct hid_device *hdev, enum hid_report_type type, u8 *data,
- u32 *size, int interrupt)
+ size_t *buf_size, u32 *size, int interrupt)
{
struct hid_bpf_ctx_kern ctx_kern = {
.ctx = {
@@ -81,6 +81,7 @@ dispatch_hid_bpf_device_event(struct hid_device *hdev, enum hid_report_type type
*size = ret;
}
+ *buf_size = ctx_kern.ctx.allocated_size;
return ctx_kern.data;
}
EXPORT_SYMBOL_GPL(dispatch_hid_bpf_device_event);
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e3d728d67b53..c6d98634b97e 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1986,24 +1986,32 @@ int __hid_request(struct hid_device *hid, struct hid_report *report,
}
EXPORT_SYMBOL_GPL(__hid_request);
-int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
- int interrupt)
+int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
+ size_t bufsize, u32 size, int interrupt)
{
struct hid_report_enum *report_enum = hid->report_enum + type;
struct hid_report *report;
struct hid_driver *hdrv;
int max_buffer_size = HID_MAX_BUFFER_SIZE;
u32 rsize, csize = size;
+ size_t bsize = bufsize;
u8 *cdata = data;
int ret = 0;
report = hid_get_report(report_enum, data);
if (!report)
- goto out;
+ return 0;
+
+ if (unlikely(bsize < csize)) {
+ hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
+ report->id, csize, bsize);
+ return -EINVAL;
+ }
if (report_enum->numbered) {
cdata++;
csize--;
+ bsize--;
}
rsize = hid_compute_report_size(report);
@@ -2016,9 +2024,15 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
else if (rsize > max_buffer_size)
rsize = max_buffer_size;
+ if (bsize < rsize) {
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
+ report->id, rsize, bsize);
+ return -EINVAL;
+ }
+
if (csize < rsize) {
dbg_hid("report %d is too short, (%d < %d)\n", report->id,
- csize, rsize);
+ csize, rsize);
memset(cdata + csize, 0, rsize - csize);
}
@@ -2027,7 +2041,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
if (hid->claimed & HID_CLAIMED_HIDRAW) {
ret = hidraw_report_event(hid, data, size);
if (ret)
- goto out;
+ return ret;
}
if (hid->claimed != HID_CLAIMED_HIDRAW && report->maxfield) {
@@ -2039,7 +2053,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
if (hid->claimed & HID_CLAIMED_INPUT)
hidinput_report_event(hid, report);
-out:
+
return ret;
}
EXPORT_SYMBOL_GPL(hid_report_raw_event);
@@ -2055,12 +2069,13 @@ EXPORT_SYMBOL_GPL(hid_report_raw_event);
*
* This is data entry for lower layers.
*/
-int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
- int interrupt)
+int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data,
+ u32 size, int interrupt)
{
struct hid_report_enum *report_enum;
struct hid_driver *hdrv;
struct hid_report *report;
+ size_t bufsize = size;
int ret = 0;
if (!hid)
@@ -2076,7 +2091,7 @@ int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data
report_enum = hid->report_enum + type;
hdrv = hid->driver;
- data = dispatch_hid_bpf_device_event(hid, type, data, &size, interrupt);
+ data = dispatch_hid_bpf_device_event(hid, type, data, &bufsize, &size, interrupt);
if (IS_ERR(data)) {
ret = PTR_ERR(data);
goto unlock;
@@ -2105,7 +2120,7 @@ int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data
goto unlock;
}
- ret = hid_report_raw_event(hid, type, data, size, interrupt);
+ ret = hid_report_raw_event(hid, type, data, bufsize, size, interrupt);
unlock:
up(&hid->driver_input_lock);
diff --git a/drivers/hid/hid-gfrm.c b/drivers/hid/hid-gfrm.c
index 699186ff2349..d2a56bf92b41 100644
--- a/drivers/hid/hid-gfrm.c
+++ b/drivers/hid/hid-gfrm.c
@@ -66,7 +66,7 @@ static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
switch (data[1]) {
case GFRM100_SEARCH_KEY_DOWN:
ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, search_key_dn,
- sizeof(search_key_dn), 1);
+ sizeof(search_key_dn), sizeof(search_key_dn), 1);
break;
case GFRM100_SEARCH_KEY_AUDIO_DATA:
@@ -74,7 +74,7 @@ static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
case GFRM100_SEARCH_KEY_UP:
ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, search_key_up,
- sizeof(search_key_up), 1);
+ sizeof(search_key_up), sizeof(search_key_up), 1);
break;
default:
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 339a227c457e..113307157a27 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3692,7 +3692,7 @@ static int hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
memcpy(&consumer_report[1], &data[3], 4);
/* We are called from atomic context */
hid_report_raw_event(hidpp->hid_dev, HID_INPUT_REPORT,
- consumer_report, 5, 1);
+ consumer_report, sizeof(consumer_report), 5, 1);
return 1;
}
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 003950894362..6c04eed0a464 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -479,7 +479,7 @@ static void mt_get_feature(struct hid_device *hdev, struct hid_report *report)
}
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, buf,
- size, 0);
+ size, size, 0);
if (ret)
dev_warn(&hdev->dev, "failed to report feature\n");
}
diff --git a/drivers/hid/hid-primax.c b/drivers/hid/hid-primax.c
index 1e6413d07cae..16e2a811eda9 100644
--- a/drivers/hid/hid-primax.c
+++ b/drivers/hid/hid-primax.c
@@ -44,7 +44,7 @@ static int px_raw_event(struct hid_device *hid, struct hid_report *report,
data[0] |= (1 << (data[idx] - 0xE0));
data[idx] = 0;
}
- hid_report_raw_event(hid, HID_INPUT_REPORT, data, size, 0);
+ hid_report_raw_event(hid, HID_INPUT_REPORT, data, size, size, 0);
return 1;
default: /* unknown report */
diff --git a/drivers/hid/hid-vivaldi-common.c b/drivers/hid/hid-vivaldi-common.c
index b0af2be94895..7fb986615768 100644
--- a/drivers/hid/hid-vivaldi-common.c
+++ b/drivers/hid/hid-vivaldi-common.c
@@ -85,7 +85,7 @@ void vivaldi_feature_mapping(struct hid_device *hdev,
}
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, report_data,
- report_len, 0);
+ report_len, report_len, 0);
if (ret) {
dev_warn(&hdev->dev, "failed to report feature %d\n",
field->report->id);
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 52011503ff3b..52b7f474d866 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -74,7 +74,7 @@ static void wacom_wac_queue_flush(struct hid_device *hdev,
int err;
size = kfifo_out(fifo, buf, sizeof(buf));
- err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, false);
+ err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, size, false);
if (err) {
hid_warn(hdev, "%s: unable to flush event due to error %d\n",
__func__, err);
@@ -319,7 +319,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
data, n, WAC_CMD_RETRIES);
if (ret == n && features->type == HID_GENERIC) {
ret = hid_report_raw_event(hdev,
- HID_FEATURE_REPORT, data, n, 0);
+ HID_FEATURE_REPORT, data, n, n, 0);
} else if (ret == 2 && features->type != HID_GENERIC) {
features->touch_max = data[1];
} else {
@@ -380,7 +380,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
data, n, WAC_CMD_RETRIES);
if (ret == n) {
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT,
- data, n, 0);
+ data, n, n, 0);
} else {
hid_warn(hdev, "%s: could not retrieve sensor offsets\n",
__func__);
diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c
index 15335c38cb26..e761411ccf64 100644
--- a/drivers/staging/greybus/hid.c
+++ b/drivers/staging/greybus/hid.c
@@ -201,7 +201,7 @@ static void gb_hid_init_report(struct gb_hid *ghid, struct hid_report *report)
* we just need to setup the input fields, so using
* hid_report_raw_event is safe.
*/
- hid_report_raw_event(ghid->hid, report->type, ghid->inbuf, size, 1);
+ hid_report_raw_event(ghid->hid, report->type, ghid->inbuf, ghid->bufsize, size, 1);
}
static void gb_hid_init_reports(struct gb_hid *ghid)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index f4bdaf1b8f41..a9857fdfc327 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -1205,8 +1205,8 @@ static inline u32 hid_report_len(struct hid_report *report)
return DIV_ROUND_UP(report->size, 8) + (report->id > 0);
}
-int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
- int interrupt);
+int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
+ size_t bufsize, u32 size, int interrupt);
/* HID quirks API */
unsigned long hid_lookup_quirk(const struct hid_device *hdev);
diff --git a/include/linux/hid_bpf.h b/include/linux/hid_bpf.h
index e9afb61e6ee0..eafaac1109ac 100644
--- a/include/linux/hid_bpf.h
+++ b/include/linux/hid_bpf.h
@@ -147,7 +147,7 @@ struct hid_bpf_link {
#ifdef CONFIG_HID_BPF
u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
- u32 *size, int interrupt);
+ size_t *buf_size, u32 *size, int interrupt);
int hid_bpf_connect_device(struct hid_device *hdev);
void hid_bpf_disconnect_device(struct hid_device *hdev);
void hid_bpf_destroy_device(struct hid_device *hid);
@@ -155,7 +155,7 @@ void hid_bpf_device_init(struct hid_device *hid);
u8 *call_hid_bpf_rdesc_fixup(struct hid_device *hdev, u8 *rdesc, unsigned int *size);
#else /* CONFIG_HID_BPF */
static inline u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type,
- u8 *data, u32 *size, int interrupt) { return data; }
+ u8 *data, size_t *buf_size, u32 *size, int interrupt) { return data; }
static inline int hid_bpf_connect_device(struct hid_device *hdev) { return 0; }
static inline void hid_bpf_disconnect_device(struct hid_device *hdev) {}
static inline void hid_bpf_destroy_device(struct hid_device *hid) {}
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [linux-6.6.y 1/3] HID: core: Add printk_ratelimited variants to hid_warn() etc
From: Lee Jones @ 2026-06-03 13:31 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, Sasha Levin,
linux-input, linux-kernel, greybus-dev, linux-staging, bpf
Cc: stable, Vicki Pfau, Jiri Kosina
From: Vicki Pfau <vi@endrift.com>
hid_warn_ratelimited() is needed. Add the others as part of the block.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
(cherry picked from commit 1d64624243af8329b4b219d8c39e28ea448f9929)
Signed-off-by: Lee Jones <lee@kernel.org>
---
include/linux/hid.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 5d37e2349fae..f4bdaf1b8f41 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -1252,4 +1252,15 @@ int hid_pidff_init_with_quirks(struct hid_device *hid, __u32 initial_quirks);
#define hid_dbg_once(hid, fmt, ...) \
dev_dbg_once(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_err_ratelimited(hid, fmt, ...) \
+ dev_err_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_notice_ratelimited(hid, fmt, ...) \
+ dev_notice_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_warn_ratelimited(hid, fmt, ...) \
+ dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_info_ratelimited(hid, fmt, ...) \
+ dev_info_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_dbg_ratelimited(hid, fmt, ...) \
+ dev_dbg_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+
#endif
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [PATCH] staging: most: video: Use min_t() macro for type safety
From: Vojtěch Krátký @ 2026-06-03 13:19 UTC (permalink / raw)
To: gregkh, christian.gromm
Cc: linux-staging, linux-kernel, Vojtěch Krátký
Replace the open-coded ternary operator matching a minimum calculation
with the standard kernel min_t() macro. Because 'count' is a size_t
and 'rem' is a signed integer, comparing them directly introduces a
signed/unsigned comparison risk. Forcing both to size_t via min_t()
ensures safely typed comparison and fixes a build-time macro assertion.
Signed-off-by: Vojtěch Krátký <vo.kratky@seznam.cz>
---
drivers/staging/most/video/video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/most/video/video.c b/drivers/staging/most/video/video.c
index 04351f8ccccf..709f61ed0322 100644
--- a/drivers/staging/most/video/video.c
+++ b/drivers/staging/most/video/video.c
@@ -178,7 +178,7 @@ static ssize_t comp_vdev_read(struct file *filp, char __user *buf,
while (count > 0 && data_ready(mdev)) {
struct mbo *const mbo = get_top_mbo(mdev);
int const rem = mbo->processed_length - fh->offs;
- int const cnt = rem < count ? rem : count;
+ int const cnt = min_t(size_t, rem, count);
if (copy_to_user(buf, mbo->virt_address + fh->offs, cnt)) {
v4l2_err(&mdev->v4l2_dev, "read: copy_to_user failed\n");
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] staging: axis-fifo: remove driver
From: Michal Simek @ 2026-06-03 13:25 UTC (permalink / raw)
To: Grewstad, Dan Carpenter, lucas.fariamo08
Cc: gregkh, linux-kernel, linux-staging, Ovidiu Panait, Jacob Feder
In-Reply-To: <CAD03fja+rghsG=nY7zEZCO1RuX+ZEst92_U28xLoLv8YQMjf+g@mail.gmail.com>
+Lucas
On 6/3/26 14:25, Grewstad wrote:
> Adding Michal Simek, as he posted some relevant points in another thread.
>
> On Wed, Jun 3, 2026 at 1:49 PM Michal Simek <michal.simek@amd.com> wrote:
>>
>> Hi,
>>
>> On 6/1/26 09:15, Grewstad wrote:
>
>>
>> It is clear that driver in current state can't be used with axi ethernet out of
>> box because pretty much it is just about user interface for fifo via char device
>> fops. But we are talking about the same IP used in specific scenario and this
>> driver doesn't implement integration which can be used in ethernet driver.
>
>> I don't think you will find out any in-tree user because driver purpose is
>> different. It is about providing a user way via char device to push data to axi
>> streaming interface which can be consumed by user logic. It is generic way how
>> to push data there without writing specialized kernel driver for custom HW.
>> I think this is leaf driver which provide a way to axi fifo streaming interface
>
>> where stream is connected to custom HW which consumes it. I can understand that
>> this can be very useful for a lot of people who wants to process data from user
>> space via custom logic with using streaming interface.
>
>> And I don't have any issue to agree to move the driver out of staging to common
>> location.
>
> Thanks for letting me know. When you say common location, can you give your
> opinion on where it can be moved? We cannot find any user-space applications
> that use this driver, as you said it is a 'leaf driver'. Because of
> this, we do not know
> how it is used, who the end users are and hence we dont know where it
> can be moved.
We have drivers/misc/ for this purpose right?
There is attempt to move dt binding to yaml too but I can't see Lucas in this
thread.
https://lore.kernel.org/all/20260227181051.36207-1-lucas.fariamo08@gmail.com/
I was talking to our networking team and they have FIFO support on their plan
with axi ethernet.
Just a summary I am not convinced that this driver is in a state to be removed.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH] staging: fbtft: Use sysfs_emit_at() to print to sysfs file
From: David Laight @ 2026-06-03 12:48 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dan Carpenter, Thomas Petazzoni, Andy Shevchenko,
Greg Kroah-Hartman, Helge Deller, Thomas Zimmermann,
Chintan Patel, dri-devel, linux-fbdev, linux-staging,
linux-kernel, kernel-janitors
In-Reply-To: <ah_cd9Ax4fzOhBp7@ashevche-desk.local>
On Wed, 3 Jun 2026 10:49:11 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Wed, Jun 03, 2026 at 10:34:21AM +0300, Dan Carpenter wrote:
> > This scnprintf() uses the wrong limit. It should be "PAGE_SIZE - len"
> > instead of just PAGE_SIZE. We're not going to hit the limit in real
> > life since we are printing at most FBTFT_GAMMA_MAX_VALUES_TOTAL (128)
> > u32 values, however, it's still worth fixing.
> >
> > Use sysfs_emit_at() to fix this since this is a sysfs file.
>
> OK,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> ...
>
> > for (i = 0; i < par->gamma.num_curves; i++) {
> > for (j = 0; j < par->gamma.num_values; j++)
> > - len += scnprintf(&buf[len], PAGE_SIZE,
> > + len += sysfs_emit_at(buf, len,
> > "%04x ", curves[i * par->gamma.num_values + j]);
>
> Can we switch to use hex_dump_to_buffer() at some point?
>
That gets hard when you really want to aim for something nearer seq_printf().
Oh, the way the loops in the code are written doesn't look like
it gives the compiler much chance of optimising it very well.
This is probably equivalent:
for (i = par->gamma.num_curves; i--;) {
for (j = par->gamma.num_values; j--;)
len += sysfs_emit_at(buf, len, "%04x ", *curves++);
buf[len - 1] = '\n';
}
and will generate much better code.
(Although most of the cost inside the snprintf() function - which is horrid.)
num_values better be non-zero.
-- David
^ permalink raw reply
* [PATCH] staging: rtl8723bs: remove unused network_type_in_use field
From: Cong Nguyen @ 2026-06-03 12:28 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-staging, linux-kernel, Cong Nguyen
The network_type_in_use member of struct wlan_bssid_ex is write-only:
nothing in the driver ever reads it. It is assigned in three places,
none of which feed anything:
- collect_bss_info() hard-codes it to Ndis802_11OFDM24 for every
parsed beacon/probe response, regardless of the network's actual
band or rates (it is even wrong for 5 GHz APs, which the same
function explicitly handles).
- rtw_check_beacon_data() and rtw_update_registrypriv_dev_network()
derive it from the wireless mode via a switch, but the result is
likewise never consumed.
The live PHY classification the driver actually acts on is kept in
wlan_network.network_type (the WIRELESS_11x value), so this NDIS-era
field is redundant.
struct wlan_bssid_ex is an internal structure passed by pointer through
the driver command queue; it is never serialized to firmware or onto
the air (the wire data lives in ies[]), so dropping a member is
layout-safe as long as the module is rebuilt as a whole.
enum ndis_802_11_network_type existed only to type this field, so
remove it as well. No functional change.
Signed-off-by: Cong Nguyen <congnt264@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_ap.c | 15 ---------------
drivers/staging/rtl8723bs/core/rtw_mlme.c | 16 ----------------
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 2 --
drivers/staging/rtl8723bs/include/wlan_bssdef.h | 11 +----------
4 files changed, 1 insertion(+), 43 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 4b4012411011..9a0bc06df6ad 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -1056,21 +1056,6 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 *pbuf, int len)
if (p && ie_len > 0)
pHT_info_ie = p;
- switch (network_type) {
- case WIRELESS_11B:
- pbss_network->network_type_in_use = Ndis802_11DS;
- break;
- case WIRELESS_11G:
- case WIRELESS_11BG:
- case WIRELESS_11G_24N:
- case WIRELESS_11BG_24N:
- pbss_network->network_type_in_use = Ndis802_11OFDM24;
- break;
- default:
- pbss_network->network_type_in_use = Ndis802_11OFDM24;
- break;
- }
-
pmlmepriv->cur_network.network_type = network_type;
pmlmepriv->htpriv.ht_option = false;
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index ddfc56f0253d..587246668a0b 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -2127,22 +2127,6 @@ void rtw_update_registrypriv_dev_network(struct adapter *adapter)
pdev_network->rssi = 0;
- switch (pregistrypriv->wireless_mode) {
- case WIRELESS_11B:
- pdev_network->network_type_in_use = (Ndis802_11DS);
- break;
- case WIRELESS_11G:
- case WIRELESS_11BG:
- case WIRELESS_11_24N:
- case WIRELESS_11G_24N:
- case WIRELESS_11BG_24N:
- pdev_network->network_type_in_use = (Ndis802_11OFDM24);
- break;
- default:
- /* TODO */
- break;
- }
-
pdev_network->configuration.ds_config = (pregistrypriv->channel);
if (cur_network->network.infrastructure_mode == Ndis802_11IBSS)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 5f00fe282d1b..1235d43789c8 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -3971,8 +3971,6 @@ u8 collect_bss_info(struct adapter *padapter, union recv_frame *precv_frame, str
memcpy(bssid->supported_rates + i, (p + 2), len);
}
- bssid->network_type_in_use = Ndis802_11OFDM24;
-
if (bssid->ie_length < 12)
return _FAIL;
diff --git a/drivers/staging/rtl8723bs/include/wlan_bssdef.h b/drivers/staging/rtl8723bs/include/wlan_bssdef.h
index 812a68394268..f2e1c0834ffc 100644
--- a/drivers/staging/rtl8723bs/include/wlan_bssdef.h
+++ b/drivers/staging/rtl8723bs/include/wlan_bssdef.h
@@ -23,14 +23,6 @@ struct ndis_802_11_ssid {
u8 ssid[32];
};
-enum ndis_802_11_network_type {
- Ndis802_11FH,
- Ndis802_11DS,
- Ndis802_11OFDM5,
- Ndis802_11OFDM24,
- Ndis802_11NetworkTypeMax /* not a real type, defined as an upper bound */
-};
-
/*
FW will only save the channel number in DSConfig.
ODI Handler will convert the channel number to freq. number.
@@ -65,7 +57,7 @@ struct ndis_80211_var_ie {
/* Length is the 4 bytes multiples of the sum of
* ETH_ALEN + 2 +
* sizeof (struct ndis_802_11_ssid) + sizeof (u32) +
- * sizeof (long) + sizeof (enum ndis_802_11_network_type) +
+ * sizeof (long) +
* sizeof (struct ndis_802_11_conf) + sizeof (NDIS_802_11_RATES_EX) + ie_length
*
* Except for ie_length, all other fields are fixed length. Therefore, we can
@@ -159,7 +151,6 @@ struct wlan_bssid_ex {
struct ndis_802_11_ssid ssid;
u32 privacy;
long rssi;/* in dBM, raw data , get from PHY) */
- enum ndis_802_11_network_type network_type_in_use;
struct ndis_802_11_conf configuration;
enum ndis_802_11_network_infrastructure infrastructure_mode;
NDIS_802_11_RATES_EX supported_rates;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] staging: axis-fifo: remove driver
From: Grewstad @ 2026-06-03 12:25 UTC (permalink / raw)
To: Dan Carpenter
Cc: gregkh, linux-kernel, linux-staging, Ovidiu Panait, Jacob Feder,
michal.simek
In-Reply-To: <ah7Wn3-meqmDLk_d@stanley.mountain>
Adding Michal Simek, as he posted some relevant points in another thread.
On Wed, Jun 3, 2026 at 1:49 PM Michal Simek <michal.simek@amd.com> wrote:
>
> Hi,
>
> On 6/1/26 09:15, Grewstad wrote:
>
> It is clear that driver in current state can't be used with axi ethernet out of
> box because pretty much it is just about user interface for fifo via char device
> fops. But we are talking about the same IP used in specific scenario and this
> driver doesn't implement integration which can be used in ethernet driver.
> I don't think you will find out any in-tree user because driver purpose is
> different. It is about providing a user way via char device to push data to axi
> streaming interface which can be consumed by user logic. It is generic way how
> to push data there without writing specialized kernel driver for custom HW.
> I think this is leaf driver which provide a way to axi fifo streaming interface
> where stream is connected to custom HW which consumes it. I can understand that
> this can be very useful for a lot of people who wants to process data from user
> space via custom logic with using streaming interface.
> And I don't have any issue to agree to move the driver out of staging to common
> location.
Thanks for letting me know. When you say common location, can you give your
opinion on where it can be moved? We cannot find any user-space applications
that use this driver, as you said it is a 'leaf driver'. Because of
this, we do not know
how it is used, who the end users are and hence we dont know where it
can be moved.
Thanks,
Arihan Bhor
On Tue, Jun 2, 2026 at 6:42 PM Dan Carpenter <error27@gmail.com> wrote:
>
> On Tue, Jun 02, 2026 at 06:31:27PM +0530, Grewstad wrote:
> > On Tue, Jun 2, 2026 at 5:07 PM Dan Carpenter <error27@gmail.com> wrote:
> > >
> > > On Tue, Jun 02, 2026 at 04:01:53PM +0530, Arihan Bhor wrote:
> > >
> > > I don't think we should delete this driver. From reading the git
> > > log, Ovidiu Panait was obviously using this code last year. Let's
> > > also add Jacob Feder, although he hasn't touched the code in 8 years,
> > > he still might know if there are other users.
> >
> > I could not find any user-space applications that depend on this driver.
> >
> > https://lore.kernel.org/lkml/CAD03fjb=_kW9=q9YV4qnQ5GD=HMB5Bx7pf3+AFcgDR2gVc1V6Q@mail.gmail.com/
> > I was looking for any users of this driver on the linux-kernel, linux-staging,
> > and linux-arm-kernel mailing lists as well as Jacob Feder, and received no
> > replies since I posted it 1 day ago. If someone is using it or maintaining a
> > proprietary app, they will complain and we can bring the driver back.
>
> Here are people using it and running into issues in Jan 2025.
> https://adaptivesupport.amd.com/s/question/0D54U00008zRBdISAW/vitis-is-not-creating-a-driver-entry-for-axififomm-43?language=zh_CN
> Someone provides a work around:
> https://adaptivesupport.amd.com/s/question/0D54U00008sLBuMSAW/how-to-use-the-axi-stream-fifo-drivers-xllfifoh-xllfifogc-etc-in-the-project?language=en_US
> Then Ovidiu Panait fixed the bug in Sep by adding the correct
> compatible.
>
> regards,
> dan carpenter
^ permalink raw reply
* Re: [PATCH] staging: media: atomisp: fix typo in rx.c
From: Marlon Trujillo @ 2026-06-03 11:25 UTC (permalink / raw)
To: Andy Shevchenko
Cc: hansg, mchehab, gregkh, sakari.ailus, andy, linux-media,
linux-staging, linux-kernel
In-Reply-To: <CAHp75Vc913Dgo_fzqBGZBaPB03De7V41dwd4uLpw9gvUe-+JDQ@mail.gmail.com>
On Wed, May 27, 2026 at 07:32:30AM +0200, Andy Shevchenko wrote:
> Is this the only one single typo in the whole driver?
No, I took a closer look and found multiple similar typos across
the driver.
>
> But before doing that, invest your time into reading linux-media@
Thanks, that was helpful. I checked the linux-media archives and
noticed others have already been sending similar typo and comment
style fixes as well.
Given that, I can scan for additional typos and fix them together
with their surrounding comment blocks.
Would you prefer a v2 of this patch, or a separate cleanup patch
(or small series) covering these fixes?
Thanks,
Marlon
^ permalink raw reply
* Re: [PATCH v2] staging: iio: addac: fix CamelCase naming in adt7316
From: Jonathan Cameron @ 2026-06-03 11:00 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Jad Keskes, linux-staging, linux-iio
In-Reply-To: <ah_Kbff-c38NWV66@stanley.mountain>
On Wed, 3 Jun 2026 09:32:13 +0300
Dan Carpenter <error27@gmail.com> wrote:
> On Tue, Jun 02, 2026 at 08:03:08PM +0100, Jad Keskes wrote:
> > checkpatch flagged a few CamelCase names in this driver.
> > AIN and DAC prefixes are lowercased as standard kernel style.
>
> The AIN things aren't an issue and checkpatch doesn't complain
> about them.
Also they are userspace ABI. Admittedly this is in staging and that
ABI is completely none compliant with IIO standards, but none the less
you should be very very careful when making that sort of change.
This driver needs a mass of work to drag it into the modern age.
IIRC there have been a few partial attempts at that in the past.
One key part of that is most of what you are touching in this
patch is in code that will not exist after this is modernized.
I'd be surprised if there is low hanging fruit like this that actually
makes sense to do in the remaining staging/iio drivers.
Mostly much more radical surgery is required.
Anyhow, with that all in mind I'm not planning to take this sort
of change to this driver
Jonathan
>
> > Vref is kept capitalized since V stands for Voltage and is a
> > proper technical abbreviation.
> >
> > DA_AB and DA_CD are renamed to dac_ab and dac_cd to match the
> > register constants ADT7316_VREF_BYPASS_DAC_AB and
> > ADT7316_VREF_BYPASS_DAC_CD that they reference.
>
> This sort of change would need to be in its own commit. (We're
> dropping the rest of the commit anyway). The difference
> between DA and DAC is not totally clear to me... The
> adt7316_show_DAC_2Vref_ch_mask() function only seems to deal
> with DA but the adt7316_store_DAC_2Vref_ch_mask() does stuff
> with both. So I'm not sure I understand the naming. (I have
> not investigated and this is my first time to look at this
> code).
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH v2] staging: iio: adc: ad7816: Use devm_gpiod_get_optional() for busy GPIO
From: Dan Carpenter @ 2026-06-03 10:54 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Taha Narimani, jic23, lars, Michael.Hennerich, gregkh, dlechner,
nuno.sa, andy, linux-iio, linux-staging, linux-kernel
In-Reply-To: <aiAD7HRnWmSJb738@ashevche-desk.local>
On Wed, Jun 03, 2026 at 01:37:32PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 03, 2026 at 01:20:08PM +0300, Dan Carpenter wrote:
> > On Wed, Jun 03, 2026 at 12:26:11PM +0300, Andy Shevchenko wrote:
> > > On Wed, Jun 03, 2026 at 12:33:33PM +0000, Taha Narimani wrote:
>
> ...
>
> > > > - if (chip->id == ID_AD7817) {
> > > > + if (chip->busy_pin) {
> > >
> > > If we get GPIO optional, this check wouldn't be necessary anymore as the below
> > > should return 0 IIRC in this case.
> >
> > No, it's still necessary. It can be NULL because of the CONFIG_
> > in which case, sure, gpiod_get_value() is a no-op. But it can
> > also be NULL because of the device tree and in that case we need
> > the check to avoid a NULL pointer dereference.
>
> Can you elaborate on the latter more? I fail to see that.
> What I see is that the function either implemented or not is NULL-aware.
>
Ah, yes. You're right. The VALIDATE_DESC() macro has a return hiding
inside. I hadn't seen that.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2] staging: iio: adc: ad7816: Use devm_gpiod_get_optional() for busy GPIO
From: Jonathan Cameron @ 2026-06-03 10:52 UTC (permalink / raw)
To: Taha Narimani
Cc: lars, Michael.Hennerich, gregkh, dlechner, nuno.sa, andy,
linux-iio, linux-staging, linux-kernel
In-Reply-To: <20260603123333.5608-1-tahanarimani3443@gmail.com>
On Wed, 3 Jun 2026 12:33:33 +0000
Taha Narimani <tahanarimani3443@gmail.com> wrote:
> The driver currently utilizes devm_gpiod_get() for the 'busy' line,
> which makes the GPIO mandatory. However, the busy pin is hardware-optional
> depending on the specific board configuration.
>
> Switch to devm_gpiod_get_optional() to allow boards that do not have
> this pin wired up to still probe the driver successfully, and remove
> the redundant conditional chip-ID check since the optional API handles
> missing descriptors gracefully.
>
> Signed-off-by: Taha Narimani <tahanarimani3443@gmail.com>
I tried to pick this up, but it doesn't apply. I suspect that's because
you've put it on top of your previous patch which modified the checks on chip->id
Please send it as a single patch. Also this is fixing a false assumption in the
driver so it should have an appropriate Fixes tag.
Trivial comment inline.
Thanks,
Jonathan
> ---
> Changes in v2:
> - Fixed trailing whitespace and missing newline at the end of the file.
> - Converted the file format to Unix (LF) to remove carriage returns.
> - Removed the explicit chip-ID check around the busy pin logic.
> - Improved the commit message to provide clear architectural justification.
>
> drivers/staging/iio/adc/ad7816.c | 19 +++++++++----------
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
> index 0eac484..039b34d 100644
> --- a/drivers/staging/iio/adc/ad7816.c
> +++ b/drivers/staging/iio/adc/ad7816.c
> @@ -84,7 +84,7 @@ static int ad7816_spi_read(struct ad7816_chip_info *chip, u16 *data)
> gpiod_set_value(chip->convert_pin, 1);
> }
>
> - if (chip->id == ID_AD7817) {
> + if (chip->busy_pin) {
> while (gpiod_get_value(chip->busy_pin))
> cpu_relax();
> }
> @@ -380,15 +380,14 @@ static int ad7816_probe(struct spi_device *spi_dev)
> ret);
> return ret;
> }
> - if (chip->id == ID_AD7817) {
> - chip->busy_pin = devm_gpiod_get(&spi_dev->dev, "busy",
> - GPIOD_IN);
> - if (IS_ERR(chip->busy_pin)) {
> - ret = PTR_ERR(chip->busy_pin);
> - dev_err(&spi_dev->dev, "Failed to request busy GPIO: %d\n",
> - ret);
> - return ret;
> - }
> +
> + chip->busy_pin = devm_gpiod_get_optional(&spi_dev->dev, "busy",
> + GPIOD_IN);
Trivial: We are more relaxed on line lengths these days so for cases like this
where it would only go a little past 80 chars to have it on one line I would
generally prefer it that way.
> + if (IS_ERR(chip->busy_pin)) {
> + ret = PTR_ERR(chip->busy_pin);
> + dev_err(&spi_dev->dev, "Failed to request busy GPIO: %d\n",
> + ret);
> + return ret;
> }
>
> indio_dev->name = spi_get_device_id(spi_dev)->name;
^ permalink raw reply
* Re: [PATCH v2] staging: iio: adc: ad7816: Use devm_gpiod_get_optional() for busy GPIO
From: Andy Shevchenko @ 2026-06-03 10:37 UTC (permalink / raw)
To: Dan Carpenter
Cc: Taha Narimani, jic23, lars, Michael.Hennerich, gregkh, dlechner,
nuno.sa, andy, linux-iio, linux-staging, linux-kernel
In-Reply-To: <ah__2Fjf0MxIQLnh@stanley.mountain>
On Wed, Jun 03, 2026 at 01:20:08PM +0300, Dan Carpenter wrote:
> On Wed, Jun 03, 2026 at 12:26:11PM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 03, 2026 at 12:33:33PM +0000, Taha Narimani wrote:
...
> > > - if (chip->id == ID_AD7817) {
> > > + if (chip->busy_pin) {
> >
> > If we get GPIO optional, this check wouldn't be necessary anymore as the below
> > should return 0 IIRC in this case.
>
> No, it's still necessary. It can be NULL because of the CONFIG_
> in which case, sure, gpiod_get_value() is a no-op. But it can
> also be NULL because of the device tree and in that case we need
> the check to avoid a NULL pointer dereference.
Can you elaborate on the latter more? I fail to see that.
What I see is that the function either implemented or not is NULL-aware.
> > > while (gpiod_get_value(chip->busy_pin))
> > > cpu_relax();
> > > }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] staging: iio: adc: ad7816: Use devm_gpiod_get_optional() for busy GPIO
From: Dan Carpenter @ 2026-06-03 10:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Taha Narimani, jic23, lars, Michael.Hennerich, gregkh, dlechner,
nuno.sa, andy, linux-iio, linux-staging, linux-kernel
In-Reply-To: <ah_zMybQBDHakXpX@ashevche-desk.local>
On Wed, Jun 03, 2026 at 12:26:11PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 03, 2026 at 12:33:33PM +0000, Taha Narimani wrote:
> > The driver currently utilizes devm_gpiod_get() for the 'busy' line,
> > which makes the GPIO mandatory. However, the busy pin is hardware-optional
> > depending on the specific board configuration.
> >
> > Switch to devm_gpiod_get_optional() to allow boards that do not have
> > this pin wired up to still probe the driver successfully, and remove
> > the redundant conditional chip-ID check since the optional API handles
> > missing descriptors gracefully.
>
> ...
>
> > - if (chip->id == ID_AD7817) {
> > + if (chip->busy_pin) {
>
> If we get GPIO optional, this check wouldn't be necessary anymore as the below
> should return 0 IIRC in this case.
>
No, it's still necessary. It can be NULL because of the CONFIG_
in which case, sure, gpiod_get_value() is a no-op. But it can
also be NULL because of the device tree and in that case we need
the check to avoid a NULL pointer dereference.
> > while (gpiod_get_value(chip->busy_pin))
> > cpu_relax();
> > }
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v3] staging: rtl8723bs: remove unnecessary parentheses
From: Dan Carpenter @ 2026-06-03 10:18 UTC (permalink / raw)
To: Eugene Mavick
Cc: gregkh, khomenkov, ethantidmore06, m.steinmoetzger, tomasz.unger,
arthur.stupa, jannik, linux-staging, linux-kernel
In-Reply-To: <DIZB2839PXFV.3A5L73XAO2X67@mavick.dev>
On Wed, Jun 03, 2026 at 05:26:46PM +0800, Eugene Mavick wrote:
> My previous reply can be disregarded, I realise a few of the parantheses
> removals are still present in the v3. I will correct those and send a
> v4.
Heh. Yes. And also the commit message says there are some.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2] staging: iio: adc: ad7816: Use devm_gpiod_get_optional() for busy GPIO
From: Andy Shevchenko @ 2026-06-03 9:27 UTC (permalink / raw)
To: Joshua Crofts
Cc: Taha Narimani, jic23, lars, Michael.Hennerich, gregkh, dlechner,
nuno.sa, andy, linux-iio, linux-staging, linux-kernel
In-Reply-To: <CALoEA-zvki0Gvzug6bueyf6p5011_rP94uEijrUKaJTGneo_cA@mail.gmail.com>
On Wed, Jun 03, 2026 at 11:13:17AM +0200, Joshua Crofts wrote:
> On Wed, 3 Jun 2026 at 11:07, Taha Narimani <tahanarimani3443@gmail.com> wrote:
...
> > + chip->busy_pin = devm_gpiod_get_optional(&spi_dev->dev, "busy",
> > + GPIOD_IN);
> > + if (IS_ERR(chip->busy_pin)) {
> > + ret = PTR_ERR(chip->busy_pin);
> > + dev_err(&spi_dev->dev, "Failed to request busy GPIO: %d\n",
> > + ret);
>
> Looking at this, you could eventually move all of the dev_err() calls in the
> probe() function to use dev_err_probe(). (For another patch though).
No, it must be in this patch, otherwise it might regress quite badly (from
the user, who wants to see a bootlog nice and clean, perspective).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] staging: iio: adc: ad7816: Use devm_gpiod_get_optional() for busy GPIO
From: Andy Shevchenko @ 2026-06-03 9:26 UTC (permalink / raw)
To: Taha Narimani
Cc: jic23, lars, Michael.Hennerich, gregkh, dlechner, nuno.sa, andy,
linux-iio, linux-staging, linux-kernel
In-Reply-To: <20260603123333.5608-1-tahanarimani3443@gmail.com>
On Wed, Jun 03, 2026 at 12:33:33PM +0000, Taha Narimani wrote:
> The driver currently utilizes devm_gpiod_get() for the 'busy' line,
> which makes the GPIO mandatory. However, the busy pin is hardware-optional
> depending on the specific board configuration.
>
> Switch to devm_gpiod_get_optional() to allow boards that do not have
> this pin wired up to still probe the driver successfully, and remove
> the redundant conditional chip-ID check since the optional API handles
> missing descriptors gracefully.
...
> - if (chip->id == ID_AD7817) {
> + if (chip->busy_pin) {
If we get GPIO optional, this check wouldn't be necessary anymore as the below
should return 0 IIRC in this case.
> while (gpiod_get_value(chip->busy_pin))
> cpu_relax();
> }
> + chip->busy_pin = devm_gpiod_get_optional(&spi_dev->dev, "busy",
> + GPIOD_IN);
Make it a single line. Perhaps with a help of
struct device *dev = &spi_dev->dev;
added to the top of the function.
> + if (IS_ERR(chip->busy_pin)) {
> + ret = PTR_ERR(chip->busy_pin);
> + dev_err(&spi_dev->dev, "Failed to request busy GPIO: %d\n",
> + ret);
> + return ret;
You can't do that, it will spam bootlog very quickly if this GPIO is deferred
and never appears. The proper way is to
return dev_err_probe(dev, PTR_ERR(chip->busy_pin), "...");
> }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] staging: rtl8723bs: simplify NULL pointer checks in rtw_recv.h
From: Jeeva Anandh @ 2026-06-03 9:14 UTC (permalink / raw)
To: gregkh; +Cc: linux-staging, linux-kernel, Jeeva Anandh
Replace explicit NULL pointer comparisons with idiomatic
pointer checks to improve readability and follow kernel style.
Signed-off-by: Jeeva Anandh <anandhjeeva215@gmail.com>
---
drivers/staging/rtl8723bs/include/rtw_recv.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/rtw_recv.h b/drivers/staging/rtl8723bs/include/rtw_recv.h
index 8e45871f07f0..9c32d480a20a 100644
--- a/drivers/staging/rtl8723bs/include/rtw_recv.h
+++ b/drivers/staging/rtl8723bs/include/rtw_recv.h
@@ -349,7 +349,7 @@ s32 rtw_recv_entry(union recv_frame *precv_frame);
static inline u8 *get_rxmem(union recv_frame *precvframe)
{
/* always return rx_head... */
- if (precvframe == NULL)
+ if (!precvframe)
return NULL;
return precvframe->u.hdr.rx_head;
@@ -362,7 +362,7 @@ static inline u8 *recvframe_pull(union recv_frame *precvframe, signed int sz)
/* used for extract sz bytes from rx_data, update rx_data and return the updated rx_data to the caller */
- if (precvframe == NULL)
+ if (!precvframe)
return NULL;
@@ -387,7 +387,7 @@ static inline u8 *recvframe_put(union recv_frame *precvframe, signed int sz)
/* after putting, rx_tail must be still larger than rx_end. */
unsigned char *prev_rx_tail;
- if (precvframe == NULL)
+ if (!precvframe)
return NULL;
prev_rx_tail = precvframe->u.hdr.rx_tail;
@@ -414,7 +414,7 @@ static inline u8 *recvframe_pull_tail(union recv_frame *precvframe, signed int s
/* used for extract sz bytes from rx_end, update rx_end and return the updated rx_end to the caller */
/* after pulling, rx_end must be still larger than rx_data. */
- if (precvframe == NULL)
+ if (!precvframe)
return NULL;
precvframe->u.hdr.rx_tail -= sz;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] staging: iio: adc: ad7816: Use devm_gpiod_get_optional() for busy GPIO
From: Joshua Crofts @ 2026-06-03 9:13 UTC (permalink / raw)
To: Taha Narimani
Cc: jic23, lars, Michael.Hennerich, gregkh, dlechner, nuno.sa, andy,
linux-iio, linux-staging, linux-kernel
In-Reply-To: <20260603123333.5608-1-tahanarimani3443@gmail.com>
On Wed, 3 Jun 2026 at 11:07, Taha Narimani <tahanarimani3443@gmail.com> wrote:
> ---
> + chip->busy_pin = devm_gpiod_get_optional(&spi_dev->dev, "busy",
> + GPIOD_IN);
> + if (IS_ERR(chip->busy_pin)) {
> + ret = PTR_ERR(chip->busy_pin);
> + dev_err(&spi_dev->dev, "Failed to request busy GPIO: %d\n",
> + ret);
Looking at this, you could eventually move all of the dev_err() calls in the
probe() function to use dev_err_probe(). (For another patch though).
--
Kind regards
CJD
^ permalink raw reply
* [PATCH v2] staging: iio: adc: ad7816: Use devm_gpiod_get_optional() for busy GPIO
From: Taha Narimani @ 2026-06-03 12:33 UTC (permalink / raw)
To: jic23, lars, Michael.Hennerich, gregkh
Cc: dlechner, nuno.sa, andy, linux-iio, linux-staging, linux-kernel,
Taha Narimani
The driver currently utilizes devm_gpiod_get() for the 'busy' line,
which makes the GPIO mandatory. However, the busy pin is hardware-optional
depending on the specific board configuration.
Switch to devm_gpiod_get_optional() to allow boards that do not have
this pin wired up to still probe the driver successfully, and remove
the redundant conditional chip-ID check since the optional API handles
missing descriptors gracefully.
Signed-off-by: Taha Narimani <tahanarimani3443@gmail.com>
---
Changes in v2:
- Fixed trailing whitespace and missing newline at the end of the file.
- Converted the file format to Unix (LF) to remove carriage returns.
- Removed the explicit chip-ID check around the busy pin logic.
- Improved the commit message to provide clear architectural justification.
drivers/staging/iio/adc/ad7816.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index 0eac484..039b34d 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -84,7 +84,7 @@ static int ad7816_spi_read(struct ad7816_chip_info *chip, u16 *data)
gpiod_set_value(chip->convert_pin, 1);
}
- if (chip->id == ID_AD7817) {
+ if (chip->busy_pin) {
while (gpiod_get_value(chip->busy_pin))
cpu_relax();
}
@@ -380,15 +380,14 @@ static int ad7816_probe(struct spi_device *spi_dev)
ret);
return ret;
}
- if (chip->id == ID_AD7817) {
- chip->busy_pin = devm_gpiod_get(&spi_dev->dev, "busy",
- GPIOD_IN);
- if (IS_ERR(chip->busy_pin)) {
- ret = PTR_ERR(chip->busy_pin);
- dev_err(&spi_dev->dev, "Failed to request busy GPIO: %d\n",
- ret);
- return ret;
- }
+
+ chip->busy_pin = devm_gpiod_get_optional(&spi_dev->dev, "busy",
+ GPIOD_IN);
+ if (IS_ERR(chip->busy_pin)) {
+ ret = PTR_ERR(chip->busy_pin);
+ dev_err(&spi_dev->dev, "Failed to request busy GPIO: %d\n",
+ ret);
+ return ret;
}
indio_dev->name = spi_get_device_id(spi_dev)->name;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3] staging: rtl8723bs: remove unnecessary parentheses
From: Dan Carpenter @ 2026-06-03 8:44 UTC (permalink / raw)
To: Eugene Mavick
Cc: gregkh, khomenkov, ethantidmore06, m.steinmoetzger, tomasz.unger,
arthur.stupa, jannik, linux-staging, linux-kernel
In-Reply-To: <20260603080105.780648-1-m@mavick.dev>
On Wed, Jun 03, 2026 at 04:01:05PM +0800, Eugene Mavick wrote:
> Remove unnecessary parentheses to clear checkpatch.pl warnings
>
> Example of fixed warnings:
> CHECK: Unnecessary parentheses around dvobj->cam_cache[id]
> CHECK: Unnecessary parentheses around 'val != 0xfe'
No, leave these. It's a staging specific rule. I even modified
checkpatch to not warn about these so I'm not sure how you are seeing
them. I just tested again and checkpatch doesn't warn...
regards,
dan carpenter
^ permalink raw reply
* Re: [RFC] drivers/staging/axis-fifo: Looking for users
From: Michal Simek @ 2026-06-03 8:18 UTC (permalink / raw)
To: Grewstad, Greg KH
Cc: radhey.shyam.pandey, Andrew Lunn, jic23, linux-staging,
linux-arm-kernel, linux-kernel, jacobsfeder, Katakam, Harini
In-Reply-To: <CAD03fjb=_kW9=q9YV4qnQ5GD=HMB5Bx7pf3+AFcgDR2gVc1V6Q@mail.gmail.com>
Hi,
On 6/1/26 09:15, Grewstad wrote:
> Hi,
> The AXI Stream FIFO driver has been in staging since 2018. I was trying to
> understand whether there are real in-tree users of this hardware today, and
> what the expected direction for graduating the driver out of staging might be.
>
> The only in tree reference to this driver that i found is
> drivers/ethernet/xilinx/xilinx_axienet_main.c, which states:
>
> * TODO:
> * - Add Axi Fifo support.
>
> From this, it appears AXI Stream FIFO support may be used for some AXI
> Ethernet hardware configurations. However, I’m not sure whether there are
> any other in-tree users of the AXI Stream FIFO IP besides Ethernet, or
> whether Ethernet is the primary intended consumer.
It is clear that driver in current state can't be used with axi ethernet out of
box because pretty much it is just about user interface for fifo via char device
fops. But we are talking about the same IP used in specific scenario and this
driver doesn't implement integration which can be used in ethernet driver.
>
> If there are no other in-tree users, it’s unclear whether this driver should
> remain a standalone staging driver or be integrated into a specific subsystem
> like networking.
I don't think you will find out any in-tree user because driver purpose is
different. It is about providing a user way via char device to push data to axi
streaming interface which can be consumed by user logic. It is generic way how
to push data there without writing specialized kernel driver for custom HW.
> Can you let me know if there are any known in-tree users for this driver,
> whether it has a large enough user base to justify its existence in
> the kernel tree,
> and what the hardware's real use cases are?
I think this is leaf driver which provide a way to axi fifo streaming interface
where stream is connected to custom HW which consumes it. I can understand that
this can be very useful for a lot of people who wants to process data from user
space via custom logic with using streaming interface.
And I don't have any issue to agree to move the driver out of staging to common
location.
Thanks,
Michal
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox