* Re: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
From: d3z @ 2026-06-01 21:30 UTC (permalink / raw)
To: even.xu, xinpeng.sun, jikos, bentiss
Cc: Danny D ., linux-input, linux-kernel, abhishektamboli9,
sakari.ailus
In-Reply-To: <IA1PR11MB60985B856D77963E2DBE47F9F4152@IA1PR11MB6098.namprd11.prod.outlook.com>
From: Danny D. <d3z.the.dev@gmail.com>
Hi Even,
Thanks for the quick reply and for sharing your patch.
First, the missing piece from your mail: my name is Danny D.
(d3z.the.dev@gmail.com) - please use it for any
Signed-off-by/Reported-by/Tested-by.
One note on the starting assumption, though: in its current configuration
this Surface Pro 10 doesn't go to S3 at all. /sys/power/mem_sleep only
offers s2idle:
$ cat /sys/power/mem_sleep
[s2idle]
There's no "deep" entry to select here, so every suspend goes through
s2idle and never reaches PM_SUSPEND_MEM. The touch IC still loses power
across that s2idle suspend - the same as over hibernation - which is what
gives the "recv failed: -11" on resume.
That's the catch with the attached patch: it gates the THC reconfigure on
if (last_suspend_state == PM_SUSPEND_MEM)
i.e. S3 only. On this machine that branch never runs, so it wouldn't bring
the touchscreen back here. Happy to apply it and confirm on the device, but
from the code path alone it can't help while we're s2idle-only.
What I did instead was key off whether the device actually kept power
rather than the suspend type: run the full reset only when the device isn't
a wake source (device_may_wakeup() == false), mirroring quickspi_restore().
A wake-enabled device stays on the light path so wake-on-touch is preserved;
one that lost power goes through reset_tic() re-enumeration. That fires on
both s2idle and S3, which is what makes it work on the SP10.
I've tested this on the Surface Pro 10 across many s2idle suspend/resume
cycles - touch and pen both keep working - and just posted a v2 that adds
the device_may_wakeup() gate.
Could we converge on the wakeup-based condition? I'm glad to test any
revision of your patch on the hardware, and equally glad for you to carry
the fix with my Signed-off-by/Tested-by once it handles the s2idle case.
Thanks,
Danny
^ permalink raw reply
* [PATCH v2] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
From: d3z @ 2026-06-01 21:18 UTC (permalink / raw)
To: even.xu, jikos, bentiss
Cc: xinpeng.sun, linux-input, linux-kernel, sakari.ailus,
abhishektamboli9, Danny D .
In-Reply-To: <20260529222210.1532876-1-d3z.the.dev@gmail.com>
From: Danny D. <d3z.the.dev@gmail.com>
On the Surface Pro 10 (Meteor Lake) the touchscreen stops working after a
suspend/resume cycle and only recovers after a reboot. The driver logs
"GET_DEVICE_INFO: recv failed: -11" on resume.
This platform suspends through s2idle: /sys/power/mem_sleep exposes
"[s2idle]" as the only state, there is no "deep"/S3 entry at all. The
touch IC nonetheless loses power across that s2idle suspend, the same
way it does across hibernation. quickspi_resume() only re-selects the
THC port, restores interrupts and DMA and sends a HIDSPI_ON command,
assuming the touch IC kept its power and state. When it has actually
lost power the HIDSPI_ON command is never acknowledged and the
descriptor read fails, leaving the touchscreen dead until the module is
reloaded.
quickspi_restore() already handles this for hibernation by
reconfiguring the THC SPI/LTR settings and running reset_tic() to
re-enumerate the device. Make quickspi_resume() do the same when the
device is not a wake source. A wake-enabled device keeps its power and
state across suspend, so it stays on the light restore path: resetting
it would discard a pending wake touch event and break wake-on-touch.
The non-wake path mirrors the existing quickspi_restore() sequence,
including enabling interrupts before reset_tic(), so it introduces no
new ordering relative to code already in the driver.
This change has been validated on a Surface Pro 10 running the
linux-surface kernel across multiple s2idle suspend/resume cycles; it
has not been tested on a mainline build.
Closes: https://github.com/linux-surface/linux-surface/issues/1799
Signed-off-by: Danny D. <d3z.the.dev@gmail.com>
---
v1 -> v2:
- Only run the full reset when the device is not a wake source
(device_may_wakeup()), so wake-on-touch is no longer disturbed.
- Reword the changelog around s2idle: the SP10 has no "deep"/S3 state, the
touch IC loses power across s2idle.
.../hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 60 +++++++++++++++++--
1 file changed, 56 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
--- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
@@ -784,20 +784,72 @@ static int quickspi_resume(struct device
if (ret)
return ret;
+ /*
+ * A wake-enabled device keeps its power and state across suspend, so
+ * only restore the THC context. Resetting it here would discard a
+ * pending wake touch event and break wake-on-touch.
+ */
+ if (device_may_wakeup(qsdev->dev)) {
+ thc_interrupt_config(qsdev->thc_hw);
+
+ thc_interrupt_enable(qsdev->thc_hw, true);
+
+ ret = thc_dma_configure(qsdev->thc_hw);
+ if (ret)
+ return ret;
+
+ return thc_interrupt_quiesce(qsdev->thc_hw, false);
+ }
+
+ /*
+ * Otherwise the touch IC may have lost power across suspend. On
+ * platforms that suspend through s2idle (for example the Surface Pro
+ * 10, whose firmware exposes s2idle as the only mem_sleep state) the
+ * IC loses power the same way it does across hibernation. A plain
+ * HIDSPI_ON is then not acknowledged and the descriptor read fails, so
+ * re-enumerate the device through the full reset flow already used by
+ * quickspi_restore().
+ */
+ thc_spi_input_output_address_config(qsdev->thc_hw,
+ qsdev->input_report_hdr_addr,
+ qsdev->input_report_bdy_addr,
+ qsdev->output_report_addr);
+
+ ret = thc_spi_read_config(qsdev->thc_hw, qsdev->spi_freq_val,
+ qsdev->spi_read_io_mode,
+ qsdev->spi_read_opcode,
+ qsdev->spi_packet_size);
+ if (ret)
+ return ret;
+
+ ret = thc_spi_write_config(qsdev->thc_hw, qsdev->spi_freq_val,
+ qsdev->spi_write_io_mode,
+ qsdev->spi_write_opcode,
+ qsdev->spi_packet_size,
+ qsdev->performance_limit);
+ if (ret)
+ return ret;
+
thc_interrupt_config(qsdev->thc_hw);
thc_interrupt_enable(qsdev->thc_hw, true);
- ret = thc_dma_configure(qsdev->thc_hw);
+ /* The touch IC may have lost power, reset it to recover */
+ ret = reset_tic(qsdev);
if (ret)
return ret;
- ret = thc_interrupt_quiesce(qsdev->thc_hw, false);
+ ret = thc_dma_configure(qsdev->thc_hw);
if (ret)
return ret;
- if (!device_may_wakeup(qsdev->dev))
- return quickspi_set_power(qsdev, HIDSPI_ON);
+ thc_ltr_config(qsdev->thc_hw,
+ qsdev->active_ltr_val,
+ qsdev->low_power_ltr_val);
+
+ thc_change_ltr_mode(qsdev->thc_hw, THC_LTR_MODE_ACTIVE);
+
+ qsdev->state = QUICKSPI_ENABLED;
return 0;
}
--
2.43.0
^ permalink raw reply
* Re: [PATCH v14 1/2] HID: cp2112: Add fwnode support
From: Andy Shevchenko @ 2026-06-01 19:18 UTC (permalink / raw)
To: Danny Kaehn
Cc: Benjamin Tissoires, Andi Shyti, Conor Dooley, Jiri Kosina,
linux-input, Dmitry Torokhov, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen,
Bartosz Golaszewski
In-Reply-To: <20260520-cp2112-dt-v14-1-b1b4b6734b6f@plexus.com>
On Wed, May 20, 2026 at 11:13:06AM -0500, Danny Kaehn wrote:
> Support describing the CP2112's I2C and GPIO interfaces in firmware.
>
> Bindings between the firmware nodes and the functions of the device
> are distinct between ACPI and DeviceTree.
>
> For ACPI, the i2c_adapter will use the child with _ADR equal to Zero
> and the gpio_chip will use the child with _ADR equal to One.
>
> For DeviceTree, the i2c_adapter will use the child with name "i2c",
> but the gpio_chip will share a firmware node with the CP2112.
As we seems settled on the approaches in both cases, I think we are fine
to go
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 3/3] HID: i2c-hid-of: Fall back to ACPI _DSM when hid-descr-addr is missing
From: sashiko-bot @ 2026-06-01 18:47 UTC (permalink / raw)
Cc: linux-input, dmitry.torokhov
In-Reply-To: <tencent_0EE402E968E17B8EACEDFF0E9EBDDBF17E09@qq.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The i2c-hid-of driver uses the ACPI _DSM fallback to obtain the HID descriptor address but does not provide a restore_sequence callback to re-evaluate the _DSM during hibernation (S4) restore.
--
commit 3ebee1e22f96c1e99e3c6adbd49d92242f2497f9
Author: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
HID: i2c-hid-of: Fall back to ACPI _DSM when hid-descr-addr is missing
This commit updates the i2c-hid-of driver to fall back to the ACPI _DSM
method for obtaining the HID descriptor address when the "hid-descr-addr"
property is missing. It specifically targets devices using the "PRP0001"
_HID with a "hid-over-i2c" compatible string. Safe default power and reset
delays are also configured for these devices.
> diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c b/drivers/hid/i2c-hid/i2c-hid-of.c
> index 57379b77e9778..e925e2d2cfe0d 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-of.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-of.c
> @@ -92,6 +92,36 @@ static int i2c_hid_of_probe(struct i2c_client *client)
> ihid_of->ops.power_down = i2c_hid_of_power_down;
>
> ret = device_property_read_u32(dev, "hid-descr-addr", &val);
> + if (ret) {
> + /*
> + * Some devices, for example the Lenovo KaiTian N60d and Inspur
> + * CP300L3, declare their I2C HID touchpad with _HID "PRP0001"
> + * and _DSD compatible "hid-over-i2c" but lack the
> + * "hid-descr-addr" property. Fall back to _DSM to obtain the
> + * HID descriptor address.
> + */
> + int dsm_ret = i2c_hid_core_acpi_get_descriptor(dev);
[Severity: High]
Does this missing PM callback break S4 hibernation restore?
The native i2c-hid-acpi driver re-evaluates the _DSM method during hibernation
restore via its restore_sequence callback to reinitialize the hardware state,
such as switching the hardware back from PS/2 emulation to I2C-HID mode.
Because this ACPI _DSM fallback is added in i2c_hid_of_probe() without also
wiring up ops.restore_sequence in the OF driver, will these touchpads fail
to resume correctly and become unresponsive after waking from S4?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260601181510.38705-1-Yeking@Red54.com?part=3
^ permalink raw reply
* Re: [PATCH v2 3/4] regulator: Add driver for MediaTek MT6328 PMIC regulators
From: Mark Brown @ 2026-06-01 18:41 UTC (permalink / raw)
To: y.oudjana
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Flora Fu, Alexandre Mergnat,
Liam Girdwood, Dmitry Torokhov, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-input
In-Reply-To: <20260531-mt6735-pwrap-mt6328-pmic-v2-3-dac37bf92894@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]
On Sun, May 31, 2026 at 11:10:44AM +0200, Yassine Oudjana via B4 Relay wrote:
> @@ -0,0 +1,500 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MediaTek MT6328 regulator driver
> + * Based on MT6323 driver.
> + *
> + * Copyright (c) 2016 MediaTek Inc.
> + * Copyright (c) 2022 Yassine Oudjana <y.oudjana@protonmail.com>
> + */
Please make the entire comment a C++ one so things look more
intentional.
> +static const unsigned int ldo_volt_table3[] = {
> + 0, 0, 0, 1800000, 1900000, 2000000, 2100000, 2200000
> +};
Use linear_min_sel for the first three values.
> +static const struct linear_range ldo_volt_range1[] = {
> + REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250)
> +};
If there's just one range there's no need for a lookup table, use
regulator_map_voltage_linar().
> +static int mt6328_get_status(struct regulator_dev *rdev)
> +{
> + int ret;
> + u32 regval;
> + struct mt6328_regulator_info *info = rdev_get_drvdata(rdev);
> +
> + ret = regmap_read(rdev->regmap, info->desc.enable_reg, ®val);
> + if (ret != 0) {
> + dev_err(&rdev->dev, "Failed to get enable reg: %d\n", ret);
> + return ret;
> + }
> +
> + return (regval & info->qi) ? REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
> +}
get_status() should report the actual status of the regulator, not what
was configured. If the device can't report this just omit the
operation.
> + if (mt6328_regulators[i].vselctrl_reg) {
> + if (regmap_read(mt6328->regmap,
> + mt6328_regulators[i].vselctrl_reg,
> + ®val) < 0) {
> + dev_err(&pdev->dev,
> + "Failed to read buck ctrl\n");
> + return -EIO;
Better to return the actual error.
> + rdev = devm_regulator_register(&pdev->dev,
> + &mt6328_regulators[i].desc, &config);
> + if (IS_ERR(rdev)) {
> + dev_err(&pdev->dev, "failed to register %s\n",
> + mt6328_regulators[i].desc.name);
> + return PTR_ERR(rdev);
dev_err_probe().
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 02/10] [v3] input: gpio-keys: make legacy gpiolib optional
From: Arnd Bergmann @ 2026-06-01 18:32 UTC (permalink / raw)
To: sashiko-reviews; +Cc: linux-input, Dmitry Torokhov, Hans de Goede, Jin Yao
In-Reply-To: <20260530004519.1C8E81F00893@smtp.kernel.org>
On Sat, May 30, 2026, at 02:45, sashiko-bot@kernel.org wrote:
> [Severity: High]
> Does this change break legacy devices that legitimately provide both a valid
> GPIO and a valid IRQ?
>
> If a legacy platform provides both a valid GPIO and an IRQ, this condition
> now evaluates to false.
>
> By skipping the GPIO request entirely, the driver falls back to treating the
> device as a pure IRQ button. This forces the driver to lose hardware
> debouncing and rely on a simulated release timer instead of checking the
> physical GPIO line.
There are only three drivers that provide the ->irq field. Two are the
ones that I'm changing in this patch, the soc_button_array driver
is the third and none of them set ->irq and ->gpio at the same time.
>> */
>> struct gpio_keys_button {
>> unsigned int code;
>> +#ifdef CONFIG_GPIOLIB_LEGACY
>> int gpio;
>> +#endif
>> int active_low;
>
> [Severity: Medium]
> Will this cause build failures for drivers that assign to this field when
> CONFIG_GPIOLIB_LEGACY is disabled?
Yes, that is the intention of the patch: nothing should set the
->gpio field unless GPIOLIB_LEGACY is set.
> Other modern drivers dynamically create the platform device and pass legacy
> GPIO numbers by directly assigning to this field:
>
> drivers/input/misc/soc_button_array.c:soc_button_device_create() {
> ...
> gpio_keys[n_buttons].gpio = gpio;
> ...
> }
>
> When CONFIG_GPIOLIB_LEGACY is disabled, this results in a compilation failure
> since struct gpio_keys_button no longer has the gpio member.
I previously included a patch force-enable GPIOLIB_LEGACY in this
patch series, see
https://lore.kernel.org/all/npijagtgyad33xxlq46b7kwzydhcgt5tkgd5ihsjl6t4czbqyf@umovipwh73i2/
I made a mistake during a rebase, so my older patch was still
included in my randconfig testing but not in the series I
sent. All the other changes in it are now redundant, bit
the soc_button_array portion indeed still remains.
Hans, Dmitry, do you already have plans to deal with the
soc_button_array driver to move it away from legacy GPIOs?
So far I can see four possible ways we can deal with it,
but none that I actually like:
a) delay the problem, apply my original oneline change
to 'select GPIOLIB_LEGACY' and fix it later, so we
can make GPIOLIB_LEGACY default-disabled in 7.3.
b) add a gpiod member to struct gpio_keys_button and skip
the intermediate gpio number here. Clean it up later.
c) always pass the gpio as an interrupt, as the driver
already does for some machines
d) add dynamic device properties that duplicate the
information from ACPI/DMI, so the driver can
stop using platform data
e) disconnect gpio_keys_button from gpio-keys.c and
register the buttons to the input subsystem
directly from soc_button_device_create().
Any suggestions?
Arnd
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: remove excess kernel-doc member in hidpp_scroll_counter
From: Benjamin Tissoires @ 2026-06-01 18:20 UTC (permalink / raw)
To: linux-input, Rosen Penev
Cc: Filipe Laíns, Bastien Nocera, Jiri Kosina, Hans de Goede,
linux-kernel
In-Reply-To: <20260531000150.378695-1-rosenp@gmail.com>
On Sat, 30 May 2026 17:01:50 -0700, Rosen Penev wrote:
> The @dev member described in the kernel-doc does not exist in the
> struct. Remove the stale entry.
>
> Fixes: 0610430e3dea ("HID: logitech-hidpp: add input_device ptr to struct
> hidpp_device")
> Assisted-by: opencode:big-pickle
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-7.2/logitech), thanks!
[1/1] HID: logitech-hidpp: remove excess kernel-doc member in hidpp_scroll_counter
https://git.kernel.org/hid/hid/c/f22a5db8a7d3
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] HID: wacom: fix sleeping in atomic context in wacom_wac_queue_flush()
From: Benjamin Tissoires @ 2026-06-01 18:19 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, Jinmo Yang
Cc: jikos, stable, Benjamin Tissoires
In-Reply-To: <20260601134124.1560886-1-jinmo44.yang@gmail.com>
On Mon, 01 Jun 2026 22:41:22 +0900, Jinmo Yang wrote:
> wacom_wac_queue_flush() uses GFP_KERNEL for kzalloc, but it can be
> called from atomic context via the .raw_event callback path. Patch 1
> fixes this by switching to GFP_ATOMIC, and patch 2 converts the buffer
> management to use __free(kfree) cleanup as suggested by Dmitry.
>
> Changes since v1:
> - Replaced Suggested-by with Reported-by for Sashiko-bot
> - Added patch 2 to use __free(kfree) cleanup facility (Dmitry)
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-7.2/wacom), thanks!
[1/2] HID: wacom: use GFP_ATOMIC in wacom_wac_queue_flush()
https://git.kernel.org/hid/hid/c/55f1ad573e34
[2/2] HID: wacom: use cleanup.h for wacom_wac_queue_flush() buffer management
https://git.kernel.org/hid/hid/c/cb605d48dac9
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/1] HID: wacom: fix slab-out-of-bounds write in kfifo_copy_in
From: Benjamin Tissoires @ 2026-06-01 18:19 UTC (permalink / raw)
To: Jason Gerecke, Ping Cheng, Jinmo Yang
Cc: Jiri Kosina, linux-input, linux-kernel, stable
In-Reply-To: <20260524135203.1996265-1-jinmo44.yang@gmail.com>
On Sun, 24 May 2026 22:52:02 +0900, Jinmo Yang wrote:
> I found the following slab-out-of-bounds write in the wacom HID driver
> while fuzzing with syzkaller on v7.1.0-rc4-next-20260522:
>
> BUG: KASAN: slab-out-of-bounds in kfifo_copy_in+0xf3/0x130 lib/kfifo.c:106
> Write of size 3842 at addr ffff888009179000 by task syz.3.9362/61135
>
> CPU: 1 UID: 0 PID: 61135 Comm: syz.3.9362 Not tainted 7.1.0-rc4-next-20260522-dirty #3 PREEMPT(lazy)
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0x97/0xe0 lib/dump_stack.c:120
> print_address_description mm/kasan/report.c:378 [inline]
> print_report+0x157/0x4c9 mm/kasan/report.c:482
> kasan_report+0xce/0x100 mm/kasan/report.c:595
> check_region_inline mm/kasan/generic.c:186 [inline]
> kasan_check_range+0x10f/0x1e0 mm/kasan/generic.c:200
> __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106
> kfifo_copy_in+0xf3/0x130 lib/kfifo.c:106
> __kfifo_in_r lib/kfifo.c:442 [inline]
> __kfifo_in_r+0x1b2/0x230 lib/kfifo.c:434
> wacom_wac_queue_insert drivers/hid/wacom_sys.c:65 [inline]
> wacom_wac_pen_serial_enforce drivers/hid/wacom_sys.c:165 [inline]
> wacom_raw_event+0x900/0xa90 drivers/hid/wacom_sys.c:179
> __hid_input_report.constprop.0+0x39a/0x4d0 drivers/hid/hid-core.c:2161
> uhid_dev_input2 drivers/hid/uhid.c:618 [inline]
> uhid_char_write+0xa8a/0xfa0 drivers/hid/uhid.c:776
> vfs_write+0x2c0/0xe40 fs/read_write.c:686
> ksys_write+0x1f8/0x250 fs/read_write.c:740
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0xee/0x590 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-7.2/wacom), thanks!
[1/1] HID: wacom: fix slab-out-of-bounds write in wacom_wac_queue_insert
https://git.kernel.org/hid/hid/c/6b3014ec0e9a
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/2] Add support for Microsoft Surface Pro 12in
From: Benjamin Tissoires @ 2026-06-01 18:18 UTC (permalink / raw)
To: linux-kernel, linux-input, linux-arm-msm, devicetree,
Harrison Vanderbyl
Cc: jikos, andersson, konradybcio, robh, krzk+dt, conor+dt,
dmitry.baryshkov
In-Reply-To: <20260529011619.9586-1-harrison.vanderbyl@gmail.com>
On Fri, 29 May 2026 11:16:14 +1000, Harrison Vanderbyl wrote:
> Changes in v3:
>
> Rebase:
> - Rebased on next-20260528
> - Removed ice device tree changes
>
> Device tree:
> - Fixed C++ style comment in &i2c9 to use /* */ style
> - Flattened mdss_dp3 port into &mdss_dp3_out directly
> - Whitespace and formatting nits
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-7.2/core), thanks!
[1/2] hid: Pen battery quirk for Surface Pro 12in
https://git.kernel.org/hid/hid/c/3a1e4e77e3ee
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 00/11] HID: storing pointers in 'hid_device_id::driver_data'
From: Benjamin Tissoires @ 2026-06-01 18:18 UTC (permalink / raw)
To: Jiri Kosina, Ping Cheng, Jason Gerecke,
Pawel Zalewski (The Capable Hub)
Cc: linux-kernel, linux-input, Christian A. Ehrhardt,
Christian A. Ehrhardt
In-Reply-To: <20260518-mod-devicetable-hid_device_id-v1-0-a08e3989c283@thegoodpenguin.co.uk>
On Mon, 18 May 2026 17:06:19 +0100, Pawel Zalewski (The Capable Hub) wrote:
> The <linux/mod_devicetable.h> has multiple structs that follow
> the pattern of having either 'driver_data' or 'driver_info'
> fields which are of the 'kernel_ulong_t' type. Then how to
> interpret that field is user defined, some users will treat
> the value as an actual integer, others as a valid pointer to
> dereference.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-7.2/cleanup_driver_data), thanks!
[05/11] HID: hid-belkin: clean up usage of 'driver_data'
https://git.kernel.org/hid/hid/c/4de4b8a5ddc2
[06/11] HID: hid-cypress: clean up usage of 'driver_data'
https://git.kernel.org/hid/hid/c/73e784ddf895
[07/11] HID: hid-gfrm: clean up usage of 'driver_data'
https://git.kernel.org/hid/hid/c/0b8bb8c3c913
[08/11] HID: hid-ite: clean up usage of 'driver_data'
https://git.kernel.org/hid/hid/c/b11dfa6cc3c8
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* [PATCH v2 3/3] HID: i2c-hid-of: Fall back to ACPI _DSM when hid-descr-addr is missing
From: 谢致邦 (XIE Zhibang) @ 2026-06-01 18:15 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov
Cc: Yeking, bentiss, dianders, jikos, linux-kernel, superm1,
谢致邦 (XIE Zhibang), Pin-yen Lin, Xu Rao,
Kwok Kin Ming, Dan Carpenter
In-Reply-To: <20260601181510.38705-1-Yeking@Red54.com>
Before commit b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are
separate modules"), the unified i2c-hid driver handled both PNP0C50 ACPI
devices and hid-over-i2c OF devices. After the split, devices with _HID
"PRP0001" and _DSD compatible "hid-over-i2c" are only probed by
i2c_hid_of, which requires "hid-descr-addr" in the _DSD. Some devices,
for example the Lenovo KaiTian N60d and Inspur CP300L3, provide the HID
descriptor address only through the _DSM method. Call the common
i2c_hid_core_acpi_get_descriptor() helper as a fallback, and set safe
post-power-on and post-reset-deassert delays.
Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
drivers/hid/i2c-hid/i2c-hid-of.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c b/drivers/hid/i2c-hid/i2c-hid-of.c
index 57379b77e977..e925e2d2cfe0 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of.c
@@ -92,6 +92,36 @@ static int i2c_hid_of_probe(struct i2c_client *client)
ihid_of->ops.power_down = i2c_hid_of_power_down;
ret = device_property_read_u32(dev, "hid-descr-addr", &val);
+ if (ret) {
+ /*
+ * Some devices, for example the Lenovo KaiTian N60d and Inspur
+ * CP300L3, declare their I2C HID touchpad with _HID "PRP0001"
+ * and _DSD compatible "hid-over-i2c" but lack the
+ * "hid-descr-addr" property. Fall back to _DSM to obtain the
+ * HID descriptor address.
+ */
+ int dsm_ret = i2c_hid_core_acpi_get_descriptor(dev);
+
+ if (dsm_ret >= 0) {
+ dev_warn(dev,
+ "hid-descr-addr NOT found, using _DSM fallback. Contact vendor for firmware update!\n");
+ val = dsm_ret;
+
+ /*
+ * Firmware providing the descriptor address only
+ * through _DSM may also lack "post-power-on-delay-ms"
+ * or "post-reset-deassert-delay-ms", leaving the
+ * driver without enough delay before the first HID
+ * descriptor read. Set safe defaults to avoid reading
+ * the descriptor before the device has finished its
+ * internal power-on reset.
+ */
+ ihid_of->post_power_delay_ms = 250;
+ ihid_of->post_reset_delay_ms = 250;
+
+ ret = 0;
+ }
+ }
if (ret) {
dev_err(dev, "HID register address not provided\n");
return -ENODEV;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/3] HID: i2c-hid: Move common ACPI _DSM helper into core
From: 谢致邦 (XIE Zhibang) @ 2026-06-01 18:15 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov
Cc: Yeking, bentiss, dianders, jikos, linux-kernel, superm1,
谢致邦 (XIE Zhibang), Pin-yen Lin, Xu Rao,
Kwok Kin Ming, Dan Carpenter
In-Reply-To: <20260601181510.38705-1-Yeking@Red54.com>
Move the _DSM call that gets the HID descriptor address from
i2c-hid-acpi.c to a shared helper in i2c-hid-core.c so both
i2c-hid-acpi.c and i2c-hid-of.c can use it.
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
drivers/hid/i2c-hid/i2c-hid-acpi.c | 32 ++++-----------------------
drivers/hid/i2c-hid/i2c-hid-core.c | 35 ++++++++++++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid.h | 11 ++++++++++
3 files changed, 50 insertions(+), 28 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index f65fb6396b69..234789a07047 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -25,12 +25,12 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pm.h>
-#include <linux/uuid.h>
#include "i2c-hid.h"
struct i2c_hid_acpi {
struct i2chid_ops ops;
+ struct i2c_client *client;
struct acpi_device *adev;
};
@@ -48,36 +48,11 @@ static const struct acpi_device_id i2c_hid_acpi_blacklist[] = {
{ }
};
-/* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
-static guid_t i2c_hid_guid =
- GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
- 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
-
-static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
-{
- struct acpi_device *adev = ihid_acpi->adev;
- acpi_handle handle = acpi_device_handle(adev);
- union acpi_object *obj;
- u16 hid_descriptor_address;
-
- obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
- ACPI_TYPE_INTEGER);
- if (!obj) {
- acpi_handle_err(handle, "Error _DSM call to get HID descriptor address failed\n");
- return -ENODEV;
- }
-
- hid_descriptor_address = obj->integer.value;
- ACPI_FREE(obj);
-
- return hid_descriptor_address;
-}
-
static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
{
struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
- i2c_hid_acpi_get_descriptor(ihid_acpi);
+ i2c_hid_core_acpi_get_descriptor(&ihid_acpi->client->dev);
}
static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
@@ -102,11 +77,12 @@ static int i2c_hid_acpi_probe(struct i2c_client *client)
if (!ihid_acpi)
return -ENOMEM;
+ ihid_acpi->client = client;
ihid_acpi->adev = adev;
ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
- ret = i2c_hid_acpi_get_descriptor(ihid_acpi);
+ ret = i2c_hid_core_acpi_get_descriptor(dev);
if (ret < 0)
return ret;
hid_descriptor_address = ret;
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 3adb16366e93..1e1a8df5686d 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -1405,6 +1405,41 @@ const struct dev_pm_ops i2c_hid_core_pm = {
};
EXPORT_SYMBOL_GPL(i2c_hid_core_pm);
+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+
+/* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
+static guid_t i2c_hid_guid =
+ GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
+ 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
+
+int i2c_hid_core_acpi_get_descriptor(struct device *dev)
+{
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+ acpi_handle handle;
+ union acpi_object *obj;
+ u16 hid_descriptor_address;
+
+ if (!adev)
+ return -ENODEV;
+
+ handle = acpi_device_handle(adev);
+ obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
+ ACPI_TYPE_INTEGER);
+ if (!obj) {
+ acpi_handle_err(handle,
+ "Error _DSM call to get HID descriptor address failed\n");
+ return -ENODEV;
+ }
+
+ hid_descriptor_address = obj->integer.value;
+ ACPI_FREE(obj);
+
+ return hid_descriptor_address;
+}
+EXPORT_SYMBOL_GPL(i2c_hid_core_acpi_get_descriptor);
+#endif
+
MODULE_DESCRIPTION("HID over I2C core driver");
MODULE_AUTHOR("Benjamin Tissoires <benjamin.tissoires@gmail.com>");
MODULE_LICENSE("GPL");
diff --git a/drivers/hid/i2c-hid/i2c-hid.h b/drivers/hid/i2c-hid/i2c-hid.h
index 1724a435c783..bc8661c65b1a 100644
--- a/drivers/hid/i2c-hid/i2c-hid.h
+++ b/drivers/hid/i2c-hid/i2c-hid.h
@@ -44,4 +44,15 @@ void i2c_hid_core_shutdown(struct i2c_client *client);
extern const struct dev_pm_ops i2c_hid_core_pm;
+#ifdef CONFIG_ACPI
+struct device;
+int i2c_hid_core_acpi_get_descriptor(struct device *dev);
+#else
+struct device;
+static inline int i2c_hid_core_acpi_get_descriptor(struct device *dev)
+{
+ return -ENODEV;
+}
+#endif
+
#endif
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/3] HID: i2c-hid-acpi: Move blacklist check to probe() before devm_kzalloc()
From: 谢致邦 (XIE Zhibang) @ 2026-06-01 18:15 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov
Cc: Yeking, bentiss, dianders, jikos, linux-kernel, superm1,
谢致邦 (XIE Zhibang), Pin-yen Lin, Xu Rao,
Kwok Kin Ming, Dan Carpenter
In-Reply-To: <20260601181510.38705-1-Yeking@Red54.com>
Move the check so the function can return early without wasting an
allocation. This is a pure refactoring, no functional change.
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
v2: Merge declaration into assignment.
drivers/hid/i2c-hid/i2c-hid-acpi.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index abd700a101f4..f65fb6396b69 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -60,9 +60,6 @@ static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
union acpi_object *obj;
u16 hid_descriptor_address;
- if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
- return -ENODEV;
-
obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
ACPI_TYPE_INTEGER);
if (!obj) {
@@ -93,15 +90,19 @@ static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
static int i2c_hid_acpi_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
+ struct acpi_device *adev = ACPI_COMPANION(dev);
struct i2c_hid_acpi *ihid_acpi;
u16 hid_descriptor_address;
int ret;
+ if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
+ return -ENODEV;
+
ihid_acpi = devm_kzalloc(&client->dev, sizeof(*ihid_acpi), GFP_KERNEL);
if (!ihid_acpi)
return -ENOMEM;
- ihid_acpi->adev = ACPI_COMPANION(dev);
+ ihid_acpi->adev = adev;
ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v1] HID: i2c-hid-of: Use named initializers for struct i2c_device_id
From: Benjamin Tissoires @ 2026-06-01 18:15 UTC (permalink / raw)
To: Jiri Kosina, Uwe Kleine-König (The Capable Hub)
Cc: linux-input, linux-kernel
In-Reply-To: <20260519160420.1597193-2-u.kleine-koenig@baylibre.com>
On Tue, 19 May 2026 18:04:20 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
>
> This patch doesn't modify the compiled array, only its representation in
> source form benefits. The former was confirmed with x86 and arm64
> builds.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-7.2/i2c-hid), thanks!
[1/1] HID: i2c-hid-of: Use named initializers for struct i2c_device_id
https://git.kernel.org/hid/hid/c/eda0f9e57087
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* [PATCH v2 0/3] HID: i2c-hid: Fix some PRP0001 touchpads probe after OF/ACPI split
From: 谢致邦 (XIE Zhibang) @ 2026-06-01 18:15 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov
Cc: Yeking, bentiss, dianders, jikos, linux-kernel, superm1,
谢致邦 (XIE Zhibang), Pin-yen Lin, Xu Rao,
Kwok Kin Ming, Dan Carpenter
In-Reply-To: <ahnqMMhD8jn51ch7@google.com>
Before commit b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are
separate modules"), the unified i2c-hid driver handled both PNP0C50 ACPI
devices and hid-over-i2c OF devices. After the split, devices with _HID
"PRP0001" and _DSD compatible "hid-over-i2c" are only probed by
i2c_hid_of, which requires "hid-descr-addr" in the _DSD. Some devices,
for example the Lenovo KaiTian N60d and Inspur CP300L3, provide the HID
descriptor address only through the _DSM method and thus fail to probe.
Patch 1 moves the blacklist check so the function can return early
without wasting an allocation.
Patch 2 moves the _DSM call that gets the HID descriptor address from
i2c-hid-acpi.c to a shared helper in i2c-hid-core.c so both
i2c-hid-acpi.c and i2c-hid-of.c can use it.
Patch 3 calls the common helper as a fallback when "hid-descr-addr" is
missing, and sets safe post-power-on and post-reset-deassert delays.
谢致邦 (XIE Zhibang) (3):
HID: i2c-hid-acpi: Move blacklist check to probe() before
devm_kzalloc()
HID: i2c-hid: Move common ACPI _DSM helper into core
HID: i2c-hid-of: Fall back to ACPI _DSM when hid-descr-addr is missing
drivers/hid/i2c-hid/i2c-hid-acpi.c | 41 +++++++-----------------------
drivers/hid/i2c-hid/i2c-hid-core.c | 35 +++++++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid-of.c | 30 ++++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid.h | 11 ++++++++
4 files changed, 85 insertions(+), 32 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2] HID: wiimote: Fix table layout and whitespace errors
From: Benjamin Tissoires @ 2026-06-01 18:15 UTC (permalink / raw)
To: David Rheinsberg, Jiri Kosina, Bogdan Petru, Joshua Jun,
J. Neuschäfer
Cc: linux-input, linux-kernel
In-Reply-To: <20260326-wiimod-table-v2-1-a11703ccdf41@posteo.net>
On Thu, 26 Mar 2026 15:03:48 +0100, J. Neuschäfer wrote:
> Some tab characters snuck into the data layout table for turntable
> extensions, which resulted in the table only looking right at a tabstop
> of 4, which is uncommon in the kernel. Change them to the equivalent
> amount of spaces, which should look correct in any editor.
>
> While at it, also fix the other whitespace errors (trailing spaces at
> end of line) introduced in the same commit.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-7.2/wiimote), thanks!
[1/1] HID: wiimote: Fix table layout and whitespace errors
https://git.kernel.org/hid/hid/c/12b7731995ca
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* [PATCH 3/3] HID: i2c-hid-of: Fall back to ACPI _DSM when hid-descr-addr is missing
From: 谢致邦 (XIE Zhibang) @ 2026-06-01 17:37 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov
Cc: Yeking, bentiss, dianders, jikos, linux-kernel, superm1,
谢致邦 (XIE Zhibang), Pin-yen Lin, Xu Rao,
Kwok Kin Ming, Dan Carpenter
In-Reply-To: <20260601173722.38151-1-Yeking@Red54.com>
Before commit b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are
separate modules"), the unified i2c-hid driver handled both PNP0C50 ACPI
devices and hid-over-i2c OF devices. After the split, devices with _HID
"PRP0001" and _DSD compatible "hid-over-i2c" are only probed by
i2c_hid_of, which requires "hid-descr-addr" in the _DSD. Some devices,
for example the Lenovo KaiTian N60d and Inspur CP300L3, provide the HID
descriptor address only through the _DSM method. Call the common
i2c_hid_core_acpi_get_descriptor() helper as a fallback, and set safe
post-power-on and post-reset-deassert delays.
Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
drivers/hid/i2c-hid/i2c-hid-of.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c b/drivers/hid/i2c-hid/i2c-hid-of.c
index 57379b77e977..e925e2d2cfe0 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of.c
@@ -92,6 +92,36 @@ static int i2c_hid_of_probe(struct i2c_client *client)
ihid_of->ops.power_down = i2c_hid_of_power_down;
ret = device_property_read_u32(dev, "hid-descr-addr", &val);
+ if (ret) {
+ /*
+ * Some devices, for example the Lenovo KaiTian N60d and Inspur
+ * CP300L3, declare their I2C HID touchpad with _HID "PRP0001"
+ * and _DSD compatible "hid-over-i2c" but lack the
+ * "hid-descr-addr" property. Fall back to _DSM to obtain the
+ * HID descriptor address.
+ */
+ int dsm_ret = i2c_hid_core_acpi_get_descriptor(dev);
+
+ if (dsm_ret >= 0) {
+ dev_warn(dev,
+ "hid-descr-addr NOT found, using _DSM fallback. Contact vendor for firmware update!\n");
+ val = dsm_ret;
+
+ /*
+ * Firmware providing the descriptor address only
+ * through _DSM may also lack "post-power-on-delay-ms"
+ * or "post-reset-deassert-delay-ms", leaving the
+ * driver without enough delay before the first HID
+ * descriptor read. Set safe defaults to avoid reading
+ * the descriptor before the device has finished its
+ * internal power-on reset.
+ */
+ ihid_of->post_power_delay_ms = 250;
+ ihid_of->post_reset_delay_ms = 250;
+
+ ret = 0;
+ }
+ }
if (ret) {
dev_err(dev, "HID register address not provided\n");
return -ENODEV;
--
2.54.0
^ permalink raw reply related
* [PATCH 2/3] HID: i2c-hid: Move common ACPI _DSM helper into core
From: 谢致邦 (XIE Zhibang) @ 2026-06-01 17:37 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov
Cc: Yeking, bentiss, dianders, jikos, linux-kernel, superm1,
谢致邦 (XIE Zhibang), Pin-yen Lin, Xu Rao,
Kwok Kin Ming, Dan Carpenter
In-Reply-To: <20260601173722.38151-1-Yeking@Red54.com>
Move the _DSM call that gets the HID descriptor address from
i2c-hid-acpi.c to a shared helper in i2c-hid-core.c so both
i2c-hid-acpi.c and i2c-hid-of.c can use it.
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
drivers/hid/i2c-hid/i2c-hid-acpi.c | 32 ++++-----------------------
drivers/hid/i2c-hid/i2c-hid-core.c | 35 ++++++++++++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid.h | 11 ++++++++++
3 files changed, 50 insertions(+), 28 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index acfe0fb9e99a..bd888134f4cd 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -25,12 +25,12 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pm.h>
-#include <linux/uuid.h>
#include "i2c-hid.h"
struct i2c_hid_acpi {
struct i2chid_ops ops;
+ struct i2c_client *client;
struct acpi_device *adev;
};
@@ -48,36 +48,11 @@ static const struct acpi_device_id i2c_hid_acpi_blacklist[] = {
{ }
};
-/* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
-static guid_t i2c_hid_guid =
- GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
- 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
-
-static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
-{
- struct acpi_device *adev = ihid_acpi->adev;
- acpi_handle handle = acpi_device_handle(adev);
- union acpi_object *obj;
- u16 hid_descriptor_address;
-
- obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
- ACPI_TYPE_INTEGER);
- if (!obj) {
- acpi_handle_err(handle, "Error _DSM call to get HID descriptor address failed\n");
- return -ENODEV;
- }
-
- hid_descriptor_address = obj->integer.value;
- ACPI_FREE(obj);
-
- return hid_descriptor_address;
-}
-
static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
{
struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
- i2c_hid_acpi_get_descriptor(ihid_acpi);
+ i2c_hid_core_acpi_get_descriptor(&ihid_acpi->client->dev);
}
static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
@@ -103,11 +78,12 @@ static int i2c_hid_acpi_probe(struct i2c_client *client)
if (!ihid_acpi)
return -ENOMEM;
+ ihid_acpi->client = client;
ihid_acpi->adev = adev;
ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
- ret = i2c_hid_acpi_get_descriptor(ihid_acpi);
+ ret = i2c_hid_core_acpi_get_descriptor(dev);
if (ret < 0)
return ret;
hid_descriptor_address = ret;
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 3adb16366e93..1e1a8df5686d 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -1405,6 +1405,41 @@ const struct dev_pm_ops i2c_hid_core_pm = {
};
EXPORT_SYMBOL_GPL(i2c_hid_core_pm);
+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+
+/* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
+static guid_t i2c_hid_guid =
+ GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
+ 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
+
+int i2c_hid_core_acpi_get_descriptor(struct device *dev)
+{
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+ acpi_handle handle;
+ union acpi_object *obj;
+ u16 hid_descriptor_address;
+
+ if (!adev)
+ return -ENODEV;
+
+ handle = acpi_device_handle(adev);
+ obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
+ ACPI_TYPE_INTEGER);
+ if (!obj) {
+ acpi_handle_err(handle,
+ "Error _DSM call to get HID descriptor address failed\n");
+ return -ENODEV;
+ }
+
+ hid_descriptor_address = obj->integer.value;
+ ACPI_FREE(obj);
+
+ return hid_descriptor_address;
+}
+EXPORT_SYMBOL_GPL(i2c_hid_core_acpi_get_descriptor);
+#endif
+
MODULE_DESCRIPTION("HID over I2C core driver");
MODULE_AUTHOR("Benjamin Tissoires <benjamin.tissoires@gmail.com>");
MODULE_LICENSE("GPL");
diff --git a/drivers/hid/i2c-hid/i2c-hid.h b/drivers/hid/i2c-hid/i2c-hid.h
index 1724a435c783..bc8661c65b1a 100644
--- a/drivers/hid/i2c-hid/i2c-hid.h
+++ b/drivers/hid/i2c-hid/i2c-hid.h
@@ -44,4 +44,15 @@ void i2c_hid_core_shutdown(struct i2c_client *client);
extern const struct dev_pm_ops i2c_hid_core_pm;
+#ifdef CONFIG_ACPI
+struct device;
+int i2c_hid_core_acpi_get_descriptor(struct device *dev);
+#else
+struct device;
+static inline int i2c_hid_core_acpi_get_descriptor(struct device *dev)
+{
+ return -ENODEV;
+}
+#endif
+
#endif
--
2.54.0
^ permalink raw reply related
* [PATCH 1/3] HID: i2c-hid-acpi: Move blacklist check to probe() before devm_kzalloc()
From: 谢致邦 (XIE Zhibang) @ 2026-06-01 17:37 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov
Cc: Yeking, bentiss, dianders, jikos, linux-kernel, superm1,
谢致邦 (XIE Zhibang), Pin-yen Lin, Xu Rao,
Kwok Kin Ming, Dan Carpenter
In-Reply-To: <20260601173722.38151-1-Yeking@Red54.com>
Move the check so the function can return early without wasting an
allocation. This is a pure refactoring, no functional change.
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
drivers/hid/i2c-hid/i2c-hid-acpi.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index abd700a101f4..acfe0fb9e99a 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -60,9 +60,6 @@ static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
union acpi_object *obj;
u16 hid_descriptor_address;
- if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
- return -ENODEV;
-
obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
ACPI_TYPE_INTEGER);
if (!obj) {
@@ -93,15 +90,20 @@ static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
static int i2c_hid_acpi_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
+ struct acpi_device *adev;
struct i2c_hid_acpi *ihid_acpi;
u16 hid_descriptor_address;
int ret;
+ adev = ACPI_COMPANION(dev);
+ if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
+ return -ENODEV;
+
ihid_acpi = devm_kzalloc(&client->dev, sizeof(*ihid_acpi), GFP_KERNEL);
if (!ihid_acpi)
return -ENOMEM;
- ihid_acpi->adev = ACPI_COMPANION(dev);
+ ihid_acpi->adev = adev;
ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
--
2.54.0
^ permalink raw reply related
* [PATCH 0/3] HID: i2c-hid: Fix some PRP0001 touchpads probe after OF/ACPI split
From: 谢致邦 (XIE Zhibang) @ 2026-06-01 17:37 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov
Cc: Yeking, bentiss, dianders, jikos, linux-kernel, superm1,
谢致邦 (XIE Zhibang), Pin-yen Lin, Xu Rao,
Kwok Kin Ming, Dan Carpenter
In-Reply-To: <ahnqMMhD8jn51ch7@google.com>
Before commit b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are
separate modules"), the unified i2c-hid driver handled both PNP0C50 ACPI
devices and hid-over-i2c OF devices. After the split, devices with _HID
"PRP0001" and _DSD compatible "hid-over-i2c" are only probed by
i2c_hid_of, which requires "hid-descr-addr" in the _DSD. Some devices,
for example the Lenovo KaiTian N60d and Inspur CP300L3, provide the HID
descriptor address only through the _DSM method and thus fail to probe.
Patch 1 moves the blacklist check so the function can return early
without wasting an allocation.
Patch 2 moves the _DSM call that gets the HID descriptor address from
i2c-hid-acpi.c to a shared helper in i2c-hid-core.c so both
i2c-hid-acpi.c and i2c-hid-of.c can use it.
Patch 3 calls the common helper as a fallback when "hid-descr-addr" is
missing, and sets safe post-power-on and post-reset-deassert delays.
谢致邦 (XIE Zhibang) (3):
HID: i2c-hid-acpi: Move blacklist check to probe() before
devm_kzalloc()
HID: i2c-hid: Move common ACPI _DSM helper into core
HID: i2c-hid-of: Fall back to ACPI _DSM when hid-descr-addr is missing
drivers/hid/i2c-hid/i2c-hid-acpi.c | 42 +++++++-----------------------
drivers/hid/i2c-hid/i2c-hid-core.c | 35 +++++++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid-of.c | 30 +++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid.h | 11 ++++++++
4 files changed, 86 insertions(+), 32 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 1/4] HID: multitouch: set INPUT_PROP_PRESSUREPAD based on Digitizer/Button Type
From: Rong Zhang @ 2026-06-01 17:25 UTC (permalink / raw)
To: devnull+peter.hutterer.who-t.net
Cc: bentiss, dmitry.torokhov, jikos, linux-input, linux-kernel,
linux-kselftest, peter.hutterer, shuah, vadim
In-Reply-To: <20251222-wip-hid-pressurepad-v2-1-054ac9689bb7@who-t.net>
Hi all,
Hopefully I'm not too late to show up here.
> From: Peter Hutterer <peter.hutterer@who-t.net>
>
> A Digitizer/Button Type value of 1 indicates the device is a
> pressurepad, see
> https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection#device-capabilities-feature-report
>
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> ---
> drivers/hid/hid-multitouch.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 179dc316b4b518d78bdc900d9fd15756c5eba83e..382e6f50c4f7e663af7d028abb8be7cb2e6e7b8e 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -81,6 +81,7 @@ MODULE_LICENSE("GPL");
> #define MT_INPUTMODE_TOUCHPAD 0x03
>
> #define MT_BUTTONTYPE_CLICKPAD 0
> +#define MT_BUTTONTYPE_PRESSUREPAD 1
>
> enum latency_mode {
> HID_LATENCY_NORMAL = 0,
> @@ -179,6 +180,7 @@ struct mt_device {
> __u8 inputmode_value; /* InputMode HID feature value */
> __u8 maxcontacts;
> bool is_buttonpad; /* is this device a button pad? */
> + bool is_pressurepad; /* is this device a pressurepad? */
> bool is_haptic_touchpad; /* is this device a haptic touchpad? */
> bool serial_maybe; /* need to check for serial protocol */
>
> @@ -530,8 +532,14 @@ static void mt_feature_mapping(struct hid_device *hdev,
> }
>
> mt_get_feature(hdev, field->report);
> - if (field->value[usage->usage_index] == MT_BUTTONTYPE_CLICKPAD)
> + switch (field->value[usage->usage_index]) {
> + case MT_BUTTONTYPE_CLICKPAD:
> td->is_buttonpad = true;
> + break;
> + case MT_BUTTONTYPE_PRESSUREPAD:
> + td->is_pressurepad = true;
> + break;
> + }
>
> break;
> case 0xff0000c5:
> @@ -1393,6 +1401,8 @@ static int mt_touch_input_configured(struct hid_device *hdev,
>
> if (td->is_buttonpad)
> __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
> + if (td->is_pressurepad)
> + __set_bit(INPUT_PROP_PRESSUREPAD, input->propbit);
I noticed that this leads to dual reporting on my device.
Consider previous checks:
if (application == HID_DG_TOUCHPAD) {
mt_application->mt_flags |= INPUT_MT_POINTER;
td->inputmode_value = MT_INPUTMODE_TOUCHPAD;
}
...
/* check for clickpads */
if ((app->mt_flags & INPUT_MT_POINTER) &&
(app->buttons_count == 1))
td->is_buttonpad = true;
... where `td->is_buttonpad' is set to true when a pressure pad has only
one button, i.e., the "touchpad button integrated with digitizer" [1].
Most (if not all) pressure pads fall into this category. As a result,
the presence of INPUT_PROP_PRESSUREPAD is always accompanied by the
presence of INPUT_PROP_BUTTONPAD.
Since the corresponding testcase neither expects dual reporting nor
prohibits it, I am confused of the intended properties to expose. Is it
a mistake or an intended behavior? If it's the former, I am going to
submit a patch to fix it.
[1]: https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-buttons-report-level-usages
Thanks,
Rong
>
> app->pending_palm_slots = devm_kcalloc(&hi->input->dev,
> BITS_TO_LONGS(td->maxcontacts),
>
> --
> 2.51.1
>
^ permalink raw reply
* Re: [bug report] Potential atomicity bug in drivers/input/joydev.c, between joydev_0x_read() and joydev_ioctl_common()
From: Dmitry Torokhov @ 2026-06-01 17:22 UTC (permalink / raw)
To: Ginger; +Cc: linux-input
In-Reply-To: <CAGp+u1YARE-sqwuNtbpG7E4TO-Nt1KQEeWiHn6pjoLz5kmt8HQ@mail.gmail.com>
Hi Ginger,
On Mon, Jun 01, 2026 at 03:07:05PM +0800, Ginger wrote:
> Dear Linux kernel maintainers,
>
> My research-based static analyzer found a potential atomicity bug
> within the 'drivers/input' subsystem, more specifically, in
> 'drivers/input/joydev.c'.
>
> This potential issue is present as of git commit
> eb3f4b7426cfd2b79d65b7d37155480b32259a11 of the mainline kernel.
>
> Potential concurrent triggering executions:
> T0:
> joydev_0x_read
> --> spin_lock_irq(&input->event_lock);
> --> read from joydev->abs
> --> spin_unlock_irq(&input->event_lock);
>
> T1:
> joydev_ioctl_common
> --> case JSIOCSCORR:
> --> write to joydev->abs[i] (no unlocked)
>
> The above trace is meant to demonstrate an illustrative example of the issue:
> IMHO, in 'joydev_0x_read', the 'input->event_lock' is adopted to
> serialize the read
> accesses to joydev's fields like 'abs' and 'keypam' or input's fields
> like 'input->key.
> However, in either case, the write-side accesses to these fields are
> not similarly
> serialized.
Yes, there is lack of locking in joydev. Some of this might be OK (if
we prevent tearing on reads/writes) since the data may actually be
obsolete immediately after we read it, while in many places we
actually do need consistency, especially when we adjust key and axis
maps.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 01/10] [v2] [net-next] net: dsa: b53: hide legacy gpiolib usage on non-mips
From: Arnd Bergmann @ 2026-06-01 16:50 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Dmitry Torokhov, linux-input
In-Reply-To: <20260530004519.A9BAB1F00898@smtp.kernel.org>
On Sat, May 30, 2026, at 02:45, sashiko-bot@kernel.org wrote:
>
> [Severity: High]
> Does this silently ignore probe errors like -EPROBE_DEFER?
>
> Previously, if devm_gpio_request_one failed, the error was returned to the
> caller. Now, b53_switch_get_reset_gpio handles the request and returns an
> ERR_PTR on failure, but that error pointer is simply stored in dev->reset_gpio
> while b53_switch_init unconditionally returns 0.
>
> Later in the code, b53_switch_reset_gpio relies on IS_ERR(dev->reset_gpio)
> to gracefully return, which would silently skip the reset sequence entirely
> if the GPIO controller simply isn't ready yet (-EPROBE_DEFER) or if there
> was a memory allocation failure (-ENOMEM).
The driver already ignored errors previously on BCM47xx. and
I can see that -EPROBE_DEFER cannot happen because the gpio
driver is very simplistic and always built-in.
I've updated the patch to propagate -EPROBE_DEFER anway as that
is clearly the correct thing to do in case it ever gets used extended
to other platforms. All other errors continue to be ignored to
keep the current behavior of the driver.
Arnd
^ permalink raw reply
* Re: [PATCH v4 00/36] HID: iio: basic clean up and introduce devm_ API for HID sensors
From: srinivas pandruvada @ 2026-06-01 15:55 UTC (permalink / raw)
To: Jonathan Cameron, Sanjay Chitroda
Cc: jikos, dlechner, nuno.sa, andy, sakari.ailus, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260526165639.42d6e98e@jic23-huawei>
On Tue, 2026-05-26 at 16:56 +0100, Jonathan Cameron wrote:
> On Mon, 25 May 2026 00:50:23 +0530
> Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:
>
> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> >
> > Key highlights:
> > - 0000-0024: General cleanup and kernel few coding style fixes
> > across HID IIO drivers
> > - 0025: Remove unused iio_dev argument from HID IIO sensor helper
> > - 0026: Introduce devm_hid_sensor_setup_trigger() device-managed
> > API
> > - 0027-0036: Convert HID IIO sensor drivers to use the new devm-
> > based trigger setup
> >
> > changes in v4:
> > - Extend the series to cover remaining HID IIO drivers with devm
> > API usage
> > - Reorder patches to place cleanup and warning fix at beginning
> > and,
> > devm-related changes toward the end based on feedback from David
> > - v3 series ->
> > https://lore.kernel.org/all/20260509101040.791404-1-sanjayembedded@gmail.com/
> > changes in v3:
> > - Added cleanup and prepratory changes before adding devm_ API
> > conversion based on self review: 0002, 0004, 0006, 0007 and 0008
> > - Address andy's review comment on commit message and coding style
> > - v2 series ->
> > https://lore.kernel.org/all/20260429175918.2541914-1-sanjayembedded@gmail.com/
> > changes in v2:
> > - Following input from Jonathan and Andy, squash initial patch v1
> > series in single change as individual change should not break
> > anything
> > - Add devm API support and two driver using the same
> > - v1 series ->
> > https://lore.kernel.org/all/20260428071613.1134053-1-sanjayembedded@gmail.com/
> >
> > Testing:
> > - Compiled with W=1 for each patch in series
> > - Build-tested on QEMU x86_64
> >
> > P.S.
> > - Sashiko reported an issue in a different driver and noted that it
> > is not
> > introduced by this series. I have taken this feedback into
> > account and
> > will address the actual issue in a separate series focus on that
> > driver.
> > - Once this series is merged into the IIO tree, a number of HID IIO
> > drivers will become available to fully converted to devm API
> > usage.
> > - The changes are organized across drivers to keep similar
> > modifications
> > grouped together for consistency, making the series easier to
> > review,
> > rather than grouping all changes per driver.
> >
> The series is mostly fine, though not sure what happened with how you
> sent
> it as I have it in seperate threads of 10 patches at a time. If you
> are having
> email troubles with big series, use b4 to send them instead
> (instructions on kernel.org)
>
> My main concern is this is a lot of churn on a critical driver. I'd
> like therefore
> to be able to see the full benefit of those devm patches rather than
> get us
> part way as this does.
>
I am not able to apply this patchset cleanly on 7.1-rc6. This series
does formatting changes, u32 changes and devm changes. Atleast three
different series will be better.
Thanks,
Srinivas
> Jonathan
>
> > Thanks,
> > Sanjay Chitroda
> >
> > Sanjay Chitroda (36):
> > iio: hid-sensors: add missing blank line after declarations
> > iio: gyro: hid-sensor-gyro-3d: use u32 instead of unsigned
> > iio: accel: hid-sensor-accel-3d: use u32 instead of unsigned
> > iio: light: hid-sensor-als: use u32 instead of unsigned
> > iio: light: hid-sensor-prox: use u32 instead of unsigned
> > iio: orientation: hid-sensor-incl-3d: use u32 instead of unsigned
> > iio: orientation: hid-sensor-rotation: use u32 instead of
> > unsigned
> > iio: pressure: hid-sensor-press: use u32 instead of unsigned
> > iio: humidity: hid-sensor-humidity: align parenthesis for
> > readability
> > iio: gyro: hid-sensor-gyro-3d: align parenthesis for readability
> > iio: magnetometer: hid-sensor-magn-3d: align parenthesis for
> > readability
> > iio: humidity: hid-sensor-humidity: use common device for devres
> > iio: position: hid-sensor-custom-intel-hinge: use common device
> > for
> > devres
> > iio: temperature: hid-sensor-temperature: use common device for
> > devres
> > iio: humidity: hid-sensor-humidity: use local struct device
> > iio: gyro: hid-sensor-gyro-3d: use local struct device
> > iio: accel: hid-sensor-accel-3d: use local struct device
> > iio: light: hid-sensor-als: use local struct device
> > iio: light: hid-sensor-prox: use local struct device
> > iio: magnetometer: hid-sensor-magn-3d: use local struct device
> > iio: orientation: hid-sensor-incl-3d: use local struct device
> > iio: orientation: hid-sensor-rotation: use local struct device
> > iio: position: hid-sensor-custom-intel-hinge: use local struct
> > device
> > iio: pressure: hid-sensor-press: use local struct device
> > iio: hid-sensors: remove unused iio_dev argument
> > iio: hid-sensors: introduce device managed API
> > iio: gyro: hid-sensor-gyro-3d: drop hid_sensor_remove_trigger()
> > using
> > devm API
> > iio: humidity: hid-sensor-humidity: drop
> > hid_sensor_remove_trigger()
> > using devm API
> > iio: light: hid-sensor-prox: drop hid_sensor_remove_trigger()
> > using
> > devm API
> > iio: light: hid-sensor-als: drop hid_sensor_remove_trigger()
> > using
> > devm API
> > iio: magnetometer: hid-sensor-magn-3d: drop
> > hid_sensor_remove_trigger() using devm API
> > iio: orientation: hid-sensor-incl-3d: drop
> > hid_sensor_remove_trigger()
> > using devm API
> > iio: orientation: hid-sensor-rotation: drop
> > hid_sensor_remove_trigger() using devm API
> > iio: position: hid-sensor-custom-intel-hinge: drop
> > hid_sensor_remove_trigger() using devm API
> > iio: pressure: hid-sensor-press: drop hid_sensor_remove_trigger()
> > using devm API
> > iio: temperature: hid-sensor-temperature: drop
> > hid_sensor_remove_trigger() using devm API
> >
> > drivers/iio/accel/hid-sensor-accel-3d.c | 30 ++---
> > .../common/hid-sensors/hid-sensor-trigger.c | 24 +++-
> > .../common/hid-sensors/hid-sensor-trigger.h | 5 +-
> > drivers/iio/gyro/hid-sensor-gyro-3d.c | 96 ++++++++------
> > -
> > drivers/iio/humidity/hid-sensor-humidity.c | 61 +++++-----
> > drivers/iio/light/hid-sensor-als.c | 31 +++--
> > drivers/iio/light/hid-sensor-prox.c | 30 ++---
> > drivers/iio/magnetometer/hid-sensor-magn-3d.c | 112 +++++++++-----
> > ----
> > drivers/iio/orientation/hid-sensor-incl-3d.c | 36 +++---
> > drivers/iio/orientation/hid-sensor-rotation.c | 38 +++---
> > .../position/hid-sensor-custom-intel-hinge.c | 27 ++---
> > drivers/iio/pressure/hid-sensor-press.c | 36 +++---
> > .../iio/temperature/hid-sensor-temperature.c | 15 +--
> > 13 files changed, 264 insertions(+), 277 deletions(-)
> >
> >
> > base-commit: 08297ca8422541dde6c8b7e6b1d68bd4aa4568ef
^ 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