* [PATCH v3 1/2] dt-bindings: HID: i2c-hid: ilitek: Introduce bindings for Ilitek ili9882t
From: Cong Yang @ 2023-06-07 13:34 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov, jikos,
benjamin.tissoires, dianders, hsinyi
Cc: linux-input, devicetree, linux-kernel, Cong Yang
In-Reply-To: <20230607133458.4075667-1-yangcong5@huaqin.corp-partner.google.com>
The ili9882t touch screen chip same as Elan eKTH6915 controller
has a reset gpio. The difference is that ili9882t needs to use
vccio-supply instead of vcc33-supply. Doug's series[1] allows panels
and touchscreens to power on/off together, let's add a phandle for this.
[1]: https: //lore.kernel.org/all/20230523193017.4109557-1-dianders@chromium.org/
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
---
.../bindings/input/ilitek,ili9882t.yaml | 67 +++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
diff --git a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
new file mode 100644
index 000000000000..f69fa3aaf4c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ilitek,ili9882t.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ili9882t touchscreen controller
+
+maintainers:
+ - Dmitry Torokhov <dmitry.torokhov@gmail.com>
+
+description:
+ Supports the Ilitek ili9882t touchscreen controller.
+ This touchscreen controller uses the i2c-hid protocol with a reset GPIO.
+
+properties:
+ compatible:
+ items:
+ - const: ilitek,ili9882t
+
+ reg:
+ const: 0x41
+
+ interrupts:
+ maxItems: 1
+
+ panel:
+ description: If this is a touchscreen, the panel it's connected to. This
+ indicates that the panel and touchscreen are expected to be power
+ sequenced together.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ reset-gpios:
+ description: Reset GPIO.
+
+
+ vccio-supply:
+ description: The 1.8V supply to the touchscreen.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vccio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen: touchscreen@41 {
+ compatible = "ilitek,ili9882t";
+ reg = <0x41>;
+
+ interrupt-parent = <&pio>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+
+ reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>;
+ vccio-supply = <&mt6366_vio18_reg>;
+ };
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v3 0/2] Add ili9882t bindings and timing
From: Cong Yang @ 2023-06-07 13:34 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov, jikos,
benjamin.tissoires, dianders, hsinyi
Cc: linux-input, devicetree, linux-kernel, Cong Yang
Add bindings for Ilitek. The ili9882t touch screen chip same as
Elan eKTH6915 controller has a reset gpio. The difference is that
ilitek9882 needs to use vccio-supply instead of vcc33-supply.
From Dmitry suggestion, it would make more sense to distinguish the
binging of ili9882 and eKTH6915.
From The datasheet specifies there should be 60ms between touch SDA
sleep and panel RESX. so we can add the 65 ms delay in i2c_hid_core_suspend.
Changes in v3:
- PATCH 1/2: Introduce bindings for Ilitek.
- Link to v2: https://lore.kernel.org/all/20230605060524.1178164-1-yangcong5@huaqin.corp-partner.google.com/
Changes in v2:
- PATCH 1/2: fix ran make dt_binding_check warnings/errors.
- PATCH 1/2: remove oneOf,just enum.
- Link to v1: https://lore.kernel.org/all/20230602140948.2138668-1-yangcong5@huaqin.corp-partner.google.com/
Cong Yang (2):
dt-bindings: HID: i2c-hid: ilitek: Introduce bindings for Ilitek
ili9882t
HID: i2c-hid: elan: Add ili9882t timing
.../bindings/input/ilitek,ili9882t.yaml | 67 +++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid-of-elan.c | 20 ++++--
2 files changed, 83 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
--
2.25.1
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Handle timeout differently from busy
From: Benjamin Tissoires @ 2023-06-07 10:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Linux regressions mailing list, Jiri Kosina, Bastien Nocera,
linux-input, linux-kernel, Peter F . Patel-Schneider,
Filipe Laíns, Nestor Lopez Casado, Mark Lord
In-Reply-To: <2023060703-colony-shakily-3514@gregkh>
On Wed, Jun 7, 2023 at 11:46 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jun 06, 2023 at 08:37:26PM +0200, Benjamin Tissoires wrote:
> > On Tue, Jun 6, 2023 at 8:18 PM Linux regression tracking (Thorsten
> > Leemhuis) <regressions@leemhuis.info> wrote:
> > >
> > >
> > >
> > > On 06.06.23 15:27, Jiri Kosina wrote:
> > > > On Mon, 5 Jun 2023, Linux regression tracking (Thorsten Leemhuis) wrote:
> > > >
> > > >>>>> If an attempt at contacting a receiver or a device fails because the
> > > >>>>> receiver or device never responds, don't restart the communication, only
> > > >>>>> restart it if the receiver or device answers that it's busy, as originally
> > > >>>>> intended.
> > > >>>>>
> > > >>>>> This was the behaviour on communication timeout before commit 586e8fede795
> > > >>>>> ("HID: logitech-hidpp: Retry commands when device is busy").
> > > >>>>>
> > > >>>>> This fixes some overly long waits in a critical path on boot, when
> > > >>>>> checking whether the device is connected by getting its HID++ version.
> > > >>>>>
> > > >>>>> Signed-off-by: Bastien Nocera <hadess@hadess.net>
> > > >>>>> Suggested-by: Mark Lord <mlord@pobox.com>
> > > >>>>> Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy")
> > > >>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412
> > > >>> [...]
> > > >>>>
> > > >>>> I have applied this even before getting confirmation from the reporters in
> > > >>>> bugzilla, as it's the right thing to do anyway.
> > > >>>
> > > >>> Unfortunately it doesn't seem to cure the reported issue (while reverting
> > > >>> 586e8fede79 does):
> > > >>
> > > >> BTW, remind me again: was fixing this by reverting 586e8fede79 for now a
> > > >> option? I guess it's not, but if I'm wrong I wonder if that might at
> > > >> this point be the best way forward.
> > > >
> > > > This should now all be fixed by
> > > >
> > > > https://git.kernel.org/linus/7c28afd5512e371773dbb2bf95a31ed5625651d9
> > >
> > > Jiri, Benjamin, many many thx for working on this.
> > >
> > > Hmmm. No CC: <stable... tag.
> > >
> > > Should we ask Greg to pick this up for 6.3 now, or better wait a few
> > > days? He currently already has 6199d23c91ce ("HID: logitech-hidpp:
> > > Handle timeout differently from busy") in his queue for the next 6.3.y
> > > release.
> >
> > Well, the Fixes: tag supposedly is enough to let the stable folks to
> > pick it up.
>
> No, not at all, please see:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to do this properly.
>
> (hint, we need a cc: stable@ in the signed-off-by area.)
>
> We only pick up stuff with "Fixes:" semi-often, sometimes never,
> depending on our workload. Never rely on that.
Oh right. Given that those patches eventually end up in stable sooner
or later I made the shortcut in my head. Thanks for correcting that :)
>
> It's been this way for 18+ years now, nothing new :)
>
> > But you are right, let's Cc Greg for a quicker inclusion
> > in the 6.3 tree.
> >
> > Greg, would you mind adding the commit above (7c28afd5512e37) onto the
> > 6.3 stable queue? Thanks!
>
> Now queued up, thanks.
Great thanks!
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Handle timeout differently from busy
From: Greg Kroah-Hartman @ 2023-06-07 9:46 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Linux regressions mailing list, Jiri Kosina, Bastien Nocera,
linux-input, linux-kernel, Peter F . Patel-Schneider,
Filipe Laíns, Nestor Lopez Casado, Mark Lord
In-Reply-To: <CAO-hwJL3RcfOxQvhqDFTwgfY=oAJqR5rsHmO5qDVwNUEh3K58Q@mail.gmail.com>
On Tue, Jun 06, 2023 at 08:37:26PM +0200, Benjamin Tissoires wrote:
> On Tue, Jun 6, 2023 at 8:18 PM Linux regression tracking (Thorsten
> Leemhuis) <regressions@leemhuis.info> wrote:
> >
> >
> >
> > On 06.06.23 15:27, Jiri Kosina wrote:
> > > On Mon, 5 Jun 2023, Linux regression tracking (Thorsten Leemhuis) wrote:
> > >
> > >>>>> If an attempt at contacting a receiver or a device fails because the
> > >>>>> receiver or device never responds, don't restart the communication, only
> > >>>>> restart it if the receiver or device answers that it's busy, as originally
> > >>>>> intended.
> > >>>>>
> > >>>>> This was the behaviour on communication timeout before commit 586e8fede795
> > >>>>> ("HID: logitech-hidpp: Retry commands when device is busy").
> > >>>>>
> > >>>>> This fixes some overly long waits in a critical path on boot, when
> > >>>>> checking whether the device is connected by getting its HID++ version.
> > >>>>>
> > >>>>> Signed-off-by: Bastien Nocera <hadess@hadess.net>
> > >>>>> Suggested-by: Mark Lord <mlord@pobox.com>
> > >>>>> Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy")
> > >>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412
> > >>> [...]
> > >>>>
> > >>>> I have applied this even before getting confirmation from the reporters in
> > >>>> bugzilla, as it's the right thing to do anyway.
> > >>>
> > >>> Unfortunately it doesn't seem to cure the reported issue (while reverting
> > >>> 586e8fede79 does):
> > >>
> > >> BTW, remind me again: was fixing this by reverting 586e8fede79 for now a
> > >> option? I guess it's not, but if I'm wrong I wonder if that might at
> > >> this point be the best way forward.
> > >
> > > This should now all be fixed by
> > >
> > > https://git.kernel.org/linus/7c28afd5512e371773dbb2bf95a31ed5625651d9
> >
> > Jiri, Benjamin, many many thx for working on this.
> >
> > Hmmm. No CC: <stable... tag.
> >
> > Should we ask Greg to pick this up for 6.3 now, or better wait a few
> > days? He currently already has 6199d23c91ce ("HID: logitech-hidpp:
> > Handle timeout differently from busy") in his queue for the next 6.3.y
> > release.
>
> Well, the Fixes: tag supposedly is enough to let the stable folks to
> pick it up.
No, not at all, please see:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
(hint, we need a cc: stable@ in the signed-off-by area.)
We only pick up stuff with "Fixes:" semi-often, sometimes never,
depending on our workload. Never rely on that.
It's been this way for 18+ years now, nothing new :)
> But you are right, let's Cc Greg for a quicker inclusion
> in the 6.3 tree.
>
> Greg, would you mind adding the commit above (7c28afd5512e37) onto the
> 6.3 stable queue? Thanks!
Now queued up, thanks.
greg k-h
^ permalink raw reply
* [PATCH] Input: rotary_encoder - don't double assign input->dev.parent
From: Roi L @ 2023-06-07 9:10 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, Roi L
devm_input_allocate_device() already assigns the @dev.parent field of the
input device/structure, so there's no need to reassign input->dev.parent
to dev.
Signed-off-by: Roi L <roeilev321_@outlook.com>
---
drivers/input/misc/rotary_encoder.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
index 22ec62083065..5c11cbe30167 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -255,7 +255,6 @@ static int rotary_encoder_probe(struct platform_device *pdev)
input->name = pdev->name;
input->id.bustype = BUS_HOST;
- input->dev.parent = dev;
if (encoder->relative_axis)
input_set_capability(input, EV_REL, encoder->axis);
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: input: touchscreen: Add ilitek 9882T touchscreen chip
From: cong yang @ 2023-06-07 8:55 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, conor+dt,
jikos, benjamin.tissoires, dianders, hsinyi, linux-input,
devicetree, linux-kernel
In-Reply-To: <ZH+ANlOaPH2nkZPT@google.com>
Hi,Dmitry
On Wed, Jun 7, 2023 at 2:51 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Mon, Jun 05, 2023 at 12:34:54PM +0200, Krzysztof Kozlowski wrote:
> > On 05/06/2023 08:05, Cong Yang wrote:
> > > Add an ilitek touch screen chip ili9882t.
> > >
> > > Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> > > ---
> > > .../bindings/input/elan,ekth6915.yaml | 23 ++++++++++++++++---
> > > 1 file changed, 20 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> > > index 05e6f2df604c..f0e7ffdce605 100644
> > > --- a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> > > +++ b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> > > @@ -15,11 +15,14 @@ description:
> > >
> > > properties:
> > > compatible:
> > > - items:
> > > - - const: elan,ekth6915
> > > + enum:
> > > + - elan,ekth6915
> > > + - ilitek,ili9882t
> > >
> > > reg:
> > > - const: 0x10
> > > + enum:
> > > + - 0x10
> > > + - 0x41
> > >
> > > interrupts:
> > > maxItems: 1
> > > @@ -29,11 +32,13 @@ properties:
> > >
> > > vcc33-supply:
> > > description: The 3.3V supply to the touchscreen.
> > > + If using ili9882t then this supply will not be needed.
> >
> > What does it mean "will not be needed"? Describe the hardware, not your
> > drivers.
>
> I do not think it makes sense to merge Ilitek and Elan into a single
> binding. The only thing that they have in common is that we are trying
> to reuse drivers/hid/i2c-hid/i2c-hid-of-elan.c to handle reset timings
> (which is also questionable IMO).
>
> Maybe if we had a single unified binding for HID-over-I2C touchscreens
> then combining would make more sense, at least to me...
>
Okay, thanks for the suggestion, I will add an ilitek binding.
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH RFC 1/4] dt-bindings: input: document Goodix Berlin Touchscreen IC
From: Krzysztof Kozlowski @ 2023-06-07 8:35 UTC (permalink / raw)
To: Neil Armstrong, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bastien Nocera, Hans de Goede, Henrik Rydberg
Cc: linux-input, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20230606-topic-goodix-berlin-upstream-initial-v1-1-4a0741b8aefd@linaro.org>
On 06/06/2023 16:31, Neil Armstrong wrote:
> Document the Goodix GT9916 wich is part of the "Berlin" serie
> of Touchscreen controllers IC from Goodix.
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> .../bindings/input/touchscreen/goodix-berlin.yaml | 81 ++++++++++++++++++++++
Filename like compatible, so at least with vendor,device style.
Preferably named exactly like compatible, since you have only one.
> 1 file changed, 81 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix-berlin.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix-berlin.yaml
> new file mode 100644
> index 000000000000..4c24a541e919
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix-berlin.yaml
> @@ -0,0 +1,81 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/touchscreen/goodix-berlin.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Goodix Belin series touchscreen controller
> +
> +maintainers:
> + - Neil Armstrong <neil.armstrong@linaro.org>
> +
> +allOf:
> + - $ref: touchscreen.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - goodix,gt9916
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> +
> + avdd-supply:
> + description: Analog power supply regulator on AVDD pin
> +
> + vddio-supply:
> + description: GPIO power supply regulator on VDDIO pin
> +
> + spi-max-frequency: true
> + touchscreen-inverted-x: true
> + touchscreen-inverted-y: true
> + touchscreen-size-x: true
> + touchscreen-size-y: true
> + touchscreen-swapped-x-y: true
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
I bet supplies are required - at least one of them. If hardware needs
them, they should be required by the bindings.
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/gpio/gpio.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + gt9916@5d {
Node names should be generic. See also explanation and list of examples
in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
touchscreen?
> + compatible = "goodix,gt9916";
> + reg = <0x5d>;
> + interrupt-parent = <&gpio>;
> + interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
> + reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
> + };
> + };
Best regards,
Krzysztof
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 8c9cce9cb81b5fdc6e66bf3f129727b89e8daab7
From: kernel test robot @ 2023-06-07 7:37 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: 8c9cce9cb81b5fdc6e66bf3f129727b89e8daab7 Input: pm8941-powerkey - fix debounce on gen2+ PMICs
elapsed time: 722m
configs tested: 144
configs skipped: 5
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha buildonly-randconfig-r006-20230606 gcc
alpha defconfig gcc
alpha randconfig-r036-20230606 gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r012-20230606 gcc
arc randconfig-r016-20230606 gcc
arc randconfig-r043-20230606 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm randconfig-r035-20230606 clang
arm randconfig-r046-20230606 gcc
arm64 allyesconfig gcc
arm64 buildonly-randconfig-r001-20230606 gcc
arm64 defconfig gcc
arm64 randconfig-r021-20230606 clang
csky defconfig gcc
csky randconfig-r014-20230606 gcc
csky randconfig-r021-20230606 gcc
csky randconfig-r022-20230606 gcc
csky randconfig-r031-20230606 gcc
hexagon buildonly-randconfig-r005-20230606 clang
hexagon randconfig-r011-20230606 clang
hexagon randconfig-r041-20230606 clang
hexagon randconfig-r045-20230606 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-i001-20230606 gcc
i386 randconfig-i002-20230606 gcc
i386 randconfig-i003-20230606 gcc
i386 randconfig-i004-20230606 gcc
i386 randconfig-i005-20230606 gcc
i386 randconfig-i006-20230606 gcc
i386 randconfig-i011-20230606 clang
i386 randconfig-i012-20230606 clang
i386 randconfig-i013-20230606 clang
i386 randconfig-i014-20230606 clang
i386 randconfig-i015-20230606 clang
i386 randconfig-i016-20230606 clang
i386 randconfig-i051-20230606 gcc
i386 randconfig-i052-20230606 gcc
i386 randconfig-i053-20230606 gcc
i386 randconfig-i054-20230606 gcc
i386 randconfig-i055-20230606 gcc
i386 randconfig-i056-20230606 gcc
i386 randconfig-i061-20230606 gcc
i386 randconfig-i062-20230606 gcc
i386 randconfig-i063-20230606 gcc
i386 randconfig-i064-20230606 gcc
i386 randconfig-i065-20230606 gcc
i386 randconfig-i066-20230606 gcc
i386 randconfig-r013-20230606 clang
i386 randconfig-r015-20230606 clang
i386 randconfig-r024-20230606 clang
i386 randconfig-r034-20230606 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-r022-20230606 gcc
loongarch randconfig-r026-20230606 gcc
loongarch randconfig-r032-20230606 gcc
m68k allmodconfig gcc
m68k defconfig gcc
m68k randconfig-r016-20230606 gcc
microblaze buildonly-randconfig-r004-20230606 gcc
microblaze randconfig-r015-20230606 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips buildonly-randconfig-r002-20230606 clang
mips buildonly-randconfig-r006-20230606 clang
mips randconfig-r001-20230606 clang
mips randconfig-r025-20230606 gcc
nios2 defconfig gcc
nios2 randconfig-r014-20230606 gcc
nios2 randconfig-r032-20230606 gcc
openrisc randconfig-r003-20230606 gcc
parisc buildonly-randconfig-r001-20230606 gcc
parisc defconfig gcc
parisc randconfig-r011-20230606 gcc
parisc randconfig-r012-20230606 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc randconfig-r033-20230606 gcc
powerpc randconfig-r034-20230606 gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r003-20230606 clang
riscv defconfig gcc
riscv randconfig-r013-20230606 clang
riscv randconfig-r025-20230606 clang
riscv randconfig-r036-20230606 gcc
riscv randconfig-r042-20230606 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r044-20230606 clang
sh allmodconfig gcc
sh randconfig-r006-20230606 gcc
sh randconfig-r023-20230606 gcc
sh randconfig-r035-20230606 gcc
sparc defconfig gcc
sparc64 randconfig-r031-20230606 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allyesconfig gcc
x86_64 buildonly-randconfig-r004-20230606 gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230606 gcc
x86_64 randconfig-a002-20230606 gcc
x86_64 randconfig-a003-20230606 gcc
x86_64 randconfig-a004-20230606 gcc
x86_64 randconfig-a005-20230606 gcc
x86_64 randconfig-a006-20230606 gcc
x86_64 randconfig-a011-20230606 clang
x86_64 randconfig-a012-20230606 clang
x86_64 randconfig-a013-20230606 clang
x86_64 randconfig-a014-20230606 clang
x86_64 randconfig-a015-20230606 clang
x86_64 randconfig-a016-20230606 clang
x86_64 randconfig-r005-20230606 gcc
x86_64 randconfig-r026-20230606 clang
x86_64 randconfig-x051-20230606 clang
x86_64 randconfig-x052-20230606 clang
x86_64 randconfig-x053-20230606 clang
x86_64 randconfig-x054-20230606 clang
x86_64 randconfig-x055-20230606 clang
x86_64 randconfig-x056-20230606 clang
x86_64 randconfig-x061-20230606 clang
x86_64 randconfig-x062-20230606 clang
x86_64 randconfig-x063-20230606 clang
x86_64 randconfig-x064-20230606 clang
x86_64 randconfig-x065-20230606 clang
x86_64 randconfig-x066-20230606 clang
x86_64 rhel-8.3 gcc
xtensa buildonly-randconfig-r005-20230606 gcc
xtensa randconfig-r002-20230606 gcc
xtensa randconfig-r024-20230606 gcc
xtensa randconfig-r033-20230606 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 2/2] Input: xpad - Add GameSir VID for Xbox One controllers
From: Vicki Pfau @ 2023-06-07 1:28 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: Sam Lantinga, Pavel Rojtberg, Vicki Pfau
In-Reply-To: <20230607012812.379640-1-vi@endrift.com>
From: Sam Lantinga <slouken@libsdl.org>
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
Signed-off-by: Vicki Pfau <vi@endrift.com>
---
drivers/input/joystick/xpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 745047215e42..459b5c507399 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -499,6 +499,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOXONE_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller for Xbox */
XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke Xbox One pad */
XPAD_XBOX360_VENDOR(0x2f24), /* GameSir controllers */
+ XPAD_XBOXONE_VENDOR(0x3537), /* GameSir Controllers */
XPAD_XBOX360_VENDOR(0x31e3), /* Wooting Keyboards */
XPAD_XBOX360_VENDOR(0x3285), /* Nacon GC-100 */
{ }
--
2.40.1
^ permalink raw reply related
* [PATCH 0/2] Input: xpad - Additional controller support
From: Vicki Pfau @ 2023-06-07 1:28 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: Vicki Pfau, Pavel Rojtberg
This series includes two patches: one is a fixed resubmit of a previously
reverted patch (first applied as db7220c48d8d), and the other is a simple
addition to the VID table for Xbox One controllers.
Sam Lantinga (1):
Input: xpad - Add GameSir VID for Xbox One controllers
Vicki Pfau (1):
Input: xpad - fix support for some third-party controllers
drivers/input/joystick/xpad.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
--
2.40.1
^ permalink raw reply
* [PATCH 1/2] Input: xpad - fix support for some third-party controllers
From: Vicki Pfau @ 2023-06-07 1:28 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: Vicki Pfau, Pavel Rojtberg, Andrey Smirnov
In-Reply-To: <20230607012812.379640-1-vi@endrift.com>
Some third-party controllers, such as the HORPIAD FPS for Nintendo Switch and
Gamesir-G3w, require a specific packet that the first-party XInput driver sends
before it will start sending reports. It's not currently known what this packet
does, but since the first-party driver always sends it's unlikely that this
could cause issues with existing controllers.
Co-authored-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Vicki Pfau <vi@endrift.com>
---
drivers/input/joystick/xpad.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 5d6a25b42bf9..745047215e42 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -264,6 +264,7 @@ static const struct xpad_device {
{ 0x0f0d, 0x0067, "HORIPAD ONE", 0, XTYPE_XBOXONE },
{ 0x0f0d, 0x0078, "Hori Real Arcade Pro V Kai Xbox One", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE },
{ 0x0f0d, 0x00c5, "Hori Fighting Commander ONE", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE },
+ { 0x0f0d, 0x00dc, "HORIPAD FPS for Nintendo Switch", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x0f30, 0x010b, "Philips Recoil", 0, XTYPE_XBOX },
{ 0x0f30, 0x0202, "Joytech Advanced Controller", 0, XTYPE_XBOX },
{ 0x0f30, 0x8888, "BigBen XBMiniPad Controller", 0, XTYPE_XBOX },
@@ -1720,6 +1721,27 @@ static int xpad_start_input(struct usb_xpad *xpad)
return error;
}
}
+ if (xpad->xtype == XTYPE_XBOX360) {
+ /*
+ * Some third-party controllers Xbox 360-style controllers
+ * require this message to finish initialization.
+ */
+ u8 dummy[20];
+
+ error = usb_control_msg_recv(xpad->udev, 0,
+ /* bRequest */ 0x01,
+ /* bmRequestType */
+ USB_TYPE_VENDOR | USB_DIR_IN |
+ USB_RECIP_INTERFACE,
+ /* wValue */ 0x100,
+ /* wIndex */ 0x00,
+ dummy, sizeof(dummy),
+ 25, GFP_KERNEL);
+ if (error)
+ dev_warn(&xpad->dev->dev,
+ "unable to receive magic message: %d\n",
+ error);
+ }
return 0;
}
--
2.40.1
^ permalink raw reply related
* [syzbot] Monthly input report (Jun 2023)
From: syzbot @ 2023-06-06 23:24 UTC (permalink / raw)
To: linux-input, linux-kernel, syzkaller-bugs
Hello input maintainers/developers,
This is a 31-day syzbot report for the input subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/input
During the period, 0 new issues were detected and 0 were fixed.
In total, 9 issues are still open and 48 have been fixed so far.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 2519 Yes WARNING in input_mt_init_slots
https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
<2> 935 Yes WARNING in implement
https://syzkaller.appspot.com/bug?extid=38e7237add3712479d65
<3> 98 Yes WARNING in cm109_urb_irq_callback/usb_submit_urb
https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
<4> 94 Yes general protection fault in hidraw_release
https://syzkaller.appspot.com/bug?extid=953a33deaf38c66a915e
<5> 49 Yes inconsistent lock state in find_vmap_area
https://syzkaller.appspot.com/bug?extid=8d19062486784d15dda9
<6> 34 Yes WARNING in bcm5974_start_traffic/usb_submit_urb
https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622
<7> 13 Yes KASAN: use-after-free Read in powermate_config_complete (4)
https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: amd_sfh driver causes kernel oops during boot
From: Malte Starostik @ 2023-06-06 22:57 UTC (permalink / raw)
To: Benjamin Tissoires, Linux regressions mailing list,
Limonciello, Mario
Cc: Bagas Sanjaya, basavaraj.natikar, linux-input, linux, stable
In-Reply-To: <79bd270e-4a0d-b4be-992b-73c65d085624@amd.com>
Am Dienstag, 6. Juni 2023, 17:25:13 CEST schrieb Limonciello, Mario:
> On 6/6/2023 3:08 AM, Benjamin Tissoires wrote:
> > On Jun 06 2023, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>> On Mon, Jun 05, 2023 at 01:24:25PM +0200, Malte Starostik wrote:
> >>>> Hello,
> >>>>
> >>>> chiming in here as I'm experiencing what looks like the exact same
> >>>> issue, also on a Lenovo Z13 notebook, also on Arch:
> >>>> Oops during startup in task udev-worker followed by udev-worker
> >>>> blocking all attempts to suspend or cleanly shutdown/reboot the
> >>>> machine
> > I have a suspicion on commit 7bcfdab3f0c6 ("HID: amd_sfh: if no sensors
> > are enabled, clean up") because the stack trace says that there is a bad
> > list_add, which could happen if the object is not correctly initialized.
> >
> > However, that commit was present in v6.2, so it might not be that one.
> >
> If I'm not mistaken the Z13 doesn't actually have any
> sensors connected to SFH. So I think the suspicion on
> 7bcfdab3f0c6 and theory this is triggered by HID init makes
> a lot of sense.
>
> Can you try this patch?
>
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> index d9b7b01900b5..fa693a5224c6 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> @@ -324,6 +324,7 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev
> *privdata)
> devm_kfree(dev, cl_data->report_descr[i]);
> }
> dev_warn(dev, "Failed to discover, sensors not enabled
> is %d\n", cl_data->is_any_sensor_enabled);
> + cl_data->num_hid_devices = 0;
> return -EOPNOTSUPP;
> }
> schedule_delayed_work(&cl_data->work_buffer,
> msecs_to_jiffies(AMD_SFH_IDLE_LOOP));
I applied this to 9e87b63ed37e202c77aa17d4112da6ae0c7c097c now, which was the
origin when I started the whole bisection. Clean rebuild, issue still
persists.
Out of 50 boots, I got:
25 clean
22 Oops as posted by the OP
1 same Oops, followed by a panic
1 lockup [1]
1 hanging with just a blank screen
Not sure whether the lockups are related, but [1] mentions modprobe and udev-
worker as well and all problems including the blank screen one appear roughly
at the same time during boot. As this is before a graphics mode switch, I
suspect the last mentioned case may be like [1] while the screen was blanked.
To support the timing correlation: the UVC error for the IR cam shown in the
photo (normal boot noise) also appears right before the BUG in the non-lockup
bad case.
I do see the dev_warn in dmesg, so the code path modified in your patch is
indeed hit:
[ 10.897521] pcie_mp2_amd 0000:63:00.7: Failed to discover, sensors not
enabled is 1
[ 10.897533] pcie_mp2_amd: probe of 0000:63:00.7 failed with error -95
BR Malte
[1] https://photos.app.goo.gl/2FAvQ7DqBsHEF6Bd8
^ permalink raw reply
* Re: [PATCH] Input: ads7846 - Fix usage of match data
From: Guenter Roeck @ 2023-06-06 21:34 UTC (permalink / raw)
To: Linus Walleij
Cc: Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, soc,
Dmitry Torokhov, linux-omap, linux-input
On Tue, Jun 06, 2023 at 09:13:04PM +0200, Linus Walleij wrote:
> device_get_match_data() returns the match data directly, fix
> this up and fix the probe crash.
>
> Fixes: 767d83361aaa ("Input: ads7846 - Convert to use software nodes")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* Re: [PATCH] Input: ads7846 - Fix usage of match data
From: Dmitry Torokhov @ 2023-06-06 19:15 UTC (permalink / raw)
To: Linus Walleij
Cc: Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, soc, linux-omap,
linux-input, Guenter Roeck
In-Reply-To: <20230606191304.3804174-1-linus.walleij@linaro.org>
On Tue, Jun 06, 2023 at 09:13:04PM +0200, Linus Walleij wrote:
> device_get_match_data() returns the match data directly, fix
> this up and fix the probe crash.
>
> Fixes: 767d83361aaa ("Input: ads7846 - Convert to use software nodes")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> This patch needs to be applied to the SoC tree where the
> offending patch is residing.
> ---
> drivers/input/touchscreen/ads7846.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> index 40eb27f1b23f..fe6fe8acd8a6 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -1117,20 +1117,13 @@ MODULE_DEVICE_TABLE(of, ads7846_dt_ids);
> static const struct ads7846_platform_data *ads7846_get_props(struct device *dev)
> {
> struct ads7846_platform_data *pdata;
> - const struct platform_device_id *pdev_id;
> u32 value;
>
> - pdev_id = device_get_match_data(dev);
> - if (!pdev_id) {
> - dev_err(dev, "Unknown device model\n");
> - return ERR_PTR(-EINVAL);
> - }
> -
> pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> if (!pdata)
> return ERR_PTR(-ENOMEM);
>
> - pdata->model = (unsigned long)pdev_id->driver_data;
> + pdata->model = (u32)device_get_match_data(dev);
>
> device_property_read_u16(dev, "ti,vref-delay-usecs",
> &pdata->vref_delay_usecs);
> --
> 2.34.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 1/4] Input: ads7846 - Convert to use software nodes
From: Linus Walleij @ 2023-06-06 19:15 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Thomas Bogendoerfer,
Dmitry Torokhov, Mark Brown, Bartosz Golaszewski, Andreas Kemnade,
Helge Deller, Ulf Hansson, linux-omap, linux-arm-kernel,
linux-kernel, linux-mips, linux-input, linux-spi, linux-fbdev,
dri-devel, linux-mmc
In-Reply-To: <ac6ef7f2-0d7a-ba43-4b63-0a23d899230f@wanadoo.fr>
On Sun, Jun 4, 2023 at 5:44 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> > + /* Asserts RESET */
> > + gpiod_set_value(md->reset, 1);
>
> Hi,
>
> should this also be done in the probe if mipid_detect() fails?
It's a nice bonus but surely not urgent or necessary.
> If yes, please also look at [1], that I've just sent, which introduces
> an error handling path in the probe.
Looks good to me.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] Input: ads7846 - Fix usage of match data
From: Linus Walleij @ 2023-06-06 19:13 UTC (permalink / raw)
To: Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, soc,
Dmitry Torokhov
Cc: linux-omap, linux-input, Linus Walleij, Guenter Roeck
device_get_match_data() returns the match data directly, fix
this up and fix the probe crash.
Fixes: 767d83361aaa ("Input: ads7846 - Convert to use software nodes")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
This patch needs to be applied to the SoC tree where the
offending patch is residing.
---
drivers/input/touchscreen/ads7846.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 40eb27f1b23f..fe6fe8acd8a6 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1117,20 +1117,13 @@ MODULE_DEVICE_TABLE(of, ads7846_dt_ids);
static const struct ads7846_platform_data *ads7846_get_props(struct device *dev)
{
struct ads7846_platform_data *pdata;
- const struct platform_device_id *pdev_id;
u32 value;
- pdev_id = device_get_match_data(dev);
- if (!pdev_id) {
- dev_err(dev, "Unknown device model\n");
- return ERR_PTR(-EINVAL);
- }
-
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return ERR_PTR(-ENOMEM);
- pdata->model = (unsigned long)pdev_id->driver_data;
+ pdata->model = (u32)device_get_match_data(dev);
device_property_read_u16(dev, "ti,vref-delay-usecs",
&pdata->vref_delay_usecs);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/2] Input: tps65219-pwrbutton - Use regmap_set_bits()
From: Dmitry Torokhov @ 2023-06-06 19:12 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Markus Schneider-Pargmann, linux-input, kernel
In-Reply-To: <20230605161458.117361-2-u.kleine-koenig@pengutronix.de>
On Mon, Jun 05, 2023 at 06:14:58PM +0200, Uwe Kleine-König wrote:
> regmap_set_bits() is equivalent to regmap_update_bits() if mask == val.
> The probe function uses regmap_clear_bits() to enable irqs, so
> symmetrically make use of regmap_set_bits() to disable them. There is no
> semantic difference.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: tps65219-pwrbutton - Convert to .remove_new()
From: Dmitry Torokhov @ 2023-06-06 19:12 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Markus Schneider-Pargmann, linux-input, kernel
In-Reply-To: <20230605161458.117361-1-u.kleine-koenig@pengutronix.de>
On Mon, Jun 05, 2023 at 06:14:57PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart from
> emitting a warning).
>
> To improve here there is a quest to make the remove callback return void.
> In the first step of this quest all drivers are converted to .remove_new()
> which already returns void. Eventually after all drivers are converted,
> .remove_new() is renamed to .remove().
>
> Before this driver might have returned an error. In this case emit a
> warning that tells more about the problem than the generic warning by
> the core, and instead of making the remove callback return zero
> unconditionally, convert to .remove_new() which is equivalent.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] Input: pm8941-powerkey - fix debounce on gen2+ PMICs
From: Dmitry Torokhov @ 2023-06-06 19:12 UTC (permalink / raw)
To: Caleb Connolly
Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, linux-input,
linux-arm-msm, phone-devel
In-Reply-To: <20230529-pm8941-pwrkey-debounce-v1-2-c043a6d5c814@linaro.org>
On Mon, May 29, 2023 at 08:55:07PM +0100, Caleb Connolly wrote:
> Since PM8998/PM660, the power key debounce register was redefined to
> support shorter debounce times. On PM8941 the shortest debounce time
> (represented by register value 0) was 15625us, on PM8998 the shortest
> debounce time is 62us, with the default being 2ms.
>
> Adjust the bit shift to correctly program debounce on PM8998 and newer.
>
> Fixes: 68c581d5e7d8 ("Input: add Qualcomm PM8941 power key driver")
> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] MAINTAINERS: Adjust Qualcomm driver globbing
From: Dmitry Torokhov @ 2023-06-06 19:12 UTC (permalink / raw)
To: Caleb Connolly
Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, linux-input,
linux-arm-msm, phone-devel
In-Reply-To: <20230529-pm8941-pwrkey-debounce-v1-1-c043a6d5c814@linaro.org>
On Mon, May 29, 2023 at 08:55:06PM +0100, Caleb Connolly wrote:
> The only drivers matching pm8???-* are two levels deep, adjust the glob
> to match them.
>
> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RFC 0/4] input: touchscreen: add initial support for Goodix Berlin touchscreen IC
From: Dmitry Torokhov @ 2023-06-06 19:02 UTC (permalink / raw)
To: Neil Armstrong
Cc: Hans de Goede, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bastien Nocera, Henrik Rydberg, linux-input, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <665c9aa5-ef70-65ce-7d9c-4b3b93874934@linaro.org>
On Tue, Jun 06, 2023 at 08:55:35PM +0200, Neil Armstrong wrote:
> Hi Dmitry,
>
> On 06/06/2023 20:44, Dmitry Torokhov wrote:
> > On Tue, Jun 06, 2023 at 08:12:04PM +0200, Neil Armstrong wrote:
> > > Hi,
> > >
> > > On 06/06/2023 17:31, Hans de Goede wrote:
> > > > Hi Neil,
> > > >
> > > > On 6/6/23 16:31, Neil Armstrong wrote:
> > > > > These touchscreen ICs support SPI, I2C and I3C interface, up to
> > > > > 10 finger touch, stylus and gestures events.
> > > > >
> > > > > This initial driver is derived from the Goodix goodix_ts_berlin
> > > > > available at [1] and [2] and only supports the GT9916 IC
> > > > > present on the Qualcomm SM8550 MTP & QRD touch panel.
> > > > >
> > > > > The current implementation only supports BerlinD, aka GT9916.
> > > > >
> > > > > Support for advanced features like:
> > > > > - Firmware & config update
> > > > > - Stylus events
> > > > > - Gestures events
> > > > > - Previous revisions support (BerlinA or BerlinB)
> > > > > is not included in current version.
> > > > >
> > > > > The current support will work with currently flashed firmware
> > > > > and config, and bail out if firmware or config aren't flashed yet.
> > > >
> > > > What I'm missing here / in the commit msg of
> > > > "input: touchscreen: add core support for Goodix Berlin Touchscreen IC"
> > > >
> > > > is an explanation why this is a new driver instead of adding
> > > > support to the existing goodix.c code.
> > > >
> > > > I assume you have good reasons for this, but it would be good
> > > > if you can write the reasons for this down.
> > >
> > > Sure, should I write it down here and/or update the commit message in a new revision ?
> > >
> > > Anyway, here's the reasons:
> > > - globally the event handling "looks like" the current goodix.c, but again the offsets
> > > are again different and none of the register address are the same, and unlike the current
> > > support all registers are provided by the "ic_info" structure
> > > - while with the current code it *could* be possible to merge it, with a lot of changes,
> > > the firmware management looks really different, and it would be really hard to merge.
> > >
> > > But I may be wrong, and may be misleaded by the goodix driver structure (even if it
> > > went through a really heavy cleaning process).
> > >
> > > Globally it seems they tried to match the "event handling" process of the previous
> > > generations, but the firmware interface is completely different.
> >
> > It is not unprecedented for drivers to share event processing and
> > implement several ways/generations of firmware update mechanisms.
>
> Thanks for your reply, I'm perfectly aware of that, this is why I posted
> this as RFC.
>
> If the event handling is vaguely similar, I'm not sure it's worth refactoring the
> current driver since I do not have the old and current IC datasheet nor
> HW to check for current support non-regression.
>
> What I'm sure is that not a single register address, flag or struct is even close
> to the current upstream defined ones.
OK, it looks like Hans' preference is also to have a separate driver, so
let's keep them separate.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 28/43] input: keypad: ep93xx: add DT support for Cirrus EP93xx
From: Dmitry Torokhov @ 2023-06-06 18:57 UTC (permalink / raw)
To: Nikita Shubin
Cc: Alexander Sverdlin, Arnd Bergmann, Linus Walleij, Andy Shevchenko,
Jonathan Cameron, Michael Peters, Kris Bahnsen, linux-input,
linux-kernel
In-Reply-To: <20230601054549.10843-10-nikita.shubin@maquefel.me>
On Thu, Jun 01, 2023 at 08:45:33AM +0300, Nikita Shubin wrote:
> - get keymap from the device tree
> - find register range from the device tree
> - get interrupts from device tree
>
> Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
> ---
>
> Notes:
> v0 -> v1:
>
> - fixed header
> - dropped coma in id table
> - take debounce, prescale from dt
> - remove ep93xx_keypad_platform_data
> - move flags to module params
> - drop setting clock rate, it's useless, as was never used,
> it seems we are okay with default clk rate used
> - move usefull defines from platform file here
> - drop platform header
>
> drivers/input/keyboard/ep93xx_keypad.c | 78 +++++++++++++-------------
> 1 file changed, 40 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/input/keyboard/ep93xx_keypad.c b/drivers/input/keyboard/ep93xx_keypad.c
> index 55075addcac2..8b0e73f56216 100644
> --- a/drivers/input/keyboard/ep93xx_keypad.c
> +++ b/drivers/input/keyboard/ep93xx_keypad.c
> @@ -20,6 +20,7 @@
> #include <linux/bits.h>
> #include <linux/module.h>
> #include <linux/platform_device.h>
> +#include <linux/mod_devicetable.h>
> #include <linux/interrupt.h>
> #include <linux/clk.h>
> #include <linux/io.h>
> @@ -27,7 +28,6 @@
> #include <linux/input/matrix_keypad.h>
> #include <linux/slab.h>
> #include <linux/soc/cirrus/ep93xx.h>
> -#include <linux/platform_data/keypad-ep93xx.h>
> #include <linux/pm_wakeirq.h>
>
> /*
> @@ -61,12 +61,18 @@
> #define KEY_REG_KEY1_MASK GENMASK(5, 0)
> #define KEY_REG_KEY1_SHIFT 0
>
> +#define EP93XX_MATRIX_ROWS (8)
> +#define EP93XX_MATRIX_COLS (8)
> +
> #define EP93XX_MATRIX_SIZE (EP93XX_MATRIX_ROWS * EP93XX_MATRIX_COLS)
>
> struct ep93xx_keypad {
> - struct ep93xx_keypad_platform_data *pdata;
> struct input_dev *input_dev;
> struct clk *clk;
> + unsigned int debounce;
> + unsigned int prescale;
> + unsigned int flags;
> + unsigned int clk_rate;
>
> void __iomem *mmio_base;
>
> @@ -80,6 +86,17 @@ struct ep93xx_keypad {
> bool enabled;
> };
>
> +/* flags for the ep93xx_keypad driver */
> +#define EP93XX_KEYPAD_DISABLE_3_KEY (1<<0) /* disable 3-key reset */
> +#define EP93XX_KEYPAD_DIAG_MODE (1<<1) /* diagnostic mode */
> +#define EP93XX_KEYPAD_BACK_DRIVE (1<<2) /* back driving mode */
> +#define EP93XX_KEYPAD_TEST_MODE (1<<3) /* scan only column 0 */
> +#define EP93XX_KEYPAD_AUTOREPEAT (1<<4) /* enable key autorepeat */
> +
> +static int ep93xx_keypad_flags;
> +module_param(ep93xx_keypad_flags, int, 0);
> +MODULE_PARM_DESC(ep93xx_keypad_flags, "EP93XX keypad flags.");
> +
> static irqreturn_t ep93xx_keypad_irq_handler(int irq, void *dev_id)
> {
> struct ep93xx_keypad *keypad = dev_id;
> @@ -133,23 +150,20 @@ static irqreturn_t ep93xx_keypad_irq_handler(int irq, void *dev_id)
>
> static void ep93xx_keypad_config(struct ep93xx_keypad *keypad)
> {
> - struct ep93xx_keypad_platform_data *pdata = keypad->pdata;
> unsigned int val = 0;
>
> - clk_set_rate(keypad->clk, pdata->clk_rate);
> -
> - if (pdata->flags & EP93XX_KEYPAD_DISABLE_3_KEY)
> + if (keypad->flags & EP93XX_KEYPAD_DISABLE_3_KEY)
> val |= KEY_INIT_DIS3KY;
> - if (pdata->flags & EP93XX_KEYPAD_DIAG_MODE)
> + if (keypad->flags & EP93XX_KEYPAD_DIAG_MODE)
> val |= KEY_INIT_DIAG;
> - if (pdata->flags & EP93XX_KEYPAD_BACK_DRIVE)
> + if (keypad->flags & EP93XX_KEYPAD_BACK_DRIVE)
> val |= KEY_INIT_BACK;
> - if (pdata->flags & EP93XX_KEYPAD_TEST_MODE)
> + if (keypad->flags & EP93XX_KEYPAD_TEST_MODE)
> val |= KEY_INIT_T2;
>
> - val |= ((pdata->debounce << KEY_INIT_DBNC_SHIFT) & KEY_INIT_DBNC_MASK);
> + val |= ((keypad->debounce << KEY_INIT_DBNC_SHIFT) & KEY_INIT_DBNC_MASK);
>
> - val |= ((pdata->prescale << KEY_INIT_PRSCL_SHIFT) & KEY_INIT_PRSCL_MASK);
> + val |= ((keypad->prescale << KEY_INIT_PRSCL_SHIFT) & KEY_INIT_PRSCL_MASK);
>
> __raw_writel(val, keypad->mmio_base + KEY_INIT);
> }
> @@ -220,17 +234,10 @@ static int ep93xx_keypad_resume(struct device *dev)
> static DEFINE_SIMPLE_DEV_PM_OPS(ep93xx_keypad_pm_ops,
> ep93xx_keypad_suspend, ep93xx_keypad_resume);
>
> -static void ep93xx_keypad_release_gpio_action(void *_pdev)
> -{
> - struct platform_device *pdev = _pdev;
> -
> - ep93xx_keypad_release_gpio(pdev);
> -}
> -
> static int ep93xx_keypad_probe(struct platform_device *pdev)
> {
> + struct device_node *np = pdev->dev.of_node;
> struct ep93xx_keypad *keypad;
> - const struct matrix_keymap_data *keymap_data;
> struct input_dev *input_dev;
> int err;
>
> @@ -238,14 +245,6 @@ static int ep93xx_keypad_probe(struct platform_device *pdev)
> if (!keypad)
> return -ENOMEM;
>
> - keypad->pdata = dev_get_platdata(&pdev->dev);
> - if (!keypad->pdata)
> - return -EINVAL;
> -
> - keymap_data = keypad->pdata->keymap_data;
> - if (!keymap_data)
> - return -EINVAL;
> -
> keypad->irq = platform_get_irq(pdev, 0);
> if (keypad->irq < 0)
> return keypad->irq;
> @@ -254,19 +253,15 @@ static int ep93xx_keypad_probe(struct platform_device *pdev)
> if (IS_ERR(keypad->mmio_base))
> return PTR_ERR(keypad->mmio_base);
>
> - err = ep93xx_keypad_acquire_gpio(pdev);
> - if (err)
> - return err;
> -
> - err = devm_add_action_or_reset(&pdev->dev,
> - ep93xx_keypad_release_gpio_action, pdev);
> - if (err)
> - return err;
> -
> keypad->clk = devm_clk_get(&pdev->dev, NULL);
> if (IS_ERR(keypad->clk))
> return PTR_ERR(keypad->clk);
>
> + keypad->flags = ep93xx_keypad_flags;
> +
> + of_property_read_u32(np, "cirrus,debounce-delay-ms", &keypad->debounce);
> + of_property_read_u32(np, "cirrus,prescale", &keypad->prescale);
Please use device_property_read_*() API for this.
> +
> input_dev = devm_input_allocate_device(&pdev->dev);
> if (!input_dev)
> return -ENOMEM;
> @@ -278,13 +273,13 @@ static int ep93xx_keypad_probe(struct platform_device *pdev)
> input_dev->open = ep93xx_keypad_open;
> input_dev->close = ep93xx_keypad_close;
>
> - err = matrix_keypad_build_keymap(keymap_data, NULL,
> + err = matrix_keypad_build_keymap(NULL, NULL,
> EP93XX_MATRIX_ROWS, EP93XX_MATRIX_COLS,
> keypad->keycodes, input_dev);
> if (err)
> return err;
>
> - if (keypad->pdata->flags & EP93XX_KEYPAD_AUTOREPEAT)
> + if (keypad->flags & EP93XX_KEYPAD_AUTOREPEAT)
> __set_bit(EV_REP, input_dev->evbit);
I think this should be controlled by "autorepeat" device property.
> input_set_drvdata(input_dev, keypad);
>
> @@ -315,10 +310,17 @@ static int ep93xx_keypad_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct of_device_id ep93xx_keypad_of_ids[] = {
> + { .compatible = "cirrus,ep9307-keypad" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, ep93xx_keypad_of_ids);
> +
> static struct platform_driver ep93xx_keypad_driver = {
> .driver = {
> .name = "ep93xx-keypad",
> .pm = pm_sleep_ptr(&ep93xx_keypad_pm_ops),
> + .of_match_table = ep93xx_keypad_of_ids,
> },
> .probe = ep93xx_keypad_probe,
> .remove = ep93xx_keypad_remove,
> --
> 2.37.4
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RFC 0/4] input: touchscreen: add initial support for Goodix Berlin touchscreen IC
From: Hans de Goede @ 2023-06-06 18:55 UTC (permalink / raw)
To: neil.armstrong, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bastien Nocera, Henrik Rydberg
Cc: linux-input, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <2677ae8c-59d3-b658-dc3f-918838ac0fb6@linaro.org>
Hi,
On 6/6/23 20:12, Neil Armstrong wrote:
> Hi,
>
> On 06/06/2023 17:31, Hans de Goede wrote:
>> Hi Neil,
>>
>> On 6/6/23 16:31, Neil Armstrong wrote:
>>> These touchscreen ICs support SPI, I2C and I3C interface, up to
>>> 10 finger touch, stylus and gestures events.
>>>
>>> This initial driver is derived from the Goodix goodix_ts_berlin
>>> available at [1] and [2] and only supports the GT9916 IC
>>> present on the Qualcomm SM8550 MTP & QRD touch panel.
>>>
>>> The current implementation only supports BerlinD, aka GT9916.
>>>
>>> Support for advanced features like:
>>> - Firmware & config update
>>> - Stylus events
>>> - Gestures events
>>> - Previous revisions support (BerlinA or BerlinB)
>>> is not included in current version.
>>>
>>> The current support will work with currently flashed firmware
>>> and config, and bail out if firmware or config aren't flashed yet.
>>
>> What I'm missing here / in the commit msg of
>> "input: touchscreen: add core support for Goodix Berlin Touchscreen IC"
>>
>> is an explanation why this is a new driver instead of adding
>> support to the existing goodix.c code.
>>
>> I assume you have good reasons for this, but it would be good
>> if you can write the reasons for this down.
>
> Sure, should I write it down here and/or update the commit message in a new revision ?
Yes please add this to the commit msg for the next version.
> Anyway, here's the reasons:
> - globally the event handling "looks like" the current goodix.c, but again the offsets
> are again different and none of the register address are the same, and unlike the current
> support all registers are provided by the "ic_info" structure
> - while with the current code it *could* be possible to merge it, with a lot of changes,
> the firmware management looks really different, and it would be really hard to merge.
>
> But I may be wrong, and may be misleaded by the goodix driver structure (even if it
> went through a really heavy cleaning process).
No doing a new separate driver sounds about right to me. The current goodix driver already has a lot of different code-paths. So since there does not seem to be a whole lot of code sharing potential adding yet more special case handling / paths is not desirable IMHO.
Regards,
Hans
>>> [1] https://github.com/goodix/goodix_ts_berlin
>>> [2] https://git.codelinaro.org/clo/la/platform/vendor/opensource/touch-drivers
>>>
>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>>> ---
>>> Neil Armstrong (4):
>>> dt-bindings: input: document Goodix Berlin Touchscreen IC
>>> input: touchscreen: add core support for Goodix Berlin Touchscreen IC
>>> input: touchscreen: add I2C support for Goodix Berlin Touchscreen IC
>>> input: touchscreen: add SPI support for Goodix Berlin Touchscreen IC
>>>
>>> .../bindings/input/touchscreen/goodix-berlin.yaml | 81 ++
>>> drivers/input/touchscreen/Kconfig | 33 +
>>> drivers/input/touchscreen/Makefile | 3 +
>>> drivers/input/touchscreen/goodix_berlin.h | 228 +++++
>>> drivers/input/touchscreen/goodix_berlin_core.c | 935 +++++++++++++++++++++
>>> drivers/input/touchscreen/goodix_berlin_i2c.c | 76 ++
>>> drivers/input/touchscreen/goodix_berlin_spi.c | 183 ++++
>>> 7 files changed, 1539 insertions(+)
>>> ---
>>> base-commit: 6db29e14f4fb7bce9eb5290288e71b05c2b0d118
>>> change-id: 20230606-topic-goodix-berlin-upstream-initial-ba97e8ec8f4c
>>>
>>> Best regards,
>>
>
^ permalink raw reply
* Re: [PATCH RFC 0/4] input: touchscreen: add initial support for Goodix Berlin touchscreen IC
From: Neil Armstrong @ 2023-06-06 18:55 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Hans de Goede, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bastien Nocera, Henrik Rydberg, linux-input, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <ZH9+ndrF0RIgFhnI@google.com>
Hi Dmitry,
On 06/06/2023 20:44, Dmitry Torokhov wrote:
> On Tue, Jun 06, 2023 at 08:12:04PM +0200, Neil Armstrong wrote:
>> Hi,
>>
>> On 06/06/2023 17:31, Hans de Goede wrote:
>>> Hi Neil,
>>>
>>> On 6/6/23 16:31, Neil Armstrong wrote:
>>>> These touchscreen ICs support SPI, I2C and I3C interface, up to
>>>> 10 finger touch, stylus and gestures events.
>>>>
>>>> This initial driver is derived from the Goodix goodix_ts_berlin
>>>> available at [1] and [2] and only supports the GT9916 IC
>>>> present on the Qualcomm SM8550 MTP & QRD touch panel.
>>>>
>>>> The current implementation only supports BerlinD, aka GT9916.
>>>>
>>>> Support for advanced features like:
>>>> - Firmware & config update
>>>> - Stylus events
>>>> - Gestures events
>>>> - Previous revisions support (BerlinA or BerlinB)
>>>> is not included in current version.
>>>>
>>>> The current support will work with currently flashed firmware
>>>> and config, and bail out if firmware or config aren't flashed yet.
>>>
>>> What I'm missing here / in the commit msg of
>>> "input: touchscreen: add core support for Goodix Berlin Touchscreen IC"
>>>
>>> is an explanation why this is a new driver instead of adding
>>> support to the existing goodix.c code.
>>>
>>> I assume you have good reasons for this, but it would be good
>>> if you can write the reasons for this down.
>>
>> Sure, should I write it down here and/or update the commit message in a new revision ?
>>
>> Anyway, here's the reasons:
>> - globally the event handling "looks like" the current goodix.c, but again the offsets
>> are again different and none of the register address are the same, and unlike the current
>> support all registers are provided by the "ic_info" structure
>> - while with the current code it *could* be possible to merge it, with a lot of changes,
>> the firmware management looks really different, and it would be really hard to merge.
>>
>> But I may be wrong, and may be misleaded by the goodix driver structure (even if it
>> went through a really heavy cleaning process).
>>
>> Globally it seems they tried to match the "event handling" process of the previous
>> generations, but the firmware interface is completely different.
>
> It is not unprecedented for drivers to share event processing and
> implement several ways/generations of firmware update mechanisms.
Thanks for your reply, I'm perfectly aware of that, this is why I posted
this as RFC.
If the event handling is vaguely similar, I'm not sure it's worth refactoring the
current driver since I do not have the old and current IC datasheet nor
HW to check for current support non-regression.
What I'm sure is that not a single register address, flag or struct is even close
to the current upstream defined ones.
Neil
>
> Thanks.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox