* Re: [PATCH v3 0/3] Radxa NIO 12L: Add GPIO keys and LED support
From: Rob Herring (Arm) @ 2025-09-05 17:45 UTC (permalink / raw)
To: Julien Massot
Cc: Louis-Alexis Eyraud, kernel, linux-mediatek,
AngeloGioacchino Del Regno, linux-kernel, linux-input,
Matthias Brugger, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, Dmitry Torokhov, devicetree
In-Reply-To: <20250905-radxa-nio-12-l-gpio-v3-0-40f11377fb55@collabora.com>
On Fri, 05 Sep 2025 13:51:57 +0200, Julien Massot wrote:
> This patchset adds support for the GPIO-connected red and blue LEDs,
> as well as the various hardware buttons present on the Radxa NIO 12L
> board.
>
> It also includes a fix for the missing release (key-up) interrupt
> handling for PMIC-managed GPIO keys.
>
> Signed-off-by: Julien Massot <julien.massot@collabora.com>
> ---
> Changes in v3:
> Patch 3/3: drop the deprecated LEDs label property
> - Link to v2: https://lore.kernel.org/r/20250826-radxa-nio-12-l-gpio-v2-0-7f18fa3fbfc8@collabora.com
>
> Changes in v2:
> PATCH 1/3
> - Add Fixes tag
> - Drop Angelo's Reviewed-By since I'm now introducing the
> 'key_release_irq' member that was missing in v1.
> - Link to v1: https://lore.kernel.org/r/20250801-radxa-nio-12-l-gpio-v1-0-d0840f85d2c8@collabora.com
>
> ---
> Julien Massot (3):
> Input: mtk-pmic-keys - MT6359 has a specific release irq
> arm64: dts: mediatek: mt8395-nio-12l: add PMIC and GPIO keys support
> arm64: dts: mediatek: mt8395-nio-12l: add support for blue and red LEDs
>
> .../boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 65 ++++++++++++++++++++++
> drivers/input/keyboard/mtk-pmic-keys.c | 5 +-
> 2 files changed, 69 insertions(+), 1 deletion(-)
> ---
> base-commit: 6c68f4c0a147c025ae0b25fab688c7c47964a02f
> change-id: 20250801-radxa-nio-12-l-gpio-54f208c25333
>
> Best regards,
> --
> Julien Massot <julien.massot@collabora.com>
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
This patch series was applied (using b4) to base:
Base: using specified base-commit 6c68f4c0a147c025ae0b25fab688c7c47964a02f
If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)
New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/mediatek/' for 20250905-radxa-nio-12-l-gpio-v3-0-40f11377fb55@collabora.com:
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dtb: gpio-leds (gpio-leds): 'rgb-blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/leds/leds-gpio.yaml#
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: mediatek: mt8395-nio-12l: add support for blue and red LEDs
From: Julien Massot @ 2025-09-05 11:52 UTC (permalink / raw)
To: kernel, Dmitry Torokhov, Matthias Brugger,
AngeloGioacchino Del Regno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Louis-Alexis Eyraud
Cc: linux-input, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Julien Massot
In-Reply-To: <20250905-radxa-nio-12-l-gpio-v3-0-40f11377fb55@collabora.com>
The Radxa NIO 12L board has an RGB LED, of which only red and blue
are controllable.
Red and blue LEDs: no need to choose, both are enabled.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Julien Massot <julien.massot@collabora.com>
---
.../boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index fd596e2298285361ad7c2fb828feec598d75a73e..0ea36e7c960fc0b2607833d743c5e2e806864600 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -10,6 +10,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/mt8195-pinfunc.h>
#include <dt-bindings/regulator/mediatek,mt6360-regulator.h>
#include <dt-bindings/spmi/spmi.h>
@@ -73,6 +74,26 @@ button-volume-up {
};
};
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&gpio_leds_pins>;
+ pinctrl-names = "default";
+
+ /*
+ * This board has a RGB LED, of which only R and B
+ * are controllable.
+ */
+ rgb-blue {
+ color = <LED_COLOR_ID_BLUE>;
+ gpios = <&pio 6 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_RED>;
+ gpios = <&pio 7 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
wifi_vreg: regulator-wifi-3v3-en {
compatible = "regulator-fixed";
regulator-name = "wifi_3v3_en";
@@ -647,6 +668,14 @@ pins {
};
};
+ gpio_leds_pins: gpio-leds-pins {
+ pins {
+ pinmux = <PINMUX_GPIO6__FUNC_GPIO6>,
+ <PINMUX_GPIO7__FUNC_GPIO7>;
+ output-low;
+ };
+ };
+
i2c2_pins: i2c2-pins {
pins-bus {
pinmux = <PINMUX_GPIO12__FUNC_SDA2>,
--
2.51.0
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: mediatek: mt8395-nio-12l: add PMIC and GPIO keys support
From: Julien Massot @ 2025-09-05 11:51 UTC (permalink / raw)
To: kernel, Dmitry Torokhov, Matthias Brugger,
AngeloGioacchino Del Regno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Louis-Alexis Eyraud
Cc: linux-input, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Julien Massot
In-Reply-To: <20250905-radxa-nio-12-l-gpio-v3-0-40f11377fb55@collabora.com>
Add support for PMIC and GPIO keys on the Radxa NIO 12L board:
Declare a gpio-keys node for the Volume Up button using GPIO106.
Add the corresponding pin configuration in the pinctrl node.
Add a mediatek,mt6359-keys subnode under the PMIC to handle the
power and home buttons exposed by the MT6359.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Julien Massot <julien.massot@collabora.com>
---
.../boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 36 ++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index 329c60cc6a6be0b4be8c0b8bb033b32d35302804..fd596e2298285361ad7c2fb828feec598d75a73e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -8,6 +8,7 @@
#include "mt8195.dtsi"
#include "mt6359.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/pinctrl/mt8195-pinfunc.h>
#include <dt-bindings/regulator/mediatek,mt6360-regulator.h>
@@ -60,6 +61,18 @@ backlight: backlight {
status = "disabled";
};
+ keys: gpio-keys {
+ compatible = "gpio-keys";
+
+ button-volume-up {
+ wakeup-source;
+ debounce-interval = <100>;
+ gpios = <&pio 106 GPIO_ACTIVE_LOW>;
+ label = "volume_up";
+ linux,code = <KEY_VOLUMEUP>;
+ };
+ };
+
wifi_vreg: regulator-wifi-3v3-en {
compatible = "regulator-fixed";
regulator-name = "wifi_3v3_en";
@@ -626,6 +639,14 @@ pins-txd {
};
};
+ gpio_key_pins: gpio-keys-pins {
+ pins {
+ pinmux = <PINMUX_GPIO106__FUNC_GPIO106>;
+ bias-pull-up;
+ input-enable;
+ };
+ };
+
i2c2_pins: i2c2-pins {
pins-bus {
pinmux = <PINMUX_GPIO12__FUNC_SDA2>,
@@ -880,6 +901,21 @@ &pciephy {
&pmic {
interrupts-extended = <&pio 222 IRQ_TYPE_LEVEL_HIGH>;
+
+ mt6359keys: keys {
+ compatible = "mediatek,mt6359-keys";
+ mediatek,long-press-mode = <1>;
+ power-off-time-sec = <0>;
+
+ power-key {
+ linux,keycodes = <KEY_POWER>;
+ wakeup-source;
+ };
+
+ home {
+ linux,keycodes = <KEY_HOME>;
+ };
+ };
};
&scp {
--
2.51.0
^ permalink raw reply related
* [PATCH v3 1/3] Input: mtk-pmic-keys - MT6359 has a specific release irq
From: Julien Massot @ 2025-09-05 11:51 UTC (permalink / raw)
To: kernel, Dmitry Torokhov, Matthias Brugger,
AngeloGioacchino Del Regno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Louis-Alexis Eyraud
Cc: linux-input, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Julien Massot
In-Reply-To: <20250905-radxa-nio-12-l-gpio-v3-0-40f11377fb55@collabora.com>
Support for MT6359 PMIC keys has been added recently.
However, the key release event is not properly handled:
only key press events are generated, leaving key states
stuck in "pressed".
This patch ensures that both key press and key release events
are properly emitted by handling the release logic correctly.
Introduce a 'key_release_irq' member to the 'mtk_pmic_regs',
to identify the devices that have a separate irq for the
release event.
Fixes: bc25e6bf032e ("Input: mtk-pmic-keys - add support for MT6359 PMIC keys")
Signed-off-by: Julien Massot <julien.massot@collabora.com>
---
drivers/input/keyboard/mtk-pmic-keys.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
index 50e2e792c91d2626d3f282d04a1db60845827ef2..c78d9f6d97c4f7a77b4c44cee3b93e4712a19aec 100644
--- a/drivers/input/keyboard/mtk-pmic-keys.c
+++ b/drivers/input/keyboard/mtk-pmic-keys.c
@@ -55,6 +55,7 @@ struct mtk_pmic_regs {
const struct mtk_pmic_keys_regs keys_regs[MTK_PMIC_MAX_KEY_COUNT];
u32 pmic_rst_reg;
u32 rst_lprst_mask; /* Long-press reset timeout bitmask */
+ bool key_release_irq;
};
static const struct mtk_pmic_regs mt6397_regs = {
@@ -116,6 +117,7 @@ static const struct mtk_pmic_regs mt6358_regs = {
MTK_PMIC_HOMEKEY_RST),
.pmic_rst_reg = MT6358_TOP_RST_MISC,
.rst_lprst_mask = MTK_PMIC_RST_DU_MASK,
+ .key_release_irq = true,
};
static const struct mtk_pmic_regs mt6359_regs = {
@@ -129,6 +131,7 @@ static const struct mtk_pmic_regs mt6359_regs = {
MTK_PMIC_HOMEKEY_RST),
.pmic_rst_reg = MT6359_TOP_RST_MISC,
.rst_lprst_mask = MTK_PMIC_RST_DU_MASK,
+ .key_release_irq = true,
};
struct mtk_pmic_keys_info {
@@ -368,7 +371,7 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
if (keys->keys[index].irq < 0)
return keys->keys[index].irq;
- if (of_device_is_compatible(node, "mediatek,mt6358-keys")) {
+ if (mtk_pmic_regs->key_release_irq) {
keys->keys[index].irq_r = platform_get_irq_byname(pdev,
irqnames_r[index]);
--
2.51.0
^ permalink raw reply related
* [PATCH v3 0/3] Radxa NIO 12L: Add GPIO keys and LED support
From: Julien Massot @ 2025-09-05 11:51 UTC (permalink / raw)
To: kernel, Dmitry Torokhov, Matthias Brugger,
AngeloGioacchino Del Regno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Louis-Alexis Eyraud
Cc: linux-input, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Julien Massot
This patchset adds support for the GPIO-connected red and blue LEDs,
as well as the various hardware buttons present on the Radxa NIO 12L
board.
It also includes a fix for the missing release (key-up) interrupt
handling for PMIC-managed GPIO keys.
Signed-off-by: Julien Massot <julien.massot@collabora.com>
---
Changes in v3:
Patch 3/3: drop the deprecated LEDs label property
- Link to v2: https://lore.kernel.org/r/20250826-radxa-nio-12-l-gpio-v2-0-7f18fa3fbfc8@collabora.com
Changes in v2:
PATCH 1/3
- Add Fixes tag
- Drop Angelo's Reviewed-By since I'm now introducing the
'key_release_irq' member that was missing in v1.
- Link to v1: https://lore.kernel.org/r/20250801-radxa-nio-12-l-gpio-v1-0-d0840f85d2c8@collabora.com
---
Julien Massot (3):
Input: mtk-pmic-keys - MT6359 has a specific release irq
arm64: dts: mediatek: mt8395-nio-12l: add PMIC and GPIO keys support
arm64: dts: mediatek: mt8395-nio-12l: add support for blue and red LEDs
.../boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 65 ++++++++++++++++++++++
drivers/input/keyboard/mtk-pmic-keys.c | 5 +-
2 files changed, 69 insertions(+), 1 deletion(-)
---
base-commit: 6c68f4c0a147c025ae0b25fab688c7c47964a02f
change-id: 20250801-radxa-nio-12-l-gpio-54f208c25333
Best regards,
--
Julien Massot <julien.massot@collabora.com>
^ permalink raw reply
* Re: [PATCH v1 13/14] dt-bindings: input/touchscreen: Convert MELFAS MIP4 Touchscreen to YAML
From: Linus Walleij @ 2025-09-05 11:33 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, angelogioacchino.delregno, broonie, chunkuang.hu,
ck.hu, conor+dt, davem, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
louisalexis.eyraud, maarten.lankhorst, matthias.bgg, mchehab,
minghsiu.tsai, mripard, p.zabel, pabeni, robh, sean.wang, simona,
support.opensource, tiffany.lin, tzimmermann, yunfei.dong,
devicetree, dri-devel, linux-arm-kernel, linux-clk, linux-gpio,
linux-input, linux-kernel, linux-media, linux-mediatek,
linux-sound, netdev
In-Reply-To: <caguo7ud4dapb4yupeq2x4ocwoh4dt5nedwjsyuqsaratugcgz@ozajhsqwfzq6>
On Fri, Sep 5, 2025 at 12:02 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Aug 21, 2025 at 01:56:24PM +0200, Linus Walleij wrote:
> > Hi Ariel,
> >
> > thanks for your patch!
> >
> > On Wed, Aug 20, 2025 at 7:17 PM Ariel D'Alessandro
> > <ariel.dalessandro@collabora.com> wrote:
> >
> > > + ce-gpios:
> > > + description: GPIO connected to the CE (chip enable) pin of the chip
> > > + maxItems: 1
> >
> > Mention that this should always have the flag GPIO_ACTIVE_HIGH
> > as this is required by the hardware.
> >
> > Unfortunately we have no YAML syntax for enforcing flags :/
>
> Theoretically there can be an inverter on the line, so from the AP point
> of view the line is active low while from the peripheral POV the pin is
> active high...
Yes, I think someone even proposed adding inverters to the
device tree and was nixed.
It's a matter of phrasing I would say:
"Mention that this should nominally have the flag GPIO_ACTIVE_HIGH
as this is required by the hardware."
s/always/nominally/g
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 13/14] dt-bindings: input/touchscreen: Convert MELFAS MIP4 Touchscreen to YAML
From: Dmitry Torokhov @ 2025-09-05 10:02 UTC (permalink / raw)
To: Linus Walleij
Cc: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, angelogioacchino.delregno, broonie, chunkuang.hu,
ck.hu, conor+dt, davem, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
louisalexis.eyraud, maarten.lankhorst, matthias.bgg, mchehab,
minghsiu.tsai, mripard, p.zabel, pabeni, robh, sean.wang, simona,
support.opensource, tiffany.lin, tzimmermann, yunfei.dong,
devicetree, dri-devel, linux-arm-kernel, linux-clk, linux-gpio,
linux-input, linux-kernel, linux-media, linux-mediatek,
linux-sound, netdev
In-Reply-To: <CACRpkdbpKqKyebADj0xPFq3g0biPh-vm4d6C3sd8r0URyfyYRg@mail.gmail.com>
On Thu, Aug 21, 2025 at 01:56:24PM +0200, Linus Walleij wrote:
> Hi Ariel,
>
> thanks for your patch!
>
> On Wed, Aug 20, 2025 at 7:17 PM Ariel D'Alessandro
> <ariel.dalessandro@collabora.com> wrote:
>
> > + ce-gpios:
> > + description: GPIO connected to the CE (chip enable) pin of the chip
> > + maxItems: 1
>
> Mention that this should always have the flag GPIO_ACTIVE_HIGH
> as this is required by the hardware.
>
> Unfortunately we have no YAML syntax for enforcing flags :/
Theoretically there can be an inverter on the line, so from the AP point
of view the line is active low while from the peripheral POV the pin is
active high...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/5] platform/chrome: Fix a race when probing drivers
From: Tzung-Bi Shih @ 2025-09-05 8:38 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Benson Leung, linux-input, chrome-platform
In-Reply-To: <4gtrvxpo6zqk54uvavrox7hszszdpvdubz4w6iaks72zq3jjsw@b6cfvi5ysj2u>
On Thu, Sep 04, 2025 at 07:06:23AM -0700, Dmitry Torokhov wrote:
> On Tue, Sep 02, 2025 at 09:18:47PM +0800, Tzung-Bi Shih wrote:
> > On Fri, Aug 29, 2025 at 08:50:01PM +0800, Tzung-Bi Shih wrote:
> > > On Fri, Aug 29, 2025 at 11:28:55AM +0000, Dmitry Torokhov wrote:
> > > > On Thu, Aug 28, 2025 at 08:35:56AM +0000, Tzung-Bi Shih wrote:
> > > > > A race is observed when cros_ec_lpc and cros-ec-keyb are all built as
> > > > > modules. cros_ec_lpc is cros-ec-keyb's parent. However, they can be
> > > > > probed at the same time.
> > > > >
> > > > > Example:
> > > > >
> > > > > + -----------------------------------------------------------------+
> > > > > | Some init process (e.g. udevd) | deferred_probe_work_func worker |
> > > > > + -----------------------------------------------------------------+
> > > > > | Probe cros-ec-keyb. | |
> > > > > | - Decide to defer[1]. | |
> > > > > | | A device bound to a driver[2]. |
> > > > > | Probe cros_ec_lpc. | |
> > > > > | - Init the struct[3]. | |
> > > > > | | Retry cros-ec-keyb from the |
> > > > > | | deferred list[4]. |
> > > > > | | - Won't defer again as [3]. |
> > > > > | | - Access uninitialized data in |
> > > > > | | the struct. |
> > > > > | - Register the device. | |
> > > > > + -----------------------------------------------------------------+
> > > > >
> > > > > [1] https://elixir.bootlin.com/linux/v6.16/source/drivers/input/keyboard/cros_ec_keyb.c#L707
> > > > > [2] https://elixir.bootlin.com/linux/v6.16/source/drivers/base/dd.c#L405
> > > > > [3] https://elixir.bootlin.com/linux/v6.16/source/drivers/platform/chrome/cros_ec_lpc.c#L644
> > > > > [4] https://elixir.bootlin.com/linux/v6.16/source/drivers/base/dd.c#L418
> > > > >
> > > > > Note that the device link[5] can't help as in the observed environment,
> > > > > the devices are already added via device_add()[6].
> > > > >
> > > > > [5] https://www.kernel.org/doc/html/latest/driver-api/device_link.html#usage
> > > > > [6] https://elixir.bootlin.com/linux/v6.16/source/drivers/acpi/acpi_platform.c#L177
> > > > >
> > > > > The series fixes the issue by ensuring the struct is ready for accessing
> > > > > before continuing to probe cros-ec-keyb.
> > > >
> > > > Why is the keyboard platform device instantiated before the transport
> > > > (cros_ec_lpc) is done initializing? I think this is the root of the
> > > > issue...
> > >
> > > I may misunderstand but it seems to me:
> > >
> > > - The ACPI bus enumerated and instantiated the platform devices[6] first.
> > >
> > > - The keyboard platform device was probed when `cros_ec_keyb_driver`
> > > registered. It deferred as its parent's drvdata was NULL[1].
> > >
> > > - The transport platform device was probed when `cros_ec_lpc_driver`
> > > registered. It set the drvdata[3].
> > >
> > > - The keyboard platform device was probed again from retrying the deferred
> > > list, by another thread `deferred_probe_work_func`. The parent's drvdata
> > > wasn't NULL and cros_ec_register() for the transport device weren't
> > > finished. The race happened.
> >
> > Hi Dmitry,
> >
> > Does it make sense to you?
>
> I'll have to research how MFD mixes up statically described and
> DT-described platform devices and makes sure that children are not
> probed before the parent is ready - I think we need to make cros_ec
> behave the same way.
I may misunderstand but FWIW:
I failed to find relevant code in MFD [7] that guarantees the probe order.
Also, I'm curious about wouldn't code at [7] results in duplicate platform
devices? E.g., 1 populated from OF; 1 created by MFD.
Note: current cros_ec_dev.c doesn't use `of_compatible` in struct mfd_cell.
If we're looking at how cros_ec_dev.c guarantees the order:
- The transport platfrom device is probed first. It calls cros_ec_register().
- In cros_ec_register(), it registers the MFD device "cros-ec-dev". And the
children devices are added via mfd_add_devices().
Back to the issue we observed:
- The platform devices are created when it scans the tree in ACPI[6]. We
probably have no way to prevent the devices from adding unless specifying
`enumeration_by_parent`[8].
- When some of them are modules, the driver registrations are tied to the
module insertion. They can be arrived by anytime unless we use something
similar to soft dependency[9]. A Kconfig dependency will also
be needed to prevent cros_ec_lpcs=m but cros_ec_keyb=y. However,
cros_ec_keyb would need to specify 2 possible dependencies "cros_ec_lpcs"
and "cros_ec_spi"[10]. I'm not sure what would be happening if a system
has no cros_ec_spi module at all.
[7] https://elixir.bootlin.com/linux/v6.16/source/drivers/mfd/mfd-core.c#L184
[8] https://elixir.bootlin.com/linux/v6.16/source/drivers/acpi/scan.c#L2204
[9] https://elixir.bootlin.com/linux/v6.16/source/include/linux/module.h#L176
[10] https://elixir.bootlin.com/linux/v6.16/source/drivers/input/keyboard/Kconfig#L743
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 1939a9fcb80353dd8b111aa1e79c691afbde08b4
From: kernel test robot @ 2025-09-05 8:12 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 1939a9fcb80353dd8b111aa1e79c691afbde08b4 Input: i8042 - add TUXEDO InfinityBook Pro Gen10 AMD to i8042 quirk table
elapsed time: 1003m
configs tested: 194
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig clang-22
alpha allyesconfig clang-19
alpha defconfig clang-19
arc allmodconfig clang-19
arc allnoconfig clang-22
arc allyesconfig clang-19
arc axs103_defconfig clang-22
arc defconfig clang-19
arc randconfig-001-20250905 clang-22
arc randconfig-001-20250905 gcc-11.5.0
arc randconfig-002-20250905 clang-22
arc randconfig-002-20250905 gcc-13.4.0
arm allmodconfig clang-19
arm allnoconfig clang-22
arm allyesconfig clang-19
arm defconfig clang-19
arm randconfig-001-20250905 clang-22
arm randconfig-002-20250905 clang-22
arm randconfig-003-20250905 clang-16
arm randconfig-003-20250905 clang-22
arm randconfig-004-20250905 clang-22
arm randconfig-004-20250905 gcc-14.3.0
arm vt8500_v6_v7_defconfig clang-22
arm64 allmodconfig clang-19
arm64 allnoconfig clang-22
arm64 defconfig clang-19
arm64 randconfig-001-20250905 clang-22
arm64 randconfig-002-20250905 clang-17
arm64 randconfig-002-20250905 clang-22
arm64 randconfig-003-20250905 clang-17
arm64 randconfig-003-20250905 clang-22
arm64 randconfig-004-20250905 clang-22
csky allnoconfig clang-22
csky defconfig clang-19
csky randconfig-001-20250905 gcc-11.5.0
csky randconfig-002-20250905 gcc-11.5.0
hexagon allmodconfig clang-19
hexagon allnoconfig clang-22
hexagon allyesconfig clang-19
hexagon defconfig clang-19
hexagon randconfig-001-20250905 gcc-11.5.0
hexagon randconfig-002-20250905 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig clang-20
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20250905 clang-20
i386 buildonly-randconfig-002-20250905 clang-20
i386 buildonly-randconfig-003-20250905 clang-20
i386 buildonly-randconfig-004-20250905 clang-20
i386 buildonly-randconfig-004-20250905 gcc-13
i386 buildonly-randconfig-005-20250905 clang-20
i386 buildonly-randconfig-006-20250905 clang-20
i386 defconfig clang-20
i386 randconfig-001-20250905 gcc-13
i386 randconfig-002-20250905 gcc-13
i386 randconfig-003-20250905 gcc-13
i386 randconfig-004-20250905 gcc-13
i386 randconfig-005-20250905 gcc-13
i386 randconfig-006-20250905 gcc-13
i386 randconfig-007-20250905 gcc-13
i386 randconfig-011-20250905 clang-20
i386 randconfig-012-20250905 clang-20
i386 randconfig-013-20250905 clang-20
i386 randconfig-014-20250905 clang-20
i386 randconfig-015-20250905 clang-20
i386 randconfig-016-20250905 clang-20
i386 randconfig-017-20250905 clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch defconfig clang-19
loongarch randconfig-001-20250905 gcc-11.5.0
loongarch randconfig-002-20250905 gcc-11.5.0
m68k allmodconfig clang-19
m68k allnoconfig gcc-15.1.0
m68k allyesconfig clang-19
m68k defconfig clang-19
m68k m5272c3_defconfig clang-22
microblaze allmodconfig clang-19
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig clang-19
microblaze defconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
nios2 allnoconfig gcc-15.1.0
nios2 defconfig gcc-15.1.0
nios2 randconfig-001-20250905 gcc-11.5.0
nios2 randconfig-002-20250905 gcc-11.5.0
openrisc allnoconfig clang-22
openrisc allyesconfig gcc-15.1.0
openrisc defconfig gcc-13
parisc allmodconfig gcc-15.1.0
parisc allnoconfig clang-22
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20250905 gcc-11.5.0
parisc randconfig-002-20250905 gcc-11.5.0
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig clang-22
powerpc allyesconfig gcc-15.1.0
powerpc mpc836x_rdk_defconfig clang-22
powerpc randconfig-001-20250905 gcc-11.5.0
powerpc randconfig-002-20250905 gcc-11.5.0
powerpc randconfig-003-20250905 gcc-11.5.0
powerpc64 randconfig-001-20250905 gcc-11.5.0
powerpc64 randconfig-002-20250905 gcc-11.5.0
powerpc64 randconfig-003-20250905 gcc-11.5.0
riscv allmodconfig gcc-15.1.0
riscv allnoconfig clang-22
riscv allyesconfig gcc-15.1.0
riscv defconfig gcc-13
riscv randconfig-001-20250905 gcc-14.3.0
riscv randconfig-001-20250905 gcc-15.1.0
riscv randconfig-002-20250905 clang-22
riscv randconfig-002-20250905 gcc-15.1.0
s390 allmodconfig gcc-15.1.0
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 defconfig gcc-13
s390 randconfig-001-20250905 gcc-15.1.0
s390 randconfig-001-20250905 gcc-9.5.0
s390 randconfig-002-20250905 clang-22
s390 randconfig-002-20250905 gcc-15.1.0
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh defconfig gcc-13
sh randconfig-001-20250905 gcc-15.1.0
sh randconfig-002-20250905 gcc-15.1.0
sh se7619_defconfig clang-22
sh sh7710voipgw_defconfig clang-22
sh titan_defconfig clang-22
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20250905 gcc-15.1.0
sparc randconfig-001-20250905 gcc-8.5.0
sparc randconfig-002-20250905 gcc-15.1.0
sparc64 defconfig gcc-13
sparc64 randconfig-001-20250905 gcc-15.1.0
sparc64 randconfig-001-20250905 gcc-8.5.0
sparc64 randconfig-002-20250905 clang-22
sparc64 randconfig-002-20250905 gcc-15.1.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig clang-19
um defconfig gcc-13
um i386_defconfig gcc-13
um randconfig-001-20250905 clang-22
um randconfig-001-20250905 gcc-15.1.0
um randconfig-002-20250905 gcc-13
um randconfig-002-20250905 gcc-15.1.0
um x86_64_defconfig gcc-13
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20250905 clang-20
x86_64 buildonly-randconfig-001-20250905 gcc-13
x86_64 buildonly-randconfig-002-20250905 clang-20
x86_64 buildonly-randconfig-002-20250905 gcc-13
x86_64 buildonly-randconfig-003-20250905 gcc-13
x86_64 buildonly-randconfig-004-20250905 clang-20
x86_64 buildonly-randconfig-004-20250905 gcc-13
x86_64 buildonly-randconfig-005-20250905 clang-20
x86_64 buildonly-randconfig-005-20250905 gcc-13
x86_64 buildonly-randconfig-006-20250905 gcc-13
x86_64 defconfig clang-20
x86_64 kexec clang-20
x86_64 randconfig-001-20250905 clang-20
x86_64 randconfig-002-20250905 clang-20
x86_64 randconfig-003-20250905 clang-20
x86_64 randconfig-004-20250905 clang-20
x86_64 randconfig-005-20250905 clang-20
x86_64 randconfig-006-20250905 clang-20
x86_64 randconfig-007-20250905 clang-20
x86_64 randconfig-008-20250905 clang-20
x86_64 randconfig-071-20250905 clang-20
x86_64 randconfig-072-20250905 clang-20
x86_64 randconfig-073-20250905 clang-20
x86_64 randconfig-074-20250905 clang-20
x86_64 randconfig-075-20250905 clang-20
x86_64 randconfig-076-20250905 clang-20
x86_64 randconfig-077-20250905 clang-20
x86_64 randconfig-078-20250905 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-13
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-13
x86_64 rhel-9.4-ltp gcc-13
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20250905 gcc-15.1.0
xtensa randconfig-001-20250905 gcc-8.5.0
xtensa randconfig-002-20250905 gcc-15.1.0
xtensa randconfig-002-20250905 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: goodix: Drop 'interrupts' requirement
From: Geert Uytterhoeven @ 2025-09-05 7:57 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-input, Conor Dooley, Dmitry Torokhov, Krzysztof Kozlowski,
Rob Herring, devicetree, linux-renesas-soc
In-Reply-To: <20250904195727.168152-1-marek.vasut+renesas@mailbox.org>
On Fri, 5 Sept 2025 at 02:44, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Since commit 409fe0cea366 ("Input: goodix - add support for polling mode")
> the interrupts property is optional, since at least the Linux kernel driver
> supports also polling mode.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH RESEND v2] hid: intel-thc-hid: intel-quicki2c: support ACPI config for advanced features
From: Even Xu @ 2025-09-05 2:52 UTC (permalink / raw)
To: xinpeng.sun
Cc: bentiss, jikos, linux-input, linux-kernel, rui1.zhang,
srinivas.pandruvada, Even Xu
In-Reply-To: <20250905013935.1356008-1-xinpeng.sun@intel.com>
Add comment inline.
> From: Xinpeng Sun <xinpeng.sun@intel.com>
> To: jikos@kernel.org, bentiss@kernel.org
> Cc: srinivas.pandruvada@linux.intel.com, linux-input@vger.kernel.org,
> linux-kernel@vger.kernel.org, Xinpeng Sun <xinpeng.sun@intel.com>,
> Rui Zhang <rui1.zhang@intel.com>
> Subject: [PATCH RESEND v2] hid: intel-thc-hid: intel-quicki2c: support ACPI config for advanced features
> Date: Fri, 5 Sep 2025 09:39:35 +0800 [thread overview]
> Message-ID: <20250905013935.1356008-1-xinpeng.sun@intel.com> (raw)
>
> There is a new BIOS enhancement that adds the capability to configure the
> following two features of I2C subsystem introduced in commit 1ed0b48
> ("Intel-thc: Introduce max input size control") and commit 3f2a921
> ("Intel-thc: Introduce interrupt delay control"):
> - Max input size control
> - Interrupt delay control
>
> As BIOS is used for the configuration of these two features, change driver
> data usage to indicate hardware capability, and add corresponding ACPI
> configuration support in QuickI2C driver.
>
> Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
> Tested-by: Rui Zhang <rui1.zhang@intel.com>
> ---
> .../intel-quicki2c/pci-quicki2c.c | 43 ++++++++++++++-----
> .../intel-quicki2c/quicki2c-dev.h | 24 ++++++++++-
> 2 files changed, 55 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> index 854926b3cfd4..787c32557d24 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> @@ -23,6 +23,7 @@
>
> static struct quicki2c_ddata ptl_ddata = {
> .max_detect_size = MAX_RX_DETECT_SIZE_PTL,
> + .max_interrupt_delay = MAX_RX_INTERRUPT_DELAY,
> };
>
> /* THC QuickI2C ACPI method to get device properties */
> @@ -123,8 +124,8 @@ static int quicki2c_acpi_get_dsd_property(struct acpi_device *adev, acpi_string
> static int quicki2c_get_acpi_resources(struct quicki2c_device *qcdev)
> {
> struct acpi_device *adev = ACPI_COMPANION(qcdev->dev);
> - struct quicki2c_subip_acpi_parameter i2c_param;
> - struct quicki2c_subip_acpi_config i2c_config;
> + struct quicki2c_subip_acpi_parameter i2c_param = {0};
> + struct quicki2c_subip_acpi_config i2c_config = {0};
Remove the initialization {0}, it's unnecessary.
> u32 hid_desc_addr;
> int ret = -EINVAL;
>
> @@ -200,6 +201,21 @@ static int quicki2c_get_acpi_resources(struct quicki2c_device *qcdev)
> return -EOPNOTSUPP;
> }
>
> + if (qcdev->ddata) {
> + qcdev->i2c_max_frame_size_enable = i2c_config.FSEN;
> + qcdev->i2c_int_delay_enable = i2c_config.INDE;
> +
> + if (i2c_config.FSVL <= qcdev->ddata->max_detect_size)
> + qcdev->i2c_max_frame_size = i2c_config.FSVL;
> + else
> + qcdev->i2c_max_frame_size = qcdev->ddata->max_detect_size;
> +
> + if (i2c_config.INDV <= qcdev->ddata->max_interrupt_delay)
> + qcdev->i2c_int_delay = i2c_config.INDV;
> + else
> + qcdev->i2c_int_delay = qcdev->ddata->max_interrupt_delay;
> + }
> +
> return 0;
> }
>
> @@ -441,17 +457,24 @@ static void quicki2c_dma_adv_enable(struct quicki2c_device *qcdev)
> * max input length <= THC detect capability, enable the feature with device
> * max input length.
> */
> - if (qcdev->ddata->max_detect_size >=
> - le16_to_cpu(qcdev->dev_desc.max_input_len)) {
> - thc_i2c_set_rx_max_size(qcdev->thc_hw,
> - le16_to_cpu(qcdev->dev_desc.max_input_len));
> + if (qcdev->i2c_max_frame_size_enable) {
> + if (qcdev->i2c_max_frame_size >=
> + le16_to_cpu(qcdev->dev_desc.max_input_len)) {
> + thc_i2c_set_rx_max_size(qcdev->thc_hw,
> + le16_to_cpu(qcdev->dev_desc.max_input_len));
> + } else {
> + dev_warn(qcdev->dev,
> + "Max frame size is smaller than hid max input length!");
> + thc_i2c_set_rx_max_size(qcdev->thc_hw,
> + le16_to_cpu(qcdev->i2c_max_frame_size));
> + }
> thc_i2c_rx_max_size_enable(qcdev->thc_hw, true);
> }
>
> /* If platform supports interrupt delay feature, enable it with given delay */
> - if (qcdev->ddata->interrupt_delay) {
> + if (qcdev->i2c_int_delay_enable) {
> thc_i2c_set_rx_int_delay(qcdev->thc_hw,
> - qcdev->ddata->interrupt_delay);
> + qcdev->i2c_int_delay * 10);
> thc_i2c_rx_int_delay_enable(qcdev->thc_hw, true);
> }
> }
> @@ -464,10 +487,10 @@ static void quicki2c_dma_adv_enable(struct quicki2c_device *qcdev)
> */
> static void quicki2c_dma_adv_disable(struct quicki2c_device *qcdev)
> {
> - if (qcdev->ddata->max_detect_size)
> + if (qcdev->i2c_max_frame_size_enable)
> thc_i2c_rx_max_size_enable(qcdev->thc_hw, false);
>
> - if (qcdev->ddata->interrupt_delay)
> + if (qcdev->i2c_int_delay_enable)
> thc_i2c_rx_int_delay_enable(qcdev->thc_hw, false);
> }
>
> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> index d412eafcf9ea..0d423d5dd7a7 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> @@ -38,6 +38,8 @@
>
> /* PTL Max packet size detection capability is 255 Bytes */
> #define MAX_RX_DETECT_SIZE_PTL 255
> +/* Max interrupt delay capability is 2.56ms */
> +#define MAX_RX_INTERRUPT_DELAY 256
>
> /* Default interrupt delay is 1ms, suitable for most devices */
> #define DEFAULT_INTERRUPT_DELAY_US (1 * USEC_PER_MSEC)
> @@ -101,6 +103,10 @@ struct quicki2c_subip_acpi_parameter {
> * @HMTD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line Transmit HOLD Period
> * @HMRD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line Receive HOLD Period
> * @HMSL: Maximum length (in ic_clk_cycles) of suppressed spikes in High Speed Mode
> + * @FSEN: Maximum Frame Size Feature Enable Control
> + * @FSVL: Maximum Frame Size Value (unit in Bytes)
> + * @INDE: Interrupt Delay Feature Enable Control
> + * @INDV: Interrupt Delay Value (unit in 10 us)
> *
> * Those properties get from QUICKI2C_ACPI_METHOD_NAME_ISUB method, used for
> * I2C timing configure.
> @@ -127,17 +133,22 @@ struct quicki2c_subip_acpi_config {
> u64 HMTD;
> u64 HMRD;
> u64 HMSL;
> +
> + u64 FSEN;
> + u64 FSVL;
> + u64 INDE;
> + u64 INDV;
> u8 reserved;
> };
>
> /**
> * struct quicki2c_ddata - Driver specific data for quicki2c device
> * @max_detect_size: Identify max packet size detect for rx
> - * @interrupt_delay: Identify interrupt detect delay for rx
> + * @interrupt_delay: Identify max interrupt detect delay for rx
> */
> struct quicki2c_ddata {
> u32 max_detect_size;
> - u32 interrupt_delay;
> + u32 max_interrupt_delay;
> };
>
> struct device;
> @@ -170,6 +181,10 @@ struct acpi_device;
> * @report_len: The length of input/output report packet
> * @reset_ack_wq: Workqueue for waiting reset response from device
> * @reset_ack: Indicate reset response received or not
> + * @i2c_max_frame_size_enable: Indicate max frame size feature enabled or not
> + * @i2c_max_frame_size: Max RX frame size (unit in Bytes)
> + * @i2c_int_delay_enable: Indicate interrupt delay feature enabled or not
> + * @i2c_int_delay: Interrupt detection delay value (unit in 10 us)
> */
> struct quicki2c_device {
> struct device *dev;
> @@ -200,6 +215,11 @@ struct quicki2c_device {
>
> wait_queue_head_t reset_ack_wq;
> bool reset_ack;
> +
> + u32 i2c_max_frame_size_enable;
> + u32 i2c_max_frame_size;
> + u32 i2c_int_delay_enable;
> + u32 i2c_int_delay;
> };
>
> #endif /* _QUICKI2C_DEV_H_ */
> --
> 2.40.1
^ permalink raw reply
* Re: [PATCH v2 2/2] hid: intel-thc-hid: intel-quickspi: Add WCL Device IDs
From: Even Xu @ 2025-09-05 2:07 UTC (permalink / raw)
To: xinpeng.sun
Cc: bentiss, jikos, linux-input, linux-kernel, srinivas.pandruvada,
Even Xu
In-Reply-To: <20250828021000.3299377-2-xinpeng.sun@intel.com>
Thanks for the patch!
Reviewed-by: Even Xu <even.xu@intel.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] hid: intel-thc-hid: intel-quicki2c: Add WCL Device IDs
From: Even Xu @ 2025-09-05 1:58 UTC (permalink / raw)
To: xinpeng.sun
Cc: bentiss, jikos, linux-input, linux-kernel, srinivas.pandruvada,
Even Xu
In-Reply-To: <20250828021000.3299377-1-xinpeng.sun@intel.com>
Thanks for the patch!
Reviewed-by: Even Xu <even.xu@intel.com>
^ permalink raw reply
* [PATCH RESEND v2] hid: intel-thc-hid: intel-quicki2c: support ACPI config for advanced features
From: Xinpeng Sun @ 2025-09-05 1:39 UTC (permalink / raw)
To: jikos, bentiss
Cc: srinivas.pandruvada, linux-input, linux-kernel, Xinpeng Sun,
Rui Zhang
There is a new BIOS enhancement that adds the capability to configure the
following two features of I2C subsystem introduced in commit 1ed0b48
("Intel-thc: Introduce max input size control") and commit 3f2a921
("Intel-thc: Introduce interrupt delay control"):
- Max input size control
- Interrupt delay control
As BIOS is used for the configuration of these two features, change driver
data usage to indicate hardware capability, and add corresponding ACPI
configuration support in QuickI2C driver.
Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
Tested-by: Rui Zhang <rui1.zhang@intel.com>
---
.../intel-quicki2c/pci-quicki2c.c | 43 ++++++++++++++-----
.../intel-quicki2c/quicki2c-dev.h | 24 ++++++++++-
2 files changed, 55 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
index 854926b3cfd4..787c32557d24 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
@@ -23,6 +23,7 @@
static struct quicki2c_ddata ptl_ddata = {
.max_detect_size = MAX_RX_DETECT_SIZE_PTL,
+ .max_interrupt_delay = MAX_RX_INTERRUPT_DELAY,
};
/* THC QuickI2C ACPI method to get device properties */
@@ -123,8 +124,8 @@ static int quicki2c_acpi_get_dsd_property(struct acpi_device *adev, acpi_string
static int quicki2c_get_acpi_resources(struct quicki2c_device *qcdev)
{
struct acpi_device *adev = ACPI_COMPANION(qcdev->dev);
- struct quicki2c_subip_acpi_parameter i2c_param;
- struct quicki2c_subip_acpi_config i2c_config;
+ struct quicki2c_subip_acpi_parameter i2c_param = {0};
+ struct quicki2c_subip_acpi_config i2c_config = {0};
u32 hid_desc_addr;
int ret = -EINVAL;
@@ -200,6 +201,21 @@ static int quicki2c_get_acpi_resources(struct quicki2c_device *qcdev)
return -EOPNOTSUPP;
}
+ if (qcdev->ddata) {
+ qcdev->i2c_max_frame_size_enable = i2c_config.FSEN;
+ qcdev->i2c_int_delay_enable = i2c_config.INDE;
+
+ if (i2c_config.FSVL <= qcdev->ddata->max_detect_size)
+ qcdev->i2c_max_frame_size = i2c_config.FSVL;
+ else
+ qcdev->i2c_max_frame_size = qcdev->ddata->max_detect_size;
+
+ if (i2c_config.INDV <= qcdev->ddata->max_interrupt_delay)
+ qcdev->i2c_int_delay = i2c_config.INDV;
+ else
+ qcdev->i2c_int_delay = qcdev->ddata->max_interrupt_delay;
+ }
+
return 0;
}
@@ -441,17 +457,24 @@ static void quicki2c_dma_adv_enable(struct quicki2c_device *qcdev)
* max input length <= THC detect capability, enable the feature with device
* max input length.
*/
- if (qcdev->ddata->max_detect_size >=
- le16_to_cpu(qcdev->dev_desc.max_input_len)) {
- thc_i2c_set_rx_max_size(qcdev->thc_hw,
- le16_to_cpu(qcdev->dev_desc.max_input_len));
+ if (qcdev->i2c_max_frame_size_enable) {
+ if (qcdev->i2c_max_frame_size >=
+ le16_to_cpu(qcdev->dev_desc.max_input_len)) {
+ thc_i2c_set_rx_max_size(qcdev->thc_hw,
+ le16_to_cpu(qcdev->dev_desc.max_input_len));
+ } else {
+ dev_warn(qcdev->dev,
+ "Max frame size is smaller than hid max input length!");
+ thc_i2c_set_rx_max_size(qcdev->thc_hw,
+ le16_to_cpu(qcdev->i2c_max_frame_size));
+ }
thc_i2c_rx_max_size_enable(qcdev->thc_hw, true);
}
/* If platform supports interrupt delay feature, enable it with given delay */
- if (qcdev->ddata->interrupt_delay) {
+ if (qcdev->i2c_int_delay_enable) {
thc_i2c_set_rx_int_delay(qcdev->thc_hw,
- qcdev->ddata->interrupt_delay);
+ qcdev->i2c_int_delay * 10);
thc_i2c_rx_int_delay_enable(qcdev->thc_hw, true);
}
}
@@ -464,10 +487,10 @@ static void quicki2c_dma_adv_enable(struct quicki2c_device *qcdev)
*/
static void quicki2c_dma_adv_disable(struct quicki2c_device *qcdev)
{
- if (qcdev->ddata->max_detect_size)
+ if (qcdev->i2c_max_frame_size_enable)
thc_i2c_rx_max_size_enable(qcdev->thc_hw, false);
- if (qcdev->ddata->interrupt_delay)
+ if (qcdev->i2c_int_delay_enable)
thc_i2c_rx_int_delay_enable(qcdev->thc_hw, false);
}
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
index d412eafcf9ea..0d423d5dd7a7 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
@@ -38,6 +38,8 @@
/* PTL Max packet size detection capability is 255 Bytes */
#define MAX_RX_DETECT_SIZE_PTL 255
+/* Max interrupt delay capability is 2.56ms */
+#define MAX_RX_INTERRUPT_DELAY 256
/* Default interrupt delay is 1ms, suitable for most devices */
#define DEFAULT_INTERRUPT_DELAY_US (1 * USEC_PER_MSEC)
@@ -101,6 +103,10 @@ struct quicki2c_subip_acpi_parameter {
* @HMTD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line Transmit HOLD Period
* @HMRD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line Receive HOLD Period
* @HMSL: Maximum length (in ic_clk_cycles) of suppressed spikes in High Speed Mode
+ * @FSEN: Maximum Frame Size Feature Enable Control
+ * @FSVL: Maximum Frame Size Value (unit in Bytes)
+ * @INDE: Interrupt Delay Feature Enable Control
+ * @INDV: Interrupt Delay Value (unit in 10 us)
*
* Those properties get from QUICKI2C_ACPI_METHOD_NAME_ISUB method, used for
* I2C timing configure.
@@ -127,17 +133,22 @@ struct quicki2c_subip_acpi_config {
u64 HMTD;
u64 HMRD;
u64 HMSL;
+
+ u64 FSEN;
+ u64 FSVL;
+ u64 INDE;
+ u64 INDV;
u8 reserved;
};
/**
* struct quicki2c_ddata - Driver specific data for quicki2c device
* @max_detect_size: Identify max packet size detect for rx
- * @interrupt_delay: Identify interrupt detect delay for rx
+ * @interrupt_delay: Identify max interrupt detect delay for rx
*/
struct quicki2c_ddata {
u32 max_detect_size;
- u32 interrupt_delay;
+ u32 max_interrupt_delay;
};
struct device;
@@ -170,6 +181,10 @@ struct acpi_device;
* @report_len: The length of input/output report packet
* @reset_ack_wq: Workqueue for waiting reset response from device
* @reset_ack: Indicate reset response received or not
+ * @i2c_max_frame_size_enable: Indicate max frame size feature enabled or not
+ * @i2c_max_frame_size: Max RX frame size (unit in Bytes)
+ * @i2c_int_delay_enable: Indicate interrupt delay feature enabled or not
+ * @i2c_int_delay: Interrupt detection delay value (unit in 10 us)
*/
struct quicki2c_device {
struct device *dev;
@@ -200,6 +215,11 @@ struct quicki2c_device {
wait_queue_head_t reset_ack_wq;
bool reset_ack;
+
+ u32 i2c_max_frame_size_enable;
+ u32 i2c_max_frame_size;
+ u32 i2c_int_delay_enable;
+ u32 i2c_int_delay;
};
#endif /* _QUICKI2C_DEV_H_ */
--
2.40.1
^ permalink raw reply related
* [PATCH 1/1] dt-bindings: input: convert max11801-ts to yaml format
From: Frank Li @ 2025-09-04 20:06 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Convert max11801-ts to yaml format.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
.../input/touchscreen/max11801-ts.txt | 17 -------
.../input/touchscreen/maxim,max11801.yaml | 46 +++++++++++++++++++
2 files changed, 46 insertions(+), 17 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/maxim,max11801.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt
deleted file mode 100644
index 05e982c3454eb..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* MAXI MAX11801 Resistive touch screen controller with i2c interface
-
-Required properties:
-- compatible: must be "maxim,max11801"
-- reg: i2c slave address
-- interrupts: touch controller interrupt
-
-Example:
-
-&i2c1 {
- max11801: touchscreen@48 {
- compatible = "maxim,max11801";
- reg = <0x48>;
- interrupt-parent = <&gpio3>;
- interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/maxim,max11801.yaml b/Documentation/devicetree/bindings/input/touchscreen/maxim,max11801.yaml
new file mode 100644
index 0000000000000..4f528d2201992
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/maxim,max11801.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/maxim,max11801.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAXI MAX11801 Resistive touch screen controller with i2c interface
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: maxim,max11801
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+allOf:
+ - $ref: touchscreen.yaml
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@48 {
+ compatible = "maxim,max11801";
+ reg = <0x48>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH] dt-bindings: input: touchscreen: goodix: Drop 'interrupts' requirement
From: Marek Vasut @ 2025-09-04 19:57 UTC (permalink / raw)
To: linux-input
Cc: Marek Vasut, Conor Dooley, Dmitry Torokhov, Krzysztof Kozlowski,
Rob Herring, devicetree, linux-renesas-soc
Since commit 409fe0cea366 ("Input: goodix - add support for polling mode")
the interrupts property is optional, since at least the Linux kernel driver
supports also polling mode.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
Documentation/devicetree/bindings/input/touchscreen/goodix.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
index eb4992f708b70..a96137c6f0635 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
@@ -62,7 +62,6 @@ additionalProperties: false
required:
- compatible
- reg
- - interrupts
examples:
- |
--
2.50.1
^ permalink raw reply related
* [PATCH 1/1] dt-bindings: input: convert semtech,sx8654 to yaml format
From: Frank Li @ 2025-09-04 19:17 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Convert sx8654.txt to yaml format.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
.../input/touchscreen/semtech,sx8654.yaml | 52 +++++++++++++++++++
.../bindings/input/touchscreen/sx8654.txt | 23 --------
2 files changed, 52 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml b/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
new file mode 100644
index 0000000000000..b2554064b6888
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/semtech,sx8654.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech SX8654 I2C Touchscreen Controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - semtech,sx8650
+ - semtech,sx8654
+ - semtech,sx8655
+ - semtech,sx8656
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@48 {
+ compatible = "semtech,sx8654";
+ reg = <0x48>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
deleted file mode 100644
index 0ebe6dd043c7b..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Semtech SX8654 I2C Touchscreen Controller
-
-Required properties:
-- compatible: must be one of the following, depending on the model:
- "semtech,sx8650"
- "semtech,sx8654"
- "semtech,sx8655"
- "semtech,sx8656"
-- reg: i2c slave address
-- interrupts: touch controller interrupt
-
-Optional properties:
- - reset-gpios: GPIO specification for the NRST input
-
-Example:
-
- sx8654@48 {
- compatible = "semtech,sx8654";
- reg = <0x48>;
- interrupt-parent = <&gpio6>;
- interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
- };
--
2.34.1
^ permalink raw reply related
* [PATCH 1/1] dt-bindings: input: convert semtech,sx8654 to yaml format
From: Frank Li @ 2025-09-04 19:03 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Convert sx8654.txt to yaml format.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
.../input/touchscreen/semtech,sx8654.yaml | 52 +++++++++++++++++++
.../bindings/input/touchscreen/sx8654.txt | 23 --------
2 files changed, 52 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml b/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
new file mode 100644
index 0000000000000..b2554064b6888
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/semtech,sx8654.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech SX8654 I2C Touchscreen Controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - semtech,sx8650
+ - semtech,sx8654
+ - semtech,sx8655
+ - semtech,sx8656
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@48 {
+ compatible = "semtech,sx8654";
+ reg = <0x48>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
deleted file mode 100644
index 0ebe6dd043c7b..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Semtech SX8654 I2C Touchscreen Controller
-
-Required properties:
-- compatible: must be one of the following, depending on the model:
- "semtech,sx8650"
- "semtech,sx8654"
- "semtech,sx8655"
- "semtech,sx8656"
-- reg: i2c slave address
-- interrupts: touch controller interrupt
-
-Optional properties:
- - reset-gpios: GPIO specification for the NRST input
-
-Example:
-
- sx8654@48 {
- compatible = "semtech,sx8654";
- reg = <0x48>;
- interrupt-parent = <&gpio6>;
- interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
- };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-04 18:18 UTC (permalink / raw)
To: Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <SN6PR02MB41573C5451F21286667C5441D400A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 9/4/25 09:26, Michael Kelley wrote:
> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>
>> On 9/2/25 07:42, Michael Kelley wrote:
>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>
>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>
>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>> encompasses builtin code and various other things and not a dedicated config
>>>> option for VMBUS. Vmbus should really have a config option just like
>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>> to build VMBUS driver and make that distinction explicit. With that
>>>> CONFIG_HYPERV could be changed to bool.
>>>
>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>> is already mostly in separate source files code, though there's some
>>> entanglement in the handling of VMBus interrupts, which could be
>>> improved later.
>>>
>>> However, I have a compatibility concern. Consider this scenario:
>>>
>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>> built with CONFIG_HYPERV=m.
>>> 2) Grab a new version of kernel source code that contains this patch set.
>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>> 4) Build the new kernel. This succeeds.
>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>
>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>> newly built kernel has no Hyper-V support and won't run in a
>>> Hyper-V VM.
>>>
>>> As a second issue, if in Step 1 the current kernel was built with
>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>> and won't run in a typical Hyper-V VM.
>>>
>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>> I'm not sure how to fix the first issue, except by continuing to
>>> allow CONFIG_HYPERV=m.
>>
>> To certain extent, imo, users are expected to check config files
>> for changes when moving to new versions/releases, so it would be a
>> one time burden.
>
> I'm not so sanguine about the impact. For those of us who work with
> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
> the details of how the Kconfig files are put together. And the issue occurs
> with no error messages that something has gone wrong in building
> the kernel, except that it won't boot. Just running "make olddefconfig"
> has worked in the past, so some users will be befuddled and end up
> generating Azure support incidents. I also wonder about breaking
> automated test suites for new kernels, as they are likely to be running
> "make olddefconfig" or something similar as part of the automation.
>
>> CONFIG_HYPERV=m is just broken imo as one sees that
>> in .config but magically symbols in drivers/hv are in kerenel.
>>
>
> I agree that's not ideal. But note that some Hyper-V code and symbols
> like ms_hyperv_init_platform() and related functions show up when
> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
> is one of the recognized and somewhat hardwired hypervisors (like
> VMware, for example).
>
> Finally, there are about a dozen other places in the kernel that use
> the same Makefile construct to make some code built-in even though
> the CONFIG option is set to "m". That may not be enough occurrences
> to make it standard practice, but Hyper-V guests are certainly not the
> only case.
>
> In my mind, this is judgment call with no absolute right answer. What
> do others think about the tradeoffs?
Wei had said in private message that he agrees this is a good idea. Nuno
said earlier above:
"FWIW I think it's a good idea, interested to hear what others think."
Thanks,
-Mukesh
^ permalink raw reply
* [PATCH] HID: cp2112: fix setter callbacks return value
From: Sébastien Szymanski @ 2025-09-04 16:42 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Linus Walleij,
Bartosz Golaszewski
Cc: Bartosz Golaszewski, linux-input, linux-kernel, linux-gpio,
Sébastien Szymanski
Since commit 6485543488a6 ("HID: cp2112: use new line value setter
callbacks"), setting a GPIO value always fails with error -EBADE.
That's because the returned value by the setter callbacks is the
returned value by the hid_hw_raw_request() function which is the number of
bytes sent on success or a negative value on error. The function
gpiochip_set() returns -EBADE if the setter callbacks return a value >
0.
Fix this by making the setter callbacks return 0 on success or a negative
value on error.
While at it, use the returned value by cp2112_gpio_set_unlocked() in the
direction_output callback.
Fixes: 6485543488a6 ("HID: cp2112: use new line value setter callbacks")
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
---
drivers/hid/hid-cp2112.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index 482f62a78c4155a50cceea3c8894ee5959e9aaed..5a95ea3bec9805453712b7b9e3d3fefec2351822 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -229,10 +229,12 @@ static int cp2112_gpio_set_unlocked(struct cp2112_device *dev,
ret = hid_hw_raw_request(hdev, CP2112_GPIO_SET, buf,
CP2112_GPIO_SET_LENGTH, HID_FEATURE_REPORT,
HID_REQ_SET_REPORT);
- if (ret < 0)
+ if (ret != CP2112_GPIO_SET_LENGTH) {
hid_err(hdev, "error setting GPIO values: %d\n", ret);
+ return ret < 0 ? ret : -EIO;
+ }
- return ret;
+ return 0;
}
static int cp2112_gpio_set(struct gpio_chip *chip, unsigned int offset,
@@ -309,9 +311,7 @@ static int cp2112_gpio_direction_output(struct gpio_chip *chip,
* Set gpio value when output direction is already set,
* as specified in AN495, Rev. 0.2, cpt. 4.4
*/
- cp2112_gpio_set_unlocked(dev, offset, value);
-
- return 0;
+ return cp2112_gpio_set_unlocked(dev, offset, value);
}
static int cp2112_hid_get(struct hid_device *hdev, unsigned char report_number,
---
base-commit: b320789d6883cc00ac78ce83bccbfe7ed58afcf0
change-id: 20250902-hid-cp2112-fix-set-value-1898aa5e041f
Best regards,
--
Sébastien Szymanski <sebastien.szymanski@armadeus.com>
^ permalink raw reply related
* [PATCH v2 1/1] dt-bindings: input: exc3000: move eeti,egalax_ts from egalax-ts.txt to eeti,exc3000.yaml
From: Frank Li @ 2025-09-04 17:15 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Remove legacy binding egalax-ts.txt file. And add compatible string
eeti,egalax_ts and wakeup-gpios to eeti,exc3000.yaml. "eeti,egalax_ts" is
general compatible string, which is not preferred. But it is compatible
with old devices (older than 10 years) and existing driver in
drivers/input/touchscreen/egalax_ts.c.
Allow address 0x4 for eeti,egalax_ts.
Don't require touchscreen-size-x(y) for eeti,egalax_ts.
Keep the same restriction for existing compatible string.
Fix below DTB_CHECKS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dtb: /soc/bus@2100000/i2c@21a8000/egalax_ts@4: failed to match any schema with compatible: ['eeti,egalax_ts']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- sorry missed one local change at v1
- allow address 0x4 for eeti,egalax_ts.
- move out touchscreen-size-x(y) from required.
---
.../input/touchscreen/eeti,exc3000.yaml | 30 +++++++++++++++----
.../bindings/input/touchscreen/egalax-ts.txt | 18 -----------
2 files changed, 24 insertions(+), 24 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
index 1c7ae05a8c15e..d19b07d4cfd4a 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
@@ -9,25 +9,25 @@ title: EETI EXC3000 series touchscreen controller
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
-allOf:
- - $ref: touchscreen.yaml#
-
properties:
compatible:
oneOf:
- const: eeti,exc3000
- const: eeti,exc80h60
- const: eeti,exc80h84
+ - const: eeti,egalax_ts # Do NOT use for new binding
- items:
- enum:
- eeti,exc81w32
- const: eeti,exc80h84
reg:
- const: 0x2a
+ enum: [0x4, 0x2a]
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
+ wakeup-gpios:
+ maxItems: 1
vdd-supply:
description: Power supply regulator for the chip
touchscreen-size-x: true
@@ -40,11 +40,29 @@ required:
- compatible
- reg
- interrupts
- - touchscreen-size-x
- - touchscreen-size-y
additionalProperties: false
+allOf:
+ - $ref: touchscreen.yaml#
+
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: eeti,egalax_ts
+ then:
+ properties:
+ reg:
+ const: 0x2a
+
+ wakeup-gpios: false
+
+ required:
+ - touchscreen-size-x
+ - touchscreen-size-y
+
examples:
- |
#include "dt-bindings/interrupt-controller/irq.h"
diff --git a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
deleted file mode 100644
index ebbe938105745..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* EETI eGalax Multiple Touch Controller
-
-Required properties:
-- compatible: must be "eeti,egalax_ts"
-- reg: i2c slave address
-- interrupts: touch controller interrupt
-- wakeup-gpios: the gpio pin to be used for waking up the controller
- and also used as irq pin
-
-Example:
-
- touchscreen@4 {
- compatible = "eeti,egalax_ts";
- reg = <0x04>;
- interrupt-parent = <&gpio1>;
- interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
- wakeup-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
- };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] HID: cp2112: fix setter callbacks return value
From: Bartosz Golaszewski @ 2025-09-04 16:45 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: Bartosz Golaszewski, linux-input, linux-kernel, linux-gpio,
Jiri Kosina, Benjamin Tissoires, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20250904-hid-cp2112-fix-set-value-v1-1-17d2e26dc8c9@armadeus.com>
On Thu, 4 Sep 2025 18:42:07 +0200, "Sébastien Szymanski"
<sebastien.szymanski@armadeus.com> said:
> Since commit 6485543488a6 ("HID: cp2112: use new line value setter
> callbacks"), setting a GPIO value always fails with error -EBADE.
>
> That's because the returned value by the setter callbacks is the
> returned value by the hid_hw_raw_request() function which is the number of
> bytes sent on success or a negative value on error. The function
> gpiochip_set() returns -EBADE if the setter callbacks return a value >
> 0.
>
> Fix this by making the setter callbacks return 0 on success or a negative
> value on error.
>
> While at it, use the returned value by cp2112_gpio_set_unlocked() in the
> direction_output callback.
>
> Fixes: 6485543488a6 ("HID: cp2112: use new line value setter callbacks")
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
> ---
Eek! With the number of conversions it was bound to happen to some drivers
since I can't really functionally test most of them. :(
Thanks for spotting it and fixing it!
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
^ permalink raw reply
* RE: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Michael Kelley @ 2025-09-04 16:26 UTC (permalink / raw)
To: Mukesh R, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <ff4c58f1-564d-ddfa-bdff-48ffee6e0d72@linux.microsoft.com>
From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>
> On 9/2/25 07:42, Michael Kelley wrote:
> > From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
> >>
> >> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
> >> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
> >> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
> >> built if CONFIG_HYPER is set, either loadable or builtin.
> >>
> >> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
> >> encompasses builtin code and various other things and not a dedicated config
> >> option for VMBUS. Vmbus should really have a config option just like
> >> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
> >> to build VMBUS driver and make that distinction explicit. With that
> >> CONFIG_HYPERV could be changed to bool.
> >
> > Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
> > support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
> > is already mostly in separate source files code, though there's some
> > entanglement in the handling of VMBus interrupts, which could be
> > improved later.
> >
> > However, I have a compatibility concern. Consider this scenario:
> >
> > 1) Assume running in a Hyper-V VM with a current Linux kernel version
> > built with CONFIG_HYPERV=m.
> > 2) Grab a new version of kernel source code that contains this patch set.
> > 3) Run 'make olddefconfig' to create the .config file for the new kernel.
> > 4) Build the new kernel. This succeeds.
> > 5) Install and run the new kernel in the Hyper-V VM. This fails.
> >
> > The failure occurs because CONFIG_HYPERV=m is no longer legal,
> > so the .config file created in Step 3 has CONFIG_HYPERV=n. The
> > newly built kernel has no Hyper-V support and won't run in a
> > Hyper-V VM.
> >
> > As a second issue, if in Step 1 the current kernel was built with
> > CONFIG_HYPERV=y, then the .config file for the new kernel will have
> > CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
> > defaults to 'n', so the new kernel doesn't have any VMBus drivers
> > and won't run in a typical Hyper-V VM.
> >
> > The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
> > a default value, such as whatever CONFIG_HYPERV is set to. But
> > I'm not sure how to fix the first issue, except by continuing to
> > allow CONFIG_HYPERV=m.
>
> To certain extent, imo, users are expected to check config files
> for changes when moving to new versions/releases, so it would be a
> one time burden.
I'm not so sanguine about the impact. For those of us who work with
Hyper-V frequently, yes, it's probably not that big of an issue -- we can
figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
the details of how the Kconfig files are put together. And the issue occurs
with no error messages that something has gone wrong in building
the kernel, except that it won't boot. Just running "make olddefconfig"
has worked in the past, so some users will be befuddled and end up
generating Azure support incidents. I also wonder about breaking
automated test suites for new kernels, as they are likely to be running
"make olddefconfig" or something similar as part of the automation.
> CONFIG_HYPERV=m is just broken imo as one sees that
> in .config but magically symbols in drivers/hv are in kerenel.
>
I agree that's not ideal. But note that some Hyper-V code and symbols
like ms_hyperv_init_platform() and related functions show up when
CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
is one of the recognized and somewhat hardwired hypervisors (like
VMware, for example).
Finally, there are about a dozen other places in the kernel that use
the same Makefile construct to make some code built-in even though
the CONFIG option is set to "m". That may not be enough occurrences
to make it standard practice, but Hyper-V guests are certainly not the
only case.
In my mind, this is judgment call with no absolute right answer. What
do others think about the tradeoffs?
Michael
^ permalink raw reply
* Re: [PATCH] Input: i8042 - add TUXEDO InfinityBook Pro Gen10 AMD to i8042 quirk table
From: Dmitry Torokhov @ 2025-09-04 14:38 UTC (permalink / raw)
To: Werner Sembach; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <20250826142646.13516-1-wse@tuxedocomputers.com>
On Tue, Aug 26, 2025 at 04:26:06PM +0200, Werner Sembach wrote:
> From: Christoffer Sandberg <cs@tuxedo.de>
>
> Occasionally wakes up from suspend with missing input on the internal
> keyboard. Setting the quirks appears to fix the issue for this device as
> well.
>
> Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Cc: stable@vger.kernel.org
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: imagis: add missing minItems
From: Dmitry Torokhov @ 2025-09-04 14:33 UTC (permalink / raw)
To: Conor Dooley
Cc: Duje Mihanović, Markuss Broks, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Karel Balej, David Wronek,
phone-devel, ~postmarketos/upstreaming, linux-input, devicetree,
linux-kernel
In-Reply-To: <20250826-yippee-tamper-5439f104769b@spud>
On Tue, Aug 26, 2025 at 06:38:05PM +0100, Conor Dooley wrote:
> On Mon, Aug 25, 2025 at 08:57:57PM +0200, Duje Mihanović wrote:
> > On Monday, 25 August 2025 18:42:38 Central European Summer Time Conor Dooley wrote:
> > > On Sun, Aug 24, 2025 at 06:12:05PM +0200, Duje Mihanović wrote:
> > > > The binding currently expects exactly 5 keycodes, which matches the
> > > > chip's theoretical maximum but probably not the number of touch keys on
> > > > any phone using the IST3032C. Add a minItems value of 2 to prevent
> > > > dt-validate complaints.
> > >
> > > Does this mean that there are devicetrees in the wild that use < 5
> > > keycodes?
> >
> > Indeed.
>
> oke, Acked-by: Conor Dooley <conor.dooley@microchip.com>
Applied, thank you.
--
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