* Re: [PATCH v2 4/7] i2c: of-prober: Defer regulator_disable() on successful probe in simple helper
From: sashiko-bot @ 2026-07-03 12:08 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: dmitry.torokhov, devicetree, linux-input, conor+dt, robh
In-Reply-To: <20260703115601.1323491-5-wenst@chromium.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The prober unconditionally sleeps for 100ms during the cleanup path even when no matching I2C component is found, unnecessarily delaying system boot.
--
commit 772a8f5b00b1078ef6740a0746df36699760f2f2
Author: Chen-Yu Tsai <wenst@chromium.org>
i2c: of-prober: Defer regulator_disable() on successful probe in simple helper
This patch defers regulator disabling in the I2C OF component prober by adding
a 100ms delay. The delay allows asynchronously probing drivers to catch and
increase the regulator enable count, avoiding hardware re-initialization.
> diff --git a/drivers/i2c/i2c-core-of-prober.c b/drivers/i2c/i2c-core-of-prober.c
> index f274e260353cd..17495125467ed 100644
> --- a/drivers/i2c/i2c-core-of-prober.c
> +++ b/drivers/i2c/i2c-core-of-prober.c
> @@ -243,11 +243,23 @@ static int i2c_of_probe_simple_enable_regulator(struct device *dev, struct i2c_o
> return 0;
> }
>
> -static void i2c_of_probe_simple_disable_regulator(struct device *dev, struct i2c_of_probe_simple_ctx *ctx)
> +static void i2c_of_probe_simple_disable_regulator(struct device *dev,
> + struct i2c_of_probe_simple_ctx *ctx,
> + bool defer_disable)
> {
> if (!ctx->supply)
> return;
>
> + /*
> + * Wait a bit of time for async drivers to probe and increase the
> + * regulator enable count. This allows the drivers to check and
> + * skip waiting for re-initialization.
> + */
> + if (defer_disable) {
> + dev_dbg(dev, "Deferring regulator disable\n");
> + msleep(100);
> + }
> +
[ ... ]
> @@ -409,7 +421,7 @@ void i2c_of_probe_simple_cleanup(struct device *dev, void *data)
> i2c_of_probe_simple_disable_gpio(dev, ctx);
> i2c_of_probe_simple_put_gpiod(ctx);
>
> - i2c_of_probe_simple_disable_regulator(dev, ctx);
> + i2c_of_probe_simple_disable_regulator(dev, ctx, true);
[Severity: Medium]
Does this unconditionally sleep for 100ms even when no matching I2C component
is found?
If i2c_of_probe_component() iterates over potential components but finds none,
it calls ops->cleanup(dev, ctx), which invokes i2c_of_probe_simple_cleanup().
Because defer_disable is hardcoded to true here,
i2c_of_probe_simple_disable_regulator() will execute the 100ms sleep.
Could this result in an unnecessary 100ms boot delay on systems missing the
probed component, since no async driver will ever probe in this failure path?
> i2c_of_probe_simple_put_supply(ctx);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703115601.1323491-1-wenst@chromium.org?part=4
^ permalink raw reply
* Re: [PATCH v2 5/7] platform/chrome: of_hw_prober: Add delay for hana trackpads
From: sashiko-bot @ 2026-07-03 12:10 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: devicetree, linux-input, conor+dt, dmitry.torokhov, robh
In-Reply-To: <20260703115601.1323491-6-wenst@chromium.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The result of regulator_is_enabled() is assigned to or bitwise-ANDed with a boolean variable, causing negative error codes to incorrectly evaluate to true and skip required hardware initialization delays.
--
commit 1aa1abec8abc658e89bd1583fb36c5b23bda7cf8
Author: Chen-Yu Tsai <wenst@chromium.org>
platform/chrome: of_hw_prober: Add delay for hana trackpads
Up until now, the MT8173 elm/hana device tree has set the dedicated
regulator supplying the trackpad as always-on, simply because the Elan
driver was missing proper delays. As a result the delay for the
Synaptics trackpad was also omitted, as it was not strictly required
under such a model and delayed the availability of the trackpad to the
user.
> The Elan driver recently gained proper delays after power-up, with
> adaptive skipping of the delay if the regulator was originally
> on. The I2C HID driver and I2C OF component prober library gained
> similar adaptive delay skipping. The device tree will be fixed to have
> the regulator not be always on, and proper post-power-on delay time
> added to the I2C HID device.
[Severity: High]
Does the adaptive skipping logic mentioned here safely handle negative error
codes from regulator_is_enabled()?
Looking at the implementations of this adaptive skipping,
regulator_is_enabled() can return a negative error code (e.g., -EIO, -EBUSY)
on failure, but this result is being directly assigned to or bitwise-ANDed
with a boolean.
For example, in drivers/hid/i2c-hid/i2c-hid-of.c:i2c_hid_of_power_up():
for (unsigned int i = 0; i < ARRAY_SIZE(ihid_of->supplies); i++)
supply_was_enabled &= regulator_is_enabled(ihid_of->supplies[i].consumer);
Since supply_was_enabled is promoted to int for the bitwise AND, does this
outcome depend on the parity of the error code? It looks like odd errors
(like -EIO) will yield true (skipping the delay), while even errors (like
-EBUSY) will yield false.
Similarly, in drivers/i2c/i2c-core-of-prober.c:
i2c_of_probe_simple_enable_regulator():
supply_was_on = regulator_is_enabled(ctx->supply);
And in drivers/input/mouse/elan_i2c_core.c:elan_probe() and elan_resume():
supply_was_enabled = regulator_is_enabled(data->vcc);
Since any non-zero integer evaluates to true in C, assigning a negative error
code directly to a bool means all errors will incorrectly signal that the
regulator was already on.
Could this cause a regression where a transient I2C or hardware error when
querying the regulator state makes the driver incorrectly skip required
hardware initialization delays and fail the device probe?
> Also add the post-power-on delay to the ChromeOS OF component prober,
> so that if the regulator is off at the time of probing, the prober knows
> to wait for the hardware to initialize.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703115601.1323491-1-wenst@chromium.org?part=5
^ permalink raw reply
* Re: [PATCH v2 2/6] iio: hid-sensors: align function parenthesis for readability
From: Andy Shevchenko @ 2026-07-03 12:52 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Sanjay Chitroda via B4 Relay, sanjayembeddedse, David Lechner,
Nuno Sá, Andy Shevchenko, Jiri Kosina, Srinivas Pandruvada,
linux-iio, linux-kernel, linux-input
In-Reply-To: <20260702182015.303db93c@jic23-huawei>
On Thu, Jul 02, 2026 at 06:20:15PM +0100, Jonathan Cameron wrote:
> On Thu, 02 Jul 2026 21:47:59 +0530
> Sanjay Chitroda via B4 Relay <devnull+sanjayembeddedse.gmail.com@kernel.org> wrote:
>
> > Adjust alignment of parentheses across HID sensor IIO drivers to
> > improve readability and maintain consistency with kernel coding style.
> >
> > While updating the formatting, group related arguments consistently in
> > multi-line function signatures where appropriate.
> >
> > No functional change intended.
>
> Whilst I appreciate this code isn't quite in line with standards
> and usually like that stuff to be fixed up, in this particular case
> this is a massive amount of churn. That churn will make backporting
> fixes etc messier, so I'd like input on whether others consider this
> one worthwhile. Jiri, Srinivas, Andy etc. What do you think?
I am fine as long as Srinivas is. I understand pros and cons of this, but from
time to time we have patches à la this one that messes up with backporting but
were accepted as a good part of some bigger series.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] HID: logitech-hidpp: add HID++ 2.0 reprogrammable button support
From: Bastien Nocera @ 2026-07-03 12:53 UTC (permalink / raw)
To: Elliot Douglas; +Cc: linux-input, lains, jikos, bentiss, linux-kernel
In-Reply-To: <CAGt6S1pqCNPeV-Hy6w-8eynKhKwzz5X4fefkJfM0gYGgQzGAwA@mail.gmail.com>
On Wed, 2026-07-01 at 15:32 -0700, Elliot Douglas wrote:
> Just wanted to poke on this thread again, Benjamin or Bastien, what
> is needed to
> push this forward or should I send the v2 at this point?
You're definitely better off sending a new version when there's no
feedback incoming, it acts as a gentle reminder and avoids another back
and forth if there's no further comments (apart from the ones in the
original review).
>
> Thanks,
> Elliot
>
> On Wed, Jun 17, 2026 at 6:16 PM Elliot Douglas
> <edouglas7358@gmail.com> wrote:
> >
> > Thanks, that makes sense.
> >
> > For Solaar, this is not continuously forced. The kernel only
> > programs
> > temporary diversion when the device connects. Solaar can still
> > issue HID++
> > commands through hidraw, so if Solaar changes reporting for the
> > same controls
> > afterwards, the last writer wins.
> >
> > If Solaar takes over those controls for custom actions, the kernel
> > would stop
> > receiving the diverted button notifications for normal evdev
> > reporting until
> > the kernel diverts the controls again, for example after reconnect.
> > While the
> > controls remain diverted, hidraw clients should still receive the
> > raw HID++
> > reports.
> >
> > I have addressed the inline comments locally for v2:
> > - replaced the profile/count wrapper with NULL-terminated mapping
> > arrays
> > - cached the selected mapping pointer in struct hidpp_device
> >
> > I'll wait for Benjamin's input to send Patch v2.
> >
> >
> > On Wed, Jun 17, 2026 at 3:28 AM Bastien Nocera <hadess@hadess.net>
> > wrote:
> > >
> > > On Sat, 2026-06-13 at 10:51 -0700, Elliot Douglas wrote:
> > > > Some Logitech HID++ 2.0 mice can report diverted reprogrammable
> > > > controls through HID++ feature 0x1b04, SpecialKeysMseButtons /
> > > > REPROG_CONTROLS_V4, instead of the normal HID mouse report.
> > > >
> > > > Add a quirk-gated event path for those controls. The handler
> > > > temporarily
> > > > diverts verified per-product controls, parses
> > > > divertedButtonsEvent as the
> > > > current pressed-control list, and reports the corresponding
> > > > evdev key state
> > > > for every mapped control.
> > > >
> > > > Keep the control mappings in per-product profiles so adding
> > > > support for
> > > > another mouse does not change the evdev capabilities advertised
> > > > by
> > > > already-supported devices.
> > >
> > > How does this forced setting work/clash with the programmable
> > > buttons
> > > in Solaar?
> > >
> > > I've added some inline comments below.
> > >
> > > >
> > > > Documentation for feature 0x1b04 describes divertedButtonsEvent
> > > > as a list
> > > > of currently pressed diverted buttons, which is the event
> > > > format handled
> > > > here.
> > > >
> > > > Link:
> > > > https://lekensteyn.nl/files/logitech/x1b04_specialkeysmsebuttons.html
> > > >
> > > > Signed-off-by: Elliot Douglas <edouglas7358@gmail.com>
> > > > ---
> > > > drivers/hid/hid-logitech-hidpp.c | 215
> > > > +++++++++++++++++++++++++++++++
> > > > 1 file changed, 215 insertions(+)
> > > >
> > > > diff --git a/drivers/hid/hid-logitech-hidpp.c
> > > > b/drivers/hid/hid-logitech-hidpp.c
> > > > index 70ba1a5e40d8..24c9cfaa4f37 100644
> > > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > > @@ -76,6 +76,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
> > > > #define HIDPP_QUIRK_HI_RES_SCROLL_1P0 BIT(28)
> > > > #define HIDPP_QUIRK_WIRELESS_STATUS BIT(29)
> > > > #define HIDPP_QUIRK_RESET_HI_RES_SCROLL BIT(30)
> > > > +#define HIDPP_QUIRK_HIDPP_REPROG_CONTROLS_BTNS BIT(31)
> > > >
> > > > /* These are just aliases for now */
> > > > #define HIDPP_QUIRK_KBD_SCROLL_WHEEL HIDPP_QUIRK_HIDPP_WHEELS
> > > > @@ -205,6 +206,7 @@ struct hidpp_device {
> > > > struct hidpp_scroll_counter vertical_wheel_counter;
> > > >
> > > > u8 wireless_feature_index;
> > > > + u8 reprog_controls_feature_index;
> > > >
> > > > int hires_wheel_multiplier;
> > > > u8 hires_wheel_feature_index;
> > > > @@ -3601,6 +3603,209 @@ static int
> > > > hidpp10_extra_mouse_buttons_raw_event(struct hidpp_device
> > > > *hidpp,
> > > > return 1;
> > > > }
> > > >
> > > > +/* -----------------------------------------------------------
> > > > --------------- */
> > > > +/* HID++2.0 reprogrammable
> > > > controls */
> > > > +/* -----------------------------------------------------------
> > > > --------------- */
> > > > +
> > > > +#define HIDPP_PAGE_REPROG_CONTROLS_V4
> > > > 0x1b04
> > > > +
> > > > +#define HIDPP_REPROG_CONTROLS_GET_COUNT
> > > > 0x00
> > > > +#define HIDPP_REPROG_CONTROLS_GET_CID_INFO 0x10
> > > > +#define HIDPP_REPROG_CONTROLS_SET_CONTROL_REPORTING 0x30
> > > > +
> > > > +#define HIDPP_REPROG_CONTROLS_FLAG_MOUSE BIT(0)
> > > > +#define HIDPP_REPROG_CONTROLS_FLAG_DIVERT BIT(5)
> > > > +
> > > > +#define HIDPP_REPROG_CONTROLS_TEMPORARY_DIVERTED BIT(0)
> > > > +#define HIDPP_REPROG_CONTROLS_CHANGE_TEMPORARY_DIVERT
> > > > BIT(1)
> > > > +
> > > > +#define HIDPP_REPROG_CONTROLS_EVENT_DIVERTED 0x00
> > > > +
> > > > +struct hidpp_reprog_control_mapping {
> > > > + u16 control;
> > > > + u16 code;
> > > > +};
> > > > +
> > > > +struct hidpp_reprog_controls_profile {
> > > > + const struct hidpp_reprog_control_mapping *mappings;
> > >
> > > probably needs a __counted_by(), or maybe as it's static, it
> > > might be
> > > better to not require an intermediate struct, and return a NULL-
> > > terminated array instead.
> > >
> > > > + unsigned int mapping_count;
> > > > +};
> > > > +
> > > > +static const struct hidpp_reprog_controls_profile *
> > > > +hidpp20_reprog_controls_get_profile(struct hidpp_device
> > > > *hidpp)
> > > > +{
> > > > + return NULL;
> > > > +}
> > > > +
> > > > +static int hidpp20_reprog_controls_get_count(struct
> > > > hidpp_device *hidpp)
> > > > +{
> > > > + struct hidpp_report response;
> > > > + u8 feature_index = hidpp->reprog_controls_feature_index;
> > > > + u8 cmd = HIDPP_REPROG_CONTROLS_GET_COUNT;
> > > > + int ret;
> > > > +
> > > > + ret = hidpp_send_fap_command_sync(hidpp, feature_index,
> > > > cmd, NULL, 0,
> > > > + &response);
> > > > + if (ret > 0)
> > > > + return -EPROTO;
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + return response.fap.params[0];
> > > > +}
> > > > +
> > > > +static int hidpp20_reprog_controls_get_cid_info(struct
> > > > hidpp_device *hidpp,
> > > > + u8 index, u16
> > > > *control,
> > > > + u8 *flags)
> > > > +{
> > > > + struct hidpp_report response;
> > > > + u8 feature_index = hidpp->reprog_controls_feature_index;
> > > > + u8 cmd = HIDPP_REPROG_CONTROLS_GET_CID_INFO;
> > > > + int ret;
> > > > +
> > > > + ret = hidpp_send_fap_command_sync(hidpp, feature_index,
> > > > cmd, &index,
> > > > + sizeof(index),
> > > > &response);
> > > > + if (ret > 0)
> > > > + return -EPROTO;
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + *control = get_unaligned_be16(&response.fap.params[0]);
> > > > + *flags = response.fap.params[4];
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static bool hidpp20_reprog_controls_find_control(struct
> > > > hidpp_device *hidpp,
> > > > + u16 control)
> > > > +{
> > > > + int count, ret;
> > > > + u16 cid;
> > > > + u8 flags;
> > > > + int i;
> > > > +
> > > > + count = hidpp20_reprog_controls_get_count(hidpp);
> > > > + if (count < 0)
> > > > + return false;
> > > > +
> > > > + for (i = 0; i < count; i++) {
> > > > + ret = hidpp20_reprog_controls_get_cid_info(hidpp,
> > > > i, &cid,
> > > > +
> > > > &flags);
> > > > + if (ret)
> > > > + return false;
> > > > +
> > > > + if (cid == control)
> > > > + return (flags &
> > > > HIDPP_REPROG_CONTROLS_FLAG_MOUSE) &&
> > > > + (flags &
> > > > HIDPP_REPROG_CONTROLS_FLAG_DIVERT);
> > > > + }
> > > > +
> > > > + return false;
> > > > +}
> > > > +
> > > > +static int
> > > > hidpp20_reprog_controls_set_control_reporting(struct
> > > > hidpp_device *hidpp,
> > > > + u16
> > > > control, u8 flags)
> > > > +{
> > > > + struct hidpp_report response;
> > > > + u8 params[5];
> > > > +
> > > > + put_unaligned_be16(control, ¶ms[0]);
> > > > + params[2] = flags;
> > > > + put_unaligned_be16(control, ¶ms[3]);
> > > > +
> > > > + return hidpp_send_fap_command_sync(hidpp,
> > > > + hidpp-
> > > > >reprog_controls_feature_index,
> > > > +
> > > > HIDPP_REPROG_CONTROLS_SET_CONTROL_REPORTING,
> > > > + params,
> > > > sizeof(params), &response);
> > > > +}
> > > > +
> > > > +static void hidpp20_reprog_controls_connect(struct
> > > > hidpp_device *hidpp)
> > > > +{
> > > > + const struct hidpp_reprog_controls_profile *profile;
> > > > + u8 flags = HIDPP_REPROG_CONTROLS_TEMPORARY_DIVERTED |
> > > > + HIDPP_REPROG_CONTROLS_CHANGE_TEMPORARY_DIVERT;
> > > > + unsigned int i;
> > > > +
> > > > + if (!(hidpp->quirks &
> > > > HIDPP_QUIRK_HIDPP_REPROG_CONTROLS_BTNS))
> > > > + return;
> > > > +
> > > > + profile = hidpp20_reprog_controls_get_profile(hidpp);
> > >
> > > Could the profile be cached in the hidpp_device struct?
> > >
> > > > + if (!profile)
> > > > + return;
> > > > +
> > > > + if (hidpp_root_get_feature(hidpp,
> > > > HIDPP_PAGE_REPROG_CONTROLS_V4,
> > > > + &hidpp-
> > > > >reprog_controls_feature_index))
> > > > + return;
> > > > +
> > > > + for (i = 0; i < profile->mapping_count; i++) {
> > > > + u16 control = profile->mappings[i].control;
> > > > +
> > > > + if (!hidpp20_reprog_controls_find_control(hidpp,
> > > > control))
> > > > + continue;
> > > > +
> > > > +
> > > > hidpp20_reprog_controls_set_control_reporting(hidpp, control,
> > > > flags);
> > > > + }
> > > > +}
> > > > +
> > > > +static int hidpp20_reprog_controls_raw_event(struct
> > > > hidpp_device *hidpp,
> > > > + u8 *data, int size)
> > > > +{
> > > > + const struct hidpp_reprog_controls_profile *profile;
> > > > + const struct hidpp_reprog_control_mapping *mapping;
> > > > + struct hidpp_report *report = (struct hidpp_report
> > > > *)data;
> > > > + u16 controls[4];
> > > > + bool pressed;
> > > > + unsigned int i, j;
> > > > +
> > > > + if (!(hidpp->quirks &
> > > > HIDPP_QUIRK_HIDPP_REPROG_CONTROLS_BTNS) ||
> > > > + !hidpp->input ||
> > > > + hidpp->reprog_controls_feature_index == 0xff)
> > > > + return 0;
> > > > +
> > > > + profile = hidpp20_reprog_controls_get_profile(hidpp);
> > > > + if (!profile)
> > > > + return 0;
> > > > +
> > > > + if (size < HIDPP_REPORT_LONG_LENGTH ||
> > > > + report->fap.feature_index != hidpp-
> > > > >reprog_controls_feature_index ||
> > > > + report->fap.funcindex_clientid !=
> > > > HIDPP_REPROG_CONTROLS_EVENT_DIVERTED)
> > > > + return 0;
> > > > +
> > > > + for (i = 0; i < ARRAY_SIZE(controls); i++)
> > > > + controls[i] = get_unaligned_be16(&report-
> > > > >fap.params[i * 2]);
> > > > +
> > > > + for (i = 0; i < profile->mapping_count; i++) {
> > > > + mapping = &profile->mappings[i];
> > > > + pressed = false;
> > > > +
> > > > + for (j = 0; j < ARRAY_SIZE(controls); j++) {
> > > > + if (controls[j] == mapping->control) {
> > > > + pressed = true;
> > > > + break;
> > > > + }
> > > > + }
> > > > +
> > > > + input_report_key(hidpp->input, mapping->code,
> > > > pressed);
> > > > + }
> > > > +
> > > > + input_sync(hidpp->input);
> > > > +
> > > > + return 1;
> > > > +}
> > > > +
> > > > +static void hidpp20_reprog_controls_populate_input(struct
> > > > hidpp_device *hidpp,
> > > > + struct
> > > > input_dev *input_dev)
> > > > +{
> > > > + const struct hidpp_reprog_controls_profile *profile;
> > > > + unsigned int i;
> > > > +
> > > > + profile = hidpp20_reprog_controls_get_profile(hidpp);
> > > > + if (!profile)
> > > > + return;
> > > > +
> > > > + for (i = 0; i < profile->mapping_count; i++)
> > > > + input_set_capability(input_dev, EV_KEY, profile-
> > > > >mappings[i].code);
> > > > +}
> > > > +
> > > > static void hidpp10_extra_mouse_buttons_populate_input(
> > > > struct hidpp_device *hidpp, struct
> > > > input_dev *input_dev)
> > > > {
> > > > @@ -3859,6 +4064,9 @@ static void hidpp_populate_input(struct
> > > > hidpp_device *hidpp,
> > > >
> > > > if (hidpp->quirks & HIDPP_QUIRK_HIDPP_EXTRA_MOUSE_BTNS)
> > > > hidpp10_extra_mouse_buttons_populate_input(hidpp,
> > > > input);
> > > > +
> > > > + if (hidpp->quirks &
> > > > HIDPP_QUIRK_HIDPP_REPROG_CONTROLS_BTNS)
> > > > + hidpp20_reprog_controls_populate_input(hidpp,
> > > > input);
> > > > }
> > > >
> > > > static int hidpp_input_configured(struct hid_device *hdev,
> > > > @@ -3971,6 +4179,10 @@ static int hidpp_raw_hidpp_event(struct
> > > > hidpp_device *hidpp, u8 *data,
> > > > return ret;
> > > > }
> > > >
> > > > + ret = hidpp20_reprog_controls_raw_event(hidpp, data,
> > > > size);
> > > > + if (ret != 0)
> > > > + return ret;
> > > > +
> > > > if (hidpp->quirks &
> > > > HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS) {
> > > > ret = hidpp10_consumer_keys_raw_event(hidpp,
> > > > data, size);
> > > > if (ret != 0)
> > > > @@ -4264,6 +4476,8 @@ static void hidpp_connect_event(struct
> > > > work_struct *work)
> > > > return;
> > > > }
> > > >
> > > > + hidpp20_reprog_controls_connect(hidpp);
> > > > +
> > > > if (hidpp->quirks &
> > > > HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS) {
> > > > ret = hidpp10_consumer_keys_connect(hidpp);
> > > > if (ret)
> > > > @@ -4436,6 +4650,7 @@ static int hidpp_probe(struct hid_device
> > > > *hdev, const struct hid_device_id *id)
> > > > hidpp->hid_dev = hdev;
> > > > hidpp->name = hdev->name;
> > > > hidpp->quirks = id->driver_data;
> > > > + hidpp->reprog_controls_feature_index = 0xff;
> > > > hid_set_drvdata(hdev, hidpp);
> > > >
> > > > ret = hid_parse(hdev);
^ permalink raw reply
* Re: [PATCH v4 0/5] Add OneXPlayer Configuration HID Driver
From: Günther Noack @ 2026-07-03 14:25 UTC (permalink / raw)
To: Derek J. Clark
Cc: Jiri Kosina, Benjamin Tissoires, Pierre-Loup A . Griffais,
Lee Jones, Lambert Fan, Zhouwang Huang, linux-input, linux-doc,
linux-kernel
In-Reply-To: <20260419042624.625746-1-derekjohn.clark@gmail.com>
Hello Derek!
On Sat, Apr 18, 2026 at 09:26:19PM -0700, Derek J. Clark wrote:
> Adds an HID driver for OneXPlayer HID configuration devices. There are
> currently 2 generations of OneXPlayer HID protocol. The first (OneXPlayer
> F1 series) only provides an RGB control interface over HID. The Second
> (X1 mini series, G1 series, AOKZOE A1X) also includes a hardware level
> button mapping interface, vibration intensity settings, and the ability
> to switch output between xinput and a debug mode that can be used to debug
> the button mapping. Some devices (G1 Series, APEX) use a hybrid of Gen1
> RGB control and Gen 2 controller settings. To ensure there is no conflicts
> when the driver is loaded, we skip creating the RGB interface for Gen 2
> devices if there is a DMI match.
>
> I'll also add a note that Gen 1 devices also have an interface for
> setting the key map and debug mode, but that is done entirely over a
> serial TTY device so it is not able to be added to this driver. There
> are also some "Gen 0" devices (OneXPlayer 2 Series) also use it, but
> the TTY interface also handles the RGB control so no support is
> provided by this driver for those interfaces.
>
> Signed-off-by: Derel J. Clark <derekjohn.clark@gmail.com>
Sorry I am late to this review, but here are two issues I discovered
when looking at the code:
(1) The functions oxp_hid_raw_event_gen_1() and
oxp_hid_raw_event_gen_2() are both forgetting to do bounds checks
against the "size" argument.
For real devices, which send a real report descriptor, these buffers
will be large enough, but a device that sends a faked report
descriptor can provoke an out-of-bounds-read here by underspecifying
the size for these reports.
(2) oxp_hid_probe() and other functions are populating drvdata, and
drvdata is a static variable. If you plug in two of these devices
at the same time, they will step on each other's toes, and this
leads to all kinds of memory corruption problems when they do.
I believe the right way to go about this is to allocate a separate
piece of memory for each device that you are plugging in. Other
device drivers do this uing devm_kzalloc().
Disclaimer:
I found these through code inspection and curiosity but have not tried
to reproduce the crashes.
Per Linux's official threat model[1], these are not considered security
vulnerabilities. An attacker who impersonates a USB device and gains
illegitimate access to the USB port might be able to provoke these bugs
though, and I wouldn't be surprised if (2) also just leads to system
crashes when using two of these devices at the same time.
—Günther
[1] https://docs.kernel.org/process/threat-model.html
^ permalink raw reply
* [PATCH] Add a quirk for a Cirque I2C device.
From: Vadim Klishko @ 2026-07-03 14:47 UTC (permalink / raw)
To: jikos; +Cc: linux-input, linux-kernel, Vadim Klishko
Cirque touchpads with PID D0C1 generate an error when probed
by the I2C HID driver, resulting in no hidraw device created.
Signed-off-by: Vadim Klishko <vadim@cirque.com>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/i2c-hid/i2c-hid-core.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 1059922baaac..496589277bd5 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -334,6 +334,7 @@
#define I2C_VENDOR_ID_CIRQUE 0x0488
#define I2C_PRODUCT_ID_CIRQUE_1063 0x1063
+#define I2C_PRODUCT_ID_CIRQUE_D0C1 0xD0C1
#define USB_VENDOR_ID_CJTOUCH 0x24b8
#define USB_DEVICE_ID_CJTOUCH_MULTI_TOUCH_0020 0x0020
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 3adb16366e93..63004bcbfa71 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -136,6 +136,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_BAD_INPUT_SIZE },
{ I2C_VENDOR_ID_CIRQUE, I2C_PRODUCT_ID_CIRQUE_1063,
I2C_HID_QUIRK_NO_SLEEP_ON_SUSPEND },
+ { I2C_VENDOR_ID_CIRQUE, I2C_PRODUCT_ID_CIRQUE_D0C1,
+ I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
/*
* Without additional power on command, at least some QTEC devices send garbage
*/
--
2.34.1
^ permalink raw reply related
* [PATCH 0/3] hid: fix missing hid_is_usb() checks in three drivers
From: Jann Horn @ 2026-07-03 15:16 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
This fixes missing hid_is_usb() checks before to_usb_interface() in
three HID drivers.
I've split it into three patches so that they can have separate "Fixes"
tags, hopefully they are easier to stable-backport this way.
Signed-off-by: Jann Horn <jannh@google.com>
---
Jann Horn (3):
HID: asus: fix missing hid_is_usb() check
HID: huawei: fix missing hid_is_usb() check
HID: rapoo: fix missing hid_is_usb() check
drivers/hid/hid-asus.c | 2 +-
drivers/hid/hid-huawei.c | 5 +++--
drivers/hid/hid-rapoo.c | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
---
base-commit: 51512e22efe813d8223de27f6fd02a8a48ea2323
change-id: 20260703-hid-usbcheck-9163e6cf6015
Best regards,
--
Jann Horn <jannh@google.com>
^ permalink raw reply
* [PATCH 1/3] HID: asus: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:16 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v1-0-e80259ff625d@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: 00e005c952f7 ("hid-asus: check ROG Ally MCU version and warn")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-asus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 3f5e96900b67..befa990b3210 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
return ret;
}
- if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
+ if ((drvdata->quirks & QUIRK_ROG_ALLY_XPAD) && hid_is_usb(hdev)) {
intf = to_usb_interface(hdev->dev.parent);
udev = interface_to_usbdev(intf);
validate_mcu_fw_version(hdev,
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 2/3] HID: huawei: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:16 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v1-0-e80259ff625d@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: e93faaca84b7 ("HID: huawei: fix CD30 keyboard report descriptor issue")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-huawei.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-huawei.c b/drivers/hid/hid-huawei.c
index 6a616bf21b38..ee3fc6f68475 100644
--- a/drivers/hid/hid-huawei.c
+++ b/drivers/hid/hid-huawei.c
@@ -44,11 +44,12 @@ static const __u8 huawei_cd30_kbd_rdesc_fixed[] = {
static const __u8 *huawei_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
+ struct usb_interface *intf = hid_is_usb(hdev) ?
+ to_usb_interface(hdev->dev.parent) : NULL;
switch (hdev->product) {
case USB_DEVICE_ID_HUAWEI_CD30KBD:
- if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {
+ if (!intf || intf->cur_altsetting->desc.bInterfaceNumber == 1) {
if (*rsize != sizeof(huawei_cd30_kbd_rdesc_fixed) ||
memcmp(huawei_cd30_kbd_rdesc_fixed, rdesc,
sizeof(huawei_cd30_kbd_rdesc_fixed)) != 0) {
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 3/3] HID: rapoo: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:16 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v1-0-e80259ff625d@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: 00e005c952f7 ("hid-asus: check ROG Ally MCU version and warn")Fixes: b3b1c68fb726 ("HID: rapoo: Add support for side buttons on RAPOO 0x2015 mouse")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-rapoo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
index 4c81f3086de4..5c9c396fabf7 100644
--- a/drivers/hid/hid-rapoo.c
+++ b/drivers/hid/hid-rapoo.c
@@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
- if (hdev->bus == BUS_USB) {
+ if (hid_is_usb(hdev)) {
struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
if (intf->cur_altsetting->desc.bInterfaceNumber != 1)
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH] HID: asus: fix UAF of ->kbd_backlight on !CONFIG_ASUS_WMI
From: Jann Horn @ 2026-07-03 15:27 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Carlo Caione, linux-input, linux-kernel, stable, Jann Horn
On kernels without !CONFIG_ASUS_WMI, asus_hid_register_listener() will
fail. asus_kbd_register_leds() reacts to this by freeing
drvdata->kbd_backlight, but doesn't NULL out the pointer, causing UAF when
asus_remove() follows this pointer.
I have tested that this bug causes an ASAN splat, and that this change
fixes the issue.
Cc: stable@vger.kernel.org
Fixes: af22a610bc38 ("HID: asus: support backlight on USB keyboards")
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-asus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 3f5e96900b67..c2a5edebbd7a 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -777,6 +777,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
if (ret < 0) {
/* No need to have this still around */
devm_kfree(&hdev->dev, drvdata->kbd_backlight);
+ drvdata->kbd_backlight = NULL;
}
return ret;
---
base-commit: 51512e22efe813d8223de27f6fd02a8a48ea2323
change-id: 20260703-hid-asus-uaf-0b8e1325fc00
Best regards,
--
Jann Horn <jannh@google.com>
^ permalink raw reply related
* Re: [PATCH 3/3] HID: rapoo: fix missing hid_is_usb() check
From: sashiko-bot @ 2026-07-03 15:29 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-usbcheck-v1-3-e80259ff625d@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Missing Kconfig dependency `depends on USB_HID` for `CONFIG_HID_RAPOO` causes a linker error.
- [Low] Malformed `Fixes:` tags in the commit message.
--
commit ac5c5d7fc93db76e1ff4b587da9d47600a05ff83
Author: Jann Horn <jannh@google.com>
HID: rapoo: fix missing hid_is_usb() check
This commit fixes a potential splat by verifying a HID device is actually on
a USB bus before casting its parent to a usb_interface.
> I have verified that it is currently possible to trigger a kernel splat due
> to this bug in an ASAN build, and that this commit fixes the issue.
>
> Fixes: 00e005c952f7 ("hid-asus: check ROG Ally MCU version and warn")Fixes: b3b1c68fb726 ("HID: rapoo: Add support for side buttons on RAPOO 0x2015 mouse")
[Severity: Low]
This isn't a bug, but there are two Fixes tags concatenated on the same line.
Could this break automated patch parsing tools and stable backporting scripts
that expect each tag to be on a separate line?
> Cc: stable@vger.kernel.org
> Signed-off-by: Jann Horn <jannh@google.com>
>
> diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
> index 4c81f3086de43..5c9c396fabf77 100644
> --- a/drivers/hid/hid-rapoo.c
> +++ b/drivers/hid/hid-rapoo.c
[ ... ]
> @@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
> return ret;
> }
>
> - if (hdev->bus == BUS_USB) {
> + if (hid_is_usb(hdev)) {
[Severity: Low]
Does the introduction of hid_is_usb() in rapoo_probe() require an update to
the CONFIG_HID_RAPOO entry in drivers/hid/Kconfig?
Because hid_is_usb() is defined and exported exclusively by the usbhid module,
if a user configures the kernel with CONFIG_HID_RAPOO=y and CONFIG_USB_HID=n
(or m), will this cause a build failure during the linking stage due to an
undefined reference?
Should CONFIG_HID_RAPOO now explicitly depend on USB_HID?
> struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
>
> if (intf->cur_altsetting->desc.bInterfaceNumber != 1)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-usbcheck-v1-0-e80259ff625d@google.com?part=3
^ permalink raw reply
* Re: [PATCH 1/3] HID: asus: fix missing hid_is_usb() check
From: sashiko-bot @ 2026-07-03 15:32 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-usbcheck-v1-1-e80259ff625d@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing pointer invalidation after `devm_kfree` causes a deterministic Use-After-Free on the failure path.
--
commit d3bce769a13470fb7e8717746a98294d5eb006c9
Author: Jann Horn <jannh@google.com>
HID: asus: fix missing hid_is_usb() check
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent. Fix the use of to_usb_interface() without a
hid_is_usb() check.
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 3f5e96900b67a..befa990b3210e 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> return ret;
> }
>
> - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> + if ((drvdata->quirks & QUIRK_ROG_ALLY_XPAD) && hid_is_usb(hdev)) {
> intf = to_usb_interface(hdev->dev.parent);
> udev = interface_to_usbdev(intf);
> validate_mcu_fw_version(hdev,
[Severity: High]
This is a pre-existing issue, but does the failure path in this function leave
a dangling pointer that can cause a use-after-free?
If asus_hid_register_listener() fails later in asus_kbd_register_leds():
ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
if (ret < 0) {
/* No need to have this still around */
devm_kfree(&hdev->dev, drvdata->kbd_backlight);
}
The memory allocated for drvdata->kbd_backlight is freed, but the pointer is
not set to NULL.
Then asus_probe() catches the failure, emits a warning, but improperly allows
probe to succeed:
if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
(asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID)) &&
(asus_kbd_register_leds(hdev)))
hid_warn(hdev, "Failed to initialize backlight.\n");
If this occurs, could a subsequent call to asus_remove() or asus_resume()
dereference the freed memory?
if (drvdata->kbd_backlight) {
asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
drvdata->kbd_backlight->removed = true;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-usbcheck-v1-0-e80259ff625d@google.com?part=1
^ permalink raw reply
* Re: [PATCH] HID: asus: fix UAF of ->kbd_backlight on !CONFIG_ASUS_WMI
From: sashiko-bot @ 2026-07-03 15:42 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-asus-uaf-v1-1-1a2af2534eb0@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Race condition in asus_remove() due to incorrect teardown order for fn_lock_sync_work, leading to Use-After-Free.
--
commit 10088228c9fb50f752e52778b8014fc75f17200d
Author: Jann Horn <jannh@google.com>
HID: asus: fix UAF of ->kbd_backlight on !CONFIG_ASUS_WMI
This commit fixes a Use-After-Free bug where drvdata->kbd_backlight was not
set to NULL after being freed in asus_kbd_register_leds(). By explicitly
clearing the pointer when asus_hid_register_listener() fails, it prevents
asus_remove() from following a freed pointer during teardown.
Cc: stable@vger.kernel.org
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 3f5e96900b67a..c2a5edebbd7a7 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -777,6 +777,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> if (ret < 0) {
> /* No need to have this still around */
> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
> + drvdata->kbd_backlight = NULL;
> }
>
> return ret;
[Severity: High]
This is a pre-existing issue, but I noticed a potential race condition in
asus_remove() that might lead to a Use-After-Free.
When a device is removed, asus_remove() calls cancel_work_sync() for
fn_lock_sync_work before stopping the hardware:
drivers/hid/hid-asus.c:asus_remove() {
...
if (drvdata->quirks & QUIRK_HID_FN_LOCK)
cancel_work_sync(&drvdata->fn_lock_sync_work);
hid_hw_stop(hdev);
}
If a KEY_FN_ESC event arrives in the window between these two calls, won't
the HID core invoke asus_event() and blindly requeue the work?
drivers/hid/hid-asus.c:asus_event() {
...
case KEY_FN_ESC:
if (drvdata->quirks & QUIRK_HID_FN_LOCK) {
drvdata->fn_lock = !drvdata->fn_lock;
schedule_work(&drvdata->fn_lock_sync_work);
}
break;
...
}
Since the driver data is freed after device removal, could this executed
work access freed memory if the teardown order isn't reversed so that
hid_hw_stop() runs before cancel_work_sync()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-asus-uaf-v1-1-1a2af2534eb0@google.com?part=1
^ permalink raw reply
* [PATCH v2 0/3] hid: fix missing hid_is_usb() checks in three drivers
From: Jann Horn @ 2026-07-03 15:45 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
This fixes missing hid_is_usb() checks before to_usb_interface() in
three HID drivers.
I've split it into three patches so that they can have separate "Fixes"
tags, hopefully they are easier to stable-backport this way.
Signed-off-by: Jann Horn <jannh@google.com>
---
Changes in v2:
- patch 3/3: fix typo in "Fixes" line
- patch 3/3: add USB_HID dependency (alternative would be to implement a
stub for hid_is_usb())
- Link to v1: https://patch.msgid.link/20260703-hid-usbcheck-v1-0-e80259ff625d@google.com
---
Jann Horn (3):
HID: asus: fix missing hid_is_usb() check
HID: huawei: fix missing hid_is_usb() check
HID: rapoo: fix missing hid_is_usb() check
drivers/hid/Kconfig | 1 +
drivers/hid/hid-asus.c | 2 +-
drivers/hid/hid-huawei.c | 5 +++--
drivers/hid/hid-rapoo.c | 2 +-
4 files changed, 6 insertions(+), 4 deletions(-)
---
base-commit: 51512e22efe813d8223de27f6fd02a8a48ea2323
change-id: 20260703-hid-usbcheck-9163e6cf6015
Best regards,
--
Jann Horn <jannh@google.com>
^ permalink raw reply
* [PATCH v2 1/3] HID: asus: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:45 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: 00e005c952f7 ("hid-asus: check ROG Ally MCU version and warn")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-asus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 3f5e96900b67..befa990b3210 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
return ret;
}
- if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
+ if ((drvdata->quirks & QUIRK_ROG_ALLY_XPAD) && hid_is_usb(hdev)) {
intf = to_usb_interface(hdev->dev.parent);
udev = interface_to_usbdev(intf);
validate_mcu_fw_version(hdev,
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH v2 2/3] HID: huawei: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:45 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: e93faaca84b7 ("HID: huawei: fix CD30 keyboard report descriptor issue")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-huawei.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-huawei.c b/drivers/hid/hid-huawei.c
index 6a616bf21b38..ee3fc6f68475 100644
--- a/drivers/hid/hid-huawei.c
+++ b/drivers/hid/hid-huawei.c
@@ -44,11 +44,12 @@ static const __u8 huawei_cd30_kbd_rdesc_fixed[] = {
static const __u8 *huawei_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
+ struct usb_interface *intf = hid_is_usb(hdev) ?
+ to_usb_interface(hdev->dev.parent) : NULL;
switch (hdev->product) {
case USB_DEVICE_ID_HUAWEI_CD30KBD:
- if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {
+ if (!intf || intf->cur_altsetting->desc.bInterfaceNumber == 1) {
if (*rsize != sizeof(huawei_cd30_kbd_rdesc_fixed) ||
memcmp(huawei_cd30_kbd_rdesc_fixed, rdesc,
sizeof(huawei_cd30_kbd_rdesc_fixed)) != 0) {
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH v2 3/3] HID: rapoo: fix missing hid_is_usb() check
From: Jann Horn @ 2026-07-03 15:45 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Ilpo Järvinen, Mario Limonciello, Luke D. Jones, Miao Li,
linux-input, linux-kernel, Jann Horn, stable
In-Reply-To: <20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com>
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
Add a dependency on USB_HID for hid_is_usb(), as other HID drivers do; the
alternative would be to provide a simple stub implementation on !USB_HID
builds.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
Fixes: b3b1c68fb726 ("HID: rapoo: Add support for side buttons on RAPOO 0x2015 mouse")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/Kconfig | 1 +
drivers/hid/hid-rapoo.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index f9bcaeb66385..48934c4f3c45 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1048,6 +1048,7 @@ config HID_PXRC
config HID_RAPOO
tristate "Rapoo non-fully HID-compliant devices"
+ depends on USB_HID
help
Support for Rapoo devices that are not fully compliant with the
HID standard.
diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
index 4c81f3086de4..5c9c396fabf7 100644
--- a/drivers/hid/hid-rapoo.c
+++ b/drivers/hid/hid-rapoo.c
@@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
- if (hdev->bus == BUS_USB) {
+ if (hid_is_usb(hdev)) {
struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
if (intf->cur_altsetting->desc.bInterfaceNumber != 1)
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* Re: [PATCH v2 1/3] HID: asus: fix missing hid_is_usb() check
From: sashiko-bot @ 2026-07-03 15:58 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-usbcheck-v2-1-c5ed7bc94772@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Dangling pointer in `drvdata->kbd_backlight` leading to Use-After-Free when WMI listener registration fails.
--
commit 0bcf68d0cd670d6cc4fac38b7be14d0855140731
Author: Jann Horn <jannh@google.com>
HID: asus: fix missing hid_is_usb() check
This commit fixes a kernel splat caused by uhid devices that identify as
being on BUS_USB without actually having a USB parent. It adds a missing
hid_is_usb() check before calling to_usb_interface().
Cc: stable@vger.kernel.org
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 3f5e96900b67a..befa990b3210e 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> return ret;
> }
>
> - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> + if ((drvdata->quirks & QUIRK_ROG_ALLY_XPAD) && hid_is_usb(hdev)) {
> intf = to_usb_interface(hdev->dev.parent);
> udev = interface_to_usbdev(intf);
> validate_mcu_fw_version(hdev,
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential
use-after-free later in this same function.
When asus_hid_register_listener() fails, the code frees the backlight
structure but leaves the pointer dangling:
drivers/hid/hid-asus.c:asus_kbd_register_leds() {
...
ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
if (ret < 0) {
/* No need to have this still around */
devm_kfree(&hdev->dev, drvdata->kbd_backlight);
}
return ret;
}
Since asus_probe() logs a warning but continues successfully when this
fails, could this cause a use-after-free during device removal or
suspend?
It looks like asus_remove() checks if the pointer is non-null before
dereferencing it:
drivers/hid/hid-asus.c:asus_remove() {
...
if (drvdata->kbd_backlight) {
asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
...
}
Should drvdata->kbd_backlight be set to NULL after being freed to prevent
this?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com?part=1
^ permalink raw reply
* Re: [PATCH v2 3/3] HID: rapoo: fix missing hid_is_usb() check
From: sashiko-bot @ 2026-07-03 16:02 UTC (permalink / raw)
To: Jann Horn; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260703-hid-usbcheck-v2-3-c5ed7bc94772@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing hid_hw_stop() cleanup on error paths in rapoo_probe() causes hardware resource leaks and a Use-After-Free.
--
commit ed7992bab1a88e74142aa29aa65b4061257a86cb
Author: Jann Horn <jannh@google.com>
HID: rapoo: fix missing hid_is_usb() check
This commit adds a hid_is_usb() check before calling to_usb_interface() to
handle uhid devices reporting BUS_USB without an actual USB parent. It also
adds a USB_HID dependency for hid_is_usb().
[ ... ]
> diff --git a/drivers/hid/hid-rapoo.c b/drivers/hid/hid-rapoo.c
> index 4c81f3086de43..5c9c396fabf77 100644
> --- a/drivers/hid/hid-rapoo.c
> +++ b/drivers/hid/hid-rapoo.c
> @@ -36,7 +36,7 @@ static int rapoo_probe(struct hid_device *hdev, const struct hid_device_id *id)
> return ret;
> }
>
> - if (hdev->bus == BUS_USB) {
> + if (hid_is_usb(hdev)) {
> struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
>
> if (intf->cur_altsetting->desc.bInterfaceNumber != 1)
[Severity: High]
This is a pre-existing issue, but are we missing hid_hw_stop() calls on the
error paths later in rapoo_probe()?
If devm_input_allocate_device() fails, the code returns -ENOMEM directly:
input = devm_input_allocate_device(&hdev->dev);
if (!input)
return -ENOMEM;
Similarly, if input_register_device() fails, it returns the error:
ret = input_register_device(input);
if (ret)
return ret;
When returning these errors after hid_hw_start() has succeeded, the HID core
probe fails and sets hdev->driver to NULL, but hid_hw_stop() is never called
to stop the hardware and kill active URBs.
When the device is later unplugged, usbhid_disconnect() frees the usbhid
structure, but skips hid_hw_stop() because hdev->driver is NULL.
Because active USB URBs are not killed, when the USB core later flushes the
endpoints and cancels the URBs, the completion handler hid_irq_in() attempts
to clear state bits in the already-freed usbhid structure, like calling
clear_bit(HID_IN_RUNNING, &usbhid->iofl).
This results in a use-after-free write memory corruption. While this requires
local physical access to the USB port and specific conditions like memory
pressure to induce a probe failure, it guarantees memory corruption when
triggered.
Would it be better to add an error label that calls hid_hw_stop() when the
input device allocation or registration fails?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-hid-usbcheck-v2-0-c5ed7bc94772@google.com?part=3
^ permalink raw reply
* [PATCH] HID: core: fix number/pointer type confusion on long items
From: Jann Horn @ 2026-07-03 18:30 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Henrik Rydberg, linux-input, linux-kernel, stable, Jann Horn
When fetch_item() is called by hid_scan_report() on an item with
HID_ITEM_TAG_LONG, it stores a pointer to the item data in
item->data.longdata instead of storing a value directly in
item->data.{u8/u16/u32}.
When item_udata() or item_sdata() encounters such an item, it incorrectly
assumes that the item is in short format, and therefore returns the lower
part of a kernel pointer reinterpreted as a number.
When a HID device is connected whose descriptor contains a
HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this
causes the lower half of a kernel pointer to be printed into dmesg as a
number, like this:
hid (null): invalid report_size 107953555
To fix it, let item_udata() and item_sdata() verify that the item is in
short format.
Note that this bug only affects hid_scan_report(), while the main parsing
pass hid_parse_collections() will always bail out when encountering a long
item.
Sidenote: There are currently no users of data.longdata; maybe we should
just remove any parsing of long-format descriptors as a follow-up.
Fixes: 3dc8fc083dbf ("HID: Use hid_parser for pre-scanning the report descriptors")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/hid/hid-core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 41a79e43c82b..d6676505e122 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -379,6 +379,9 @@ static int hid_add_field(struct hid_parser *parser, unsigned report_type, unsign
static u32 item_udata(struct hid_item *item)
{
+ if (item->format != HID_ITEM_FORMAT_SHORT)
+ return 0;
+
switch (item->size) {
case 1: return item->data.u8;
case 2: return item->data.u16;
@@ -389,6 +392,9 @@ static u32 item_udata(struct hid_item *item)
static s32 item_sdata(struct hid_item *item)
{
+ if (item->format != HID_ITEM_FORMAT_SHORT)
+ return 0;
+
switch (item->size) {
case 1: return item->data.s8;
case 2: return item->data.s16;
---
base-commit: 51512e22efe813d8223de27f6fd02a8a48ea2323
change-id: 20260703-hid-core-data-typeconfusion-95c660affffe
Best regards,
--
Jann Horn <jannh@google.com>
^ permalink raw reply related
* [dtor-input:for-linus] BUILD SUCCESS 536394ec81419b67d9f4f0028812c4372397be1b
From: kernel test robot @ 2026-07-03 18:56 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 536394ec81419b67d9f4f0028812c4372397be1b Input: maple_keyb - set driver data before registering input device
elapsed time: 760m
configs tested: 324
configs skipped: 5
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc axs103_defconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001 gcc-16.1.0
arc randconfig-001-20260703 gcc-16.1.0
arc randconfig-001-20260703 gcc-8.5.0
arc randconfig-001-20260704 gcc-8.5.0
arc randconfig-002 gcc-16.1.0
arc randconfig-002-20260703 gcc-16.1.0
arc randconfig-002-20260703 gcc-8.5.0
arc randconfig-002-20260704 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig gcc-16.1.0
arm keystone_defconfig gcc-16.1.0
arm mvebu_v7_defconfig clang-23
arm randconfig-001 gcc-16.1.0
arm randconfig-001-20260703 gcc-16.1.0
arm randconfig-001-20260703 gcc-8.5.0
arm randconfig-001-20260704 gcc-8.5.0
arm randconfig-002 gcc-16.1.0
arm randconfig-002-20260703 gcc-16.1.0
arm randconfig-002-20260703 gcc-8.5.0
arm randconfig-002-20260704 gcc-8.5.0
arm randconfig-003 gcc-16.1.0
arm randconfig-003-20260703 gcc-16.1.0
arm randconfig-003-20260703 gcc-8.5.0
arm randconfig-003-20260704 gcc-8.5.0
arm randconfig-004 gcc-16.1.0
arm randconfig-004-20260703 gcc-16.1.0
arm randconfig-004-20260703 gcc-8.5.0
arm randconfig-004-20260704 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 gcc-10.5.0
arm64 randconfig-001-20260703 clang-23
arm64 randconfig-001-20260703 gcc-10.5.0
arm64 randconfig-001-20260704 gcc-16.1.0
arm64 randconfig-002 gcc-10.5.0
arm64 randconfig-002-20260703 gcc-10.5.0
arm64 randconfig-002-20260703 gcc-12.5.0
arm64 randconfig-002-20260704 gcc-16.1.0
arm64 randconfig-003 gcc-10.5.0
arm64 randconfig-003-20260703 gcc-10.5.0
arm64 randconfig-003-20260704 gcc-16.1.0
arm64 randconfig-004 gcc-10.5.0
arm64 randconfig-004-20260703 gcc-10.5.0
arm64 randconfig-004-20260703 gcc-8.5.0
arm64 randconfig-004-20260704 gcc-16.1.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 gcc-10.5.0
csky randconfig-001-20260703 gcc-10.5.0
csky randconfig-001-20260703 gcc-12.5.0
csky randconfig-001-20260704 gcc-16.1.0
csky randconfig-002 gcc-10.5.0
csky randconfig-002-20260703 gcc-10.5.0
csky randconfig-002-20260704 gcc-16.1.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260703 gcc-11.5.0
hexagon randconfig-001-20260703 gcc-16.1.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260703 gcc-11.5.0
hexagon randconfig-002-20260703 gcc-16.1.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001 clang-22
i386 buildonly-randconfig-001-20260703 clang-22
i386 buildonly-randconfig-002 clang-22
i386 buildonly-randconfig-002-20260703 clang-22
i386 buildonly-randconfig-003 clang-22
i386 buildonly-randconfig-003-20260703 clang-22
i386 buildonly-randconfig-004 clang-22
i386 buildonly-randconfig-004-20260703 clang-22
i386 buildonly-randconfig-005 clang-22
i386 buildonly-randconfig-005-20260703 clang-22
i386 buildonly-randconfig-006 clang-22
i386 buildonly-randconfig-006-20260703 clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001 clang-22
i386 randconfig-001-20260703 clang-22
i386 randconfig-002 clang-22
i386 randconfig-002-20260703 clang-22
i386 randconfig-003 clang-22
i386 randconfig-003-20260703 clang-22
i386 randconfig-004 clang-22
i386 randconfig-004-20260703 clang-22
i386 randconfig-005 clang-22
i386 randconfig-005-20260703 clang-22
i386 randconfig-006 clang-22
i386 randconfig-006-20260703 clang-22
i386 randconfig-007 clang-22
i386 randconfig-007-20260703 clang-22
i386 randconfig-011 clang-22
i386 randconfig-011-20260703 clang-22
i386 randconfig-012 clang-22
i386 randconfig-012-20260703 clang-22
i386 randconfig-013 clang-22
i386 randconfig-013-20260703 clang-22
i386 randconfig-014 clang-22
i386 randconfig-014-20260703 clang-22
i386 randconfig-015 clang-22
i386 randconfig-015-20260703 clang-22
i386 randconfig-016 clang-22
i386 randconfig-016-20260703 clang-22
i386 randconfig-017 clang-22
i386 randconfig-017-20260703 clang-22
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260703 gcc-11.5.0
loongarch randconfig-001-20260703 gcc-16.1.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260703 gcc-11.5.0
loongarch randconfig-002-20260703 gcc-16.1.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
microblaze defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 defconfig gcc-11.5.0
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260703 gcc-11.5.0
nios2 randconfig-001-20260703 gcc-16.1.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260703 gcc-11.5.0
nios2 randconfig-002-20260703 gcc-16.1.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001 clang-23
parisc randconfig-001-20260703 clang-23
parisc randconfig-001-20260704 clang-23
parisc randconfig-002 clang-23
parisc randconfig-002-20260703 clang-23
parisc randconfig-002-20260704 clang-23
parisc64 defconfig clang-23
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc chrp32_defconfig clang-23
powerpc ep8248e_defconfig gcc-16.1.0
powerpc randconfig-001 clang-23
powerpc randconfig-001-20260703 clang-23
powerpc randconfig-001-20260704 clang-23
powerpc randconfig-002 clang-23
powerpc randconfig-002-20260703 clang-23
powerpc randconfig-002-20260704 clang-23
powerpc64 randconfig-001 clang-23
powerpc64 randconfig-001-20260703 clang-23
powerpc64 randconfig-001-20260704 clang-23
powerpc64 randconfig-002 clang-23
powerpc64 randconfig-002-20260703 clang-23
powerpc64 randconfig-002-20260704 clang-23
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001-20260703 gcc-9.5.0
riscv randconfig-001-20260704 gcc-10.5.0
riscv randconfig-002-20260703 gcc-9.5.0
riscv randconfig-002-20260704 gcc-10.5.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001-20260703 gcc-9.5.0
s390 randconfig-001-20260704 gcc-10.5.0
s390 randconfig-002-20260703 gcc-9.5.0
s390 randconfig-002-20260704 gcc-10.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh hp6xx_defconfig gcc-16.1.0
sh randconfig-001-20260703 gcc-9.5.0
sh randconfig-001-20260704 gcc-10.5.0
sh randconfig-002-20260703 gcc-9.5.0
sh randconfig-002-20260704 gcc-10.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260703 gcc-11.5.0
sparc randconfig-001-20260704 gcc-16.1.0
sparc randconfig-002-20260703 gcc-11.5.0
sparc randconfig-002-20260704 gcc-16.1.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260703 gcc-11.5.0
sparc64 randconfig-001-20260704 gcc-16.1.0
sparc64 randconfig-002-20260703 gcc-11.5.0
sparc64 randconfig-002-20260704 gcc-16.1.0
um allmodconfig clang-17
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260703 gcc-11.5.0
um randconfig-001-20260704 gcc-16.1.0
um randconfig-002-20260703 gcc-11.5.0
um randconfig-002-20260704 gcc-16.1.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260703 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260703 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260703 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260703 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260703 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260703 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 clang-22
x86_64 randconfig-001-20260703 clang-22
x86_64 randconfig-002 clang-22
x86_64 randconfig-002-20260703 clang-22
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260703 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260703 clang-22
x86_64 randconfig-005 clang-22
x86_64 randconfig-005-20260703 clang-22
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260703 clang-22
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260703 gcc-13
x86_64 randconfig-011-20260703 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260703 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260703 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260703 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260703 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260703 clang-22
x86_64 randconfig-016-20260703 gcc-14
x86_64 randconfig-071 clang-22
x86_64 randconfig-071-20260703 clang-22
x86_64 randconfig-072 clang-22
x86_64 randconfig-072-20260703 clang-22
x86_64 randconfig-073 clang-22
x86_64 randconfig-073-20260703 clang-22
x86_64 randconfig-074 clang-22
x86_64 randconfig-074-20260703 clang-22
x86_64 randconfig-075 clang-22
x86_64 randconfig-075-20260703 clang-22
x86_64 randconfig-076 clang-22
x86_64 randconfig-076-20260703 clang-22
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa common_defconfig gcc-16.1.0
xtensa randconfig-001-20260703 gcc-11.5.0
xtensa randconfig-001-20260704 gcc-16.1.0
xtensa randconfig-002-20260703 gcc-11.5.0
xtensa randconfig-002-20260704 gcc-16.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] HID: logitech-dj: Add support for G915 TKL receiver 0xc545
From: Colin Blower @ 2026-07-04 0:28 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Filipe Laíns, linux-input, linux-kernel
The Logitech G915 TKL has a lightspeed receiver with a product id of
0xc545. This receiver seems to behave like 0xc547 receiver.
Add a definition for this new receiver id and a mapping for the
recvr_type_gaming_hidpp_ls_1_3 type, the receiver now reports battery
status of the connected keyboard.
Signed-off-by: Colin Blower <colin@1101b.com>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-logitech-dj.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 1059922baaac..0089a5e88ec9 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -967,6 +967,7 @@
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_2 0xc543
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_3 0xc547
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_4 0xc54d
+#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_5 0xc545
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY 0xc53a
#define USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER 0xc548
#define USB_DEVICE_ID_SPACETRAVELLER 0xc623
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 381e4dc5aba7..49b96ff2bc36 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -2102,6 +2102,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_4),
.driver_data = recvr_type_gaming_hidpp_ls_1_3},
+ { /* Logitech lightspeed receiver (0xc545) */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+ USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_5),
+ .driver_data = recvr_type_gaming_hidpp_ls_1_3},
{ /* Logitech 27 MHz HID++ 1.0 receiver (0xc513) */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER),
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v2 2/6] iio: hid-sensors: align function parenthesis for readability
From: srinivas pandruvada @ 2026-07-04 1:09 UTC (permalink / raw)
To: Andy Shevchenko, Jonathan Cameron
Cc: Sanjay Chitroda via B4 Relay, sanjayembeddedse, David Lechner,
Nuno Sá, Andy Shevchenko, Jiri Kosina, linux-iio,
linux-kernel, linux-input
In-Reply-To: <akewhE9wEpU6UW0u@ashevche-desk.local>
On Fri, 2026-07-03 at 15:52 +0300, Andy Shevchenko wrote:
> On Thu, Jul 02, 2026 at 06:20:15PM +0100, Jonathan Cameron wrote:
> > On Thu, 02 Jul 2026 21:47:59 +0530
> > Sanjay Chitroda via B4 Relay
> > <devnull+sanjayembeddedse.gmail.com@kernel.org> wrote:
> >
> > > Adjust alignment of parentheses across HID sensor IIO drivers to
> > > improve readability and maintain consistency with kernel coding
> > > style.
> > >
> > > While updating the formatting, group related arguments
> > > consistently in
> > > multi-line function signatures where appropriate.
> > >
> > > No functional change intended.
> >
> > Whilst I appreciate this code isn't quite in line with standards
> > and usually like that stuff to be fixed up, in this particular case
> > this is a massive amount of churn. That churn will make
> > backporting
> > fixes etc messier, so I'd like input on whether others consider
> > this
> > one worthwhile. Jiri, Srinivas, Andy etc. What do you think?
>
> I am fine as long as Srinivas is. I understand pros and cons of this,
> but from
> time to time we have patches à la this one that messes up with
> backporting but
> were accepted as a good part of some bigger series.
I am fine. I guess we will deal with backporting issues as they appear.
Thanks,
Srinivas
^ permalink raw reply
* [PATCH 00/26] sh: maple: cleanup and modernize input drivers
From: Dmitry Torokhov @ 2026-07-04 5:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz
Cc: Florian Fuchs, Adrian McMenamin, linux-kernel, Dmitry Torokhov,
linux-input, linux-mtd, linux-sh
This series aims to modernize the Maple bus core and its input drivers
(keyboard, mouse, joystick/controller), addressing build failures, race
conditions, and coding style issues:
- fixes a build failure in vmu-flash.c due to missing include
- fixes keyboard press detection logic (eliminating a 1-poll delay and
redundant press events)
- corrects D-pad axis limits and optimizes event reporting using
branchless calculations
- implements open() and close() in maple_keyb so all Maple input drivers
only poll when actively open
- introduces callback_mutex in the Maple bus core to avoid potential UAF
when stopping/unbinding the drivers
- removes the unused driver field from struct maple_device (write-only
since 2008) and eliminates the redundant maple_unsupported_device dummy
driver
- implements standard bus-level probe() and remove() methods for the
Maple bus
- converts all three Maple input drivers to use managed resources, and
fixes style issues reported by checkpatch.
This compiles but has not been tested on real hardware.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Dmitry Torokhov (26):
sh: maple: include linux/device.h in linux/maple.h
Input: maple_keyb - fix key press detection
Input: maplecontrol - only enable present axes
Input: maplemouse - stop polling and clear callback on close
Input: maplecontrol - stop polling and clear callback on close
Input: maplecontrol - simplify maple_device retrieval in open/close
Input: maple_keyb - implement open and close methods
Input: maplemouse - remove redundant drvdata resetting
Input: maple_keyb - remove redundant drvdata resetting
Input: maplecontrol - remove redundant drvdata resetting
Input: maplemouse - remove unused mdev->driver assignment
Input: maplecontrol - remove unused mdev->driver assignment
Input: maple_keyb - remove unused mdev->driver assignment
mtd: maps: vmu-flash: remove unused mdev->driver assignment
sh: maple: remove not needed maple_unsupported_device driver
sh: maple: remove unused driver field from struct maple_device
sh: maple: implement bus-level probe/remove
sh: maple: introduce callback_mutex in maple_device
Input: maple_keyb - remove redundant mutex and remove method
Input: maple_keyb - convert to devm
Input: maplemouse - convert to devm
Input: maplecontrol - convert to devm
Input: maple_keyb - fix style issues
Input: maplemouse - fix style issues
Input: maplecontrol - fix style issues
Input: maple_keyb - remove redundant 'new' buffer from struct dc_kbd
drivers/input/joystick/maplecontrol.c | 98 +++++++++------------------
drivers/input/keyboard/maple_keyb.c | 124 +++++++++++++---------------------
drivers/input/mouse/maplemouse.c | 55 ++++-----------
drivers/mtd/maps/vmu-flash.c | 15 ++--
drivers/sh/maple/maple.c | 61 ++++++++++-------
include/linux/maple.h | 8 ++-
6 files changed, 140 insertions(+), 221 deletions(-)
---
base-commit: 2b763db0c2763d6bf73d7d3e69665222d1f377cf
change-id: 20260628-b4-maple-cleanup-884682ae108b
Thanks.
--
Dmitry
^ 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