* [PATCH v6 6/7] pinctrl: mediatek: mt6397: Add MediaTek MT6392
From: Luca Leonardo Scorcia @ 2026-06-12 20:04 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Louis-Alexis Eyraud, Julien Massot, Val Packett,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260612200717.361018-1-l.scorcia@gmail.com>
Add support for the MT6392 pinctrl device, which is very similar to
MT6397 with a handful of different property values and its own pins
definition.
Update the MT6397 driver to retrieve device data from the match table and
use it for driver init.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/pinctrl/mediatek/pinctrl-mt6397.c | 37 ++++++++++-
drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h | 64 +++++++++++++++++++
2 files changed, 99 insertions(+), 2 deletions(-)
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6397.c b/drivers/pinctrl/mediatek/pinctrl-mt6397.c
index 03d0f65d7bcc..8ba02e70595c 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6397.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6397.c
@@ -12,10 +12,32 @@
#include <linux/mfd/mt6397/core.h>
#include "pinctrl-mtk-common.h"
+#include "pinctrl-mtk-mt6392.h"
#include "pinctrl-mtk-mt6397.h"
#define MT6397_PIN_REG_BASE 0xc000
+static const struct mtk_pinctrl_devdata mt6392_pinctrl_data = {
+ .pins = mtk_pins_mt6392,
+ .npins = ARRAY_SIZE(mtk_pins_mt6392),
+ .dir_offset = (MT6397_PIN_REG_BASE + 0x000),
+ .ies_offset = MTK_PINCTRL_NOT_SUPPORT,
+ .smt_offset = MTK_PINCTRL_NOT_SUPPORT,
+ .pullen_offset = (MT6397_PIN_REG_BASE + 0x020),
+ .pullsel_offset = (MT6397_PIN_REG_BASE + 0x040),
+ .dout_offset = (MT6397_PIN_REG_BASE + 0x080),
+ .din_offset = (MT6397_PIN_REG_BASE + 0x0a0),
+ .pinmux_offset = (MT6397_PIN_REG_BASE + 0x0c0),
+ .type1_start = 7,
+ .type1_end = 7,
+ .port_shf = 3,
+ .port_mask = 0x3,
+ .port_align = 2,
+ .mode_mask = 0xf,
+ .mode_per_reg = 5,
+ .mode_shf = 4,
+};
+
static const struct mtk_pinctrl_devdata mt6397_pinctrl_data = {
.pins = mtk_pins_mt6397,
.npins = ARRAY_SIZE(mtk_pins_mt6397),
@@ -40,13 +62,24 @@ static const struct mtk_pinctrl_devdata mt6397_pinctrl_data = {
static int mt6397_pinctrl_probe(struct platform_device *pdev)
{
struct mt6397_chip *mt6397;
+ const struct mtk_pinctrl_devdata *data;
+
+ data = device_get_match_data(&pdev->dev);
+ if (!data)
+ return -ENOENT;
mt6397 = dev_get_drvdata(pdev->dev.parent);
- return mtk_pctrl_init(pdev, &mt6397_pinctrl_data, mt6397->regmap);
+ return mtk_pctrl_init(pdev, data, mt6397->regmap);
}
static const struct of_device_id mt6397_pctrl_match[] = {
- { .compatible = "mediatek,mt6397-pinctrl", },
+ {
+ .compatible = "mediatek,mt6392-pinctrl",
+ .data = &mt6392_pinctrl_data
+ }, {
+ .compatible = "mediatek,mt6397-pinctrl",
+ .data = &mt6397_pinctrl_data
+ },
{ }
};
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h b/drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h
new file mode 100644
index 000000000000..e7241af28fdb
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PINCTRL_MTK_MT6392_H
+#define __PINCTRL_MTK_MT6392_H
+
+#include <linux/pinctrl/pinctrl.h>
+#include "pinctrl-mtk-common.h"
+
+static const struct mtk_desc_pin mtk_pins_mt6392[] = {
+ MTK_PIN(PINCTRL_PIN(0, "INT"),
+ NULL, "mt6392",
+ MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+ MTK_FUNCTION(0, "GPIO0"),
+ MTK_FUNCTION(1, "INT"),
+ MTK_FUNCTION(5, "TEST_CK2"),
+ MTK_FUNCTION(6, "TEST_IN1"),
+ MTK_FUNCTION(7, "TEST_OUT1")
+ ),
+ MTK_PIN(PINCTRL_PIN(1, "SRCLKEN"),
+ NULL, "mt6392",
+ MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+ MTK_FUNCTION(0, "GPIO1"),
+ MTK_FUNCTION(1, "SRCLKEN"),
+ MTK_FUNCTION(5, "TEST_CK0"),
+ MTK_FUNCTION(6, "TEST_IN2"),
+ MTK_FUNCTION(7, "TEST_OUT2")
+ ),
+ MTK_PIN(PINCTRL_PIN(2, "RTC_32K1V8"),
+ NULL, "mt6392",
+ MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+ MTK_FUNCTION(0, "GPIO2"),
+ MTK_FUNCTION(1, "RTC_32K1V8"),
+ MTK_FUNCTION(5, "TEST_CK1"),
+ MTK_FUNCTION(6, "TEST_IN3"),
+ MTK_FUNCTION(7, "TEST_OUT3")
+ ),
+ MTK_PIN(PINCTRL_PIN(3, "SPI_CLK"),
+ NULL, "mt6392",
+ MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+ MTK_FUNCTION(0, "GPIO3"),
+ MTK_FUNCTION(1, "SPI_CLK")
+ ),
+ MTK_PIN(PINCTRL_PIN(4, "SPI_CSN"),
+ NULL, "mt6392",
+ MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+ MTK_FUNCTION(0, "GPIO4"),
+ MTK_FUNCTION(1, "SPI_CSN")
+ ),
+ MTK_PIN(PINCTRL_PIN(5, "SPI_MOSI"),
+ NULL, "mt6392",
+ MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+ MTK_FUNCTION(0, "GPIO5"),
+ MTK_FUNCTION(1, "SPI_MOSI")
+ ),
+ MTK_PIN(PINCTRL_PIN(6, "SPI_MISO"),
+ NULL, "mt6392",
+ MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+ MTK_FUNCTION(0, "GPIO6"),
+ MTK_FUNCTION(1, "SPI_MISO"),
+ MTK_FUNCTION(6, "TEST_IN4"),
+ MTK_FUNCTION(7, "TEST_OUT4")
+ ),
+};
+
+#endif /* __PINCTRL_MTK_MT6392_H */
--
2.43.0
^ permalink raw reply related
* [PATCH v6 7/7] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Luca Leonardo Scorcia @ 2026-06-12 20:04 UTC (permalink / raw)
To: linux-mediatek
Cc: Val Packett, Luca Leonardo Scorcia, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Louis-Alexis Eyraud,
Julien Massot, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260612200717.361018-1-l.scorcia@gmail.com>
From: Val Packett <val@packett.cool>
Add the dts to be included by all boards using the MT6392 PMIC,
providing support for keys, pinctrl and RTC.
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
arch/arm64/boot/dts/mediatek/mt6392.dtsi | 41 ++++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
new file mode 100644
index 000000000000..b8d943e47816
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Copyright (c) 2024 Val Packett <val@packett.cool>
+ */
+
+#include <dt-bindings/input/input.h>
+
+&pwrap {
+ pmic: pmic {
+ compatible = "mediatek,mt6392", "mediatek,mt6323";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ mt6392keys: keys {
+ compatible = "mediatek,mt6392-keys";
+
+ key-power {
+ linux,keycodes = <KEY_POWER>;
+ wakeup-source;
+ };
+
+ key-home {
+ linux,keycodes = <KEY_HOME>;
+ wakeup-source;
+ };
+ };
+
+ mt6392pio: pinctrl {
+ compatible = "mediatek,mt6392-pinctrl";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ mt6392rtc: rtc {
+ compatible = "mediatek,mt6392-rtc",
+ "mediatek,mt6323-rtc";
+ };
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 1/7] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: sashiko-bot @ 2026-06-12 20:37 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: devicetree, linux-input, conor+dt, dmitry.torokhov, robh
In-Reply-To: <20260612200717.361018-2-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The dt-bindings schema for the MT6392 PMIC omits the 'mediatek,mt6392-regulator' compatible string for the 'regulators' child node. Since the 'regulators' node is unconditionally marked as required in the schema, any complete device tree correctly describing the MT6392 hardware must include it. Omitting the MT6392-specific regulator compatible string from the schema forces DT authors to either write incomplete DTs (which fail validation because the node is required) or use incorrect/generic compatible strings, causing schema validation failures when they attempt to properly describe the hardware with 'mediatek,mt6392-regulator'.
--
commit a20444c8e4c98a81558d6d5c619b650c00235e18
Author: Fabien Parent <parent.f@gmail.com>
dt-bindings: mfd: mt6397: Add MT6392 PMIC
Add the initial bindings for the MT6392 PMIC and its RTC device.
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> index 3cbc0dc12c319..e39e81aa99249 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
[ ... ]
> @@ -72,6 +76,10 @@ properties:
> - mediatek,mt6331-rtc
> - mediatek,mt6358-rtc
> - mediatek,mt6397-rtc
> + - items:
> + - enum:
> + - mediatek,mt6392-rtc
> + - const: mediatek,mt6323-rtc
[Severity: Medium]
Should the mediatek,mt6392-regulator compatible string be added to the
regulators child node as well?
Since the regulators node is unconditionally marked as required in the schema,
any complete device tree describing the MT6392 hardware must include it.
Does this missing string cause a regression where DT authors are forced to
either write incomplete DTs (which fail validation) or use incorrect compatible
strings?
This causes schema validation failures when authors attempt to properly describe
the hardware with mediatek,mt6392-regulator:
Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml:
regulators:
...
properties:
compatible:
oneOf:
- enum:
- mediatek,mt6323-regulator
- mediatek,mt6328-regulator
...
> - items:
> - enum:
> - mediatek,mt6359-rtc
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612200717.361018-1-l.scorcia@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v6 5/7] input: keyboard: mtk-pmic-keys: Add MT6392 support
From: sashiko-bot @ 2026-06-12 20:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-input, dmitry.torokhov, conor+dt, robh, devicetree
In-Reply-To: <20260612200717.361018-6-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds array access and incorrect parsing of disabled DT nodes in `mtk_pmic_keys_probe` due to a mismatch between child counting and iteration macros.
- [High] `mt6357_regs` incorrectly uses `MTK_PMIC_HOMEKEY_INDEX` instead of `MTK_PMIC_HOMEKEY_RST` for the home key reset mask.
--
commit 2b2bdf18b713288536d3d56d4b82a48e65594233
Author: Val Packett <val@packett.cool>
input: keyboard: mtk-pmic-keys: Add MT6392 support
This commit adds support for the MT6392 PMIC to the mediatek pmic keys driver
by defining its specific register layout and adding the required compatible
string.
> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
> index c78d9f6d97c4f..8b4a89fce4fb1 100644
> --- a/drivers/input/keyboard/mtk-pmic-keys.c
> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
[ ... ]
> @@ -69,6 +70,19 @@ static const struct mtk_pmic_regs mt6397_regs = {
> .rst_lprst_mask = MTK_PMIC_RST_DU_MASK,
> };
>
> +static const struct mtk_pmic_regs mt6392_regs = {
> + .keys_regs[MTK_PMIC_PWRKEY_INDEX] =
> + MTK_PMIC_KEYS_REGS(MT6392_CHRSTATUS, 0x2,
> + MT6392_INT_MISC_CON, 0x10,
> + MTK_PMIC_PWRKEY_RST),
> + .keys_regs[MTK_PMIC_HOMEKEY_INDEX] =
> + MTK_PMIC_KEYS_REGS(MT6392_CHRSTATUS, 0x4,
> + MT6392_INT_MISC_CON, 0x8,
> + MTK_PMIC_HOMEKEY_RST),
> + .pmic_rst_reg = MT6392_TOP_RST_MISC,
> + .rst_lprst_mask = MTK_PMIC_RST_DU_MASK,
> +};
> +
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential
out-of-bounds access in mtk_pmic_keys_probe() due to a mismatch in child node
parsing:
drivers/input/keyboard/mtk-pmic-keys.c:mtk_pmic_keys_probe() {
...
keycount = of_get_available_child_count(node);
if (keycount > MTK_PMIC_MAX_KEY_COUNT) {
dev_err(dev, "too many keys defined (%d)\n", keycount);
return -EINVAL;
}
for_each_child_of_node_scoped(node, child) {
keys->keys[index].regs = &keys->mtk_regs->keys_regs[index];
...
}
The check uses of_get_available_child_count(), which skips nodes with
status="disabled", but the loop uses for_each_child_of_node_scoped(), which
iterates over all child nodes regardless of their availability.
If a device tree defines more than MTK_PMIC_MAX_KEY_COUNT nodes but disables
enough to pass the initial check, could the loop execute more than
MTK_PMIC_MAX_KEY_COUNT times? Would this cause an out-of-bounds array access
on the keys->keys[] and irqnames[] arrays?
[Severity: High]
This is a pre-existing issue as well, but looking at the existing register
definitions, mt6357_regs appears to use the wrong macro for the home key
reset mask:
drivers/input/keyboard/mtk-pmic-keys.c:
static const struct mtk_pmic_regs mt6357_regs = {
.keys_regs[MTK_PMIC_PWRKEY_INDEX] =
MTK_PMIC_KEYS_REGS(MT6357_TOPSTATUS,
0x2, MT6357_INT_MISC_CON, 0x10, MTK_PMIC_PWRKEY_RST),
.keys_regs[MTK_PMIC_HOMEKEY_INDEX] =
MTK_PMIC_KEYS_REGS(MT6357_TOPSTATUS,
0x8, MT6357_INT_MISC_CON, 0x8, MTK_PMIC_HOMEKEY_INDEX),
...
};
Does this incorrectly use MTK_PMIC_HOMEKEY_INDEX instead of
MTK_PMIC_HOMEKEY_RST?
Because MTK_PMIC_HOMEKEY_INDEX is just an array index, would this result in
modifying the wrong bits in the reset register during
mtk_pmic_keys_lp_reset_setup() and failing to properly enable the long-press
hardware reset for the home key on MT6357?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612200717.361018-1-l.scorcia@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v6 4/7] mfd: mt6397: Add support for MT6392 PMIC
From: sashiko-bot @ 2026-06-12 20:44 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-input, dmitry.torokhov, robh, conor+dt, devicetree
In-Reply-To: <20260612200717.361018-5-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The PM notifier `chip->pm_nb` and the unmanaged `irq_domain` are leaked on probe failure and driver unbind, leading to a Use-After-Free during system suspend/resume.
--
commit 7e58614b47c19c51b0d112cc3708ab6bf5ecdc5a
Author: Fabien Parent <parent.f@gmail.com>
mfd: mt6397: Add support for MT6392 PMIC
Align the MT6397 PMIC driver to other MFD drivers by passing only an
identifier through mt6397_of_match[*].data and add support for the MT6392
PMIC and its RTC, keys and pinctrl devices.
> diff --git a/drivers/mfd/mt6397-irq.c b/drivers/mfd/mt6397-irq.c
> index 5d2e5459f7444..80ea5b92d232f 100644
> --- a/drivers/mfd/mt6397-irq.c
> +++ b/drivers/mfd/mt6397-irq.c
> @@ -203,6 +205,12 @@ int mt6397_irq_init(struct mt6397_chip *chip)
> chip->int_status[0] = MT6397_INT_STATUS0;
> chip->int_status[1] = MT6397_INT_STATUS1;
> break;
> + case MT6392_CHIP_ID:
> + chip->int_con[0] = MT6392_INT_CON0;
> + chip->int_con[1] = MT6392_INT_CON1;
> + chip->int_status[0] = MT6392_INT_STATUS0;
> + chip->int_status[1] = MT6392_INT_STATUS1;
> + break;
>
> default:
> dev_err(chip->dev, "unsupported chip: 0x%x\n", chip->chip_id);
[Severity: High]
This is a pre-existing issue, but I noticed a potential memory safety
problem involving the initialization in mt6397_irq_init() and the probe
error path in mt6397_probe().
Later in mt6397_irq_init(), we call:
register_pm_notifier(&chip->pm_nb);
However, there doesn't seem to be a corresponding unregister_pm_notifier()
anywhere in the driver, nor a .remove callback in mt6397_driver.
If devm_mfd_add_devices() fails in mt6397_probe(), the devres mechanism
will free the mt6397_chip structure (pmic). Since the pm_nb remains
linked in the global pm_chain_head list, wouldn't a subsequent
suspend/resume event dereference the freed memory and cause a
use-after-free panic?
Additionally, could this also leak the irq_domain (created with
irq_domain_create_linear) if the driver is unbound via sysfs?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612200717.361018-1-l.scorcia@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH] HID: hidpp: fix potential UAF in hidpp_connect_event()
From: Jiri Kosina @ 2026-06-12 21:30 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Dmitry Torokhov, linux-input, Benjamin Tissoires
In-Reply-To: <20260612160404.1E45A1F00ACA@smtp.kernel.org>
On Fri, 12 Jun 2026, sashiko-bot@kernel.org wrote:
> Because hidpp_connect_event() runs asynchronously in a workqueue, incoming
> HID reports can be processed concurrently by hidpp_raw_event() in
> interrupt context.
This is good point. I will send a v2.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] Input: tsc2007 - Read "ti,poll-period" as u32
From: Rob Herring (Arm) @ 2026-06-12 21:50 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
The "ti,poll-period" property is documented as a normal uint32 cell.
The driver used a u64 helper, which makes the helper type disagree with
the schema even though the stored value is still small.
Read "ti,poll-period" with the u32 helper matching the documented DT
cell size.
Assisted-by: Codex:gpt-5-5
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
drivers/input/touchscreen/tsc2007_core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2007_core.c b/drivers/input/touchscreen/tsc2007_core.c
index 524f14eb3da2..db18b712999d 100644
--- a/drivers/input/touchscreen/tsc2007_core.c
+++ b/drivers/input/touchscreen/tsc2007_core.c
@@ -224,7 +224,6 @@ static int tsc2007_get_pendown_state_gpio(struct device *dev)
static int tsc2007_probe_properties(struct device *dev, struct tsc2007 *ts)
{
u32 val32;
- u64 val64;
if (!device_property_read_u32(dev, "ti,max-rt", &val32))
ts->max_rt = val32;
@@ -240,8 +239,8 @@ static int tsc2007_probe_properties(struct device *dev, struct tsc2007 *ts)
if (!device_property_read_u32(dev, "ti,fuzzz", &val32))
ts->fuzzz = val32;
- if (!device_property_read_u64(dev, "ti,poll-period", &val64))
- ts->poll_period = msecs_to_jiffies(val64);
+ if (!device_property_read_u32(dev, "ti,poll-period", &val32))
+ ts->poll_period = msecs_to_jiffies(val32);
else
ts->poll_period = msecs_to_jiffies(1);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] Input: tsc2007 - Read "ti,poll-period" as u32
From: sashiko-bot @ 2026-06-12 21:58 UTC (permalink / raw)
Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260612215033.1885245-1-robh@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] A 'ti,poll-period' value of 0 causes an infinite polling loop in tsc2007_soft_irq().
--
commit dfcc8705b785de318165f57112a4d5c957e4ec74
Author: Rob Herring (Arm) <robh@kernel.org>
Input: tsc2007 - Read "ti,poll-period" as u32
The "ti,poll-period" property is documented as a normal uint32 cell.
The driver used a u64 helper, which makes the helper type disagree with
the schema even though the stored value is still small.
Read "ti,poll-period" with the u32 helper matching the documented DT
cell size.
> diff --git a/drivers/input/touchscreen/tsc2007_core.c b/drivers/input/touchscreen/tsc2007_core.c
> --- a/drivers/input/touchscreen/tsc2007_core.c
> +++ b/drivers/input/touchscreen/tsc2007_core.c
[ ... ]
> @@ -238,8 +237,8 @@ static int tsc2007_probe_properties(struct device *dev, struct tsc2007 *ts)
> if (!device_property_read_u32(dev, "ti,fuzzz", &val32))
> ts->fuzzz = val32;
>
> - if (!device_property_read_u64(dev, "ti,poll-period", &val64))
> - ts->poll_period = msecs_to_jiffies(val64);
> + if (!device_property_read_u32(dev, "ti,poll-period", &val32))
> + ts->poll_period = msecs_to_jiffies(val32);
[Severity: High]
Does this change unintentionally allow ts->poll_period to become 0, leading to
an infinite loop in tsc2007_soft_irq()?
Previously, if a 32-bit zero value was provided in the device tree,
device_property_read_u64() would fail due to a length mismatch, triggering
the fallback to a safe 1 jiffy (ts->poll_period = msecs_to_jiffies(1)).
With this fix, a 32-bit zero is successfully parsed, setting
ts->poll_period = 0.
If ts->poll_period is 0, wait_event_timeout(ts->wait, ts->stopped,
ts->poll_period) in tsc2007_soft_irq() evaluates the timeout as 0 and returns
immediately without sleeping. This results in the thread spinning in a tight
loop as long as the touchscreen is pressed.
Should we sanitize a 0 value here so it defaults to 1?
> else
> ts->poll_period = msecs_to_jiffies(1);
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612215033.1885245-1-robh@kernel.org?part=1
^ permalink raw reply
* Re: [PATCH v6 1/7] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
From: Rob Herring @ 2026-06-12 22:07 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251215-macsmc-subdevs-v6-1-0518cb5f28ae@gmail.com>
On Mon, Dec 15, 2025 at 07:37:45PM +1000, James Calligeros wrote:
> Apple Silicon devices integrate a vast array of sensors, monitoring
> current, power, temperature, and voltage across almost every part of
> the system. The sensors themselves are all connected to the System
> Management Controller (SMC). The SMC firmware exposes the data
> reported by these sensors via its standard FourCC-based key-value
> API. The SMC is also responsible for monitoring and controlling any
> fans connected to the system, exposing them in the same way.
>
> For reasons known only to Apple, each device exposes its sensors with
> an almost totally unique set of keys. This is true even for devices
> which share an SoC. An M1 Mac mini, for example, will report its core
> temperatures on different keys to an M1 MacBook Pro. Worse still, the
> SMC does not provide a way to enumerate the available keys at runtime,
> nor do the keys follow any sort of reasonable or consistent naming
> rules that could be used to deduce their purpose. We must therefore
> know which keys are present on any given device, and which function
> they serve, ahead of time.
>
> Add a schema so that we can describe the available sensors for a given
> Apple Silicon device in the Devicetree.
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> .../bindings/hwmon/apple,smc-hwmon.yaml | 86 +++++++++++++++++++++++++
> .../bindings/mfd/apple,smc.yaml | 36 +++++++++++
> MAINTAINERS | 1 +
> 3 files changed, 123 insertions(+)
I fixed up the error and applied. Please ensure all your patches get
applied.
Rob
^ permalink raw reply
* Re: [PATCH v2 3/4] HID: asus: add support for xgm led
From: Antheas Kapenekakis @ 2026-06-13 0:30 UTC (permalink / raw)
To: Denis Benato
Cc: Denis Benato, linux-kernel, linux-input, Benjamin Tissoires,
Jiri Kosina, Luke D . Jones, Mateusz Schyboll
In-Reply-To: <f4d34bd2-c7aa-43da-a3f3-a9dafe82af66@gmail.com>
On Fri, 12 Jun 2026 at 17:56, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 6/12/26 16:39, Antheas Kapenekakis wrote:
> > On Fri, 12 Jun 2026 at 16:23, Denis Benato <denis.benato@linux.dev> wrote:
> >> XG mobile stations have very bright leds behind the fan that can be
> >> turned either ON or OFF: add a cled interface to allow controlling the
> >> brightness of those red leds.
> >>
> >> Signed-off-by: Denis Benato <denis.benato@linux.dev>
> >> ---
> >> drivers/hid/hid-asus.c | 70 ++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 70 insertions(+)
> >>
> >> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> >> index 323dc0b7f3ff..21c4a60d224e 100644
> >> --- a/drivers/hid/hid-asus.c
> >> +++ b/drivers/hid/hid-asus.c
> >> @@ -51,6 +51,8 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> >> #define FEATURE_KBD_LED_REPORT_ID1 0x5d
> >> #define FEATURE_KBD_LED_REPORT_ID2 0x5e
> >>
> >> +#define ROG_XGM_REPORT_SIZE 300
> >> +
> >> #define ROG_ALLY_REPORT_SIZE 64
> >> #define ROG_ALLY_X_MIN_MCU 313
> >> #define ROG_ALLY_MIN_MCU 319
> >> @@ -118,6 +120,11 @@ struct asus_kbd_leds {
> >> bool removed;
> >> };
> >>
> >> +struct asus_xgm_led {
> >> + struct led_classdev cdev;
> >> + struct hid_device *hdev;
> >> +};
> >> +
> >> struct asus_touchpad_info {
> >> int max_x;
> >> int max_y;
> >> @@ -143,6 +150,7 @@ struct asus_drvdata {
> >> unsigned long battery_next_query;
> >> struct work_struct fn_lock_sync_work;
> >> bool fn_lock;
> >> + struct asus_xgm_led *xgm_led;
> >> };
> >>
> >> static int asus_report_battery(struct asus_drvdata *, u8 *, int);
> >> @@ -941,6 +949,23 @@ static int asus_battery_probe(struct hid_device *hdev)
> >> return ret;
> >> }
> >>
> >> +static int asus_xgm_led_set(struct led_classdev *led_cdev, enum led_brightness value)
> >> +{
> >> + const u8 buf[ROG_XGM_REPORT_SIZE] = {
> >> + FEATURE_KBD_LED_REPORT_ID2, 0xC5, (value) ? 0x50 : 0x00
> >> + };
> >> + struct asus_xgm_led *xgm = container_of(led_cdev, struct asus_xgm_led, cdev);
> >> + int ret;
> >> +
> >> + ret = asus_kbd_set_report(xgm->hdev, buf, ROG_XGM_REPORT_SIZE);
> >> + if (ret != ROG_XGM_REPORT_SIZE) {
> >> + hid_err(xgm->hdev, "Unable to set XG mobile led state: %d\n", ret);
> >> + return ret;
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
> >> {
> >> struct input_dev *input = hi->input;
> >> @@ -1184,6 +1209,14 @@ static int __maybe_unused asus_resume(struct hid_device *hdev)
I might have confused the hunk here and you are right, input
configured is above.
> >> }
> >> }
> >>
> >> + if (drvdata->xgm_led) {
> >> + ret = asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
> >> + if (ret) {
> >> + hid_err(hdev, "Asus failed to restore xgm brightness: %d\n", ret);
> >> + goto asus_resume_err;
> >> + }
> >> + }
> >> +
> >> asus_resume_err:
> >> return ret;
> >> }
> >> @@ -1310,6 +1343,40 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> >> }
> >> }
> >>
> >> + if (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID) &&
> >> + ((hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2022) ||
> >> + (hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2023))) {
> >> + drvdata->xgm_led = devm_kzalloc(&hdev->dev, sizeof(*drvdata->xgm_led), GFP_KERNEL);
> >> + if (drvdata->xgm_led == NULL) {
> >> + ret = -ENOMEM;
> >> + goto err_stop_hw;
> >> + }
> >> + drvdata->xgm_led->hdev = hdev;
> >> + drvdata->xgm_led->cdev.name = devm_kasprintf(&hdev->dev, GFP_KERNEL,
> >> + "asus:xgm-%s:led",
> >> + strlen(hdev->uniq) ?
> >> + hdev->uniq : dev_name(&hdev->dev));
> >> + drvdata->xgm_led->cdev.brightness = 1;
> >> + drvdata->xgm_led->cdev.max_brightness = 1;
> >> + drvdata->xgm_led->cdev.brightness_set_blocking = asus_xgm_led_set;
> >> +
> >> + /*
> >> + * Sometimes after a reboot LEDs are ON, sometimes are OFF: set them to
> >> + * what the default brightness resets when doing a cold boot.
> >> + */
> > I think this is set by the driver, so you should reformat the comment
> > above, so you should trim the comment.
> >
> > Perhaps, "The LED state is arbitrary on boot, therefore default to the
> > initial brightness set above". This way it does not become outdated if
> > cdev.brightness changes.
> yeah better spelling. I agree.
> >> + ret = asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
> >> + if (ret) {
> >> + hid_err(hdev, "Asus failed to set xgm led: %d\n", ret);
> >> + goto err_stop_hw;
> >> + }
> > You already do this in asus_input_configured so you do it twice?
> > Perhaps skip one if you end up keeping them? I think that it's better
> > to keep this block.
> In asus_input_configured? Will take a look in the next days. I tought
> the other was in asus_resume since at resume they resets back...
> > Or even better return an error in _get so that on boot it is
> > ambiguous? I assume the leds remain to the state they had prior to the
> > reboot? With this change, imagine a user that turned off the leds in
> > windows, permabooted into Linux, and now has the lights always turn on
> > during boot.
> Cold boot sets them to ON, while rebooting keep them at what they were.
>
> After exiting from sleep they are always ON, but this is on an ally,
> I don't know if on an old rog flow it's the same.
> > Moreover, can systemd restore this or is it out of scope for its led
> > handler? Perhaps it is an ambitious idea though, and better skipped.
> I don't see realistic for this to fail if it was successful at probe so it
> shouldn't matter. As for systemd restoring them it would have to
> be informed that they changed (but there is no read-back) so either
> way something has to happen at resume, but doing this means no
> additional software is necessary and user preference is being
> respected regardless of anything else.
Ok, so xg mobile is the first generation gpu dock with the wide
connector, which is why it is i2c. It's probably from the side port.
So, when it initializes in general it enables the leds. And it
initializes on boot and on wake. And it has no memory.
For not setting the led, you could return an error on reads if the
brightness has not been written yet and if it has return a cached
value / restore on awake. You can store the brightness in the struct
below xgm_led, e.g., xgm_led_val, and initialize it to -1. If it is
-1, get would return the same error you did for battery capacity in
asus-wmi
In that case, you would remove the init from probe. Otherwise, the
current patch with a small tweak to the comment if you do a revision
is fine by me
Reviewed by: Antheas Kapenekakis <lkml@antheas.dev>
> >> +
> >> + ret = led_classdev_register(&hdev->dev, &drvdata->xgm_led->cdev);
> >> + if (ret) {
> >> + hid_err(hdev, "Asus failed to register xgm led: %d\n", ret);
> >> + goto err_stop_hw;
> >> + }
> >> + }
> >> +
> >> /* Laptops keyboard backlight is always at 0x5a */
> >> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
> >> (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID)) &&
> >> @@ -1366,6 +1433,9 @@ static void asus_remove(struct hid_device *hdev)
> >> if (drvdata->quirks & QUIRK_HID_FN_LOCK)
> >> cancel_work_sync(&drvdata->fn_lock_sync_work);
> >>
> >> + if (drvdata->xgm_led)
> >> + led_classdev_unregister(&drvdata->xgm_led->cdev);
> >> +
> >> hid_hw_stop(hdev);
> >> }
> >>
> >> --
> >> 2.47.3
> >>
> >>
> Thanks,
> Denis
>
^ permalink raw reply
* [PATCH] Input: goodix - clamp the device-reported contact count
From: Bryam Vargas via B4 Relay @ 2026-06-13 2:10 UTC (permalink / raw)
To: Dmitry Torokhov, Hans de Goede; +Cc: linux-input, linux-kernel
From: Bryam Vargas <hexlabsecurity@proton.me>
goodix_ts_read_input_report() copies the number of touch points reported
by the device into an on-stack buffer
u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];
which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only
runtime check bounds the per-interrupt count against ts->max_touch_num,
but that value is taken verbatim from a 4-bit field of the device
configuration block and is never clamped:
ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f;
The nibble can be 0..15, so a malfunctioning, malicious or counterfeit
controller (or an attacker tampering with the I2C bus) can advertise up
to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num
of up to 15 and the second goodix_i2c_read() writes
ts->contact_size * (touch_num - 1) bytes past the one-contact header into
point_data - up to 30 bytes (45 with the 9-byte report format) beyond the
92-byte buffer: a stack out-of-bounds write.
Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts
point_data[] is sized for, when reading it from the configuration.
Fixes: a7ac7c95d468 ("Input: goodix - use max touch number from device config")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
drivers/input/touchscreen/goodix.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index f8798d11ec03..17fcfe45988c 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -1057,7 +1057,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
}
ts->int_trigger_type = ts->config[TRIGGER_LOC] & 0x03;
- ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f;
+ ts->max_touch_num = min(ts->config[MAX_CONTACTS_LOC] & 0x0f,
+ GOODIX_MAX_CONTACTS);
x_max = get_unaligned_le16(&ts->config[RESOLUTION_LOC]);
y_max = get_unaligned_le16(&ts->config[RESOLUTION_LOC + 2]);
---
base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66
change-id: 20260612-b4-disp-6844625d-463f81173dc6
Best regards,
--
Bryam Vargas <hexlabsecurity@proton.me>
^ permalink raw reply related
* Re: [PATCH] Input: goodix - clamp the device-reported contact count
From: sashiko-bot @ 2026-06-13 2:22 UTC (permalink / raw)
To: Bryam Vargas via B4 Relay; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260612-b4-disp-6844625d-v1-1-df0aed080c9d@proton.me>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unbalanced IRQ teardown and request on suspend/resume leads to kernel panic.
--
commit 67a6ac06922d6e5f9f42f13db85b8ae1bd396b75
Author: Bryam Vargas <hexlabsecurity@proton.me>
Input: goodix - clamp the device-reported contact count
This commit fixes an out-of-bounds stack write when reading the input
report. It clamps the maximum number of touch points reported by the
device configuration to prevent a malicious or malfunctioning controller
from overflowing the on-stack buffer.
> diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
> index f8798d11ec030..17fcfe45988c2 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
[Severity: High]
This isn't a bug introduced by this patch, but looking at the driver's
suspend and resume paths, is there a potential regression regarding null
pointer dereferences if device initialization fails asynchronously?
If asynchronous firmware loading or configuration fails, device
initialization aborts without unbinding the driver. The ts->input_dev
pointer remains uninitialized, and the interrupt is never requested.
During system suspend, goodix_suspend() unconditionally calls
goodix_free_irq(), which invokes devm_free_irq() without checking if the
interrupt was actually requested:
goodix_suspend()->goodix_free_irq():
if (ts->client->irq)
devm_free_irq(&ts->client->dev, ts->client->irq, ts);
This triggers a warning because the managed resource does not exist.
Furthermore, upon system resume, goodix_resume() unconditionally
calls goodix_request_irq():
goodix_resume():
...
error = goodix_request_irq(ts);
if (error)
return error;
This successfully registers the interrupt handler even though the device
is completely uninitialized.
When a subsequent touch event triggers the interrupt,
goodix_process_events() blindly accesses the uninitialized input device:
goodix_process_events():
...
input_mt_sync_frame(ts->input_dev);
Because ts->input_dev is uninitialized, does this dereference cause a
regression during device operation?
Could the suspend and resume functions be updated to verify the device is
fully initialized before tearing down and requesting the interrupt?
> @@ -1057,7 +1057,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
> }
>
> ts->int_trigger_type = ts->config[TRIGGER_LOC] & 0x03;
> - ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f;
> + ts->max_touch_num = min(ts->config[MAX_CONTACTS_LOC] & 0x0f,
> + GOODIX_MAX_CONTACTS);
>
> x_max = get_unaligned_le16(&ts->config[RESOLUTION_LOC]);
> y_max = get_unaligned_le16(&ts->config[RESOLUTION_LOC + 2]);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-b4-disp-6844625d-v1-1-df0aed080c9d@proton.me?part=1
^ permalink raw reply
* [PATCH] Input: mms114 - reject an oversized device packet size
From: Bryam Vargas via B4 Relay @ 2026-06-13 4:21 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-kernel, linux-input, Joonyoung Shim, Kyungmin Park
From: Bryam Vargas <hexlabsecurity@proton.me>
mms114_interrupt() reads a packet of touch data from the device into a
fixed-size on-stack buffer
struct mms114_touch touch[MMS114_MAX_TOUCH];
which holds MMS114_MAX_TOUCH (10) events of MMS114_EVENT_SIZE (8) bytes,
i.e. 80 bytes. The length of the I2C read into it is taken verbatim from
the device:
packet_size = mms114_read_reg(data, MMS114_PACKET_SIZE);
if (packet_size <= 0)
goto out;
...
error = __mms114_read_reg(data, MMS114_INFORMATION, packet_size,
(u8 *)touch);
packet_size is a single device register byte (0x0F) and the only check
is the lower bound packet_size <= 0; it is never bounded against the
size of touch[]. A malfunctioning, malicious or counterfeit controller
(or an attacker tampering with the I2C bus) can report a packet_size of
up to 255, so __mms114_read_reg() writes up to 175 bytes past the end of
touch[] on the IRQ-thread stack: a stack out-of-bounds write that can
overwrite the stack canary, saved registers and the return address.
A well-formed device never reports more than the buffer holds, so reject
an oversized packet and drop the report, consistent with the handler's
other error paths, rather than reading past the buffer.
Fixes: 07b8481d4aff ("Input: add MELFAS mms114 touchscreen driver")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
drivers/input/touchscreen/mms114.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index af462086a65c..4c75f16c503d 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -226,6 +226,13 @@ static irqreturn_t mms114_interrupt(int irq, void *dev_id)
if (packet_size <= 0)
goto out;
+ /* the device controls packet_size; reject anything too big for touch[] */
+ if (packet_size > (int)sizeof(touch)) {
+ dev_err(&client->dev, "Invalid packet size %d (max %zu)\n",
+ packet_size, sizeof(touch));
+ goto out;
+ }
+
/* MMS136 has slightly different event size */
if (data->type == TYPE_MMS134S || data->type == TYPE_MMS136)
touch_size = packet_size / MMS136_EVENT_SIZE;
---
base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66
change-id: 20260612-b4-disp-dc4b8dc4-8e39b9d64247
Best regards,
--
Bryam Vargas <hexlabsecurity@proton.me>
^ permalink raw reply related
* Re: [PATCH] Input: mms114 - reject an oversized device packet size
From: sashiko-bot @ 2026-06-13 4:31 UTC (permalink / raw)
To: Bryam Vargas via B4 Relay; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260612-b4-disp-dc4b8dc4-v1-1-d7cb0a828d92@proton.me>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Stack out-of-bounds read and severe struct misalignment when parsing MMS136/MMS134S touch events, leading to a kernel memory information leak.
--
commit 2622e1ec203d4e3a475cf8bb039715b16ecc29d8
Author: Bryam Vargas <hexlabsecurity@proton.me>
Input: mms114 - reject an oversized device packet size
This commit adds a bounds check to reject packet sizes from the device that
exceed the size of the local touch array. This prevents a stack out-of-bounds
write caused by a malfunctioning or malicious device.
Cc: stable@vger.kernel.org
> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
> index af462086a65ca..4c75f16c503dc 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
> @@ -226,6 +226,13 @@ static irqreturn_t mms114_interrupt(int irq, void *dev_id)
> if (packet_size <= 0)
> goto out;
>
> + /* the device controls packet_size; reject anything too big for touch[] */
> + if (packet_size > (int)sizeof(touch)) {
> + dev_err(&client->dev, "Invalid packet size %d (max %zu)\n",
> + packet_size, sizeof(touch));
> + goto out;
> + }
> +
> /* MMS136 has slightly different event size */
> if (data->type == TYPE_MMS134S || data->type == TYPE_MMS136)
> touch_size = packet_size / MMS136_EVENT_SIZE;
[Severity: High]
This is a pre-existing issue, but does this calculation cause an out-of-bounds
read and structure misalignment later in the function?
If packet_size is up to 80 (the maximum allowed by the newly added bounds
check), touch_size for MMS136 and MMS134S devices will be 80 / 6 = 13.
In the loop further down in mms114_interrupt():
for (index = 0; index < touch_size; index++) {
switch (touch[index].type) {
When index reaches 12, touch[12] reads 8 bytes starting from offset 96,
because sizeof(struct mms114_touch) is 8 bytes. Since the touch array is only
80 bytes long, wouldn't this read past the end of the stack buffer?
Also, since the hardware sends contiguous 6-byte events but they are iterated
using an 8-byte array step, does this misalign the parsing for every event
after the first one?
This misaligned and out-of-bounds stack data is then processed in
mms114_process_mt(), where touch->width and touch->strength are passed to
input_report_abs(). Could this inadvertently leak uninitialized stack memory to
userspace?
> else
> touch_size = packet_size / MMS114_EVENT_SIZE;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-b4-disp-dc4b8dc4-v1-1-d7cb0a828d92@proton.me?part=1
^ permalink raw reply
* [PATCH] Input: synaptics-rmi4 - bound the SMBus block read to the caller buffer
From: Bryam Vargas via B4 Relay @ 2026-06-13 5:39 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, linux-input, Andrew Duggan, linux-kernel
From: Bryam Vargas <hexlabsecurity@proton.me>
smb_block_read() takes a destination length but passes it nowhere:
static int smb_block_read(struct rmi_transport_dev *xport,
u8 commandcode, void *buf, size_t len)
{
...
retval = i2c_smbus_read_block_data(client, commandcode, buf);
i2c_smbus_read_block_data() has no destination-size argument; it copies
the block count reported by the device (the first SMBus byte, up to
I2C_SMBUS_BLOCK_MAX = 32) into buf. The RMI callers pass buffers far
smaller than 32 bytes - rmi_read_pdt_entry() reads a PDT entry into an
on-stack u8 buf[RMI_PDT_ENTRY_SIZE] (6 bytes) during the PDT scan - so a
malfunctioning, malicious or counterfeit RMI4 SMBus controller (or an
attacker tampering with the I2C bus) that reports a larger block count
overflows the caller's stack buffer by up to 32 - 6 = 26 bytes,
clobbering the stack canary, saved registers and the return address.
Read into a local I2C_SMBUS_BLOCK_MAX-sized buffer and copy back at most
len bytes, so the device can never write past the caller's buffer.
Fixes: 82264d0cf7ae ("Input: synaptics-rmi4 - add SMBus support")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
drivers/input/rmi4/rmi_smbus.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
index f3d0b40721df..ea957aba28f1 100644
--- a/drivers/input/rmi4/rmi_smbus.c
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -177,12 +177,20 @@ static int smb_block_read(struct rmi_transport_dev *xport,
struct rmi_smb_xport *rmi_smb =
container_of(xport, struct rmi_smb_xport, xport);
struct i2c_client *client = rmi_smb->client;
+ u8 data[I2C_SMBUS_BLOCK_MAX];
int retval;
- retval = i2c_smbus_read_block_data(client, commandcode, buf);
+ /*
+ * i2c_smbus_read_block_data() copies the device-reported block count
+ * (up to I2C_SMBUS_BLOCK_MAX) into the destination and has no way to
+ * know its size, so read into a local buffer and copy back at most
+ * len bytes - never past the caller's buffer.
+ */
+ retval = i2c_smbus_read_block_data(client, commandcode, data);
if (retval < 0)
return retval;
+ memcpy(buf, data, min_t(size_t, retval, len));
return retval;
}
---
base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66
change-id: 20260613-b4-disp-2e033955-ffe3889ce3e9
Best regards,
--
Bryam Vargas <hexlabsecurity@proton.me>
^ permalink raw reply related
* Re: [PATCH] Input: synaptics-rmi4 - bound the SMBus block read to the caller buffer
From: sashiko-bot @ 2026-06-13 5:51 UTC (permalink / raw)
To: Bryam Vargas via B4 Relay; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260613-b4-disp-2e033955-v1-1-43ab7281667a@proton.me>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds read and information leak in `rmi_smb_write_block`.
--
commit d7c26cbb5c7a78f15621da67eb9707ffe6750b59
Author: Bryam Vargas <hexlabsecurity@proton.me>
Input: synaptics-rmi4 - bound the SMBus block read to the caller buffer
This commit fixes a stack overflow in smb_block_read by reading into a local
buffer first. It then copies back at most len bytes to ensure the device
never writes past the caller's buffer.
> diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
> index f3d0b40721df0..ea957aba28f17 100644
> --- a/drivers/input/rmi4/rmi_smbus.c
> +++ b/drivers/input/rmi4/rmi_smbus.c
> @@ -177,12 +177,20 @@ static int smb_block_read(struct rmi_transport_dev *xport,
> struct rmi_smb_xport *rmi_smb =
> container_of(xport, struct rmi_smb_xport, xport);
> struct i2c_client *client = rmi_smb->client;
> + u8 data[I2C_SMBUS_BLOCK_MAX];
> int retval;
>
> - retval = i2c_smbus_read_block_data(client, commandcode, buf);
> + /*
> + * i2c_smbus_read_block_data() copies the device-reported block count
> + * (up to I2C_SMBUS_BLOCK_MAX) into the destination and has no way to
> + * know its size, so read into a local buffer and copy back at most
> + * len bytes - never past the caller's buffer.
> + */
> + retval = i2c_smbus_read_block_data(client, commandcode, data);
> if (retval < 0)
> return retval;
>
> + memcpy(buf, data, min_t(size_t, retval, len));
> return retval;
> }
[Severity: High]
This isn't a bug introduced by this patch, but while looking at this file,
I noticed a similar size calculation issue in rmi_smb_write_block().
Does this code overflow databuff on the final chunk if len is not a
multiple of 32?
drivers/input/rmi4/rmi_smbus.c:rmi_smb_write_block() {
...
while (cur_len > 0) {
/*
* break into 32 bytes chunks to write get command code
*/
int block_len = min_t(int, len, SMB_MAX_COUNT);
...
retval = smb_block_write(xport, commandcode,
databuff, block_len);
...
cur_len -= SMB_MAX_COUNT;
databuff += SMB_MAX_COUNT;
}
...
}
It appears block_len is calculated using the invariant len parameter instead
of cur_len. If len is greater than 32 but not a multiple of 32 (e.g., 40),
the second iteration will evaluate min(40, 32) = 32 instead of the
remaining 8 bytes.
This would cause smb_block_write() to read 32 bytes from databuff when
only 8 valid bytes remain, leading to an out-of-bounds read.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-b4-disp-2e033955-v1-1-43ab7281667a@proton.me?part=1
^ permalink raw reply
* [PATCH] Input: cyapa - bound the SMBus block reads to the caller buffer
From: Bryam Vargas via B4 Relay @ 2026-06-13 6:12 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Dudley Du, Benson Leung, linux-input, Daniel Kurtz, linux-kernel
From: Bryam Vargas <hexlabsecurity@proton.me>
cyapa_smbus_read_block() takes the expected length of the result but
never uses it to bound the destination:
if (SMBUS_GROUP_BLOCK_CMD_MASK & cmd) {
smbus_cmd = SMBUS_ENCODE_RW(cmd, SMBUS_READ);
ret = i2c_smbus_read_block_data(client, smbus_cmd, values);
goto out;
}
...
buf = values + I2C_SMBUS_BLOCK_MAX * index;
ret = i2c_smbus_read_block_data(client, smbus_cmd, buf);
i2c_smbus_read_block_data() has no destination-size argument; it copies
the block count reported by the device (the first SMBus byte, up to
I2C_SMBUS_BLOCK_MAX = 32) into the buffer. Several callers pass buffers
smaller than 32 bytes - cyapa_detect() reads CYAPA_CMD_BL_STATUS into an
on-stack u8 status[BL_STATUS_SIZE] (3 bytes), and the group-query path
reads into u8 query_data[QUERY_DATA_SIZE] (27 bytes) - so a
malfunctioning, malicious or counterfeit trackpad (or an attacker
tampering with the SMBus) that reports a larger block count overflows
the caller's stack buffer by up to 32 - 3 = 29 bytes, clobbering the
stack canary, saved registers and the return address.
Read each block into a local I2C_SMBUS_BLOCK_MAX-sized buffer and copy
back only the expected number of bytes, in both the group-block branch
and the multi-block loop, so the device can never write past the
caller's buffer.
Fixes: 6ddaf744c9f6 ("Input: cyapa - add support for smbus protocol")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
drivers/input/mouse/cyapa_gen3.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index fc3fb954523b..832775bb7182 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -247,27 +247,37 @@ ssize_t cyapa_smbus_read_block(struct cyapa *cyapa, u8 cmd, size_t len,
ssize_t ret;
u8 index;
u8 smbus_cmd;
- u8 *buf;
+ u8 buf[I2C_SMBUS_BLOCK_MAX];
struct i2c_client *client = cyapa->client;
if (!(SMBUS_BYTE_BLOCK_CMD_MASK & cmd))
return -EINVAL;
+ /*
+ * i2c_smbus_read_block_data() copies the device-reported block count
+ * (up to I2C_SMBUS_BLOCK_MAX) into its buffer and has no way to know
+ * its size, so read into a local buffer and copy back at most the
+ * expected number of bytes - never past the caller's buffer.
+ */
if (SMBUS_GROUP_BLOCK_CMD_MASK & cmd) {
/* read specific block registers command. */
smbus_cmd = SMBUS_ENCODE_RW(cmd, SMBUS_READ);
- ret = i2c_smbus_read_block_data(client, smbus_cmd, values);
+ ret = i2c_smbus_read_block_data(client, smbus_cmd, buf);
+ if (ret > 0)
+ memcpy(values, buf, min_t(size_t, ret, len));
goto out;
}
ret = 0;
for (index = 0; index * I2C_SMBUS_BLOCK_MAX < len; index++) {
+ size_t offset = index * I2C_SMBUS_BLOCK_MAX;
+
smbus_cmd = SMBUS_ENCODE_IDX(cmd, index);
smbus_cmd = SMBUS_ENCODE_RW(smbus_cmd, SMBUS_READ);
- buf = values + I2C_SMBUS_BLOCK_MAX * index;
ret = i2c_smbus_read_block_data(client, smbus_cmd, buf);
if (ret < 0)
goto out;
+ memcpy(values + offset, buf, min_t(size_t, ret, len - offset));
}
out:
---
base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66
change-id: 20260613-b4-disp-8e550272-a1a447c54089
Best regards,
--
Bryam Vargas <hexlabsecurity@proton.me>
^ permalink raw reply related
* Re: [PATCH] Input: cyapa - bound the SMBus block reads to the caller buffer
From: sashiko-bot @ 2026-06-13 6:24 UTC (permalink / raw)
To: Bryam Vargas via B4 Relay; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260613-b4-disp-8e550272-v1-1-9658cf8292c2@proton.me>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] cyapa_smbus_read_block masks short reads by unconditionally returning the expected length, causing callers to process and leak uninitialized stack memory.
- [High] Explicit `input_unregister_device()` on a `devm` allocated input device causes double-unregistration and memory leak.
--
commit 3fd76440d016e0f73dbb99ea7474006c10fb3123
Author: Bryam Vargas <hexlabsecurity@proton.me>
Input: cyapa - bound the SMBus block reads to the caller buffer
This commit prevents a potential buffer overflow in the cyapa driver's
SMBus block read path. It introduces a local buffer to ensure that the
number of bytes copied back does not exceed the size of the destination
buffer provided by the caller.
> diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
> index fc3fb954523b7..832775bb71825 100644
> --- a/drivers/input/mouse/cyapa_gen3.c
> +++ b/drivers/input/mouse/cyapa_gen3.c
[ ... ]
> @@ -247,27 +247,37 @@ ssize_t cyapa_smbus_read_block(struct cyapa *cyapa, u8 cmd, size_t len,
> ssize_t ret;
> u8 index;
> u8 smbus_cmd;
> - u8 *buf;
> + u8 buf[I2C_SMBUS_BLOCK_MAX];
> struct i2c_client *client = cyapa->client;
>
> if (!(SMBUS_BYTE_BLOCK_CMD_MASK & cmd))
> return -EINVAL;
>
> + /*
> + * i2c_smbus_read_block_data() copies the device-reported block count
> + * (up to I2C_SMBUS_BLOCK_MAX) into its buffer and has no way to know
> + * its size, so read into a local buffer and copy back at most the
> + * expected number of bytes - never past the caller's buffer.
> + */
> if (SMBUS_GROUP_BLOCK_CMD_MASK & cmd) {
> /* read specific block registers command. */
> smbus_cmd = SMBUS_ENCODE_RW(cmd, SMBUS_READ);
> - ret = i2c_smbus_read_block_data(client, smbus_cmd, values);
> + ret = i2c_smbus_read_block_data(client, smbus_cmd, buf);
> + if (ret > 0)
> + memcpy(values, buf, min_t(size_t, ret, len));
> goto out;
> }
>
> ret = 0;
> for (index = 0; index * I2C_SMBUS_BLOCK_MAX < len; index++) {
> + size_t offset = index * I2C_SMBUS_BLOCK_MAX;
> +
> smbus_cmd = SMBUS_ENCODE_IDX(cmd, index);
> smbus_cmd = SMBUS_ENCODE_RW(smbus_cmd, SMBUS_READ);
> - buf = values + I2C_SMBUS_BLOCK_MAX * index;
> ret = i2c_smbus_read_block_data(client, smbus_cmd, buf);
> if (ret < 0)
> goto out;
> + memcpy(values + offset, buf, min_t(size_t, ret, len - offset));
> }
>
> out:
[Severity: High]
This isn't a bug introduced by this patch, but does returning len in
cyapa_smbus_read_block() mask a short read if ret < len?
The function returns the requested length even if fewer bytes were read:
cyapa_smbus_read_block() {
...
out:
return ret > 0 ? len : ret;
}
Callers seem to assume their buffers are fully populated if the return value
matches the requested length. For instance, in cyapa_gen3_get_query_data():
u8 query_data[QUERY_DATA_SIZE];
int ret;
if (cyapa->state != CYAPA_STATE_OP)
return -EBUSY;
ret = cyapa_read_block(cyapa, CYAPA_CMD_GROUP_QUERY, query_data);
if (ret != QUERY_DATA_SIZE)
return (ret < 0) ? ret : -EIO;
memcpy(&cyapa->product_id[0], &query_data[0], 5);
Could this lead to processing uninitialized stack memory and exposing it
to userspace if the read is short?
[Severity: High]
This is also a pre-existing issue, but does calling input_unregister_device()
on a devm-allocated device in cyapa_update_fw_store() cause a double-free or
resource leak?
Looking at cyapa_update_fw_store() in drivers/input/mouse/cyapa.c:
if (cyapa->input) {
/* ... */
input_unregister_device(cyapa->input);
cyapa->input = NULL;
}
Since the device was originally allocated with devm_input_allocate_device()
in cyapa_create_input_dev(), manually unregistering it leaves the devres
cleanup action still queued.
Could the devres action trigger a double-unregistration when the device
unbinds, and does allocating a new device via cyapa_reinitialize() during
each firmware update leak the old devres actions?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-b4-disp-8e550272-v1-1-9658cf8292c2@proton.me?part=1
^ permalink raw reply
* Re: [PATCH v6 0/7] Add support for MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-06-13 6:46 UTC (permalink / raw)
To: linux-mediatek
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Julien Massot,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Akari Tsuyukusa,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260612200717.361018-1-l.scorcia@gmail.com>
Please ignore this patch set. As correctly described by sashiko-bot,
the binding with no regulator node would not be usable, even if it
passed dtbs_check. I need to complete work on that and then resubmit.
Sorry about the confusion.
Il giorno ven 12 giu 2026 alle ore 22:26 Luca Leonardo Scorcia
<l.scorcia@gmail.com> ha scritto:
>
> The MediaTek MT6392 PMIC is usually found on devices powered by
> the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
>
> This series is mostly based around patches submitted a couple
> years ago by Fabien Parent and not merged and from Val Packett's
> submission from Jan 2025 that included extra cleanups, fixes, and a
> new dtsi file similar to ones that exist for other PMICs. Some
> comments weren't addressed and the series was ultimately not merged.
>
> These patches only enable three functions: keys, pinctrl and RTC.
> Regulators and speaker amp will follow later as I still need to further
> improve those two, but getting the main PMIC in will make the series
> easier to review.
>
> I added a handful of device tree improvements to fix some dtbs_check
> errors, added support for the pinctrl device and addressed the comments
> from last year's reviews.
>
> Please note that patch 0005 depends on patch 0004 as they both need the
> registers.h file, but they belong to different driver areas. I'm not sure
> if I'm supposed to squash them even if they belong to different driver
> areas of if it's fine like this. Any advice is welcome.
>
> The series has been tested on Xiaomi Mi Smart Clock X04G and on the
> Lenovo Smart Clock 2.
>
> Changes in v6:
> - Dropped the regulators driver for the moment
> - Explained the FCHR key name origin in the commit message
> - Introduced the MFD_CELL_* macro in the sub-devices definitions.
> A separate, independent commit introduced MFD_CELL_* to all the
> subdevices in the mt6397-core.c file for consistency
> - Replaced of_device_get_match_data with device_get_match_data
> - Removed the mfd_match_data enum in favor of the preexisting
> chip_id enum
> - Adjusted the error message if the device is unsupported
>
> Changes in v5 [5]:
> - Double checked regulator driver with data sheet and Android sources.
> The data sheet I have misses a lot of register descriptions, but
> Android sources have been helpful to fill the gaps
> - Reintroduced the required attribute for the regulator compatible
> in the bindings
> - Fixed the missing reference to the MT6392 schema
> - Fixed casts/unused vars reported by kernel test robot
> - Removed Reviewed-by tags from the regulator patches as they have been
> modified in this version
>
> Changes in v4 [4]:
> - Dropped usage of the regulator compatible
> - Fixed commit messages text to properly reference the target subsystem
> - Added supply rails to the regulator
> - Reworked the regulator schema and PMIC dtsi. Now all supplies are
> documented and the schema no longer includes voltage information
> - Removed redundant ldo- / buck- prefixes
> - Renamed the pinfunc header to mediatek,mt6392-pinfunc.h
> - Modified the MFD driver to use a simple identifier in the of_match
> data properties
>
> Changes in v3 [3]:
> - Added pinctrl device
> - Changed mt6397-rtc fallback to mt6323-rtc
> - Added schema for regulators
> - Fixed checkpatch issues
>
> Changes in v2 [2]:
> - Replaced explicit compatibles with fallbacks
>
> Initial version: [1]
>
> [1] https://lore.kernel.org/linux-mediatek/cover.1771865014.git.l.scorcia@gmail.com/
> [2] https://lore.kernel.org/linux-mediatek/20260306120521.163654-1-l.scorcia@gmail.com/
> [3] https://lore.kernel.org/linux-mediatek/20260317184507.523060-1-l.scorcia@gmail.com/
> [4] https://lore.kernel.org/linux-mediatek/20260330083429.359819-1-l.scorcia@gmail.com/
> [5] https://lore.kernel.org/linux-mediatek/20260420213529.1645560-1-l.scorcia@gmail.com/
>
> Fabien Parent (3):
> dt-bindings: mfd: mt6397: Add MT6392 PMIC
> dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys
> mfd: mt6397: Add support for MT6392 PMIC
>
> Luca Leonardo Scorcia (2):
> mfd: mt6397: Use MFD_CELL_* to describe sub-devices
> pinctrl: mediatek: mt6397: Add MediaTek MT6392
>
> Val Packett (2):
> input: keyboard: mtk-pmic-keys: Add MT6392 support
> arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
>
> .../bindings/input/mediatek,pmic-keys.yaml | 1 +
> .../bindings/mfd/mediatek,mt6397.yaml | 8 +
> arch/arm64/boot/dts/mediatek/mt6392.dtsi | 41 ++
> drivers/input/keyboard/mtk-pmic-keys.c | 17 +
> drivers/mfd/mt6397-core.c | 294 +++++------
> drivers/mfd/mt6397-irq.c | 8 +
> drivers/pinctrl/mediatek/pinctrl-mt6397.c | 37 +-
> drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h | 64 +++
> include/linux/mfd/mt6392/core.h | 43 ++
> include/linux/mfd/mt6392/registers.h | 488 ++++++++++++++++++
> include/linux/mfd/mt6397/core.h | 1 +
> 11 files changed, 840 insertions(+), 162 deletions(-)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h
> create mode 100644 include/linux/mfd/mt6392/core.h
> create mode 100644 include/linux/mfd/mt6392/registers.h
>
> --
> 2.43.0
>
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH v4 1/7] arm64: defconfig: Enable Allwinner LRADC input driver
From: Jernej Škrabec @ 2026-06-13 8:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-2-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:15 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Enable Allwinner LRADC input driver as module to support buttons on Baijie
> HelperBoard A133.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej Skrabec
^ permalink raw reply
* Re: [PATCH v4 5/7] arm64: dts: allwinner: a100: Add LRADC node
From: Jernej Škrabec @ 2026-06-13 8:20 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-6-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:19 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> A100/A133 SoCs feature a Low Rate ADC (LRADC) for Key application.
>
> Specs:
> - Power supply voltage: 1.8 V
> - Reference voltage: 1.35 V
> - Interrupt support
> - Support Hold Key and General Key
> - Support normal, continue and single work mode
> - 6-bits resolution, sample rate up to 2 kHz
> - Voltage input range between 0 and 1.35 V
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
> Changelog:
> v4:
> - added allwinner,sun50i-a100-lradc compatible
> v3:
> - new patch
>
> arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> index b3fb1e0ee796..7cb06b19b5a5 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> @@ -466,6 +466,15 @@ ths: thermal-sensor@5070400 {
> #thermal-sensor-cells = <1>;
> };
>
> + lradc: lradc@5070800 {
> + compatible = "allwinner,sun50i-a100-lradc", "allwinner,sun50i-r329-lradc";
Break this into two lines, like usb_otg below. With that:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej Skrabec
> + reg = <0x05070800 0x400>;
> + interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_LRADC>;
> + resets = <&ccu RST_BUS_LRADC>;
> + status = "disabled";
> + };
> +
> usb_otg: usb@5100000 {
> compatible = "allwinner,sun50i-a100-musb",
> "allwinner,sun8i-a33-musb";
>
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Jernej Škrabec @ 2026-06-13 8:22 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-7-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Add reserved-memory node carving out Trusted Firmware-A region spanning
> fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> itself passes the address range in the fdt to U-Boot, U-Boot currently
> only reserves this memory internally, but doesn't carve out the region
> in the fdt passed to Linux.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
NAK. It is job of boot procedure to properly inject TF-A reserved node.
Any issue should be fixed there.
Best regards,
Jernej Skrabec
> ---
> Changelog:
> v4:
> - new patch
>
> arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> index 7cb06b19b5a5..d8391663fd1d 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> #clock-cells = <0>;
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /*
> + * 256 KiB reserved for Trusted Firmware-A (BL31).
> + * This is added by BL31 itself, but some bootloaders fail
> + * to propagate this into the DTB handed to kernels.
> + */
> + secmon@40000000 {
> + reg = <0x0 0x40000000 0x0 0x40000>;
> + no-map;
> + };
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupts = <GIC_PPI 13
>
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Alexander Sverdlin @ 2026-06-13 8:34 UTC (permalink / raw)
To: Jernej Škrabec, linux-arm-kernel, linux-sunxi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <_6NEZ78hR8a_3V2bhBAGoQ@gmail.com>
Hi Jernej,
On Sat, 2026-06-13 at 10:22 +0200, Jernej Škrabec wrote:
> Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> > Add reserved-memory node carving out Trusted Firmware-A region spanning
> > fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> > itself passes the address range in the fdt to U-Boot, U-Boot currently
> > only reserves this memory internally, but doesn't carve out the region
> > in the fdt passed to Linux.
> >
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
>
> NAK. It is job of boot procedure to properly inject TF-A reserved node.
> Any issue should be fixed there.
like in commit 0d17c865118881609ea7e381c7cadbb7979cc596
("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
? ;-)
> Best regards,
> Jernej Skrabec
>
> > ---
> > Changelog:
> > v4:
> > - new patch
> >
> > arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > index 7cb06b19b5a5..d8391663fd1d 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> > #clock-cells = <0>;
> > };
> >
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /*
> > + * 256 KiB reserved for Trusted Firmware-A (BL31).
> > + * This is added by BL31 itself, but some bootloaders fail
> > + * to propagate this into the DTB handed to kernels.
> > + */
> > + secmon@40000000 {
> > + reg = <0x0 0x40000000 0x0 0x40000>;
> > + no-map;
> > + };
> > + };
> > +
> > timer {
> > compatible = "arm,armv8-timer";
> > interrupts = <GIC_PPI 13
--
Alexander Sverdlin.
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Jernej Škrabec @ 2026-06-13 9:38 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <b428d57ba5464f1226daf099877f4c25fa4fc191.camel@gmail.com>
Dne sobota, 13. junij 2026 ob 10:34:42 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Hi Jernej,
>
> On Sat, 2026-06-13 at 10:22 +0200, Jernej Škrabec wrote:
> > Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> > > Add reserved-memory node carving out Trusted Firmware-A region spanning
> > > fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> > > itself passes the address range in the fdt to U-Boot, U-Boot currently
> > > only reserves this memory internally, but doesn't carve out the region
> > > in the fdt passed to Linux.
> > >
> > > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> >
> > NAK. It is job of boot procedure to properly inject TF-A reserved node.
> > Any issue should be fixed there.
>
>
> like in commit 0d17c865118881609ea7e381c7cadbb7979cc596
> ("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
>
> ? ;-)
I was against that too.
It's time to be fixed in bootloader.
Best regards,
Jernej
>
> > Best regards,
> > Jernej Skrabec
> >
> > > ---
> > > Changelog:
> > > v4:
> > > - new patch
> > >
> > > arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > index 7cb06b19b5a5..d8391663fd1d 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> > > #clock-cells = <0>;
> > > };
> > >
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + /*
> > > + * 256 KiB reserved for Trusted Firmware-A (BL31).
> > > + * This is added by BL31 itself, but some bootloaders fail
> > > + * to propagate this into the DTB handed to kernels.
> > > + */
> > > + secmon@40000000 {
> > > + reg = <0x0 0x40000000 0x0 0x40000>;
> > > + no-map;
> > > + };
> > > + };
> > > +
> > > timer {
> > > compatible = "arm,armv8-timer";
> > > interrupts = <GIC_PPI 13
>
>
^ permalink raw reply
* Re: [PATCH v2 8/9] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Jun Yan @ 2026-06-13 9:53 UTC (permalink / raw)
To: conor
Cc: conor+dt, devicetree, dmitry.torokhov, jerrysteve1101, krzk+dt,
linux-input, linux-kernel, robh
In-Reply-To: <20260612-plethora-debatable-d00cb679277b@spud>
> On Fri, Jun 12, 2026 at 03:22:14PM +0800, Jun Yan wrote:
> > CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
> > and hardware reset support.
> >=20
> > Add the compatible string for CAP1114, add its datasheet URL,
> > update the maximum of LED channel reg, and add constraint for
> > linux,keycodes.
> >=20
> > Previously, the LED reg property had a default maximum of 7 for CAP1188.
> > With the addition of CAP1114, the default maximum is now 11.
> > An if-then constraint is added to limit the LED count for CAP1188.
> >=20
> > Update description for microchip,input-threshold: CAP1114 only provides
> > eight threshold entries, which does not match its total channel count.
> >=20
> > CAP1114 does not support microchip,signal-guard and
> > microchip,calib-sensitivity.
> >=20
> > Add CAP1114 to the unsupported enum list.
> >=20
> > Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> > ---
> > .../bindings/input/microchip,cap11xx.yaml | 32 ++++++++++++++++++-
> > 1 file changed, 31 insertions(+), 1 deletion(-)
> >=20
> > diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.ya=
> ml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > index 778ec6d659a8..0e9a1a8a3f3e 100644
> > --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > @@ -12,6 +12,7 @@ description: |
> > =20
> > For more product information please see the links below:
> > CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.=
> pdf
> > + CAP1114: https://ww1.microchip.com/downloads/en/DeviceDoc/00002444A.=
> pdf
> > CAP1126: https://ww1.microchip.com/downloads/en/DeviceDoc/00001623B.=
> pdf
> > CAP1188: https://ww1.microchip.com/downloads/en/DeviceDoc/00001620C.=
> pdf
> > CAP1203: https://ww1.microchip.com/downloads/en/DeviceDoc/00001572B.=
> pdf
> > @@ -26,6 +27,7 @@ properties:
> > compatible:
> > enum:
> > - microchip,cap1106
> > + - microchip,cap1114
> > - microchip,cap1126
> > - microchip,cap1188
> > - microchip,cap1203
> > @@ -122,6 +124,8 @@ properties:
> > is required for a touch to be registered, making the touch sensor =
> less
> > sensitive.
> > The number of entries must correspond to the number of channels.
> > + CAP1114 is an exception where channels 8~14 reuse the eighth entry=
> 's
> > + threshold, so counts differ.
> > =20
> > microchip,calib-sensitivity:
> > $ref: /schemas/types.yaml#/definitions/uint32-array
> > @@ -149,7 +153,7 @@ patternProperties:
> > reg:
> > description: LED channel number
> > minimum: 0
> > - maximum: 7
> > + maximum: 10
> > =20
> > label: true
> > =20
> > @@ -178,6 +182,18 @@ allOf:
> > properties:
> > reset-gpios: false
> > =20
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - microchip,cap1114
> > + then:
> > + properties:
> > + linux,keycodes:
> > + minItems: 14
> > + maxItems: 14
>
> Sashiko complaint here is valid.
> You need to increase the outer constraint to max 14, and only set the
> min here.
> Then you need to add an else that sets maxitems to 8.
Thanks for the review. I'll fix this in v3.
> pw-bot: changes-requested
>
> Cheers,
> Conor.
^ 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