* Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core
From: mikhail.v.gavrilov @ 2026-03-11 17:47 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20260228223628.472208-1-mikhail.v.gavrilov@gmail.com>
On Sun, 2026-03-01 at 03:36 +0500, Mikhail Gavrilov wrote:
> A lockdep circular locking dependency warning can be triggered
> reproducibly when using a force-feedback gamepad with uinput (for
> example, playing ELDEN RING under Wine with a Flydigi Vader 5
> controller):
>
> ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
>
> The cycle is caused by four lock acquisition paths:
>
> 1. ff upload: input_ff_upload() holds ff->mutex and calls
> uinput_dev_upload_effect() -> uinput_request_submit() ->
> uinput_request_send(), which acquires udev->mutex.
>
> 2. device create: uinput_ioctl_handler() holds udev->mutex and calls
> uinput_create_device() -> input_register_device(), which acquires
> input_mutex.
>
> 3. device register: input_register_device() holds input_mutex and
> calls kbd_connect() -> input_register_handle(), which acquires
> dev->mutex.
>
> 4. evdev release: evdev_release() calls input_flush_device() under
> dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
>
>
>
Hi Dmitry,
Friendly ping on this patch. It fixes a reproducible lockdep circular
dependency warning in uinput with force-feedback gamepads under
Wine/Proton, tested on 7.0-rc1.
I realize I should have included:
Fixes: ff462551235d ("Input: uinput - switch to the new FF
interface")
Cc: stable@vger.kernel.org
Should I resend as v2 with these tags, or can you add them when
applying?
--
Best Regards,
Mike Gavrilov.
^ permalink raw reply
* Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core
From: Dmitry Torokhov @ 2026-03-11 17:50 UTC (permalink / raw)
To: mikhail.v.gavrilov; +Cc: linux-input, linux-kernel
In-Reply-To: <e28527adc34ace88462f2fcce53ab8586dc760a7.camel@gmail.com>
On Wed, Mar 11, 2026 at 10:47:25PM +0500, mikhail.v.gavrilov@gmail.com wrote:
> On Sun, 2026-03-01 at 03:36 +0500, Mikhail Gavrilov wrote:
> > A lockdep circular locking dependency warning can be triggered
> > reproducibly when using a force-feedback gamepad with uinput (for
> > example, playing ELDEN RING under Wine with a Flydigi Vader 5
> > controller):
> >
> > ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
> >
> > The cycle is caused by four lock acquisition paths:
> >
> > 1. ff upload: input_ff_upload() holds ff->mutex and calls
> > uinput_dev_upload_effect() -> uinput_request_submit() ->
> > uinput_request_send(), which acquires udev->mutex.
> >
> > 2. device create: uinput_ioctl_handler() holds udev->mutex and calls
> > uinput_create_device() -> input_register_device(), which acquires
> > input_mutex.
> >
> > 3. device register: input_register_device() holds input_mutex and
> > calls kbd_connect() -> input_register_handle(), which acquires
> > dev->mutex.
> >
> > 4. evdev release: evdev_release() calls input_flush_device() under
> > dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
> >
> >
> >
> Hi Dmitry,
>
> Friendly ping on this patch. It fixes a reproducible lockdep circular
> dependency warning in uinput with force-feedback gamepads under
> Wine/Proton, tested on 7.0-rc1.
>
> I realize I should have included:
>
> Fixes: ff462551235d ("Input: uinput - switch to the new FF
> interface")
> Cc: stable@vger.kernel.org
>
> Should I resend as v2 with these tags, or can you add them when
> applying?
Sorry I need a bit more time to evaluate the patch. I think what you
proposed makes sense, just give me a couple more days.
If there are no changes needed I can add necessary tags on my end.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: Enable MX Master 4 over bluetooth
From: Adrian Freund @ 2026-03-11 19:19 UTC (permalink / raw)
To: linux-kernel, linux-input; +Cc: Jiri Kosina, Benjamin Tissoires, Adrian Freund
The Logitech MX Master 4 can be connected over bluetooth or through a
Logitech Bolt receiver. This change adds support for non-standard HID
features, such as high resolution scrolling when the mouse is connected
over bluetooth.
Because no Logitech Bolt receiver driver exists yet those features
won't be available when the mouse is connected through the receiver.
Signed-off-by: Adrian Freund <adrian@freund.io>
---
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d40932809ce1..cf07660bd85b 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4668,6 +4668,8 @@ static const struct hid_device_id hidpp_devices[] = {
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
{ /* Slim Solar+ K980 Keyboard over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb391) },
+ { /* MX Master 4 mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb042) },
{}
};
--
2.53.0
^ permalink raw reply related
* [PATCH] xpad: Add RedOctane Games vendor id
From: Sanjay Govind @ 2026-03-11 21:31 UTC (permalink / raw)
To: Dmitry Torokhov, Vicki Pfau, Sanjay Govind, Nilton Perim Neto,
Mario Limonciello, Lode Willems
Cc: Pierre-Loup A. Griffais, linux-input, linux-kernel
Add vendor ID for RedOctane Games to xpad
Signed-off-by: Sanjay Govind <sanjay.govind9@gmail.com>
---
drivers/input/joystick/xpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index bf4accf3f581..e97ff270d978 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -585,6 +585,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOX360_VENDOR(0x3651), /* CRKD Controllers */
XPAD_XBOXONE_VENDOR(0x366c), /* ByoWave controllers */
XPAD_XBOX360_VENDOR(0x37d7), /* Flydigi Controllers */
+ XPAD_XBOX360_VENDOR(0x3958), /* RedOctane Games Controllers */
XPAD_XBOX360_VENDOR(0x413d), /* Black Shark Green Ghost Controller */
{ }
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 49/61] media: Prefer IS_ERR_OR_NULL over manual NULL check
From: Kieran Bingham @ 2026-03-11 23:03 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, lin
Cc: Shuah Khan, Mauro Carvalho Chehab
In-Reply-To: <20260310-b4-is_err_or_null-v1-49-bd63b656022d@avm.de>
Quoting Philipp Hahn (2026-03-10 11:49:15)
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Shuah Khan <skhan@linuxfoundation.org>
> To: Kieran Bingham <kieran.bingham@ideasonboard.com>
> To: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: linux-media@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/media/test-drivers/vimc/vimc-streamer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/test-drivers/vimc/vimc-streamer.c b/drivers/media/test-drivers/vimc/vimc-streamer.c
> index 15d863f97cbf96b7ca7fbf3d7b6b6ec39fcc8ae3..da5aca50bcb4990c06f28e5a883eb398606991e9 100644
> --- a/drivers/media/test-drivers/vimc/vimc-streamer.c
> +++ b/drivers/media/test-drivers/vimc/vimc-streamer.c
> @@ -167,7 +167,7 @@ static int vimc_streamer_thread(void *data)
> for (i = stream->pipe_size - 1; i >= 0; i--) {
> frame = stream->ved_pipeline[i]->process_frame(
> stream->ved_pipeline[i], frame);
> - if (!frame || IS_ERR(frame))
> + if (IS_ERR_OR_NULL(frame))
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> break;
> }
> //wait for 60hz
>
> --
> 2.43.0
>
^ permalink raw reply
* Fwd: [PATCH 09/12] dt-bindings: input: Document hid-over-spi DT schema
From: Jingyuan Liang @ 2026-03-12 0:58 UTC (permalink / raw)
To: Rob Herring
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley, linux-input,
linux-doc, LKML, linux-spi, linux-trace-kernel, devicetree,
Henry Barnor, Dmitry Antipov, Jarrett Schultz
In-Reply-To: <CAEe3GZHSqepvjjopLwrWX3_n4+RnCeVVQnAO=Swixgu2z3OpUw@mail.gmail.com>
(Resending to the list. Apologies, I accidentally dropped the CCs on
my initial reply!)
On Tue, Mar 3, 2026 at 5:53 AM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Mar 3, 2026 at 12:14 AM Jingyuan Liang <jingyliang@chromium.org> wrote:
> >
> > Documentation describes the required and optional properties for
> > implementing Device Tree for a Microsoft G6 Touch Digitizer that
> > supports HID over SPI Protocol 1.0 specification.
> >
> > The properties are common to HID over SPI.
> >
> > Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> > Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> > Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> > ---
> > .../devicetree/bindings/input/hid-over-spi.yaml | 153 +++++++++++++++++++++
> > 1 file changed, 153 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > new file mode 100644
> > index 000000000000..b623629ed9d3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > @@ -0,0 +1,153 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: HID over SPI Devices
> > +
> > +maintainers:
> > + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > + - Jiri Kosina <jkosina@suse.cz>
> > +
> > +description: |+
> > + HID over SPI provides support for various Human Interface Devices over the
> > + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> > + or sensors.
> > +
> > + The specification has been written by Microsoft and is currently available here:
> > + https://www.microsoft.com/en-us/download/details.aspx?id=103325
> > +
> > + If this binding is used, the kernel module spi-hid will handle the communication
> > + with the device and the generic hid core layer will handle the protocol.
> > +
> > +allOf:
> > + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - microsoft,g6-touch-digitizer
> > + - const: hid-over-spi
> > + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> > + const: hid-over-spi
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + reset-gpios:
> > + maxItems: 1
> > + description:
> > + GPIO specifier for the digitizer's reset pin (active low). The line must
> > + be flagged with GPIO_ACTIVE_LOW.
> > +
> > + vdd-supply:
> > + description:
> > + Regulator for the VDD supply voltage.
>
> Is this part of the spec? This won't scale for multiple devices with
> different power rails.
This is not part of the spec but is needed for power management. Is it okay I
mark it as optional? Thank you.
>
> > +
> > + input-report-header-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0
> > + maximum: 0xffffff
> > + description:
> > + A value to be included in the Read Approval packet, listing an address of
> > + the input report header to be put on the SPI bus. This address has 24
> > + bits.
> > +
> > + input-report-body-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0
> > + maximum: 0xffffff
> > + description:
> > + A value to be included in the Read Approval packet, listing an address of
> > + the input report body to be put on the SPI bus. This address has 24 bits.
> > +
> > + output-report-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0
> > + maximum: 0xffffff
> > + description:
> > + A value to be included in the Output Report sent by the host, listing an
> > + address where the output report on the SPI bus is to be written to. This
> > + address has 24 bits.
> > +
> > + post-power-on-delay-ms:
> > + description:
> > + Optional time in ms required by the device after enabling its regulators
> > + or powering it on, before it is ready for communication.
>
> Drop. This should be implied by the compatible.
Thank you, I will fix this in v2.
>
> > +
> > + minimal-reset-delay-ms:
> > + description:
> > + Optional minimum amount of time in ms that device needs to be in reset
> > + state for the reset to take effect.
>
> Drop. This should be implied by the compatible.
I will fix this in v2.
>
> > +
> > + read-opcode:
> > + $ref: /schemas/types.yaml#/definitions/uint8
> > + description:
> > + Value to be used in Read Approval packets. 1 byte.
> > +
> > + write-opcode:
> > + $ref: /schemas/types.yaml#/definitions/uint8
> > + description:
> > + Value to be used in Write Approval packets. 1 byte.
>
> Why are these and the address properties above not defined by the
> spec? Do they vary for a specific device? If not, then they should be
> implied by the compatible.
These properties are not defined by the spec:
"The Input Report Address (header or body) and READ opcode are retrieved
from ACPI."
Same for the output report address and write opcode. I will drop these in v2.
>
> > +
> > + hid-over-spi-flags:
> > + $ref: /schemas/types.yaml#/definitions/uint16
> > + description:
> > + 16 bits.
> > + Bits 0-12 - Reserved (must be 0)
> > + Bit 13 - SPI Write Mode. Possible values -
> > + * 0b0- Writes are carried out in Single-SPI mode
> > + * 0b1- Writes are carried out in the Multi-SPI mode specified by bits
> > + 14-15
> > + Bits 14-15 - Multi-SPI Mode. Possible values -
> > + * 0b00- Single SPI
> > + * 0b01- Dual SPI
> > + * 0b10- Quad SPI
>
> We already have SPI properties to define the bus width for read and write.
Will fix this in v2.
>
> > +
> > +required:
> > + - compatible
> > + - interrupts
> > + - reset-gpios
> > + - vdd-supply
> > + - input-report-header-address
> > + - input-report-body-address
> > + - output-report-address
> > + - read-opcode
> > + - write-opcode
> > + - hid-over-spi-flags
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + spi {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + hid@0 {
> > + compatible = "hid-over-spi";
> > + reg = <0x0>;
> > + interrupts-extended = <&gpio 42 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
> > + vdd-supply = <&pm8350c_l3>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ts_d6_reset_assert &ts_d6_int_bias>;
> > + input-report-header-address = <0x1000>;
> > + input-report-body-address = <0x1004>;
> > + output-report-address = <0x2000>;
> > + read-opcode = <0x0b>;
> > + write-opcode = <0x02>;
> > + hid-over-spi-flags = <0x0000>;
> > + post-power-on-delay-ms = <5>;
> > + minimal-reset-delay-ms = <5>;
> > + };
> > + };
> > \ No newline at end of file
>
> Fix this.
Will fix this in v2.
>
> Rob
^ permalink raw reply
* Re: [PATCH v6 16/19] HID: Add documentation for Lenovo Legion Go drivers
From: Akira Yokosawa @ 2026-03-12 2:44 UTC (permalink / raw)
To: derekjohn.clark
Cc: bentiss, hughsient, jikos, linux-doc, linux-input, linux-kernel,
mario.limonciello, mpearson-lenovo, pgriffais, shaohz1, zhangzx36
In-Reply-To: <20260310072937.3295875-17-derekjohn.clark@gmail.com>
Hi,
On Tue, 10 Mar 2026 07:29:34 +0000, Derek J. Clark wrote:
> Adds ABI documentation for the hid-lenovo-go-s and hid-lenovo-go
> drivers.
>
> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
> ---
> v3:
> - Remove excess + from every line of patch.
> ---
> .../ABI/testing/sysfs-driver-hid-lenovo-go | 724 ++++++++++++++++++
> .../ABI/testing/sysfs-driver-hid-lenovo-go-s | 304 ++++++++
> MAINTAINERS | 2 +
> 3 files changed, 1030 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-lenovo-go
> create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s
This (commit 168c91839139 in next-20260311) causes a lot of new warnings
in "make htmldocs" such as:
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode is defined 2 times: /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:364; /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:234
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode_index is defined 2 times: /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:373; /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:243
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled is defined 2 times: /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:636; /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:252
[snip]
Please fix.
Thanks, Akira
^ permalink raw reply
* Re: [tip:timers/vdso 37/45] progs/hid_bpf_helpers.h:117:31: error: declaration of 'struct bpf_wq' will not be visible outside of this function
From: Thomas Weißschuh @ 2026-03-12 6:46 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, linux-input, kernel test robot, oe-kbuild-all,
linux-kernel, x86, Thomas Gleixner
In-Reply-To: <abGeK0FpNn5uXi8B@beelink>
Hi Benjamin,
thanks for the quick response.
On Wed, Mar 11, 2026 at 06:05:25PM +0100, Benjamin Tissoires wrote:
> On Mar 11 2026, Thomas Weißschuh wrote:
> > could you take a look at the report below?
> > This looks like an issue in the HID BPF subsystem, surfaced by my
> > unrelated change. Does this ring a bell for you?
> >
> > I wasn't able to reproduce it so far, but will continue looking into it.
>
> Both struct bpf_wq and struct hid_device should be generated in the
> vmlinux.h that we include in the selftests. So this is definitely not
> related to your patch AFAICT.
Ack. To be sure I sent this branch again through 0day and will see if it
breaks on the same commit.
> Looking in the config, we have `# CONFIG_HID_SUPPORT is not set` -> so
> that would explain why struct hid_device is not available. But in that
> case, why are the HID selftests even built?
CONFIG_DEBUG_INFO_BTF is also not set. So there should be no vmlinux.h
at all in the first. Which is exactly what happens in my attempts
to reproduce the issue. But even when fixing that up, the issue persists.
> The bpf_wq bits should be related to a similar-ish issue where one
> config setting is not set and so it's not included in the final BTF.
I'll look into how exactly things end up in vmlinux.h.
At least the headers for 'struct bpf_wq' are always included somewhere.
But maybe the type also needs to be used to define some structure.
> I paged out how we can ignore selftests based on the .config, so if you
> have any hints, that would be nice :)
Inspecting the kernel configuration might be hard, as there might be no file
for it available. Could you use vmlinux.h itself for feature detection?
Thomas
> > On Wed, Mar 11, 2026 at 03:29:54PM +0100, kernel test robot wrote:
> > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso
> > > head: f7178f159b2a36d070fd43b0d751e4e4415ec39e
> > > commit: 912632a7fd4cc1eac2778828d92e8fe46939d6bd [37/45] vdso/datapage: Trim down unnecessary includes
> > > config: riscv-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260311/202603111558.KLCIxsZB-lkp@intel.com/config)
> > > compiler: riscv64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260311/202603111558.KLCIxsZB-lkp@intel.com/reproduce)
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202603111558.KLCIxsZB-lkp@intel.com/
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > > In file included from progs/hid.c:3:
> > > >> progs/hid_bpf_helpers.h:117:31: error: declaration of 'struct bpf_wq' will not be visible outside of this function [-Werror,-Wvisibility]
> > > 117 | extern int bpf_wq_init(struct bpf_wq *wq, void *p__map, unsigned int flags) __weak __ksym;
> > > | ^
> > > progs/hid_bpf_helpers.h:118:32: error: declaration of 'struct bpf_wq' will not be visible outside of this function [-Werror,-Wvisibility]
> > > 118 | extern int bpf_wq_start(struct bpf_wq *wq, unsigned int flags) __weak __ksym;
> > > | ^
> > > progs/hid_bpf_helpers.h:119:39: error: declaration of 'struct bpf_wq' will not be visible outside of this function [-Werror,-Wvisibility]
> > > 119 | extern int bpf_wq_set_callback(struct bpf_wq *wq,
> > > | ^
> > > >> progs/hid.c:448:16: error: field has incomplete type 'struct bpf_wq'
> > > 448 | struct bpf_wq work;
> > > | ^
> > > progs/hid.c:448:9: note: forward declaration of 'struct bpf_wq'
> > > 448 | struct bpf_wq work;
> > > | ^
> > > >> progs/hid.c:487:18: error: incompatible pointer types passing 'struct bpf_wq *' to parameter of type 'struct bpf_wq *' [-Wincompatible-pointer-types]
> > > 487 | if (bpf_wq_init(wq, &hmap, 0) != 0)
> > > | ^~
> > > progs/hid_bpf_helpers.h:117:39: note: passing argument to parameter 'wq' here
> > > 117 | extern int bpf_wq_init(struct bpf_wq *wq, void *p__map, unsigned int flags) __weak __ksym;
> > > | ^
> > > progs/hid.c:490:26: error: incompatible pointer types passing 'struct bpf_wq *' to parameter of type 'struct bpf_wq *' [-Wincompatible-pointer-types]
> > > 490 | if (bpf_wq_set_callback(wq, wq_cb_sleepable, 0))
> > > | ^~
> > > progs/hid_bpf_helpers.h:119:47: note: passing argument to parameter 'wq' here
> > > 119 | extern int bpf_wq_set_callback(struct bpf_wq *wq,
> > > | ^
> > > progs/hid.c:493:19: error: incompatible pointer types passing 'struct bpf_wq *' to parameter of type 'struct bpf_wq *' [-Wincompatible-pointer-types]
> > > 493 | if (bpf_wq_start(wq, 0))
> > > | ^~
> > > progs/hid_bpf_helpers.h:118:40: note: passing argument to parameter 'wq' here
> > > 118 | extern int bpf_wq_start(struct bpf_wq *wq, unsigned int flags) __weak __ksym;
> > > | ^
> > > progs/hid.c:503:24: error: incomplete definition of type 'struct hid_device'
> > > 503 | int hid = hid_ctx->hid->id;
> > > | ~~~~~~~~~~~~^
> > > progs/hid_bpf_helpers.h:59:9: note: forward declaration of 'struct hid_device'
> > > 59 | struct hid_device *hid;
> > > | ^
> > > 8 errors generated.
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://github.com/intel/lkp-tests/wiki
> >
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Enable MX Master 4 over bluetooth
From: Jiri Kosina @ 2026-03-12 12:44 UTC (permalink / raw)
To: Adrian Freund; +Cc: linux-kernel, linux-input, Benjamin Tissoires
In-Reply-To: <20260311191933.81007-1-adrian@freund.io>
On Wed, 11 Mar 2026, Adrian Freund wrote:
> The Logitech MX Master 4 can be connected over bluetooth or through a
> Logitech Bolt receiver. This change adds support for non-standard HID
> features, such as high resolution scrolling when the mouse is connected
> over bluetooth.
> Because no Logitech Bolt receiver driver exists yet those features
> won't be available when the mouse is connected through the receiver.
>
> Signed-off-by: Adrian Freund <adrian@freund.io>
Applied to hid.git#for-7.0/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6 0/3] HID: Add support for multiple batteries per device
From: Jiri Kosina @ 2026-03-12 12:55 UTC (permalink / raw)
To: Lucas Zampieri
Cc: linux-input, linux-kernel, Benjamin Tissoires, Sebastian Reichel,
Bastien Nocera, linux-pm, lcasmz54
In-Reply-To: <20251226111019.31243-1-lzampier@redhat.com>
On Fri, 26 Dec 2025, Lucas Zampieri wrote:
> This series adds support for HID devices with multiple batteries.
>
> Currently, the HID battery reporting subsystem only supports one battery per
> device. There are several devices with multiple batteries that would benefit
> from this support:
> - Gaming headsets with batteries in both the headset and charging dock
> - Wireless earbuds with per-earbud batteries plus charging case
> - Split keyboards with per-side batteries
Lucas,
I've gone through this v6 and it looks good to me.
There are some simple conflicts with the current codebase through. So
instead of me fixing them without testing, could you please look into
rebasing it once more on top of hid.git, and I'll then merge it?
Thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: quirks: really enable the intended work around for appledisplay
From: Jiri Kosina @ 2026-03-12 12:56 UTC (permalink / raw)
To: René Rebe
Cc: Lukas Bulwahn, Benjamin Tissoires, linux-input, kernel-janitors,
linux-kernel, Lukas Bulwahn
In-Reply-To: <9pos2s83-p7q0-oq36-oqo3-s555o07p31n9@xreary.bet>
On Sat, 21 Feb 2026, Jiri Kosina wrote:
> > > Commit c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for
> > > appledisplay") intends to add a quirk for kernels built with Apple Cinema
> > > Display support, but it refers to the non-existing config option
> > > CONFIG_APPLEDISPLAY, whereas the config option for Apple Cinema Display
> > > support is named CONFIG_USB_APPLEDISPLAY.
> > >
> > > Refer to the intended config option CONFIG_USB_APPLEDISPLAY in the ifdef
> > > directive.
> > >
> > > Fixes: c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay")
> > > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
> > > ---
> > >
> > > Note this fix suggests that the patch of commit c7fabe4ad921 in this form
> > > was never effectively tested, checking the effect that the commit message
> > > claims it would have.
> >
> > Thanks for spotting this. It was tested when I did this years ago. Though, maybe I
> > tested before adding the #if IS_ENABLED, anciently hit some key in Vim, o
> > something was renamed since then.
> >
> > Either way, I’ll get the display out of the basement and re-test it the coming days.
>
> Is there any results of this testing, please?
Friendly ping on this one :)
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: Jason Gunthorpe @ 2026-03-12 12:57 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
In-Reply-To: <abBlpGKO842B3yl9@google.com>
On Wed, Mar 11, 2026 at 02:40:36AM +0800, Kuan-Wei Chiu wrote:
> IMHO, the necessity of IS_ERR_OR_NULL() often highlights a confusing or
> flawed API design. It usually implies that the caller is unsure whether
> a failure results in an error pointer or a NULL pointer.
+1
IS_ERR_OR_NULL() should always be looked on with suspicion. Very
little should be returning some tri-state 'ERR' 'NULL' 'SUCCESS'
pointer. What does the middle condition even mean? IS_ERR_OR_NULL()
implies ERR and NULL are semanticly the same, so fix the things to
always use ERR.
If you want to improve things work to get rid of the NULL checks this
script identifies. Remove ERR or NULL because only one can ever
happen, or fix the source to consistently return ERR.
Jason
^ permalink raw reply
* Re: [PATCH] HID: appletb-kbd: add .resume method in PM
From: Jiri Kosina @ 2026-03-12 13:03 UTC (permalink / raw)
To: Aditya Garg; +Cc: Benjamin Tissoires, linux-input, linux-kernel, stable
In-Reply-To: <MAUPR01MB115468D46765D7DF8C2882B4CB86CA@MAUPR01MB11546.INDPRD01.PROD.OUTLOOK.COM>
On Tue, 17 Feb 2026, Aditya Garg wrote:
> Upon resuming from suspend, the Touch Bar driver was missing a resume
> method in order to restore the original mode the Touch Bar was on before
> suspending. It is the same as the reset_resume method.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Aditya Garg <gargaditya08@live.com>
Now in hid.git#for-7.0/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: mcp2221: Add module parameter to enfoce GPIO mode
From: Jiri Kosina @ 2026-03-12 13:05 UTC (permalink / raw)
To: Linus Walleij; +Cc: Rishi Gupta, Benjamin Tissoires, linux-input, linux-gpio
In-Reply-To: <20260218-hid-mcp2221-gpio-v1-1-a2ba53867354@kernel.org>
On Wed, 18 Feb 2026, Linus Walleij wrote:
> Add a module parameter to MCP2221 to enfor GPIO mode on the
> general purpose pins GP0 thru GP3.
>
> If I plug a device of this type into my machine, it will use the
> GP0, GP1, GP2 and GP3 pins for IIO voltage readings by default
> if CONFIG_IIO is set.
>
> However there may be cases where IIO is available but we want to
> use the GP0 thru GP3 lines for GPIO anyway.
>
> Example use:
>
> insmode hid-mcp2221.ko gpio_mode_enforce=1
>
> Result in dmesg:
> mcp2221 0003:04D8:00DD.0005: GPIO 0 not in gpio mode
> mcp2221 0003:04D8:00DD.0005: GPIO 1 not in gpio mode
> mcp2221 0003:04D8:00DD.0005: GPIO 2 not in gpio mode
> mcp2221 0003:04D8:00DD.0005: GPIO 3 not in gpio mode
> mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 0!
> mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 1!
> mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 2!
> mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 3!
>
> After this the gpiolib tools such as gpioset can be used to alter
> the GPIO line values successfully.
>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
Applied to hid.git#for-7.1/mcp2221, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCHv2] hid: hid-pl: eliminate private debug macro
From: Jiri Kosina @ 2026-03-12 13:21 UTC (permalink / raw)
To: Oliver Neukum; +Cc: bentiss, linux-input
In-Reply-To: <20260303084359.1206434-1-oneukum@suse.com>
On Tue, 3 Mar 2026, Oliver Neukum wrote:
> Use proper dynamic debugging.
>
> V2: use hid_dbg() instead of dev_dbg()
Please always put the 'vn -> vn+1' changelog below the '--- ' line so that
they don't end up in the final commit.
Now in hid.git#for-7.1/pl, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Rob Herring (Arm) @ 2026-03-12 14:00 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Krzysztof Kozlowski, linux-pm, Conor Dooley, Pavel Machek,
devicetree, Lee Jones, Ion Agorria, linux-leds, Dmitry Torokhov,
linux-input, Sebastian Reichel, Michał Mirosław,
linux-kernel
In-Reply-To: <20260304185751.83494-2-clamor95@gmail.com>
On Wed, 04 Mar 2026 20:57:45 +0200, Svyatoslav Ryhel wrote:
> Document embedded controller used in ASUS Transformer device series.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../asus,tf201-ec-pad.yaml | 119 ++++++++++++++++++
> 1 file changed, 119 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,tf201-ec-pad.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: input: add settling-time-us common property
From: Rob Herring @ 2026-03-12 15:02 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: robin, andy, geert, krzk+dt, conor+dt, dmitry.torokhov,
hvilleneuve, mkorpershoek, matthias.bgg,
angelogioacchino.delregno, lee, alexander.sverdlin, marek.vasut,
akurz, devicetree, linux-kernel, linux-input, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260305192101.2125660-3-hugo@hugovil.com>
On Thu, Mar 05, 2026 at 02:20:48PM -0500, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Add common property that can be reused by other bindings.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> Note: a similar property is used by gpio-matrix-keypad.yaml:
> col-scan-delay-us
> ---
> Documentation/devicetree/bindings/input/input.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/input.yaml b/Documentation/devicetree/bindings/input/input.yaml
> index 502e0b7eb500a..14652d324e2ca 100644
> --- a/Documentation/devicetree/bindings/input/input.yaml
> +++ b/Documentation/devicetree/bindings/input/input.yaml
> @@ -66,6 +66,14 @@ properties:
> reset automatically. Device with key pressed reset feature can specify
> this property.
>
> + settling-time-us:
> + description:
> + Delay, in microseconds, when activating an output line/col/row GPIO
> + before we can reliably read other input GPIOs that maybe affected by this
> + output. This can be the case for an output with a RC circuit that affects
> + ramp-up/down times.
Whether it is GPIOs or not depends on the implementation. Just drop
'GPIO' and replace 'GPIOs' with 'lines'.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Rob
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: input: add GPIO charlieplex keypad
From: Rob Herring (Arm) @ 2026-03-12 15:02 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: akurz, linux-mediatek, mkorpershoek, andy, devicetree,
alexander.sverdlin, dmitry.torokhov, linux-arm-kernel,
linux-kernel, krzk+dt, matthias.bgg, lee, robin, linux-input,
conor+dt, marek.vasut, hvilleneuve, geert,
angelogioacchino.delregno
In-Reply-To: <20260305192101.2125660-4-hugo@hugovil.com>
On Thu, 05 Mar 2026 14:20:49 -0500, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Add DT bindings for GPIO charlieplex keypad.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> .../input/gpio-charlieplex-keypad.yaml | 108 ++++++++++++++++++
> 1 file changed, 108 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: input: add debounce-delay-ms common property
From: Rob Herring (Arm) @ 2026-03-12 15:03 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: matthias.bgg, linux-kernel, akurz, linux-mediatek, geert, lee,
hvilleneuve, conor+dt, linux-input, angelogioacchino.delregno,
andy, robin, mkorpershoek, krzk+dt, alexander.sverdlin,
devicetree, dmitry.torokhov, marek.vasut, linux-arm-kernel
In-Reply-To: <20260305192101.2125660-2-hugo@hugovil.com>
On Thu, 05 Mar 2026 14:20:47 -0500, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> A few bindings are already defining a debounce-delay-ms property, so
> add it to the input binding to reduce redundant redefines.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> .../devicetree/bindings/auxdisplay/holtek,ht16k33.yaml | 5 ++---
> .../devicetree/bindings/input/cirrus,ep9307-keypad.yaml | 7 +++----
> .../devicetree/bindings/input/gpio-matrix-keypad.yaml | 5 ++---
> Documentation/devicetree/bindings/input/input.yaml | 8 ++++++++
> .../devicetree/bindings/input/mediatek,mt6779-keypad.yaml | 1 +
> Documentation/devicetree/bindings/mfd/fsl,mc13xxx.yaml | 2 --
> 6 files changed, 16 insertions(+), 12 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:04 UTC (permalink / raw)
To: Steven Rostedt, Peter Zijlstra, Dmitry Ilvokhin
Cc: Vineeth Pillai (Google), Masami Hiramatsu, Mathieu Desnoyers,
Ingo Molnar, Jens Axboe, io-uring, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
Marcelo Ricardo Leitner, Xin Long, Jon Maloy, Aaron Conole,
Eelco Chaudron, Ilya Maximets, netdev, bpf, linux-sctp,
tipc-discussion, dev, Oded Gabbay, Koby Elbaz, dri-devel,
Rafael J. Wysocki, Viresh Kumar, Gautham R. Shenoy, Huang Rui,
Mario Limonciello, Len Brown, Srinivas Pandruvada, linux-pm,
MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Christian König,
Sumit Semwal, linaro-mm-sig, Eddie James, Andrew Jeffery,
Joel Stanley, linux-fsi, David Airlie, Simona Vetter,
Alex Deucher, Danilo Krummrich, Matthew Brost, Philipp Stanner,
Harry Wentland, Leo Li, amd-gfx, Jiri Kosina, Benjamin Tissoires,
linux-input, Wolfram Sang, linux-i2c, Mark Brown,
Michael Hennerich, Nuno Sá, linux-spi, James E.J. Bottomley,
Martin K. Petersen, linux-scsi, Chris Mason, David Sterba,
linux-btrfs, linux-trace-kernel, linux-kernel
When a caller already guards a tracepoint with an explicit enabled check:
if (trace_foo_enabled() && cond)
trace_foo(args);
trace_foo() internally re-evaluates the static_branch_unlikely() key.
Since static branches are patched binary instructions the compiler cannot
fold the two evaluations, so every such site pays the cost twice.
This series introduces trace_invoke_##name() as a companion to
trace_##name(). It calls __do_trace_##name() directly, bypassing the
redundant static-branch re-check, while preserving all other correctness
properties of the normal path (RCU-watching assertion, might_fault() for
syscall tracepoints). The internal __do_trace_##name() symbol is not
leaked to call sites; trace_invoke_##name() is the only new public API.
if (trace_foo_enabled() && cond)
trace_invoke_foo(args); /* calls __do_trace_foo() directly */
The first patch adds the three-location change to
include/linux/tracepoint.h (__DECLARE_TRACE, __DECLARE_TRACE_SYSCALL,
and the !TRACEPOINTS_ENABLED stub). The remaining 14 patches
mechanically convert all guarded call sites found in the tree:
kernel/, io_uring/, net/, accel/habanalabs, cpufreq/, devfreq/,
dma-buf/, fsi/, drm/, HID, i2c/, spi/, scsi/ufs/, and btrfs/.
This series is motivated by Peter Zijlstra's observation in the discussion
around Dmitry Ilvokhin's locking tracepoint instrumentation series, where
he noted that compilers cannot optimize static branches and that guarded
call sites end up evaluating the static branch twice for no reason, and
by Steven Rostedt's suggestion to add a proper API instead of exposing
internal implementation details like __do_trace_##name() directly to
call sites:
https://lore.kernel.org/linux-trace-kernel/8298e098d3418cb446ef396f119edac58a3414e9.1772642407.git.d@ilvokhin.com
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Vineeth Pillai (Google) (15):
tracepoint: Add trace_invoke_##name() API
kernel: Use trace_invoke_##name() at guarded tracepoint call sites
io_uring: Use trace_invoke_##name() at guarded tracepoint call sites
net: Use trace_invoke_##name() at guarded tracepoint call sites
accel/habanalabs: Use trace_invoke_##name() at guarded tracepoint call
sites
cpufreq: Use trace_invoke_##name() at guarded tracepoint call sites
devfreq: Use trace_invoke_##name() at guarded tracepoint call sites
dma-buf: Use trace_invoke_##name() at guarded tracepoint call sites
fsi: Use trace_invoke_##name() at guarded tracepoint call sites
drm: Use trace_invoke_##name() at guarded tracepoint call sites
HID: Use trace_invoke_##name() at guarded tracepoint call sites
i2c: Use trace_invoke_##name() at guarded tracepoint call sites
spi: Use trace_invoke_##name() at guarded tracepoint call sites
scsi: ufs: Use trace_invoke_##name() at guarded tracepoint call sites
btrfs: Use trace_invoke_##name() at guarded tracepoint call sites
drivers/accel/habanalabs/common/device.c | 12 ++++++------
drivers/accel/habanalabs/common/mmu/mmu.c | 3 ++-
drivers/accel/habanalabs/common/pci/pci.c | 4 ++--
drivers/cpufreq/amd-pstate.c | 10 +++++-----
drivers/cpufreq/cpufreq.c | 2 +-
drivers/cpufreq/intel_pstate.c | 2 +-
drivers/devfreq/devfreq.c | 2 +-
drivers/dma-buf/dma-fence.c | 4 ++--
drivers/fsi/fsi-master-aspeed.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++--
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 4 ++--
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 2 +-
drivers/i2c/i2c-core-slave.c | 2 +-
drivers/spi/spi-axi-spi-engine.c | 4 ++--
drivers/ufs/core/ufshcd.c | 12 ++++++------
fs/btrfs/extent_map.c | 4 ++--
fs/btrfs/raid56.c | 4 ++--
include/linux/tracepoint.h | 11 +++++++++++
io_uring/io_uring.h | 2 +-
kernel/irq_work.c | 2 +-
kernel/sched/ext.c | 2 +-
kernel/smp.c | 2 +-
net/core/dev.c | 2 +-
net/core/xdp.c | 2 +-
net/openvswitch/actions.c | 2 +-
net/openvswitch/datapath.c | 2 +-
net/sctp/outqueue.c | 2 +-
net/tipc/node.c | 2 +-
30 files changed, 62 insertions(+), 50 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH 01/15] tracepoint: Add trace_invoke_##name() API
From: Vineeth Pillai (Google) @ 2026-03-12 15:04 UTC (permalink / raw)
To: Steven Rostedt, Peter Zijlstra, Dmitry Ilvokhin
Cc: Vineeth Pillai (Google), Masami Hiramatsu, Mathieu Desnoyers,
Ingo Molnar, Jens Axboe, io-uring, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
Marcelo Ricardo Leitner, Xin Long, Jon Maloy, Aaron Conole,
Eelco Chaudron, Ilya Maximets, netdev, bpf, linux-sctp,
tipc-discussion, dev, Oded Gabbay, Koby Elbaz, dri-devel,
Rafael J. Wysocki, Viresh Kumar, Gautham R. Shenoy, Huang Rui,
Mario Limonciello, Len Brown, Srinivas Pandruvada, linux-pm,
MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Christian König,
Sumit Semwal, linaro-mm-sig, Eddie James, Andrew Jeffery,
Joel Stanley, linux-fsi, David Airlie, Simona Vetter,
Alex Deucher, Danilo Krummrich, Matthew Brost, Philipp Stanner,
Harry Wentland, Leo Li, amd-gfx, Jiri Kosina, Benjamin Tissoires,
linux-input, Wolfram Sang, linux-i2c, Mark Brown,
Michael Hennerich, Nuno Sá, linux-spi, James E.J. Bottomley,
Martin K. Petersen, linux-scsi, Chris Mason, David Sterba,
linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Add trace_invoke_##name() as a companion to trace_##name(). When a
caller already guards a tracepoint with an explicit enabled check:
if (trace_foo_enabled() && cond)
trace_foo(args);
trace_foo() internally repeats the static_branch_unlikely() test, which
the compiler cannot fold since static branches are patched binary
instructions. This results in two static-branch evaluations for every
guarded call site.
trace_invoke_##name() calls __do_trace_##name() directly, skipping the
redundant static-branch re-check. This avoids leaking the internal
__do_trace_##name() symbol into call sites while still eliminating the
double evaluation:
if (trace_foo_enabled() && cond)
trace_invoke_foo(args); /* calls __do_trace_foo() directly */
Three locations are updated:
- __DECLARE_TRACE: invoke form omits static_branch_unlikely, retains
the LOCKDEP RCU-watching assertion.
- __DECLARE_TRACE_SYSCALL: same, plus retains might_fault().
- !TRACEPOINTS_ENABLED stub: empty no-op so callers compile cleanly
when tracepoints are compiled out.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
include/linux/tracepoint.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 22ca1c8b54f32..07219316a8e14 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -294,6 +294,10 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
WARN_ONCE(!rcu_is_watching(), \
"RCU not watching for tracepoint"); \
} \
+ } \
+ static inline void trace_invoke_##name(proto) \
+ { \
+ __do_trace_##name(args); \
}
#define __DECLARE_TRACE_SYSCALL(name, proto, args, data_proto) \
@@ -313,6 +317,11 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
WARN_ONCE(!rcu_is_watching(), \
"RCU not watching for tracepoint"); \
} \
+ } \
+ static inline void trace_invoke_##name(proto) \
+ { \
+ might_fault(); \
+ __do_trace_##name(args); \
}
/*
@@ -398,6 +407,8 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
#define __DECLARE_TRACE_COMMON(name, proto, args, data_proto) \
static inline void trace_##name(proto) \
{ } \
+ static inline void trace_invoke_##name(proto) \
+ { } \
static inline int \
register_trace_##name(void (*probe)(data_proto), \
void *data) \
--
2.53.0
^ permalink raw reply related
* [PATCH 11/15] HID: Use trace_invoke_##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:05 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Srinivas Pandruvada, Jiri Kosina, Benjamin Tissoires, Zhang Lixu,
Andy Shevchenko, linux-input, linux-kernel, linux-trace-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_invoke_foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_invoke_foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index ed3405c05e73c..01334a6599971 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -110,7 +110,7 @@ void ish_event_tracer(struct ishtp_device *dev, const char *format, ...)
vsnprintf(tmp_buf, sizeof(tmp_buf), format, args);
va_end(args);
- trace_ishtp_dump(tmp_buf);
+ trace_invoke_ishtp_dump(tmp_buf);
}
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Mathieu Desnoyers @ 2026-03-12 15:12 UTC (permalink / raw)
To: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Dmitry Ilvokhin
Cc: Masami Hiramatsu, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
On 2026-03-12 11:04, Vineeth Pillai (Google) wrote:
> When a caller already guards a tracepoint with an explicit enabled check:
>
> if (trace_foo_enabled() && cond)
> trace_foo(args);
>
> trace_foo() internally re-evaluates the static_branch_unlikely() key.
> Since static branches are patched binary instructions the compiler cannot
> fold the two evaluations, so every such site pays the cost twice.
>
> This series introduces trace_invoke_##name() as a companion to
> trace_##name(). It calls __do_trace_##name() directly, bypassing the
> redundant static-branch re-check, while preserving all other correctness
> properties of the normal path (RCU-watching assertion, might_fault() for
> syscall tracepoints). The internal __do_trace_##name() symbol is not
> leaked to call sites; trace_invoke_##name() is the only new public API.
>
> if (trace_foo_enabled() && cond)
> trace_invoke_foo(args); /* calls __do_trace_foo() directly */
FYI, we have a similar concept in LTTng-UST for userspace
instrumentation already:
if (lttng_ust_tracepoint_enabled(provider, name))
lttng_ust_do_tracepoint(provider, name, ...);
Perhaps it can provide some ideas about API naming.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [PATCH 01/15] tracepoint: Add trace_invoke_##name() API
From: Steven Rostedt @ 2026-03-12 15:12 UTC (permalink / raw)
To: Vineeth Pillai (Google)
Cc: Peter Zijlstra, Dmitry Ilvokhin, Masami Hiramatsu,
Mathieu Desnoyers, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <20260312150523.2054552-2-vineeth@bitbyteword.org>
On Thu, 12 Mar 2026 11:04:56 -0400
"Vineeth Pillai (Google)" <vineeth@bitbyteword.org> wrote:
> Add trace_invoke_##name() as a companion to trace_##name(). When a
> caller already guards a tracepoint with an explicit enabled check:
>
> if (trace_foo_enabled() && cond)
> trace_foo(args);
>
> trace_foo() internally repeats the static_branch_unlikely() test, which
> the compiler cannot fold since static branches are patched binary
> instructions. This results in two static-branch evaluations for every
> guarded call site.
>
> trace_invoke_##name() calls __do_trace_##name() directly, skipping the
> redundant static-branch re-check. This avoids leaking the internal
> __do_trace_##name() symbol into call sites while still eliminating the
> double evaluation:
>
> if (trace_foo_enabled() && cond)
> trace_invoke_foo(args); /* calls __do_trace_foo() directly */
>
> Three locations are updated:
> - __DECLARE_TRACE: invoke form omits static_branch_unlikely, retains
> the LOCKDEP RCU-watching assertion.
> - __DECLARE_TRACE_SYSCALL: same, plus retains might_fault().
> - !TRACEPOINTS_ENABLED stub: empty no-op so callers compile cleanly
> when tracepoints are compiled out.
>
> Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
> Assisted-by: Claude:claude-sonnet-4-6
I'm guessing Claude helped with the other patches. Did it really help with this one?
-- Steve
> ---
> include/linux/tracepoint.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 22ca1c8b54f32..07219316a8e14 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -294,6 +294,10 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> WARN_ONCE(!rcu_is_watching(), \
> "RCU not watching for tracepoint"); \
> } \
> + } \
> + static inline void trace_invoke_##name(proto) \
> + { \
> + __do_trace_##name(args); \
> }
>
> #define __DECLARE_TRACE_SYSCALL(name, proto, args, data_proto) \
> @@ -313,6 +317,11 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> WARN_ONCE(!rcu_is_watching(), \
> "RCU not watching for tracepoint"); \
> } \
> + } \
> + static inline void trace_invoke_##name(proto) \
> + { \
> + might_fault(); \
> + __do_trace_##name(args); \
> }
>
> /*
> @@ -398,6 +407,8 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> #define __DECLARE_TRACE_COMMON(name, proto, args, data_proto) \
> static inline void trace_##name(proto) \
> { } \
> + static inline void trace_invoke_##name(proto) \
> + { } \
> static inline int \
> register_trace_##name(void (*probe)(data_proto), \
> void *data) \
^ permalink raw reply
* Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Steven Rostedt @ 2026-03-12 15:23 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Vineeth Pillai (Google), Peter Zijlstra, Dmitry Ilvokhin,
Masami Hiramatsu, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <1e3c2830-765e-4271-89f7-0b6784b37597@efficios.com>
On Thu, 12 Mar 2026 11:12:41 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> > if (trace_foo_enabled() && cond)
> > trace_invoke_foo(args); /* calls __do_trace_foo() directly */
>
> FYI, we have a similar concept in LTTng-UST for userspace
> instrumentation already:
>
> if (lttng_ust_tracepoint_enabled(provider, name))
> lttng_ust_do_tracepoint(provider, name, ...);
>
> Perhaps it can provide some ideas about API naming.
I find the word "invoke" sounding more official than "do" ;-)
Note, Vineeth came up with the naming. I would have done "do" but when I
saw "invoke" I thought it sounded better.
-- Steve
^ 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