* Re: [PATCH 1/7] dt-bindings: input: melfas,mms114: add MMS252 compatible
From: Dmitry Torokhov @ 2024-01-23 3:33 UTC (permalink / raw)
To: Bryant Mairs
Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij, linux-arm-msm,
devicetree, linux-kernel, linux-input, Luca Weiss
In-Reply-To: <20231105204759.37107-2-bryant@mai.rs>
On Sun, Nov 05, 2023 at 09:46:16PM +0100, Bryant Mairs wrote:
> From: Luca Weiss <luca@z3ntu.xyz>
>
> Add a compatible for MMS252 touchscreen which appears to work fine with
> the MMS114 driver.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Signed-off-by: Bryant Mairs <bryant@mai.rs>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v6 7/7] x86/vmware: Add TDX hypercall support
From: H. Peter Anvin @ 2024-01-23 0:17 UTC (permalink / raw)
To: Alexey Makhalov, Dave Hansen, linux-kernel, virtualization, bp,
dave.hansen, mingo, tglx
Cc: x86, netdev, richardcochran, linux-input, dmitry.torokhov, zackr,
linux-graphics-maintainer, pv-drivers, namit, timothym, akaher,
jsipek, dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms, kirill.shutemov
In-Reply-To: <c01cecef-db06-49d8-aa2e-548908c65861@broadcom.com>
On January 22, 2024 4:04:33 PM PST, Alexey Makhalov <alexey.makhalov@broadcom.com> wrote:
>
>
>On 1/22/24 10:28 AM, H. Peter Anvin wrote:
>> On January 22, 2024 8:32:22 AM PST, Dave Hansen <dave.hansen@intel.com> wrote:
>>> On 1/9/24 00:40, Alexey Makhalov wrote:
>>>> +#ifdef CONFIG_INTEL_TDX_GUEST
>>>> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
>>>> + struct tdx_module_args *args)
>>>> +{
>>>> + if (!hypervisor_is_type(X86_HYPER_VMWARE))
>>>> + return ULONG_MAX;
>>>> +
>>>> + if (cmd & ~VMWARE_CMD_MASK) {
>>>> + pr_warn_once("Out of range command %lx\n", cmd);
>>>> + return ULONG_MAX;
>>>> + }
>>>> +
>>>> + args->r10 = VMWARE_TDX_VENDOR_LEAF;
>>>> + args->r11 = VMWARE_TDX_HCALL_FUNC;
>>>> + args->r12 = VMWARE_HYPERVISOR_MAGIC;
>>>> + args->r13 = cmd;
>>>> + args->r15 = 0; /* CPL */
>>>> +
>>>> + __tdx_hypercall(args);
>>>> +
>>>> + return args->r12;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
>>>> +#endif
>>>
>>> This is the kind of wrapper that I was hoping for. Thanks.
>>>
>>> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>>>
>>
>> I'm slightly confused by this TBH.
>>
>> Why are the arguments passed in as a structure, which is modified by the wrapper to boot? This is analogous to a system call interface.
>>
>> Furthermore, this is an out-of-line function; it should never be called with !X86_HYPER_VMWARE or you are introducing overhead for other hypervisors; I believe a pr_warn_once() is in order at least, just as you have for the out-of-range test.
>>
>
>This patch series introduces vmware_hypercall family of functions similar to kvm_hypercall. Similarity: both vmware and kvm implementations are static inline functions and both of them use __tdx_hypercall (global not exported symbol). Difference: kvm_hypercall functions are used _only_ within the kernel, but vmware_hypercall are also used by modules.
>Exporting __tdx_hypercall function is an original Dave's concern.
>So we ended up with exporting wrapper, not generic, but VMware specific with added checks against arbitrary use.
>vmware_tdx_hypercall is not designed for !X86_HYPER_VMWARE callers. But such a calls are not forbidden.
>Arguments in a structure is an API for __tdx_hypercall(). Input and output argument handling are done by vmware_hypercall callers, while VMware specific dress up is inside the wrapper.
>
>Peter, do you think code comments are required to make it clear for the reader?
>
>
TBH that explanation didn't make much sense to me...
^ permalink raw reply
* Re: [PATCH v6 7/7] x86/vmware: Add TDX hypercall support
From: Alexey Makhalov @ 2024-01-23 0:04 UTC (permalink / raw)
To: H. Peter Anvin, Dave Hansen, linux-kernel, virtualization, bp,
dave.hansen, mingo, tglx
Cc: x86, netdev, richardcochran, linux-input, dmitry.torokhov, zackr,
linux-graphics-maintainer, pv-drivers, namit, timothym, akaher,
jsipek, dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms, kirill.shutemov
In-Reply-To: <4CF87BC4-E8C8-4584-A275-5A985D5A18A1@zytor.com>
On 1/22/24 10:28 AM, H. Peter Anvin wrote:
> On January 22, 2024 8:32:22 AM PST, Dave Hansen <dave.hansen@intel.com> wrote:
>> On 1/9/24 00:40, Alexey Makhalov wrote:
>>> +#ifdef CONFIG_INTEL_TDX_GUEST
>>> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
>>> + struct tdx_module_args *args)
>>> +{
>>> + if (!hypervisor_is_type(X86_HYPER_VMWARE))
>>> + return ULONG_MAX;
>>> +
>>> + if (cmd & ~VMWARE_CMD_MASK) {
>>> + pr_warn_once("Out of range command %lx\n", cmd);
>>> + return ULONG_MAX;
>>> + }
>>> +
>>> + args->r10 = VMWARE_TDX_VENDOR_LEAF;
>>> + args->r11 = VMWARE_TDX_HCALL_FUNC;
>>> + args->r12 = VMWARE_HYPERVISOR_MAGIC;
>>> + args->r13 = cmd;
>>> + args->r15 = 0; /* CPL */
>>> +
>>> + __tdx_hypercall(args);
>>> +
>>> + return args->r12;
>>> +}
>>> +EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
>>> +#endif
>>
>> This is the kind of wrapper that I was hoping for. Thanks.
>>
>> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>>
>
> I'm slightly confused by this TBH.
>
> Why are the arguments passed in as a structure, which is modified by the wrapper to boot? This is analogous to a system call interface.
>
> Furthermore, this is an out-of-line function; it should never be called with !X86_HYPER_VMWARE or you are introducing overhead for other hypervisors; I believe a pr_warn_once() is in order at least, just as you have for the out-of-range test.
>
This patch series introduces vmware_hypercall family of functions
similar to kvm_hypercall. Similarity: both vmware and kvm
implementations are static inline functions and both of them use
__tdx_hypercall (global not exported symbol). Difference: kvm_hypercall
functions are used _only_ within the kernel, but vmware_hypercall are
also used by modules.
Exporting __tdx_hypercall function is an original Dave's concern.
So we ended up with exporting wrapper, not generic, but VMware specific
with added checks against arbitrary use.
vmware_tdx_hypercall is not designed for !X86_HYPER_VMWARE callers. But
such a calls are not forbidden.
Arguments in a structure is an API for __tdx_hypercall(). Input and
output argument handling are done by vmware_hypercall callers, while
VMware specific dress up is inside the wrapper.
Peter, do you think code comments are required to make it clear for the
reader?
^ permalink raw reply
* Re: [PATCH v2 00/33] spi: get rid of some legacy macros
From: Jonathan Cameron @ 2024-01-22 19:23 UTC (permalink / raw)
To: Mark Brown
Cc: Uwe Kleine-König, kernel, Moritz Fischer, Wu Hao, Xu Yilun,
Tom Rix, linux-fpga, linux-kernel, Alexander Aring,
Stefan Schmidt, Miquel Raynal, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-wpan, netdev,
Lars-Peter Clausen, Michael Hennerich, linux-iio, Dmitry Torokhov,
linux-input, Ulf Hansson, Rayyan Ansari, Andy Shevchenko,
Jonathan Cameron, Martin Tuma, Mauro Carvalho Chehab, linux-media,
Sergey Kozlov, Arnd Bergmann, Greg Kroah-Hartman, Yang Yingliang,
linux-mmc, Richard Weinberger, Vignesh Raghavendra, Rob Herring,
Heiko Stuebner, Michal Simek, Amit Kumar Mahapatra via Alsa-devel,
linux-mtd, Martin Blumenstingl, Geert Uytterhoeven,
Pali Rohár, Simon Horman, Ronald Wahl, Benson Leung,
Tzung-Bi Shih, Guenter Roeck, chrome-platform, Max Filippov,
linux-spi, linux-arm-kernel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, Matthias Brugger, AngeloGioacchino Del Regno,
linux-mediatek, Thomas Zimmermann, Javier Martinez Canillas,
Amit Kumar Mahapatra, dri-devel, linux-fbdev, linux-staging,
Viresh Kumar, Rui Miguel Silva, Johan Hovold, Alex Elder,
greybus-dev, Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe,
linux-integrity, Herve Codina, Alan Stern, Aaro Koskinen,
Krzysztof Kozlowski, linux-usb, Helge Deller, Dario Binacchi,
Kalle Valo, Dmitry Antipov, libertas-dev, linux-wireless,
Jonathan Corbet, James Clark, Bjorn Helgaas, linux-doc
In-Reply-To: <e62cdf7f-ce58-4f46-a0a0-25ce9fb271b1@sirena.org.uk>
On Mon, 22 Jan 2024 18:18:22 +0000
Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
>
> > Note that Jonathan Cameron has already applied patch 3 to his tree, it
> > didn't appear in a public tree though yet. I still included it here to
> > make the kernel build bots happy.
>
> It's also going to be needed for buildability of the end of the series.
Ah. I thought intent was to split this across all the different trees
then do the final patch only after they were all gone?
I'm fine with it going all in one go if people prefer that.
My tree will be out in a few mins. Was just waiting to rebase on rc1
which I've just done.
Jonathan
^ permalink raw reply
* Re: [PATCH] Input - 88pm80x_onkey: add SPDX and drop GPL boilerplate
From: Dmitry Torokhov @ 2024-01-22 19:13 UTC (permalink / raw)
To: Duje Mihanović; +Cc: linux-input, linux-kernel
In-Reply-To: <20240121-88pm80x-onkey-spdx-v1-1-b646d4749f5b@skole.hr>
On Sun, Jan 21, 2024 at 10:11:00PM +0100, Duje Mihanović wrote:
> Add a SPDX-License-Identifier to the 88PM80x onkey driver and drop the
> GPL boilerplate in accordance with current kernel code guidelines.
>
> Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v6 7/7] x86/vmware: Add TDX hypercall support
From: H. Peter Anvin @ 2024-01-22 18:28 UTC (permalink / raw)
To: Dave Hansen, Alexey Makhalov, linux-kernel, virtualization, bp,
dave.hansen, mingo, tglx
Cc: x86, netdev, richardcochran, linux-input, dmitry.torokhov, zackr,
linux-graphics-maintainer, pv-drivers, namit, timothym, akaher,
jsipek, dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms, kirill.shutemov
In-Reply-To: <ff370e42-f48b-4c62-9b44-9d4031cd78b0@intel.com>
On January 22, 2024 8:32:22 AM PST, Dave Hansen <dave.hansen@intel.com> wrote:
>On 1/9/24 00:40, Alexey Makhalov wrote:
>> +#ifdef CONFIG_INTEL_TDX_GUEST
>> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
>> + struct tdx_module_args *args)
>> +{
>> + if (!hypervisor_is_type(X86_HYPER_VMWARE))
>> + return ULONG_MAX;
>> +
>> + if (cmd & ~VMWARE_CMD_MASK) {
>> + pr_warn_once("Out of range command %lx\n", cmd);
>> + return ULONG_MAX;
>> + }
>> +
>> + args->r10 = VMWARE_TDX_VENDOR_LEAF;
>> + args->r11 = VMWARE_TDX_HCALL_FUNC;
>> + args->r12 = VMWARE_HYPERVISOR_MAGIC;
>> + args->r13 = cmd;
>> + args->r15 = 0; /* CPL */
>> +
>> + __tdx_hypercall(args);
>> +
>> + return args->r12;
>> +}
>> +EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
>> +#endif
>
>This is the kind of wrapper that I was hoping for. Thanks.
>
>Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>
I'm slightly confused by this TBH.
Why are the arguments passed in as a structure, which is modified by the wrapper to boot? This is analogous to a system call interface.
Furthermore, this is an out-of-line function; it should never be called with !X86_HYPER_VMWARE or you are introducing overhead for other hypervisors; I believe a pr_warn_once() is in order at least, just as you have for the out-of-range test.
^ permalink raw reply
* Re: [PATCH v2 00/33] spi: get rid of some legacy macros
From: Mark Brown @ 2024-01-22 18:18 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: kernel, Moritz Fischer, Wu Hao, Xu Yilun, Tom Rix, linux-fpga,
linux-kernel, Alexander Aring, Stefan Schmidt, Miquel Raynal,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-wpan, netdev, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, linux-iio, Dmitry Torokhov, linux-input,
Ulf Hansson, Rayyan Ansari, Andy Shevchenko, Jonathan Cameron,
Martin Tuma, Mauro Carvalho Chehab, linux-media, Sergey Kozlov,
Arnd Bergmann, Greg Kroah-Hartman, Yang Yingliang, linux-mmc,
Richard Weinberger, Vignesh Raghavendra, Rob Herring,
Heiko Stuebner, Michal Simek, Amit Kumar Mahapatra via Alsa-devel,
linux-mtd, Martin Blumenstingl, Geert Uytterhoeven,
Pali Rohár, Simon Horman, Ronald Wahl, Benson Leung,
Tzung-Bi Shih, Guenter Roeck, chrome-platform, Max Filippov,
linux-spi, linux-arm-kernel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, Matthias Brugger, AngeloGioacchino Del Regno,
linux-mediatek, Thomas Zimmermann, Javier Martinez Canillas,
Amit Kumar Mahapatra, dri-devel, linux-fbdev, linux-staging,
Viresh Kumar, Rui Miguel Silva, Johan Hovold, Alex Elder,
greybus-dev, Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe,
linux-integrity, Herve Codina, Alan Stern, Aaro Koskinen,
Krzysztof Kozlowski, linux-usb, Helge Deller, Dario Binacchi,
Kalle Valo, Dmitry Antipov, libertas-dev, linux-wireless,
Jonathan Corbet, James Clark, Bjorn Helgaas, linux-doc
In-Reply-To: <cover.1705944943.git.u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
> Note that Jonathan Cameron has already applied patch 3 to his tree, it
> didn't appear in a public tree though yet. I still included it here to
> make the kernel build bots happy.
It's also going to be needed for buildability of the end of the series.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2 00/33] spi: get rid of some legacy macros
From: Uwe Kleine-König @ 2024-01-22 18:06 UTC (permalink / raw)
To: Mark Brown
Cc: kernel, Moritz Fischer, Wu Hao, Xu Yilun, Tom Rix, linux-fpga,
linux-kernel, Alexander Aring, Stefan Schmidt, Miquel Raynal,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-wpan, netdev, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, linux-iio, Dmitry Torokhov, linux-input,
Ulf Hansson, Rayyan Ansari, Andy Shevchenko, Jonathan Cameron,
Martin Tuma, Mauro Carvalho Chehab, linux-media, Sergey Kozlov,
Arnd Bergmann, Greg Kroah-Hartman, Yang Yingliang, linux-mmc,
Richard Weinberger, Vignesh Raghavendra, Rob Herring,
Heiko Stuebner, Michal Simek, Amit Kumar Mahapatra via Alsa-devel,
linux-mtd, Martin Blumenstingl, Geert Uytterhoeven,
Pali Rohár, Simon Horman, Ronald Wahl, Benson Leung,
Tzung-Bi Shih, Guenter Roeck, chrome-platform, Max Filippov,
linux-spi, linux-arm-kernel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, Matthias Brugger, AngeloGioacchino Del Regno,
linux-mediatek, Thomas Zimmermann, Javier Martinez Canillas,
Amit Kumar Mahapatra, dri-devel, linux-fbdev, linux-staging,
Viresh Kumar, Rui Miguel Silva, Johan Hovold, Alex Elder,
greybus-dev, Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe,
linux-integrity, Herve Codina, Alan Stern, Aaro Koskinen,
Krzysztof Kozlowski, linux-usb, Helge Deller, Dario Binacchi,
Kalle Valo, Dmitry Antipov, libertas-dev, linux-wireless,
Jonathan Corbet, James Clark, Bjorn Helgaas, linux-doc
Hello,
this is v2 of this patch set.
Changes since (implicit) v1, sent with Message-Id:
cover.1705348269.git.u.kleine-koenig@pengutronix.de:
- Rebase to v6.8-rc1
- Fix a build failure on sh
- Added the tags received in (implicit) v1.
The slave-mt27xx driver needs some more work. The patch presented here
is enough however to get rid of the defines handled in patch 32.
Cleaning that up is out-of-scope for this series, so I'll delay that
until later.
Note that Jonathan Cameron has already applied patch 3 to his tree, it
didn't appear in a public tree though yet. I still included it here to
make the kernel build bots happy.
Best regards
Uwe
Uwe Kleine-König (33):
fpga: ice40-spi: Follow renaming of SPI "master" to "controller"
ieee802154: ca8210: Follow renaming of SPI "master" to "controller"
iio: adc: ad_sigma_delta: Follow renaming of SPI "master" to
"controller"
Input: pxspad - follow renaming of SPI "master" to "controller"
Input: synaptics-rmi4 - follow renaming of SPI "master" to
"controller"
media: mgb4: Follow renaming of SPI "master" to "controller"
media: netup_unidvb: Follow renaming of SPI "master" to "controller"
media: usb/msi2500: Follow renaming of SPI "master" to "controller"
media: v4l2-subdev: Follow renaming of SPI "master" to "controller"
misc: gehc-achc: Follow renaming of SPI "master" to "controller"
mmc: mmc_spi: Follow renaming of SPI "master" to "controller"
mtd: dataflash: Follow renaming of SPI "master" to "controller"
mtd: rawnand: fsl_elbc: Let .probe retry if local bus is missing
net: ks8851: Follow renaming of SPI "master" to "controller"
net: vertexcom: mse102x: Follow renaming of SPI "master" to
"controller"
platform/chrome: cros_ec_spi: Follow renaming of SPI "master" to
"controller"
spi: bitbang: Follow renaming of SPI "master" to "controller"
spi: cadence-quadspi: Don't emit error message on allocation error
spi: cadence-quadspi: Follow renaming of SPI "master" to "controller"
spi: cavium: Follow renaming of SPI "master" to "controller"
spi: geni-qcom: Follow renaming of SPI "master" to "controller"
spi: loopback-test: Follow renaming of SPI "master" to "controller"
spi: slave-mt27xx: Follow renaming of SPI "master" to "controller"
spi: spidev: Follow renaming of SPI "master" to "controller"
staging: fbtft: Follow renaming of SPI "master" to "controller"
staging: greybus: spi: Follow renaming of SPI "master" to "controller"
tpm_tis_spi: Follow renaming of SPI "master" to "controller"
usb: gadget: max3420_udc: Follow renaming of SPI "master" to
"controller"
video: fbdev: mmp: Follow renaming of SPI "master" to "controller"
wifi: libertas: Follow renaming of SPI "master" to "controller"
spi: fsl-lib: Follow renaming of SPI "master" to "controller"
spi: Drop compat layer from renaming "master" to "controller"
Documentation: spi: Update documentation for renaming "master" to
"controller"
.../driver-api/driver-model/devres.rst | 2 +-
Documentation/spi/spi-summary.rst | 74 +++++++++----------
drivers/char/tpm/tpm_tis_spi_main.c | 4 +-
drivers/fpga/ice40-spi.c | 4 +-
drivers/iio/adc/ad_sigma_delta.c | 14 ++--
drivers/input/joystick/psxpad-spi.c | 4 +-
drivers/input/rmi4/rmi_spi.c | 2 +-
drivers/media/pci/mgb4/mgb4_core.c | 14 ++--
.../media/pci/netup_unidvb/netup_unidvb_spi.c | 48 ++++++------
drivers/media/usb/msi2500/msi2500.c | 38 +++++-----
drivers/media/v4l2-core/v4l2-spi.c | 4 +-
drivers/misc/gehc-achc.c | 8 +-
drivers/mmc/host/mmc_spi.c | 6 +-
drivers/mtd/devices/mtd_dataflash.c | 2 +-
drivers/mtd/nand/raw/fsl_elbc_nand.c | 3 +-
drivers/net/ethernet/micrel/ks8851_spi.c | 4 +-
drivers/net/ethernet/vertexcom/mse102x.c | 2 +-
drivers/net/ieee802154/ca8210.c | 2 +-
.../net/wireless/marvell/libertas/if_spi.c | 2 +-
drivers/platform/chrome/cros_ec_spi.c | 8 +-
drivers/spi/spi-ath79.c | 4 +-
drivers/spi/spi-bitbang.c | 64 ++++++++--------
drivers/spi/spi-butterfly.c | 6 +-
drivers/spi/spi-cadence-quadspi.c | 7 +-
drivers/spi/spi-cavium.c | 6 +-
drivers/spi/spi-cavium.h | 2 +-
drivers/spi/spi-davinci.c | 6 +-
drivers/spi/spi-fsl-lib.c | 14 ++--
drivers/spi/spi-geni-qcom.c | 2 +-
drivers/spi/spi-gpio.c | 2 +-
drivers/spi/spi-lm70llp.c | 6 +-
drivers/spi/spi-loopback-test.c | 4 +-
drivers/spi/spi-oc-tiny.c | 6 +-
drivers/spi/spi-omap-uwire.c | 4 +-
drivers/spi/spi-sh-sci.c | 10 +--
drivers/spi/spi-slave-mt27xx.c | 2 +-
drivers/spi/spi-xilinx.c | 4 +-
drivers/spi/spi-xtensa-xtfpga.c | 2 +-
drivers/spi/spi.c | 2 +-
drivers/spi/spidev.c | 2 +-
drivers/staging/fbtft/fbtft-core.c | 4 +-
drivers/staging/greybus/spilib.c | 66 ++++++++---------
drivers/usb/gadget/udc/max3420_udc.c | 2 +-
drivers/video/fbdev/mmp/hw/mmp_spi.c | 26 +++----
include/linux/spi/spi.h | 20 +----
include/linux/spi/spi_bitbang.h | 2 +-
include/media/v4l2-common.h | 6 +-
47 files changed, 254 insertions(+), 272 deletions(-)
base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
--
2.43.0
^ permalink raw reply
* [PATCH v2 05/33] Input: synaptics-rmi4 - follow renaming of SPI "master" to "controller"
From: Uwe Kleine-König @ 2024-01-22 18:07 UTC (permalink / raw)
To: Mark Brown
Cc: kernel, Dmitry Torokhov, Ulf Hansson, Rayyan Ansari,
Andy Shevchenko, Jonathan Cameron, linux-input, linux-kernel,
linux-spi
In-Reply-To: <cover.1705944943.git.u.kleine-koenig@pengutronix.de>
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/rmi4/rmi_spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_spi.c b/drivers/input/rmi4/rmi_spi.c
index 07c866f42296..9d92129aa432 100644
--- a/drivers/input/rmi4/rmi_spi.c
+++ b/drivers/input/rmi4/rmi_spi.c
@@ -375,7 +375,7 @@ static int rmi_spi_probe(struct spi_device *spi)
struct rmi_device_platform_data *spi_pdata = spi->dev.platform_data;
int error;
- if (spi->master->flags & SPI_CONTROLLER_HALF_DUPLEX)
+ if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX)
return -EINVAL;
rmi_spi = devm_kzalloc(&spi->dev, sizeof(struct rmi_spi_xport),
--
2.43.0
^ permalink raw reply related
* [PATCH v2 04/33] Input: pxspad - follow renaming of SPI "master" to "controller"
From: Uwe Kleine-König @ 2024-01-22 18:06 UTC (permalink / raw)
To: Mark Brown; +Cc: kernel, Dmitry Torokhov, linux-input, linux-kernel, linux-spi
In-Reply-To: <cover.1705944943.git.u.kleine-koenig@pengutronix.de>
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/joystick/psxpad-spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/joystick/psxpad-spi.c b/drivers/input/joystick/psxpad-spi.c
index de734a927b4d..c47fc5f34bd0 100644
--- a/drivers/input/joystick/psxpad-spi.c
+++ b/drivers/input/joystick/psxpad-spi.c
@@ -342,8 +342,8 @@ static int psxpad_spi_probe(struct spi_device *spi)
spi->mode = SPI_MODE_3;
spi->bits_per_word = 8;
/* (PlayStation 1/2 joypad might be possible works 250kHz/500kHz) */
- spi->master->min_speed_hz = 125000;
- spi->master->max_speed_hz = 125000;
+ spi->controller->min_speed_hz = 125000;
+ spi->controller->max_speed_hz = 125000;
spi_setup(spi);
/* pad settings */
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] Input - 88pm80x_onkey: add SPDX and drop GPL boilerplate
From: Greg KH @ 2024-01-22 17:38 UTC (permalink / raw)
To: Duje Mihanović; +Cc: Dmitry Torokhov, linux-input, linux-kernel
In-Reply-To: <20240121-88pm80x-onkey-spdx-v1-1-b646d4749f5b@skole.hr>
On Sun, Jan 21, 2024 at 10:11:00PM +0100, Duje Mihanović wrote:
> Add a SPDX-License-Identifier to the 88PM80x onkey driver and drop the
> GPL boilerplate in accordance with current kernel code guidelines.
>
> Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
> ---
> drivers/input/misc/88pm80x_onkey.c | 14 +-------------
> 1 file changed, 1 insertion(+), 13 deletions(-)
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v6 7/7] x86/vmware: Add TDX hypercall support
From: Dave Hansen @ 2024-01-22 16:32 UTC (permalink / raw)
To: Alexey Makhalov, linux-kernel, virtualization, bp, hpa,
dave.hansen, mingo, tglx
Cc: x86, netdev, richardcochran, linux-input, dmitry.torokhov, zackr,
linux-graphics-maintainer, pv-drivers, namit, timothym, akaher,
jsipek, dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms, kirill.shutemov
In-Reply-To: <20240109084052.58661-8-amakhalov@vmware.com>
On 1/9/24 00:40, Alexey Makhalov wrote:
> +#ifdef CONFIG_INTEL_TDX_GUEST
> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
> + struct tdx_module_args *args)
> +{
> + if (!hypervisor_is_type(X86_HYPER_VMWARE))
> + return ULONG_MAX;
> +
> + if (cmd & ~VMWARE_CMD_MASK) {
> + pr_warn_once("Out of range command %lx\n", cmd);
> + return ULONG_MAX;
> + }
> +
> + args->r10 = VMWARE_TDX_VENDOR_LEAF;
> + args->r11 = VMWARE_TDX_HCALL_FUNC;
> + args->r12 = VMWARE_HYPERVISOR_MAGIC;
> + args->r13 = cmd;
> + args->r15 = 0; /* CPL */
> +
> + __tdx_hypercall(args);
> +
> + return args->r12;
> +}
> +EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
> +#endif
This is the kind of wrapper that I was hoping for. Thanks.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: input: imagis: Document touch keys
From: Duje Mihanović @ 2024-01-22 16:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Markuss Broks, Dmitry Torokhov, Rob Herring, Conor Dooley,
Karel Balej, ~postmarketos/upstreaming, phone-devel, devicetree,
linux-input, linux-kernel
In-Reply-To: <acd64ed2-c36b-45e5-a71e-98c98ff1cb74@linaro.org>
On Monday, January 22, 2024 11:27:09 AM CET Krzysztof Kozlowski wrote:
> On 20/01/2024 22:16, Duje Mihanović wrote:
> > diff --git
> > a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
> > b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
> > index 2af71cbcc97d..960e5436642f 100644
> > ---
> > a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
> > +++
> > b/Documentation/devicetree/bindings/input/touchscreen/
imagis,ist3038c.yaml>
> > @@ -42,6 +42,17 @@ properties:
> > touchscreen-inverted-y: true
> > touchscreen-swapped-x-y: true
> >
> > +if:
> Move allOf here and keep it under allOf.
>
> > + properties:
> > + compatible:
> > + contains:
> > + const: imagis,ist3032c
> > +then:
> > + properties:
>
> > + linux,keycodes:
> No, this property is not allowed by your binding. I doubt this was
> really tested.
>
> Anyway, even if it works, it's not what we expect. Where is the property
> defined?
I was under the impression that it can be defined inside the if statement
since "make dt_binding_check" ran without any errors. If that's wrong, I'm not
sure how else to make the property valid only for ist3032c (the two devices
using ist3038c, samsung-j5 and j5x seem to have tm2-touchkey instead).
Regards,
--
Duje
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: touchscreen: add himax hid-over-spi driver
From: Tomasz Figa @ 2024-01-22 13:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Tylor Yang, Doug Anderson, jingyliang, poyuan_chang, hbarnor,
jikos, wuxy23, conor+dt, luolm1, robh+dt, dmitry.torokhov,
devicetree, krzysztof.kozlowski+dt, poyu_hung, linux-kernel,
linux-input, benjamin.tissoires
In-Reply-To: <5a2f292d-efdf-4647-89ce-e4f5d28c7192@linaro.org>
On Mon, Jan 22, 2024 at 5:08 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 22/01/2024 05:57, Tomasz Figa wrote:
> > Hi Krzysztof,
> >
> > On Wed, Oct 18, 2023 at 2:08 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 17/10/2023 11:18, Tylor Yang wrote:
> >>> Hello,
> >>>
> >>> This patch series adds the driver for Himax HID-over-SPI touchscreen ICs.
> >>> This driver takes a position in [1], it intends to take advantage of SPI
> >>> transfer speed and HID interface.
> >>>
> >>
> >> Dear Google/Chromium folks,
> >>
> >> As a multi-billion company I am sure you can spare some small amount of
> >> time/effort/money for internal review before using community for this
> >> purpose. I mean reviewing trivial issues, like coding style, or just
> >> running checkpatch. You know, the obvious things.
> >>
> >> There is no need to use expensive time of community reviewers to review
> >> very simple mistakes, the ones which we fixed in Linux kernel years ago
> >> (also with automated tools). You can and you should do it, before
> >> submitting drivers for community review.
> >>
> >> Thanks in advance.
> >
> > First of all, I can understand your sentiment towards some of the
> > patches being in a very rough shape. As a community we have large
> > volumes of patches to review and it would be really helpful if new
> > contributors followed some basic simple steps, as described in our
> > "Submitting patches" page...
>
> I don't really understand why responding to something which is three
> months old.
Uh, I got the reply from Dmitry 3 days ago and didn't realize it was that old.
> Anyway, I talked with Doug on Plumbers about it so things
> are more or less clarified, however since two Google folks responded,
> let me continue.
>
> >
> > That said, it's not a fair assumption that there are no steps taken to
> > offload the upstream reviewers community by the corporate
> > contributors. We usually do have basic internal pre-reviews for
> > patches coming from partners and even a pre-review bot (CoP) that can
>
> Good to know.
>
> > automate some of the checks such as checkpatch or bisectability. But
> > as others said in this thread, we don't control our partners and they
> > are free to send the patches just directly to the mailing lists if
> > they want to do so. In a similar way, not everyone in ChromeOS is
> > super experienced with upstream submissions, so sometimes they may not
> > be aware of the best practices, etc.
> >
> > I haven't seen the patch in question, but I'd assume it's more like an
> > exception rather than a usual pattern, so I'd appreciate it if we
>
> Unfortunately that's the pattern. I was complaining few times about very
> poor quality of some patches from some partners before writing that email.
>
> Just to clarify: all the complains are about missing basic stuff, like
> running basic tools. They don't even require internal review by humans.
>
Hmm, that's sad then, but then also as I said, we don't control our
partners, so we can't really guarantee that every single patch goes
through some kind of internal review. Hopefully this has improved by
now and continues to improve as the tooling I mentioned gets more
widely used.
> > could avoid aggressive responses like that and try to solve the
> > problems in a more productive way. Just a simple response with a link
> > to https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > wouldn't really cost you much, or actually even less than the entire
> > litany in this email.
>
> Simple response to docs don't work. Docs are quite long and contributors
> questioned here just don't read them in details.
If asking someone to read a doc doesn't lead to that person reading
the doc, then that's another story. My personal experience is
different, though... But well, again, we're talking about humans, so
we're going to end up with a wide range of extreme cases, regardless
of what we do.
Tbh. I (as a kernel maintainer too) would really imagine we also have
some more automated tooling for the upstream kernel workflows. I don't
see anything preventing some kind of checkpatch (or whatnot) bots,
responding to patches automatically. (Actually we're working on
something like this for the Media subsystem...)
Best regards,
Tomasz
^ permalink raw reply
* Re: PS/2 keyboard of laptop Dell XPS 13 9360 goes missing after S3
From: Hans de Goede @ 2024-01-22 13:43 UTC (permalink / raw)
To: Paul Menzel
Cc: linux-input, linux-pm, Dell.Client.Kernel, regressions,
linux-kernel
In-Reply-To: <0b30c88a-6f0c-447f-a08e-29a2a0256c1b@molgen.mpg.de>
[-- Attachment #1: Type: text/plain, Size: 4211 bytes --]
Hi Paul,
On 1/21/24 15:26, Paul Menzel wrote:
> Dear Hans,
>
>
> As always thank you very much for taking the time to reply.
>
>
> Am 20.01.24 um 21:26 schrieb Hans de Goede:
>
>> On 1/18/24 13:57, Paul Menzel wrote:
>>> #regzbot introduced v6.6.11..v6.7
>
>>> There seems to be a regression in Linux 6.7 on the Dell XPS 13 9360 (Intel i7-7500U).
>>>
>>> [ 0.000000] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022
>>>
>>> The PS/2 keyboard goes missing after S3 resume¹. The problem does not happen with Linux 6.6.11.
>>
>> Thank you for reporting this.
>>
>> Can you try adding "i8042.dumbkbd=1" to your kernel commandline?
>>
>> This should at least lead to the device not disappearing from
>>
>> "sudo libinput list-devices"
>>
>> The next question is if the keyboard will still actually
>> work after suspend/resume with "i8042.dumbkbd=1". If it
>> stays in the list, but no longer works then there is
>> a problem with the i8042 controller; or interrupt
>> delivery to the i8042 controller.
>>
>> If "i8042.dumbkbd=1" somehow fully fixes things, then I guess
>> my atkbd driver fix for other laptop keyboards is somehow
>> causing issues for yours.
>
> Just a quick feedback, that booting with `i8042.dumbkbd=1` seems to fix the issue.
>
>> If "i8042.dumbkbd=1" fully fixes things, can you try building
>> your own 6.7.0 kernel with commit 936e4d49ecbc:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=936e4d49ecbc8c404790504386e1422b599dec39
>>
>> reverted?
>
> I am going to try that as soon as possible.
Assuming this was not some one time glitch with 6.7.0,
I have prepared a patch hopefully fixing this (1) as well
as a follow up fix to address another potential issue which
I have noticed.
Can you please give a 6.7.0 (2) kernel with the 2 attached
patches added a try ?
I know building kernels can be a bit of work / takes time,
sorry. If you are short on time I would prefer testing these 2
patches and see if they fix things over trying a plain revert.
Regards,
Hans
1) Assuming it is caused by this commit in the first place,
which seems likely
2) 6.8-rc1 has a follow up patch which is squashed into the
first patch here, so these patches will only apply cleanly
to 6.7.0 .
>>> [ 1.435071] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
>>> [ 1.435409] i8042: Warning: Keylock active
>>> [ 1.437624] serio: i8042 KBD port at 0x60,0x64 irq 1
>>> [ 1.437631] serio: i8042 AUX port at 0x60,0x64 irq 12
>>> […]
>>> [ 1.439743] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
>>>
>>> $ sudo libinput list-devices
>>> […]
>>> Device: AT Translated Set 2 keyboard
>>> Kernel: /dev/input/event0
>>> Group: 15
>>> Seat: seat0, default
>>> Capabilities: keyboard
>>> Tap-to-click: n/a
>>> Tap-and-drag: n/a
>>> Tap drag lock: n/a
>>> Left-handed: n/a
>>> Nat.scrolling: n/a
>>> Middle emulation: n/a
>>> Calibration: n/a
>>> Scroll methods: none
>>> Click methods: none
>>> Disable-w-typing: n/a
>>> Disable-w-trackpointing: n/a
>>> Accel profiles: n/a
>>> Rotation: 0.0
>>>
>>> `libinput list-devices` does not list the device after resuming
>>> from S3. Some of the function keys, like brightness and airplane
>>> mode keys, still work, as the events are probably transmitted over
>>> the embedded controller or some other mechanism. An external USB
>>> keyboard also still works.
>>>
>>> I haven’t had time to further analyze this, but wanted to report
>>> it. No idea
>>>
>>>
>>> Kind regards,
>>>
>>> Paul
>>>
>>>
>>> ¹ s2idle is not working correctly on the device, in the sense, that
>>> energy usage is very high in that state, and the full battery is at
>>> 20 % after leaving it for eight hours.
>
[-- Attachment #2: 0001-Input-atkbd-Skip-ATKBD_CMD_SETLEDS-when-skipping-ATK.patch --]
[-- Type: text/x-patch, Size: 2981 bytes --]
From 067f89e34264617dd22b0cb850c7996c93152cd1 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Tue, 16 Jan 2024 21:43:25 +0100
Subject: [PATCH 1/2] Input: atkbd - Skip ATKBD_CMD_SETLEDS when skipping
ATKBD_CMD_GETID
After commit 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in
translated mode") the keyboard on a Dell XPS 13 9360 has stopped
working after a suspend/resume.
The problem appears to be that atkbd_probe() fails when called
from atkbd_reconnect() on resume, which on systems where
ATKBD_CMD_GETID is skipped can only happen by ATKBD_CMD_SETLEDS
failing. ATKBD_CMD_SETLEDS failing because ATKBD_CMD_GETID was
skipped is weird, but apparently that is what is happening.
Fix this by also skipping ATKBD_CMD_SETLEDS when skipping
ATKBD_CMD_GETID.
Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/linux-input/0aa4a61f-c939-46fe-a572-08022e8931c7@molgen.mpg.de/
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/keyboard/atkbd.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 786f00f6b7fd..c229bd6b3f7f 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -791,9 +791,9 @@ static bool atkbd_is_portable_device(void)
* not work. So in this case simply assume a keyboard is connected to avoid
* confusing some laptop keyboards.
*
- * Skipping ATKBD_CMD_GETID ends up using a fake keyboard id. Using a fake id is
- * ok in translated mode, only atkbd_select_set() checks atkbd->id and in
- * translated mode that is a no-op.
+ * Skipping ATKBD_CMD_GETID ends up using a fake keyboard id. Using the standard
+ * 0xab83 id is ok in translated mode, only atkbd_select_set() checks atkbd->id
+ * and in translated mode that is a no-op.
*/
static bool atkbd_skip_getid(struct atkbd *atkbd)
{
@@ -824,6 +824,11 @@ static int atkbd_probe(struct atkbd *atkbd)
"keyboard reset failed on %s\n",
ps2dev->serio->phys);
+ if (atkbd_skip_getid(atkbd)) {
+ atkbd->id = 0xab83;
+ return 0;
+ }
+
/*
* Then we check the keyboard ID. We should get 0xab83 under normal conditions.
* Some keyboards report different values, but the first byte is always 0xab or
@@ -832,10 +837,10 @@ static int atkbd_probe(struct atkbd *atkbd)
*/
param[0] = param[1] = 0xa5; /* initialize with invalid values */
- if (atkbd_skip_getid(atkbd) || ps2_command(ps2dev, param, ATKBD_CMD_GETID)) {
+ if (ps2_command(ps2dev, param, ATKBD_CMD_GETID)) {
/*
- * If the get ID command was skipped or failed, we check if we can at least set
+ * If the get ID command failed, we check if we can at least set
* the LEDs on the keyboard. This should work on every keyboard out there.
* It also turns the LEDs off, which we want anyway.
*/
--
2.43.0
[-- Attachment #3: 0002-Input-atkbd-Do-not-skip-atkbd_deactivate-when-skippi.patch --]
[-- Type: text/x-patch, Size: 1493 bytes --]
From bb6435baea52f66e7aaca43520bdb1f71a181a5e Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Mon, 22 Jan 2024 14:32:16 +0100
Subject: [PATCH 2/2] Input: atkbd - Do not skip atkbd_deactivate() when
skipping ATKBD_CMD_GETID
After commit 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in
translated mode") not only the getid command is skipped, but also
the de-activating of the keyboard at the end of atkbd_probe(), potentially
re-introducing the problem fixed by commit be2d7e4233a4 ("Input: atkbd -
fix multi-byte scancode handling on reconnect").
Make sure multi-byte scancode handling on reconnect is still handled
correctly by not skipping the atkbd_deactivate() call.
Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/keyboard/atkbd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index c229bd6b3f7f..7f67f9f2946b 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -826,7 +826,7 @@ static int atkbd_probe(struct atkbd *atkbd)
if (atkbd_skip_getid(atkbd)) {
atkbd->id = 0xab83;
- return 0;
+ goto deactivate_kbd;
}
/*
@@ -863,6 +863,7 @@ static int atkbd_probe(struct atkbd *atkbd)
return -1;
}
+deactivate_kbd:
/*
* Make sure nothing is coming from the keyboard and disturbs our
* internal state.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] dt-bindings: input: imagis: Document touch keys
From: Krzysztof Kozlowski @ 2024-01-22 10:27 UTC (permalink / raw)
To: Duje Mihanović, Markuss Broks, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Karel Balej, ~postmarketos/upstreaming, phone-devel, devicetree,
linux-input, linux-kernel
In-Reply-To: <20240120-b4-imagis-keys-v2-2-d7fc16f2e106@skole.hr>
On 20/01/2024 22:16, Duje Mihanović wrote:
> IST3032C (and possibly some other models) has touch keys. Document this.
>
> Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
> ---
Please provide changelog describing what changed against v1. Cover
letter has something but it is not accurate. It says nothing about this
patch.
> .../bindings/input/touchscreen/imagis,ist3038c.yaml | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
> index 2af71cbcc97d..960e5436642f 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
> @@ -42,6 +42,17 @@ properties:
> touchscreen-inverted-y: true
> touchscreen-swapped-x-y: true
>
> +if:
Move allOf here and keep it under allOf.
> + properties:
> + compatible:
> + contains:
> + const: imagis,ist3032c
> +then:
> + properties:
> + linux,keycodes:
No, this property is not allowed by your binding. I doubt this was
really tested.
Anyway, even if it works, it's not what we expect. Where is the property
defined?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] Input: matrix_keypad - avoid repeatedly converting GPIO to IRQ
From: Bartosz Golaszewski @ 2024-01-22 8:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Dan Carpenter, linux-kernel
In-Reply-To: <20240121053232.276968-1-dmitry.torokhov@gmail.com>
On Sun, 21 Jan 2024 at 06:32, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> gpio_to_irq() is getting more expensive and may require sleeping.
This is no longer true, the relevant commit was reverted and I have
now a working series where I'm using SRCU for lockless list traversal
so if anything it will actually become cheaper.
> Convert row GPIOs to interrupt numbers once in probe() and use
> this information when the driver needs to enable or disable given
> interrupt line.
That being said, I'm not against this change, though this may not be
very useful after all.
Bartosz
[snip!]
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: touchscreen: add himax hid-over-spi driver
From: Krzysztof Kozlowski @ 2024-01-22 8:08 UTC (permalink / raw)
To: Tomasz Figa
Cc: Tylor Yang, Doug Anderson, jingyliang, poyuan_chang, hbarnor,
jikos, wuxy23, conor+dt, luolm1, robh+dt, dmitry.torokhov,
devicetree, krzysztof.kozlowski+dt, poyu_hung, linux-kernel,
linux-input, benjamin.tissoires
In-Reply-To: <CAAFQd5AN-1FTHZcE1Eja0Jd4iqpDocZSz19F44RxqtvKs6ikeQ@mail.gmail.com>
On 22/01/2024 05:57, Tomasz Figa wrote:
> Hi Krzysztof,
>
> On Wed, Oct 18, 2023 at 2:08 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 17/10/2023 11:18, Tylor Yang wrote:
>>> Hello,
>>>
>>> This patch series adds the driver for Himax HID-over-SPI touchscreen ICs.
>>> This driver takes a position in [1], it intends to take advantage of SPI
>>> transfer speed and HID interface.
>>>
>>
>> Dear Google/Chromium folks,
>>
>> As a multi-billion company I am sure you can spare some small amount of
>> time/effort/money for internal review before using community for this
>> purpose. I mean reviewing trivial issues, like coding style, or just
>> running checkpatch. You know, the obvious things.
>>
>> There is no need to use expensive time of community reviewers to review
>> very simple mistakes, the ones which we fixed in Linux kernel years ago
>> (also with automated tools). You can and you should do it, before
>> submitting drivers for community review.
>>
>> Thanks in advance.
>
> First of all, I can understand your sentiment towards some of the
> patches being in a very rough shape. As a community we have large
> volumes of patches to review and it would be really helpful if new
> contributors followed some basic simple steps, as described in our
> "Submitting patches" page...
I don't really understand why responding to something which is three
months old. Anyway, I talked with Doug on Plumbers about it so things
are more or less clarified, however since two Google folks responded,
let me continue.
>
> That said, it's not a fair assumption that there are no steps taken to
> offload the upstream reviewers community by the corporate
> contributors. We usually do have basic internal pre-reviews for
> patches coming from partners and even a pre-review bot (CoP) that can
Good to know.
> automate some of the checks such as checkpatch or bisectability. But
> as others said in this thread, we don't control our partners and they
> are free to send the patches just directly to the mailing lists if
> they want to do so. In a similar way, not everyone in ChromeOS is
> super experienced with upstream submissions, so sometimes they may not
> be aware of the best practices, etc.
>
> I haven't seen the patch in question, but I'd assume it's more like an
> exception rather than a usual pattern, so I'd appreciate it if we
Unfortunately that's the pattern. I was complaining few times about very
poor quality of some patches from some partners before writing that email.
Just to clarify: all the complains are about missing basic stuff, like
running basic tools. They don't even require internal review by humans.
> could avoid aggressive responses like that and try to solve the
> problems in a more productive way. Just a simple response with a link
> to https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> wouldn't really cost you much, or actually even less than the entire
> litany in this email.
Simple response to docs don't work. Docs are quite long and contributors
questioned here just don't read them in details.
Best regards,
Krzysztof
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS d259f137461b9067ff46a10922e66a6e9fc38e12
From: kernel test robot @ 2024-01-22 5:09 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: d259f137461b9067ff46a10922e66a6e9fc38e12 dt-bindings: input: touchscreen: goodix: clarify irq-gpios misleading text
elapsed time: 1440m
configs tested: 218
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha defconfig gcc
arc allnoconfig gcc
arc defconfig gcc
arc hsdk_defconfig gcc
arc randconfig-001-20240121 gcc
arc randconfig-001-20240122 gcc
arc randconfig-002-20240121 gcc
arc randconfig-002-20240122 gcc
arm allnoconfig gcc
arm axm55xx_defconfig gcc
arm gemini_defconfig gcc
arm h3600_defconfig gcc
arm integrator_defconfig gcc
arm jornada720_defconfig gcc
arm lpc18xx_defconfig gcc
arm omap2plus_defconfig gcc
arm pxa910_defconfig gcc
arm pxa_defconfig gcc
arm randconfig-001-20240121 gcc
arm randconfig-002-20240121 gcc
arm randconfig-003-20240121 gcc
arm randconfig-004-20240121 gcc
arm stm32_defconfig gcc
arm u8500_defconfig gcc
arm vf610m4_defconfig gcc
arm wpcm450_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240121 gcc
arm64 randconfig-002-20240121 gcc
arm64 randconfig-003-20240121 gcc
arm64 randconfig-004-20240121 gcc
csky allnoconfig gcc
csky defconfig gcc
csky randconfig-001-20240121 gcc
csky randconfig-001-20240122 gcc
csky randconfig-002-20240121 gcc
csky randconfig-002-20240122 gcc
hexagon allmodconfig clang
hexagon allyesconfig clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20240121 gcc
i386 buildonly-randconfig-002-20240121 gcc
i386 buildonly-randconfig-003-20240121 gcc
i386 buildonly-randconfig-004-20240121 gcc
i386 buildonly-randconfig-005-20240121 gcc
i386 buildonly-randconfig-006-20240121 gcc
i386 defconfig gcc
i386 randconfig-001-20240121 gcc
i386 randconfig-002-20240121 gcc
i386 randconfig-003-20240121 gcc
i386 randconfig-004-20240121 gcc
i386 randconfig-005-20240121 gcc
i386 randconfig-006-20240121 gcc
i386 randconfig-011-20240121 clang
i386 randconfig-012-20240121 clang
i386 randconfig-013-20240121 clang
i386 randconfig-014-20240121 clang
i386 randconfig-015-20240121 clang
i386 randconfig-016-20240121 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch allyesconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240121 gcc
loongarch randconfig-001-20240122 gcc
loongarch randconfig-002-20240121 gcc
loongarch randconfig-002-20240122 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k m5249evb_defconfig gcc
m68k m5275evb_defconfig gcc
m68k mac_defconfig gcc
m68k virt_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips bcm47xx_defconfig gcc
mips decstation_64_defconfig gcc
mips decstation_defconfig gcc
mips rt305x_defconfig gcc
nios2 3c120_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240121 gcc
nios2 randconfig-001-20240122 gcc
nios2 randconfig-002-20240121 gcc
nios2 randconfig-002-20240122 gcc
openrisc allmodconfig gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
openrisc simple_smp_defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240121 gcc
parisc randconfig-001-20240122 gcc
parisc randconfig-002-20240121 gcc
parisc randconfig-002-20240122 gcc
parisc64 alldefconfig gcc
parisc64 defconfig gcc
powerpc allnoconfig gcc
powerpc amigaone_defconfig gcc
powerpc arches_defconfig gcc
powerpc bamboo_defconfig gcc
powerpc randconfig-001-20240121 gcc
powerpc randconfig-002-20240121 gcc
powerpc randconfig-003-20240121 gcc
powerpc redwood_defconfig gcc
powerpc tqm8560_defconfig gcc
powerpc64 randconfig-001-20240121 gcc
powerpc64 randconfig-002-20240121 gcc
powerpc64 randconfig-003-20240121 gcc
riscv allmodconfig gcc
riscv allyesconfig gcc
riscv defconfig gcc
riscv nommu_k210_sdcard_defconfig gcc
riscv randconfig-001-20240121 gcc
riscv randconfig-002-20240121 gcc
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20240122 gcc
s390 randconfig-002-20240122 gcc
sh alldefconfig gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh apsh4a3a_defconfig gcc
sh defconfig gcc
sh lboxre2_defconfig gcc
sh randconfig-001-20240121 gcc
sh randconfig-001-20240122 gcc
sh randconfig-002-20240121 gcc
sh randconfig-002-20240122 gcc
sh rsk7201_defconfig gcc
sh se7343_defconfig gcc
sh sh7710voipgw_defconfig gcc
sparc allmodconfig gcc
sparc allyesconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240121 gcc
sparc64 randconfig-001-20240122 gcc
sparc64 randconfig-002-20240121 gcc
sparc64 randconfig-002-20240122 gcc
um allmodconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20240121 gcc
um randconfig-002-20240121 gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240121 gcc
x86_64 buildonly-randconfig-001-20240122 clang
x86_64 buildonly-randconfig-002-20240121 gcc
x86_64 buildonly-randconfig-002-20240122 clang
x86_64 buildonly-randconfig-003-20240121 gcc
x86_64 buildonly-randconfig-003-20240122 clang
x86_64 buildonly-randconfig-004-20240121 gcc
x86_64 buildonly-randconfig-004-20240122 clang
x86_64 buildonly-randconfig-005-20240121 gcc
x86_64 buildonly-randconfig-005-20240122 clang
x86_64 buildonly-randconfig-006-20240121 gcc
x86_64 buildonly-randconfig-006-20240122 clang
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-011-20240121 gcc
x86_64 randconfig-011-20240122 clang
x86_64 randconfig-012-20240121 gcc
x86_64 randconfig-012-20240122 clang
x86_64 randconfig-013-20240121 gcc
x86_64 randconfig-013-20240122 clang
x86_64 randconfig-014-20240121 gcc
x86_64 randconfig-014-20240122 clang
x86_64 randconfig-015-20240121 gcc
x86_64 randconfig-015-20240122 clang
x86_64 randconfig-016-20240121 gcc
x86_64 randconfig-016-20240122 clang
x86_64 randconfig-071-20240121 gcc
x86_64 randconfig-071-20240122 clang
x86_64 randconfig-072-20240121 gcc
x86_64 randconfig-072-20240122 clang
x86_64 randconfig-073-20240121 gcc
x86_64 randconfig-073-20240122 clang
x86_64 randconfig-074-20240121 gcc
x86_64 randconfig-074-20240122 clang
x86_64 randconfig-075-20240121 gcc
x86_64 randconfig-075-20240122 clang
x86_64 randconfig-076-20240121 gcc
x86_64 randconfig-076-20240122 clang
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa allnoconfig gcc
xtensa allyesconfig gcc
xtensa generic_kc705_defconfig gcc
xtensa randconfig-001-20240121 gcc
xtensa randconfig-001-20240122 gcc
xtensa randconfig-002-20240121 gcc
xtensa randconfig-002-20240122 gcc
xtensa xip_kc705_defconfig gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: touchscreen: add himax hid-over-spi driver
From: Tomasz Figa @ 2024-01-22 4:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Tylor Yang, Doug Anderson, jingyliang, poyuan_chang, hbarnor,
jikos, wuxy23, conor+dt, luolm1, robh+dt, dmitry.torokhov,
devicetree, krzysztof.kozlowski+dt, poyu_hung, linux-kernel,
linux-input, benjamin.tissoires
In-Reply-To: <6c7d9c92-7616-4fad-806e-44302c33b63c@linaro.org>
Hi Krzysztof,
On Wed, Oct 18, 2023 at 2:08 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 17/10/2023 11:18, Tylor Yang wrote:
> > Hello,
> >
> > This patch series adds the driver for Himax HID-over-SPI touchscreen ICs.
> > This driver takes a position in [1], it intends to take advantage of SPI
> > transfer speed and HID interface.
> >
>
> Dear Google/Chromium folks,
>
> As a multi-billion company I am sure you can spare some small amount of
> time/effort/money for internal review before using community for this
> purpose. I mean reviewing trivial issues, like coding style, or just
> running checkpatch. You know, the obvious things.
>
> There is no need to use expensive time of community reviewers to review
> very simple mistakes, the ones which we fixed in Linux kernel years ago
> (also with automated tools). You can and you should do it, before
> submitting drivers for community review.
>
> Thanks in advance.
First of all, I can understand your sentiment towards some of the
patches being in a very rough shape. As a community we have large
volumes of patches to review and it would be really helpful if new
contributors followed some basic simple steps, as described in our
"Submitting patches" page...
That said, it's not a fair assumption that there are no steps taken to
offload the upstream reviewers community by the corporate
contributors. We usually do have basic internal pre-reviews for
patches coming from partners and even a pre-review bot (CoP) that can
automate some of the checks such as checkpatch or bisectability. But
as others said in this thread, we don't control our partners and they
are free to send the patches just directly to the mailing lists if
they want to do so. In a similar way, not everyone in ChromeOS is
super experienced with upstream submissions, so sometimes they may not
be aware of the best practices, etc.
I haven't seen the patch in question, but I'd assume it's more like an
exception rather than a usual pattern, so I'd appreciate it if we
could avoid aggressive responses like that and try to solve the
problems in a more productive way. Just a simple response with a link
to https://www.kernel.org/doc/html/latest/process/submitting-patches.html
wouldn't really cost you much, or actually even less than the entire
litany in this email.
Let's be nice to each other. Thanks.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH 1/2] Input: uinput - Allow uinput_request_submit wait interrupting
From: Dmitry Torokhov @ 2024-01-22 4:03 UTC (permalink / raw)
To: Vicki Pfau, Rafael J. Wysocki; +Cc: linux-input
In-Reply-To: <853baa9e-1c76-4e61-b1f6-a1155ccb5dd7@endrift.com>
Hi Vicki,
On Thu, Dec 14, 2023 at 07:04:09PM -0800, Vicki Pfau wrote:
> Hi Dmitry
>
> On 12/8/23 19:24, Vicki Pfau wrote:
> > Hi Dmitry,
> >
> > On 12/8/23 11:32, Dmitry Torokhov wrote:
> >> Hi Vicki,
> >>
> >> On Wed, Dec 06, 2023 at 10:34:05PM -0800, Vicki Pfau wrote:
> >>> Currently, uinput_request_submit will only fail if the request wait times out.
> >>> However, in other places this wait is interruptable, and in this specific
> >>> location it can lead to issues, such as causing system suspend to hang until
> >>> the request times out.
> >>
> >> Could you please explain how a sleeping process can cause suspend to
> >> hang?
> >
> > While I'm not 100% sure how it happens, given I found this by
> > reproducing it before I came up with a theory for why it happened,
> > my guess is that as it's trying to suspend all of userspace
> > programs, it suspends the process that owns the uinput handle, so it
> > can't continue to service requests, while the other process hangs in
> > the uninterruptable call, blocking suspend for 30 seconds until the
> > call times out.
> >
> >>
> >>> Since the timeout is so long, this can cause the
> >>> appearance of a total system freeze. Making the wait interruptable resolves
> >>> this and possibly further issues.
> >>
> >> I think you are trying to find a justification too hard and it does not
> >> make sense, however I agree that allowing to kill the process issuing
> >> the request without waiting for the timeout to expire if the other side
> >> is stuck might be desirable.
> >
> > This isn't reaching. As I said above, I discovered the patched line
> > of code *after* observing suspend hanging for 30 seconds while
> > trying to reproduce another bug. I wrote this patch, retested, and
> > found that it now suspended immediately, leading to a visible
> > -ERESTARTSYS in strace on coming back from suspend.
> >
I must apologize, you indeed weren't reaching. As far as I can see,
putting tasks into the freezer (which happens during system suspend) is
done via delivering a fake signal to the task. So the task indeed needs
to be in an interruptible state, uninterruptible tasks result in system
failing to suspend.
> > I can post the reproduction case somewhere, but the test program is
> > only the evdev client end, with the uinput side being Steam, which I
> > don't have source code for.
> >
> >>
> >> I think the best way to use wait_for_completion_killable_timeout()
> >> so that stray signals do not disturb userspace, but the processes can
> >> still be terminated.
> >
> > There's already a mutex_lock_interruptable in uinput_request_send
> > that could cause this to fall back to userspace under similar
> > circumstances. The only difference I can find, which is admittedly a
> > bug in this patch now that I look at it again, is that
> > uinput_dev_event would get called twice, leading to the request
> > getting duplicated.
>
> After further investigation, it seems this would still be the case
> even if the request times out--an invalid request would get left in
> the buffer, which means that while this is a new way to trigger the
> issue, it's not actually a new issue.
No, I disagree that it is the same issue. The timeout condition is
pretty much fatal, I expect the caller to exit or stop using the device
if request times out (because either the real device is not responding,
or userspace is not responding, and there is no indication that they
will start responding any time soon). That is why the timeout value is
so generous (30 seconds). In this case we definitely not expect the
request to be re-submitted, either automatically, or explicitly by
userspace.
If we make waiting on the request interruptible we may get interrupted
by a stray signal, and I do not know how both producer (the process
issuing the uinput request) and consumer of the request, will react to
essentially duplicate requests being sent.
I believe we can split this into 2 separate issues:
1. The fact that it is not possible terminate the producer process while
it is waiting for request to be handled (for 30 seconds). I think this
can be safely resolved by switching to
wait_for_completion_killable_timeout(). This will allow fatal signals to
break the wait, and for the process to exit.
2. Producer task failing to enter refrigerator and breaking suspend.
I wonder if the best way to handle that is for uinput to create and
register wakeup source, and then use __pm_stay_awake() and __pm_relax()
to indicate to the rest of the system that suspend is blocked. I believe
userspace should be able to handle this and repeat suspend attempt when
the condition clears...
Rafael, do you have any suggestions here? And I wonder, could we make
killable tasks also enter refrigerator?
Also, now that I think about it more, we should not use slot number for
request->id, as I expect the common situation is to have 1 outstanding
request, so all requests have id 0. Instead we should have a counter and
increase it. This way timeout handling will be more robust, we will not
mistake delayed response to the previous request as response to the
current one.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input - 88pm80x_onkey: add SPDX and drop GPL boilerplate
From: Duje Mihanović @ 2024-01-21 21:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Duje Mihanović
Add a SPDX-License-Identifier to the 88PM80x onkey driver and drop the
GPL boilerplate in accordance with current kernel code guidelines.
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
---
drivers/input/misc/88pm80x_onkey.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/input/misc/88pm80x_onkey.c b/drivers/input/misc/88pm80x_onkey.c
index 31f0702c3d01..4b0685f96113 100644
--- a/drivers/input/misc/88pm80x_onkey.c
+++ b/drivers/input/misc/88pm80x_onkey.c
@@ -1,22 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0-only
/*
* Marvell 88PM80x ONKEY driver
*
* Copyright (C) 2012 Marvell International Ltd.
* Haojian Zhuang <haojian.zhuang@marvell.com>
* Qiao Zhou <zhouqiao@marvell.com>
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License. See the file "COPYING" in the main directory of this
- * archive for more details.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include <linux/kernel.h>
---
base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
change-id: 20240121-88pm80x-onkey-spdx-27c059f68884
Best regards,
--
Duje Mihanović <duje.mihanovic@skole.hr>
^ permalink raw reply related
* Re: PS/2 keyboard of laptop Dell XPS 13 9360 goes missing after S3
From: Hans de Goede @ 2024-01-21 14:39 UTC (permalink / raw)
To: Paul Menzel
Cc: linux-input, linux-pm, Dell.Client.Kernel, regressions,
linux-kernel
In-Reply-To: <0b30c88a-6f0c-447f-a08e-29a2a0256c1b@molgen.mpg.de>
Hi Paul,
On 1/21/24 15:26, Paul Menzel wrote:
> Dear Hans,
>
>
> As always thank you very much for taking the time to reply.
>
>
> Am 20.01.24 um 21:26 schrieb Hans de Goede:
>
>> On 1/18/24 13:57, Paul Menzel wrote:
>>> #regzbot introduced v6.6.11..v6.7
>
>>> There seems to be a regression in Linux 6.7 on the Dell XPS 13 9360 (Intel i7-7500U).
>>>
>>> [ 0.000000] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022
>>>
>>> The PS/2 keyboard goes missing after S3 resume¹. The problem does not happen with Linux 6.6.11.
>>
>> Thank you for reporting this.
>>
>> Can you try adding "i8042.dumbkbd=1" to your kernel commandline?
>>
>> This should at least lead to the device not disappearing from
>>
>> "sudo libinput list-devices"
>>
>> The next question is if the keyboard will still actually
>> work after suspend/resume with "i8042.dumbkbd=1". If it
>> stays in the list, but no longer works then there is
>> a problem with the i8042 controller; or interrupt
>> delivery to the i8042 controller.
>>
>> If "i8042.dumbkbd=1" somehow fully fixes things, then I guess
>> my atkbd driver fix for other laptop keyboards is somehow
>> causing issues for yours.
>
> Just a quick feedback, that booting with `i8042.dumbkbd=1` seems to fix the issue.
>
>> If "i8042.dumbkbd=1" fully fixes things, can you try building
>> your own 6.7.0 kernel with commit 936e4d49ecbc:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=936e4d49ecbc8c404790504386e1422b599dec39
>>
>> reverted?
>
> I am going to try that as soon as possible.
Ok, thank you.
I'm a bit surprised that my fix which skips sending
the getid command to the kbd during init would actually
cause this issue.
Can you retest with an unmodified 6.7.0 to make sure
that this was not some onetime glitch ?
Regards,
Hans
>>> [ 1.435071] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
>>> [ 1.435409] i8042: Warning: Keylock active
>>> [ 1.437624] serio: i8042 KBD port at 0x60,0x64 irq 1
>>> [ 1.437631] serio: i8042 AUX port at 0x60,0x64 irq 12
>>> […]
>>> [ 1.439743] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
>>>
>>> $ sudo libinput list-devices
>>> […]
>>> Device: AT Translated Set 2 keyboard
>>> Kernel: /dev/input/event0
>>> Group: 15
>>> Seat: seat0, default
>>> Capabilities: keyboard
>>> Tap-to-click: n/a
>>> Tap-and-drag: n/a
>>> Tap drag lock: n/a
>>> Left-handed: n/a
>>> Nat.scrolling: n/a
>>> Middle emulation: n/a
>>> Calibration: n/a
>>> Scroll methods: none
>>> Click methods: none
>>> Disable-w-typing: n/a
>>> Disable-w-trackpointing: n/a
>>> Accel profiles: n/a
>>> Rotation: 0.0
>>>
>>> `libinput list-devices` does not list the device after resuming
>>> from S3. Some of the function keys, like brightness and airplane
>>> mode keys, still work, as the events are probably transmitted over
>>> the embedded controller or some other mechanism. An external USB
>>> keyboard also still works.
>>>
>>> I haven’t had time to further analyze this, but wanted to report
>>> it. No idea
>>>
>>>
>>> Kind regards,
>>>
>>> Paul
>>>
>>>
>>> ¹ s2idle is not working correctly on the device, in the sense, that
>>> energy usage is very high in that state, and the full battery is at
>>> 20 % after leaving it for eight hours.
>
^ permalink raw reply
* Re: PS/2 keyboard of laptop Dell XPS 13 9360 goes missing after S3
From: Paul Menzel @ 2024-01-21 14:26 UTC (permalink / raw)
To: Hans de Goede
Cc: linux-input, linux-pm, Dell.Client.Kernel, regressions,
linux-kernel
In-Reply-To: <f27b491c-2f1c-4e68-804c-24eeaa8d10de@redhat.com>
Dear Hans,
As always thank you very much for taking the time to reply.
Am 20.01.24 um 21:26 schrieb Hans de Goede:
> On 1/18/24 13:57, Paul Menzel wrote:
>> #regzbot introduced v6.6.11..v6.7
>> There seems to be a regression in Linux 6.7 on the Dell XPS 13 9360 (Intel i7-7500U).
>>
>> [ 0.000000] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022
>>
>> The PS/2 keyboard goes missing after S3 resume¹. The problem does not happen with Linux 6.6.11.
>
> Thank you for reporting this.
>
> Can you try adding "i8042.dumbkbd=1" to your kernel commandline?
>
> This should at least lead to the device not disappearing from
>
> "sudo libinput list-devices"
>
> The next question is if the keyboard will still actually
> work after suspend/resume with "i8042.dumbkbd=1". If it
> stays in the list, but no longer works then there is
> a problem with the i8042 controller; or interrupt
> delivery to the i8042 controller.
>
> If "i8042.dumbkbd=1" somehow fully fixes things, then I guess
> my atkbd driver fix for other laptop keyboards is somehow
> causing issues for yours.
Just a quick feedback, that booting with `i8042.dumbkbd=1` seems to fix
the issue.
> If "i8042.dumbkbd=1" fully fixes things, can you try building
> your own 6.7.0 kernel with commit 936e4d49ecbc:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=936e4d49ecbc8c404790504386e1422b599dec39
>
> reverted?
I am going to try that as soon as possible.
Kind regards,
Paul
>> [ 1.435071] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
>> [ 1.435409] i8042: Warning: Keylock active
>> [ 1.437624] serio: i8042 KBD port at 0x60,0x64 irq 1
>> [ 1.437631] serio: i8042 AUX port at 0x60,0x64 irq 12
>> […]
>> [ 1.439743] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
>>
>> $ sudo libinput list-devices
>> […]
>> Device: AT Translated Set 2 keyboard
>> Kernel: /dev/input/event0
>> Group: 15
>> Seat: seat0, default
>> Capabilities: keyboard
>> Tap-to-click: n/a
>> Tap-and-drag: n/a
>> Tap drag lock: n/a
>> Left-handed: n/a
>> Nat.scrolling: n/a
>> Middle emulation: n/a
>> Calibration: n/a
>> Scroll methods: none
>> Click methods: none
>> Disable-w-typing: n/a
>> Disable-w-trackpointing: n/a
>> Accel profiles: n/a
>> Rotation: 0.0
>>
>> `libinput list-devices` does not list the device after resuming
>> from S3. Some of the function keys, like brightness and airplane
>> mode keys, still work, as the events are probably transmitted over
>> the embedded controller or some other mechanism. An external USB
>> keyboard also still works.
>>
>> I haven’t had time to further analyze this, but wanted to report
>> it. No idea
>>
>>
>> Kind regards,
>>
>> Paul
>>
>>
>> ¹ s2idle is not working correctly on the device, in the sense, that
>> energy usage is very high in that state, and the full battery is at
>> 20 % after leaving it for eight hours.
^ permalink raw reply
* [PATCH 3/3] Input: matrix_keypad - switch to using managed resources
From: Dmitry Torokhov @ 2024-01-21 5:32 UTC (permalink / raw)
To: linux-input, Dan Carpenter, Bartosz Golaszewski; +Cc: linux-kernel
In-Reply-To: <20240121053232.276968-1-dmitry.torokhov@gmail.com>
Switch the drivers to use managed resources (devm) to simplify error
handling and remove the need to have remove() implementation.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/matrix_keypad.c | 89 +++++++-------------------
1 file changed, 24 insertions(+), 65 deletions(-)
diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c
index 44ef600b8f19..695c03e075b5 100644
--- a/drivers/input/keyboard/matrix_keypad.c
+++ b/drivers/input/keyboard/matrix_keypad.c
@@ -278,38 +278,41 @@ static int matrix_keypad_init_gpio(struct platform_device *pdev,
/* initialized strobe lines as outputs, activated */
for (i = 0; i < pdata->num_col_gpios; i++) {
- err = gpio_request(pdata->col_gpios[i], "matrix_kbd_col");
+ err = devm_gpio_request(&pdev->dev,
+ pdata->col_gpios[i], "matrix_kbd_col");
if (err) {
dev_err(&pdev->dev,
"failed to request GPIO%d for COL%d\n",
pdata->col_gpios[i], i);
- goto err_free_cols;
+ return err;
}
gpio_direction_output(pdata->col_gpios[i], !pdata->active_low);
}
for (i = 0; i < pdata->num_row_gpios; i++) {
- err = gpio_request(pdata->row_gpios[i], "matrix_kbd_row");
+ err = devm_gpio_request(&pdev->dev,
+ pdata->row_gpios[i], "matrix_kbd_row");
if (err) {
dev_err(&pdev->dev,
"failed to request GPIO%d for ROW%d\n",
pdata->row_gpios[i], i);
- goto err_free_rows;
+ return err;
}
gpio_direction_input(pdata->row_gpios[i]);
}
if (pdata->clustered_irq > 0) {
- err = request_any_context_irq(pdata->clustered_irq,
+ err = devm_request_any_context_irq(&pdev->dev,
+ pdata->clustered_irq,
matrix_keypad_interrupt,
pdata->clustered_irq_flags,
"matrix-keypad", keypad);
if (err < 0) {
dev_err(&pdev->dev,
"Unable to acquire clustered interrupt\n");
- goto err_free_rows;
+ return err;
}
keypad->row_irqs[0] = pdata->clustered_irq;
@@ -322,10 +325,11 @@ static int matrix_keypad_init_gpio(struct platform_device *pdev,
dev_err(&pdev->dev,
"Unable to convert GPIO line %i to irq: %d\n",
pdata->row_gpios[i], err);
- goto err_free_irqs;
+ return err;
}
- err = request_any_context_irq(irq,
+ err = devm_request_any_context_irq(&pdev->dev,
+ irq,
matrix_keypad_interrupt,
IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING,
@@ -334,7 +338,7 @@ static int matrix_keypad_init_gpio(struct platform_device *pdev,
dev_err(&pdev->dev,
"Unable to acquire interrupt for GPIO line %i\n",
pdata->row_gpios[i]);
- goto err_free_irqs;
+ return err;
}
keypad->row_irqs[i] = irq;
@@ -345,36 +349,8 @@ static int matrix_keypad_init_gpio(struct platform_device *pdev,
/* initialized as disabled - enabled by input->open */
disable_row_irqs(keypad);
- return 0;
-
-err_free_irqs:
- while (--i >= 0)
- free_irq(keypad->row_irqs[i], keypad);
- i = pdata->num_row_gpios;
-err_free_rows:
- while (--i >= 0)
- gpio_free(pdata->row_gpios[i]);
- i = pdata->num_col_gpios;
-err_free_cols:
- while (--i >= 0)
- gpio_free(pdata->col_gpios[i]);
-
- return err;
-}
-
-static void matrix_keypad_free_gpio(struct matrix_keypad *keypad)
-{
- const struct matrix_keypad_platform_data *pdata = keypad->pdata;
- int i;
-
- for (i = 0; i < keypad->num_row_irqs; i++)
- free_irq(keypad->row_irqs[i], keypad);
-
- for (i = 0; i < pdata->num_row_gpios; i++)
- gpio_free(pdata->row_gpios[i]);
- for (i = 0; i < pdata->num_col_gpios; i++)
- gpio_free(pdata->col_gpios[i]);
+ return 0;
}
#ifdef CONFIG_OF
@@ -473,12 +449,13 @@ static int matrix_keypad_probe(struct platform_device *pdev)
return -EINVAL;
}
- keypad = kzalloc(sizeof(struct matrix_keypad), GFP_KERNEL);
- input_dev = input_allocate_device();
- if (!keypad || !input_dev) {
- err = -ENOMEM;
- goto err_free_mem;
- }
+ keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
+ if (!keypad)
+ return -ENOMEM;
+
+ input_dev = devm_input_allocate_device(&pdev->dev);
+ if (!input_dev)
+ return -ENOMEM;
keypad->input_dev = input_dev;
keypad->pdata = pdata;
@@ -489,7 +466,6 @@ static int matrix_keypad_probe(struct platform_device *pdev)
input_dev->name = pdev->name;
input_dev->id.bustype = BUS_HOST;
- input_dev->dev.parent = &pdev->dev;
input_dev->open = matrix_keypad_start;
input_dev->close = matrix_keypad_stop;
@@ -499,7 +475,7 @@ static int matrix_keypad_probe(struct platform_device *pdev)
NULL, input_dev);
if (err) {
dev_err(&pdev->dev, "failed to build keymap\n");
- goto err_free_mem;
+ return -ENOMEM;
}
if (!pdata->no_autorepeat)
@@ -509,32 +485,16 @@ static int matrix_keypad_probe(struct platform_device *pdev)
err = matrix_keypad_init_gpio(pdev, keypad);
if (err)
- goto err_free_mem;
+ return err;
err = input_register_device(keypad->input_dev);
if (err)
- goto err_free_gpio;
+ return err;
device_init_wakeup(&pdev->dev, pdata->wakeup);
platform_set_drvdata(pdev, keypad);
return 0;
-
-err_free_gpio:
- matrix_keypad_free_gpio(keypad);
-err_free_mem:
- input_free_device(input_dev);
- kfree(keypad);
- return err;
-}
-
-static void matrix_keypad_remove(struct platform_device *pdev)
-{
- struct matrix_keypad *keypad = platform_get_drvdata(pdev);
-
- matrix_keypad_free_gpio(keypad);
- input_unregister_device(keypad->input_dev);
- kfree(keypad);
}
#ifdef CONFIG_OF
@@ -547,7 +507,6 @@ MODULE_DEVICE_TABLE(of, matrix_keypad_dt_match);
static struct platform_driver matrix_keypad_driver = {
.probe = matrix_keypad_probe,
- .remove_new = matrix_keypad_remove,
.driver = {
.name = "matrix-keypad",
.pm = pm_sleep_ptr(&matrix_keypad_pm_ops),
--
2.43.0.429.g432eaa2c6b-goog
^ 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