* Re: [PATCH 05/22] sound: remove sh-specific sounds/soc/sh drivers
From: Kuninori Morimoto @ 2023-01-17 22:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Yoshinori Sato, Rich Felker, Arnd Bergmann, Greg Kroah-Hartman,
Laurent Pinchart, Kieran Bingham, Geert Uytterhoeven,
linux-kernel, linux-watchdog, devicetree, linux-arch, dmaengine,
dri-devel, linux-renesas-soc, linux-i2c, linux-input, linux-media,
linux-mmc, linux-mtd, netdev, linux-gpio, linux-rtc, linux-spi,
linux-serial, linux-usb, linux-fbdev, alsa-devel, linux-sh
In-Reply-To: <20230113062339.1909087-6-hch@lst.de>
Hi Christoph
>
> Now that arch/sh is removed these drivers are dead code.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
(snip)
> sound/soc/sh/fsi.c | 9 -
(snip)
> config SND_SOC_SH4_FSI
> tristate "SH4 FSI support"
> depends on COMMON_CLK
You can remove sound/soc/sh/fsi.c
It is for SH SoC.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: remove arch/sh
From: Geert Uytterhoeven @ 2023-01-17 20:26 UTC (permalink / raw)
To: Rob Landley
Cc: Christoph Hellwig, John Paul Adrian Glaubitz, Yoshinori Sato,
Rich Felker, Arnd Bergmann, Greg Kroah-Hartman, Laurent Pinchart,
Kieran Bingham, Geert Uytterhoeven, linux-kernel, linux-watchdog,
devicetree, linux-arch, dmaengine, dri-devel, linux-renesas-soc,
linux-i2c, linux-input, linux-media, linux-mmc, linux-mtd, netdev,
linux-gpio, linux-rtc, linux-spi, linux-serial, linux-usb,
linux-fbdev, alsa-devel, linux-sh
In-Reply-To: <9325a949-8d19-435a-50bd-9ebe0a432012@landley.net>
Hi Rob,
On Tue, Jan 17, 2023 at 8:01 PM Rob Landley <rob@landley.net> wrote:
> On 1/16/23 01:13, Christoph Hellwig wrote:
> > On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote:
> >> I'm still maintaining and using this port in Debian.
> >>
> >> It's a bit disappointing that people keep hammering on it. It works fine for me.
> >
> > What platforms do you (or your users) use it on?
>
> 3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), and an
> sh4 emulator.
>
> I have multiple j-core systems (sh2 compatible with extensions, nommu, 3
> different kinds of boards running it here). There's an existing mmu version of
> j-core that's sh3 flavored but they want to redo it so it hasn't been publicly
> released yet, I have yet to get that to run Linux because the mmu code would
> need adapting, but the most recent customer projects were on the existing nommu
> SOC, as was last year's ASIC work via sky130.
J4 still vaporware?
> My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the
> little blue one is... sh4a I think? (It can run the same userspace, I haven't
> replaced that board's kernel since I got it, I think it's the type Glaubitz is
> using? It's mostly in case he had an issue I couldn't reproduce on different
> hardware, or if I spill something on my N40.)
>
> I also have a physical sh2 board on the shelf which I haven't touched in years
> (used to comparison test during j2 development, and then the j2 boards replaced it).
>
> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's
> really convenient: neither of my physical boards boot from SD card so replacing
> the kernel requires reflashing soldered in flash. (They'll net mount userspace
> but I haven't gotten either bootloader to net-boot a kernel.)
On my landisk (with boots from CompactFLASH), I boot the original 2.6.22
kernel, and use kexec to boot-test each and every renesas-drivers
release. Note that this requires both the original 2.6.22 kernel
and matching kexec-tools. Apparently both upstreamed kernel and
kexec-tools support for SH are different, and incompatible with each
other, so you cannot kexec from a contemporary kernel.
I tried working my way up from 2.6.22, but gave up around 2.6.29.
Probably I should do this with r2d and qemu instead ;-)
Both r2d and landisk are SH7751.
Probably SH7722/'23'24 (e.g. Migo-R and Ecovec boards) are also
worth keeping. Most on-SoC blocks have drivers with DT support,
as they are shared with ARM. So the hardest part is clock and
interrupt-controller support.
Unfortunately I no longer have access to the (remote) Migo-R.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: remove arch/sh
From: Rob Landley @ 2023-01-17 19:13 UTC (permalink / raw)
To: Christoph Hellwig, John Paul Adrian Glaubitz
Cc: Yoshinori Sato, Rich Felker, Arnd Bergmann, Greg Kroah-Hartman,
Laurent Pinchart, Kieran Bingham, Geert Uytterhoeven,
linux-kernel, linux-watchdog, devicetree, linux-arch, dmaengine,
dri-devel, linux-renesas-soc, linux-i2c, linux-input, linux-media,
linux-mmc, linux-mtd, netdev, linux-gpio, linux-rtc, linux-spi,
linux-serial, linux-usb, linux-fbdev, alsa-devel, linux-sh
In-Reply-To: <20230116071306.GA15848@lst.de>
On 1/16/23 01:13, Christoph Hellwig wrote:
> On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote:
>> I'm still maintaining and using this port in Debian.
>>
>> It's a bit disappointing that people keep hammering on it. It works fine for me.
>
> What platforms do you (or your users) use it on?
3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), and an
sh4 emulator.
I have multiple j-core systems (sh2 compatible with extensions, nommu, 3
different kinds of boards running it here). There's an existing mmu version of
j-core that's sh3 flavored but they want to redo it so it hasn't been publicly
released yet, I have yet to get that to run Linux because the mmu code would
need adapting, but the most recent customer projects were on the existing nommu
SOC, as was last year's ASIC work via sky130.
My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the
little blue one is... sh4a I think? (It can run the same userspace, I haven't
replaced that board's kernel since I got it, I think it's the type Glaubitz is
using? It's mostly in case he had an issue I couldn't reproduce on different
hardware, or if I spill something on my N40.)
I also have a physical sh2 board on the shelf which I haven't touched in years
(used to comparison test during j2 development, and then the j2 boards replaced it).
I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's
really convenient: neither of my physical boards boot from SD card so replacing
the kernel requires reflashing soldered in flash. (They'll net mount userspace
but I haven't gotten either bootloader to net-boot a kernel.)
I include sh4 in the my mkroot builds each toybox release, I have a ~300 line
bash script that builds bootable toybox systems for a dozen-ish architectures,
including building a kernel configured to run under qemu:
https://github.com/landley/toybox/blob/master/scripts/mkroot.sh
And I ship the resulting bootable system images, most recent release is at:
https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/
As described at:
http://landley.net/toybox/faq.html#mkroot
Various people in Japan have more hardware, but I haven't made it physically
back there since 2020. (My residency card expired during the pandemic.)
Rob
^ permalink raw reply
* Re: [PATCH] hid: stop drivers from selecting CONFIG_HID
From: Greg Kroah-Hartman @ 2023-01-17 17:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Basavaraj Natikar, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, Arnd Bergmann, Douglas Anderson,
Dmitry Torokhov, linux-input, linux-kernel
In-Reply-To: <20230117172121.2715953-1-arnd@kernel.org>
On Tue, Jan 17, 2023 at 06:20:55PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> There is a mix of drivers using either 'depends on HID' or 'select HID',
> which causes both circular dependencies and missed dependencies for
> a 'select':
>
> WARNING: unment direct dependencies for HID
> Depends on [m]: HID_SUPPORT [=y] && INPUT [=m]
> Selected by [y]:
> - AMD_SFH_HID [=y] && HID_SUPPORT [=y] && (X86_64 || COMPILE_TEST [=y]) && PCI [=y]
> Selected by [m]:
> - I2C_HID_CORE [=m] && HID_SUPPORT [=y]
>
> WARNING: unmet direct dependencies detected for INPUT_FF_MEMLESS
> Depends on [m]: INPUT [=m]
> Selected by [y]:
> - DRAGONRISE_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_DRAGONRISE [=y]
> - HID_MICROSOFT [=y] && HID_SUPPORT [=y] && HID [=y]
> - GREENASIA_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_GREENASIA [=y]
> Selected by [m]:
> - INPUT_ARIZONA_HAPTICS [=m] && INPUT [=m] && INPUT_MISC [=y] && MFD_ARIZONA [=y] && SND_SOC [=m]
> - INPUT_PM8XXX_VIBRATOR [=m] && INPUT [=m] && INPUT_MISC [=y] && (MFD_PM8XXX [=m] || MFD_SPMI_PMIC [=n])
> - INPUT_MAX8997_HAPTIC [=m] && INPUT [=m] && INPUT_MISC [=y] && PWM [=y] && MFD_MAX8997 [=y]
> - INPUT_GPIO_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y])
> - INPUT_REGULATOR_HAPTIC [=m] && INPUT [=m] && INPUT_MISC [=y] && REGULATOR [=y]
> - INPUT_TWL6040_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && TWL6040_CORE [=y]
> - INPUT_PWM_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && PWM [=y]
> - INPUT_DRV260X_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y])
> - INPUT_DRV2665_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y]
> - INPUT_DRV2667_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y]
> - INPUT_SC27XX_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && (MFD_SC27XX_PMIC [=y] || COMPILE_TEST [=y])
> - HID_MAYFLASH [=m] && HID_SUPPORT [=y] && HID [=y]
>
> Avoid this by changing all HID client drivers to use 'depends on HID'.
> For I2C_HID, this requires a larger rework of the Kconfig description,
> but it hopefully becomes easier to understand without the complex
> I2C_HID_CORE definition.
>
> Fixes: 25621bcc8976 ("HID: Kconfig: split HID support and hid-core compilation")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/hid/amd-sfh-hid/Kconfig | 2 +-
> drivers/hid/i2c-hid/Kconfig | 31 ++++++++++++++++---------------
> drivers/hid/intel-ish-hid/Kconfig | 2 +-
> 3 files changed, 18 insertions(+), 17 deletions(-)
>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] hid: stop drivers from selecting CONFIG_HID
From: Randy Dunlap @ 2023-01-17 17:25 UTC (permalink / raw)
To: Arnd Bergmann, Basavaraj Natikar, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, Greg Kroah-Hartman
Cc: Arnd Bergmann, Douglas Anderson, Dmitry Torokhov, linux-input,
linux-kernel
In-Reply-To: <20230117172121.2715953-1-arnd@kernel.org>
On 1/17/23 09:20, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> There is a mix of drivers using either 'depends on HID' or 'select HID',
> which causes both circular dependencies and missed dependencies for
> a 'select':
>
> WARNING: unment direct dependencies for HID
> Depends on [m]: HID_SUPPORT [=y] && INPUT [=m]
> Selected by [y]:
> - AMD_SFH_HID [=y] && HID_SUPPORT [=y] && (X86_64 || COMPILE_TEST [=y]) && PCI [=y]
> Selected by [m]:
> - I2C_HID_CORE [=m] && HID_SUPPORT [=y]
>
> WARNING: unmet direct dependencies detected for INPUT_FF_MEMLESS
> Depends on [m]: INPUT [=m]
> Selected by [y]:
> - DRAGONRISE_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_DRAGONRISE [=y]
> - HID_MICROSOFT [=y] && HID_SUPPORT [=y] && HID [=y]
> - GREENASIA_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_GREENASIA [=y]
> Selected by [m]:
> - INPUT_ARIZONA_HAPTICS [=m] && INPUT [=m] && INPUT_MISC [=y] && MFD_ARIZONA [=y] && SND_SOC [=m]
> - INPUT_PM8XXX_VIBRATOR [=m] && INPUT [=m] && INPUT_MISC [=y] && (MFD_PM8XXX [=m] || MFD_SPMI_PMIC [=n])
> - INPUT_MAX8997_HAPTIC [=m] && INPUT [=m] && INPUT_MISC [=y] && PWM [=y] && MFD_MAX8997 [=y]
> - INPUT_GPIO_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y])
> - INPUT_REGULATOR_HAPTIC [=m] && INPUT [=m] && INPUT_MISC [=y] && REGULATOR [=y]
> - INPUT_TWL6040_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && TWL6040_CORE [=y]
> - INPUT_PWM_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && PWM [=y]
> - INPUT_DRV260X_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y])
> - INPUT_DRV2665_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y]
> - INPUT_DRV2667_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y]
> - INPUT_SC27XX_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && (MFD_SC27XX_PMIC [=y] || COMPILE_TEST [=y])
> - HID_MAYFLASH [=m] && HID_SUPPORT [=y] && HID [=y]
>
> Avoid this by changing all HID client drivers to use 'depends on HID'.
> For I2C_HID, this requires a larger rework of the Kconfig description,
> but it hopefully becomes easier to understand without the complex
> I2C_HID_CORE definition.
>
> Fixes: 25621bcc8976 ("HID: Kconfig: split HID support and hid-core compilation")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> drivers/hid/amd-sfh-hid/Kconfig | 2 +-
> drivers/hid/i2c-hid/Kconfig | 31 ++++++++++++++++---------------
> drivers/hid/intel-ish-hid/Kconfig | 2 +-
> 3 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/hid/amd-sfh-hid/Kconfig b/drivers/hid/amd-sfh-hid/Kconfig
> index 56e473fc3c93..af752dd3a340 100644
> --- a/drivers/hid/amd-sfh-hid/Kconfig
> +++ b/drivers/hid/amd-sfh-hid/Kconfig
> @@ -5,7 +5,7 @@ menu "AMD SFH HID Support"
>
> config AMD_SFH_HID
> tristate "AMD Sensor Fusion Hub"
> - select HID
> + depends on HID
> help
> If you say yes to this option, support will be included for the
> AMD Sensor Fusion Hub.
> diff --git a/drivers/hid/i2c-hid/Kconfig b/drivers/hid/i2c-hid/Kconfig
> index d65abe65ce73..b72b7f1ceca8 100644
> --- a/drivers/hid/i2c-hid/Kconfig
> +++ b/drivers/hid/i2c-hid/Kconfig
> @@ -1,11 +1,15 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -menu "I2C HID support"
> - depends on I2C
> +menuconfig I2C_HID
> + tristate "I2C HID support"
> + default y
> + depends on I2C && INPUT && HID
> +
> +if I2C_HID
>
> config I2C_HID_ACPI
> tristate "HID over I2C transport layer ACPI driver"
> - default n
> - depends on I2C && INPUT && ACPI
> + depends on ACPI
> + select I2C_HID_CORE
> help
> Say Y here if you use a keyboard, a touchpad, a touchscreen, or any
> other HID based devices which is connected to your computer via I2C.
> @@ -19,8 +23,8 @@ config I2C_HID_ACPI
>
> config I2C_HID_OF
> tristate "HID over I2C transport layer Open Firmware driver"
> - default n
> - depends on I2C && INPUT && OF
> + depends on OF
> + select I2C_HID_CORE
> help
> Say Y here if you use a keyboard, a touchpad, a touchscreen, or any
> other HID based devices which is connected to your computer via I2C.
> @@ -34,8 +38,8 @@ config I2C_HID_OF
>
> config I2C_HID_OF_ELAN
> tristate "Driver for Elan hid-i2c based devices on OF systems"
> - default n
> - depends on I2C && INPUT && OF
> + depends on OF
> + select I2C_HID_CORE
> help
> Say Y here if you want support for Elan i2c devices that use
> the i2c-hid protocol on Open Firmware (Device Tree)-based
> @@ -49,8 +53,8 @@ config I2C_HID_OF_ELAN
>
> config I2C_HID_OF_GOODIX
> tristate "Driver for Goodix hid-i2c based devices on OF systems"
> - default n
> - depends on I2C && INPUT && OF
> + depends on OF
> + select I2C_HID_CORE
> help
> Say Y here if you want support for Goodix i2c devices that use
> the i2c-hid protocol on Open Firmware (Device Tree)-based
> @@ -62,10 +66,7 @@ config I2C_HID_OF_GOODIX
> will be called i2c-hid-of-goodix. It will also build/depend on
> the module i2c-hid.
>
> -endmenu
> -
> config I2C_HID_CORE
> tristate
> - default y if I2C_HID_ACPI=y || I2C_HID_OF=y || I2C_HID_OF_ELAN=y || I2C_HID_OF_GOODIX=y
> - default m if I2C_HID_ACPI=m || I2C_HID_OF=m || I2C_HID_OF_ELAN=m || I2C_HID_OF_GOODIX=m
> - select HID
> +
> +endif
> diff --git a/drivers/hid/intel-ish-hid/Kconfig b/drivers/hid/intel-ish-hid/Kconfig
> index 689da84a520d..253dc10d35ef 100644
> --- a/drivers/hid/intel-ish-hid/Kconfig
> +++ b/drivers/hid/intel-ish-hid/Kconfig
> @@ -6,7 +6,7 @@ config INTEL_ISH_HID
> tristate "Intel Integrated Sensor Hub"
> default n
> depends on X86
> - select HID
> + depends on HID
> help
> The Integrated Sensor Hub (ISH) enables the ability to offload
> sensor polling and algorithm processing to a dedicated low power
--
~Randy
^ permalink raw reply
* [PATCH] hid: stop drivers from selecting CONFIG_HID
From: Arnd Bergmann @ 2023-01-17 17:20 UTC (permalink / raw)
To: Basavaraj Natikar, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, Greg Kroah-Hartman
Cc: Arnd Bergmann, Douglas Anderson, Dmitry Torokhov, linux-input,
linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
There is a mix of drivers using either 'depends on HID' or 'select HID',
which causes both circular dependencies and missed dependencies for
a 'select':
WARNING: unment direct dependencies for HID
Depends on [m]: HID_SUPPORT [=y] && INPUT [=m]
Selected by [y]:
- AMD_SFH_HID [=y] && HID_SUPPORT [=y] && (X86_64 || COMPILE_TEST [=y]) && PCI [=y]
Selected by [m]:
- I2C_HID_CORE [=m] && HID_SUPPORT [=y]
WARNING: unmet direct dependencies detected for INPUT_FF_MEMLESS
Depends on [m]: INPUT [=m]
Selected by [y]:
- DRAGONRISE_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_DRAGONRISE [=y]
- HID_MICROSOFT [=y] && HID_SUPPORT [=y] && HID [=y]
- GREENASIA_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_GREENASIA [=y]
Selected by [m]:
- INPUT_ARIZONA_HAPTICS [=m] && INPUT [=m] && INPUT_MISC [=y] && MFD_ARIZONA [=y] && SND_SOC [=m]
- INPUT_PM8XXX_VIBRATOR [=m] && INPUT [=m] && INPUT_MISC [=y] && (MFD_PM8XXX [=m] || MFD_SPMI_PMIC [=n])
- INPUT_MAX8997_HAPTIC [=m] && INPUT [=m] && INPUT_MISC [=y] && PWM [=y] && MFD_MAX8997 [=y]
- INPUT_GPIO_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y])
- INPUT_REGULATOR_HAPTIC [=m] && INPUT [=m] && INPUT_MISC [=y] && REGULATOR [=y]
- INPUT_TWL6040_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && TWL6040_CORE [=y]
- INPUT_PWM_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && PWM [=y]
- INPUT_DRV260X_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y])
- INPUT_DRV2665_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y]
- INPUT_DRV2667_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y]
- INPUT_SC27XX_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && (MFD_SC27XX_PMIC [=y] || COMPILE_TEST [=y])
- HID_MAYFLASH [=m] && HID_SUPPORT [=y] && HID [=y]
Avoid this by changing all HID client drivers to use 'depends on HID'.
For I2C_HID, this requires a larger rework of the Kconfig description,
but it hopefully becomes easier to understand without the complex
I2C_HID_CORE definition.
Fixes: 25621bcc8976 ("HID: Kconfig: split HID support and hid-core compilation")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/hid/amd-sfh-hid/Kconfig | 2 +-
drivers/hid/i2c-hid/Kconfig | 31 ++++++++++++++++---------------
drivers/hid/intel-ish-hid/Kconfig | 2 +-
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/Kconfig b/drivers/hid/amd-sfh-hid/Kconfig
index 56e473fc3c93..af752dd3a340 100644
--- a/drivers/hid/amd-sfh-hid/Kconfig
+++ b/drivers/hid/amd-sfh-hid/Kconfig
@@ -5,7 +5,7 @@ menu "AMD SFH HID Support"
config AMD_SFH_HID
tristate "AMD Sensor Fusion Hub"
- select HID
+ depends on HID
help
If you say yes to this option, support will be included for the
AMD Sensor Fusion Hub.
diff --git a/drivers/hid/i2c-hid/Kconfig b/drivers/hid/i2c-hid/Kconfig
index d65abe65ce73..b72b7f1ceca8 100644
--- a/drivers/hid/i2c-hid/Kconfig
+++ b/drivers/hid/i2c-hid/Kconfig
@@ -1,11 +1,15 @@
# SPDX-License-Identifier: GPL-2.0-only
-menu "I2C HID support"
- depends on I2C
+menuconfig I2C_HID
+ tristate "I2C HID support"
+ default y
+ depends on I2C && INPUT && HID
+
+if I2C_HID
config I2C_HID_ACPI
tristate "HID over I2C transport layer ACPI driver"
- default n
- depends on I2C && INPUT && ACPI
+ depends on ACPI
+ select I2C_HID_CORE
help
Say Y here if you use a keyboard, a touchpad, a touchscreen, or any
other HID based devices which is connected to your computer via I2C.
@@ -19,8 +23,8 @@ config I2C_HID_ACPI
config I2C_HID_OF
tristate "HID over I2C transport layer Open Firmware driver"
- default n
- depends on I2C && INPUT && OF
+ depends on OF
+ select I2C_HID_CORE
help
Say Y here if you use a keyboard, a touchpad, a touchscreen, or any
other HID based devices which is connected to your computer via I2C.
@@ -34,8 +38,8 @@ config I2C_HID_OF
config I2C_HID_OF_ELAN
tristate "Driver for Elan hid-i2c based devices on OF systems"
- default n
- depends on I2C && INPUT && OF
+ depends on OF
+ select I2C_HID_CORE
help
Say Y here if you want support for Elan i2c devices that use
the i2c-hid protocol on Open Firmware (Device Tree)-based
@@ -49,8 +53,8 @@ config I2C_HID_OF_ELAN
config I2C_HID_OF_GOODIX
tristate "Driver for Goodix hid-i2c based devices on OF systems"
- default n
- depends on I2C && INPUT && OF
+ depends on OF
+ select I2C_HID_CORE
help
Say Y here if you want support for Goodix i2c devices that use
the i2c-hid protocol on Open Firmware (Device Tree)-based
@@ -62,10 +66,7 @@ config I2C_HID_OF_GOODIX
will be called i2c-hid-of-goodix. It will also build/depend on
the module i2c-hid.
-endmenu
-
config I2C_HID_CORE
tristate
- default y if I2C_HID_ACPI=y || I2C_HID_OF=y || I2C_HID_OF_ELAN=y || I2C_HID_OF_GOODIX=y
- default m if I2C_HID_ACPI=m || I2C_HID_OF=m || I2C_HID_OF_ELAN=m || I2C_HID_OF_GOODIX=m
- select HID
+
+endif
diff --git a/drivers/hid/intel-ish-hid/Kconfig b/drivers/hid/intel-ish-hid/Kconfig
index 689da84a520d..253dc10d35ef 100644
--- a/drivers/hid/intel-ish-hid/Kconfig
+++ b/drivers/hid/intel-ish-hid/Kconfig
@@ -6,7 +6,7 @@ config INTEL_ISH_HID
tristate "Intel Integrated Sensor Hub"
default n
depends on X86
- select HID
+ depends on HID
help
The Integrated Sensor Hub (ISH) enables the ability to offload
sensor polling and algorithm processing to a dedicated low power
--
2.39.0
^ permalink raw reply related
* Re: [PATCH] Input: ipaq-micro-ts - fix DEFINE_SIMPLE_DEV_PM_OPS typo
From: Jonathan Cameron @ 2023-01-17 17:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Torokhov, Linus Walleij, Arnd Bergmann, linux-input,
linux-kernel
In-Reply-To: <20230117164539.1631336-1-arnd@kernel.org>
On Tue, 17 Jan 2023 17:45:33 +0100
Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The previous change was not properly build tested and needs
> a trivial spelling change:
>
> ipaq-micro-ts.c:146:8: error: type defaults to 'int' in declaration of 'DEFINE_SIMPLE_DEV_PM' [-Werror=implicit-int]
>
> Fixes: 144ff5e03d74 ("Input: ipaq-micro-ts - use DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Hi Arnd,
I clearly messed up my build tests - will look into how that went wrong.
From an initial look, this looks like a driver that could benefit from
a || COMPILE_TEST addition to the Kconfig depenencies. Nothing looks to be
build time dependent on the related MFD.
Thanks for fixing it up.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> drivers/input/touchscreen/ipaq-micro-ts.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/ipaq-micro-ts.c b/drivers/input/touchscreen/ipaq-micro-ts.c
> index d8e25b502968..94720c41c9be 100644
> --- a/drivers/input/touchscreen/ipaq-micro-ts.c
> +++ b/drivers/input/touchscreen/ipaq-micro-ts.c
> @@ -143,8 +143,8 @@ static int micro_ts_resume(struct device *dev)
> return 0;
> }
>
> -static DEFINE_SIMPLE_DEV_PM(micro_ts_dev_pm_ops,
> - micro_ts_suspend, micro_ts_resume);
> +static DEFINE_SIMPLE_DEV_PM_OPS(micro_ts_dev_pm_ops,
> + micro_ts_suspend, micro_ts_resume);
>
> static struct platform_driver micro_ts_device_driver = {
> .driver = {
^ permalink raw reply
* [PATCH] Input: ipaq-micro-ts - fix DEFINE_SIMPLE_DEV_PM_OPS typo
From: Arnd Bergmann @ 2023-01-17 16:45 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Cameron, Linus Walleij
Cc: Arnd Bergmann, linux-input, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The previous change was not properly build tested and needs
a trivial spelling change:
ipaq-micro-ts.c:146:8: error: type defaults to 'int' in declaration of 'DEFINE_SIMPLE_DEV_PM' [-Werror=implicit-int]
Fixes: 144ff5e03d74 ("Input: ipaq-micro-ts - use DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/touchscreen/ipaq-micro-ts.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/ipaq-micro-ts.c b/drivers/input/touchscreen/ipaq-micro-ts.c
index d8e25b502968..94720c41c9be 100644
--- a/drivers/input/touchscreen/ipaq-micro-ts.c
+++ b/drivers/input/touchscreen/ipaq-micro-ts.c
@@ -143,8 +143,8 @@ static int micro_ts_resume(struct device *dev)
return 0;
}
-static DEFINE_SIMPLE_DEV_PM(micro_ts_dev_pm_ops,
- micro_ts_suspend, micro_ts_resume);
+static DEFINE_SIMPLE_DEV_PM_OPS(micro_ts_dev_pm_ops,
+ micro_ts_suspend, micro_ts_resume);
static struct platform_driver micro_ts_device_driver = {
.driver = {
--
2.39.0
^ permalink raw reply related
* Re: [PATCH] Input: iqs626a - drop unused device node references
From: Mattijs Korpershoek @ 2023-01-17 16:45 UTC (permalink / raw)
To: Jeff LaBundy, dmitry.torokhov; +Cc: linux-input, jeff
In-Reply-To: <Y7Rm40a+rrwxTIOD@nixie71>
On Tue, Jan 03, 2023 at 11:33, Jeff LaBundy <jeff@labundy.com> wrote:
> Each call to device/fwnode_get_named_child_node() must be matched
> with a call to fwnode_handle_put() once the corresponding node is
> no longer in use. This ensures a reference count remains balanced
> in the case of dynamic device tree support.
>
> Currently, the driver never calls fwnode_handle_put(); this patch
> adds the missing calls. Because fwnode_handle_put() does not take
> a const *fwnode_handle, the const qualifier is removed across all
> corresponding *fwnode_handle instances.
>
> To facilitate this change, the logic that parses event thresholds
> is collapsed in order to limit the number of locations from which
> fwnode_handle_put() must be called.
>
> Fixes: f1d2809de97a ("Input: Add support for Azoteq IQS626A")
> Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
> ---
> drivers/input/misc/iqs626a.c | 87 +++++++++++++++++-------------------
> 1 file changed, 42 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/input/misc/iqs626a.c b/drivers/input/misc/iqs626a.c
> index 23b5dd9552dc..060efb75f8cf 100644
> --- a/drivers/input/misc/iqs626a.c
> +++ b/drivers/input/misc/iqs626a.c
> @@ -458,12 +458,11 @@ struct iqs626_private {
>
> static noinline_for_stack int
> iqs626_parse_events(struct iqs626_private *iqs626,
> - const struct fwnode_handle *ch_node,
> - enum iqs626_ch_id ch_id)
> + struct fwnode_handle *ch_node, enum iqs626_ch_id ch_id)
> {
> struct iqs626_sys_reg *sys_reg = &iqs626->sys_reg;
> struct i2c_client *client = iqs626->client;
> - const struct fwnode_handle *ev_node;
> + struct fwnode_handle *ev_node;
> const char *ev_name;
> u8 *thresh, *hyst;
> unsigned int thresh_tp[IQS626_NUM_CH_TP_3];
> @@ -509,7 +508,7 @@ iqs626_parse_events(struct iqs626_private *iqs626,
> * Trackpad touch events are simply described under the
> * trackpad child node.
> */
> - ev_node = ch_node;
> + ev_node = fwnode_handle_get(ch_node);
> } else {
> ev_name = iqs626_events[i].name;
> ev_node = fwnode_get_named_child_node(ch_node, ev_name);
> @@ -533,6 +532,7 @@ iqs626_parse_events(struct iqs626_private *iqs626,
> dev_err(&client->dev,
> "Invalid input type: %u\n",
> val);
> + fwnode_handle_put(ev_node);
> return -EINVAL;
> }
>
> @@ -547,6 +547,7 @@ iqs626_parse_events(struct iqs626_private *iqs626,
> dev_err(&client->dev,
> "Invalid %s channel hysteresis: %u\n",
> fwnode_get_name(ch_node), val);
> + fwnode_handle_put(ev_node);
> return -EINVAL;
> }
>
> @@ -561,29 +562,12 @@ iqs626_parse_events(struct iqs626_private *iqs626,
> }
> }
>
> - if (ch_id != IQS626_CH_TP_2 && ch_id != IQS626_CH_TP_3 &&
> - !fwnode_property_read_u32(ev_node, "azoteq,thresh", &val)) {
> - if (val > IQS626_CHx_THRESH_MAX) {
> - dev_err(&client->dev,
> - "Invalid %s channel threshold: %u\n",
> - fwnode_get_name(ch_node), val);
> - return -EINVAL;
> - }
> -
> - if (ch_id == IQS626_CH_HALL)
> - *thresh = val;
> - else
> - *(thresh + iqs626_events[i].th_offs) = val;
> -
> - continue;
> - }
> -
> - if (!fwnode_property_present(ev_node, "azoteq,thresh"))
> - continue;
> -
> error = fwnode_property_read_u32_array(ev_node, "azoteq,thresh",
> thresh_tp, num_ch);
> - if (error) {
> + fwnode_handle_put(ev_node);
> + if (error == -EINVAL) {
> + continue;
> + } else if (error) {
> dev_err(&client->dev,
> "Failed to read %s channel thresholds: %d\n",
> fwnode_get_name(ch_node), error);
> @@ -598,6 +582,20 @@ iqs626_parse_events(struct iqs626_private *iqs626,
> return -EINVAL;
> }
>
> + switch (ch_id) {
> + case IQS626_CH_TP_2:
> + case IQS626_CH_TP_3:
> + break;
> +
> + case IQS626_CH_HALL:
> + *thresh = thresh_tp[j];
> + continue;
> +
> + default:
> + thresh[iqs626_events[i].th_offs] = thresh_tp[j];
> + continue;
> + }
> +
> sys_reg->tp_grp_reg.ch_reg_tp[j].thresh = thresh_tp[j];
> }
> }
> @@ -607,8 +605,7 @@ iqs626_parse_events(struct iqs626_private *iqs626,
>
> static noinline_for_stack int
> iqs626_parse_ati_target(struct iqs626_private *iqs626,
> - const struct fwnode_handle *ch_node,
> - enum iqs626_ch_id ch_id)
> + struct fwnode_handle *ch_node, enum iqs626_ch_id ch_id)
> {
> struct iqs626_sys_reg *sys_reg = &iqs626->sys_reg;
> struct i2c_client *client = iqs626->client;
> @@ -716,7 +713,7 @@ iqs626_parse_ati_target(struct iqs626_private *iqs626,
> }
>
> static int iqs626_parse_pins(struct iqs626_private *iqs626,
> - const struct fwnode_handle *ch_node,
> + struct fwnode_handle *ch_node,
> const char *propname, u8 *enable)
> {
> struct i2c_client *client = iqs626->client;
> @@ -764,7 +761,7 @@ static int iqs626_parse_pins(struct iqs626_private *iqs626,
> }
>
> static int iqs626_parse_trackpad(struct iqs626_private *iqs626,
> - const struct fwnode_handle *ch_node)
> + struct fwnode_handle *ch_node)
> {
> struct iqs626_sys_reg *sys_reg = &iqs626->sys_reg;
> struct i2c_client *client = iqs626->client;
> @@ -889,8 +886,7 @@ static int iqs626_parse_trackpad(struct iqs626_private *iqs626,
>
> static noinline_for_stack int
> iqs626_parse_channel(struct iqs626_private *iqs626,
> - const struct fwnode_handle *ch_node,
> - enum iqs626_ch_id ch_id)
> + struct fwnode_handle *ch_node, enum iqs626_ch_id ch_id)
> {
> struct iqs626_sys_reg *sys_reg = &iqs626->sys_reg;
> struct i2c_client *client = iqs626->client;
> @@ -924,6 +920,20 @@ iqs626_parse_channel(struct iqs626_private *iqs626,
> return -EINVAL;
> }
>
> + error = iqs626_parse_ati_target(iqs626, ch_node, ch_id);
> + if (error)
> + return error;
> +
> + error = iqs626_parse_events(iqs626, ch_node, ch_id);
> + if (error)
> + return error;
> +
> + if (!fwnode_property_present(ch_node, "azoteq,ati-exclude"))
> + sys_reg->redo_ati |= iqs626_channels[ch_id].active;
> +
> + if (!fwnode_property_present(ch_node, "azoteq,reseed-disable"))
> + sys_reg->reseed |= iqs626_channels[ch_id].active;
> +
> *engine |= IQS626_CHx_ENG_0_MEAS_CAP_SIZE;
> if (fwnode_property_present(ch_node, "azoteq,meas-cap-decrease"))
> *engine &= ~IQS626_CHx_ENG_0_MEAS_CAP_SIZE;
> @@ -1378,23 +1388,10 @@ static int iqs626_parse_prop(struct iqs626_private *iqs626)
> continue;
>
> error = iqs626_parse_channel(iqs626, ch_node, i);
> + fwnode_handle_put(ch_node);
> if (error)
> return error;
>
> - error = iqs626_parse_ati_target(iqs626, ch_node, i);
> - if (error)
> - return error;
> -
> - error = iqs626_parse_events(iqs626, ch_node, i);
> - if (error)
> - return error;
> -
> - if (!fwnode_property_present(ch_node, "azoteq,ati-exclude"))
> - sys_reg->redo_ati |= iqs626_channels[i].active;
> -
> - if (!fwnode_property_present(ch_node, "azoteq,reseed-disable"))
> - sys_reg->reseed |= iqs626_channels[i].active;
> -
> sys_reg->active |= iqs626_channels[i].active;
> }
>
> --
> 2.34.1
^ permalink raw reply
* Re: PATCH: Add devce IDs for Logitech G923 Xbox Steering Wheel
From: Mattijs Korpershoek @ 2023-01-17 16:29 UTC (permalink / raw)
To: Walt Holman, linux-kernel, linux-input
In-Reply-To: <743753078.40.1672170394290.JavaMail.zimbra@holmansrus.com>
Hello Walt,
Thank you for your patch.
On Tue, Dec 27, 2022 at 13:46, Walt Holman <walt@holmansrus.com> wrote:
> Hello,
>
> This patch adds support for the Logitech G923 Xbox edition steering wheel. This uses the hid-logitech-hidpp kernel module and from my testing, force feedback and all buttons work. This requires the usb_modeswitch application to setup the device in PC mode with a magic string that is the same as the Logitech 920 wheel. Originally I had massaged a patch I found for this wheel, however, much of it was unnecessary and I culled it back to just adding the ID's. Let me know if you need anything else or have any questions. Thanks,
It looks like this patch has been sent as an attachment, not inline. The
subject also looks invalid.
It should be in the lines of:
[PATCH] HID: quirks: Add quirk for Logitech G923 Xbox steering wheel
To make sure your patch gets picked up by a maintainer, can you please
resend it as a plain-text email, following the standard kernel
procedure?
Here are some links to help you preparing your submission:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#no-mime-no-links-no-compression-no-attachments-just-plain-text
If you are new to kernel development, the b4 tool could also help you
preparing your change and finding the right receivers:
https://people.kernel.org/monsieuricon/sending-a-kernel-patch-with-b4-part-1
Hope that helps,
Mattijs
>
> Signed-off-by: Walt Holman walt@holmansrus.com
> diff -u2 -r linux-source/drivers/hid/hid-ids.h linux-target/drivers/hid/hid-ids.h
> --- linux-source/drivers/hid/hid-ids.h 2022-12-21 10:48:12.000000000 -0600
> +++ linux-target/drivers/hid/hid-ids.h 2022-12-22 12:50:16.403880137 -0600
> @@ -820,4 +820,5 @@
> #define USB_DEVICE_ID_LOGITECH_G29_WHEEL 0xc24f
> #define USB_DEVICE_ID_LOGITECH_G920_WHEEL 0xc262
> +#define USB_DEVICE_ID_LOGITECH_G923_XBOX_WHEEL 0xc26e
> #define USB_DEVICE_ID_LOGITECH_WINGMAN_F3D 0xc283
> #define USB_DEVICE_ID_LOGITECH_FORCE3D_PRO 0xc286
> diff -u2 -r linux-source/drivers/hid/hid-logitech-hidpp.c linux-target/drivers/hid/hid-logitech-hidpp.c
> --- linux-source/drivers/hid/hid-logitech-hidpp.c 2022-12-21 10:48:12.000000000 -0600
> +++ linux-target/drivers/hid/hid-logitech-hidpp.c 2022-12-22 12:53:36.335755199 -0600
> @@ -4341,4 +4341,7 @@
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G920_WHEEL),
> .driver_data = HIDPP_QUIRK_CLASS_G920 | HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
> + { /* Logitech G923 Wheel (Xbox version) over USB */
> + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G923_XBOX_WHEEL),
> + .driver_data = HIDPP_QUIRK_CLASS_G920 | HIDPP_QUIRK_FORCE_OUTPUT_REPORTS },
> { /* Logitech G Pro Gaming Mouse over USB */
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC088) },
^ permalink raw reply
* Re: [PASEMI] Nemo board doesn't reboot anymore after the commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice"
From: Jiri Kosina @ 2023-01-17 14:46 UTC (permalink / raw)
To: Christian Zigotzky
Cc: anpatel, linux-input, linuxppc-dev, Darren Stevens, R.T.Dickinson,
mad skateman, Christian Zigotzky
In-Reply-To: <aafbda4b-3a1a-cf7d-0a29-ba0b8b4adc4e@xenosoft.de>
On Tue, 17 Jan 2023, Christian Zigotzky wrote:
> >> The reboot issue is still present in the RC2 of kernel 6.2. We still need
> >> the
> >> usbhid.patch. [1]
> >>
> >> Please check the bad commit. [2]
> > Ankit,
> >
> > have you tested with all the devices that you added the quirk for in your
> > original patch?
> >
> > Unless I hear otherwise, I will just drop
> > the quirk for USB_DEVICE_ID_CHERRY_MOUSE_000C before this gets clarified.
> >
> > Thanks,
> >
> The issue also affects the RC4.
Given the lack of input from Ankit, I have just queued the patch below in
for-6.2/upstream-fixes.
From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] HID: revert CHERRY_MOUSE_000C quirk
This partially reverts commit f6d910a89a2391 ("HID: usbhid: Add ALWAYS_POLL quirk
for some mice"), as it turns out to break reboot on some platforms for reason
yet to be understood.
Fixes: f6d910a89a2391 ("HID: usbhid: Add ALWAYS_POLL quirk for some mice")
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-ids.h | 1 -
drivers/hid/hid-quirks.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 82713ef3aaa6..c3735848ed5d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -274,7 +274,6 @@
#define USB_DEVICE_ID_CH_AXIS_295 0x001c
#define USB_VENDOR_ID_CHERRY 0x046a
-#define USB_DEVICE_ID_CHERRY_MOUSE_000C 0x000c
#define USB_DEVICE_ID_CHERRY_CYMOTION 0x0023
#define USB_DEVICE_ID_CHERRY_CYMOTION_SOLAR 0x0027
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 0e9702c7f7d6..be3ad02573de 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -54,7 +54,6 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FLIGHT_SIM_YOKE), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_PEDALS), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_THROTTLE), HID_QUIRK_NOGET },
- { HID_USB_DEVICE(USB_VENDOR_ID_CHERRY, USB_DEVICE_ID_CHERRY_MOUSE_000C), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE), HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70RGB), HID_QUIRK_NO_INIT_REPORTS },
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PASEMI] Nemo board doesn't reboot anymore after the commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice"
From: Christian Zigotzky @ 2023-01-17 13:51 UTC (permalink / raw)
To: Jiri Kosina
Cc: anpatel, linux-input, linuxppc-dev, Darren Stevens, R.T.Dickinson,
mad skateman, Christian Zigotzky
In-Reply-To: <nycvar.YFH.7.76.2301061540530.1734@cbobk.fhfr.pm>
On 06 January 2023 at 03:41 pm, Jiri Kosina wrote:
> On Fri, 6 Jan 2023, Christian Zigotzky wrote:
>
>> Hello,
>>
>> The reboot issue is still present in the RC2 of kernel 6.2. We still need the
>> usbhid.patch. [1]
>>
>> Please check the bad commit. [2]
> Ankit,
>
> have you tested with all the devices that you added the quirk for in your
> original patch?
>
> Unless I hear otherwise, I will just drop
> the quirk for USB_DEVICE_ID_CHERRY_MOUSE_000C before this gets clarified.
>
> Thanks,
>
The issue also affects the RC4.
-- Christian
^ permalink raw reply
* Re: [PATCH 0/8] HID: remove some unneeded exported symbols from hid.h
From: Jiri Kosina @ 2023-01-17 12:45 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Hans de Goede, Benjamin Tissoires, David Rheinsberg,
Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-input, linux-kernel, linux-usb, linux-bluetooth, netdev
In-Reply-To: <20221222-hid-v1-0-f4a6c35487a5@weissschuh.net>
On Thu, 22 Dec 2022, Thomas Weißschuh wrote:
> Small cleanup to get rid of exports of the lowlevel hid drivers and to make
> them const.
>
> To: Hans de Goede <hdegoede@redhat.com>
> To: Jiri Kosina <jikos@kernel.org>
> To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> To: David Rheinsberg <david.rheinsberg@gmail.com>
> To: Marcel Holtmann <marcel@holtmann.org>
> To: Johan Hedberg <johan.hedberg@gmail.com>
> To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> To: "David S. Miller" <davem@davemloft.net>
> To: Eric Dumazet <edumazet@google.com>
> To: Jakub Kicinski <kuba@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> Cc: linux-input@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Cc: linux-bluetooth@vger.kernel.org
> Cc: netdev@vger.kernel.org
>
> ---
> Thomas Weißschuh (8):
> HID: letsketch: Use hid_is_usb()
> HID: usbhid: Make hid_is_usb() non-inline
> HID: Remove unused function hid_is_using_ll_driver()
> HID: Unexport struct usb_hid_driver
> HID: Unexport struct uhid_hid_driver
> HID: Unexport struct hidp_hid_driver
> HID: Unexport struct i2c_hid_ll_driver
> HID: Make lowlevel driver structs const
>
> drivers/hid/hid-letsketch.c | 2 +-
> drivers/hid/i2c-hid/i2c-hid-core.c | 3 +--
> drivers/hid/uhid.c | 3 +--
> drivers/hid/usbhid/hid-core.c | 9 +++++++--
> include/linux/hid.h | 18 ++----------------
> net/bluetooth/hidp/core.c | 3 +--
> 6 files changed, 13 insertions(+), 25 deletions(-)
Applied to hid.git#for-6.3/hid-core. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/2] Cover Letter: HID: drop assumptions on non-empty report lists
From: Jiri Kosina @ 2023-01-17 12:10 UTC (permalink / raw)
To: Pietro Borrello
Cc: Benjamin Tissoires, Kees Cook, Hanno Zulla, Cristiano Giuffrida,
Bos, H.J., Jakob Koschel, linux-input, linux-kernel
In-Reply-To: <20230114-hid-fix-emmpty-report-list-v1-0-e4d02fad3ba5@diag.uniroma1.it>
On Mon, 16 Jan 2023, Pietro Borrello wrote:
> We found potential misuses of list_entry() on lists in hid driver
> code that are not checked.
> Issuing a list_entry() on an empty list causes a type confusion making
> the list_entry point to the list_head itself.
> The most impactful seems the missing check for an empty list in
> hid_validate_values() which is supposed to check the validity of the
> reports themselves, potentially affecting all the drivers that rely on it.
Both applied to hid.git#for-6.2/upstream-fixes. Thanks Pietro,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] HID: hid-steam: Add Steam Deck support
From: Bastien Nocera @ 2023-01-17 10:10 UTC (permalink / raw)
To: Vicki Pfau; +Cc: linux-input
In-Reply-To: <a438b9b6-6646-deb9-e369-c22d5b8dc570@endrift.com>
On Mon, 2023-01-16 at 21:22 -0800, Vicki Pfau wrote:
>
>
> On 1/11/23 02:24, Bastien Nocera wrote:
> > On Tue, 2023-01-10 at 17:23 -0800, Vicki Pfau wrote:
> > > Add preliminary support for the Steam Deck's controller
> > > interface.
> > > Currently,
> > > this only supports the controller inputs and toggling lizard
> > > mode. It
> > > does not
> > > support any of the advanced features, such as the motion sensors
> > > or
> > > force-feedback.
> >
> > I had to look up what "lizard mode" is. This is a pretty awful name
> > for
> > a "compatibility"/"boot" mode. This should probably be defined in
> > the
> > commit message as that's a Valve specific term.
> >
>
> It's already defined in the comment at the top of the file.
This doesn't appear in the patch itself though.
> Does it need to be defined again in the commit message? If so, does
> every vendor-specific term used in every driver need to be defined
> every commit mentions that functionality? That seems wasteful, if so.
That's how I would do it, or change the name so it's not eyerollingly
cumbersome (and scientifically inaccurate ;)
But I'll let the maintainers comment on this.
Please make sure to keep the mailing-list on CC:.
^ permalink raw reply
* RE: [PATCH] Input: i8042: Disable wake from keyboard by default on several AMD systems
From: Limonciello, Mario @ 2023-01-17 2:51 UTC (permalink / raw)
To: Dmitry Torokhov, linux-kernel@vger.kernel.org
Cc: Xaver Hugl, linux-input@vger.kernel.org
In-Reply-To: <20230116184830.30573-1-mario.limonciello@amd.com>
[Public]
> -----Original Message-----
> From: Limonciello, Mario <Mario.Limonciello@amd.com>
> Sent: Monday, January 16, 2023 12:49
> To: Dmitry Torokhov <dmitry.torokhov@gmail.com>; linux-
> kernel@vger.kernel.org
> Cc: Limonciello, Mario <Mario.Limonciello@amd.com>; Xaver Hugl
> <xaver.hugl@gmail.com>; linux-input@vger.kernel.org
> Subject: [PATCH] Input: i8042: Disable wake from keyboard by default on several
> AMD systems
>
> By default when the system is configured for suspend to idle by default
> the keyboard is set up as a wake source. This matches the behavior that
> Windows uses for Modern Standby as well.
>
> It has been reported that a variety of AMD based designs there are
> spurious wakeups are happening where two IRQ sources are active.
>
> ```
> PM: Triggering wakeup from IRQ 9
> PM: Triggering wakeup from IRQ 1
> ```
>
> In these designs IRQ 9 is the ACPI SCI and IRQ 1 is the PS/2 keyboard.
> An example way to trigger this is to suspend the system and then unplug
> the AC adapter. The SOC will be in a hardware sleep state and plugging
> in the AC adapter returns control to the kernel's s2idle loop.
>
> Normally if just IRQ 9 was active the s2idle loop would advance any EC
> transactions and no other IRQ being active would cause the s2idle loop
> to put the SOC back into hardware sleep state.
>
> When this bug occurred IRQ 1 is also active even if no keyboard activity
> occurred. This causes the s2idle loop to break and the system to wake.
>
> This is a platform firmware bug triggering IRQ1 without keyboard activity.
> This occurs in Windows as well, but Windows will enter "SW DRIPS" and
> then with no activity enters back into "HW DRIPS" (hardware sleep state).
>
> This issue affects Renoir, Lucienne, Cezanne, and Barcelo based platforms
> that use LPC EC. It does not happen on newer systems such as Mendocino or
> Rembrandt.
>
> It's been fixed in newer platform firmware, but determining whether the
> system vendor uses an LPC EC and has deployed the fix is not possible.
>
> To avoid triggering the bug check the CPU model and adjust the policy for
> s2idle wakeup from keyboard on these systems to be disabled by default.
>
> Users who know that their firmware is fixed and want to use wakeup from
> keyboard can manually enable wakeup from sysfs by modifying
> `/sys/bus/serio/devices/serio0/power/wakeup`.
>
> Reported-by: Xaver Hugl <xaver.hugl@gmail.com>
> Tested-by: Xaver Hugl <xaver.hugl@gmail.com>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2115#note_1724008
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
Hi,
Please disregard this patch. In thinking about it more, I don't want to put the
workaround directly in i8042. I am working with Xaver to test deploying the
workaround in platform/x86/amd/pmc.c instead so that we can ensure it only
runs on the firmware versions known to have the flaw and will post a new
patch when we have it working.
Thanks,
^ permalink raw reply
* Re: [PATCH] Input: gpio-keys - add support for linux,input-value dts property
From: Gergo Koteles @ 2023-01-17 1:04 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
In-Reply-To: <Y8XVKAqSL4AC7MH+@google.com>
Hi,
On 2023. 01. 16. 23:52, Dmitry Torokhov wrote:
> Hi,
>
> On Mon, Jan 16, 2023 at 10:59:47PM +0100, Gergo Koteles wrote:
>> Allows setting the value of EV_ABS events from dts.
>
> This needs adjustment to the binding documentation.
>
> Thanks.
>
Do you mean Documentation/devicetree/bindings/input/gpio-keys.yaml?
The linux,input-value is already there.
Thanks
^ permalink raw reply
* Re: [PATCH] Input: i8042: Disable wake from keyboard by default on several AMD systems
From: Dmitry Torokhov @ 2023-01-16 22:59 UTC (permalink / raw)
To: Mario Limonciello; +Cc: linux-kernel, Xaver Hugl, linux-input
In-Reply-To: <20230116184830.30573-1-mario.limonciello@amd.com>
Hi Mario,
On Mon, Jan 16, 2023 at 12:48:30PM -0600, Mario Limonciello wrote:
> By default when the system is configured for suspend to idle by default
> the keyboard is set up as a wake source. This matches the behavior that
> Windows uses for Modern Standby as well.
>
> It has been reported that a variety of AMD based designs there are
> spurious wakeups are happening where two IRQ sources are active.
>
> ```
> PM: Triggering wakeup from IRQ 9
> PM: Triggering wakeup from IRQ 1
> ```
>
> In these designs IRQ 9 is the ACPI SCI and IRQ 1 is the PS/2 keyboard.
> An example way to trigger this is to suspend the system and then unplug
> the AC adapter. The SOC will be in a hardware sleep state and plugging
> in the AC adapter returns control to the kernel's s2idle loop.
>
> Normally if just IRQ 9 was active the s2idle loop would advance any EC
> transactions and no other IRQ being active would cause the s2idle loop
> to put the SOC back into hardware sleep state.
>
> When this bug occurred IRQ 1 is also active even if no keyboard activity
> occurred. This causes the s2idle loop to break and the system to wake.
>
> This is a platform firmware bug triggering IRQ1 without keyboard activity.
> This occurs in Windows as well, but Windows will enter "SW DRIPS" and
> then with no activity enters back into "HW DRIPS" (hardware sleep state).
>
> This issue affects Renoir, Lucienne, Cezanne, and Barcelo based platforms
> that use LPC EC. It does not happen on newer systems such as Mendocino or
> Rembrandt.
>
> It's been fixed in newer platform firmware, but determining whether the
> system vendor uses an LPC EC and has deployed the fix is not possible.
>
> To avoid triggering the bug check the CPU model and adjust the policy for
> s2idle wakeup from keyboard on these systems to be disabled by default.
I think there are Chrome devices using these chipsets that use coreboot
firmware and do not exhibit the problematic behavior, so in addition to
CPU model check we need to check the firmware origin as well.
>
> Users who know that their firmware is fixed and want to use wakeup from
> keyboard can manually enable wakeup from sysfs by modifying
> `/sys/bus/serio/devices/serio0/power/wakeup`.
>
> Reported-by: Xaver Hugl <xaver.hugl@gmail.com>
> Tested-by: Xaver Hugl <xaver.hugl@gmail.com>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2115#note_1724008
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> drivers/input/serio/i8042.c | 25 ++++++++++++++++++++++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
> index 6dac7c1853a54..c9eeca18c0816 100644
> --- a/drivers/input/serio/i8042.c
> +++ b/drivers/input/serio/i8042.c
> @@ -23,6 +23,7 @@
> #include <linux/suspend.h>
> #include <linux/property.h>
>
> +#include <asm/cpu_device_id.h>
Is it available on all architectures? Historically we were trying to
hide platform details in drivers/input/serio/i8042-acpipnpio.h
> #include <asm/io.h>
>
> MODULE_AUTHOR("Vojtech Pavlik <vojtech@suse.cz>");
> @@ -433,6 +434,26 @@ static void i8042_port_close(struct serio *serio)
> i8042_interrupt(0, NULL);
> }
>
> +static bool i8042_should_wakeup_by_default(struct serio *serio)
> +{
> +#ifdef CONFIG_X86
> + const struct x86_cpu_id irq1_bug_cpu_ids[] = {
> + X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 96, NULL), /* Renoir */
> + X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 104, NULL), /* Lucienne */
> + X86_MATCH_VENDOR_FAM_MODEL(AMD, 25, 80, NULL), /* Cezanne/Barcelo */
> + {}
> + };
> +
> + if (x86_match_cpu(irq1_bug_cpu_ids)) {
> + pr_info_once("Disabling wakeup from keyboard to avoid firmware bug\n");
> + return false;
> + }
> +#endif
> + if (!pm_suspend_default_s2idle())
> + return false;
> + return serio == i8042_ports[I8042_KBD_PORT_NO].serio;
> +}
> +
> /*
> * i8042_start() is called by serio core when port is about to finish
> * registering. It will mark port as existing so i8042_interrupt can
> @@ -451,10 +472,8 @@ static int i8042_start(struct serio *serio)
> * behavior on many platforms using suspend-to-RAM (ACPI S3)
> * by default.
> */
> - if (pm_suspend_default_s2idle() &&
> - serio == i8042_ports[I8042_KBD_PORT_NO].serio) {
> + if (i8042_should_wakeup_by_default(serio))
> device_set_wakeup_enable(&serio->dev, true);
> - }
>
> spin_lock_irq(&i8042_lock);
> port->exists = true;
> --
> 2.34.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: gpio-keys - add support for linux,input-value dts property
From: Dmitry Torokhov @ 2023-01-16 22:52 UTC (permalink / raw)
To: Gergo Koteles; +Cc: linux-input
In-Reply-To: <20230116215947.354660-1-soyer@irl.hu>
Hi,
On Mon, Jan 16, 2023 at 10:59:47PM +0100, Gergo Koteles wrote:
> Allows setting the value of EV_ABS events from dts.
This needs adjustment to the binding documentation.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: gpio-keys - add support for linux,input-value dts property
From: Gergo Koteles @ 2023-01-16 21:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Gergo Koteles
Allows setting the value of EV_ABS events from dts.
Signed-off-by: Gergo Koteles <soyer@irl.hu>
---
drivers/input/keyboard/gpio_keys.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 5496482a38c1..c42f86ad0766 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -770,6 +770,9 @@ gpio_keys_get_devtree_pdata(struct device *dev)
&button->type))
button->type = EV_KEY;
+ fwnode_property_read_u32(child, "linux,input-value",
+ (u32 *)&button->value);
+
button->wakeup =
fwnode_property_read_bool(child, "wakeup-source") ||
/* legacy name */
--
2.39.0
^ permalink raw reply related
* Improvement for Joystick and Force Feedback section
From: Hiran Chaudhuri @ 2023-01-16 20:09 UTC (permalink / raw)
To: linux-input
Hello there,
I am neither developer nor committer on the linux kernel. But trying to
figure out the kernel support for my Microsoft Sidewinder Force
Feedback 2 joystick I found two things that might get improved in the
kernel documentation. Maybe someone could update it with below
information:
1)
https://www.kernel.org/doc/html/latest/input/joydev/joystick.html#microsoft-sidewinder-joysticks
The Microsoft Sidewinder Force Feedback 2 joystick is not listed at
all, but after playing around I was able to make it work. So it makes
sense to extend the list with that model.
2) https://www.kernel.org/doc/html/latest/input/ff.html#does-it-work
When trying fftest it is important to use the correct device node
/dev/input/eventXX. Unfortunately I was fiddling for a long time with
the wrong node (it may even change depending on the hot-plugging of the
USB devices).
Therefore first run the command `evtest`, which scans all
/dev/input/event* nodes and will print the devices found. From that
pick the correct file, then run `fftest`.
Also the command `ffcfstress` is a very nice test to verify the
joystick works.
Best regards
Hiran
^ permalink raw reply
* [PATCH] Input: i8042: Disable wake from keyboard by default on several AMD systems
From: Mario Limonciello @ 2023-01-16 18:48 UTC (permalink / raw)
To: Dmitry Torokhov, linux-kernel; +Cc: Mario Limonciello, Xaver Hugl, linux-input
By default when the system is configured for suspend to idle by default
the keyboard is set up as a wake source. This matches the behavior that
Windows uses for Modern Standby as well.
It has been reported that a variety of AMD based designs there are
spurious wakeups are happening where two IRQ sources are active.
```
PM: Triggering wakeup from IRQ 9
PM: Triggering wakeup from IRQ 1
```
In these designs IRQ 9 is the ACPI SCI and IRQ 1 is the PS/2 keyboard.
An example way to trigger this is to suspend the system and then unplug
the AC adapter. The SOC will be in a hardware sleep state and plugging
in the AC adapter returns control to the kernel's s2idle loop.
Normally if just IRQ 9 was active the s2idle loop would advance any EC
transactions and no other IRQ being active would cause the s2idle loop
to put the SOC back into hardware sleep state.
When this bug occurred IRQ 1 is also active even if no keyboard activity
occurred. This causes the s2idle loop to break and the system to wake.
This is a platform firmware bug triggering IRQ1 without keyboard activity.
This occurs in Windows as well, but Windows will enter "SW DRIPS" and
then with no activity enters back into "HW DRIPS" (hardware sleep state).
This issue affects Renoir, Lucienne, Cezanne, and Barcelo based platforms
that use LPC EC. It does not happen on newer systems such as Mendocino or
Rembrandt.
It's been fixed in newer platform firmware, but determining whether the
system vendor uses an LPC EC and has deployed the fix is not possible.
To avoid triggering the bug check the CPU model and adjust the policy for
s2idle wakeup from keyboard on these systems to be disabled by default.
Users who know that their firmware is fixed and want to use wakeup from
keyboard can manually enable wakeup from sysfs by modifying
`/sys/bus/serio/devices/serio0/power/wakeup`.
Reported-by: Xaver Hugl <xaver.hugl@gmail.com>
Tested-by: Xaver Hugl <xaver.hugl@gmail.com>
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2115#note_1724008
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/input/serio/i8042.c | 25 ++++++++++++++++++++++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 6dac7c1853a54..c9eeca18c0816 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -23,6 +23,7 @@
#include <linux/suspend.h>
#include <linux/property.h>
+#include <asm/cpu_device_id.h>
#include <asm/io.h>
MODULE_AUTHOR("Vojtech Pavlik <vojtech@suse.cz>");
@@ -433,6 +434,26 @@ static void i8042_port_close(struct serio *serio)
i8042_interrupt(0, NULL);
}
+static bool i8042_should_wakeup_by_default(struct serio *serio)
+{
+#ifdef CONFIG_X86
+ const struct x86_cpu_id irq1_bug_cpu_ids[] = {
+ X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 96, NULL), /* Renoir */
+ X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 104, NULL), /* Lucienne */
+ X86_MATCH_VENDOR_FAM_MODEL(AMD, 25, 80, NULL), /* Cezanne/Barcelo */
+ {}
+ };
+
+ if (x86_match_cpu(irq1_bug_cpu_ids)) {
+ pr_info_once("Disabling wakeup from keyboard to avoid firmware bug\n");
+ return false;
+ }
+#endif
+ if (!pm_suspend_default_s2idle())
+ return false;
+ return serio == i8042_ports[I8042_KBD_PORT_NO].serio;
+}
+
/*
* i8042_start() is called by serio core when port is about to finish
* registering. It will mark port as existing so i8042_interrupt can
@@ -451,10 +472,8 @@ static int i8042_start(struct serio *serio)
* behavior on many platforms using suspend-to-RAM (ACPI S3)
* by default.
*/
- if (pm_suspend_default_s2idle() &&
- serio == i8042_ports[I8042_KBD_PORT_NO].serio) {
+ if (i8042_should_wakeup_by_default(serio))
device_set_wakeup_enable(&serio->dev, true);
- }
spin_lock_irq(&i8042_lock);
port->exists = true;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/2] Docs: Add some missing SPDX license identifiers of subsystem docs
From: SeongJae Park @ 2023-01-16 17:23 UTC (permalink / raw)
To: Alex Deucher
Cc: SeongJae Park, Jonathan Corbet, linux-hwmon, alsa-devel,
Herbert Xu, linux-doc, linux-kernel, dri-devel, Dmitry Torokhov,
Takashi Iwai, Jaroslav Kysela, Jean Delvare, linux-crypto,
Thomas Zimmermann, linux-input, David S. Miller, Guenter Roeck
In-Reply-To: <CADnq5_OUnkzoZcCdW0X-=gJsXSRgY=GLrbmfNj0geDCzL5a7eQ@mail.gmail.com>
Hi Alex,
On Sun, 15 Jan 2023 10:35:57 -0500 Alex Deucher <alexdeucher@gmail.com> wrote:
> On Sat, Jan 14, 2023 at 2:48 PM SeongJae Park <sj@kernel.org> wrote:
> >
> > Some subsystem documents are missing SPDX license identifiers. Add
> > those.
>
> It would be good to split this up per subsystem.
Thank you for the comment, will do so in next spin.
Thanks,
SJ
[...]
^ permalink raw reply
* [PATCH v2 2/2] HID: i2c-hid: acpi: Unify ACPI ID tables format
From: Andy Shevchenko @ 2023-01-16 15:46 UTC (permalink / raw)
To: Dmitry Torokhov, Raul E Rangel, Benjamin Tissoires, linux-input,
linux-kernel
Cc: Jiri Kosina, Andy Shevchenko
In-Reply-To: <20230116154621.16135-1-andriy.shevchenko@linux.intel.com>
Unify ACPI ID tables format by:
- surrounding HID by spaces
- dropping unnecessary driver_data assignment to 0
- dropping comma at the terminator entry
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
v2: no changes
drivers/hid/i2c-hid/i2c-hid-acpi.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index 5e28da45e762..3a7e2bcb5412 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -39,8 +39,8 @@ static const struct acpi_device_id i2c_hid_acpi_blacklist[] = {
* The CHPN0001 ACPI device, which is used to describe the Chipone
* ICN8505 controller, has a _CID of PNP0C50 but is not HID compatible.
*/
- {"CHPN0001", 0 },
- { },
+ { "CHPN0001" },
+ { }
};
/* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
@@ -104,9 +104,9 @@ static int i2c_hid_acpi_probe(struct i2c_client *client)
}
static const struct acpi_device_id i2c_hid_acpi_match[] = {
- {"ACPI0C50", 0 },
- {"PNP0C50", 0 },
- { },
+ { "ACPI0C50" },
+ { "PNP0C50" },
+ { }
};
MODULE_DEVICE_TABLE(acpi, i2c_hid_acpi_match);
--
2.39.0
^ permalink raw reply related
* [PATCH v2 1/2] HID: i2c-hid: acpi: Drop unneded NULL check of adev
From: Andy Shevchenko @ 2023-01-16 15:46 UTC (permalink / raw)
To: Dmitry Torokhov, Raul E Rangel, Benjamin Tissoires, linux-input,
linux-kernel
Cc: Jiri Kosina, Andy Shevchenko
The driver is enumerated on ACPI platforms, so adev is valid.
Since there is no valid I²C ID table provided, there is no
possibility to bind a device to this driver via user space.
Hence, drop unneeded NULL check of adev.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
v2: no changes
drivers/hid/i2c-hid/i2c-hid-acpi.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index 375c77c3db74..5e28da45e762 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -48,8 +48,9 @@ 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 acpi_device *adev)
+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;
@@ -81,29 +82,22 @@ static int i2c_hid_acpi_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
struct i2c_hid_acpi *ihid_acpi;
- struct acpi_device *adev;
u16 hid_descriptor_address;
int ret;
- adev = ACPI_COMPANION(dev);
- if (!adev) {
- dev_err(&client->dev, "Error could not get ACPI device\n");
- return -ENODEV;
- }
-
ihid_acpi = devm_kzalloc(&client->dev, sizeof(*ihid_acpi), GFP_KERNEL);
if (!ihid_acpi)
return -ENOMEM;
- ihid_acpi->adev = adev;
+ ihid_acpi->adev = ACPI_COMPANION(dev);
ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
- ret = i2c_hid_acpi_get_descriptor(adev);
+ ret = i2c_hid_acpi_get_descriptor(ihid_acpi);
if (ret < 0)
return ret;
hid_descriptor_address = ret;
- acpi_device_fix_up_power(adev);
+ acpi_device_fix_up_power(ihid_acpi->adev);
return i2c_hid_core_probe(client, &ihid_acpi->ops,
hid_descriptor_address, 0);
--
2.39.0
^ permalink raw reply related
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