* Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support
From: Fenglin Wu @ 2023-07-18 6:38 UTC (permalink / raw)
To: Krzysztof Kozlowski, linux-arm-msm, linux-kernel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, linux-input, devicetree
Cc: quic_collinsd, quic_subbaram, quic_kamalw, jestar
In-Reply-To: <cb534cdb-508e-b03e-4e39-50cd6654377a@linaro.org>
On 7/18/2023 2:33 PM, Krzysztof Kozlowski wrote:
> On 18/07/2023 08:26, Fenglin Wu wrote:
>> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
>> PMICs.
>>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> ---
>
> I don't see changelog. No changes then?
>
Sorry, I updated the change log in the cover letter which didn't seems
to be sent to a wider audience, I will resend it by adding more
receivers in the to list
Fenglin
>> Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> index c8832cd0d7da..481163105d24 100644
>> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> @@ -15,6 +15,9 @@ properties:
>> - qcom,pm8058-vib
>> - qcom,pm8916-vib
>> - qcom,pm8921-vib
>> + - qcom,pmi632-vib
>> + - qcom,pm7250b-vib
>> + - qcom,pm7325b-vib
>
> Not much improved. With missing changelog, it seems you ignored the
> feedback.
>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support
From: Krzysztof Kozlowski @ 2023-07-18 6:33 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, linux-kernel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, linux-input, devicetree
Cc: quic_collinsd, quic_subbaram, quic_kamalw, jestar
In-Reply-To: <20230718062639.2339589-2-quic_fenglinw@quicinc.com>
On 18/07/2023 08:26, Fenglin Wu wrote:
> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
> PMICs.
>
> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> ---
I don't see changelog. No changes then?
> Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> index c8832cd0d7da..481163105d24 100644
> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> @@ -15,6 +15,9 @@ properties:
> - qcom,pm8058-vib
> - qcom,pm8916-vib
> - qcom,pm8921-vib
> + - qcom,pmi632-vib
> + - qcom,pm7250b-vib
> + - qcom,pm7325b-vib
Not much improved. With missing changelog, it seems you ignored the
feedback.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs
From: Fenglin Wu @ 2023-07-18 6:26 UTC (permalink / raw)
To: linux-arm-msm, linux-kernel, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Dmitry Torokhov, linux-input
Cc: quic_collinsd, quic_subbaram, quic_fenglinw, quic_kamalw, jestar
In-Reply-To: <20230718062639.2339589-1-quic_fenglinw@quicinc.com>
Add support for vibrator module inside PMI632, PM7250B, PM7325B.
It is very similar to vibrator inside PM8xxx but just the drive
amplitude is controlled through 2 bytes registers.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
index 04cb87efd799..213fdfd47c7f 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -25,6 +25,9 @@ struct pm8xxx_regs {
unsigned int drv_addr;
unsigned int drv_mask;
unsigned int drv_shift;
+ unsigned int drv_addr2;
+ unsigned int drv_mask2;
+ unsigned int drv_shift2;
unsigned int drv_en_manual_mask;
};
@@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
.drv_en_manual_mask = 0,
};
+static struct pm8xxx_regs pmi632_regs = {
+ .enable_addr = 0x5746,
+ .enable_mask = BIT(7),
+ .drv_addr = 0x5740,
+ .drv_mask = 0xff,
+ .drv_shift = 0,
+ .drv_addr2 = 0x5741,
+ .drv_mask2 = 0x0f,
+ .drv_shift2 = 8,
+ .drv_en_manual_mask = 0,
+};
+
+static struct pm8xxx_regs pm7250b_regs = {
+ .enable_addr = 0x5346,
+ .enable_mask = BIT(7),
+ .drv_addr = 0x5340,
+ .drv_mask = 0xff,
+ .drv_shift = 0,
+ .drv_addr2 = 0x5341,
+ .drv_mask2 = 0x0f,
+ .drv_shift2 = 8,
+ .drv_en_manual_mask = 0,
+};
+
+static struct pm8xxx_regs pm7325b_regs = {
+ .enable_addr = 0xdf46,
+ .enable_mask = BIT(7),
+ .drv_addr = 0xdf40,
+ .drv_mask = 0xff,
+ .drv_shift = 0,
+ .drv_addr2 = 0xdf41,
+ .drv_mask2 = 0x0f,
+ .drv_shift2 = 8,
+ .drv_en_manual_mask = 0,
+};
+
/**
* struct pm8xxx_vib - structure to hold vibrator data
* @vib_input_dev: input device supporting force feedback
@@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
return rc;
vib->reg_vib_drv = val;
+ if (regs->drv_addr2 != 0 && on) {
+ val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
+ rc = regmap_write(vib->regmap, regs->drv_addr2, val);
+ if (rc < 0)
+ return rc;
+ }
if (regs->enable_mask)
rc = regmap_update_bits(vib->regmap, regs->enable_addr,
@@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
{ .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
{ .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
{ .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
+ { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
+ { .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
+ { .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
{ }
};
MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
--
2.25.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support
From: Fenglin Wu @ 2023-07-18 6:26 UTC (permalink / raw)
To: linux-arm-msm, linux-kernel, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
linux-input, devicetree
Cc: quic_collinsd, quic_subbaram, quic_fenglinw, quic_kamalw, jestar
In-Reply-To: <20230718062639.2339589-1-quic_fenglinw@quicinc.com>
Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
PMICs.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
index c8832cd0d7da..481163105d24 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
@@ -15,6 +15,9 @@ properties:
- qcom,pm8058-vib
- qcom,pm8916-vib
- qcom,pm8921-vib
+ - qcom,pmi632-vib
+ - qcom,pm7250b-vib
+ - qcom,pm7325b-vib
reg:
maxItems: 1
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v1 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support
From: Krzysztof Kozlowski @ 2023-07-18 6:11 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, linux-kernel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, linux-input, devicetree
Cc: quic_collinsd, quic_subbaram, quic_kamalw, jestar
In-Reply-To: <2b1301e6-fac3-7a06-6716-a65ffd0be7c2@quicinc.com>
On 18/07/2023 04:37, Fenglin Wu wrote:
>
>
> On 7/18/2023 3:59 AM, Krzysztof Kozlowski wrote:
>> On 17/07/2023 08:25, Fenglin Wu wrote:
>>> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
>>> and PM7550BA PMICs.
>>>
>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>> ---
>>> Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> index c8832cd0d7da..642408e2b35f 100644
>>> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> @@ -15,6 +15,10 @@ properties:
>>> - qcom,pm8058-vib
>>> - qcom,pm8916-vib
>>> - qcom,pm8921-vib
>>> + - qcom,pmi632-vib
>>> + - qcom,pm7250b-vib
>>> + - qcom,pm7325b-vib
>>> + - qcom,pm7550ba-vib
>>
>> Aren't the last two compatible?
>
> There are still every different PMICs even though the vibrator module in
> PM7325B and PM7550BA are the same and they share the same register base
> address as well.
So the vibrator modules are compatible? Then I propose to make them
compatible.
Best regards,
Krzysztof
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 904ef2c47d8f3d0f0c7d5c0dd68ecc95908d7360
From: kernel test robot @ 2023-07-18 6:03 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: 904ef2c47d8f3d0f0c7d5c0dd68ecc95908d7360 Input: gpio-keys - convert to dev_err_probe()
elapsed time: 724m
configs tested: 171
configs skipped: 11
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
alpha randconfig-r004-20230718 gcc
alpha randconfig-r024-20230717 gcc
alpha randconfig-r026-20230717 gcc
arc allyesconfig gcc
arc axs101_defconfig gcc
arc defconfig gcc
arc hsdk_defconfig gcc
arc nsimosci_hs_smp_defconfig gcc
arc randconfig-r036-20230717 gcc
arc randconfig-r043-20230717 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm aspeed_g5_defconfig gcc
arm clps711x_defconfig gcc
arm defconfig gcc
arm exynos_defconfig gcc
arm h3600_defconfig gcc
arm keystone_defconfig gcc
arm randconfig-r046-20230717 clang
arm realview_defconfig gcc
arm s3c6400_defconfig gcc
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r001-20230717 clang
arm64 randconfig-r002-20230717 clang
arm64 randconfig-r014-20230717 gcc
arm64 randconfig-r035-20230717 clang
csky defconfig gcc
csky randconfig-r004-20230717 gcc
csky randconfig-r023-20230717 gcc
hexagon randconfig-r041-20230717 clang
hexagon randconfig-r045-20230717 clang
i386 allyesconfig clang
i386 allyesconfig gcc
i386 buildonly-randconfig-r004-20230717 clang
i386 buildonly-randconfig-r004-20230718 gcc
i386 buildonly-randconfig-r005-20230717 clang
i386 buildonly-randconfig-r005-20230718 gcc
i386 buildonly-randconfig-r006-20230717 clang
i386 buildonly-randconfig-r006-20230718 gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-i001-20230717 clang
i386 randconfig-i002-20230717 clang
i386 randconfig-i003-20230717 clang
i386 randconfig-i004-20230717 clang
i386 randconfig-i005-20230717 clang
i386 randconfig-i006-20230717 clang
i386 randconfig-i011-20230717 gcc
i386 randconfig-i012-20230717 gcc
i386 randconfig-i013-20230717 gcc
i386 randconfig-i014-20230717 gcc
i386 randconfig-i015-20230717 gcc
i386 randconfig-i016-20230717 gcc
i386 randconfig-r022-20230717 gcc
i386 randconfig-r023-20230717 gcc
i386 randconfig-r031-20230717 clang
i386 randconfig-r034-20230717 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-r006-20230717 gcc
loongarch randconfig-r036-20230717 gcc
m68k allmodconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k m5272c3_defconfig gcc
m68k randconfig-r011-20230717 gcc
m68k stmark2_defconfig gcc
microblaze randconfig-r005-20230718 gcc
microblaze randconfig-r006-20230718 gcc
microblaze randconfig-r012-20230717 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips decstation_r4k_defconfig gcc
mips fuloong2e_defconfig gcc
mips loongson1b_defconfig gcc
mips malta_qemu_32r6_defconfig clang
mips qi_lb60_defconfig clang
mips randconfig-r013-20230717 clang
mips randconfig-r033-20230717 gcc
mips rb532_defconfig gcc
nios2 defconfig gcc
openrisc randconfig-r005-20230717 gcc
openrisc randconfig-r021-20230717 gcc
openrisc randconfig-r024-20230717 gcc
openrisc randconfig-r025-20230717 gcc
openrisc randconfig-r031-20230717 gcc
openrisc randconfig-r034-20230717 gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc generic-32bit_defconfig gcc
parisc randconfig-r015-20230717 gcc
parisc randconfig-r016-20230717 gcc
parisc randconfig-r032-20230717 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc asp8347_defconfig gcc
powerpc iss476-smp_defconfig gcc
powerpc katmai_defconfig clang
powerpc maple_defconfig gcc
powerpc mpc5200_defconfig clang
powerpc mpc834x_itxgp_defconfig clang
powerpc ppc40x_defconfig gcc
powerpc ppc6xx_defconfig gcc
powerpc rainier_defconfig gcc
powerpc randconfig-r026-20230717 gcc
powerpc stx_gp3_defconfig gcc
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allnoconfig gcc
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-r011-20230717 gcc
riscv randconfig-r042-20230717 gcc
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r015-20230717 gcc
s390 randconfig-r025-20230717 gcc
s390 randconfig-r044-20230717 gcc
sh allmodconfig gcc
sh ecovec24-romimage_defconfig gcc
sh j2_defconfig gcc
sh kfr2r09_defconfig gcc
sh r7780mp_defconfig gcc
sh randconfig-r003-20230718 gcc
sh rts7751r2dplus_defconfig gcc
sh sdk7786_defconfig gcc
sh se7705_defconfig gcc
sh se7722_defconfig gcc
sh secureedge5410_defconfig gcc
sh sh7724_generic_defconfig gcc
sparc allyesconfig gcc
sparc defconfig gcc
sparc randconfig-r022-20230717 gcc
sparc randconfig-r033-20230717 gcc
sparc64 randconfig-r003-20230717 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allyesconfig gcc
x86_64 buildonly-randconfig-r001-20230717 clang
x86_64 buildonly-randconfig-r001-20230718 gcc
x86_64 buildonly-randconfig-r002-20230717 clang
x86_64 buildonly-randconfig-r002-20230718 gcc
x86_64 buildonly-randconfig-r003-20230717 clang
x86_64 buildonly-randconfig-r003-20230718 gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-x001-20230717 gcc
x86_64 randconfig-x002-20230717 gcc
x86_64 randconfig-x003-20230717 gcc
x86_64 randconfig-x004-20230717 gcc
x86_64 randconfig-x005-20230717 gcc
x86_64 randconfig-x006-20230717 gcc
x86_64 randconfig-x011-20230717 clang
x86_64 randconfig-x012-20230717 clang
x86_64 randconfig-x013-20230717 clang
x86_64 randconfig-x014-20230717 clang
x86_64 randconfig-x015-20230717 clang
x86_64 randconfig-x016-20230717 clang
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa audio_kc705_defconfig gcc
xtensa randconfig-r001-20230718 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support
From: Fenglin Wu @ 2023-07-18 2:37 UTC (permalink / raw)
To: Krzysztof Kozlowski, linux-arm-msm, linux-kernel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, linux-input, devicetree
Cc: quic_collinsd, quic_subbaram, quic_kamalw, jestar
In-Reply-To: <6338cc75-e3fe-ba19-3df7-727b63fec245@linaro.org>
On 7/18/2023 3:59 AM, Krzysztof Kozlowski wrote:
> On 17/07/2023 08:25, Fenglin Wu wrote:
>> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
>> and PM7550BA PMICs.
>>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> ---
>> Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> index c8832cd0d7da..642408e2b35f 100644
>> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> @@ -15,6 +15,10 @@ properties:
>> - qcom,pm8058-vib
>> - qcom,pm8916-vib
>> - qcom,pm8921-vib
>> + - qcom,pmi632-vib
>> + - qcom,pm7250b-vib
>> + - qcom,pm7325b-vib
>> + - qcom,pm7550ba-vib
>
> Aren't the last two compatible?
There are still every different PMICs even though the vibrator module in
PM7325B and PM7550BA are the same and they share the same register base
address as well.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Lenovo N24: Touchpad lost sync at byte 6
From: Jonathan Denose @ 2023-07-17 19:59 UTC (permalink / raw)
To: linux-input
Hello,
I am on a Lenovo N24 laptop.
When this device resumes after closing the lid, the mouse freezes and
is unusable. After right-clicking multiple times the touchpad resumes
working. I am seeing the following in the logs:
[ 1188.690138] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
[ 1188.699636] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
[ 1188.709124] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
[ 1188.718557] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
[ 1188.728110] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
[ 1188.975964] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
[ 1188.985456] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
[ 1188.994954] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
[ 1189.004443] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
[ 1189.013930] psmouse serio1: Touchpad at isa0060/serio1/input0 lost
sync at byte 6
This device has an ETPS/2 Elantech Touchpad. I am on kernel version:
5.15.117-19629-gf1eb3139d206.
Greg KH suggested that I try later kernel versions, and I've tried 6.4
and 6.1 and the issue is present on both of those versions. This issue
is also present on 5.10.
Currently the device suspends to ram when the lid closes. When the
device idles without the lid closing, the touchpad works fine on
resume.
I have tried adding various i8042 and psmouse kernel parameters from
searching different forums related to these error messages, but none
of them fix the issue. I have tried
- psmouse.resetafter=0
- psmouse.resetafter=1
- i8042.nomux=1
- i8042.resetafter=1/0
- i8042.reset=1 i8042.nomux=1
- i8042.noloop=1 i8042.nopnp=1 i8042.nomux=1 i8042.reset=1
I was able to resolve this issue by doing `modprobe -r psmouse &&
modprobe.psmouse proto=imps`. proto=bare and proto=exps also resolve
the issue. However, with those options enabled I can no longer use
gestures like two-finger scroll.
This issue reproduces on ChromeOS Flex and Ubuntu 22.04 but not on
Windows. On Windows the touchpad resuming after closing the lid works
fine.
What can I do to resolve this issue while also keeping touchpad gestures?
Any help is greatly appreciated!
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support
From: Krzysztof Kozlowski @ 2023-07-17 19:59 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, linux-kernel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, linux-input, devicetree
Cc: quic_collinsd, quic_subbaram, quic_kamalw, jestar
In-Reply-To: <20230717062547.2086869-2-quic_fenglinw@quicinc.com>
On 17/07/2023 08:25, Fenglin Wu wrote:
> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
> and PM7550BA PMICs.
>
> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> ---
> Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> index c8832cd0d7da..642408e2b35f 100644
> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> @@ -15,6 +15,10 @@ properties:
> - qcom,pm8058-vib
> - qcom,pm8916-vib
> - qcom,pm8921-vib
> + - qcom,pmi632-vib
> + - qcom,pm7250b-vib
> + - qcom,pm7325b-vib
> + - qcom,pm7550ba-vib
Aren't the last two compatible?
Best regards,
Krzysztof
^ permalink raw reply
* Re: Touchpad lost sync at byte 6
From: Greg KH @ 2023-07-17 19:32 UTC (permalink / raw)
To: Jonathan Denose; +Cc: linux-input
In-Reply-To: <CALNJtpU8AnWDybNXxWfWwN2EbieJBJmQqsDMb_7hjG7c7OCOsQ@mail.gmail.com>
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Mon, Jul 17, 2023 at 02:13:37PM -0500, Jonathan Denose wrote:
> Is linux-input@vger.kernel.org not also the input driver maintainers
> list? When I run get_maintainers.pl on the mouse driver files it gives
> me only this list and then some personal emails of some maintainers.
That would be correct.
> I think I may have forgotten to reply-all earlier in the thread so the
> list wasn't cc'd on all of the emails.
Then no one saw it :(
Please resend starting from the beginning.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] Input: da9063 - add wakeup support
From: Samuel Holland @ 2023-07-17 19:20 UTC (permalink / raw)
To: Dmitry Torokhov, Support Opensource
Cc: Samuel Holland, linux-input, linux-kernel
Mark the IRQ as a wake IRQ so it will be enabled during system suspend.
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
drivers/input/misc/da9063_onkey.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/input/misc/da9063_onkey.c b/drivers/input/misc/da9063_onkey.c
index b14a389600c9..74808bae326a 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -10,6 +10,7 @@
#include <linux/input.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
+#include <linux/pm_wakeirq.h>
#include <linux/workqueue.h>
#include <linux/regmap.h>
#include <linux/of.h>
@@ -251,6 +252,14 @@ static int da9063_onkey_probe(struct platform_device *pdev)
return error;
}
+ error = dev_pm_set_wake_irq(&pdev->dev, irq);
+ if (error)
+ dev_warn(&pdev->dev,
+ "Failed to set IRQ %d as a wake IRQ: %d\n",
+ irq, error);
+ else
+ device_init_wakeup(&pdev->dev, true);
+
error = input_register_device(onkey->input);
if (error) {
dev_err(&pdev->dev,
--
2.40.1
^ permalink raw reply related
* Re: Touchpad lost sync at byte 6
From: Jonathan Denose @ 2023-07-17 19:13 UTC (permalink / raw)
To: Greg KH; +Cc: linux-input
In-Reply-To: <2023070838-vacation-ferris-e486@gregkh>
Is linux-input@vger.kernel.org not also the input driver maintainers
list? When I run get_maintainers.pl on the mouse driver files it gives
me only this list and then some personal emails of some maintainers.
I think I may have forgotten to reply-all earlier in the thread so the
list wasn't cc'd on all of the emails.
On Sat, Jul 8, 2023 at 8:10 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jul 07, 2023 at 10:42:06AM -0500, Jonathan Denose wrote:
> > Hi Greg,
> >
> > Thanks for your reply.
> >
> > I have tried the 6.4 and 6.1 kernels and the issue is still present.
> > I've tried on 5.10 as well.
> >
> > I'm suspecting that this may have not worked on this hardware with any
> > kernel version. Where should I go from here?
>
> Contact the input driver maintainers on their list and work on the issue
> there.
>
> good luck!
>
> greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
From: Mark Brown @ 2023-07-17 18:49 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Biju Das, Mike Looijmans, Andreas Helbech Kleist,
Geert Uytterhoeven, Uwe Kleine-König,
linux-input@vger.kernel.org, Prabhakar Mahadev Lad,
linux-renesas-soc@vger.kernel.org, Wolfram Sang
In-Reply-To: <ZLWIPPAfeR1+KbeH@google.com>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
On Mon, Jul 17, 2023 at 11:28:12AM -0700, Dmitry Torokhov wrote:
> I think there is a disconnect. Right now device_get_match_data callbacks
> are part of fwnode_operations. I was proposing to add another optional
> device_get_match_data callback to 'struct bus_type' to allow individual
> buses control how match data is handled, before (or after) jumping into
> the fwnode-backed device_get_match_data callbacks.
Ah, that explains why I never heard of it! I can see that being useful
for providing a single interface to pull mach data out of in drivers.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
From: Biju Das @ 2023-07-17 18:45 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: Mike Looijmans, Andreas Helbech Kleist, Geert Uytterhoeven,
Uwe Kleine-König, linux-input@vger.kernel.org,
Prabhakar Mahadev Lad, linux-renesas-soc@vger.kernel.org,
Wolfram Sang, Andy Shevchenko
In-Reply-To: <ZLWIPPAfeR1+KbeH@google.com>
Hi Dmitry,
> Subject: Re: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
>
> On Mon, Jul 17, 2023 at 07:15:50PM +0100, Mark Brown wrote:
> > On Mon, Jul 17, 2023 at 04:35:02PM +0000, Biju Das wrote:
> >
> > > The .device_get_match_data callbacks are missing for I2C and SPI bus
> subsystems.
> > > Can you please throw some lights on this?
> >
> > It's the first time I've ever heard of that callback, I don't know why
> > whoever added it wouldn't have done those buses in particular or if it
> > just didn't happen. Try adding it and if it works send the patches?
>
> I think there is a disconnect. Right now device_get_match_data callbacks
> are part of fwnode_operations. I was proposing to add another optional
> device_get_match_data callback to 'struct bus_type' to allow individual
> buses control how match data is handled, before (or after) jumping into
> the fwnode-backed device_get_match_data callbacks.
That is what implemented here [1] and [2] right?
[1] https://elixir.bootlin.com/linux/v6.5-rc2/source/drivers/i2c/i2c-core-base.c#L117
[2] https://elixir.bootlin.com/linux/v6.5-rc2/source/drivers/spi/spi.c#L364
First it check for fwnode-backed device_get_match_data callbacks and
Fallback is bus-type based match.
Looks like you are proposing to unify [1] and [2] and you want the logic to be other way around. ie, first bus-type match, then fwnode-backed callbacks?
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
From: Dmitry Torokhov @ 2023-07-17 18:28 UTC (permalink / raw)
To: Mark Brown
Cc: Biju Das, Mike Looijmans, Andreas Helbech Kleist,
Geert Uytterhoeven, Uwe Kleine-König,
linux-input@vger.kernel.org, Prabhakar Mahadev Lad,
linux-renesas-soc@vger.kernel.org, Wolfram Sang
In-Reply-To: <66228ad3-c087-418c-925f-b9fd4a60fb16@sirena.org.uk>
On Mon, Jul 17, 2023 at 07:15:50PM +0100, Mark Brown wrote:
> On Mon, Jul 17, 2023 at 04:35:02PM +0000, Biju Das wrote:
>
> > The .device_get_match_data callbacks are missing for I2C and SPI bus subsystems.
> > Can you please throw some lights on this?
>
> It's the first time I've ever heard of that callback, I don't know why
> whoever added it wouldn't have done those buses in particular or if it
> just didn't happen. Try adding it and if it works send the patches?
I think there is a disconnect. Right now device_get_match_data callbacks
are part of fwnode_operations. I was proposing to add another optional
device_get_match_data callback to 'struct bus_type' to allow individual
buses control how match data is handled, before (or after) jumping into
the fwnode-backed device_get_match_data callbacks.
Thanks.
--
Dmitry
^ permalink raw reply
* RE: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
From: Biju Das @ 2023-07-17 18:27 UTC (permalink / raw)
To: Mark Brown
Cc: Dmitry Torokhov, Mike Looijmans, Andreas Helbech Kleist,
Geert Uytterhoeven, Uwe Kleine-König,
linux-input@vger.kernel.org, Prabhakar Mahadev Lad,
linux-renesas-soc@vger.kernel.org, Wolfram Sang, Andy Shevchenko
In-Reply-To: <66228ad3-c087-418c-925f-b9fd4a60fb16@sirena.org.uk>
> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> Sent: Monday, July 17, 2023 7:16 PM
> To: Biju Das <biju.das.jz@bp.renesas.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Mike Looijmans
> <mike.looijmans@topic.nl>; Andreas Helbech Kleist
> <andreaskleist@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>;
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de>; linux-
> input@vger.kernel.org; Prabhakar Mahadev Lad <prabhakar.mahadev-
> lad.rj@bp.renesas.com>; linux-renesas-soc@vger.kernel.org; Wolfram Sang
> <wsa+renesas@sang-engineering.com>
> Subject: Re: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
>
> On Mon, Jul 17, 2023 at 04:35:02PM +0000, Biju Das wrote:
>
> > The .device_get_match_data callbacks are missing for I2C and SPI bus
> subsystems.
> > Can you please throw some lights on this?
>
> It's the first time I've ever heard of that callback, I don't know why
> whoever added it wouldn't have done those buses in particular or if it
> just didn't happen. Try adding it and if it works send the patches?
I need to investigate at some point later,
Currently only OF and ACPI have these callbacks.
[1]
https://elixir.bootlin.com/linux/v6.0-rc4/source/drivers/of/property.c#L1507
[2]
https://elixir.bootlin.com/linux/v6.0-rc4/source/drivers/acpi/property.c#L1587
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
From: Mark Brown @ 2023-07-17 18:15 UTC (permalink / raw)
To: Biju Das
Cc: Dmitry Torokhov, Mike Looijmans, Andreas Helbech Kleist,
Geert Uytterhoeven, Uwe Kleine-König,
linux-input@vger.kernel.org, Prabhakar Mahadev Lad,
linux-renesas-soc@vger.kernel.org, Wolfram Sang
In-Reply-To: <OS0PR01MB592264ADC86061AB003048DD863BA@OS0PR01MB5922.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
On Mon, Jul 17, 2023 at 04:35:02PM +0000, Biju Das wrote:
> The .device_get_match_data callbacks are missing for I2C and SPI bus subsystems.
> Can you please throw some lights on this?
It's the first time I've ever heard of that callback, I don't know why
whoever added it wouldn't have done those buses in particular or if it
just didn't happen. Try adding it and if it works send the patches?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 08/10] HID: i2c-hid: Support being a panel follower
From: Doug Anderson @ 2023-07-17 18:15 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Frank Rowand, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Sam Ravnborg, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
dri-devel, Dmitry Torokhov, linux-input, Daniel Vetter,
linux-kernel, hsinyi, cros-qcom-dts-watchers, devicetree,
yangcong5, linux-arm-msm, Chris Morgan
In-Reply-To: <CAD=FV=VbdeomBGbWhppY+5TOSwt64GWBHga68OXFwsnO4gg4UA@mail.gmail.com>
Benjamin,
On Mon, Jun 26, 2023 at 3:49 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Benjamin,
>
> On Thu, Jun 8, 2023 at 8:37 AM Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> >
> > > +static const struct drm_panel_follower_funcs i2c_hid_core_panel_follower_funcs = {
> > > + .panel_prepared = i2c_hid_core_panel_prepared,
> > > + .panel_unpreparing = i2c_hid_core_panel_unpreparing,
> > > +};
> >
> > Can we make that above block at least behind a Kconfig?
> >
> > i2c-hid is often used for touchpads, and the notion of drm panel has
> > nothing to do with them. So I'd be more confident if we could disable
> > that code if not required.
>
> Now that other concerns are addressed, I started trying to write up a
> v3 and I found myself writing this as the description of the Kconfig
> entry:
>
> --
> config I2C_HID_SUPPORT_PANEL_FOLLOWER
> bool "Support i2c-hid devices that must be power sequenced with a panel"
>
> Say Y here if you want support for i2c-hid devices that need to
> coordinate power sequencing with a panel. This is typically important
> when you have a panel and a touchscreen that share power rails or
> reset GPIOs. If you say N here then the kernel will not try to honor
> any shared power sequencing for your hardware. In the best case,
> ignoring power sequencing when it's needed will draw extra power. In
> the worst case this will prevent your hardware from functioning or
> could even damage your hardware.
>
> If unsure, say Y.
>
> --
>
> I can certainly go that way, but I just wanted to truly make sure
> that's what we want. Specifically:
>
> 1. If we put the panel follower code behind a Kconfig then we actually
> have no idea if a touchscreen was intended to be a panel follower.
> Specifically the panel follower API is the one that detects the
> connection between the panel and the i2c-hid device, so without being
> able to call the panel follower API we have no idea that an i2c-hid
> device was supposed to be a panel follower.
>
> 2. It is conceivable that power sequencing a device incorrectly could
> truly cause hardware damage.
>
> Together, those points mean that if you turn off the Kconfig entry and
> then try to boot on a device that needed that Kconfig setting that you
> might damage hardware. I can code it up that way if you want, but it
> worries me...
>
>
> Alternatives that I can think of:
>
> a) I could change the panel follower API so that panel followers are
> in charge of detecting the panel that they follow. Today, that looks
> like:
>
> panel_np = of_parse_phandle(dev->of_node, "panel", 0);
> if (panel_np)
> /* It's a panel follower */
> of_node_put(panel_np);
>
> ...so we could put that code in each touchscreen driver and then fail
> to probe i2c-hid if we detect that we're supposed to be a panel
> follower but the Kconfig is turned off. The above doesn't seem
> massively ideal since it duplicates code. Also, one reason why I put
> that code in drm_panel_add_follower() is that I think this concept
> will eventually be needed even for non-DT cases. I don't know how to
> write the non-DT code right now, though...
>
>
> b) I could open-code detect the panel follower case but leave the
> actual linking to the panel follower API. AKA add to i2c-hid:
>
> if (of_property_read_bool(dev->of_node, "panel"))
> /* It's a panel follower */
>
> ...that's a smaller bit of code, but feels like an abstraction
> violation. It also would need to be updated if/when we added support
> for non-DT panel followers.
>
>
> c) I could add a "static inline" implementation of b) to "drm_panel.h".
>
> That sounds great and I started doing it. ...but then realized that it
> means adding to drm_panel.h:
>
> #include <linux/device.h>
> #include <linux/of.h>
>
> ...because otherwise of_property_read_bool() isn't defined and "struct
> device" can't be dereferenced. That might be OK, but it looks as if
> folks have been working hard to avoid things like this in header
> files. Presumably it would get uglier if/when we added the non-DT
> case, as well. That being said, I can give it a shot...
>
> --
>
> At this point, I'm hoping for some advice. How important is it for you
> to have a Kconfig for "I2C_HID_SUPPORT_PANEL_FOLLOWER"?
>
> NOTE: even if I don't add the Kconfig, I could at least create a
> function for registering the panel follower that would get most of the
> panel follower logic out of the probe function. Would that be enough?
I'd love to send a new version of this patch series, but I'm still
stuck with the above issue. I'm hoping you might have a minute to
provide your thoughts. If I don't hear anything, I'll try a v3 where I
don't have the Kconfig for "I2C_HID_SUPPORT_PANEL_FOLLOWER" but just
try to pull a little more of the code out of the probe function.
Thanks for your time!
-Doug
^ permalink raw reply
* [PATCH v3] HID: Add introduction about HID for non-kernel programmers
From: Marco Morandini @ 2023-07-17 16:40 UTC (permalink / raw)
To: Peter Hutterer, Jiri Kosina, Benjamin Tissoires, linux-input,
Jonathan Corbet, linux-doc
Add an introduction about HID meant for the casual programmer
that is trying either to fix his device or to understand
what is going wrong.
Signed-off-by: Marco Morandini <marco.morandini@polimi.it>
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
---
v2: https://lore.kernel.org/linux-input/70fdef05-d3b8-e24b-77be-901bd5be369e@polimi.it/
changes:
- corrections suggested in https://lore.kernel.org/linux-input/20230627060437.GA726439@quokka/
- corrections suggested in https://lore.kernel.org/linux-input/f53e756f-7c81-1c79-23ea-b9009fdd2ef4@infradead.org/
- corrections suggested in https://lore.kernel.org/linux-input/20230710021034.GA600582@quokka/
- corrections suggested in https://lore.kernel.org/linux-input/20230717001544.GA129954@quokka/
- some rewording of Documentation/hid/hidreport-parsing.rst
Documentation/hid/hidintro.rst | 524 ++++++++++++++++++++++++
Documentation/hid/hidreport-parsing.rst | 49 +++
Documentation/hid/index.rst | 1 +
include/linux/hid.h | 23 ++
4 files changed, 597 insertions(+)
create mode 100644 Documentation/hid/hidintro.rst
create mode 100644 Documentation/hid/hidreport-parsing.rst
diff --git a/Documentation/hid/hidintro.rst b/Documentation/hid/hidintro.rst
new file mode 100644
index 000000000000..73523e315ebd
--- /dev/null
+++ b/Documentation/hid/hidintro.rst
@@ -0,0 +1,524 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+Introduction to HID report descriptors
+======================================
+
+This chapter is meant to give a broad overview of what HID report
+descriptors are, and of how a casual (non-kernel) programmer can deal
+with HID devices that are not working well with Linux.
+
+.. contents::
+ :local:
+ :depth: 2
+
+.. toctree::
+ :maxdepth: 2
+
+ hidreport-parsing
+
+
+Introduction
+============
+
+HID stands for Human Interface Device, and can be whatever device you
+are using to interact with a computer, be it a mouse, a touchpad, a
+tablet, a microphone.
+
+Many HID devices work out the box, even if their hardware is different.
+For example, mice can have any number of buttons; they may have a
+wheel; movement sensitivity differs between different models, and so
+on. Nonetheless, most of the time everything just works, without the
+need to have specialized code in the kernel for every mouse model
+developed since 1970.
+
+This is because modern HID devices do advertise their capabilities
+through the *HID report descriptor*, a fixed set of bytes describing
+exactly what *HID reports* may be sent between the device and the host
+and the meaning of each individual bit in those reports. For example,
+a HID Report Descriptor may specify that "in a report with ID 3 the
+bits from 8 to 15 is the delta x coordinate of a mouse".
+
+The HID report itself then merely carries the actual data values
+without any extra meta information. Note that HID reports may be sent
+from the device ("Input Reports", i.e. input events), to the device
+("Output Reports" to e.g. change LEDs) or used for device configuration
+("Feature reports"). A device may support one or more HID reports.
+
+The HID subsystem is in charge of parsing the HID report descriptors,
+and converts HID events into normal input device interfaces (see
+Documentation/hid/hid-transport.rst). Devices may misbehave because the
+HID report descriptor provided by the device is wrong, or because it
+needs to be dealt with in a special way, or because some special
+device or interaction mode is not handled by the default code.
+
+The format of HID report descriptors is described by two documents,
+available from the `USB Implementers Forum <https://www.usb.org/>`_
+`HID web page <https://www.usb.org/hid>`_ address:
+
+ * the `HID USB Device Class Definition
+ <https://www.usb.org/document-library/device-class-definition-hid-111>`_ (HID Spec from now on)
+ * the `HID Usage Tables <https://usb.org/document-library/hid-usage-tables-14>`_ (HUT from now on)
+
+The HID subsystem can deal with different transport drivers
+(USB, I2C, Bluetooth, etc.). See Documentation/hid/hid-transport.rst.
+
+Parsing HID report descriptors
+==============================
+
+The current list of HID devices can be found at ``/sys/bus/hid/devices/``.
+For each device, say ``/sys/bus/hid/devices/0003\:093A\:2510.0002/``,
+one can read the corresponding report descriptor::
+
+ $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
+ 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).|
+ 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....|
+ 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...|
+ 00000030 81 06 c0 c0 |....|
+ 00000034
+
+Optional: the HID report descriptor can be read also by
+directly accessing the hidraw driver [#hidraw]_.
+
+The basic structure of HID report descriptors is defined in the HID
+spec, while HUT "defines constants that can be interpreted by an
+application to identify the purpose and meaning of a data field in a
+HID report". Each entry is defined by at least two bytes, where the
+first one defines what type of value is following and is described in
+the HID spec, while the second one carries the actual value and is
+described in the HUT.
+
+HID report descriptors can, in principle, be painstakingly parsed by
+hand, byte by byte.
+
+A short introduction on how to do this is sketched in
+Documentation/hid/hidreport-parsing.rst; you only need to understand it
+if you need to patch HID report descriptors.
+
+In practice you should not parse HID report descriptors by hand; rather,
+you should use an existing parser. Among all the available ones
+
+ * the online `USB Descriptor and Request Parser
+ <http://eleccelerator.com/usbdescreqparser/>`_;
+ * `hidrdd <https://github.com/abend0c1/hidrdd>`_,
+ that provides very detailed and somewhat verbose descriptions
+ (verbosity can be useful if you are not familiar with HID report
+ descriptors);
+ * `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_,
+ a complete utility set that allows, among other things,
+ to record and replay the raw HID reports and to debug
+ and replay HID devices.
+ It is being actively developed by the Linux HID subsystem maintainers.
+
+Parsing the mouse HID report descriptor with `hid-tools
+<https://gitlab.freedesktop.org/libevdev/hid-tools>`_ leads to
+(explanations interposed)::
+
+ $ ./hid-decode /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
+ # device 0:0
+ # 0x05, 0x01, // Usage Page (Generic Desktop) 0
+ # 0x09, 0x02, // Usage (Mouse) 2
+ # 0xa1, 0x01, // Collection (Application) 4
+ # 0x09, 0x01, // Usage (Pointer) 6
+ # 0xa1, 0x00, // Collection (Physical) 8
+ # 0x05, 0x09, // Usage Page (Button) 10
+
+what follows is a button ::
+
+ # 0x19, 0x01, // Usage Minimum (1) 12
+ # 0x29, 0x03, // Usage Maximum (3) 14
+
+first button is button number 1, last button is button number 3 ::
+
+ # 0x15, 0x00, // Logical Minimum (0) 16
+ # 0x25, 0x01, // Logical Maximum (1) 18
+
+each button can send values from 0 up to including 1
+(i.e. they are binary buttons) ::
+
+ # 0x75, 0x01, // Report Size (1) 20
+
+each button is sent as exactly one bit ::
+
+ # 0x95, 0x03, // Report Count (3) 22
+
+and there are three of those bits (matching the three buttons) ::
+
+ # 0x81, 0x02, // Input (Data,Var,Abs) 24
+
+it's actual Data (not constant padding), they represent
+a single variable (Var) and their values are Absolute (not relative);
+See HID spec Sec. 6.2.2.5 "Input, Output, and Feature Items" ::
+
+ # 0x75, 0x05, // Report Size (5) 26
+
+five additional padding bits, needed to reach a byte ::
+
+ # 0x95, 0x01, // Report Count (1) 28
+
+those five bits are repeated only once ::
+
+ # 0x81, 0x01, // Input (Cnst,Arr,Abs) 30
+
+and take Constant (Cnst) values i.e. they can be ignored. ::
+
+ # 0x05, 0x01, // Usage Page (Generic Desktop) 32
+ # 0x09, 0x30, // Usage (X) 34
+ # 0x09, 0x31, // Usage (Y) 36
+ # 0x09, 0x38, // Usage (Wheel) 38
+
+The mouse has also two physical positions (Usage (X), Usage (Y))
+and a wheel (Usage (Wheel)) ::
+
+ # 0x15, 0x81, // Logical Minimum (-127) 40
+ # 0x25, 0x7f, // Logical Maximum (127) 42
+
+each of them can send values ranging from -127 up to including 127 ::
+
+ # 0x75, 0x08, // Report Size (8) 44
+
+which is represented by eight bits ::
+
+ # 0x95, 0x03, // Report Count (3) 46
+
+and there are three of those eight bits, matching X, Y and Wheel. ::
+
+ # 0x81, 0x06, // Input (Data,Var,Rel) 48
+
+This time the data values are Relative (Rel), i.e. they represent
+the change from the previously sent report (event) ::
+
+ # 0xc0, // End Collection 50
+ # 0xc0, // End Collection 51
+ #
+ R: 52 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 c0 c0
+ N: device 0:0
+ I: 3 0001 0001
+
+
+This Report Descriptor tells us that the mouse input will be
+transmitted using four bytes: the first one for the buttons (three
+bits used, five for padding), the last three for the mouse X, Y and
+wheel changes, respectively.
+
+Indeed, for any event, the mouse will send a *report* of four bytes.
+We can check the values sent by resorting e.g. to the `hid-recorder`
+tool, from `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_:
+The sequence of bytes sent by clicking and releasing button 1, then button 2, then button 3 is::
+
+ $ sudo ./hid-recorder /dev/hidraw1
+
+ ....
+ output of hid-decode
+ ....
+
+ # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000000.000000 4 01 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000000.183949 4 00 00 00 00
+ # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000001.959698 4 02 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000002.103899 4 00 00 00 00
+ # Button: 0 0 1 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000004.855799 4 04 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000005.103864 4 00 00 00 00
+
+This example shows that when button 2 is clicked,
+the bytes ``02 00 00 00`` are sent, and the immediately subsequent
+event (``00 00 00 00``) is the release of button 2 (no buttons are
+pressed, remember that the data values are *absolute*).
+
+If instead one clicks and holds button 1, then clicks and holds button
+2, releases button 1, and finally releases button 2, the reports are::
+
+ # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000044.175830 4 01 00 00 00
+ # Button: 1 1 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000045.975997 4 03 00 00 00
+ # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000047.407930 4 02 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000049.199919 4 00 00 00 00
+
+where with ``03 00 00 00`` both buttons are pressed, and with the
+subsequent ``02 00 00 00`` button 1 is released while button 2 is still
+active.
+
+Output, Input and Feature Reports
+---------------------------------
+
+HID devices can have Input Reports, like in the mouse example, Output
+Reports, and Feature Reports. "Output" means that the information is
+sent to the device. For example, a joystick with force feedback will
+have some output; the led of a keyboard would need an output as well.
+"Input" means that data come from the device.
+
+"Feature"s are not meant to be consumed by the end user and define
+configuration options for the device. They can be queried from the host;
+when declared as *Volatile* they should be changed by the host.
+
+
+Collections, Report IDs and Evdev events
+========================================
+
+A single device can logically group data into different independent
+sets, called a *Collection*. Collections can be nested and there are
+different types of collections (see the HID spec 6.2.2.6
+"Collection, End Collection Items" for details).
+
+Different reports are identified by means of different *Report ID*
+fields, i.e. a number identifying the structure of the immediately
+following report.
+Whenever a Report ID is needed it is transmitted as the first byte of
+any report. A device with only one supported HID report (like the mouse
+example above) may omit the report ID.
+
+Consider the following HID report descriptor::
+
+ 05 01 09 02 A1 01 85 01 05 09 19 01 29 05 15 00
+ 25 01 95 05 75 01 81 02 95 01 75 03 81 01 05 01
+ 09 30 09 31 16 00 F8 26 FF 07 75 0C 95 02 81 06
+ 09 38 15 80 25 7F 75 08 95 01 81 06 05 0C 0A 38
+ 02 15 80 25 7F 75 08 95 01 81 06 C0 05 01 09 02
+ A1 01 85 02 05 09 19 01 29 05 15 00 25 01 95 05
+ 75 01 81 02 95 01 75 03 81 01 05 01 09 30 09 31
+ 16 00 F8 26 FF 07 75 0C 95 02 81 06 09 38 15 80
+ 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 80 25
+ 7F 75 08 95 01 81 06 C0 05 01 09 07 A1 01 85 05
+ 05 07 15 00 25 01 09 29 09 3E 09 4B 09 4E 09 E3
+ 09 E8 09 E8 09 E8 75 01 95 08 81 02 95 00 81 01
+ C0 05 0C 09 01 A1 01 85 06 15 00 25 01 75 01 95
+ 01 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
+ 06 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
+ 06 C0 05 0C 09 01 A1 01 85 03 09 05 15 00 26 FF
+ 00 75 08 95 02 B1 02 C0
+
+After parsing it (try to parse it on your own using the suggested
+tools!) one can see that the device presents two ``Mouse`` Application
+Collections (with reports identified by Reports IDs 1 and 2,
+respectively), a ``Keypad`` Application Collection (whose report is
+identified by the Report ID 5) and two ``Consumer Controls`` Application
+Collections, (with Report IDs 6 and 3, respectively). Note, however,
+that a device can have different Report IDs for the same Application
+Collection.
+
+The data sent will begin with the Report ID byte, and will be followed
+by the corresponding information. For example, the data transmitted for
+the last consumer control::
+
+ 0x05, 0x0C, // Usage Page (Consumer)
+ 0x09, 0x01, // Usage (Consumer Control)
+ 0xA1, 0x01, // Collection (Application)
+ 0x85, 0x03, // Report ID (3)
+ 0x09, 0x05, // Usage (Headphone)
+ 0x15, 0x00, // Logical Minimum (0)
+ 0x26, 0xFF, 0x00, // Logical Maximum (255)
+ 0x75, 0x08, // Report Size (8)
+ 0x95, 0x02, // Report Count (2)
+ 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
+ 0xC0, // End Collection
+
+will be of three bytes: the first for the Report ID (3), the next two
+for the headphone, with two (``Report Count (2)``) bytes
+(``Report Size (8)``), each ranging from 0 (``Logical Minimum (0)``)
+to 255 (``Logical Maximum (255)``).
+
+All the Input data sent by the device should be translated into
+corresponding Evdev events, so that the remaining part of the stack can
+know what is going on, e.g. the bit for the first button translates into
+the ``EV_KEY/BTN_LEFT`` evdev event and relative X movement translates
+into the ``EV_REL/REL_X`` evdev event".
+
+Events
+======
+
+In Linux, one ``/dev/input/event*`` is created for each ``Application
+Collection``. Going back to the mouse example, and repeating the
+sequence where one clicks and holds button 1, then clicks and holds
+button 2, releases button 1, and finally releases button 2, one gets::
+
+ $ sudo libinput record /dev/input/event1
+ # libinput record
+ version: 1
+ ndevices: 1
+ libinput:
+ version: "1.23.0"
+ git: "unknown"
+ system:
+ os: "opensuse-tumbleweed:20230619"
+ kernel: "6.3.7-1-default"
+ dmi: "dmi:bvnHP:bvrU77Ver.01.05.00:bd03/24/2022:br5.0:efr20.29:svnHP:pnHPEliteBook64514inchG9NotebookPC:pvr:rvnHP:rn89D2:rvrKBCVersion14.1D.00:cvnHP:ct10:cvr:sku5Y3J1EA#ABZ:"
+ devices:
+ - node: /dev/input/event1
+ evdev:
+ # Name: PixArt HP USB Optical Mouse
+ # ID: bus 0x3 vendor 0x3f0 product 0x94a version 0x111
+ # Supported Events:
+ # Event type 0 (EV_SYN)
+ # Event type 1 (EV_KEY)
+ # Event code 272 (BTN_LEFT)
+ # Event code 273 (BTN_RIGHT)
+ # Event code 274 (BTN_MIDDLE)
+ # Event type 2 (EV_REL)
+ # Event code 0 (REL_X)
+ # Event code 1 (REL_Y)
+ # Event code 8 (REL_WHEEL)
+ # Event code 11 (REL_WHEEL_HI_RES)
+ # Event type 4 (EV_MSC)
+ # Event code 4 (MSC_SCAN)
+ # Properties:
+ name: "PixArt HP USB Optical Mouse"
+ id: [3, 1008, 2378, 273]
+ codes:
+ 0: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] # EV_SYN
+ 1: [272, 273, 274] # EV_KEY
+ 2: [0, 1, 8, 11] # EV_REL
+ 4: [4] # EV_MSC
+ properties: []
+ hid: [
+ 0x05, 0x01, 0x09, 0x02, 0xa1, 0x01, 0x09, 0x01, 0xa1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x03,
+ 0x15, 0x00, 0x25, 0x01, 0x95, 0x08, 0x75, 0x01, 0x81, 0x02, 0x05, 0x01, 0x09, 0x30, 0x09, 0x31,
+ 0x09, 0x38, 0x15, 0x81, 0x25, 0x7f, 0x75, 0x08, 0x95, 0x03, 0x81, 0x06, 0xc0, 0xc0
+ ]
+ udev:
+ properties:
+ - ID_INPUT=1
+ - ID_INPUT_MOUSE=1
+ - LIBINPUT_DEVICE_GROUP=3/3f0/94a:usb-0000:05:00.3-2
+ quirks:
+ events:
+ # Current time is 12:31:56
+ - evdev:
+ - [ 0, 0, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 0, 0, 1, 272, 1] # EV_KEY / BTN_LEFT 1
+ - [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
+ - evdev:
+ - [ 1, 207892, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 1, 207892, 1, 273, 1] # EV_KEY / BTN_RIGHT 1
+ - [ 1, 207892, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1207ms
+ - evdev:
+ - [ 2, 367823, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 2, 367823, 1, 272, 0] # EV_KEY / BTN_LEFT 0
+ - [ 2, 367823, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1160ms
+ # Current time is 12:32:00
+ - evdev:
+ - [ 3, 247617, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 3, 247617, 1, 273, 0] # EV_KEY / BTN_RIGHT 0
+ - [ 3, 247617, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +880ms
+
+Note: if ``libinput record`` is not available on your system try using
+``evemu-record``.
+
+When something does not work
+============================
+
+There can be a number of reasons why a device does not behave
+correctly. For example
+
+* The HID report descriptor provided by the HID device may be wrong
+ because e.g.
+
+ * it does not follow the standard, so that the kernel
+ will not able to make sense of the HID report descriptor;
+ * the HID report descriptor *does not match* what is actually
+ sent by the device (this can be verified by reading the raw HID
+ data);
+* the HID report descriptor may need some "quirks" (see later on).
+
+As a consequence, a ``/dev/input/event*`` may not be created
+for each Application Collection, and/or the events
+there may not match what you would expect.
+
+
+Quirks
+------
+
+There are some known peculiarities of HID devices that the kernel
+knows how to fix - these are called the HID quirks and a list of those
+is available in `include/linux/hid.h`.
+
+Should this be the case, it should be enough to add the required quirk
+in the kernel, for the HID device at hand. This can be done in the file
+`drivers/hid/hid-quirks.c`. How to do it should be relatively
+straightforward after looking into the file.
+
+The list of currently defined quirks, from `include/linux/hid.h`, is
+
+.. kernel-doc:: include/linux/hid.h
+ :doc: HID quirks
+
+Quirks for USB devices can be specified while loading the usbhid module,
+see ``modinfo usbhid``, although the proper fix should go into
+hid-quirks.c and **be submitted upstream**.
+See Documentation/process/submitting-patches.rst for guidelines on how
+to submit a patch. Quirks for other busses need to go into hid-quirks.c.
+
+Fixing HID report descriptors
+-----------------------------
+
+Should you need to patch HID report descriptors the easiest way is to
+resort to eBPF, as described in Documentation/hid/hid-bpf.rst.
+
+Basically, you can change any byte of the original HID report
+descriptor. The examples in samples/hid should be a good starting point
+for your code, see e.g. `samples/hid/hid_mouse.bpf.c`::
+
+ SEC("fmod_ret/hid_bpf_rdesc_fixup")
+ int BPF_PROG(hid_rdesc_fixup, struct hid_bpf_ctx *hctx)
+ {
+ ....
+ data[39] = 0x31;
+ data[41] = 0x30;
+ return 0;
+ }
+
+Of course this can be also done within the kernel source code, see e.g.
+`drivers/hid/hid-aureal.c` or `drivers/hid/hid-samsung.c` for a slightly
+more complex file.
+
+Check Documentation/hid/hidreport-parsing.rst if you need any help
+navigating the HID manuals and understanding the exact meaning of
+the HID report descriptor hex numbers.
+
+Whatever solution you come up with, please remember to **submit the
+fix to the HID maintainers**, so that it can be directly integrated in
+the kernel and that particular HID device will start working for
+everyone else. See Documentation/process/submitting-patches.rst for
+guidelines on how to do this.
+
+
+Modifying the transmitted data on the fly
+-----------------------------------------
+
+Using eBPF it is also possible to modify the data exchanged with the
+device. See again the examples in `samples/hid`.
+
+Again, **please post your fix**, so that it can be integrated in the
+kernel!
+
+Writing a specialized driver
+----------------------------
+
+This should really be your last resort.
+
+
+.. rubric:: Footnotes
+
+.. [#hidraw] read hidraw: see Documentation/hid/hidraw.rst and
+ file `samples/hidraw/hid-example.c` for an example.
+ The output of ``hid-example`` would be, for the same mouse::
+
+ $ sudo ./hid-example
+ Report Descriptor Size: 52
+ Report Descriptor:
+ 5 1 9 2 a1 1 9 1 a1 0 5 9 19 1 29 3 15 0 25 1 75 1 95 3 81 2 75 5 95 1 81 1 5 1 9 30 9 31 9 38 15 81 25 7f 75 8 95 3 81 6 c0 c0
+
+ Raw Name: PixArt USB Optical Mouse
+ Raw Phys: usb-0000:05:00.4-2.3/input0
+ Raw Info:
+ bustype: 3 (USB)
+ vendor: 0x093a
+ product: 0x2510
+ ...
diff --git a/Documentation/hid/hidreport-parsing.rst b/Documentation/hid/hidreport-parsing.rst
new file mode 100644
index 000000000000..1d3c17f29f2b
--- /dev/null
+++ b/Documentation/hid/hidreport-parsing.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+Manual parsing of HID report descriptors
+========================================
+
+Consider again the mouse HID report descriptor
+introduced in Documentation/hid/hidintro.rst::
+
+ $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
+ 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).|
+ 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....|
+ 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...|
+ 00000030 81 06 c0 c0 |....|
+ 00000034
+
+and try to parse it by hand.
+
+Start with the first number, 0x05: it carries 2 bits for the
+length of the item, 2 bits for the type of the item and 4 bits for the
+function::
+
+ +----------+
+ | 00000101 |
+ +----------+
+ ^^
+ ---- Length of data (see HID spec 6.2.2.2)
+ ^^
+ ------ Type of the item (see HID spec 6.2.2.2, then jump to 6.2.2.7)
+ ^^^^
+ --------- Function of the item (see HID spec 6.2.2.7, then HUT Sec 3)
+
+In our case, the length is 1 byte, the type is ``Global`` and the
+function is ``Usage Page``, thus for parsing the value 0x01 in the second byte
+we need to refer to HUT Sec 3.
+
+The second number is the actual data, and its meaning can be found in
+the HUT. We have a ``Usage Page``, thus we need to refer to HUT
+Sec. 3, "Usage Pages"; from there, one sees that ``0x01`` stands for
+``Generic Desktop Page``.
+
+Moving now to the second two bytes, and following the same scheme,
+``0x09`` (i.e. ``00001001``) will be followed by one byte (``01``)
+and is a ``Local`` item (``10``). Thus, the meaning of the remaining four bits
+(``0000``) is given in the HID spec Sec. 6.2.2.8 "Local Items", so that
+we have a ``Usage``. From HUT, Sec. 4, "Generic Desktop Page", we see that
+0x02 stands for ``Mouse``.
+
+The following numbers can be parsed in the same way.
diff --git a/Documentation/hid/index.rst b/Documentation/hid/index.rst
index b2028f382f11..af02cf7cfa82 100644
--- a/Documentation/hid/index.rst
+++ b/Documentation/hid/index.rst
@@ -7,6 +7,7 @@ Human Interface Devices (HID)
.. toctree::
:maxdepth: 1
+ hidintro
hiddev
hidraw
hid-sensor
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 7f2e8ba7d783..8d1699f355ec 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -341,6 +341,29 @@ struct hid_item {
*/
#define MAX_USBHID_BOOT_QUIRKS 4
+/**
+ * DOC: HID quirks
+ * | @HID_QUIRK_NOTOUCH:
+ * | @HID_QUIRK_IGNORE: ignore this device
+ * | @HID_QUIRK_NOGET:
+ * | @HID_QUIRK_HIDDEV_FORCE:
+ * | @HID_QUIRK_BADPAD:
+ * | @HID_QUIRK_MULTI_INPUT:
+ * | @HID_QUIRK_HIDINPUT_FORCE:
+ * | @HID_QUIRK_ALWAYS_POLL:
+ * | @HID_QUIRK_INPUT_PER_APP:
+ * | @HID_QUIRK_X_INVERT:
+ * | @HID_QUIRK_Y_INVERT:
+ * | @HID_QUIRK_SKIP_OUTPUT_REPORTS:
+ * | @HID_QUIRK_SKIP_OUTPUT_REPORT_ID:
+ * | @HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP:
+ * | @HID_QUIRK_HAVE_SPECIAL_DRIVER:
+ * | @HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE:
+ * | @HID_QUIRK_FULLSPEED_INTERVAL:
+ * | @HID_QUIRK_NO_INIT_REPORTS:
+ * | @HID_QUIRK_NO_IGNORE:
+ * | @HID_QUIRK_NO_INPUT_SYNC:
+ */
/* BIT(0) reserved for backward compatibility, was HID_QUIRK_INVERT */
#define HID_QUIRK_NOTOUCH BIT(1)
#define HID_QUIRK_IGNORE BIT(2)
--
2.41.0
^ permalink raw reply related
* Re: [PATCH v2] HID: Add introduction about HID for non-kernel programmers
From: Marco Morandini @ 2023-07-17 16:38 UTC (permalink / raw)
To: Peter Hutterer
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, Jonathan Corbet,
linux-doc
In-Reply-To: <20230717001544.GA129954@quokka>
>> I've not understood how to get rid of that colon, and I would prefer to leave the
>> explanation _after_ the corresponding code block, and not move it before.
>
> https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#literal-blocks
>
> This suggests that if you write it as "what follows is a button ::"
> (i.e. space before ::) that should render it without a colon.
>
> [...]
>
I.e. RTFM :(
Apologize for this; I'm going to send v3 with the space before ::.
Thank you,
Marco
^ permalink raw reply
* RE: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
From: Biju Das @ 2023-07-17 16:35 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mike Looijmans, Andreas Helbech Kleist, Geert Uytterhoeven,
Uwe Kleine-König, linux-input@vger.kernel.org,
Prabhakar Mahadev Lad, linux-renesas-soc@vger.kernel.org,
Mark Brown, Wolfram Sang
In-Reply-To: <ZLVlIPHdmEGdG5D1@google.com>
+ Mark and Wolfram
> -----Original Message-----
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Sent: Monday, July 17, 2023 4:58 PM
> To: Biju Das <biju.das.jz@bp.renesas.com>
> Cc: Mike Looijmans <mike.looijmans@topic.nl>; Andreas Helbech Kleist
> <andreaskleist@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>;
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de>; linux-
> input@vger.kernel.org; Prabhakar Mahadev Lad <prabhakar.mahadev-
> lad.rj@bp.renesas.com>; linux-renesas-soc@vger.kernel.org
> Subject: Re: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
>
> Hi Biju,
>
> On Mon, Jul 17, 2023 at 02:17:55PM +0100, Biju Das wrote:
> > The exc3000_id.driver_data could store a pointer to the info, like for
> > ACPI/DT-based matching, making I2C, ACPI and DT-based matching more
> > similar.
> >
> > After that, we can simplify the probe() by replacing device_get_
> > match_data() and i2c_match_id() by i2c_get_match_data() as we have
> > similar I2C, ACPI and DT-based matching table.
>
> Have you considered enhancing device_get_match_data() to allow for bus-
> specific "get_match_data" implementations? This way the drivers would
> simply call device_get_match_data() and not care if they are I2C, SPI,
> or something else...
The .device_get_match_data callbacks are missing for I2C and SPI bus subsystems.
Can you please throw some lights on this?
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH] Input: xpad - add support for HyperX Game Controllers
From: Dmitry Torokhov @ 2023-07-17 16:11 UTC (permalink / raw)
To: Nguyen, Max; +Cc: linux-input@vger.kernel.org
In-Reply-To: <MW4PR84MB178010F3A35DFF92FE8CC909EB37A@MW4PR84MB1780.NAMPRD84.PROD.OUTLOOK.COM>
On Thu, Jul 13, 2023 at 09:18:37PM +0000, Nguyen, Max wrote:
> Hi Dmitry,
>
> There is an option on outlook to change outbound mails to plain text instead of HTML. Would this work?
Sorry but I do not know if that is enough. I have not used Outlook for
more than 15 years.
>
> Regards,
> Max
>
> -----Original Message-----
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Sent: Thursday, July 13, 2023 10:38 AM
> To: Nguyen, Max <maxwell.nguyen@hp.com>
> Cc: linux-input@vger.kernel.org
> Subject: Re: [PATCH] Input: xpad - add support for HyperX Game Controllers
>
> CAUTION: External Email
>
> Hi Max,
>
> On Thu, Jul 13, 2023 at 12:43:19AM +0000, Nguyen, Max wrote:
> > Hi Dmitry,
> >
> > I have sent over a new patch. Let me know the whitespace-damage issue is resolved. I will need to adjust the acks since I had missed it.
> >
>
> It looks like you are using Outlook, and it will not work. It sends a mix of HTML and plain text, and it mangles the plain text.
>
> You need to look into setting up "git send-email" or mutt or something else besides Outlook to send kernel patches.
>
> Thanks.
>
> --
> Dmitry
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: exc3000 - Simplify probe()
From: Dmitry Torokhov @ 2023-07-17 15:58 UTC (permalink / raw)
To: Biju Das
Cc: Mike Looijmans, Andreas Helbech Kleist, Geert Uytterhoeven,
Uwe Kleine-König, linux-input, Prabhakar Mahadev Lad,
linux-renesas-soc
In-Reply-To: <20230717131756.240645-2-biju.das.jz@bp.renesas.com>
Hi Biju,
On Mon, Jul 17, 2023 at 02:17:55PM +0100, Biju Das wrote:
> The exc3000_id.driver_data could store a pointer to the info,
> like for ACPI/DT-based matching, making I2C, ACPI and DT-based
> matching more similar.
>
> After that, we can simplify the probe() by replacing device_get_
> match_data() and i2c_match_id() by i2c_get_match_data() as we have
> similar I2C, ACPI and DT-based matching table.
Have you considered enhancing device_get_match_data() to allow for
bus-specific "get_match_data" implementations? This way the drivers
would simply call device_get_match_data() and not care if they are I2C,
SPI, or something else...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH resend 2] Input: gpio-keys - convert to dev_err_probe()
From: Dmitry Torokhov @ 2023-07-17 15:52 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-input, linux-kernel
In-Reply-To: <d225a837c50e2b19a41555a8f7ce0f94b1689aa4.1689600353.git.geert+renesas@glider.be>
On Mon, Jul 17, 2023 at 03:27:05PM +0200, Geert Uytterhoeven wrote:
> Use the dev_err_probe() helper, instead of open-coding the same
> operation.
>
> While at it, invert the error checking logic to simplify code flow.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH resend 2] Input: gpio-keys - convert to dev_err_probe()
From: Geert Uytterhoeven @ 2023-07-17 13:27 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Geert Uytterhoeven
Use the dev_err_probe() helper, instead of open-coding the same
operation.
While at it, invert the error checking logic to simplify code flow.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/input/keyboard/gpio_keys.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 20250b072a7a01c5..7e8342ef7a79b17f 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -523,18 +523,15 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
NULL, GPIOD_IN, desc);
if (IS_ERR(bdata->gpiod)) {
error = PTR_ERR(bdata->gpiod);
- if (error == -ENOENT) {
- /*
- * GPIO is optional, we may be dealing with
- * purely interrupt-driven setup.
- */
- bdata->gpiod = NULL;
- } else {
- if (error != -EPROBE_DEFER)
- dev_err(dev, "failed to get gpio: %d\n",
- error);
- return error;
- }
+ if (error != -ENOENT)
+ return dev_err_probe(dev, error,
+ "failed to get gpio\n");
+
+ /*
+ * GPIO is optional, we may be dealing with
+ * purely interrupt-driven setup.
+ */
+ bdata->gpiod = NULL;
}
} else if (gpio_is_valid(button->gpio)) {
/*
--
2.34.1
^ 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