* Re: [PATCH v5 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Conor Dooley @ 2023-12-12 16:54 UTC (permalink / raw)
To: Biju Das
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Support Opensource, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TYCPR01MB112697AA2A3BC9F58C7BF4B67868FA@TYCPR01MB11269.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]
On Mon, Dec 11, 2023 at 06:51:14PM +0000, Biju Das wrote:
> Hi Conor Dooley,
>
> Thanks for the feedback.
>
> > -----Original Message-----
> > From: Conor Dooley <conor@kernel.org>
> > Sent: Monday, December 11, 2023 6:38 PM
> > Subject: Re: [PATCH v5 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062
> > to json-schema
> >
> > On Sun, Dec 10, 2023 at 01:47:17PM +0000, Biju Das wrote:
> > > Convert the da9062 PMIC device tree binding documentation to json-
> > schema.
> > >
> > > Document the missing gpio child node for da9062.
> > >
> > > While at it, update description with link to product information and
> > > example.
> > >
> > > The missing child node with of_compatible defined in MFD_CELL_OF is
> > > causing the below warning message:
> > > da9062-gpio: Failed to locate of_node [id: -1]
> > >
> > > So, make all child nodes with of_compatible defined in struct mfd_cell
> > > as required property for da906{1,2} devices.
> >
> > > + gpio-controller: true
> > > +
> > > + "#gpio-cells":
> > > + const: 2
> > > +
> > > + gpio:
> > > + type: object
> > > + additionalProperties: false
> > > + properties:
> > > + compatible:
> > > + const: dlg,da9062-gpio
> >
> > > + - |
> > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > + #include <dt-bindings/regulator/dlg,da9063-regulator.h>
> > > + i2c {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + pmic@58 {
> > > + compatible = "dlg,da9062";
> > > + reg = <0x58>;
> > > + gpio-controller;
> > > + #gpio-cells = <2>;
> >
> > > + gpio {
> > > + compatible = "dlg,da9062-gpio";
> > > + };
> >
> > I know you had some conversation with Krzysztof, but I still don;t really
> > follow this. Why is the parent, rather than the child, the one that gets
> > the "gpio-controller" and "#gpio-cells" properties? The commit message
> > just mentions why missing child node was added, but not the reason for the
> > gpio properties being added at what appears to be the "wrong" level.
>
>
> Please see [1], The driver is checking against parent "gpio-controller"
>
> [1] https://elixir.bootlin.com/linux/v6.0-rc4/source/drivers/pinctrl/pinctrl-da9062.c#L270
I would appreciate if you could note in your commit message the
rationale behind the strange setup. Citing the existing driver users etc
would be helpful.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/3] dt-bindings: input: Add TouchNetix axiom touchscreen
From: Conor Dooley @ 2023-12-12 16:57 UTC (permalink / raw)
To: Kamel Bouhara
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy, catalin.popescu, mark.satterthwaite,
bartp, hannah.rossiter, Thomas Petazzoni, Gregory Clement,
bsp-development.geo
In-Reply-To: <20231211121430.1689139-3-kamel.bouhara@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 3278 bytes --]
On Mon, Dec 11, 2023 at 01:14:28PM +0100, Kamel Bouhara wrote:
> Add the TouchNetix axiom I2C touchscreen device tree bindings
> documentation.
>
> Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
> ---
> .../input/touchscreen/touchnetix,ax54a.yaml | 64 +++++++++++++++++++
> MAINTAINERS | 6 ++
> 2 files changed, 70 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
> new file mode 100644
> index 000000000000..cbdf48fc538b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/touchscreen/touchnetix,ax54a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TouchNetix Axiom series touchscreen controller
> +
> +maintainers:
> + - Kamel Bouhara <kamel.bouhara@bootlin.com>
> +
> +allOf:
> + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
Weird, you add this ref here but do not actually allow any properties
from it since you have "additionalProperties: false" below.
What's the point of its inclusion?
Cheers,
Conor.
> + - $ref: /schemas/input/input.yaml#
> +
> +properties:
> + compatible:
> + const: touchnetix,ax54a
> +
> + reg:
> + const: 0x66
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> +
> + vdda-supply:
> + description: Analog power supply regulator on VDDA pin
> +
> + vddi-supply:
> + description: I/O power supply regulator on VDDI pin
> +
> + poll-interval: true
> +
> +required:
> + - compatible
> + - reg
> + - vdda-supply
> + - vddi-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + touchscreen@66 {
> + compatible = "touchnetix,ax54a";
> + reg = <0x66>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
> + vdda-supply = <&vdda_reg>;
> + vddi-supply = <&vddi_reg>;
> + poll-interval = <20>;
> + };
> + };
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7608b714653f..4752d8436dbb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21431,6 +21431,12 @@ S: Maintained
> F: Documentation/ABI/testing/sysfs-class-firmware-attributes
> F: drivers/platform/x86/think-lmi.?
>
> +TOUCHNETIX AXIOM I2C TOUCHSCREEN DRIVER
> +M: Kamel Bouhara <kamel.bouhara@bootlin.com>
> +L: linux-input@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
> +
> THUNDERBOLT DMA TRAFFIC TEST DRIVER
> M: Isaac Hazan <isaac.hazan@intel.com>
> L: linux-usb@vger.kernel.org
> --
> 2.25.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] irq: Resolve that mask_irq/unmask_irq may not be called in pairs
From: Jiri Kosina @ 2023-12-12 16:57 UTC (permalink / raw)
To: xiongxin; +Cc: Thomas Gleixner, benjamin.tissoires, linux-input, stable,
Riwen Lu
In-Reply-To: <e125491c-4cdb-4870-924a-baeb7453bf78@kylinos.cn>
On Mon, 11 Dec 2023, xiongxin wrote:
> In this scenario, unmask_irq() will not be called, and then gpio corresponding
> interrupt pin will be masked. Finally, in the suspend() process driven by gpio
> interrupt controller, the interrupt mask register will be saved, and then
> masked will continue to be read when resuming () process. After the kernel
> resumed, the i2c hid gpio interrupt was masked and the i2c hid device was
> unavailable.
In addition to what Thomas already wrote -- what exactly is the problem
you are trying to solve here?
Is it that your device drive by i2c-hid driver is no longer sending any
data reports after a suspend/resume cycle? What makes you think that it's
because of its IRQ being disabled?
Don't you just perhaps need I2C_HID_QUIRK_RESET_ON_RESUME quirk for that
device?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* RE: [PATCH v5 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Biju Das @ 2023-12-12 17:16 UTC (permalink / raw)
To: Conor Dooley
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Support Opensource, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <20231212-enrich-borax-7943611e2586@spud>
Hi Conor Dooley,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Tuesday, December 12, 2023 4:54 PM
> Subject: Re: [PATCH v5 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062
> to json-schema
>
> On Mon, Dec 11, 2023 at 06:51:14PM +0000, Biju Das wrote:
> > Hi Conor Dooley,
> >
> > Thanks for the feedback.
> >
> > > -----Original Message-----
> > > From: Conor Dooley <conor@kernel.org>
> > > Sent: Monday, December 11, 2023 6:38 PM
> > > Subject: Re: [PATCH v5 8/8] dt-bindings: mfd: dlg,da9063: Convert
> > > da9062 to json-schema
> > >
> > > On Sun, Dec 10, 2023 at 01:47:17PM +0000, Biju Das wrote:
> > > > Convert the da9062 PMIC device tree binding documentation to json-
> > > schema.
> > > >
> > > > Document the missing gpio child node for da9062.
> > > >
> > > > While at it, update description with link to product information
> > > > and example.
> > > >
> > > > The missing child node with of_compatible defined in MFD_CELL_OF
> > > > is causing the below warning message:
> > > > da9062-gpio: Failed to locate of_node [id: -1]
> > > >
> > > > So, make all child nodes with of_compatible defined in struct
> > > > mfd_cell as required property for da906{1,2} devices.
> > >
> > > > + gpio-controller: true
> > > > +
> > > > + "#gpio-cells":
> > > > + const: 2
> > > > +
> > > > + gpio:
> > > > + type: object
> > > > + additionalProperties: false
> > > > + properties:
> > > > + compatible:
> > > > + const: dlg,da9062-gpio
> > >
> > > > + - |
> > > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > > + #include <dt-bindings/regulator/dlg,da9063-regulator.h>
> > > > + i2c {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + pmic@58 {
> > > > + compatible = "dlg,da9062";
> > > > + reg = <0x58>;
> > > > + gpio-controller;
> > > > + #gpio-cells = <2>;
> > >
> > > > + gpio {
> > > > + compatible = "dlg,da9062-gpio";
> > > > + };
> > >
> > > I know you had some conversation with Krzysztof, but I still don;t
> > > really follow this. Why is the parent, rather than the child, the
> > > one that gets the "gpio-controller" and "#gpio-cells" properties?
> > > The commit message just mentions why missing child node was added,
> > > but not the reason for the gpio properties being added at what appears
> to be the "wrong" level.
> >
> >
> > Please see [1], The driver is checking against parent "gpio-controller"
> >
> > [1]
> > https://elixir.bootlin.com/linux/v6.0-rc4/source/drivers/pinctrl/pinct
> > rl-da9062.c#L270
>
> I would appreciate if you could note in your commit message the rationale
> behind the strange setup. Citing the existing driver users etc would be
> helpful.
OK, I don't add this because the existing binding add this property in parent
and driver is based on this documentation.
There is no harm in adding this info in commit message as we are converting .txt into .yaml.
Cheers,
Biju
^ permalink raw reply
* [PATCH] HID: google_hammer: Fix invalid ENOSYS warning and unsigned.
From: Guy Chronister @ 2023-12-12 18:20 UTC (permalink / raw)
To: jikos; +Cc: benjamin.tissoires, linux-input, linux-kernel
Fixed warnings about ENOSYS and bare unsigned without int.
Signed-off-by: Guy Chronister <guylovesbritt@gmail.com>
---
drivers/hid/hid-google-hammer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index c6bdb9c4ef3e..d567f020bead 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -324,7 +324,7 @@ static int hammer_kbd_brightness_set_blocking(struct led_classdev *cdev,
}
ret = hid_hw_output_report(led->hdev, led->buf, sizeof(led->buf));
- if (ret == -ENOSYS)
+ if (ret == -EINVAL)
ret = hid_hw_raw_request(led->hdev, 0, led->buf,
sizeof(led->buf),
HID_OUTPUT_REPORT,
@@ -420,7 +420,7 @@ static int hammer_event(struct hid_device *hid, struct hid_field *field,
}
static bool hammer_has_usage(struct hid_device *hdev, unsigned int report_type,
- unsigned application, unsigned usage)
+ unsigned int application, unsigned int usage)
{
struct hid_report_enum *re = &hdev->report_enum[report_type];
struct hid_report *report;
--
2.40.1
^ permalink raw reply related
* [PATCH] HID: elo fix coding style errors.
From: Guy Chronister @ 2023-12-12 20:57 UTC (permalink / raw)
To: jikos; +Cc: benjamin.tissoires, linux-input, linux-kernel
fix whitespace errors and missing spaces around ==.
Signed-off-by: Guy Chronister <guylovesbritt@gmail.com>
---
drivers/hid/hid-elo.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-elo.c b/drivers/hid/hid-elo.c
index 2876cb6a7dca..d91d6ef4de9a 100644
--- a/drivers/hid/hid-elo.c
+++ b/drivers/hid/hid-elo.c
@@ -33,7 +33,7 @@ struct elo_priv {
static struct workqueue_struct *wq;
static bool use_fw_quirk = true;
-module_param(use_fw_quirk, bool, S_IRUGO);
+module_param(use_fw_quirk, bool, 0444);
MODULE_PARM_DESC(use_fw_quirk, "Do periodic pokes for broken M firmwares (default = true)");
static int elo_input_configured(struct hid_device *hdev,
@@ -193,7 +193,7 @@ static bool elo_broken_firmware(struct usb_device *dev)
u16 fw_lvl = le16_to_cpu(dev->descriptor.bcdDevice);
u16 child_vid, child_pid;
int i;
-
+
if (!use_fw_quirk)
return false;
if (fw_lvl != 0x10d)
@@ -205,13 +205,13 @@ static bool elo_broken_firmware(struct usb_device *dev)
child_pid = le16_to_cpu(child->descriptor.idProduct);
/*
- * If one of the devices below is present attached as a sibling of
- * the touch controller then this is a newer IBM 4820 monitor that
+ * If one of the devices below is present attached as a sibling of
+ * the touch controller then this is a newer IBM 4820 monitor that
* does not need the IBM-requested workaround if fw level is
* 0x010d - aka 'M'.
* No other HW can have this combination.
*/
- if (child_vid==0x04b3) {
+ if (child_vid == 0x04b3) {
switch (child_pid) {
case 0x4676: /* 4820 21x Video */
case 0x4677: /* 4820 51x Video */
--
2.40.1
^ permalink raw reply related
* [dtor-input:next] BUILD SUCCESS 02db1749f30fb88638e19fb16f2470724529eb81
From: kernel test robot @ 2023-12-12 23:31 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: 02db1749f30fb88638e19fb16f2470724529eb81 Input: omap4-keypad - react on keypresses if device is runtime-suspended
Warning ids grouped by kconfigs:
gcc_recent_errors
|-- arm-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
|-- arm64-randconfig-003-20231212
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-soc-amlogic-meson-secure-pwrc.o
|-- loongarch-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
|-- m68k-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
|-- parisc-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
`-- s390-allmodconfig
|-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
`-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
clang_recent_errors
|-- arm64-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-soc-amlogic-meson-secure-pwrc.o
|-- hexagon-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
|-- i386-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
|-- powerpc-allmodconfig
| |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
| `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
`-- x86_64-allmodconfig
|-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-pata_ftide010.o
`-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-ata-sata_gemini.o
elapsed time: 1191m
configs tested: 173
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc axs103_defconfig gcc
arc defconfig gcc
arc haps_hs_defconfig gcc
arc nsimosci_hs_defconfig gcc
arc randconfig-001-20231212 gcc
arc randconfig-002-20231212 gcc
arc vdk_hs38_smp_defconfig gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm allyesconfig gcc
arm defconfig clang
arm jornada720_defconfig gcc
arm omap2plus_defconfig gcc
arm randconfig-001-20231212 gcc
arm randconfig-002-20231212 gcc
arm randconfig-003-20231212 gcc
arm randconfig-004-20231212 gcc
arm rpc_defconfig gcc
arm vf610m4_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20231212 gcc
arm64 randconfig-002-20231212 gcc
arm64 randconfig-003-20231212 gcc
arm64 randconfig-004-20231212 gcc
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20231212 gcc
csky randconfig-002-20231212 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20231212 gcc
i386 buildonly-randconfig-002-20231212 gcc
i386 buildonly-randconfig-003-20231212 gcc
i386 buildonly-randconfig-004-20231212 gcc
i386 buildonly-randconfig-005-20231212 gcc
i386 buildonly-randconfig-006-20231212 gcc
i386 defconfig gcc
i386 randconfig-001-20231212 gcc
i386 randconfig-002-20231212 gcc
i386 randconfig-003-20231212 gcc
i386 randconfig-004-20231212 gcc
i386 randconfig-005-20231212 gcc
i386 randconfig-006-20231212 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20231212 gcc
loongarch randconfig-002-20231212 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k amiga_defconfig gcc
m68k defconfig gcc
m68k m5307c3_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
microblaze mmu_defconfig gcc
mips allnoconfig clang
mips allyesconfig gcc
mips bcm47xx_defconfig gcc
mips gpr_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20231212 gcc
nios2 randconfig-002-20231212 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20231212 gcc
parisc randconfig-002-20231212 gcc
parisc64 defconfig gcc
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc amigaone_defconfig gcc
powerpc pasemi_defconfig gcc
powerpc randconfig-001-20231212 gcc
powerpc randconfig-002-20231212 gcc
powerpc randconfig-003-20231212 gcc
powerpc64 randconfig-001-20231212 gcc
powerpc64 randconfig-002-20231212 gcc
powerpc64 randconfig-003-20231212 gcc
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allyesconfig gcc
riscv defconfig gcc
riscv nommu_k210_defconfig gcc
riscv randconfig-001-20231212 gcc
riscv randconfig-002-20231212 gcc
riscv rv32_defconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
sh alldefconfig gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh dreamcast_defconfig gcc
sh edosk7760_defconfig gcc
sh kfr2r09_defconfig gcc
sh migor_defconfig gcc
sh randconfig-001-20231212 gcc
sh randconfig-002-20231212 gcc
sh se7724_defconfig gcc
sh sh7763rdp_defconfig gcc
sh sh7770_generic_defconfig gcc
sh titan_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20231212 gcc
sparc64 randconfig-002-20231212 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20231212 gcc
um randconfig-002-20231212 gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20231212 gcc
x86_64 buildonly-randconfig-002-20231212 gcc
x86_64 buildonly-randconfig-003-20231212 gcc
x86_64 buildonly-randconfig-004-20231212 gcc
x86_64 buildonly-randconfig-005-20231212 gcc
x86_64 buildonly-randconfig-006-20231212 gcc
x86_64 defconfig gcc
x86_64 randconfig-011-20231212 gcc
x86_64 randconfig-012-20231212 gcc
x86_64 randconfig-013-20231212 gcc
x86_64 randconfig-014-20231212 gcc
x86_64 randconfig-015-20231212 gcc
x86_64 randconfig-016-20231212 gcc
x86_64 randconfig-071-20231212 gcc
x86_64 randconfig-072-20231212 gcc
x86_64 randconfig-073-20231212 gcc
x86_64 randconfig-074-20231212 gcc
x86_64 randconfig-075-20231212 gcc
x86_64 randconfig-076-20231212 gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa randconfig-001-20231212 gcc
xtensa randconfig-002-20231212 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] irq: Resolve that mask_irq/unmask_irq may not be called in pairs
From: xiongxin @ 2023-12-13 2:29 UTC (permalink / raw)
To: Thomas Gleixner, jikos, benjamin.tissoires
Cc: linux-input, stable, Riwen Lu, hoan, fancer.lancer, linus.walleij,
brgl, andy, linux-gpio, linux-kernel
In-Reply-To: <874jgnqwlo.ffs@tglx>
在 2023/12/12 23:17, Thomas Gleixner 写道:
> On Mon, Dec 11 2023 at 11:10, xiongxin@kylinos.cn wrote:
>> 在 2023/12/8 21:52, Thomas Gleixner 写道:
>>> On Thu, Dec 07 2023 at 09:40, xiongxin@kylinos.cn wrote:
>>> Disabled interrupts are disabled and can only be reenabled by the
>>> corresponding enable call. The existing code is entirely correct.
>>>
>>> What you are trying to do is unmasking a disabled interrupt, which
>>> results in inconsistent state.
>>>
>>> Which interrupt chip is involved here?
>>
>> i2c hid driver use gpio interrupt controller like
>> drivers/gpio/gpio-dwapb.c, The gpio interrupt controller code implements
>> handle_level_irq() and irq_disabled().
>
> No it does not. handle_level_irq() is implemented in the interrupt core
> code and irq_disabled() is not a function at all.
>
> Please describe things precisely and not by fairy tales.
>
>> Normally, when using the i2c hid device, the gpio interrupt controller's
>> mask_irq() and unmask_irq() are called in pairs.
>
> Sure. That's how the core code works.
>
>> But when doing a sleep process, such as suspend to RAM,
>> i2c_hid_core_suspend() of the i2c hid driver is called, which implements
>> the disable_irq() function,
>
> IOW, i2c_hid_core_suspend() disables the interrupt of the client device.
>
>> which finally calls __irq_disable(). Because
>> the desc parameter is set to the __irq_disabled() function without a
>> lock (desk->lock), the __irq_disabled() function can be called during
>
> That's nonsense.
>
> disable_irq(irq)
> if (!__disable_irq_nosync(irq)
> desc = irq_get_desc_buslock(irq, &flags, IRQ_GET_DESC_CHECK_GLOBAL);
>
> ^^^^^^^^^^^^^^^^^^^^ This locks the interrupt descriptor
>
> And yes disable_irq() can be invoked when the interrupt is handled
> concurrently. That's legitimate and absolutely correct, but that has
> absolutely nothing to do with the locking.
>
> The point is that after disable_irq() returns the interrupt handler is
> guaranteed not to be running and not to be invoked anymore until
> something invokes enable_irq().
>
> The fact that disable_irq() marks the interrupt disabled prevents the
> hard interrupt handler and the threaded handler to unmask the interrupt.
> That's correct and fundamental to ensure that the interrupt is and stays
> truly disabled.
>
>> if (!irqd_irq_disabled() && irqd_irq_masked())
>> unmask_irq();
>
>> In this scenario, unmask_irq() will not be called, and then gpio
>> corresponding interrupt pin will be masked.
>
> It _cannot_ be called because the interrupt is _disabled_, which means
> the interrupt stays masked. Correctly so.
>
>> Finally, in the suspend() process driven by gpio interrupt controller,
>> the interrupt mask register will be saved, and then masked will
>> continue to be read when resuming () process. After the kernel
>> resumed, the i2c hid gpio interrupt was masked and the i2c hid device
>> was unavailable.
>
> That's just wrong again.
>
> Suspend:
>
> i2c_hid_core_suspend()
> disable_irq(); <- Marks it disabled and eventually
> masks it.
>
> gpio_irq_suspend()
> save_registers(); <- Saves masked interrupt
>
> Resume:
>
> gpio_irq_resume()
> restore_registers(); <- Restores masked interrupt
>
> i2c_hid_core_resume()
> enable_irq(); <- Unmasks interrupt and removes the
> disabled marker
>
> As I explained you before, disable_irq() can only be undone by
> enable_irq() and not by ignoring the disabled state somewhere
> else. Disabled state is well defined.
>
> So if the drivers behave correctly in terms of suspend/resume ordering
> as shown above, then this all should just work.
>
> If it does not then please figure out what's the actual underlying
> problem instead of violating well defined constraints in the core code
> and telling me fairy tales about the code.
>
> Thanks,
>
> tglx
>
>
>
>
Sorry, the previous reply may not have clarified the BUG process. I
re-debugged and confirmed it yesterday. The current BUG execution
sequence is described as follows:
1: call in interrupt context
handle_level_irq(struct irq_desc *desc)
raw_spin_lock(&desc->lock);
mask_ack_irq(desc);
mask_irq(desc);
desc->irq_data.chip->irq_mask(&desc->irq_data);
<--- gpio irq_chip irq_mask call func.
irq_state_set_masked(desc);
...
handle_irq_event(desc); <--- wake interrupt handler thread
cond_unmask_irq(desc);
raw_spin_unlock(&desc->lock);
2: call in suspend process
i2c_hid_core_suspend()
disable_irq(client->irq);
__disable_irq_nosync(irq)
desc = irq_get_desc_buslock(...);
__disable_irq(desc);
irq_disable(desc);
__irq_disable(...);
irq_state_set_disabled(...); <-set disabled flag
irq_state_set_masked(desc); <-set masked flag
irq_put_desc_busunlock(desc, flags);
3: Interrupt handler thread call
irq_thread_fn()
irq_finalize_oneshot(desc, action);
raw_spin_lock_irq(&desc->lock);
if (!desc->threads_oneshot &&
!irqd_irq_disabled(&desc->irq_data) && <-
irqd_irq_masked(&desc->irq_data))
unmask_threaded_irq(desc);
unmask_irq(desc);
desc->irq_data.chip->irq_unmask(&desc->irq_data);
<--- gpio irq_chip irq_unmask call func.
raw_spin_unlock_irq(&desc->lock);
That is, there is a time between the 1:handle_level_irq() and
3:irq_thread_fn() calls for the 2:disable_irq() call to acquire the lock
and then implement the irq_state_set_disabled() operation. When finally
call irq_thread_fn()->irq_finalize_oneshot(), it cannot enter the
unmask_thread_irq() process.
In this case, the gpio irq_chip irq_mask()/irq_unmask() callback pairs
are not called in pairs, so I think this is a BUG, but not necessarily
fixed from the irq core code layer.
Next, when the gpio controller driver calls the suspend/resume process,
it is as follows:
suspend process:
dwapb_gpio_suspend()
ctx->int_mask = dwapb_read(gpio, GPIO_INTMASK);
resume process:
dwapb_gpio_resume()
dwapb_write(gpio, GPIO_INTMASK, ctx->int_mask);
In this case, the masked interrupt bit of GPIO interrupt corresponding
to i2c hid is saved, so that when gpio resume() process writes from the
register, the gpio interrupt bit corresponding to i2c hid is masked and
the i2c hid device cannot be used.
My first solution is to remove the !irqd_irq_disabled(&desc->irq_data)
condition and the BUG disappears. I can't think of a better solution
right now.
^ permalink raw reply
* Re: [PATCH] irq: Resolve that mask_irq/unmask_irq may not be called in pairs
From: xiongxin @ 2023-12-13 2:35 UTC (permalink / raw)
To: Jiri Kosina
Cc: Thomas Gleixner, benjamin.tissoires, linux-input, stable,
Riwen Lu
In-Reply-To: <1702429454313015.485.seg@mailgw>
在 2023/12/13 00:57, Jiri Kosina 写道:
> On Mon, 11 Dec 2023, xiongxin wrote:
>
>> In this scenario, unmask_irq() will not be called, and then gpio corresponding
>> interrupt pin will be masked. Finally, in the suspend() process driven by gpio
>> interrupt controller, the interrupt mask register will be saved, and then
>> masked will continue to be read when resuming () process. After the kernel
>> resumed, the i2c hid gpio interrupt was masked and the i2c hid device was
>> unavailable.
>
> In addition to what Thomas already wrote -- what exactly is the problem
> you are trying to solve here?
>
> Is it that your device drive by i2c-hid driver is no longer sending any
> data reports after a suspend/resume cycle? What makes you think that it's
> because of its IRQ being disabled?
>
> Don't you just perhaps need I2C_HID_QUIRK_RESET_ON_RESUME quirk for that
> device?
>
I have confirmed I2C_HID_QUIRK_RESET_ON_RESUME quirk, the current BUG is
related to GPIO interrupt masking, and has little to do with hid code.
I explained the detailed process of the BUG in another email.
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: input: microchip,cap11xx: add advanced sensitivity settings
From: Dmitry Torokhov @ 2023-12-13 3:18 UTC (permalink / raw)
To: Jiri Valek - 2N
Cc: krzysztof.kozlowski+dt, devicetree, linux-input, linux-kernel,
robh+dt, u.kleine-koenig
In-Reply-To: <20231121155250.613242-2-jiriv@axis.com>
On Tue, Nov 21, 2023 at 04:52:49PM +0100, Jiri Valek - 2N wrote:
> Add support for advanced sensitivity settings and signal guard feature.
>
> Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v6 2/2] Input: cap11xx - add advanced sensitivity settings
From: Dmitry Torokhov @ 2023-12-13 3:18 UTC (permalink / raw)
To: Jiri Valek - 2N
Cc: krzysztof.kozlowski+dt, devicetree, linux-input, linux-kernel,
robh+dt, u.kleine-koenig
In-Reply-To: <20231121155250.613242-3-jiriv@axis.com>
On Tue, Nov 21, 2023 at 04:52:50PM +0100, Jiri Valek - 2N wrote:
> Add support for advanced sensitivity settings that allows more precise
> tunig of touch buttons. Input-treshold allows to set the sensitivity for
> each channel separately. Also add signal guard feature for CAP129x chips.
>
> Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: xpad - add Razer Wolverine V2 support
From: Dmitry Torokhov @ 2023-12-13 3:24 UTC (permalink / raw)
To: Luca Weiss; +Cc: linux-input, linux-kernel
In-Reply-To: <20231125-razer-wolverine-v2-v1-1-979fe9f9288e@z3ntu.xyz>
On Sat, Nov 25, 2023 at 05:22:15PM +0100, Luca Weiss wrote:
> Add the VID and PID of Razer Wolverine V2 to xpad_device.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: cap11xx - stop using chip ID when configuring it
From: Dmitry Torokhov @ 2023-12-13 5:33 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Valek - 2N, linux-kernel
struct cap11xx_hw_model is supposed to describe the chip capabilities,
however later code changes introduced checks against chip ID.
Introduce new capabilities in cap11xx_hw_model and use them when applying
chip configuration, and remove the enum for chip ID. While at it, rename
no_gain to has_gain to match the rest of the new capabilities.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/cap11xx.c | 125 +++++++++++++++++--------------
1 file changed, 70 insertions(+), 55 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index ebcbc00d2059..c85bb0ca0e39 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -86,7 +86,6 @@ struct cap11xx_priv {
struct device *dev;
struct input_dev *idev;
const struct cap11xx_hw_model *model;
- u8 id;
struct cap11xx_led *leds;
int num_leds;
@@ -104,27 +103,10 @@ struct cap11xx_hw_model {
u8 product_id;
unsigned int num_channels;
unsigned int num_leds;
- bool no_gain;
-};
-
-enum {
- CAP1106,
- CAP1126,
- CAP1188,
- CAP1203,
- CAP1206,
- CAP1293,
- CAP1298
-};
-
-static const struct cap11xx_hw_model cap11xx_devices[] = {
- [CAP1106] = { .product_id = 0x55, .num_channels = 6, .num_leds = 0, .no_gain = false },
- [CAP1126] = { .product_id = 0x53, .num_channels = 6, .num_leds = 2, .no_gain = false },
- [CAP1188] = { .product_id = 0x50, .num_channels = 8, .num_leds = 8, .no_gain = false },
- [CAP1203] = { .product_id = 0x6d, .num_channels = 3, .num_leds = 0, .no_gain = true },
- [CAP1206] = { .product_id = 0x67, .num_channels = 6, .num_leds = 0, .no_gain = true },
- [CAP1293] = { .product_id = 0x6f, .num_channels = 3, .num_leds = 0, .no_gain = false },
- [CAP1298] = { .product_id = 0x71, .num_channels = 8, .num_leds = 0, .no_gain = false },
+ bool has_gain;
+ bool has_irq_config;
+ bool has_sensitivity_control;
+ bool has_signal_guard;
};
static const struct reg_default cap11xx_reg_defaults[] = {
@@ -227,7 +209,7 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
}
if (!of_property_read_u32(node, "microchip,sensor-gain", &u32_val)) {
- if (priv->model->no_gain) {
+ if (!priv->model->has_gain) {
dev_warn(dev,
"This model doesn't support 'sensor-gain'\n");
} else if (is_power_of_2(u32_val) && u32_val <= 8) {
@@ -246,9 +228,7 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
}
if (of_property_read_bool(node, "microchip,irq-active-high")) {
- if (priv->id == CAP1106 ||
- priv->id == CAP1126 ||
- priv->id == CAP1188) {
+ if (priv->model->has_irq_config) {
error = regmap_update_bits(priv->regmap,
CAP11XX_REG_CONFIG2,
CAP11XX_REG_CONFIG2_ALT_POL,
@@ -299,7 +279,7 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
if (!of_property_read_u32_array(node, "microchip,calib-sensitivity",
priv->calib_sensitivities,
priv->model->num_channels)) {
- if (priv->id == CAP1293 || priv->id == CAP1298) {
+ if (priv->model->has_sensitivity_control) {
for (i = 0; i < priv->model->num_channels; i++) {
if (!is_power_of_2(priv->calib_sensitivities[i]) ||
priv->calib_sensitivities[i] > 4) {
@@ -314,7 +294,7 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
if (error)
return error;
- if (priv->id == CAP1298) {
+ if (priv->model->num_channels > 4) {
error = cap11xx_write_calib_sens_config_2(priv);
if (error)
return error;
@@ -336,7 +316,7 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
}
if (priv->signal_guard_inputs_mask) {
- if (priv->id == CAP1293 || priv->id == CAP1298) {
+ if (priv->model->has_signal_guard) {
error = regmap_write(priv->regmap,
CAP11XX_REG_SIGNAL_GUARD_ENABLE,
priv->signal_guard_inputs_mask);
@@ -511,20 +491,16 @@ static int cap11xx_init_leds(struct device *dev,
static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
{
- const struct i2c_device_id *id = i2c_client_get_device_id(i2c_client);
+ const struct i2c_device_id *id;
+ const struct cap11xx_hw_model *cap;
struct device *dev = &i2c_client->dev;
struct cap11xx_priv *priv;
- const struct cap11xx_hw_model *cap;
int i, error;
unsigned int val, rev;
- if (id->driver_data >= ARRAY_SIZE(cap11xx_devices)) {
- dev_err(dev, "Invalid device ID %lu\n", id->driver_data);
- return -EINVAL;
- }
-
- cap = &cap11xx_devices[id->driver_data];
- if (!cap || !cap->num_channels) {
+ id = i2c_client_get_device_id(i2c_client);
+ cap = i2c_get_match_data(i2c_client);
+ if (!id || !cap || !cap->num_channels) {
dev_err(dev, "Invalid device configuration\n");
return -EINVAL;
}
@@ -569,7 +545,6 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
id->name, rev);
priv->model = cap;
- priv->id = id->driver_data;
dev_info(dev, "CAP11XX device detected, model %s, revision 0x%02x\n",
id->name, rev);
@@ -630,27 +605,67 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
return 0;
}
+static const struct cap11xx_hw_model cap1106_model = {
+ .product_id = 0x55, .num_channels = 6, .num_leds = 0,
+ .has_gain = true,
+ .has_irq_config = true,
+};
+
+static const struct cap11xx_hw_model cap1126_model = {
+ .product_id = 0x53, .num_channels = 6, .num_leds = 2,
+ .has_gain = true,
+ .has_irq_config = true,
+};
+
+static const struct cap11xx_hw_model cap1188_model = {
+ .product_id = 0x50, .num_channels = 8, .num_leds = 8,
+ .has_gain = true,
+ .has_irq_config = true,
+};
+
+static const struct cap11xx_hw_model cap1203_model = {
+ .product_id = 0x6d, .num_channels = 3, .num_leds = 0,
+};
+
+static const struct cap11xx_hw_model cap1206_model = {
+ .product_id = 0x67, .num_channels = 6, .num_leds = 0,
+};
+
+static const struct cap11xx_hw_model cap1293_model = {
+ .product_id = 0x6f, .num_channels = 3, .num_leds = 0,
+ .has_gain = true,
+ .has_sensitivity_control = true,
+ .has_signal_guard = true,
+};
+
+static const struct cap11xx_hw_model cap1298_model = {
+ .product_id = 0x71, .num_channels = 8, .num_leds = 0,
+ .has_gain = true,
+ .has_sensitivity_control = true,
+ .has_signal_guard = true,
+};
+
static const struct of_device_id cap11xx_dt_ids[] = {
- { .compatible = "microchip,cap1106", },
- { .compatible = "microchip,cap1126", },
- { .compatible = "microchip,cap1188", },
- { .compatible = "microchip,cap1203", },
- { .compatible = "microchip,cap1206", },
- { .compatible = "microchip,cap1293", },
- { .compatible = "microchip,cap1298", },
- {}
+ { .compatible = "microchip,cap1106", .data = &cap1106_model },
+ { .compatible = "microchip,cap1126", .data = &cap1126_model },
+ { .compatible = "microchip,cap1188", .data = &cap1188_model },
+ { .compatible = "microchip,cap1203", .data = &cap1203_model },
+ { .compatible = "microchip,cap1206", .data = &cap1206_model },
+ { .compatible = "microchip,cap1293", .data = &cap1293_model },
+ { .compatible = "microchip,cap1298", .data = &cap1298_model },
+ { }
};
MODULE_DEVICE_TABLE(of, cap11xx_dt_ids);
static const struct i2c_device_id cap11xx_i2c_ids[] = {
- { "cap1106", CAP1106 },
- { "cap1126", CAP1126 },
- { "cap1188", CAP1188 },
- { "cap1203", CAP1203 },
- { "cap1206", CAP1206 },
- { "cap1293", CAP1293 },
- { "cap1298", CAP1298 },
- {}
+ { "cap1106", (kernel_ulong_t)&cap1106_model },
+ { "cap1126", (kernel_ulong_t)&cap1126_model },
+ { "cap1188", (kernel_ulong_t)&cap1188_model },
+ { "cap1203", (kernel_ulong_t)&cap1203_model },
+ { "cap1206", (kernel_ulong_t)&cap1206_model },
+ { "cap1293", (kernel_ulong_t)&cap1293_model },
+ { "cap1298", (kernel_ulong_t)&cap1298_model },
+ { }
};
MODULE_DEVICE_TABLE(i2c, cap11xx_i2c_ids);
--
2.43.0.472.g3155946c3a-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH 0/3] Input: Small regmap improvements
From: Dmitry Torokhov @ 2023-12-13 5:39 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-input, linux-kernel
In-Reply-To: <20231001-input-maple-v1-0-ed3716051431@kernel.org>
On Sun, Oct 01, 2023 at 01:43:37AM +0200, Mark Brown wrote:
> This series has a few small improvements to the regmap usage in some of
> the input drivers, there's nothing really important here but it's all
> nice to have.
Applied the lot, sorry for the delay.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: max77693-haptic - add device-tree compatible strings
From: Dmitry Torokhov @ 2023-12-13 5:42 UTC (permalink / raw)
To: Marek Szyprowski; +Cc: linux-input, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20231006100320.2908210-1-m.szyprowski@samsung.com>
On Fri, Oct 06, 2023 at 12:03:20PM +0200, Marek Szyprowski wrote:
> Add the needed device-tree compatible strings to the MAX77693 haptic
> driver, so it can be automatically loaded when compiled as a kernel
> module and given device-tree contains separate (i.e. 'motor-driver') node
> under the main PMIC node. When device is instantiated from device-tree,
> the driver data cannot be read via platform_get_device_id(), so get
> device type from the parent MFD device instead, what works for both
> cases.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 01/37] dt-bindings: input: qcom,pm8921-keypad: convert to YAML format
From: Dmitry Torokhov @ 2023-12-13 5:51 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: devicetree, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Andy Gross, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
Jonathan Cameron, Lars-Peter Clausen, linux-iio, linux-input,
Pavel Machek, linux-leds, Krzysztof Kozlowski
In-Reply-To: <20230827132525.951475-2-dmitry.baryshkov@linaro.org>
On Sun, Aug 27, 2023 at 04:24:49PM +0300, Dmitry Baryshkov wrote:
> Convert the bindings for the keypad subdevices of Qualcomm PM8921 and
> PM8058 PMICs from text to YAML format.
>
> While doing the conversion also drop the linux,keypad-no-autorepeat
> The property was never used by DT files. Both input and DT binding
> maintainers consider that bindings should switch to assertive
> (linux,autorepeat) instead of negating (no-autorepeat) property.
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Krzysztof Kozlowski @ 2023-12-13 6:40 UTC (permalink / raw)
To: Biju Das, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input, devicetree, linux-pm,
Geert Uytterhoeven, Prabhakar Mahadev Lad, Biju Das,
linux-renesas-soc
In-Reply-To: <20231210134717.94020-9-biju.das.jz@bp.renesas.com>
On 10/12/2023 14:47, Biju Das wrote:
> Convert the da9062 PMIC device tree binding documentation to json-schema.
>
> Document the missing gpio child node for da9062.
>
> While at it, update description with link to product information and
> example.
>
> The missing child node with of_compatible defined in MFD_CELL_OF is
> causing the below warning message:
> da9062-gpio: Failed to locate of_node [id: -1]
>
> So, make all child nodes with of_compatible defined in struct mfd_cell
> as required property for da906{1,2} devices.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Some explanation about gpio node and gpio-controller in the main device
would be indeed nice, as Conor suggested.
But anyway looks good to me. Thank you for the conversion to DT schema.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/3] dt-bindings: input: Add TouchNetix axiom touchscreen
From: Krzysztof Kozlowski @ 2023-12-13 6:44 UTC (permalink / raw)
To: Conor Dooley, Kamel Bouhara
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy, catalin.popescu, mark.satterthwaite,
bartp, hannah.rossiter, Thomas Petazzoni, Gregory Clement,
bsp-development.geo
In-Reply-To: <20231212-rework-bounce-f4d9d12362a4@spud>
On 12/12/2023 17:57, Conor Dooley wrote:
> On Mon, Dec 11, 2023 at 01:14:28PM +0100, Kamel Bouhara wrote:
>> Add the TouchNetix axiom I2C touchscreen device tree bindings
>> documentation.
>>
>> Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
>> ---
>> .../input/touchscreen/touchnetix,ax54a.yaml | 64 +++++++++++++++++++
>> MAINTAINERS | 6 ++
>> 2 files changed, 70 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
>> new file mode 100644
>> index 000000000000..cbdf48fc538b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
>> @@ -0,0 +1,64 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/input/touchscreen/touchnetix,ax54a.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TouchNetix Axiom series touchscreen controller
>> +
>> +maintainers:
>> + - Kamel Bouhara <kamel.bouhara@bootlin.com>
>> +
>> +allOf:
>> + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
>
> Weird, you add this ref here but do not actually allow any properties
> from it since you have "additionalProperties: false" below.
>
> What's the point of its inclusion?
It still brings the type of some fields or the constraints. However need
of specifying "poll-interval" already points to missing
unevaluatedProperties.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] Input: misc: use sysfs_emit() to instead of scnprintf()
From: Dmitry Torokhov @ 2023-12-13 6:57 UTC (permalink / raw)
To: Jeff LaBundy; +Cc: ye.xingchen, colin.i.king, linux-input, linux-kernel
In-Reply-To: <Y4jbOX4ePJz7vbu1@nixie71>
On Thu, Dec 01, 2022 at 10:50:01AM -0600, Jeff LaBundy wrote:
> Hi Ye,
>
> On Thu, Dec 01, 2022 at 03:48:38PM +0800, ye.xingchen@zte.com.cn wrote:
> > From: ye xingchen <ye.xingchen@zte.com.cn>
> >
> > Replace the open-code with sysfs_emit() to simplify the code.
> >
> > Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
> > ---
> > drivers/input/misc/ims-pcu.c | 10 +++++-----
> > drivers/input/misc/iqs269a.c | 18 +++++++++---------
Split the patch in 2 for each driver, adjusted to the latest code and
applied.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: use sysfs_emit() to instead of scnprintf()
From: Dmitry Torokhov @ 2023-12-13 6:57 UTC (permalink / raw)
To: ye.xingchen; +Cc: linux-input, linux-kernel, jeff
In-Reply-To: <202212021133398847947@zte.com.cn>
On Fri, Dec 02, 2022 at 11:33:39AM +0800, ye.xingchen@zte.com.cn wrote:
> From: ye xingchen <ye.xingchen@zte.com.cn>
>
> Replace the open-code with sysfs_emit() to simplify the code.
>
> Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: mouse: use sysfs_emit() to instead of scnprintf()
From: Dmitry Torokhov @ 2023-12-13 6:57 UTC (permalink / raw)
To: ye.xingchen; +Cc: jiangjian, linux-input, linux-kernel, jeff
In-Reply-To: <202212021453578171100@zte.com.cn>
On Fri, Dec 02, 2022 at 02:53:57PM +0800, ye.xingchen@zte.com.cn wrote:
> From: ye xingchen <ye.xingchen@zte.com.cn>
>
> Replace the open-code with sysfs_emit() to simplify the code.
>
> Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: rmi4: use sysfs_emit() to instead of scnprintf()
From: Dmitry Torokhov @ 2023-12-13 6:57 UTC (permalink / raw)
To: ye.xingchen; +Cc: linux-input, linux-kernel, jeff
In-Reply-To: <202212021504062431427@zte.com.cn>
On Fri, Dec 02, 2022 at 03:04:06PM +0800, ye.xingchen@zte.com.cn wrote:
> From: ye xingchen <ye.xingchen@zte.com.cn>
>
> Replace the open-code with sysfs_emit() to simplify the code.
>
> Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4] Input: touchscreen: use sysfs_emit() to instead of scnprintf()
From: Dmitry Torokhov @ 2023-12-13 6:58 UTC (permalink / raw)
To: ye.xingchen
Cc: oliver.graute, u.kleine-koenig, jeff, nick, giulio.benetti,
michael, dario.binacchi, wsa+renesas, johan, linux-input,
linux-kernel
In-Reply-To: <202212061148163560976@zte.com.cn>
On Tue, Dec 06, 2022 at 11:48:16AM +0800, ye.xingchen@zte.com.cn wrote:
> From: ye xingchen <ye.xingchen@zte.com.cn>
>
> Follow the advice of the Documentation/filesystems/sysfs.rst and show()
> should only use sysfs_emit() or sysfs_emit_at() when formatting the
> value to be returned to user space.
>
> Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Acked-by: Oliver Graute <oliver.graute@kococonnector.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: Convert to use sysfs_emit_at() API
From: Dmitry Torokhov @ 2023-12-13 6:58 UTC (permalink / raw)
To: ye.xingchen; +Cc: linux-input, linux-kernel, jeff
In-Reply-To: <202212071644171074630@zte.com.cn>
On Wed, Dec 07, 2022 at 04:44:17PM +0800, ye.xingchen@zte.com.cn wrote:
> From: ye xingchen <ye.xingchen@zte.com.cn>
>
> Follow the advice of the Documentation/filesystems/sysfs.rst and show()
> should only use sysfs_emit() or sysfs_emit_at() when formatting the
> value to be returned to user space.
>
> Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 3/4] Input: omap-keypad - Drop optional GPIO support
From: Dmitry Torokhov @ 2023-12-13 7:10 UTC (permalink / raw)
To: Linus Walleij; +Cc: Tony Lindgren, linux-input
In-Reply-To: <20231129-descriptors-input-v1-3-9433162914a3@linaro.org>
On Wed, Nov 29, 2023 at 02:51:47PM +0100, Linus Walleij wrote:
> @@ -180,7 +176,7 @@ static int omap_kp_probe(struct platform_device *pdev)
> struct omap_kp *omap_kp;
> struct input_dev *input_dev;
> struct omap_kp_platform_data *pdata = dev_get_platdata(&pdev->dev);
> - int i, col_idx, row_idx, ret;
> + int col_idx, row_idx, ret;
col_idx and row_idx are not longer needed wither, I dropped them and
applied the patch.
Thanks.
--
Dmitry
^ 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