* [PATCH v5 0/4] arm64: dts: nuvoton: add NPCM845 SoC and EVB support
From: Tomer Maimon @ 2026-06-15 14:25 UTC (permalink / raw)
To: andrew, robh, krzk+dt, conor+dt
Cc: openbmc, devicetree, linux-kernel, avifishman70, tmaimon77,
tali.perry1, venture, yuenn, benjaminfair
This series fixes the remaining timer binding issue and adds device tree
support for peripherals on the Nuvoton NPCM845 SoC and its Evaluation
Board (EVB).
The first patch drops the undocumented timer0 clock-names property.
The second patch reorders timer0 and PECI so the APB child nodes stay in
ascending unit-address order.
The third patch introduces peripheral nodes for Ethernet, MMC, SPI, USB,
RNG, ADC, PWM-FAN, I2C, and OP-TEE firmware in the NPCM845 SoC device
tree.
The fourth patch enables these peripherals for the NPCM845-EVB, adding
MDIO nodes, reserved memory, aliases, and board-specific configurations
such as PHY modes and SPI flash partitions.
The NPCM8XX device tree was tested on NPCM845 evaluation board.
This series depends on:
https://lore.kernel.org/all/20260610121822.2524634-2-tmaimon77@gmail.com/
https://lore.kernel.org/all/20260610121822.2524634-3-tmaimon77@gmail.com/
https://lore.kernel.org/all/20260610121822.2524634-4-tmaimon77@gmail.com/
Addressed comments from:
- Rob Herring
Changes since version 4:
- Split the timer0 clock-names cleanup into a separate first patch.
- Remove nuvoton,sysgcr from udc8 and udc9.
- Rename apb: bus@f0000000 back to apb.
- Add no-map to tip_reserved.
- Rename spix-mode to nuvoton,spix-mode.
- Keep cooling-levels as 32-bit cells while encoding fan-tach-ch
as /bits/ 8.
Tomer Maimon (4):
arm64: dts: nuvoton: npcm845: Drop redundant timer clock-names
arm64: dts: nuvoton: npcm845: Reorder timer0 and PECI nodes
arm64: dts: nuvoton: npcm845: Add peripheral nodes
arm64: dts: nuvoton: npcm845-evb: Add peripheral nodes
.../dts/nuvoton/nuvoton-common-npcm8xx.dtsi | 721 +++++++++++++++++-
.../boot/dts/nuvoton/nuvoton-npcm845-evb.dts | 413 ++++++++++
.../boot/dts/nuvoton/nuvoton-npcm845.dtsi | 11 +-
3 files changed, 1126 insertions(+), 19 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 4/4] arm64: dts: qcom: sc8180x-lenovo-flex-5g: Describe the display power net
From: Konrad Dybcio @ 2026-06-15 14:22 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260615-topic-8180_disp_power-v1-0-18d36b548c48@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Describe and wire up the power supplies for the eDP panel and its
backlight. Previously, this was only working because of settings
inherited from the bootloader.
Fixes: 20dea72a393c ("arm64: dts: qcom: sc8180x: Introduce Lenovo Flex 5G")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
.../arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 47 ++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts b/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
index 0d2cfb830e83..0a8980c36c4e 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
+++ b/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
@@ -26,6 +26,7 @@ backlight: backlight {
compatible = "pwm-backlight";
pwms = <&pmc8180c_lpg 4 1000000>;
enable-gpios = <&pmc8180c_gpios 8 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vled_bl_pw>;
pinctrl-0 = <&bl_pwm_default>;
pinctrl-names = "default";
@@ -157,6 +158,38 @@ cdsp_mem: cdsp-region@98900000 {
};
};
+ vled_bl_pw: regulator-vled-bl-pw {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VLED_BL_PW";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&pmc8180_2_gpios 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&bl_pwr_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
+ vreg_lcm_3v3: regulator-edp-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_LCM_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 130 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&lcm_3v3_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
vreg_s4a_1p8: regulator-pm8150-s4 {
compatible = "regulator-fixed";
regulator-name = "vreg_s4a_1p8";
@@ -438,6 +471,7 @@ &mdss_edp {
aux-bus {
panel {
compatible = "edp-panel";
+ power-supply = <&vreg_lcm_3v3>;
no-hpd;
backlight = <&backlight>;
@@ -472,6 +506,13 @@ &pcie3_phy {
status = "okay";
};
+&pmc8180_2_gpios {
+ bl_pwr_en: blw-pwr-en-state {
+ pins = "gpio1";
+ function = "normal";
+ };
+};
+
&pmc8180_pwrkey {
status = "okay";
};
@@ -765,6 +806,12 @@ ts_int_default: ts-int-default-state {
drive-strength = <2>;
};
+ lcm_3v3_en: lcm-3v3-en-state {
+ pins = "gpio130";
+ function = "gpio";
+ bias-disable;
+ };
+
usbprim_sbu_default: usbprim-sbu-state {
oe-n-pins {
pins = "gpio152";
--
2.54.0
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: qcom: sc8180x-lenovo-flex-5g: Rename regulator nodes
From: Konrad Dybcio @ 2026-06-15 14:22 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260615-topic-8180_disp_power-v1-0-18d36b548c48@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Align with the contemporary way of naming regulator nodes (regulator-
prefix) in preparation for adding more of them.
Reorder the renamed entries to match the expectations of the DT coding
style doc.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts b/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
index d86a31ddede2..0d2cfb830e83 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
+++ b/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
@@ -157,14 +157,7 @@ cdsp_mem: cdsp-region@98900000 {
};
};
- vph_pwr: vph-pwr-regulator {
- compatible = "regulator-fixed";
- regulator-name = "vph_pwr";
- regulator-min-microvolt = <3700000>;
- regulator-max-microvolt = <3700000>;
- };
-
- vreg_s4a_1p8: pm8150-s4-regulator {
+ vreg_s4a_1p8: regulator-pm8150-s4 {
compatible = "regulator-fixed";
regulator-name = "vreg_s4a_1p8";
@@ -177,6 +170,13 @@ vreg_s4a_1p8: pm8150-s4-regulator {
vin-supply = <&vph_pwr>;
};
+ vph_pwr: regulator-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+ };
+
usbprim-sbu-mux {
compatible = "pericom,pi3usb102", "gpio-sbu-mux";
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: qcom: sc8180x-primus: Describe the display power net
From: Konrad Dybcio @ 2026-06-15 14:22 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260615-topic-8180_disp_power-v1-0-18d36b548c48@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Describe and wire up the power supplies for the eDP panel and its
backlight. Previously, this was only working because of settings
inherited from the bootloader.
Fixes: 2ce38cc1e8fe ("arm64: dts: qcom: sc8180x: Introduce Primus")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc8180x-primus.dts | 48 ++++++++++++++++++++++++++++-
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x-primus.dts b/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
index ffe7c45366ed..ed4f7f10e376 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
+++ b/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
@@ -29,9 +29,10 @@ backlight: backlight {
compatible = "pwm-backlight";
pwms = <&pmc8180c_lpg 4 1000000>;
enable-gpios = <&pmc8180c_gpios 8 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vled_bl_pw>;
- pinctrl-names = "default";
pinctrl-0 = <&bl_pwm_default>;
+ pinctrl-names = "default";
};
chosen {
@@ -167,6 +168,38 @@ reserved-region@9a500000 {
};
};
+ vled_bl_pw: regulator-vled-bl-pw {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VLED_BL_PW";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&pmc8180_2_gpios 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&bl_pwr_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
+ vreg_lcm_3v3: regulator-edp-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_LCM_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 130 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&lcm_3v3_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
vreg_nvme_0p9: regulator-nvme-0p9 {
compatible = "regulator-fixed";
regulator-name = "vreg_nvme_0p9";
@@ -540,6 +573,7 @@ &mdss_edp {
aux-bus {
panel {
compatible = "edp-panel";
+ power-supply = <&vreg_lcm_3v3>;
backlight = <&backlight>;
@@ -769,6 +803,12 @@ &wifi {
};
/* PINCTRL */
+&pmc8180_2_gpios {
+ bl_pwr_en: blw-pwr-en-state {
+ pins = "gpio1";
+ function = "normal";
+ };
+};
&pmc8180c_gpios {
bl_pwm_default: bl-pwm-default-state {
@@ -950,4 +990,10 @@ rx-pins {
bias-pull-up;
};
};
+
+ lcm_3v3_en: lcm-3v3-en-state {
+ pins = "gpio130";
+ function = "gpio";
+ bias-disable;
+ };
};
--
2.54.0
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: qcom: sc8180x-primus: Rename regulator nodes
From: Konrad Dybcio @ 2026-06-15 14:22 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260615-topic-8180_disp_power-v1-0-18d36b548c48@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
The nodes would be sorted correctly, if their names started with
"regulator-" (which is the style used in the latest submissions).
Touch that up.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc8180x-primus.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x-primus.dts b/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
index aff398390eba..ffe7c45366ed 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
+++ b/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
@@ -167,7 +167,7 @@ reserved-region@9a500000 {
};
};
- vreg_nvme_0p9: nvme-0p9-regulator {
+ vreg_nvme_0p9: regulator-nvme-0p9 {
compatible = "regulator-fixed";
regulator-name = "vreg_nvme_0p9";
@@ -177,7 +177,7 @@ vreg_nvme_0p9: nvme-0p9-regulator {
regulator-always-on;
};
- vreg_nvme_3p3: nvme-3p3-regulator {
+ vreg_nvme_3p3: regulator-nvme-3p3 {
compatible = "regulator-fixed";
regulator-name = "vreg_nvme_3p3";
@@ -190,7 +190,7 @@ vreg_nvme_3p3: nvme-3p3-regulator {
regulator-always-on;
};
- vdd_kb_tp_3v3: vdd-kb-tp-3v3-regulator {
+ vdd_kb_tp_3v3: regulator-vdd-kb-tp-3v3 {
compatible = "regulator-fixed";
regulator-name = "vdd_kb_tp_3v3";
regulator-min-microvolt = <3300000>;
@@ -205,7 +205,7 @@ vdd_kb_tp_3v3: vdd-kb-tp-3v3-regulator {
pinctrl-0 = <&kb_tp_3v3_en_active_state>;
};
- vph_pwr: vph-pwr-regulator {
+ vph_pwr: regulator-vph-pwr {
compatible = "regulator-fixed";
regulator-name = "vph_pwr";
regulator-min-microvolt = <3700000>;
--
2.54.0
^ permalink raw reply related
* [PATCH 0/4] Describe display voltage regulators on SC8180X devices
From: Konrad Dybcio @ 2026-06-15 14:22 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
Let Linux control these supplies to both ensure a known state and allow
for some power savings.
This series is compile-tested only, but verified against schematics.
Resolves the following kind of DT checker warnings:
sc8180x-lenovo-flex-5g.dtb: panel (edp-panel): 'power-supply' is a required property
Making the SC8180X platform warning-free.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Konrad Dybcio (4):
arm64: dts: qcom: sc8180x-primus: Rename regulator nodes
arm64: dts: qcom: sc8180x-primus: Describe the display power net
arm64: dts: qcom: sc8180x-lenovo-flex-5g: Rename regulator nodes
arm64: dts: qcom: sc8180x-lenovo-flex-5g: Describe the display power net
.../arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 57 ++++++++++++++++++++--
arch/arm64/boot/dts/qcom/sc8180x-primus.dts | 56 +++++++++++++++++++--
2 files changed, 103 insertions(+), 10 deletions(-)
---
base-commit: c425609d6ac4012c8bbf01ec2e10e801b1923a7b
change-id: 20260615-topic-8180_disp_power-d14df352dcb7
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v7 2/5] iio: adc: add Versal SysMon driver
From: Andy Shevchenko @ 2026-06-15 14:22 UTC (permalink / raw)
To: Salih Erim
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260614233722.2603459-3-salih.erim@amd.com>
On Mon, Jun 15, 2026 at 12:37:19AM +0100, Salih Erim wrote:
> Add the core driver and MMIO platform driver for the AMD/Xilinx Versal
> System Monitor (SysMon) block.
>
> The SysMon block resides in the platform management controller (PMC) and
> provides on-chip voltage and temperature monitoring through a 10-bit,
> 200 kSPS ADC. It can monitor up to 160 voltage channels and 64
> temperature satellites distributed across the SoC, with a consistent
> sample rate of 8 kSPS per channel regardless of how many channels are
> enabled.
>
> The hardware also provides four aggregate temperature registers that
> are always present regardless of the device tree configuration: the
> current max and min across all active satellites, and the peak and
> trough values recorded since the last hardware reset.
>
> The driver is split into two compilation units:
> - versal-sysmon-core: Channel parsing, IIO registration, read_raw
> - versal-sysmon: MMIO platform driver with custom regmap accessors
>
> Voltage results are stored in a 19-bit modified floating-point format
> and converted to millivolts. Temperature results are stored in Q8.7
> signed fixed-point Celsius format and converted to millicelsius.
>
> The MMIO regmap backend uses a custom reg_write accessor that
> automatically unlocks the NPI (NoC programming interface) lock
> register before each write, as required by the hardware. The regmap
> is configured with fast_io since the underlying MMIO accessors are
> safe to call from atomic context.
...
> +static int sysmon_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct sysmon *sysmon = iio_priv(indio_dev);
> + unsigned int regval;
> + int ret;
> +
> + guard(mutex)(&sysmon->lock);
> +
> + switch (chan->type) {
> + case IIO_TEMP:
> + if (mask == IIO_CHAN_INFO_SCALE) {
> + /* Q8.7 to millicelsius: raw * 1000 / 128 */
> + *val = MILLI;
Since this is about temperature, wouldn't be better to use
MILLIDEGREE_PER_DEGREE
here?
> + *val2 = BIT(SYSMON_FRACTIONAL_SHIFT);
> + return IIO_VAL_FRACTIONAL;
> + }
> + if (mask != IIO_CHAN_INFO_RAW)
> + return -EINVAL;
> +
> + ret = regmap_read(sysmon->regmap, chan->address, ®val);
> + if (ret)
> + return ret;
> +
> + *val = sign_extend32(regval, 15);
> + return IIO_VAL_INT;
> +
> + case IIO_VOLTAGE:
> + if (mask != IIO_CHAN_INFO_PROCESSED)
> + return -EINVAL;
> +
> + ret = regmap_read(sysmon->regmap,
> + chan->address * SYSMON_REG_STRIDE +
> + SYSMON_SUPPLY_BASE, ®val);
> + if (ret)
> + return ret;
> +
> + sysmon_supply_rawtoprocessed(regval, val);
> + return IIO_VAL_INT;
> +
> + default:
> + return -EINVAL;
> + }
> +}
...
> +static int sysmon_parse_fw(struct iio_dev *indio_dev, struct device *dev)
> +{
> + unsigned int num_chan, idx, temp_chan_idx, volt_chan_idx;
> + unsigned int num_supply, num_temp;
> + struct iio_chan_spec *sysmon_channels;
> + const char *label;
> + u32 reg;
> + int ret;
> +
> + struct fwnode_handle *supply_node __free(fwnode_handle) =
> + device_get_named_child_node(dev, "voltage-channels");
> + num_supply = fwnode_get_child_node_count(supply_node);
> +
> + struct fwnode_handle *temp_node __free(fwnode_handle) =
> + device_get_named_child_node(dev, "temperature-channels");
> + num_temp = fwnode_get_child_node_count(temp_node);
> +
> + num_chan = size_add(num_temp, size_add(ARRAY_SIZE(temp_channels), num_supply));
+ overflow.h
> + sysmon_channels = devm_kcalloc(dev, num_chan, sizeof(*sysmon_channels), GFP_KERNEL);
> + if (!sysmon_channels)
> + return -ENOMEM;
> +
> + /* Static temperature channels first */
> + memcpy(sysmon_channels, temp_channels, sizeof(temp_channels));
> + idx = ARRAY_SIZE(temp_channels);
> +
> + /* Supply channels from DT */
> + fwnode_for_each_child_node_scoped(supply_node, child) {
> + ret = fwnode_property_read_u32(child, "reg", ®);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "missing reg for supply channel\n");
> +
> + if (reg > SYSMON_SUPPLY_IDX_MAX)
> + return dev_err_probe(dev, -EINVAL,
> + "supply reg %u exceeds max %u\n",
> + reg, SYSMON_SUPPLY_IDX_MAX);
> +
> + ret = fwnode_property_read_string(child, "label", &label);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "missing label for supply channel\n");
> +
> + sysmon_channels[idx++] = (struct iio_chan_spec) {
> + .type = IIO_VOLTAGE,
> + .indexed = 1,
> + .address = reg,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> + .datasheet_name = label,
> + };
> + }
> +
> + /* Temperature satellite channels from DT */
> + fwnode_for_each_child_node_scoped(temp_node, child) {
> + ret = fwnode_property_read_u32(child, "reg", ®);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "missing reg for temp channel\n");
> +
> + if (reg < 1 || reg > SYSMON_TEMP_SAT_MAX)
> + return dev_err_probe(dev, -EINVAL,
> + "temp reg %u out of range [1..%u]\n",
> + reg, SYSMON_TEMP_SAT_MAX);
> +
> + ret = fwnode_property_read_string(child, "label", &label);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "missing label for temp channel\n");
> +
> + sysmon_channels[idx++] = (struct iio_chan_spec) {
> + .type = IIO_TEMP,
> + .indexed = 1,
> + .address = SYSMON_TEMP_SAT_BASE +
> + (reg - 1) * SYSMON_REG_STRIDE,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
> + .datasheet_name = label,
> + };
> + }
> +
> + indio_dev->num_channels = idx;
> + indio_dev->info = &sysmon_iio_info;
> +
> + /*
> + * Assign per-type sequential channel numbers.
> + * IIO sysfs uses type prefix (in_tempN, in_voltageN)
> + * so numbers only need to be unique within each type.
> + */
> + temp_chan_idx = 0;
> + volt_chan_idx = 0;
> + for (unsigned int idx = 0; idx < indio_dev->num_channels; idx++) {
> + if (sysmon_channels[idx].type == IIO_TEMP)
> + sysmon_channels[idx].channel = temp_chan_idx++;
> + else
> + sysmon_channels[idx].channel = volt_chan_idx++;
> + }
> +
> + indio_dev->channels = sysmon_channels;
> +
> + return 0;
> +}
...
> +/**
> + * sysmon_core_probe() - Initialize Versal SysMon core
It is managed, please name it accordingly: devm_sysmon_core_probe().
> + * @dev: Parent device
> + * @regmap: Register map for hardware access
> + *
> + * Return: 0 on success, negative errno on failure.
> + */
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 10/10] Input: cap11xx - add support for CAP1114
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support.
The CAP1114 uses two control registers for LED output management and
requires two button status registers for touch input state reporting.
By default, channels CS8~CS14 operate as a single grouped block.
Set the corresponding register enable bit to enable these channels as
independent touch inputs. Note these channels share the input threshold
of the eighth entry, causing num_sensor_thresholds to differ from
num_channels.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
drivers/input/keyboard/cap11xx.c | 73 ++++++++++++++++++++++++++++++--
1 file changed, 69 insertions(+), 4 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index c48ee8520a27..187a212dfa8f 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -18,6 +18,12 @@
#include <linux/gpio/consumer.h>
#include <linux/bitfield.h>
+#define CAP1114_REG_BUTTON_STATUS1 0x03
+#define CAP1114_REG_BUTTON_STATUS2 0x04
+#define CAP1114_REG_CONFIG2 0x40
+#define CAP1114_REG_CONFIG2_VOL_UP_DOWN BIT(1)
+#define CAP1114_REG_LED_OUTPUT_CONTROL1 0x73
+
#define CAP11XX_REG_MAIN_CONTROL 0x00
#define CAP11XX_REG_MAIN_CONTROL_GAIN_SHIFT (6)
#define CAP11XX_REG_MAIN_CONTROL_GAIN_MASK (0xc0)
@@ -82,6 +88,7 @@ struct cap11xx_hw_model {
unsigned int num_leds;
unsigned int num_sensor_thresholds;
bool has_gain;
+ bool has_grouped_sensors;
bool has_irq_config;
bool has_repeat_en;
bool has_sensitivity_control;
@@ -98,6 +105,8 @@ static const struct reg_default cap11xx_reg_defaults[] = {
{ CAP11XX_REG_SENSOR_THRESH(3), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(4), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(5), 0x40 },
+ { CAP11XX_REG_SENSOR_THRESH(6), 0x40 },
+ { CAP11XX_REG_SENSOR_THRESH(7), 0x40 },
{ CAP11XX_REG_CONFIG2, 0x40 },
};
@@ -106,6 +115,12 @@ static bool cap11xx_volatile_reg(struct device *dev, unsigned int reg)
switch (reg) {
case CAP11XX_REG_MAIN_CONTROL:
case CAP11XX_REG_SENSOR_INPUT:
+ /*
+ * CAP1114_REG_BUTTON_STATUS1 (CAP11XX_REG_SENSOR_INPUT) and
+ * CAP1114_REG_BUTTON_STATUS2 is volatile for the CAP1114,
+ * which supports more than 8 touch channels.
+ */
+ case CAP1114_REG_BUTTON_STATUS2:
return true;
}
@@ -285,6 +300,17 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
of_property_read_u32_array(node, "linux,keycodes",
priv->keycodes, priv->model->num_channels);
+ /*
+ * CAP1114 needs dedicated configuration to split
+ * grouped sensors into independent inputs.
+ */
+ if (priv->model->has_grouped_sensors) {
+ error = regmap_set_bits(priv->regmap, CAP1114_REG_CONFIG2,
+ CAP1114_REG_CONFIG2_VOL_UP_DOWN);
+ if (error)
+ return error;
+ }
+
if (priv->model->has_repeat_en) {
/* Disable autorepeat. The Linux input system has its own handling. */
error = regmap_write(priv->regmap, CAP11XX_REG_REPEAT_RATE, 0);
@@ -313,6 +339,21 @@ static irqreturn_t cap11xx_thread_func(int irq_num, void *data)
if (ret < 0)
goto out;
+ if (priv->model->num_channels > 8) {
+ unsigned int status2;
+
+ ret = regmap_read(priv->regmap, priv->model->sensor_input_reg_base + 1, &status2);
+ if (ret < 0)
+ goto out;
+
+ /*
+ * CAP1114 STATUS1 register only contains data for the first 6 channels.
+ * the remaining channels is stored in STATUS2.
+ */
+ status &= GENMASK(5, 0);
+ status |= FIELD_PREP(GENMASK(13, 6), status2);
+ }
+
for (i = 0; i < priv->idev->keycodemax; i++)
input_report_key(priv->idev, priv->keycodes[i],
status & (1 << i));
@@ -362,10 +403,16 @@ static int cap11xx_led_set(struct led_classdev *cdev,
* limitation. Brightness levels per LED are either
* 0 (OFF) and 1 (ON).
*/
- return regmap_update_bits(priv->regmap,
- priv->model->led_output_control_reg_base,
- BIT(led->reg),
- value ? BIT(led->reg) : 0);
+ if (led->reg >= 8)
+ return regmap_update_bits(priv->regmap,
+ priv->model->led_output_control_reg_base + 1,
+ BIT(led->reg - 8),
+ value ? BIT(led->reg - 8) : 0);
+ else
+ return regmap_update_bits(priv->regmap,
+ priv->model->led_output_control_reg_base,
+ BIT(led->reg),
+ value ? BIT(led->reg) : 0);
}
static int cap11xx_init_leds(struct device *dev,
@@ -396,6 +443,14 @@ static int cap11xx_init_leds(struct device *dev,
if (error)
return error;
+ if (num_leds > 8) {
+ error = regmap_update_bits(priv->regmap,
+ priv->model->led_output_control_reg_base + 1,
+ GENMASK(num_leds - 8 - 1, 0), 0);
+ if (error)
+ return error;
+ }
+
duty_val = FIELD_PREP(CAP11XX_REG_LED_DUTY_MAX_MASK,
CAP11XX_REG_LED_DUTY_MAX_VALUE);
@@ -573,6 +628,14 @@ static const struct cap11xx_hw_model cap1106_model = {
.has_repeat_en = true,
};
+static const struct cap11xx_hw_model cap1114_model = {
+ .product_id = 0x3a,
+ .num_channels = 14, .num_leds = 11, .num_sensor_thresholds = 8,
+ .led_output_control_reg_base = CAP1114_REG_LED_OUTPUT_CONTROL1,
+ .sensor_input_reg_base = CAP1114_REG_BUTTON_STATUS1,
+ .has_grouped_sensors = true,
+};
+
static const struct cap11xx_hw_model cap1126_model = {
.product_id = 0x53,
.num_channels = 6, .num_leds = 2, .num_sensor_thresholds = 6,
@@ -629,6 +692,7 @@ static const struct cap11xx_hw_model cap1298_model = {
static const struct of_device_id cap11xx_dt_ids[] = {
{ .compatible = "microchip,cap1106", .data = &cap1106_model },
+ { .compatible = "microchip,cap1114", .data = &cap1114_model },
{ .compatible = "microchip,cap1126", .data = &cap1126_model },
{ .compatible = "microchip,cap1188", .data = &cap1188_model },
{ .compatible = "microchip,cap1203", .data = &cap1203_model },
@@ -641,6 +705,7 @@ MODULE_DEVICE_TABLE(of, cap11xx_dt_ids);
static const struct i2c_device_id cap11xx_i2c_ids[] = {
{ .name = "cap1106", .driver_data = (kernel_ulong_t)&cap1106_model },
+ { .name = "cap1114", .driver_data = (kernel_ulong_t)&cap1114_model },
{ .name = "cap1126", .driver_data = (kernel_ulong_t)&cap1126_model },
{ .name = "cap1188", .driver_data = (kernel_ulong_t)&cap1188_model },
{ .name = "cap1203", .driver_data = (kernel_ulong_t)&cap1203_model },
--
2.54.0
^ permalink raw reply related
* [PATCH v3 09/10] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support.
Add the compatible string for CAP1114, add its datasheet URL,
update the maximum of LED channel reg, and add constraint for
linux,keycodes.
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.
Update description for microchip,input-threshold: CAP1114 only provides
eight threshold entries, which does not match its total channel count.
CAP1114 does not support microchip,signal-guard and
microchip,calib-sensitivity.
Add CAP1114 to the unsupported enum list.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
.../bindings/input/microchip,cap11xx.yaml | 37 ++++++++++++++++++-
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
index 778ec6d659a8..153099d59d1a 100644
--- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
+++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
@@ -12,6 +12,7 @@ description: |
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
@@ -62,7 +64,7 @@ properties:
linux,keycodes:
minItems: 3
- maxItems: 8
+ maxItems: 14
description: |
Specifies an array of numeric keycode values to
be used for the channels. If this property is
@@ -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.
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
label: true
@@ -178,6 +182,21 @@ allOf:
properties:
reset-gpios: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,cap1114
+ then:
+ properties:
+ linux,keycodes:
+ minItems: 14
+ else:
+ properties:
+ linux,keycodes:
+ maxItems: 8
+
- if:
properties:
compatible:
@@ -205,12 +224,26 @@ allOf:
reg:
maximum: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,cap1188
+ then:
+ patternProperties:
+ "^led@":
+ properties:
+ reg:
+ maximum: 7
+
- if:
properties:
compatible:
contains:
enum:
- microchip,cap1106
+ - microchip,cap1114
- microchip,cap1126
- microchip,cap1188
- microchip,cap1203
--
2.54.0
^ permalink raw reply related
* [PATCH v3 08/10] Input: cap11xx - guard unsupported DT properties before parsing
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
Check of_property_present() before parsing microchip,calib-sensitivity
and microchip,signal-guard, so that models which do not support these
properties (e.g. CAP1114) skip the parsing entirely.
This prevents a potential buffer overflow in calib_sensitivities[8] and
signal_guard_inputs_mask when a model with more than 8 channels
(CAP1114 has 14) would otherwise call of_property_read_u32_array()
with num_channels as the element count.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
drivers/input/keyboard/cap11xx.c | 52 +++++++++++++++++---------------
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 2e9382a721e9..c48ee8520a27 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -224,10 +224,13 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
}
}
- if (!of_property_read_u32_array(node, "microchip,calib-sensitivity",
- priv->calib_sensitivities,
- priv->model->num_channels)) {
- if (priv->model->has_sensitivity_control) {
+ if (of_property_present(node, "microchip,calib-sensitivity")) {
+ if (!priv->model->has_sensitivity_control) {
+ dev_warn(dev,
+ "This model doesn't support 'calib-sensitivity'\n");
+ } else if (!of_property_read_u32_array(node, "microchip,calib-sensitivity",
+ priv->calib_sensitivities,
+ priv->model->num_channels)) {
for (i = 0; i < priv->model->num_channels; i++) {
if (!is_power_of_2(priv->calib_sensitivities[i]) ||
priv->calib_sensitivities[i] > 4) {
@@ -247,32 +250,31 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
if (error)
return error;
}
- } else {
- dev_warn(dev,
- "This model doesn't support 'calib-sensitivity'\n");
}
}
- for (i = 0; i < priv->model->num_channels; i++) {
- if (!of_property_read_u32_index(node, "microchip,signal-guard",
- i, &u32_val)) {
- if (u32_val > 1)
- return -EINVAL;
- if (u32_val)
- priv->signal_guard_inputs_mask |= 0x01 << i;
- }
- }
-
- if (priv->signal_guard_inputs_mask) {
- if (priv->model->has_signal_guard) {
- error = regmap_write(priv->regmap,
- CAP11XX_REG_SIGNAL_GUARD_ENABLE,
- priv->signal_guard_inputs_mask);
- if (error)
- return error;
- } else {
+ if (of_property_present(node, "microchip,signal-guard")) {
+ if (!priv->model->has_signal_guard) {
dev_warn(dev,
"This model doesn't support 'signal-guard'\n");
+ } else {
+ for (i = 0; i < priv->model->num_channels; i++) {
+ if (!of_property_read_u32_index(node, "microchip,signal-guard",
+ i, &u32_val)) {
+ if (u32_val > 1)
+ return -EINVAL;
+ if (u32_val)
+ priv->signal_guard_inputs_mask |= 0x01 << i;
+ }
+ }
+
+ if (priv->signal_guard_inputs_mask) {
+ error = regmap_write(priv->regmap,
+ CAP11XX_REG_SIGNAL_GUARD_ENABLE,
+ priv->signal_guard_inputs_mask);
+ if (error)
+ return error;
+ }
}
}
--
2.54.0
^ permalink raw reply related
* [PATCH v3 07/10] Input: cap11xx - refactor code for better CAP1114 support.
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
Extend cap11xx_hw_model structure to support CAP1114 with
different register offsets and hardware characteristics:
- led_output_control_reg_base: different address on CAP1114
- sensor_input_reg_base: different address on CAP1114
- num_sensor_thresholds: separate value from num_channels for CAP1114
- has_repeat_en: repeat enable support, disabled by default on CAP1114
Include linux/bits.h, update the register operations related to LEDs.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
drivers/input/keyboard/cap11xx.c | 73 +++++++++++++++++++++++---------
1 file changed, 53 insertions(+), 20 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 3d75c0f90752..2e9382a721e9 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -5,6 +5,7 @@
* (c) 2014 Daniel Mack <linux@zonque.org>
*/
+#include <linux/bits.h>
#include <linux/delay.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -35,7 +36,6 @@
#define CAP11XX_REG_LED_DUTY_CYCLE_4 0x93
#define CAP11XX_REG_LED_DUTY_MAX_MASK (0xf0)
-#define CAP11XX_REG_LED_DUTY_MAX_MASK_SHIFT (4)
#define CAP11XX_REG_LED_DUTY_MAX_VALUE (15)
#define CAP11XX_REG_PRODUCT_ID 0xfd
@@ -76,10 +76,14 @@ struct cap11xx_priv {
struct cap11xx_hw_model {
u8 product_id;
+ u8 led_output_control_reg_base;
+ u8 sensor_input_reg_base;
unsigned int num_channels;
unsigned int num_leds;
+ unsigned int num_sensor_thresholds;
bool has_gain;
bool has_irq_config;
+ bool has_repeat_en;
bool has_sensitivity_control;
bool has_signal_guard;
};
@@ -204,8 +208,8 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
}
if (!of_property_read_u32_array(node, "microchip,input-threshold",
- priv->thresholds, priv->model->num_channels)) {
- for (i = 0; i < priv->model->num_channels; i++) {
+ priv->thresholds, priv->model->num_sensor_thresholds)) {
+ for (i = 0; i < priv->model->num_sensor_thresholds; i++) {
if (priv->thresholds[i] > 127) {
dev_err(dev, "Invalid input-threshold value %u\n",
priv->thresholds[i]);
@@ -279,10 +283,12 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
of_property_read_u32_array(node, "linux,keycodes",
priv->keycodes, priv->model->num_channels);
- /* Disable autorepeat. The Linux input system has its own handling. */
- error = regmap_write(priv->regmap, CAP11XX_REG_REPEAT_RATE, 0);
- if (error)
- return error;
+ if (priv->model->has_repeat_en) {
+ /* Disable autorepeat. The Linux input system has its own handling. */
+ error = regmap_write(priv->regmap, CAP11XX_REG_REPEAT_RATE, 0);
+ if (error)
+ return error;
+ }
return 0;
}
@@ -301,7 +307,7 @@ static irqreturn_t cap11xx_thread_func(int irq_num, void *data)
if (ret < 0)
goto out;
- ret = regmap_read(priv->regmap, CAP11XX_REG_SENSOR_INPUT, &status);
+ ret = regmap_read(priv->regmap, priv->model->sensor_input_reg_base, &status);
if (ret < 0)
goto out;
@@ -355,7 +361,7 @@ static int cap11xx_led_set(struct led_classdev *cdev,
* 0 (OFF) and 1 (ON).
*/
return regmap_update_bits(priv->regmap,
- CAP11XX_REG_LED_OUTPUT_CONTROL,
+ priv->model->led_output_control_reg_base,
BIT(led->reg),
value ? BIT(led->reg) : 0);
}
@@ -367,6 +373,7 @@ static int cap11xx_init_leds(struct device *dev,
struct cap11xx_led *led;
int cnt = of_get_child_count(node);
int error;
+ u32 duty_val;
if (!num_leds || !cnt)
return 0;
@@ -380,15 +387,18 @@ static int cap11xx_init_leds(struct device *dev,
priv->leds = led;
+ /* Set all LEDs to off */
error = regmap_update_bits(priv->regmap,
- CAP11XX_REG_LED_OUTPUT_CONTROL, 0xff, 0);
+ priv->model->led_output_control_reg_base,
+ GENMASK(min(num_leds, 8) - 1, 0), 0);
if (error)
return error;
+ duty_val = FIELD_PREP(CAP11XX_REG_LED_DUTY_MAX_MASK,
+ CAP11XX_REG_LED_DUTY_MAX_VALUE);
+
error = regmap_update_bits(priv->regmap, CAP11XX_REG_LED_DUTY_CYCLE_4,
- CAP11XX_REG_LED_DUTY_MAX_MASK,
- CAP11XX_REG_LED_DUTY_MAX_VALUE <<
- CAP11XX_REG_LED_DUTY_MAX_MASK_SHIFT);
+ CAP11XX_REG_LED_DUTY_MAX_MASK, duty_val);
if (error)
return error;
@@ -553,41 +563,64 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
}
static const struct cap11xx_hw_model cap1106_model = {
- .product_id = 0x55, .num_channels = 6, .num_leds = 0,
+ .product_id = 0x55,
+ .num_channels = 6, .num_leds = 0, .num_sensor_thresholds = 6,
+ .sensor_input_reg_base = CAP11XX_REG_SENSOR_INPUT,
.has_gain = true,
.has_irq_config = true,
+ .has_repeat_en = true,
};
static const struct cap11xx_hw_model cap1126_model = {
- .product_id = 0x53, .num_channels = 6, .num_leds = 2,
+ .product_id = 0x53,
+ .num_channels = 6, .num_leds = 2, .num_sensor_thresholds = 6,
+ .led_output_control_reg_base = CAP11XX_REG_LED_OUTPUT_CONTROL,
+ .sensor_input_reg_base = CAP11XX_REG_SENSOR_INPUT,
.has_gain = true,
.has_irq_config = true,
+ .has_repeat_en = true,
};
static const struct cap11xx_hw_model cap1188_model = {
- .product_id = 0x50, .num_channels = 8, .num_leds = 8,
+ .product_id = 0x50,
+ .num_channels = 8, .num_leds = 8, .num_sensor_thresholds = 8,
+ .led_output_control_reg_base = CAP11XX_REG_LED_OUTPUT_CONTROL,
+ .sensor_input_reg_base = CAP11XX_REG_SENSOR_INPUT,
.has_gain = true,
.has_irq_config = true,
+ .has_repeat_en = true,
};
static const struct cap11xx_hw_model cap1203_model = {
- .product_id = 0x6d, .num_channels = 3, .num_leds = 0,
+ .product_id = 0x6d,
+ .num_channels = 3, .num_leds = 0, .num_sensor_thresholds = 3,
+ .sensor_input_reg_base = CAP11XX_REG_SENSOR_INPUT,
+ .has_repeat_en = true,
};
static const struct cap11xx_hw_model cap1206_model = {
- .product_id = 0x67, .num_channels = 6, .num_leds = 0,
+ .product_id = 0x67,
+ .num_channels = 6, .num_leds = 0, .num_sensor_thresholds = 6,
+ .sensor_input_reg_base = CAP11XX_REG_SENSOR_INPUT,
+ .has_repeat_en = true,
};
static const struct cap11xx_hw_model cap1293_model = {
- .product_id = 0x6f, .num_channels = 3, .num_leds = 0,
+ .product_id = 0x6f,
+ .num_channels = 3, .num_leds = 0, .num_sensor_thresholds = 3,
+ .sensor_input_reg_base = CAP11XX_REG_SENSOR_INPUT,
.has_gain = true,
+ .has_repeat_en = true,
.has_sensitivity_control = true,
.has_signal_guard = true,
};
static const struct cap11xx_hw_model cap1298_model = {
- .product_id = 0x71, .num_channels = 8, .num_leds = 0,
+ .product_id = 0x71,
+ .num_channels = 8, .num_leds = 0, .num_sensor_thresholds = 8,
+ .sensor_input_reg_base = CAP11XX_REG_SENSOR_INPUT,
.has_gain = true,
+ .has_repeat_en = true,
.has_sensitivity_control = true,
.has_signal_guard = true,
};
--
2.54.0
^ permalink raw reply related
* [PATCH v3 06/10] Input: cap11xx - add reset gpio support
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
Some CAP11xx devices (CAP1126/CAP1188) have a dedicated RESET pin.
Add hardware reset operation to improve device reliability and
ensure proper initialization on probe.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
drivers/input/keyboard/cap11xx.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 686174722204..3d75c0f90752 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -5,6 +5,7 @@
* (c) 2014 Daniel Mack <linux@zonque.org>
*/
+#include <linux/delay.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/interrupt.h>
@@ -43,6 +44,9 @@
#define CAP11XX_MANUFACTURER_ID 0x5d
+#define CAP11XX_T_RST_FILT_MIN_US 10000
+#define CAP11XX_T_RST_ON_MIN_MS 400
+
#ifdef CONFIG_LEDS_CLASS
struct cap11xx_led {
struct cap11xx_priv *priv;
@@ -55,6 +59,7 @@ struct cap11xx_priv {
struct regmap *regmap;
struct device *dev;
struct input_dev *idev;
+ struct gpio_desc *reset_gpio;
const struct cap11xx_hw_model *model;
struct cap11xx_led *leds;
@@ -452,6 +457,16 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
+ priv->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(priv->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
+ "Failed to get 'reset' GPIO\n");
+ else if (priv->reset_gpio) {
+ usleep_range(CAP11XX_T_RST_FILT_MIN_US, CAP11XX_T_RST_FILT_MIN_US * 2);
+ gpiod_set_value_cansleep(priv->reset_gpio, 0);
+ msleep(CAP11XX_T_RST_ON_MIN_MS);
+ }
+
error = regmap_read(priv->regmap, CAP11XX_REG_PRODUCT_ID, &val);
if (error)
return dev_err_probe(dev, error, "Failed to read product ID\n");
--
2.54.0
^ permalink raw reply related
* [PATCH v3 05/10] dt-bindings: input: microchip,cap11xx: Add reset-gpios property
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, Conor Dooley, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
Add support for the optional reset-gpios property to describe
the active-high reset pin for CAP1126/CAP1188 devices.
Driving the GPIO high asserts reset and deep sleep, while driving
it low releases reset for normal operation.
Restrict this property to be available only on CAP1126 and CAP1188
chips, as other CAP11xx variants do not have a hardware reset pin.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../bindings/input/microchip,cap11xx.yaml | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
index 22a292d4a880..778ec6d659a8 100644
--- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
+++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
@@ -49,6 +49,13 @@ properties:
device's ALERT#/CM_IRQ# pin is connected to.
The device only has one interrupt source.
+ reset-gpios:
+ description: |
+ GPIO connected to the active-high RESET pin of the chip;
+ driving it high asserts reset and deep sleep, while driving
+ it low releases reset for normal operation.
+ maxItems: 1
+
autorepeat:
description: |
Enables the Linux input system's autorepeat feature on the input device.
@@ -157,6 +164,20 @@ patternProperties:
allOf:
- $ref: input.yaml
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,cap1106
+ - microchip,cap1203
+ - microchip,cap1206
+ - microchip,cap1293
+ - microchip,cap1298
+ then:
+ properties:
+ reset-gpios: false
+
- if:
properties:
compatible:
@@ -207,6 +228,8 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
+
i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -228,6 +251,8 @@ examples:
<109>, /* KEY_PAGEDOWN */
<104>; /* KEY_PAGEUP */
+ reset-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+
#address-cells = <1>;
#size-cells = <0>;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 04/10] dt-bindings: input: microchip,cap11xx: Add microchip,cap1126 LED reg constraints
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
Apply per-chip LED channel limits:
- CAP1126: max 2 channels (0-1)
- CAP1188: max 8 channels (0-7)
- CAP1106, CAP12xx: no LED support
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
.../bindings/input/microchip,cap11xx.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
index 9578c7c206a2..22a292d4a880 100644
--- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
+++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
@@ -171,6 +171,19 @@ allOf:
patternProperties:
"^led@": false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,cap1126
+ then:
+ patternProperties:
+ "^led@":
+ properties:
+ reg:
+ maximum: 1
+
- if:
properties:
compatible:
--
2.54.0
^ permalink raw reply related
* [PATCH v3 03/10] dt-bindings: input: microchip,cap11xx: Update datasheet URL and LED reg range
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
- Add datasheet links for all supported CAP11xx variants.
- Update LED node regex and replace enum constraints with minimum/maximum
for LED reg ranges in preparation for CAP1114 support.
CAP1114 has 11 LED channels. minimum/maximum constraints are easier to
maintain than long enum lists when expanding channel count later.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
.../bindings/input/microchip,cap11xx.yaml | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
index 7ade03f1b32b..9578c7c206a2 100644
--- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
+++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
@@ -10,6 +10,15 @@ description: |
The Microchip CAP1xxx Family of RightTouchTM multiple-channel capacitive
touch controllers and LED drivers. The device communication via I2C only.
+ For more product information please see the links below:
+ CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.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
+ CAP1206: https://ww1.microchip.com/downloads/en/DeviceDoc/00001567B.pdf
+ CAP1293: https://ww1.microchip.com/downloads/en/DeviceDoc/00001566B.pdf
+ CAP1298: https://ww1.microchip.com/downloads/en/DeviceDoc/00001571B.pdf
+
maintainers:
- Rob Herring <robh@kernel.org>
@@ -124,14 +133,16 @@ properties:
The number of entries must correspond to the number of channels.
patternProperties:
- "^led@[0-7]$":
+ "^led@[0-9a-f]$":
type: object
description: CAP11xx LEDs
$ref: /schemas/leds/common.yaml#
properties:
reg:
- enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ description: LED channel number
+ minimum: 0
+ maximum: 7
label: true
@@ -158,7 +169,7 @@ allOf:
- microchip,cap1298
then:
patternProperties:
- "^led@[0-7]$": false
+ "^led@": false
- if:
properties:
--
2.54.0
^ permalink raw reply related
* [PATCH v3 02/10] Input: cap11xx - remove unused register macros
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
Remove unused register address macros and unused definitions in
the cap11xx_reg_defaults array and cap11xx_volatile_reg.
This cleanup reduces code clutter and makes the driver easier to
maintain without affecting functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
drivers/input/keyboard/cap11xx.c | 58 --------------------------------
1 file changed, 58 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 485d8ba97723..686174722204 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -20,53 +20,23 @@
#define CAP11XX_REG_MAIN_CONTROL_GAIN_SHIFT (6)
#define CAP11XX_REG_MAIN_CONTROL_GAIN_MASK (0xc0)
#define CAP11XX_REG_MAIN_CONTROL_DLSEEP BIT(4)
-#define CAP11XX_REG_GENERAL_STATUS 0x02
#define CAP11XX_REG_SENSOR_INPUT 0x03
-#define CAP11XX_REG_NOISE_FLAG_STATUS 0x0a
-#define CAP11XX_REG_SENOR_DELTA(X) (0x10 + (X))
#define CAP11XX_REG_SENSITIVITY_CONTROL 0x1f
#define CAP11XX_REG_SENSITIVITY_CONTROL_DELTA_SENSE_MASK 0x70
-#define CAP11XX_REG_CONFIG 0x20
-#define CAP11XX_REG_SENSOR_ENABLE 0x21
-#define CAP11XX_REG_SENSOR_CONFIG 0x22
-#define CAP11XX_REG_SENSOR_CONFIG2 0x23
-#define CAP11XX_REG_SAMPLING_CONFIG 0x24
-#define CAP11XX_REG_CALIBRATION 0x26
-#define CAP11XX_REG_INT_ENABLE 0x27
#define CAP11XX_REG_REPEAT_RATE 0x28
#define CAP11XX_REG_SIGNAL_GUARD_ENABLE 0x29
-#define CAP11XX_REG_MT_CONFIG 0x2a
-#define CAP11XX_REG_MT_PATTERN_CONFIG 0x2b
-#define CAP11XX_REG_MT_PATTERN 0x2d
-#define CAP11XX_REG_RECALIB_CONFIG 0x2f
#define CAP11XX_REG_SENSOR_THRESH(X) (0x30 + (X))
-#define CAP11XX_REG_SENSOR_NOISE_THRESH 0x38
-#define CAP11XX_REG_STANDBY_CHANNEL 0x40
-#define CAP11XX_REG_STANDBY_CONFIG 0x41
-#define CAP11XX_REG_STANDBY_SENSITIVITY 0x42
-#define CAP11XX_REG_STANDBY_THRESH 0x43
#define CAP11XX_REG_CONFIG2 0x44
#define CAP11XX_REG_CONFIG2_ALT_POL BIT(6)
-#define CAP11XX_REG_SENSOR_BASE_CNT(X) (0x50 + (X))
-#define CAP11XX_REG_LED_POLARITY 0x73
#define CAP11XX_REG_LED_OUTPUT_CONTROL 0x74
#define CAP11XX_REG_CALIB_SENSITIVITY_CONFIG 0x80
#define CAP11XX_REG_CALIB_SENSITIVITY_CONFIG2 0x81
-
-#define CAP11XX_REG_LED_DUTY_CYCLE_1 0x90
-#define CAP11XX_REG_LED_DUTY_CYCLE_2 0x91
-#define CAP11XX_REG_LED_DUTY_CYCLE_3 0x92
#define CAP11XX_REG_LED_DUTY_CYCLE_4 0x93
-#define CAP11XX_REG_LED_DUTY_MIN_MASK (0x0f)
-#define CAP11XX_REG_LED_DUTY_MIN_MASK_SHIFT (0)
#define CAP11XX_REG_LED_DUTY_MAX_MASK (0xf0)
#define CAP11XX_REG_LED_DUTY_MAX_MASK_SHIFT (4)
#define CAP11XX_REG_LED_DUTY_MAX_VALUE (15)
-#define CAP11XX_REG_SENSOR_CALIB (0xb1 + (X))
-#define CAP11XX_REG_SENSOR_CALIB_LSB1 0xb9
-#define CAP11XX_REG_SENSOR_CALIB_LSB2 0xba
#define CAP11XX_REG_PRODUCT_ID 0xfd
#define CAP11XX_REG_MANUFACTURER_ID 0xfe
#define CAP11XX_REG_REVISION 0xff
@@ -111,37 +81,15 @@ struct cap11xx_hw_model {
static const struct reg_default cap11xx_reg_defaults[] = {
{ CAP11XX_REG_MAIN_CONTROL, 0x00 },
- { CAP11XX_REG_GENERAL_STATUS, 0x00 },
- { CAP11XX_REG_SENSOR_INPUT, 0x00 },
- { CAP11XX_REG_NOISE_FLAG_STATUS, 0x00 },
{ CAP11XX_REG_SENSITIVITY_CONTROL, 0x2f },
- { CAP11XX_REG_CONFIG, 0x20 },
- { CAP11XX_REG_SENSOR_ENABLE, 0x3f },
- { CAP11XX_REG_SENSOR_CONFIG, 0xa4 },
- { CAP11XX_REG_SENSOR_CONFIG2, 0x07 },
- { CAP11XX_REG_SAMPLING_CONFIG, 0x39 },
- { CAP11XX_REG_CALIBRATION, 0x00 },
- { CAP11XX_REG_INT_ENABLE, 0x3f },
{ CAP11XX_REG_REPEAT_RATE, 0x3f },
- { CAP11XX_REG_MT_CONFIG, 0x80 },
- { CAP11XX_REG_MT_PATTERN_CONFIG, 0x00 },
- { CAP11XX_REG_MT_PATTERN, 0x3f },
- { CAP11XX_REG_RECALIB_CONFIG, 0x8a },
{ CAP11XX_REG_SENSOR_THRESH(0), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(1), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(2), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(3), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(4), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(5), 0x40 },
- { CAP11XX_REG_SENSOR_NOISE_THRESH, 0x01 },
- { CAP11XX_REG_STANDBY_CHANNEL, 0x00 },
- { CAP11XX_REG_STANDBY_CONFIG, 0x39 },
- { CAP11XX_REG_STANDBY_SENSITIVITY, 0x02 },
- { CAP11XX_REG_STANDBY_THRESH, 0x40 },
{ CAP11XX_REG_CONFIG2, 0x40 },
- { CAP11XX_REG_LED_POLARITY, 0x00 },
- { CAP11XX_REG_SENSOR_CALIB_LSB1, 0x00 },
- { CAP11XX_REG_SENSOR_CALIB_LSB2, 0x00 },
};
static bool cap11xx_volatile_reg(struct device *dev, unsigned int reg)
@@ -149,12 +97,6 @@ static bool cap11xx_volatile_reg(struct device *dev, unsigned int reg)
switch (reg) {
case CAP11XX_REG_MAIN_CONTROL:
case CAP11XX_REG_SENSOR_INPUT:
- case CAP11XX_REG_SENOR_DELTA(0):
- case CAP11XX_REG_SENOR_DELTA(1):
- case CAP11XX_REG_SENOR_DELTA(2):
- case CAP11XX_REG_SENOR_DELTA(3):
- case CAP11XX_REG_SENOR_DELTA(4):
- case CAP11XX_REG_SENOR_DELTA(5):
return true;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v3 01/10] Input: cap11xx - clean up duplicate log and add probe error logs
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-1-jerrysteve1101@gmail.com>
Duplicated device detection log exists at line 537 and line 542,
which brings redundant kernel print messages. Drop one redundant
log entry to clean up dmesg output.
Meanwhile add missing error logs when I2C communication fails
during driver probe(), helping debug.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
drivers/input/keyboard/cap11xx.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 2447c1ae2166..485d8ba97723 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -512,7 +512,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
error = regmap_read(priv->regmap, CAP11XX_REG_PRODUCT_ID, &val);
if (error)
- return error;
+ return dev_err_probe(dev, error, "Failed to read product ID\n");
if (val != cap->product_id) {
dev_err(dev, "Product ID: Got 0x%02x, expected 0x%02x\n",
@@ -522,7 +522,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
error = regmap_read(priv->regmap, CAP11XX_REG_MANUFACTURER_ID, &val);
if (error)
- return error;
+ return dev_err_probe(dev, error, "Failed to read manufacturer ID\n");
if (val != CAP11XX_MANUFACTURER_ID) {
dev_err(dev, "Manufacturer ID: Got 0x%02x, expected 0x%02x\n",
@@ -531,11 +531,8 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
}
error = regmap_read(priv->regmap, CAP11XX_REG_REVISION, &rev);
- if (error < 0)
- return error;
-
- dev_info(dev, "CAP11XX detected, model %s, revision 0x%02x\n",
- id->name, rev);
+ if (error)
+ return dev_err_probe(dev, error, "Failed to read revision\n");
priv->model = cap;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 00/10] Input: cap11xx - Add support for CAP1114
From: Jun Yan @ 2026-06-15 14:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support.
Patches 1-4 perform driver cleanup and DT binding tweaks.
Patches 5-6 add reset-gpios support for CAP11xx.
Patches 7-10 add support for CAP1114.
Changes in v3:
- Simplified the logic of the reset pin operation.
- Adjust linux,keycodes configuration for CAP11xx.
- Drop unnecessary CAP11XX_REG_SENSOR_THRESH(8).
- Checks for the presence of microchip,calib-sensitivity and
microchip,signal-guard properties before processing them.
- Link to v2:
https://lore.kernel.org/all/20260612072237.1177304-1-jerrysteve1101@gmail.com/
Changes in v2:
- Drop LED property tweaks, keep only reg changes and node regex
update in DT bindings.
- Split microchip,cap1126 LED reg constraints into a separate patch.
- Replace usleep_range() with msleep() for 500 ms delay during
reset pin handling.
- Add missing <linux/delay.h> for usleep_range() and msleep().
- Add CAP1114 to unsupported enum for microchip,signal-guard and
microchip,calib-sensitivity
- Add constraint for linux,keycodes to support CAP1114.
- When reading CAP1114 button status, mask STATUS1 to bits 0-5
and OR with STATUS2.
- Adjust code style.
- Link to v1:
https://lore.kernel.org/all/20260606150458.250606-1-jerrysteve1101@gmail.com
Jun Yan (10):
Input: cap11xx - clean up duplicate log and add probe error logs
Input: cap11xx - remove unused register macros
dt-bindings: input: microchip,cap11xx: Update datasheet URL and LED
reg range
dt-bindings: input: microchip,cap11xx: Add microchip,cap1126 LED reg
constraints
dt-bindings: input: microchip,cap11xx: Add reset-gpios property
Input: cap11xx - add reset gpio support
Input: cap11xx - refactor code for better CAP1114 support.
Input: cap11xx - guard unsupported DT properties before parsing
dt-bindings: input: microchip,cap11xx: Add CAP1114 support
Input: cap11xx - add support for CAP1114
.../bindings/input/microchip,cap11xx.yaml | 90 +++++-
drivers/input/keyboard/cap11xx.c | 280 +++++++++++-------
2 files changed, 253 insertions(+), 117 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH net-next v7 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct
From: Christian Marangi @ 2026-06-15 14:18 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <371a1df7-084c-4431-bd00-0045298e3212@bootlin.com>
On Mon, Jun 15, 2026 at 03:33:34PM +0200, Maxime Chevallier wrote:
> Hello Christian,
>
> On 6/15/26 14:29, Christian Marangi wrote:
> > Add in phylink struct a copy of supported_interfaces from phylink_config
> > and make use of that instead of relying on phylink_config value.
> >
> > This in preparation for support of PCS handling internally to phylink
> > where a PCS can be removed or added after the phylink is created and we
> > need both a reference of the supported_interfaces value from
> > phylink_config and an internal value that can be updated with the new
> > PCS info.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> > drivers/net/phy/phylink.c | 22 +++++++++++++++-------
> > 1 file changed, 15 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > index 087ac63f9193..4d59c0dd78db 100644
> > --- a/drivers/net/phy/phylink.c
> > +++ b/drivers/net/phy/phylink.c
> > @@ -60,6 +60,11 @@ struct phylink {
> > /* The link configuration settings */
> > struct phylink_link_state link_config;
> >
> > + /* What interface are supported by the current link.
> > + * Can change on removal or addition of new PCS.
> > + */
> > + DECLARE_PHY_INTERFACE_MASK(supported_interfaces);
>
> Can you clarify a bit what you mean here ? Is that the combination of the
> interfaces the MAC supports AND the currently in-use PCS ?
>
Combination of interface the MAC supports and the currently attached PCS
(not the current one in use)
The fact that it can change is due to the fact that PCS can be attached
later and supported_interfaces can be updated accordingly.
--
Ansuel
^ permalink raw reply
* Re: [PATCH net-next v7 02/12] net: phylink: introduce internal phylink PCS handling
From: Christian Marangi @ 2026-06-15 14:17 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <3bbacda3-4225-4536-a4b4-3aa31a47a3aa@bootlin.com>
On Mon, Jun 15, 2026 at 03:31:20PM +0200, Maxime Chevallier wrote:
> Hi Christian,
>
> On 6/15/26 14:29, Christian Marangi wrote:
> > Introduce internal handling of PCS for phylink. This is an alternative
> > way to .mac_select_pcs that moves the selection logic of the PCS entirely
> > to phylink with the usage of the supported_interface value in the PCS
> > struct.
> >
> > MAC should now provide a callback to fill the available PCS in
> > phylink_config in .fill_available_pcs and fill the .num_possible_pcs with
> > the number of elements in the array. MAC should also define a new bitmap,
> > pcs_interfaces, in phylink_config to define for what interface mode a
> > dedicated PCS is required.
> >
> > On phylink_create(), an array of PCS pointer is allocated of size
> > .num_possible_pcs from phylink_config and .fill_available_pcs from
> > phylink_config is called passing as args the just allocated array and
> > the number of possible element in it.
> >
> > MAC will fill this passed array with all the available PCS.
> >
> > This array is then parsed and a linked list of PCS is created based on
> > the allocated PCS array filled by MAC via .fill_available_pcs().
> >
> > Every PCS in phylink PCS list gets then linked to the phylink instance
> > by setting the phylink value in phylink_pcs struct to the phylink instance.
> > Also the supported_interface value in phylink struct is updated with
> > the new supported_interface from the provided PCS.
> >
> > On phylink_destroy(), every PCS in phylink PCS list is unlinked from the
> > phylink instance by setting the phylink value in phylink_pcs struct to NULL
> > and removed from the PCS list.
> >
> > phylink_validate_mac_and_pcs(), phylink_major_config() and
> > phylink_inband_caps() are updated to support this new implementation
> > with the PCS list stored in phylink.
> >
> > They will make use of phylink_validate_pcs_interface() that will loop
> > for every PCS in the phylink PCS available list and find one that supports
> > the passed interface.
> >
> > phylink_validate_pcs_interface() applies the same logic of .mac_select_pcs
> > where if a supported_interface value is not set for the PCS struct, then
> > it's assumed every interface is supported.
> >
> > A MAC is required to implement either a .mac_select_pcs or make use of
> > the PCS list implementation. Implementing both will result in a fail
> > on phylink_create().
> >
> > A MAC defining .num_possible_pcs in phylink_config MUST also define a
> > .fill_available_pcs or phylink_create() will fail with an negative error.
> >
> > phylink value in phylink_pcs struct with this implementation is used to
> > track from PCS side when it's attached to a phylink instance. PCS driver
> > will make use of this information to correctly detach from a phylink
> > instance if needed.
> >
> > phylink_pcs_change() is also changed to verify that the PCS that triggered
> > a link change is the one that is currently used by the phylink instance.
> >
> > The .mac_select_pcs implementation is not changed but it's expected that
> > every MAC driver migrates to the new implementation to later deprecate
> > and remove .mac_select_pcs.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
>
> [...]
>
> > @@ -1872,10 +1993,28 @@ struct phylink *phylink_create(struct phylink_config *config,
> > mutex_init(&pl->phydev_mutex);
> > mutex_init(&pl->state_mutex);
> > INIT_WORK(&pl->resolve, phylink_resolve);
> > + INIT_LIST_HEAD(&pl->pcs_list);
> > +
> > + /* Fill the PCS list with available PCS from phylink config */
> > + ret = phylink_fill_available_pcs(pl, config);
> > + if (ret < 0) {
> > + kfree(pl);
> > + return ERR_PTR(ret);
> > + }
> > +
> > + /* Link available PCS to phylink */
> > + list_for_each_entry(pcs, &pl->pcs_list, list)
> > + pcs->phylink = pl;
> >
> > phy_interface_copy(pl->supported_interfaces,
> > config->supported_interfaces);
> >
> > + /* Update supported interfaces */
> > + list_for_each_entry(pcs, &pl->pcs_list, list)
> > + phy_interface_or(pl->supported_interfaces,
> > + pl->supported_interfaces,
> > + pcs->supported_interfaces);
> > +
>
> I'm not entirely sure about that, we may need to restrict the supported_interfaces
> from the MAC.
>
> As an example, take mvpp2. We have 2 PCSs, one for BaseX/SGMII, one for BaseR. But
> if we don't have a comphy (generic PHY) device, then we can't use all the
> combination of modes our PCSs can provide :
>
> https://elixir.bootlin.com/linux/v7.1-rc7/source/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c#L7074
>
> These aren't external PCS IPs, but from what I understand you'd like to
> handle these the same way as purely external PCSs, right ?
>
> I'd say the MAC driver utltimately has the knowledge of all possible interfaces.
>
> The way I see it, it's probably safer to let the MAC give a wide range of interfaces,
> and filter that down with what the PCSs can provide (i.e. turn that or into an and,
> while handling the case where the pcs supported interfaces is empty).
>
> What do you think ?
>
The idea is that supported_interface is a mask of every possible interface
from MAC and PCS. Then it's phylink_validate_mac_and_pcs that actually use
that mask and validates it on both MAC and PCS.
This is why the OR was used instead of AND. The idea is to have the PCS as
external standalone entry (even if they are internal to the MAC). So each
entry should have they own set of supported mask.
The previous patch and this try to address this problem where phylink is
actually clueless of what is actually supported exactly because it's has
been given MAC too much freedom of modelling limitation internally.
I feel limitation should be handled by their dedicated function with
.pcs_validate and .mac_get_caps.
Just my idea on this, if needed it's totally ok to simplify this and let
MAC entirely handle the mask. (but I feel the current idea of phylink code
was to have a generic mask in supported_interfaces and then verify MAC and
PCS in phylink_validate_mac_and_pcs())
But by thinking on it more, following your case of mvpp2, with this new
PCS:
- You need a PCS for the .get_state.
- And such PCS will have the supported interface set 1000baseX and
2500BaseX (as that is what is actually supported in HW)
Either some magic is done in .pcs_validate to deny changing the interface
that was initially configured or this gets limited at the
supported_interface configured by the MAC.
I need to check if this might be problematic for the other driver where
this is being used on OpenWrt but maybe changing the logic to an AND might
be sensible for these kind of case.
(for the other it shouldn't change anything)
--
Ansuel
^ permalink raw reply
* Re: [PATCH v2 3/5] pinctrl: samsung: Add Exynos8855 pinctrl configuration
From: Peter Griffin @ 2026-06-15 14:14 UTC (permalink / raw)
To: Alim Akhtar
Cc: krzk, robh, conor+dt, linusw, linux-samsung-soc, linux-kernel,
devicetree, linux-gpio, hajun.sung
In-Reply-To: <20260615085252.1964423-4-alim.akhtar@samsung.com>
Hi Alim,
Thanks for your patch. It's great to see more Exynos SoCs being supported!
On Mon, 15 Jun 2026 at 09:34, Alim Akhtar <alim.akhtar@samsung.com> wrote:
>
> Add pinctrl configuration for Exynos8855. The bank type
> macros are reused from Exynos850 SoC.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
> .../pinctrl/samsung/pinctrl-exynos-arm64.c | 123 ++++++++++++++++++
> drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +
> drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
> 3 files changed, 126 insertions(+)
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> index fe9f92cb037e..db120ae4d847 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> @@ -943,6 +943,129 @@ const struct samsung_pinctrl_of_match_data exynos850_of_data __initconst = {
> .num_ctrl = ARRAY_SIZE(exynos850_pin_ctrl),
> };
>
Are you sure you want to use E850 pinctrl macros and not the GS101
ones? The GS101 macros allow the fltcon offset to be specified, which
I think is required for all Exynos9 (including e850 SoC). Youngmin
sent a series previously
https://lore.kernel.org/lkml/20251202093613.852109-1-youngmin.nam@samsung.com/
fixing up some of this but it hasn't been re-spun in a while. In
particular this patch
https://lore.kernel.org/lkml/20251202093613.852109-4-youngmin.nam@samsung.com/.
> +/* pin banks of exynos8855 pin-controller 0 (ALIVE) */
> +static const struct samsung_pin_bank_data exynos8855_pin_banks0[] __initconst = {
> + /* Must start with EINTG banks, ordered by EINT group number. */
> + EXYNOS850_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
> + EXYNOS850_PIN_BANK_EINTW(4, 0x020, "gpa1", 0x04),
> + EXYNOS850_PIN_BANK_EINTN(3, 0x040, "gpq0"),
> + EXYNOS850_PIN_BANK_EINTN(2, 0x060, "gpq1"),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x080, "gpc0", 0x10),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x0a0, "gpc1", 0x14),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x0c0, "gpc2", 0x18),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x0e0, "gpc3", 0x1c),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x100, "gpc4", 0x20),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x120, "gpc5", 0x24),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x140, "gpc6", 0x28),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x160, "gpc7", 0x2c),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x180, "gpc8", 0x30),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x1a0, "gpc9", 0x34),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x1c0, "gpc10", 0x38),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x1e0, "gpc11", 0x3c),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x200, "gpc12", 0x40),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x220, "gpc13", 0x44),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x240, "gpc14", 0x48),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x260, "gpj0", 0x4c),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x280, "gpj1", 0x50),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x2a0, "gpj2", 0x54),
> +};
> +
> +/* pin banks of exynos8855 pin-controller 1 (CMGP) */
> +static const struct samsung_pin_bank_data exynos8855_pin_banks1[] __initconst = {
> + EXYNOS850_PIN_BANK_EINTW(1, 0x00, "gpm0", 0x00),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x20, "gpm1", 0x04),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x40, "gpm2", 0x08),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x60, "gpm3", 0x0c),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x80, "gpm4", 0x10),
> + EXYNOS850_PIN_BANK_EINTW(1, 0xa0, "gpm5", 0x14),
> + EXYNOS850_PIN_BANK_EINTW(1, 0xc0, "gpm6", 0x18),
> + EXYNOS850_PIN_BANK_EINTW(1, 0xe0, "gpm7", 0x1c),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x100, "gpm8", 0x20),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x120, "gpm9", 0x24),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x140, "gpm10", 0x28),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x160, "gpm11", 0x2c),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x180, "gpm12", 0x30),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x1a0, "gpm13", 0x34),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x1c0, "gpm14", 0x38),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x1e0, "gpm15", 0x3c),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x200, "gpm16", 0x40),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x220, "gpm17", 0x44),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x240, "gpm18", 0x48),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x260, "gpm19", 0x4c),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x280, "gpm20", 0x50),
> + EXYNOS850_PIN_BANK_EINTW(1, 0x2a0, "gpm21", 0x54),
> +};
> +
> +
> +/* pin banks of exynos8855 pin-controller 2 (HSI UFS) */
> +static const struct samsung_pin_bank_data exynos8855_pin_banks2[] __initconst = {
> + EXYNOS850_PIN_BANK_EINTG(2, 0x0, "gpf3", 0x00),
> +};
> +
> +/* pin banks of exynos8855 pin-controller 3 (PERIC) */
> +static const struct samsung_pin_bank_data exynos8855_pin_banks3[] __initconst = {
> + EXYNOS850_PIN_BANK_EINTG(8, 0x0, "gpp0", 0x00),
> + EXYNOS850_PIN_BANK_EINTG(8, 0x20, "gpp1", 0x04),
> + EXYNOS850_PIN_BANK_EINTG(6, 0x40, "gpp2", 0x08),
> + EXYNOS850_PIN_BANK_EINTG(4, 0x60, "gpg0", 0x0c),
> + EXYNOS850_PIN_BANK_EINTG(3, 0x80, "gpg1", 0x10),
> + EXYNOS850_PIN_BANK_EINTG(6, 0xa0, "gpb0", 0x14),
> + EXYNOS850_PIN_BANK_EINTG(4, 0xc0, "gpb1", 0x18),
> +};
> +
> +/* pin banks of exynos8855 pin-controller 4 (PERICMMC) */
> +static const struct samsung_pin_bank_data exynos8855_pin_banks4[] __initconst = {
> + EXYNOS850_PIN_BANK_EINTG(7, 0x0, "gpf2", 0x00),
> +};
> +
> +/* pin banks of exynos8855 pin-controller 5 (USI) */
> +static const struct samsung_pin_bank_data exynos8855_pin_banks5[] __initconst = {
> + EXYNOS850_PIN_BANK_EINTG(8, 0x00, "gpp3", 0x00),
> + EXYNOS850_PIN_BANK_EINTG(2, 0x20, "gpp4", 0x04),
> + EXYNOS850_PIN_BANK_EINTG(2, 0x40, "gpg2", 0x08),
> + EXYNOS850_PIN_BANK_EINTG(1, 0x60, "gpg3", 0x0c),
> +};
> +
> +static const struct samsung_pin_ctrl exynos8855_pin_ctrl[] __initconst = {
> + {
> + /* pin-controller instance 0 ALIVE data */
> + .pin_banks = exynos8855_pin_banks0,
> + .nr_banks = ARRAY_SIZE(exynos8855_pin_banks0),
> + .eint_wkup_init = exynos_eint_wkup_init,
> + .eint_gpio_init = exynos_eint_gpio_init,
> + }, {
With fltcon_offset specified, you could then use
gs101_pinctrl_suspend/gs101_pinctrl_resume callbacks here.
regards,
Peter.
> + /* pin-controller instance 1 CMGP data */
> + .pin_banks = exynos8855_pin_banks1,
> + .nr_banks = ARRAY_SIZE(exynos8855_pin_banks1),
> + .eint_gpio_init = exynos_eint_gpio_init,
> + }, {
> + /* pin-controller instance 2 HSI UFS data */
> + .pin_banks = exynos8855_pin_banks2,
> + .nr_banks = ARRAY_SIZE(exynos8855_pin_banks2),
> + .eint_gpio_init = exynos_eint_gpio_init,
> + }, {
> + /* pin-controller instance 3 PERIC data */
> + .pin_banks = exynos8855_pin_banks3,
> + .nr_banks = ARRAY_SIZE(exynos8855_pin_banks3),
> + .eint_gpio_init = exynos_eint_gpio_init,
> + }, {
> + /* pin-controller instance 4 PERICMMC data */
> + .pin_banks = exynos8855_pin_banks4,
> + .nr_banks = ARRAY_SIZE(exynos8855_pin_banks4),
> + .eint_gpio_init = exynos_eint_gpio_init,
> + }, {
> + /* pin-controller instance 5 USI data */
> + .pin_banks = exynos8855_pin_banks5,
> + .nr_banks = ARRAY_SIZE(exynos8855_pin_banks5),
> + .eint_gpio_init = exynos_eint_gpio_init,
> + },
> +};
> +
> +const struct samsung_pinctrl_of_match_data exynos8855_of_data __initconst = {
> + .ctrl = exynos8855_pin_ctrl,
> + .num_ctrl = ARRAY_SIZE(exynos8855_pin_ctrl),
> +};
> +
> /* pin banks of exynos990 pin-controller 0 (ALIVE) */
> static struct samsung_pin_bank_data exynos990_pin_banks0[] = {
> /* Must start with EINTG banks, ordered by EINT group number. */
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 5ac6f6b02327..5ecc9ed4c44d 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -1500,6 +1500,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
> .data = &exynos7885_of_data },
> { .compatible = "samsung,exynos850-pinctrl",
> .data = &exynos850_of_data },
> + { .compatible = "samsung,exynos8855-pinctrl",
> + .data = &exynos8855_of_data },
> { .compatible = "samsung,exynos8890-pinctrl",
> .data = &exynos8890_of_data },
> { .compatible = "samsung,exynos8895-pinctrl",
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> index 937600430a6e..bb02fb49b2af 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> @@ -396,6 +396,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7_of_data;
> extern const struct samsung_pinctrl_of_match_data exynos7870_of_data;
> extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
> extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
> +extern const struct samsung_pinctrl_of_match_data exynos8855_of_data;
> extern const struct samsung_pinctrl_of_match_data exynos8890_of_data;
> extern const struct samsung_pinctrl_of_match_data exynos8895_of_data;
> extern const struct samsung_pinctrl_of_match_data exynos9610_of_data;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: nuvoton: npcm845-evb: Add peripheral nodes
From: Tomer Maimon @ 2026-06-15 14:13 UTC (permalink / raw)
To: sashiko-reviews; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260610162318.E468D1F00893@smtp.kernel.org>
Hi
On Wed, 10 Jun 2026 at 19:23, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] Missing `/bits/ 8` for `fan-tach-ch` and `cooling-levels` causes incorrect 32-bit integer array emission, corrupting the thermal fan driver state.
> - [High] The `tip_reserved` memory node lacks the `no-map` directive, causing speculative external aborts.
> - [Medium] Incorrect Device Tree property name `spix-mode` prevents the FIU controller from enabling SPIX mode.
> --
>
> commit 011b4946d76e73a81f86b002033d53a6d052bd40
> Author: Tomer Maimon <tmaimon77@gmail.com>
>
> arm64: dts: nuvoton: npcm845-evb: Add peripheral nodes
>
> Enable peripheral support for the NPCM845 evaluation board by wiring up
> the SoC controller nodes to the board design.
>
> > diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
> > index 5edf5d13342da..ea92888d9b9e2 100644
> > --- a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
> > +++ b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
>
> [ ... ]
>
> > @@ -26,12 +62,389 @@ refclk: refclk-25mhz {
> > clock-frequency = <25000000>;
> > #clock-cells = <0>;
> > };
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + tip_reserved: tip@0 {
> > + reg = <0x0 0x0 0x0 0x6200000>;
>
> [Severity: High]
> Does this reserved memory region need the no-map directive?
No, the kernel shouldn't use this memory
>
> Without no-map, the kernel establishes a direct, cacheable linear mapping
> over this region. Since this block is isolated by hardware firewalls for the
> Trusted Information Processing firmware, could speculative execution or
> prefetching by the CPU into this linear mapping trigger fatal synchronous
> external aborts or SErrors?
>
> > + };
> > + };
>
> [ ... ]
>
> > +&fiux {
> > + spix-mode;
>
> [Severity: Medium]
> Is this property missing the vendor prefix?
Would be changed in V5
>
> The SPI driver for the NPCM FIU (drivers/spi/spi-npcm-fiu.c) appears to
> check specifically for the "nuvoton,spix-mode" property. If it is only named
> "spix-mode" here, will the driver fail to detect it and silently fall back
> to standard mode?
>
> > +};
>
> [ ... ]
>
> > +&pwm_fan {
> > + status = "okay";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pwm0_pins &pwm1_pins
> > + &pwm2_pins &pwm3_pins
> > + &pwm4_pins &pwm5_pins
> > + &pwm6_pins &pwm7_pins
> > + &fanin0_pins &fanin1_pins
> > + &fanin2_pins &fanin3_pins
> > + &fanin4_pins &fanin5_pins
> > + &fanin6_pins &fanin7_pins>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + fan@0 {
> > + reg = <0x00>;
> > + fan-tach-ch = <0x0 0x1>;
> > + cooling-levels = <127 255>;
>
> [Severity: High]
> Should these arrays be explicitly sized using /bits/ 8?
Could be used 32 bits.
>
> The Device Tree compiler natively emits 32-bit big-endian integers for this
> syntax. However, if the driver (npcm750-pwm-fan.c) explicitly reads both
> properties using of_property_read_u8_array(), an 8-byte payload like
> <127 255> would be read as 8 individual u8 elements:
> 0, 0, 0, 127, 0, 0, 0, 255.
>
> Does this result in registering intermediate thermal cooling states with a 0
> duty cycle, inadvertently turning the fan off during active cooling requests?
>
> > + };
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260610160816.2828713-1-tmaimon77@gmail.com?part=3
Thanks,
Tomer
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Dmitry Baryshkov @ 2026-06-15 14:11 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Gaurav Kohli, Krzysztof Kozlowski, Bjorn Andersson,
Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Amit Kucheria, Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <9a31bb29-75d7-42fa-b8a8-4155cf85cadf@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 02:30:49PM +0200, Daniel Lezcano wrote:
> Hi Gaurav,
>
> Le 15/06/2026 à 14:12, Gaurav Kohli a écrit :
> >
> >
> > On 6/15/2026 4:04 PM, Daniel Lezcano wrote:
> > > On 6/13/26 13:05, Gaurav Kohli wrote:
> > > >
> > > >
> > > > On 6/13/2026 1:11 PM, Krzysztof Kozlowski wrote:
> > > > > On 12/06/2026 15:52, Gaurav Kohli wrote:
> > > > > >
> > > > > >
> > > > > > On 6/11/2026 5:53 PM, Krzysztof Kozlowski wrote:
> > > > > > > On 11/06/2026 13:12, Gaurav Kohli wrote:
> > > > > > > > > Why? And where is this generic property defined? You cannot just
> > > > > > > > > sprinkle generic properties in random bindings.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Ack, will add why part.
> > > > > > > > These names are matched with the thermal
> > > > > > > > mitigation device identifiers
> > > > > > > > populated by remote firmware over QMI and define
> > > > > > > > mitigation devices are
> > > > > > > > exposed as cooling devices.
> > > > > > >
> > > > > > > No, -names correspond to values passed via DT, not
> > > > > > > some remote firmware.
> > > > > > > The remote firmware should give you interface which
> > > > > > > is explicit and does
> > > > > > > not need such properties.
> > > > > >
> > > > > > thanks Krzysztof for review, We need tmd-names because
> > > > > > of following reasons:
> > > > > >
> > > > > > Following Daniel's series [1], the thermal framework supports
> > > > > > mapping multiple cooling devices per remoteproc/device via indexed
> > > > > > cooling-cells.
> > > > > >
> > > > > > 1) The thermal framework's cooling-maps reference
> > > > > > cooling devices by index (for #cooling-cells = <3>).
> > > > > > Without tmd- names,
> > > > > > there's no way to know which index corresponds to which
> > > > > > TMD, as firmware
> > > > > > may return tmd-names in any order.
> > > > > >
> > > > > > below are the changes post new thermal mapping changes:
> > > > > > DT: tmd-names = "cdsp_sw", "xyz";
> > > > > > Firmware: ["cdsp_sw", "xyz1", "xyz2",]
> > > > > > Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index 1)
> > > > >
> > > > > names property are not to instruct drivers to register or not to
> > > > > register something.
> > > > >
> > > > > I don't understand the problem and explanation in the binding is
> > > > > basically non-existing.
> > > > >
> > > > > Remember that all lists and indices ARE FIXED, so driver knows exactly
> > > > > which index means what.
> > > > >
> > > >
> > > > thanks for review, shall i use driver data, which is basically
> > > > pas data structure like below:
> > > >
> > > > static const struct qcom_pas_data {
> > > > .crash_reason_smem = 601,
> > > > .firmware_name = "cdsp.mdt",
> > > > .tmd_names = (const char *[]){"xyz", NULL},
> > > > .num_tmds = 1,
> > > >
> > > > Is something like above acceptable? and this will also help to
> > > > filter tmd names as well?
> > >
> > >
> > > How the thermal framework will bind the thermal zone with the TMD ?
> > > (node pointer, id) ?
> > >
> >
> > Hi Daniel,
> >
> > thanks for review.
> >
> > With id only, in this case instead of taking tmd names from device tree,
> > qmi_tmd will take tmd name from pas_data(driver) and register with the
> > cooling framework with id only. Please let us know if this looks fine.
> May be I'm missing something but:
>
> - The QMI TMD returns a list of names, not ids
> - The QMI TMD may return the list in different order than assumed
> - The cooling map index points to the name of the TMD in the DT
> - This name is used to match the name in the aformentionned list
> - The index in the list and the id in the DT can differ
Would it be better if we define standard indices for the standard names?
This way we decouple the actual firmware strings from the DT.
> Krzysztof , I don't get why having the TMD names as properties is wrong,
> they describes the existing TMDs on the system and the cooling maps index
> points to the one to be connected with thermal zone.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 2/3] arm64: dts: nuvoton: npcm845: Add peripheral nodes
From: Tomer Maimon @ 2026-06-15 14:11 UTC (permalink / raw)
To: sashiko-reviews; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260610162038.304A01F00893@smtp.kernel.org>
Hi,
On Wed, 10 Jun 2026 at 19:20, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Low] DTC Warning (unit_address_vs_reg): The `apb` node includes a unit address but lacks a `reg` property.
> - [Low] DT Binding Schema Violation: `nuvoton,sysgcr` property is undocumented and forbidden by the ChipIdea USB2 schema.
> --
>
> commit b1b96db36d76cd5dd1f935613798ed29aade275d
> Author: Tomer Maimon <tmaimon77@gmail.com>
>
> arm64: dts: nuvoton: npcm845: Add peripheral nodes
>
> Extend the NPCM845 SoC DTSI with the peripheral controller nodes needed
> by the evaluation board and downstream platforms. Add the Ethernet MACs,
> USB device controllers and PHY, MMC controller, FIU controllers, memory
> controller, RNG, ADC, PWM/FAN controller, and I2C buses. Also add the
> OP-TEE firmware node needed to describe these blocks.
>
> > diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
> > index 7976baafb9942..1e21b2704784f 100644
> > --- a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
> > +++ b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
> [ ... ]
> > @@ -51,7 +57,255 @@ clk: rstc: reset-controller@f0801000 {
> > #clock-cells = <1>;
> > };
> >
> > - apb {
> > + gmac1: ethernet@f0804000 {
> [ ... ]
> > + udc8: usb@f0838000 {
> > + compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
> > + reg = <0x0 0xf0838000 0x0 0x1000
> > + 0x0 0xfffef000 0x0 0x800>;
> > + interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk NPCM8XX_CLK_SU>;
> > + clock-names = "clk_usb_bridge";
> > +
> > + nuvoton,sysgcr = <&gcr 0x9C 0xC000 0xC000>;
>
> [Severity: Low]
> Does this undocumented nuvoton,sysgcr property cause a dtbs_check warning?
>
> The USB Device Controllers bind to "nuvoton,npcm750-udc", which is evaluated
> against Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml. This schema
> specifies unevaluatedProperties: false but does not document nuvoton,sysgcr
> internally or in any dependencies.
will be removed at V5
>
> > + phys = <&udc0_phy>;
> > + phy_type = "utmi_wide";
> > + dr_mode = "peripheral";
> > + status = "disabled";
> > + };
> > +
> > + udc9: usb@f0839000 {
> > + compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
> > + reg = <0x0 0xf0839000 0x0 0x1000
> > + 0x0 0xfffef800 0x0 0x800>;
> > + interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk NPCM8XX_CLK_SU>;
> > + clock-names = "clk_usb_bridge";
> > +
> > + nuvoton,sysgcr = <&gcr 0x9C 0x3000 0x3000>;
>
> [Severity: Low]
> Is this the same undocumented property issue as seen above in udc8?
will be removed at V5
>
> > + phys = <&udc0_phy>;
> > + phy_type = "utmi_wide";
> > + dr_mode = "peripheral";
> > + status = "disabled";
> > + };
> > +
> [ ... ]
> > + fiux: spi@fb001000 {
> > + compatible = "nuvoton,npcm845-fiu";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0xfb001000 0x0 0x1000>,
> > + <0x0 0xf8000000 0x0 0x2000000>;
> > + reg-names = "control", "memory";
> > + clocks = <&clk NPCM8XX_CLK_SPIX>;
> > + status = "disabled";
> > + };
> > +
> > + apb: bus@f0000000 {
>
> [Severity: Low]
> Will changing this node name to include the @f0000000 unit address
> trigger a unit_address_vs_reg DTC warning?
>
> According to the Devicetree specification, if a node name includes a
> unit-address, the node must also have a reg property where the first
> address matches the unit-address. Because the apb node defines ranges
> but lacks a reg property, this might introduce build noise.
would be back to apb in V5
>
> > #address-cells = <1>;
> > #size-cells = <1>;
> > compatible = "simple-bus";
> > @@ -59,14 +313,6 @@ apb {
> > ranges = <0x0 0x0 0xf0000000 0x00300000>,
> > <0xfff00000 0x0 0xfff00000 0x00016000>;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260610160816.2828713-1-tmaimon77@gmail.com?part=2
Thanks,
Tomer
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Christian Marangi @ 2026-06-15 14:10 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <867a39de-ccc2-4dcf-be24-ab2542d20ab6@bootlin.com>
On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
> Hi Christian,
>
> On 6/15/26 14:29, Christian Marangi wrote:
> > Add support for late PCS provider attachment to a phylink instance.
> > This works by creating a global notifier for the PCS provider and
> > making each phylink instance that makes use of fwnode subscribe to
> > this notifier.
> >
> > The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
> > a new PCS provider is added.
> >
> > phylink will then react to this event and will call the new function
> > fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
> > provided by the event is present in the pcs-handle property of the
> > phylink instance.
> >
> > If a related PCS is found, then such PCS is added to the phylink
> > instance PCS list.
> >
> > Then we link the PCS to the phylink instance and we refresh the supported
> > interfaces of the phylink instance.
> >
> > Finally we check if we are in a major_config_failed scenario and trigger
> > an interface reconfiguration in the next phylink resolve.
> >
> > In the example scenario where the link was previously torn down due to
> > removal of PCS, the link will be established again as the PCS came back
> > and is now available to phylink.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
>
> [...]
>
> > @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
> > if (pl->link_gpio)
> > gpiod_put(pl->link_gpio);
> >
> > + /* Unregister notifier for late PCS attach */
> > + if (pl->fwnode_pcs_nb.notifier_call)
> > + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>
> I wanted to try this out, but I get :
>
> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | register_fwnode_pcs_notifier
>
> I guess you either need to stub this, or there's a missing Kconfig
> dependency somewhere
>
Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
the static declaration for unregister_fwnode_pcs_notifier.
--
Ansuel
^ 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