* [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Danny Kaehn @ 2026-01-27 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andy Shevchenko, Danny Kaehn, Andi Shyti, Conor Dooley
Cc: Jiri Kosina, devicetree, linux-input, Dmitry Torokhov,
Bartosz Golaszewski, Ethan Twardy, linux-i2c, linux-kernel,
Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260127-cp2112-dt-v13-0-6448ddd4bf22@plexus.com>
This is a USB HID device which includes an I2C controller and 8 GPIO pins.
The binding allows describing the chip's gpio and i2c controller in DT,
with the i2c controller being bound to a subnode named "i2c". This is
intended to be used in configurations where the CP2112 is permanently
connected in hardware.
Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
---
.../devicetree/bindings/i2c/silabs,cp2112.yaml | 100 +++++++++++++++++++++
1 file changed, 100 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
new file mode 100644
index 000000000000..a204adfe57b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/silabs,cp2112.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CP2112 HID USB to SMBus/I2C Bridge
+
+maintainers:
+ - Danny Kaehn <danny.kaehn@plexus.com>
+
+description:
+ The CP2112 is a USB HID device which includes an integrated I2C controller
+ and 8 GPIO pins. Its GPIO pins can each be configured as inputs, open-drain
+ outputs, or push-pull outputs.
+
+properties:
+ compatible:
+ const: usb10c4,ea90
+
+ reg:
+ maxItems: 1
+ description: The USB port number
+
+ interrupt-controller: true
+ "#interrupt-cells":
+ const: 2
+
+ gpio-controller: true
+ "#gpio-cells":
+ const: 2
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 8
+
+ i2c:
+ description: The SMBus/I2C controller node for the CP2112
+ $ref: /schemas/i2c/i2c-controller.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-frequency:
+ minimum: 10000
+ default: 100000
+ maximum: 400000
+
+patternProperties:
+ "-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cp2112: device@1 {
+ compatible = "usb10c4,ea90";
+ reg = <1>;
+
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #gpio-cells = <2>;
+ gpio-line-names = "CP2112_SDA", "CP2112_SCL", "TEST2",
+ "TEST3","TEST4", "TEST5", "TEST6";
+
+ fan-rst-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "FAN_RST";
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sda-gpios = <&cp2112 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&cp2112 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ temp@48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+ };
+ };
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v13 0/3] Firmware Support for USB-HID Devices and CP2112
From: Danny Kaehn @ 2026-01-27 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andy Shevchenko, Danny Kaehn, Andi Shyti, Conor Dooley
Cc: Jiri Kosina, devicetree, linux-input, Dmitry Torokhov,
Bartosz Golaszewski, Ethan Twardy, linux-i2c, linux-kernel,
Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
This patchset allows USB-HID devices to have Firmware bindings through sharing
the USB fwnode with the HID driver, and adds such a binding and driver
implementation for the CP2112 USB to SMBus Bridge (which necessitated the
USB-HID change). This change allows a CP2112 permanently attached in hardware to
be described in DT and ACPI and interoperate with other drivers.
Changes in v13:
- dt-binding changes:
- drop scl-gpios and sda-gpios from binding, since they are included
from the i2c-controller schena.
- Set indentation to 4 spaces consistently for the DTS example
- Fix alignment for gpio-line-names in the example
- Use dev_fwnode in hid-cp2112.c instead of directly accessing fwnode
- Immediately release the fwnode_handle from
device_get_named_child_node() in hid-cp2112.c
- Link to v12: https://lore.kernel.org/r/20251126-cp2112-dt-v12-0-2cdba6481db3@plexus.com
Changes in v12:
- dt-binding changes:
- Drop "on the host controller" from top-level description based on
comment from Rob H.
- Correct "Properties must precede subnodes" dt_binding_check error by
moving gpio_chip-related properties above the i2c subnode in the
binding and in the example.
- Include `interrupt-controller` property in the example
- Modify hid-cp2112.c to support separate schemas for DT vs. ACPI - DT
combines gpio subnode with the CP2112's node, but will have an I2C
subnode; while ACPI will maintain separate child nodes for the GPIO
I2C devices
Changes in v11:
- Eliminate 'gpio' subnode for DT and ACPI for the CP2112 per comment
from Rob H.
- Edit hid-cp2112.c to match for ACPI index and fall back to matching by
name (instead of the other way around)
- Separate CP2112 I2C bus speed configuration into a separate patch
Changes in v10:
- Define an enumeration and mapping for CP2112 ACPI _ADRs and devicetree
child node names, and use these in the scanning of child nodes
- Address other miscellaneous
Changes in v9:
- Add _ADR-based ACPI binding of child nodes (I2C is _ADR Zero, GPIO is _ADR One)
- Use a loop-based approach for assigning child nodes within probe().
As a consequence, hid-cp2112.c no longer maintains references to the
child fwnodes during the lifetime of the device. (plese correct if this
is actually needed for this use-case)
Changes in v8:
- Apply Review tags retroactively to patches previously reviewed
Changes in v7:
- Use dev_fwnode when calling fwnod_handle_put in i2c_adapter in hid-cp2112.c
- Capitalize I2C and GPIO in commit message for patch 0003
Changes in v6:
- Fix fwnode_handle reference leaks in hid-cp21112.c
- Simplify hog node pattern in silabs,cp2112.yaml
Changes in v5:
- Use fwnode API instead of of_node api in hid-core.c and hid-cp2112.c
- Include sda-gpios and scl-gpios in silabs,cp2112.yaml
- Additional fixups to silabs,cp2112.yaml to address comments
- Remove ngpios property
- Constrain the hog pattern to a single naming scheme
- Remove unneeded properties from the gpio hog which are provided by
the parent schema
- Submit threaded interrupt bugfix separately from this patchset, as requested
Changes in v4:
- Moved silabs,cp2112.yaml to /Documentation/devicetree/bindings/i2c
Changes in v3:
- Additional fixups to silabs,cp2112.yaml to address comments
Changes in v2:
- Added more detail to silabs,cp2112.yaml dt-binding
- Moved silabs,cp2112.yaml to /Documentation/devicetree/bindings/input
- Added support for setting smbus clock-frequency from DT in hid-cp2112.c
- Added freeing of of_nodes on error paths of _probe in hid-cp2112.c
Danny Kaehn (3):
dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
HID: usbhid: Share USB device firmware node with child HID device
HID: cp2112: Fwnode Support
.../bindings/i2c/silabs,cp2112.yaml | 113 ++++++++++++++++++
drivers/hid/hid-cp2112.c | 50 ++++++++
drivers/hid/usbhid/hid-core.c | 2 +
3 files changed, 165 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
--
2.25.1
---
Danny Kaehn (3):
dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
HID: cp2112: Fwnode Support
HID: cp2112: Configure I2C Bus Speed from Firmware
.../devicetree/bindings/i2c/silabs,cp2112.yaml | 100 +++++++++++++++++++++
drivers/hid/hid-cp2112.c | 37 ++++++++
2 files changed, 137 insertions(+)
---
base-commit: 1c772200c9dcb23a304f84a9334fe2e0d9529ab0
change-id: 20240605-cp2112-dt-7cdc95448e8a
Best regards,
--
Danny Kaehn <danny.kaehn@plexus.com>
^ permalink raw reply
* [PATCH v13 3/3] HID: cp2112: Configure I2C Bus Speed from Firmware
From: Danny Kaehn @ 2026-01-27 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andy Shevchenko, Danny Kaehn, Andi Shyti, Conor Dooley
Cc: Jiri Kosina, devicetree, linux-input, Dmitry Torokhov,
Bartosz Golaszewski, Ethan Twardy, linux-i2c, linux-kernel,
Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260127-cp2112-dt-v13-0-6448ddd4bf22@plexus.com>
Now that the I2C adapter on the CP2112 can have an associated firmware
node, set the bus speed based on firmware configuration
Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
---
drivers/hid/hid-cp2112.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index ea19b5cb58f9..4c5957e0a5cc 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -1220,6 +1220,7 @@ static int cp2112_probe(struct hid_device *hdev, const struct hid_device_id *id)
struct cp2112_smbus_config_report config;
struct fwnode_handle *child;
struct gpio_irq_chip *girq;
+ struct i2c_timings timings;
u32 addr;
int ret;
@@ -1304,6 +1305,9 @@ static int cp2112_probe(struct hid_device *hdev, const struct hid_device_id *id)
goto err_power_normal;
}
+ i2c_parse_fw_timings(&dev->adap.dev, &timings, true);
+
+ config.clock_speed = cpu_to_be32(timings.bus_freq_hz);
config.retry_time = cpu_to_be16(1);
ret = cp2112_hid_output(hdev, (u8 *)&config, sizeof(config),
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v13 3/3] HID: cp2112: Configure I2C Bus Speed from Firmware
From: Danny Kaehn @ 2026-01-27 14:54 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andy Shevchenko, Andi Shyti, Conor Dooley
Cc: Jiri Kosina, devicetree, linux-input, Dmitry Torokhov,
Bartosz Golaszewski, Ethan Twardy, linux-i2c, linux-kernel,
Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260127-cp2112-dt-v13-3-6448ddd4bf22@plexus.com>
On Tue, Jan 27, 2026 at 08:47:50AM -0600, Danny Kaehn wrote:
> Now that the I2C adapter on the CP2112 can have an associated firmware
> node, set the bus speed based on firmware configuration
>
Apologies, realized post-send that I never addressed Andy's comment
asking for a period at the end here and expressing his sign-off. Will
address with the next send if there is one; else I'll re-send this one
after other approvals.
^ permalink raw reply
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Danny Kaehn @ 2026-01-27 16:02 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andy Shevchenko, Andi Shyti, Conor Dooley
Cc: Jiri Kosina, devicetree, linux-input, Dmitry Torokhov,
Bartosz Golaszewski, Ethan Twardy, linux-i2c, linux-kernel,
Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260127-cp2112-dt-v13-1-6448ddd4bf22@plexus.com>
On Tue, Jan 27, 2026 at 08:47:48AM -0600, Danny Kaehn wrote:
> This is a USB HID device which includes an I2C controller and 8 GPIO pins.
>
> The binding allows describing the chip's gpio and i2c controller in DT,
> with the i2c controller being bound to a subnode named "i2c". This is
> intended to be used in configurations where the CP2112 is permanently
> connected in hardware.
>
> Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
> ---
Hi Folks (Intended for Rob or Krzysztof),
Wasn't sure the best way to go about this, but trying to see the best
way to get a message in front of you regarding an ask from Andy S.
In [1], Rob H initially directed that the gpio chip share a node with
the CP2112 itself, rather than having a subnode named 'gpio'.
Initially, I did the same thing for both DT and ACPI, but Andy S.
directed that ACPI should not have the node be shared in that way.
With the last revision of this patch, Andy S. asked that I try to get a
rationalle from Rob (or other DT expert presumably) on why the gpio node
should be combined with the parent, rather than being a named subnode
[2].
Any context you can provide would be extremely helpful. Apologies about
the age of this patch series and the amount of historical context; some
is due to my long delays between revisions, but other of it is due to
attempting to get the ACPI and DT folks to talk / agree.
[1]: https://lore.kernel.org/all/20240213152825.GA1223720-robh@kernel.org/
[2]: https://lore.kernel.org/all/aSdvv3Qss5oz_o6P@smile.fi.intel.com/
Thanks,
Danny Kaehn
^ permalink raw reply
* [PATCH] Input: apbps2 - fix comment style and typos
From: Bonzupii @ 2026-01-27 18:17 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Micah Ostrow
From: Micah Ostrow <bluefox9516@gmail.com>
Capitalize comment starts to match kernel coding style.
Fix spelling: "reciever" -> "receiver"
Fix grammar: "it's" (contraction of "it is") -> "its" (possessive)
Remove uncertainty from "Clear error bits?" comment.
Compile tested only.
Signed-off-by: Micah Ostrow <bluefox9516@gmail.com>
---
drivers/input/serio/apbps2.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/input/serio/apbps2.c b/drivers/input/serio/apbps2.c
index b815337be2f4..a5fbb27088be 100644
--- a/drivers/input/serio/apbps2.c
+++ b/drivers/input/serio/apbps2.c
@@ -67,7 +67,7 @@ static irqreturn_t apbps2_isr(int irq, void *dev_id)
rxflags = (status & APBPS2_STATUS_PE) ? SERIO_PARITY : 0;
rxflags |= (status & APBPS2_STATUS_FE) ? SERIO_FRAME : 0;
- /* clear error bits? */
+ /* Clear error bits */
if (rxflags)
iowrite32be(0, &priv->regs->status);
@@ -82,9 +82,9 @@ static irqreturn_t apbps2_isr(int irq, void *dev_id)
static int apbps2_write(struct serio *io, unsigned char val)
{
struct apbps2_priv *priv = io->port_data;
- unsigned int tleft = 10000; /* timeout in 100ms */
+ unsigned int tleft = 10000; /* Timeout in 100ms */
- /* delay until PS/2 controller has room for more chars */
+ /* Delay until PS/2 controller has room for more chars */
while ((ioread32be(&priv->regs->status) & APBPS2_STATUS_TF) && tleft--)
udelay(10);
@@ -104,7 +104,7 @@ static int apbps2_open(struct serio *io)
struct apbps2_priv *priv = io->port_data;
int limit;
- /* clear error flags */
+ /* Clear error flags */
iowrite32be(0, &priv->regs->status);
/* Clear old data if available (unlikely) */
@@ -112,7 +112,7 @@ static int apbps2_open(struct serio *io)
while ((ioread32be(&priv->regs->status) & APBPS2_STATUS_DR) && --limit)
ioread32be(&priv->regs->data);
- /* Enable reciever and it's interrupt */
+ /* Enable receiver and its interrupt */
iowrite32be(APBPS2_CTRL_RE | APBPS2_CTRL_RI, &priv->regs->ctrl);
return 0;
@@ -122,7 +122,7 @@ static void apbps2_close(struct serio *io)
{
struct apbps2_priv *priv = io->port_data;
- /* stop interrupts at PS/2 HW level */
+ /* Stop interrupts at PS/2 HW level */
iowrite32be(0, &priv->regs->ctrl);
}
@@ -139,7 +139,7 @@ static int apbps2_of_probe(struct platform_device *ofdev)
return -ENOMEM;
}
- /* Find Device Address */
+ /* Find device address */
priv->regs = devm_platform_get_and_ioremap_resource(ofdev, 0, NULL);
if (IS_ERR(priv->regs))
return PTR_ERR(priv->regs);
--
2.52.0
^ permalink raw reply related
* Re: bcm5974 trackpad broken after USB reset
From: Liam Mitchell @ 2026-01-27 18:25 UTC (permalink / raw)
To: Henrik Rydberg; +Cc: linux-input, Henrik Rydberg
In-Reply-To: <d1a09240-9a0f-486a-872e-8b528ff7e272@bitmath.se>
On Mon, 26 Jan 2026 at 23:20, Henrik Rydberg <rydberg@bitmath.se> wrote:
> Looks like you made real progress here, great stuff! With this
> information, we should be able to provide a proper fix, agreed.
Thanks!
> > I think a more permanent fix could be to set mode on receiving that
> > first packet (control response) and/or on receiving default 8 byte
> > packets.
>
> I like that, expecially if 0x08 never needs to be set, as touching that
> bit would require some sort of rougher handling. It was a bit uncelar if
> your experiment with the 0x00 mode went between 0x08/0x00 or 0x00/0x01.
My previous experiment was between 0x08/0x00. I just tested switching
between 0x00/0x01 and don't see any immediate difference on switching,
just the mentioned difference after sleep/resume.
Regarding never setting 0x08, I see the commit message that introduced
this mentions dropping/repeating keys if 0x08 is not set before
closing (cd72ad3). I couldn't find any traces of this issue or
discussion online. Is it likely to still be an issue?
Liam
^ permalink raw reply
* Re: [PATCH v13 2/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2026-01-27 20:06 UTC (permalink / raw)
To: Danny Kaehn
Cc: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires, Andi Shyti,
Conor Dooley, Jiri Kosina, devicetree, linux-input,
Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260127-cp2112-dt-v13-2-6448ddd4bf22@plexus.com>
On Tue, Jan 27, 2026 at 08:47:49AM -0600, Danny Kaehn wrote:
> Support describing the CP2112's I2C and GPIO interfaces in firmware.
>
> Bindings between the firmware nodes and the functions of the device
> are distinct between ACPI and DeviceTree.
>
> For ACPI, the i2c_adapter will use the child with _ADR Zero and the
_ADR equals to Zero
> gpio_chip will use the child with _ADR One. For DeviceTree, the
_ADR equals to One
> i2c_adapter will use the child with name "i2c", but the gpio_chip
> will share a firmware node with the CP2112.
...
Also it's interesting choice of capital letters in the Subject.
I would expect "...: Add fwnode support"
...
> +/**
> + * enum cp2112_child_acpi_cell_addrs - Child ACPI addresses for CP2112 sub-functions
> + * @CP2112_I2C_ADR: Address for I2C node
> + * @CP2112_GPIO_ADR: Address for GPIO node
Probably you want to mention in the description of the enum (here) that
the assigned values are explicit since this is basically a protocol between
FW and OS. That's why we may not change this values without breaking
older firmware descriptions.
> + */
> +enum cp2112_child_acpi_cell_addrs {
> + CP2112_I2C_ADR = 0,
> + CP2112_GPIO_ADR = 1,
> +};
...
> + if (is_acpi_device_node(dev_fwnode(&hdev->dev))) {
I'm wondering if we can avoid this (additional) check and use the result of one
of the branches.
> + device_for_each_child_node(&hdev->dev, child) {
If we are still use the above check it will be dev_fwnode() duplication call,
so perhaps a temporary variable to collect the device's fwnode and use it
there, below (see below), and here as for
fwnode_for_each_child_node()
> + ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> + if (ret)
> + continue;
> +
> + switch (addr) {
> + case CP2112_I2C_ADR:
> + device_set_node(&dev->adap.dev, child);
> + break;
> + case CP2112_GPIO_ADR:
> + dev->gc.fwnode = child;
> + break;
> + }
> + }
> + } else {
I would still check if this is a proper (OF) node, in case we stick with the
ACPI check above. Because we might have swnode and if it triggers, it will be
really something unexpected.
} else if (is_of_node(fwnode)) {
> + child = device_get_named_child_node(&hdev->dev, "i2c");
> + device_set_node(&dev->adap.dev, child);
> + fwnode_handle_put(child);
> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Andy Shevchenko @ 2026-01-27 21:00 UTC (permalink / raw)
To: Danny Kaehn
Cc: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires, Andi Shyti,
Conor Dooley, Jiri Kosina, devicetree, linux-input,
Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260127160217.GA3776731@LNDCL34533.neenah.na.plexus.com>
On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
> On Tue, Jan 27, 2026 at 08:47:48AM -0600, Danny Kaehn wrote:
> > This is a USB HID device which includes an I2C controller and 8 GPIO pins.
> >
> > The binding allows describing the chip's gpio and i2c controller in DT,
> > with the i2c controller being bound to a subnode named "i2c". This is
> > intended to be used in configurations where the CP2112 is permanently
> > connected in hardware.
> Hi Folks (Intended for Rob or Krzysztof),
>
> Wasn't sure the best way to go about this, but trying to see the best
> way to get a message in front of you regarding an ask from Andy S.
>
> In [1], Rob H initially directed that the gpio chip share a node with
> the CP2112 itself, rather than having a subnode named 'gpio'.
>
> Initially, I did the same thing for both DT and ACPI, but Andy S.
> directed that ACPI should not have the node be shared in that way.
>
> With the last revision of this patch, Andy S. asked that I try to get a
> rationalle from Rob (or other DT expert presumably) on why the gpio node
> should be combined with the parent, rather than being a named subnode
> [2].
>
> Any context you can provide would be extremely helpful. Apologies about
> the age of this patch series and the amount of historical context; some
> is due to my long delays between revisions, but other of it is due to
> attempting to get the ACPI and DT folks to talk / agree.
I think this is about markers such as "gpio-controller" or
"interrupt-controller" in DT for the device in question.
With that it might not be required to have a separate child
node for the GPIO function.
> [1]: https://lore.kernel.org/all/20240213152825.GA1223720-robh@kernel.org/
> [2]: https://lore.kernel.org/all/aSdvv3Qss5oz_o6P@smile.fi.intel.com/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] platform/x86: touchscreen_dmi: add DMI match for ARC 11.6 128GB HD
From: Rafał Żuchnik @ 2026-01-27 23:52 UTC (permalink / raw)
To: platform-driver-x86; +Cc: linux-input
This device is identical to Techbite Arc 11.6, but ships with a different
DMI_PRODUCT_NAME ("ARC 11.6 128GB HD").
Without this DMI match, the Silead touchscreen reports an incorrect coordinate
range, resulting in partial and wrapped touch input under Wayland.
Reuse the existing techbite_arc_11_6_data for this model.
Signed-off-by: Rafal Zuchnik <rafal.zuchnik@gmail.com>
---
diff --git a/drivers/platform/x86/touchscreen_dmi.c
b/drivers/platform/x86/touchscreen_dmi.c
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@
{
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "mPTech"),
DMI_MATCH(DMI_PRODUCT_NAME, "techBite Arc 11.6"),
DMI_MATCH(DMI_BOARD_NAME, "G8316_272B"),
},
.driver_data = (void *)&techbite_arc_11_6_data,
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "mPTech"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ARC 11.6 128GB HD"),
+ },
+ .driver_data = (void *)&techbite_arc_11_6_data,
+ },
};
^ permalink raw reply
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Krzysztof Kozlowski @ 2026-01-28 10:35 UTC (permalink / raw)
To: Danny Kaehn
Cc: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andy Shevchenko, Andi Shyti, Conor Dooley, Jiri Kosina,
devicetree, linux-input, Dmitry Torokhov, Bartosz Golaszewski,
Ethan Twardy, linux-i2c, linux-kernel, Leo Huang, Arun D Patil,
Willie Thai, Ting-Kai Chen
In-Reply-To: <20260127160217.GA3776731@LNDCL34533.neenah.na.plexus.com>
On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
> On Tue, Jan 27, 2026 at 08:47:48AM -0600, Danny Kaehn wrote:
> > This is a USB HID device which includes an I2C controller and 8 GPIO pins.
> >
> > The binding allows describing the chip's gpio and i2c controller in DT,
> > with the i2c controller being bound to a subnode named "i2c". This is
> > intended to be used in configurations where the CP2112 is permanently
> > connected in hardware.
> >
> > Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
> > ---
>
> Hi Folks (Intended for Rob or Krzysztof),
>
> Wasn't sure the best way to go about this, but trying to see the best
> way to get a message in front of you regarding an ask from Andy S.
>
> In [1], Rob H initially directed that the gpio chip share a node with
> the CP2112 itself, rather than having a subnode named 'gpio'.
>
> Initially, I did the same thing for both DT and ACPI, but Andy S.
> directed that ACPI should not have the node be shared in that way.
>
> With the last revision of this patch, Andy S. asked that I try to get a
> rationalle from Rob (or other DT expert presumably) on why the gpio node
> should be combined with the parent, rather than being a named subnode
> [2].
Because it is explicitly asked in writing bindings. Please read it.
Because we do not want Linux driver model affecting design of bindings
and DTS, by subnodes present only to instantiate Linux drivers. I do not
care about driver model in this review and I do not see any reason it
should make DTS less obvious or readable.
That's actually rule communicated many times, also documented in writing
bindings and in recent talks.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Andy Shevchenko @ 2026-01-28 12:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Danny Kaehn, Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andi Shyti, Conor Dooley, Jiri Kosina, devicetree, linux-input,
Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260128-magnificent-faithful-otter-c4f900@quoll>
On Wed, Jan 28, 2026 at 11:35:25AM +0100, Krzysztof Kozlowski wrote:
> On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
> > On Tue, Jan 27, 2026 at 08:47:48AM -0600, Danny Kaehn wrote:
> > > This is a USB HID device which includes an I2C controller and 8 GPIO pins.
> > >
> > > The binding allows describing the chip's gpio and i2c controller in DT,
> > > with the i2c controller being bound to a subnode named "i2c". This is
> > > intended to be used in configurations where the CP2112 is permanently
> > > connected in hardware.
> > >
> > > Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
> > > ---
> >
> > Hi Folks (Intended for Rob or Krzysztof),
> >
> > Wasn't sure the best way to go about this, but trying to see the best
> > way to get a message in front of you regarding an ask from Andy S.
> >
> > In [1], Rob H initially directed that the gpio chip share a node with
> > the CP2112 itself, rather than having a subnode named 'gpio'.
> >
> > Initially, I did the same thing for both DT and ACPI, but Andy S.
> > directed that ACPI should not have the node be shared in that way.
> >
> > With the last revision of this patch, Andy S. asked that I try to get a
> > rationalle from Rob (or other DT expert presumably) on why the gpio node
> > should be combined with the parent, rather than being a named subnode
> > [2].
>
> Because it is explicitly asked in writing bindings. Please read it.
>
> Because we do not want Linux driver model affecting design of bindings
> and DTS, by subnodes present only to instantiate Linux drivers. I do not
> care about driver model in this review and I do not see any reason it
> should make DTS less obvious or readable.
>
> That's actually rule communicated many times, also documented in writing
> bindings and in recent talks.
Does DT represents HW in this case? Shouldn't I²C controller be the same node?
Why not? This is inconsistent for the device that is multi-functional. And from
my understanding the firmware description (DT, ACPI, you-name-it) must follow
the HW. I don't see how it's done in this case.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] linux/interrupt.h: allow "guard" notation to disable and reenable IRQ with valid IRQ check
From: Marek Vasut @ 2026-01-28 12:23 UTC (permalink / raw)
To: Thomas Gleixner, linux-input
Cc: Peter Zijlstra (Intel), Cheng-Yang Chou, Dmitry Torokhov,
Frank Li, Geert Uytterhoeven, Jinjie Ruan, Krzysztof Kozlowski,
Marc Zyngier, Sebastian Andrzej Siewior, linux-kernel,
linux-renesas-soc
In-Reply-To: <87sebrbenj.ffs@tglx>
On 1/27/26 10:14 AM, Thomas Gleixner wrote:
> On Thu, Jan 22 2026 at 00:23, Marek Vasut wrote:
>
> $Subject: linux/interrupt.h is not a proper prefix. Just use 'genirq:'
>
> Also what means 'allow ....'? Subject lines should provide a concise
> summary of the change, i.e. something like:
>
> Provide conditional disable_irq guard variant
I did admittedly replicate the subject and tags from prior commit
c76494768761 ("linux/interrupt.h: allow "guard" notation to disable and
reenable IRQ")
Fixed, thanks.
>> Introduce disable_valid_irq scoped guard. This is an extension
>> of disable_irq scoped guard, which disables and enables IRQs
>> around a scope. The disable_valid_irq scoped guard does almost
>> the same, except it handles the case where IRQ is not valid,
>> in which case it does not do anything. This is meant to be used
>> by for example touch controller drivers, which can do both IRQ
>> driven and polling mode of operation, and this makes their code
>> slighly simpler.
>
> How many of those have this pattern? From a cursory look I found not
> even one as your example is neither applicable to upstream nor to next.
One. I think I have two-ish more candidates for conversion.
>> +static inline void disable_valid_irq(unsigned int irq)
>> +{
>> + if (irq > 0)
>> + disable_irq(irq);
>> +}
>> +
>> +static inline void enable_valid_irq(unsigned int irq)
>> +{
>> + if (irq > 0)
>> + enable_irq(irq);
>> +}
>> +
>> +DEFINE_LOCK_GUARD_1(disable_valid_irq, int,
>
> 'int' because it matches the function argument type of the inlines,
> right?
>
>> + disable_valid_irq(*_T->lock), enable_valid_irq(*_T->lock))
>
> disable_valid_irq is a pretty non-intuitive name if you look at it just
> by reading a usage site. It's not really improving the readability of
> the code, it's in fact obscuring it as the reader has to actually look
> up what the hell this means and then stumble upon a completely
> undocumented lock guard define.
>
> I'm all for using guards, but using guards just for the sake of using
> guards is not a really good approach.
I wouldn't even be opposed to converting the ili2xxx driver (the piece
of code in patch 2/2 of this series) back to simple enable/disable_irq()
. I am not particularly on board even with the disable_irq lock guard,
or more specifically, lock guard used for non-lock things like this.
^ permalink raw reply
* Re: [PATCH 1/2] linux/interrupt.h: allow "guard" notation to disable and reenable IRQ with valid IRQ check
From: Thomas Gleixner @ 2026-01-28 13:49 UTC (permalink / raw)
To: Marek Vasut, linux-input
Cc: Peter Zijlstra (Intel), Cheng-Yang Chou, Dmitry Torokhov,
Frank Li, Geert Uytterhoeven, Jinjie Ruan, Krzysztof Kozlowski,
Marc Zyngier, Sebastian Andrzej Siewior, linux-kernel,
linux-renesas-soc
In-Reply-To: <701e739d-2e82-40e7-87b5-b4ec92903af6@mailbox.org>
On Wed, Jan 28 2026 at 13:23, Marek Vasut wrote:
> On 1/27/26 10:14 AM, Thomas Gleixner wrote:
>> disable_valid_irq is a pretty non-intuitive name if you look at it just
>> by reading a usage site. It's not really improving the readability of
>> the code, it's in fact obscuring it as the reader has to actually look
>> up what the hell this means and then stumble upon a completely
>> undocumented lock guard define.
>>
>> I'm all for using guards, but using guards just for the sake of using
>> guards is not a really good approach.
> I wouldn't even be opposed to converting the ili2xxx driver (the piece
> of code in patch 2/2 of this series) back to simple enable/disable_irq()
> . I am not particularly on board even with the disable_irq lock guard,
> or more specifically, lock guard used for non-lock things like this.
I agree that guard() is a slight misnomer for such usage, but this is
about scoped auto cleanups, so using it this way makes a lot of sense
when the scope mechanism is sensible.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 1/2] linux/interrupt.h: allow "guard" notation to disable and reenable IRQ with valid IRQ check
From: Marek Vasut @ 2026-01-28 14:33 UTC (permalink / raw)
To: Thomas Gleixner, linux-input
Cc: Peter Zijlstra (Intel), Cheng-Yang Chou, Dmitry Torokhov,
Frank Li, Geert Uytterhoeven, Jinjie Ruan, Krzysztof Kozlowski,
Marc Zyngier, Sebastian Andrzej Siewior, linux-kernel,
linux-renesas-soc
In-Reply-To: <871pj9alui.ffs@tglx>
On 1/28/26 2:49 PM, Thomas Gleixner wrote:
> On Wed, Jan 28 2026 at 13:23, Marek Vasut wrote:
>> On 1/27/26 10:14 AM, Thomas Gleixner wrote:
>>> disable_valid_irq is a pretty non-intuitive name if you look at it just
>>> by reading a usage site. It's not really improving the readability of
>>> the code, it's in fact obscuring it as the reader has to actually look
>>> up what the hell this means and then stumble upon a completely
>>> undocumented lock guard define.
>>>
>>> I'm all for using guards, but using guards just for the sake of using
>>> guards is not a really good approach.
>> I wouldn't even be opposed to converting the ili2xxx driver (the piece
>> of code in patch 2/2 of this series) back to simple enable/disable_irq()
>> . I am not particularly on board even with the disable_irq lock guard,
>> or more specifically, lock guard used for non-lock things like this.
>
> I agree that guard() is a slight misnomer for such usage, but this is
> about scoped auto cleanups, so using it this way makes a lot of sense
> when the scope mechanism is sensible.
It is indeed a misnomer.
Would you prefer this patch be updated with some better function name,
or dropped outright until there are surely more users of this
functionality ?
Thank you for your help!
^ permalink raw reply
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Conor Dooley @ 2026-01-28 15:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Krzysztof Kozlowski, Danny Kaehn, Rob Herring,
Krzysztof Kozlowski, Benjamin Tissoires, Andi Shyti, Conor Dooley,
Jiri Kosina, devicetree, linux-input, Dmitry Torokhov,
Bartosz Golaszewski, Ethan Twardy, linux-i2c, linux-kernel,
Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <aXoF4zi4SZrXaku5@smile.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]
On Wed, Jan 28, 2026 at 02:49:39PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 28, 2026 at 11:35:25AM +0100, Krzysztof Kozlowski wrote:
> > On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
> > > On Tue, Jan 27, 2026 at 08:47:48AM -0600, Danny Kaehn wrote:
> > > > This is a USB HID device which includes an I2C controller and 8 GPIO pins.
> > > >
> > > > The binding allows describing the chip's gpio and i2c controller in DT,
> > > > with the i2c controller being bound to a subnode named "i2c". This is
> > > > intended to be used in configurations where the CP2112 is permanently
> > > > connected in hardware.
> > > >
> > > > Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
> > > > ---
> > >
> > > Hi Folks (Intended for Rob or Krzysztof),
> > >
> > > Wasn't sure the best way to go about this, but trying to see the best
> > > way to get a message in front of you regarding an ask from Andy S.
> > >
> > > In [1], Rob H initially directed that the gpio chip share a node with
> > > the CP2112 itself, rather than having a subnode named 'gpio'.
> > >
> > > Initially, I did the same thing for both DT and ACPI, but Andy S.
> > > directed that ACPI should not have the node be shared in that way.
> > >
> > > With the last revision of this patch, Andy S. asked that I try to get a
> > > rationalle from Rob (or other DT expert presumably) on why the gpio node
> > > should be combined with the parent, rather than being a named subnode
> > > [2].
> >
> > Because it is explicitly asked in writing bindings. Please read it.
> >
> > Because we do not want Linux driver model affecting design of bindings
> > and DTS, by subnodes present only to instantiate Linux drivers. I do not
> > care about driver model in this review and I do not see any reason it
> > should make DTS less obvious or readable.
> >
> > That's actually rule communicated many times, also documented in writing
> > bindings and in recent talks.
>
> Does DT represents HW in this case? Shouldn't I²C controller be the same node?
> Why not? This is inconsistent for the device that is multi-functional. And from
> my understanding the firmware description (DT, ACPI, you-name-it) must follow
> the HW. I don't see how it's done in this case.
The i2c controller should probably be in the same node too, unless it
would cause conflicts between function (e.g. inability to figure out if
a child is a hog or a i2c device). I would like a rationale provided for
why the i2c controller is in a subnode.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Krzysztof Kozlowski @ 2026-01-28 15:48 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Danny Kaehn, Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andi Shyti, Conor Dooley, Jiri Kosina, devicetree, linux-input,
Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <aXoF4zi4SZrXaku5@smile.fi.intel.com>
On 28/01/2026 13:49, Andy Shevchenko wrote:
> On Wed, Jan 28, 2026 at 11:35:25AM +0100, Krzysztof Kozlowski wrote:
>> On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
>>> On Tue, Jan 27, 2026 at 08:47:48AM -0600, Danny Kaehn wrote:
>>>> This is a USB HID device which includes an I2C controller and 8 GPIO pins.
>>>>
>>>> The binding allows describing the chip's gpio and i2c controller in DT,
>>>> with the i2c controller being bound to a subnode named "i2c". This is
>>>> intended to be used in configurations where the CP2112 is permanently
>>>> connected in hardware.
>>>>
>>>> Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
>>>> ---
>>>
>>> Hi Folks (Intended for Rob or Krzysztof),
>>>
>>> Wasn't sure the best way to go about this, but trying to see the best
>>> way to get a message in front of you regarding an ask from Andy S.
>>>
>>> In [1], Rob H initially directed that the gpio chip share a node with
>>> the CP2112 itself, rather than having a subnode named 'gpio'.
>>>
>>> Initially, I did the same thing for both DT and ACPI, but Andy S.
>>> directed that ACPI should not have the node be shared in that way.
>>>
>>> With the last revision of this patch, Andy S. asked that I try to get a
>>> rationalle from Rob (or other DT expert presumably) on why the gpio node
>>> should be combined with the parent, rather than being a named subnode
>>> [2].
>>
>> Because it is explicitly asked in writing bindings. Please read it.
>>
>> Because we do not want Linux driver model affecting design of bindings
>> and DTS, by subnodes present only to instantiate Linux drivers. I do not
>> care about driver model in this review and I do not see any reason it
>> should make DTS less obvious or readable.
>>
>> That's actually rule communicated many times, also documented in writing
>> bindings and in recent talks.
>
> Does DT represents HW in this case? Shouldn't I²C controller be the same node?
> Why not? This is inconsistent for the device that is multi-functional. And from
> my understanding the firmware description (DT, ACPI, you-name-it) must follow
> the HW. I don't see how it's done in this case.
What is inconsistent exactly? What sort of rule tells that every little
function needs a device node? It's first time I hear about any of such
rule and for all this time we already NAKed it so many times (node per
GPIO, node per clock, node per every little pin).
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Andy Shevchenko @ 2026-01-28 15:51 UTC (permalink / raw)
To: Conor Dooley
Cc: Krzysztof Kozlowski, Danny Kaehn, Rob Herring,
Krzysztof Kozlowski, Benjamin Tissoires, Andi Shyti, Conor Dooley,
Jiri Kosina, devicetree, linux-input, Dmitry Torokhov,
Bartosz Golaszewski, Ethan Twardy, linux-i2c, linux-kernel,
Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260128-pelican-silenced-cd6a5bf69672@spud>
On Wed, Jan 28, 2026 at 03:06:58PM +0000, Conor Dooley wrote:
> On Wed, Jan 28, 2026 at 02:49:39PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 28, 2026 at 11:35:25AM +0100, Krzysztof Kozlowski wrote:
> > > On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
...
> > > That's actually rule communicated many times, also documented in writing
> > > bindings and in recent talks.
> >
> > Does DT represents HW in this case? Shouldn't I²C controller be the same node?
> > Why not? This is inconsistent for the device that is multi-functional. And from
> > my understanding the firmware description (DT, ACPI, you-name-it) must follow
> > the HW. I don't see how it's done in this case.
>
> The i2c controller should probably be in the same node too, unless it
> would cause conflicts between function (e.g. inability to figure out if
> a child is a hog or a i2c device). I would like a rationale provided for
> why the i2c controller is in a subnode.
I can expect a disaster with such a scheme, splitting multi-functional device
to the subdevices (children) sounds to me like the best approach. With this,
one may have the same (globally named) property to be different on subdevices.
But I will hold my breath to see the outcome of this discussion.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 0/3] Add support for Awinic AW86938 haptic driver
From: Griffin Kroah-Hartman @ 2026-01-28 15:51 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Luca Weiss
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
Griffin Kroah-Hartman
Add devicetree bindings and a driver for the AW86938 haptic driver chip,
and add it to the devicetree for the Fairphone 6 smartphone.
This driver is very similar to the AW86927, and shares many core
features.
Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
---
Changes in v2:
- Added AW86938 specific registers
- Added chip model enum to differentiate chips
- Link to v1: https://lore.kernel.org/r/20251204-aw86938-driver-v1-0-ebd71868df3a@fairphone.com
---
Griffin Kroah-Hartman (3):
dt-bindings: input: awinic,aw86927: Add Awinic AW86938
Input: aw86938 - add driver for Awinic AW86938
arm64: dts: qcom: milos-fairphone-fp6: Add vibrator support
.../devicetree/bindings/input/awinic,aw86927.yaml | 4 +-
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 19 ++++++-
drivers/input/misc/aw86927.c | 65 ++++++++++++++++++----
3 files changed, 74 insertions(+), 14 deletions(-)
---
base-commit: 0364de6be161e2360cbb1f26d5aff5b343ef7bb0
change-id: 20251113-aw86938-driver-b4fa0d3228a2
Best regards,
--
Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: input: awinic,aw86927: Add Awinic AW86938
From: Griffin Kroah-Hartman @ 2026-01-28 15:51 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Luca Weiss
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
Griffin Kroah-Hartman
In-Reply-To: <20260128-aw86938-driver-v2-0-b51ee086aaf5@fairphone.com>
Add bindings for the Awinic AW86938 haptic chip which can be found in
smartphones. These two chips require a similar devicetree configuration,
but have a register layout that's not 100% compatible.
Still, we can document them in the same file.
Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
---
Documentation/devicetree/bindings/input/awinic,aw86927.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/awinic,aw86927.yaml b/Documentation/devicetree/bindings/input/awinic,aw86927.yaml
index b7252916bd727486c1a98913d4ec3ef12422e4bd..c3dee660422192720da3cf63851cea27db819742 100644
--- a/Documentation/devicetree/bindings/input/awinic,aw86927.yaml
+++ b/Documentation/devicetree/bindings/input/awinic,aw86927.yaml
@@ -11,7 +11,9 @@ maintainers:
properties:
compatible:
- const: awinic,aw86927
+ enum:
+ - awinic,aw86927
+ - awinic,aw86938
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] Input: aw86938 - add driver for Awinic AW86938
From: Griffin Kroah-Hartman @ 2026-01-28 15:51 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Luca Weiss
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
Griffin Kroah-Hartman
In-Reply-To: <20260128-aw86938-driver-v2-0-b51ee086aaf5@fairphone.com>
Add support for the I2C-connected Awinic AW86938 LRA haptic driver.
The AW86938 has a similar but slightly different register layout. In
particular, the boost mode register values.
The AW86938 also has some extra features that aren't implemented
in this driver yet.
Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
---
drivers/input/misc/aw86927.c | 65 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 53 insertions(+), 12 deletions(-)
diff --git a/drivers/input/misc/aw86927.c b/drivers/input/misc/aw86927.c
index 8ad361239cfe3a888628b15e4dbdeed0c9ca3d1a..28ec6e42fd452a0edf1e1b9a9614e2723c6d9f93 100644
--- a/drivers/input/misc/aw86927.c
+++ b/drivers/input/misc/aw86927.c
@@ -43,6 +43,12 @@
#define AW86927_PLAYCFG1_BST_VOUT_VREFSET_MASK GENMASK(6, 0)
#define AW86927_PLAYCFG1_BST_8500MV 0x50
+#define AW86938_PLAYCFG1_REG 0x06
+#define AW86938_PLAYCFG1_BST_MODE_MASK GENMASK(5, 5)
+#define AW86938_PLAYCFG1_BST_MODE_BYPASS 0
+#define AW86938_PLAYCFG1_BST_VOUT_VREFSET_MASK GENMASK(4, 0)
+#define AW86938_PLAYCFG1_BST_7000MV 0x11
+
#define AW86927_PLAYCFG2_REG 0x07
#define AW86927_PLAYCFG3_REG 0x08
@@ -140,6 +146,7 @@
#define AW86927_CHIPIDH_REG 0x57
#define AW86927_CHIPIDL_REG 0x58
#define AW86927_CHIPID 0x9270
+#define AW86938_CHIPID 0x9380
#define AW86927_TMCFG_REG 0x5b
#define AW86927_TMCFG_UNLOCK 0x7d
@@ -173,7 +180,13 @@ enum aw86927_work_mode {
AW86927_RAM_MODE,
};
+enum aw86927_model {
+ AW86927,
+ AW86938,
+};
+
struct aw86927_data {
+ enum aw86927_model model;
struct work_struct play_work;
struct device *dev;
struct input_dev *input_dev;
@@ -377,7 +390,7 @@ static int aw86927_play_sine(struct aw86927_data *haptics)
return err;
/* set gain to value lower than 0x80 to avoid distorted playback */
- err = regmap_write(haptics->regmap, AW86927_PLAYCFG2_REG, 0x7c);
+ err = regmap_write(haptics->regmap, AW86927_PLAYCFG2_REG, 0x45);
if (err)
return err;
@@ -565,13 +578,26 @@ static int aw86927_haptic_init(struct aw86927_data *haptics)
if (err)
return err;
- err = regmap_update_bits(haptics->regmap,
- AW86927_PLAYCFG1_REG,
- AW86927_PLAYCFG1_BST_VOUT_VREFSET_MASK,
- FIELD_PREP(AW86927_PLAYCFG1_BST_VOUT_VREFSET_MASK,
- AW86927_PLAYCFG1_BST_8500MV));
- if (err)
- return err;
+ switch (haptics->model) {
+ case AW86927:
+ err = regmap_update_bits(haptics->regmap,
+ AW86927_PLAYCFG1_REG,
+ AW86927_PLAYCFG1_BST_VOUT_VREFSET_MASK,
+ FIELD_PREP(AW86927_PLAYCFG1_BST_VOUT_VREFSET_MASK,
+ AW86927_PLAYCFG1_BST_8500MV));
+ if (err)
+ return err;
+ break;
+ case AW86938:
+ err = regmap_update_bits(haptics->regmap,
+ AW86938_PLAYCFG1_REG,
+ AW86938_PLAYCFG1_BST_VOUT_VREFSET_MASK,
+ FIELD_PREP(AW86938_PLAYCFG1_BST_VOUT_VREFSET_MASK,
+ AW86938_PLAYCFG1_BST_7000MV));
+ if (err)
+ return err;
+ break;
+ }
err = regmap_update_bits(haptics->regmap,
AW86927_PLAYCFG3_REG,
@@ -599,6 +625,9 @@ static int aw86927_ram_init(struct aw86927_data *haptics)
FIELD_PREP(AW86927_SYSCTRL3_EN_RAMINIT_MASK,
AW86927_SYSCTRL3_EN_RAMINIT_ON));
+ /* AW86938 wants a 1ms delay here */
+ usleep_range(1000, 1500);
+
/* Set base address for the start of the SRAM waveforms */
err = regmap_write(haptics->regmap,
AW86927_BASEADDRH_REG, AW86927_BASEADDRH_VAL);
@@ -717,9 +746,19 @@ static int aw86927_detect(struct aw86927_data *haptics)
chip_id = be16_to_cpu(read_buf);
- if (chip_id != AW86927_CHIPID) {
- dev_err(haptics->dev, "Unexpected CHIPID value 0x%x\n", chip_id);
- return -ENODEV;
+ switch (haptics->model) {
+ case AW86927:
+ if (chip_id != AW86927_CHIPID) {
+ dev_err(haptics->dev, "Unexpected CHIPID value 0x%x\n", chip_id);
+ return -ENODEV;
+ }
+ break;
+ case AW86938:
+ if (chip_id != AW86938_CHIPID) {
+ dev_err(haptics->dev, "Unexpected CHIPID value 0x%x\n", chip_id);
+ return -ENODEV;
+ }
+ break;
}
return 0;
@@ -736,6 +775,7 @@ static int aw86927_probe(struct i2c_client *client)
haptics->dev = &client->dev;
haptics->client = client;
+ haptics->model = (enum aw86927_model)device_get_match_data(&client->dev);
i2c_set_clientdata(client, haptics);
@@ -825,7 +865,8 @@ static int aw86927_probe(struct i2c_client *client)
}
static const struct of_device_id aw86927_of_id[] = {
- { .compatible = "awinic,aw86927" },
+ { .compatible = "awinic,aw86927", .data = (void *)AW86927 },
+ { .compatible = "awinic,aw86938", .data = (void *)AW86938 },
{ /* sentinel */ }
};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: qcom: milos-fairphone-fp6: Add vibrator support
From: Griffin Kroah-Hartman @ 2026-01-28 15:51 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Luca Weiss
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
Griffin Kroah-Hartman
In-Reply-To: <20260128-aw86938-driver-v2-0-b51ee086aaf5@fairphone.com>
Add the required node for haptic playback (Awinic AW86938)
Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
index 52895dd9e4fa117aef6822df230ebf644e5f02ba..881239d22fa97685206d1fa3a70723c5b77a339c 100644
--- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
+++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
@@ -625,7 +625,17 @@ vreg_l7p: ldo7 {
};
/* VL53L3 ToF @ 0x29 */
- /* AW86938FCR vibrator @ 0x5a */
+
+ vibrator@5a {
+ compatible = "awinic,aw86938";
+ reg = <0x5a>;
+
+ interrupts-extended = <&tlmm 80 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&tlmm 78 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&aw86938_int_default>;
+ pinctrl-names = "default";
+ };
};
&pm8550vs_c {
@@ -755,6 +765,13 @@ sdc2_card_det_n: sdc2-card-det-state {
bias-pull-up;
};
+ aw86938_int_default: aw86938-int-default-state {
+ pins = "gpio80";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
pm8008_int_default: pm8008-int-default-state {
pins = "gpio125";
function = "gpio";
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Krzysztof Kozlowski @ 2026-01-28 15:52 UTC (permalink / raw)
To: Conor Dooley, Andy Shevchenko
Cc: Danny Kaehn, Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andi Shyti, Conor Dooley, Jiri Kosina, devicetree, linux-input,
Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260128-pelican-silenced-cd6a5bf69672@spud>
On 28/01/2026 16:06, Conor Dooley wrote:
> On Wed, Jan 28, 2026 at 02:49:39PM +0200, Andy Shevchenko wrote:
>> On Wed, Jan 28, 2026 at 11:35:25AM +0100, Krzysztof Kozlowski wrote:
>>> On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
>>>> On Tue, Jan 27, 2026 at 08:47:48AM -0600, Danny Kaehn wrote:
>>>>> This is a USB HID device which includes an I2C controller and 8 GPIO pins.
>>>>>
>>>>> The binding allows describing the chip's gpio and i2c controller in DT,
>>>>> with the i2c controller being bound to a subnode named "i2c". This is
>>>>> intended to be used in configurations where the CP2112 is permanently
>>>>> connected in hardware.
>>>>>
>>>>> Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
>>>>> ---
>>>>
>>>> Hi Folks (Intended for Rob or Krzysztof),
>>>>
>>>> Wasn't sure the best way to go about this, but trying to see the best
>>>> way to get a message in front of you regarding an ask from Andy S.
>>>>
>>>> In [1], Rob H initially directed that the gpio chip share a node with
>>>> the CP2112 itself, rather than having a subnode named 'gpio'.
>>>>
>>>> Initially, I did the same thing for both DT and ACPI, but Andy S.
>>>> directed that ACPI should not have the node be shared in that way.
>>>>
>>>> With the last revision of this patch, Andy S. asked that I try to get a
>>>> rationalle from Rob (or other DT expert presumably) on why the gpio node
>>>> should be combined with the parent, rather than being a named subnode
>>>> [2].
>>>
>>> Because it is explicitly asked in writing bindings. Please read it.
>>>
>>> Because we do not want Linux driver model affecting design of bindings
>>> and DTS, by subnodes present only to instantiate Linux drivers. I do not
>>> care about driver model in this review and I do not see any reason it
>>> should make DTS less obvious or readable.
>>>
>>> That's actually rule communicated many times, also documented in writing
>>> bindings and in recent talks.
>>
>> Does DT represents HW in this case? Shouldn't I²C controller be the same node?
>> Why not? This is inconsistent for the device that is multi-functional. And from
>> my understanding the firmware description (DT, ACPI, you-name-it) must follow
>> the HW. I don't see how it's done in this case.
>
> The i2c controller should probably be in the same node too, unless it
> would cause conflicts between function (e.g. inability to figure out if
This one is the rationale.
> a child is a hog or a i2c device). I would like a rationale provided for
> why the i2c controller is in a subnode.
I2C controller will have children, because it is a bus, so moving it up
one level would make the entire node I2C bus and that's not only problem
for the kernel but actually for reading DT - we expect consistent choice
for children, instead of mixing nodes with and without bus-addressing.
What's more, if you have two buses you also need separate nodes to group
them (obviously).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Krzysztof Kozlowski @ 2026-01-28 15:52 UTC (permalink / raw)
To: Andy Shevchenko, Conor Dooley
Cc: Danny Kaehn, Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andi Shyti, Conor Dooley, Jiri Kosina, devicetree, linux-input,
Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <aXowcdIpdZwrc5KW@smile.fi.intel.com>
On 28/01/2026 16:51, Andy Shevchenko wrote:
> On Wed, Jan 28, 2026 at 03:06:58PM +0000, Conor Dooley wrote:
>> On Wed, Jan 28, 2026 at 02:49:39PM +0200, Andy Shevchenko wrote:
>>> On Wed, Jan 28, 2026 at 11:35:25AM +0100, Krzysztof Kozlowski wrote:
>>>> On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
>
> ...
>
>>>> That's actually rule communicated many times, also documented in writing
>>>> bindings and in recent talks.
>>>
>>> Does DT represents HW in this case? Shouldn't I²C controller be the same node?
>>> Why not? This is inconsistent for the device that is multi-functional. And from
>>> my understanding the firmware description (DT, ACPI, you-name-it) must follow
>>> the HW. I don't see how it's done in this case.
>>
>> The i2c controller should probably be in the same node too, unless it
>> would cause conflicts between function (e.g. inability to figure out if
>> a child is a hog or a i2c device). I would like a rationale provided for
>> why the i2c controller is in a subnode.
>
> I can expect a disaster with such a scheme, splitting multi-functional device
So for some years no disaster happened, at least nothing was reported to us.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Andy Shevchenko @ 2026-01-28 16:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Danny Kaehn, Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andi Shyti, Conor Dooley, Jiri Kosina, devicetree, linux-input,
Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <3db84b61-e463-4362-b142-59d3ca6eae90@kernel.org>
On Wed, Jan 28, 2026 at 04:48:18PM +0100, Krzysztof Kozlowski wrote:
> On 28/01/2026 13:49, Andy Shevchenko wrote:
> > On Wed, Jan 28, 2026 at 11:35:25AM +0100, Krzysztof Kozlowski wrote:
> >> On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
...
> >> That's actually rule communicated many times, also documented in writing
> >> bindings and in recent talks.
> >
> > Does DT represents HW in this case? Shouldn't I²C controller be the same node?
> > Why not? This is inconsistent for the device that is multi-functional. And from
> > my understanding the firmware description (DT, ACPI, you-name-it) must follow
> > the HW. I don't see how it's done in this case.
>
> What is inconsistent exactly? What sort of rule tells that every little
> function needs a device node? It's first time I hear about any of such
> rule and for all this time we already NAKed it so many times (node per
> GPIO, node per clock, node per every little pin).
That we should represent the HW as is. There is no "rule", there is a common
sense. Of course, it's possible to have all-in-one node, but this may lead
to a disaster when there are tons of devices in the Multi Functional HW
and some of them use the same properties. How would you distinguish HW
with two GPIO banks, two I²C controllers, et cetera? That's what my common
sense tells to me, putting all eggs into one bucket is just a mine field
for the future.
--
With Best Regards,
Andy Shevchenko
^ 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