* [PATCH v2 4/9] dt-bindings: input: microchip,cap11xx: Add microchip,cap1126 LED reg constraints
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-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 v2 5/9] dt-bindings: input: microchip,cap11xx: Add reset-gpios property
From: Jun Yan @ 2026-06-12 7:22 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: <20260612072237.1177304-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 v2 6/9] Input: cap11xx - add reset gpio support
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-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 | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 686174722204..75746a8a2233 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,17 @@ 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_LOW);
+ if (IS_ERR(priv->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
+ "Failed to get 'reset' GPIO\n");
+ if (priv->reset_gpio) {
+ gpiod_set_value_cansleep(priv->reset_gpio, 1);
+ 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 v2 7/9] Input: cap11xx - refactor code for better CAP1114 support.
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-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 75746a8a2233..d45bb231d7a1 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(num_leds - 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;
@@ -554,41 +564,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 v2 8/9] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-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 | 32 ++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml 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: |
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.
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,18 @@ allOf:
properties:
reset-gpios: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,cap1114
+ then:
+ properties:
+ linux,keycodes:
+ minItems: 14
+ maxItems: 14
+
- if:
properties:
compatible:
@@ -205,12 +221,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 v2 9/9] Input: cap11xx - add support for CAP1114
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-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 | 74 ++++++++++++++++++++++++++++++--
1 file changed, 70 insertions(+), 4 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index d45bb231d7a1..e4da0e26c34a 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,9 @@ 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_SENSOR_THRESH(8), 0x40 },
{ CAP11XX_REG_CONFIG2, 0x40 },
};
@@ -106,6 +116,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;
}
@@ -283,6 +299,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);
@@ -311,6 +338,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));
@@ -360,10 +402,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,
@@ -394,6 +442,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);
@@ -572,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,
@@ -628,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 },
@@ -640,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
* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add IPQ9650 PCIe PHY support
From: Dmitry Baryshkov @ 2026-06-12 7:24 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <a7952e7d-468e-4ad4-8d95-f6bfe9305170@oss.qualcomm.com>
On Fri, Jun 12, 2026 at 12:13:04PM +0530, Kathiravan Thirumoorthy wrote:
>
> On 6/12/2026 11:44 AM, Dmitry Baryshkov wrote:
> > On Fri, Jun 12, 2026 at 08:22:02AM +0530, Kathiravan Thirumoorthy wrote:
> > > On 6/12/2026 1:52 AM, Dmitry Baryshkov wrote:
> > > > On Tue, Jun 09, 2026 at 03:46:56PM +0530, Kathiravan Thirumoorthy wrote:
> > > > > On 6/8/2026 12:26 PM, Dmitry Baryshkov wrote:
> > > > > > On Tue, Jun 02, 2026 at 02:40:18PM +0530, Kathiravan Thirumoorthy wrote:
> > > > > > > The IPQ9650 platform has three Gen3 2-lane PCIe controllers and two Gen3
> > > > > > > 1-lane PCIe controllers. The PHY instances also require the on-chip refgen
> > > > > > > supply.
> > > > > > >
> > > > > > > Add the IPQ9650 Gen3 x1 and x2 QMP PCIe PHY configurations, including the
> > > > > > > refgen regulator supply.
> > > > > > >
> > > > > > > Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> > > > > > > ---
> > > > > > > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 220 +++++++++++++++++++++++++++++++
> > > > > > > 1 file changed, 220 insertions(+)
> > > > > > >
> > > > > > > @@ -3378,6 +3524,10 @@ static const char * const qmp_phy_vreg_l[] = {
> > > > > > > "vdda-phy", "vdda-pll",
> > > > > > > };
> > > > > > > +static const char * const ipq9650_qmp_phy_vreg_l[] = {
> > > > > > > + "refgen",
> > > > > > > +};
> > > > > > Now vdda-phy / vdda-pll supplies?
> > > > > Cross checked with HW team again. Along with refgen, there is a on-chip LDO
> > > > > which supplies fixed voltage to the PHYs. It is enabled upon system power on
> > > > > and no SW intervention is required.
> > > > What is it being powered by? MX? CX?
> > > It is driven by CX.
> > I assume that there is no CX collapse on IPQ9650? Is CX not scaling on
> > this chip. Please provide some details on the commit message.
>
> That's right. No CX collapse on IPQ9650. Let me rewrite the commit message
> as below. Hope its okay.
>
> --
>
> Add support for the IPQ9650 platform, which includes three Gen3 x2 PCIe
> controllers and two Gen3 x1 PCIe controllers. The PHY instances require the
> on-chip refgen supply.
>
> Add the IPQ9650 Gen3 x1 and x2 QMP PCIe PHY configurations along with the
> refgen regulator supply. Note that an on-chip LDO, driven by the SoC CX,
> supplies the PHY voltages without requiring software control. Note that CX
> power collapse is not supported on IPQ9650.
...neither CX power collapse nor rail scaling...
LGTM.
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH 1/1] ARM: dts: aspeed: g6: Add AST2600 pwm tacho controller
From: Grégoire Layet @ 2026-06-12 7:23 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: Grégoire Layet, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
It use the existing ast2600-pwm-tach driver.
Placed according to bus adresses ordering.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 189bc3bbb47c..818d486b94ac 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -102,6 +102,15 @@ ahbc: bus@1e600000 {
reg = <0x1e600000 0x100>;
};
+ pwm_tach: pwm-tach-controller@1e610000 {
+ compatible = "aspeed,ast2600-pwm-tach";
+ reg = <0x1e610000 0x100>;
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ resets = <&syscon ASPEED_RESET_PWM>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
fmc: spi@1e620000 {
reg = <0x1e620000 0xc4>, <0x20000000 0x10000000>;
#address-cells = <1>;
--
2.51.2
^ permalink raw reply related
* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: Wandun @ 2026-06-12 7:28 UTC (permalink / raw)
To: Baoquan He
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, Rob Herring, saravanak,
bhe, rppt, pjw, palmer, aou, chenhuacai, kernel, catalin.marinas,
will, alex, akpm, pasha.tatashin, pratyush, ruirui.yang,
m.szyprowski, robin.murphy
In-Reply-To: <aiqkKe1gXPZ5LZ7t@MiWiFi-R3L-srv>
On 6/11/26 20:03, Baoquan He wrote:
> On 06/11/26 at 11:09am, Wandun wrote:
>>
>>
>> On 6/11/26 10:09, Wandun wrote:
>>>
>>>
>>> On 5/27/26 11:29, Wandun Chen wrote:
>>>> From: Wandun Chen <chenwandun@lixiang.com>
>>>>
>>>> On SoCs that carve out large firmware-owned reserved memory (GPU
>>>> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
>>>> those carveouts as part of system RAM even though their contents are
>>>> firmware state that is not useful for kernel crash analysis.
>>>>
>>>> This series introduces an opt-in 'dumpable' flag [1] on struct
>>>> reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on
>>>> DT-based architectures (arm64, riscv, loongarch). By default reserved
>>>> regions are treated as non-dumpable; CMA regions are explicitly opted
>>>> in because their pages are returned to the buddy allocator and may
>>>> carry key crash-analysis data.
>>>>
>>>> The series is organized as follows:
>>>> Patches 1-3: Pre-existing fixes and a small prep change.
>>>> Patches 4-5: Restructure to allow appending /memreserve/ entries.
>>>> Patches 6-7: Add a dumpable flag and append /memreserve/ entries.
>>>> Patch 8: Add generic kdump helpers.
>>>> Patches 9-11: Wire the helpers into arm64, riscv and loongarch kdump
>>>> elfcorehdr preparation.
>>> Hi,
>>>
>>> Gentle ping on this series.
>>>
>>> Status summary:
>>> -patch 03: respun separately per Rob's suggestion, picked up for 7.2
>>> -patch 06: Acked-by: Marek Szyprowski -patch 09: Acked-by: Will Deacon
>>> The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
>>> awaiting review. your feedback would be greately appreciated. I know we
>>> are at the end of 7.1 -rc cycle, I don't want to rush this series, just
>>> collecting more feedback, and will send next version based on 7.2-rc1.
>>> If spliting the series into smaller logical group would make review
>>> easier, please let me know. Best regards, Wandun
>>
>> Apologies for the formatting issue in my previous email.
>> Here is the properly formatted version.
>>
>> Gentle ping on this series.
>
> Thanks for the effort, the overral looks good to me at 1st glance. I will
> check if there's concern on generic part. And meanwhile, I am wondering
> if there's any chance x86 or other ARCH-es w/o OF/FDT can also choose to
> not dump some areas, e.g GPU stolen memory. Surely, that's another story.
Thanks for the review, Baoquan.
IIUC, reserved memory is already excluded from vmcore on x86.
Reserved memory is typed as E820_TYPE_RESERVED in the e820 table, and
insert into iomem resource tree with IORESOURCE_MEM flag. The x86 kdump
patch uses walk_system_ram_res() which scan iomem resource tree, and
only collects ranges with IORESOURCE_SYSTEM_RAM flag, so reserved
regions are excluded.
Best regards,
Wandun
>
>>
>> Status summary:
>> - patch 03: respun separately per Rob's suggestion, picked up for 7.2
>> - patch 06: Acked-by: Marek Szyprowski
>> - patch 09: Acked-by: Will Deacon
>>
>> The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
>> awaiting review. Your feedback would be greatly appreciated.
>>
>> I know we are at the end of 7.1-rc cycle, I don't want to rush this
>> series, just collecting more feedback, and will send next version based
>> on 7.2-rc1.
>>
>> If splitting the series into smaller logical groups would make review
>> easier, please let me know.
>>
>> Best regards,
>> Wandun
>>
>>
>>>>
>>>> v2 --> v3:
>>>> 1. Fix out-of-bounds issue if device tree lacks /reserved-memory node.[2]
>>>> 2. Fix UAF issue when alloc_reserved_mem_array() fails.
>>>> 3. Add some prepare patches.
>>>>
>>>> v1 --> v2:
>>>> 1. v1 added an opt-out DT property ('linux,no-dump'). Per Rob's
>>>> feedback [1], v2 drop that property and exclude reserve memory
>>>> by default.
>>>> 2. Split some prepared patches from the original patches.
>>>> 3. Address coding-style comments on patch 5 from Rob.
>>>>
>>>> [1] https://lore.kernel.org/lkml/20260506144542.GA2072596-
>>>> robh@kernel.org/
>>>> [2] https://sashiko.dev/#/patchset/20260520091844.592753-1-
>>>> chenwandun%40lixiang.com?part=4
>>>>
>>>> Wandun Chen (11):
>>>> of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
>>>> kexec/crash: provide crash_exclude_mem_range() stub when
>>>> CONFIG_CRASH_DUMP=n
>>>> of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()
>>>> fails
>>>> of: reserved_mem: zero total_reserved_mem_cnt if no valid
>>>> /reserved-memory entry
>>>> of: reserved_mem: split alloc_reserved_mem_array() from
>>>> fdt_scan_reserved_mem_late()
>>>> of: reserved_mem: add dumpable flag to opt-in vmcore
>>>> of: reserved_mem: save /memreserve/ entries into the reserved_mem
>>>> array
>>>> of: reserved_mem: add kdump helpers to exclude non-dumpable regions
>>>> arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
>>>> riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
>>>> loongarch: kdump: exclude non-dumpable reserved memory regions from
>>>> vmcore
>>>>
>>>> arch/arm64/kernel/machine_kexec_file.c | 6 ++
>>>> arch/loongarch/kernel/machine_kexec_file.c | 6 ++
>>>> arch/riscv/kernel/machine_kexec_file.c | 4 +
>>>> drivers/of/fdt.c | 11 +-
>>>> drivers/of/of_private.h | 3 +
>>>> drivers/of/of_reserved_mem.c | 117 +++++++++++++++++++--
>>>> include/linux/crash_core.h | 6 ++
>>>> include/linux/of_reserved_mem.h | 15 +++
>>>> kernel/dma/contiguous.c | 1 +
>>>> 9 files changed, 157 insertions(+), 12 deletions(-)
>>>>
>>>
>>
^ permalink raw reply
* Re: [PATCH v2 6/9] Input: cap11xx - add reset gpio support
From: sashiko-bot @ 2026-06-12 7:31 UTC (permalink / raw)
To: Jun Yan; +Cc: linux-input, devicetree, robh, dmitry.torokhov, conor+dt
In-Reply-To: <20260612072237.1177304-7-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Unintended glitch on the reset line during probe due to GPIOD_OUT_LOW initialization.
Pre-existing issues:
- [High] Unvalidated keycodes from Device Tree cause an out-of-bounds heap write.
--
commit 5befbfbb7019f474fe2d2d2e0e3da23976b75ada
Author: Jun Yan <jerrysteve1101@gmail.com>
Input: cap11xx - add reset gpio support
Some CAP11xx devices (CAP1126/CAP1188) have a dedicated RESET pin. Add
hardware reset operation to improve device reliability and ensure proper
initialization on probe.
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 686174722204c..75746a8a22332 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -452,6 +457,17 @@ 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_LOW);
> + if (IS_ERR(priv->reset_gpio))
> + return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
> + "Failed to get 'reset' GPIO\n");
> + if (priv->reset_gpio) {
> + gpiod_set_value_cansleep(priv->reset_gpio, 1);
[Severity: Medium]
Does initializing the reset GPIO with GPIOD_OUT_LOW cause an unintended
glitch on the reset line?
When devm_gpiod_get_optional() is called with GPIOD_OUT_LOW, the GPIO line
is immediately driven to its logical low (inactive) state. If the hardware
or bootloader previously left the device in a reset state, this prematurely
pulls it out of reset.
The driver then immediately calls gpiod_set_value_cansleep() to assert
the reset. This sequence creates an extremely short, unintended
de-assert/assert glitch on the reset pin, which could violate hardware
timing requirements.
Would it be safer to request the reset GPIO with GPIOD_OUT_HIGH (or
GPIOD_ASIS) to guarantee it starts in the logically asserted state before
we hold it for the required minimum duration?
[Severity: High]
This is a pre-existing issue, but does this code overflow the keybit array
if a device tree provides unvalidated keycodes?
Later in cap11xx_i2c_probe(), the driver loops over the keycodes read from
the device tree:
for (i = 0; i < cap->num_channels; i++)
__set_bit(priv->keycodes[i], priv->idev->keybit);
Since __set_bit() does not perform bounds checking, if a device tree
specifies a keycode value greater than or equal to KEY_MAX, this will
write outside the bounds of the keybit array in the input_dev structure,
clobbering adjacent memory in the kernel heap.
Should we add a check against KEY_MAX before setting the bit?
> + 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);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072237.1177304-1-jerrysteve1101@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: talos: Add passive polling-delay for gpu-thermal zone
From: Dmitry Baryshkov @ 2026-06-12 7:32 UTC (permalink / raw)
To: haritha.k
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
manaf.pallikunhi, gaurav.kohli
In-Reply-To: <20260505-qcs615_gpu_cooling-v2-1-1ba42260b29d@oss.qualcomm.com>
On Tue, May 05, 2026 at 04:56:17PM +0530, Haritha S K via B4 Relay wrote:
> From: Haritha S K <haritha.k@oss.qualcomm.com>
>
> Introduce a passive polling delay to ensure more than one
> "passive" thermal point is considered when throttling the GPU
> thermal zone.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
> Signed-off-by: Haritha S K <haritha.k@oss.qualcomm.com>
> ---
> Changes in v2:
> - Updated commit message.
> - Link to v1: https://patch.msgid.link/20260422-qcs615_gpu_cooling-v1-1-d5a984ac29e3@oss.qualcomm.com
> ---
> arch/arm64/boot/dts/qcom/talos.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: aspeed: g6: Add AST2600 pwm tacho controller
From: Andrew Jeffery @ 2026-06-12 7:32 UTC (permalink / raw)
To: Grégoire Layet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260612072341.278591-1-gregoire.layet@9elements.com>
Hi Grégoire,
On Fri, 2026-06-12 at 07:23 +0000, Grégoire Layet wrote:
> It use the existing ast2600-pwm-tach driver.
> Placed according to bus adresses ordering.
>
> Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> index 189bc3bbb47c..818d486b94ac 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> @@ -102,6 +102,15 @@ ahbc: bus@1e600000 {
> reg = <0x1e600000 0x100>;
> };
>
> + pwm_tach: pwm-tach-controller@1e610000 {
> + compatible = "aspeed,ast2600-pwm-tach";
> + reg = <0x1e610000 0x100>;
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + resets = <&syscon ASPEED_RESET_PWM>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> fmc: spi@1e620000 {
> reg = <0x1e620000 0xc4>, <0x20000000 0x10000000>;
> #address-cells = <1>;
Thanks for the patch, however:
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git/commit/?h=aspeed/arm/dt&id=6cf976b2728f2494215c51c7339dd50b154125ce
You can also find the commit in linux-next.git master and soc.git
soc/dt, queued for v7.2.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: pse-pd: add Realtek/Broadcom PSE MCU support
From: Jonas Jelonek @ 2026-06-12 7:32 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Kory Maincent, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, devicetree, linux-kernel, Daniel Golle,
Bjørn Mork
In-Reply-To: <aiqV_10qQahSHXca@pengutronix.de>
Hi Oleksij,
On 11.06.26 13:03, Oleksij Rempel wrote:
> Hi Jonas,
>
> On Mon, Jun 08, 2026 at 08:57:55PM +0000, Jonas Jelonek wrote:
>> This series adds a PSE-PD driver for the microcontroller (MCU) that fronts
>> the PSE silicon on a range of managed switches, together with its DT
>> binding.
>>
>> Hardware model
>> ==============
>>
>> These boards do not expose the PSE chips to the host directly. A small
>> microcontroller sits on an I2C/SMBus or UART bus and manages one or more PSE
>> chips behind it; the host CPU only ever talks to that MCU, using a fixed
>> 12-byte request/response protocol with a trailing checksum. The PSE silicon
>> never appears on the bus.
>>
>> The same protocol family is used by MCUs fronting Realtek PSE chips
>> (RTL8238B, RTL8239, RTL8239C) and Broadcom PSE chips (BCM59111, BCM59121),
>> diverging in opcode numbering and a few response layouts. The driver
>> abstracts that behind a per-dialect opcode table and parser hooks, selected
>> by the compatible. The specific PSE chip behind the MCU is detected at
>> runtime and only influences per-chip constants (power scaling and the
>> per-port cap).
>>
>> Why the compatible names the protocol, not the chip
>> ===================================================
>>
>> The compatibles are "realtek,pse-mcu-rtk" and "realtek,pse-mcu-bcm". This is
>> a deliberate choice and the part most likely to raise questions, so the
>> reasoning up front.
>>
>> The node names the protocol dialect, not a part:
>>
>> - The DT node describes the MCU, not a PSE chip: the PSE chips are behind
>> the MCU and never appear on the bus, so naming the node after one (e.g.
>> "realtek,rtl8239") would describe hardware that isn't at that address.
>>
>> - The PSE chips are, in principle, usable without this MCU (host-driven
>> directly) - different hardware with a different programming model that
>> would warrant its own binding. Claiming the PSE-chip compatibles here
>> would collide with that.
>>
>> - Naming the MCU silicon is equally wrong: these are ordinary
>> general-purpose microcontrollers (GigaDevice, Nuvoton, ...) that vary
>> across boards and are not dedicated to this application.
>>
>> - What is fixed, and all the driver needs at DT-parse time, is the
>> protocol dialect, so the compatible encodes exactly that. The two
>> dialects share one protocol family and one binding, kept in a single
>> "realtek" vendor namespace because this MCU front-end is found almost
>> exclusively on Realtek-based switches; a "-rtk"/"-bcm" suffix selects
>> the dialect. This follows the "google,cros-ec-*" pattern: a compatible
>> for a firmware/protocol interface implemented by varying
>> microcontrollers.
>>
>> One compatible per dialect spans both transports:
>>
>> - The 12-byte wire protocol is identical over I2C/SMBus and UART; only the
>> plumbing differs (SMBus vs native framing on I2C, baud rate on UART),
>> and the transport is already expressed structurally by the node's parent
>> bus (i2c@... vs serial@...). A "-i2c"/"-uart" suffix would only
>> duplicate that, for a protocol that does not change across transports.
>>
>> - This is the multi-transport model used by e.g. "bosch,bmi160" (one
>> compatible, separate i2c and spi drivers binding it), rather than the
>> cros-ec model of per-transport compatibles - cros-ec splits because its
>> on-wire framing genuinely differs per bus, which is not the case here.
>>
>> The binding documents both points as well.
>>
>> Testing
>> =======
>>
>> - Linksys LGS328MPCv2 (RTL8238B, I2C)
>> - Zyxel GS1900-10HP A1 (BCM59121, UART)
>> - Zyxel GS1900-10HP B1 (RTL8238B, UART)
>> - Zyxel XMG1915-10EP (RTL8239C, UART)
>> - Zyxel XS1930-12HP (RTL8239, SMBus)
>>
>
> Thank you for your work!
Thank you!
> Overall, LGTM. Can you please take a look at this report:
> https://sashiko.dev/#/patchset/20260608205758.1830521-1-jelonek.jonas%40gmail.com
>
> kzalloc_obj - seems to be a false positive. Some other have good points.
Yes, I'll have a look and address those issues in v2 soon.
> Best Regards,
> Oleksij
Best,
Jonas
^ permalink raw reply
* Re: [PATCH v2 1/9] Input: cap11xx - clean up duplicate log and add probe error logs
From: sashiko-bot @ 2026-06-12 7:32 UTC (permalink / raw)
To: Jun Yan; +Cc: robh, dmitry.torokhov, linux-input, conor+dt, devicetree
In-Reply-To: <20260612072237.1177304-2-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Threaded interrupt handler returns IRQ_HANDLED on I2C failure, potentially causing an interrupt storm.
--
commit f746dddeb8894305a4dab485d320b84f53191dc0
Author: Jun Yan <jerrysteve1101@gmail.com>
Input: cap11xx - clean up duplicate log and add probe error logs
This commit removes a duplicated device detection log entry to clean up
dmesg output. It also adds missing error logs using dev_err_probe()
when I2C communication fails during the driver's probe sequence.
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 2447c1ae21661..485d8ba977235 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -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;
[Severity: High]
This isn't a bug introduced by this patch, but while looking at I2C failure
handling in this driver, I noticed an issue in cap11xx_thread_func().
If I2C communication fails during the interrupt handler, the code jumps to
the out label:
drivers/input/keyboard/cap11xx.c:cap11xx_thread_func() {
...
ret = regmap_update_bits(priv->regmap, CAP11XX_REG_MAIN_CONTROL, 1, 0);
if (ret < 0)
goto out;
...
out:
return IRQ_HANDLED;
}
Because it unconditionally returns IRQ_HANDLED without deasserting the
hardware interrupt, the level-triggered interrupt line remains active. This
causes the interrupt controller to unmask the IRQ and immediately trigger it
again, creating an infinite loop (interrupt storm) that can lock up the CPU.
Should the handler return IRQ_NONE upon I2C failure so the kernel's spurious
interrupt detector can eventually disable the broken IRQ?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072237.1177304-1-jerrysteve1101@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v2 5/9] dt-bindings: input: microchip,cap11xx: Add reset-gpios property
From: sashiko-bot @ 2026-06-12 7:32 UTC (permalink / raw)
To: Jun Yan; +Cc: robh, dmitry.torokhov, linux-input, devicetree, conor+dt
In-Reply-To: <20260612072237.1177304-6-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The threaded interrupt handler returns IRQ_HANDLED even when it fails to clear the hardware interrupt due to I2C errors.
--
commit ace8e5621e0baa976a27041614c9c01f25526d5e
Author: Jun Yan <jerrysteve1101@gmail.com>
dt-bindings: input: microchip,cap11xx: Add reset-gpios property
This commit adds support for the optional reset-gpios property to describe
the active-high reset pin for CAP1126 and CAP1188 devices. It restricts
this property to only these variants, as other variants lack a hardware
reset pin.
> drivers/input/keyboard/cap11xx.c:cap11xx_thread_func() {
> ...
> ret = regmap_update_bits(priv->regmap, CAP11XX_REG_MAIN_CONTROL, 1, 0);
> if (ret < 0)
> goto out;
>
> ret = regmap_read(priv->regmap, priv->model->sensor_input_reg_base, &status);
> if (ret < 0)
> goto out;
> ...
> out:
> return IRQ_HANDLED;
> }
[Severity: High]
This is a pre-existing issue, but does this error path cause an
interrupt storm?
If the I2C operations regmap_update_bits() or regmap_read() fail, the
function jumps to the out label and returns IRQ_HANDLED instead of
returning IRQ_NONE or disabling the IRQ.
Since the IRQ is registered with IRQF_ONESHOT, returning IRQ_HANDLED tells
the IRQ subsystem to unmask the interrupt line. If the interrupt condition
on the hardware was not successfully cleared due to the I2C failure, will
the interrupt immediately fire again?
This could create an infinite loop of threaded IRQ scheduling that bypasses
the kernel's spurious interrupt detector (which requires IRQ_NONE to
trigger), potentially consuming 100% of a CPU core and causing a soft
lockup.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072237.1177304-1-jerrysteve1101@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v2 7/9] Input: cap11xx - refactor code for better CAP1114 support.
From: sashiko-bot @ 2026-06-12 7:35 UTC (permalink / raw)
To: Jun Yan; +Cc: dmitry.torokhov, linux-input, conor+dt, robh, devicetree
In-Reply-To: <20260612072237.1177304-8-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The input device is registered and exposed to userspace before its threaded IRQ handler is requested, creating a race window where events could be lost or unhandled.
--
commit d2a53f68ed5e5f2311cb5dfaea4bd95be2449ab4
Author: Jun Yan <jerrysteve1101@gmail.com>
Input: cap11xx - refactor code for better CAP1114 support.
Extend cap11xx_hw_model structure to support CAP1114 with
different register offsets and hardware characteristics.
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 75746a8a22332..d45bb231d7a1f 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -554,41 +564,64 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
> }
[Severity: High]
This isn't a bug introduced by this patch, but looking at cap11xx_i2c_probe(),
the input device is registered and exposed to userspace before its threaded
IRQ handler is requested:
error = input_register_device(priv->idev);
if (error)
return error;
error = devm_request_threaded_irq(dev, i2c_client->irq,
NULL, cap11xx_thread_func,
IRQF_ONESHOT, dev_name(dev), priv);
Since input_register_device() makes the device visible to userspace, processes
like udev can immediately open the device. This invokes cap11xx_input_open()
and wakes the hardware from deep sleep.
If a hardware interrupt occurs before devm_request_threaded_irq() registers
the handler, could this unhandled interrupt cause an interrupt storm? The
kernel might then disable the IRQ line ('nobody cared'), rendering the touch
controller permanently inoperable until the module is reloaded or the system
reboots.
Should the IRQ handler be requested before the device is registered?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072237.1177304-1-jerrysteve1101@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: aspeed: g6: Add AST2600 pwm tacho controller
From: sashiko-bot @ 2026-06-12 7:35 UTC (permalink / raw)
To: Grégoire Layet; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260612072341.278591-1-gregoire.layet@9elements.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] The driver's RPM calculation function does not guard against a zero tachometer value, potentially causing a kernel panic via divide-by-zero.
- [High] The driver incorrectly shares a single `tach_divisor` variable across all 16 independent fan channels, leading to incorrect RPM calculations.
- [High] If any child fan node fails to parse, the driver silently aborts initialization but returns success from probe, skipping hwmon registration entirely.
--
commit 557da8ba2550852a62a5729f5acc74635465209e
Author: Grégoire Layet <gregoire.layet@9elements.com>
ARM: dts: aspeed: g6: Add AST2600 pwm tacho controller
This patch adds the device tree node for the AST2600 PWM tachometer
controller, placed according to bus address ordering. It enables the use of
the existing ast2600-pwm-tach driver.
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> index 189bc3bbb47c9..818d486b94ac7 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> @@ -102,6 +102,15 @@ ahbc: bus@1e600000 {
> reg = <0x1e600000 0x100>;
> };
>
> + pwm_tach: pwm-tach-controller@1e610000 {
> + compatible = "aspeed,ast2600-pwm-tach";
[Severity: Critical]
This isn't a bug introduced by this patch, but since this newly added node
enables the use of the ast2600-pwm-tach driver, could the driver trigger a
divide-by-zero panic?
In drivers/hwmon/aspeed-g6-pwm-tach.c:aspeed_get_fan_tach_ch_rpm(), the
hardware status register is read and its raw value is passed to the RPM
calculation function without verifying it is non-zero:
val = FIELD_GET(TACH_ASPEED_VALUE_MASK, val);
return aspeed_tach_val_to_rpm(priv, val);
If the hardware reports 0, tach_div evaluates to 0 in
aspeed_tach_val_to_rpm():
tach_div = tach_val * priv->tach_divisor * DEFAULT_FAN_PULSE_PR;
...
rpm = (u64)priv->clk_rate * 60;
do_div(rpm, tach_div);
Since this evaluates to 0 and is directly passed to do_div() without any
checks, will this result in a kernel panic?
[Severity: High]
This is another pre-existing issue in the driver enabled by this node, but
does the driver incorrectly share a single tach_divisor variable across all 16
independent fan channels?
In drivers/hwmon/aspeed-g6-pwm-tach.c:aspeed_tach_hwmon_write(), updating a
channel's divisor blindly overwrites the global state variable:
priv->tach_divisor = val;
When calculating RPM for any channel in aspeed_tach_val_to_rpm(), it uses this
global divisor instead of retrieving the per-channel hardware configuration:
tach_div = tach_val * priv->tach_divisor * DEFAULT_FAN_PULSE_PR;
Will this corrupt the RPM calculations for all other fan channels if a new
divisor is written to a specific channel?
[Severity: High]
This is also a pre-existing issue, but does the probe function silently abort
initialization on child node parsing failure?
In drivers/hwmon/aspeed-g6-pwm-tach.c:aspeed_pwm_tach_probe():
if (ret) {
dev_warn(dev, "Failed to create fan %d", ret);
return 0;
}
This early return with a 0 (success) code inappropriately exits the probe
function, completely skipping crucial device registration steps like
devm_hwmon_device_register_with_info().
Should the driver either propagate the error or continue to skip the malformed
node instead of aborting hwmon registration entirely?
> + reg = <0x1e610000 0x100>;
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + resets = <&syscon ASPEED_RESET_PWM>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> fmc: spi@1e620000 {
> reg = <0x1e620000 0xc4>, <0x20000000 0x10000000>;
> #address-cells = <1>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072341.278591-1-gregoire.layet@9elements.com?part=1
^ permalink raw reply
* Re: [PATCH v2 8/9] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: sashiko-bot @ 2026-06-12 7:35 UTC (permalink / raw)
To: Jun Yan; +Cc: conor+dt, dmitry.torokhov, linux-input, devicetree, robh
In-Reply-To: <20260612072237.1177304-9-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Schema constraint conflict for `linux,keycodes` makes CAP1114 validation impossible.
- [High] Buffer overflow when parsing `microchip,calib-sensitivity` property for models with >8 channels.
--
commit f0d8405d987f3f3e2623cf6af9274da6bb531e55
Author: Jun Yan <jerrysteve1101@gmail.com>
dt-bindings: input: microchip,cap11xx: Add CAP1114 support
CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support. Add the compatible string for CAP1114,
update maximum LED channels, and add constraints for linux,keycodes.
> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> index 778ec6d659a8d..0e9a1a8a3f3e7 100644
> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
[ ... ]
> @@ -178,6 +182,18 @@ allOf:
> properties:
> reset-gpios: false
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - microchip,cap1114
> + then:
> + properties:
> + linux,keycodes:
> + minItems: 14
> + maxItems: 14
> +
[Severity: High]
This conditional block enforces 14 items for linux,keycodes, but earlier in
the file there is a global constraint that limits it to 8:
linux,keycodes:
minItems: 3
maxItems: 8
Because JSON Schema evaluates global and conditional constraints cumulatively,
any valid CAP1114 node with 14 keycodes will fail dt_binding_check against
the global 8-item limit. Should the global maxItems be increased to 14,
while keeping other models constrained in their respective blocks?
[ ... ]
One additional question regarding the CAP1114 integration with the driver:
[Severity: High]
When CAP1114 support is added to the driver (since num_channels will be 14),
can this lead to an out-of-bounds write?
In drivers/input/keyboard/cap11xx.c, calib_sensitivities is a fixed-size
8-element array:
struct cap11xx_priv {
...
u32 calib_sensitivities[8];
u32 keycodes[];
};
However, during initialization, the driver reads num_channels items into it:
if (!of_property_read_u32_array(node, "microchip,calib-sensitivity",
priv->calib_sensitivities,
priv->model->num_channels)) {
Even though the CAP1114 binding forbids microchip,calib-sensitivity, an
incorrectly configured or malicious device tree providing 14 items could
cause this to overflow the 8-element array by 24 bytes. Does the driver
need to be updated to prevent this when num_channels is greater than 8?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072237.1177304-1-jerrysteve1101@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH v4 10/10] arm64: dts: qcom: shikra: Enable Bluetooth and WiFi on EVK boards
From: Dmitry Baryshkov @ 2026-06-12 7:36 UTC (permalink / raw)
To: Komal Bajaj
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, dmaengine, devicetree, linux-kernel,
linux-pm, Yepuri Siddu, Miaoqing Pan
In-Reply-To: <20260608-shikra-dt-m1-v4-10-2114300594a6@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 06:40:30PM +0530, Komal Bajaj wrote:
> Enable Bluetooth and WiFi connectivity on Shikra CQM, CQS and IQS
> EVK boards using the WCN3988 combo chip.
>
> For Bluetooth, enable uart8 and add WCN3988 Bluetooth node with
> board-specific regulator supplies across CQM, CQS and IQS Shikra
> EVK boards.
>
> For WiFi, introduce the wcn3990-wifi hardware node in shikra.dtsi
> with register space, interrupts, IOMMU configuration and reserved
> memory. The node is kept disabled by default and enabled per-board
> with the appropriate PMIC supply connections and calibration variant
> selection.
>
> Co-developed-by: Yepuri Siddu <yepuri.siddu@oss.qualcomm.com>
> Signed-off-by: Yepuri Siddu <yepuri.siddu@oss.qualcomm.com>
> Co-developed-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 59 +++++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 59 +++++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra-evk.dtsi | 15 +++++++
> arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 67 +++++++++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra.dtsi | 23 ++++++++++
> 5 files changed, 223 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 07/10] arm64: dts: qcom: shikra: Add CDSP, LPAICP, MPSS remoteproc PAS nodes
From: Dmitry Baryshkov @ 2026-06-12 7:37 UTC (permalink / raw)
To: Komal Bajaj
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, dmaengine, devicetree, linux-kernel,
linux-pm, Bibek Kumar Patro
In-Reply-To: <20260608-shikra-dt-m1-v4-7-2114300594a6@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 06:40:27PM +0530, Komal Bajaj wrote:
> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>
> Add nodes for remoteproc PAS loader for CDSP, LPAICP, MPSS subsystem.
>
> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 164 +++++++++++++++++++++++++++++++++++
> 1 file changed, 164 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 08/10] arm64: dts: qcom: shikra: Enable CDSP, LPAICP and MPSS on EVK boards
From: Dmitry Baryshkov @ 2026-06-12 7:38 UTC (permalink / raw)
To: Komal Bajaj
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, dmaengine, devicetree, linux-kernel,
linux-pm, Bibek Kumar Patro
In-Reply-To: <20260608-shikra-dt-m1-v4-8-2114300594a6@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 06:40:28PM +0530, Komal Bajaj wrote:
> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>
> Enable CDSP, LPAICP and MPSS for Qualcomm's Shikra CQM, CQS and
> IQS EVK board.
>
> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 19 +++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 19 +++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 19 +++++++++++++++++++
> 3 files changed, 57 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 9/9] Input: cap11xx - add support for CAP1114
From: sashiko-bot @ 2026-06-12 7:42 UTC (permalink / raw)
To: Jun Yan; +Cc: dmitry.torokhov, linux-input, devicetree, robh, conor+dt
In-Reply-To: <20260612072237.1177304-10-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Buffer overflow when parsing the 'microchip,calib-sensitivity' device tree property for devices with more than 8 channels.
- [Medium] Integer truncation silently drops signal guard configurations for channels 8-13.
- [Low] Out-of-bounds `GENMASK` generates an 11-bit mask for an 8-bit LED control register.
- [Low] Unnecessary 9th threshold register added to regmap defaults.
--
commit a843fc20f78c2766e479b33ffb3dcd6238d1f3f0
Author: Jun Yan <jerrysteve1101@gmail.com>
Input: cap11xx - add support for CAP1114
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.
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index d45bb231d7a1f..e4da0e26c34a8 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -98,6 +105,9 @@ 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_SENSOR_THRESH(8), 0x40 },
[Severity: Low]
Does this code inadvertently add a 9th threshold register?
Since the indexing is 0-based, an 8-threshold device should only need indices
0 through 7.
Register index 8 appears to map to an unused register.
> { CAP11XX_REG_CONFIG2, 0x40 },
> };
[ ... ]
> @@ -394,6 +442,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);
[Severity: Low]
Can this result in an out-of-bounds mask generation when num_leds > 8?
In cap11xx_init_leds() just prior to this addition, the code calls:
error = regmap_update_bits(priv->regmap,
priv->model->led_output_control_reg_base,
GENMASK(num_leds - 1, 0), 0);
When num_leds is 11 for the CAP1114 model, this generates an 11-bit mask
to update an 8-bit register.
While the regmap core safely masks this, should the mask be clamped to
min(num_leds, 8) to accurately reflect the hardware register's capacity?
> + if (error)
> + return error;
> + }
[ ... ]
> @@ -572,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,
[Severity: High]
Does this code overflow the calib_sensitivities array during initialization?
In struct cap11xx_priv, the array is rigidly sized to 8 elements:
u32 calib_sensitivities[8];
u32 keycodes[];
During cap11xx_init_keys(), when parsing "microchip,calib-sensitivity", the
driver reads priv->model->num_channels elements:
of_property_read_u32_array(node, "microchip,calib-sensitivity",
priv->calib_sensitivities,
priv->model->num_channels)
With num_channels set to 14, won't this write 14 elements into an 8-element
array, clobbering the adjacent keycodes flexible array member and potentially
causing memory corruption or a kernel panic?
[Severity: Medium]
Will this configuration lead to integer truncation when parsing the
"microchip,signal-guard" property?
In struct cap11xx_priv, the mask is defined as an 8-bit value:
u8 signal_guard_inputs_mask;
During cap11xx_init_keys(), a loop iterates up to num_channels (14) and shifts
the bits:
priv->signal_guard_inputs_mask |= 0x01 << i;
For channels 8 to 13, won't this bitwise shift exceed the 8-bit variable width
and silently truncate to 0?
Even if the CAP1114 doesn't support signal guards, this drops the bitmask for
the upper channels, bypassing the capability check and failing to emit the
intended 'unsupported' warning.
> + .led_output_control_reg_base = CAP1114_REG_LED_OUTPUT_CONTROL1,
> + .sensor_input_reg_base = CAP1114_REG_BUTTON_STATUS1,
> + .has_grouped_sensors = true,
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072237.1177304-1-jerrysteve1101@gmail.com?part=9
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: aspeed: g6: Add AST2600 pwm tacho controller
From: Grégoire Layet @ 2026-06-12 7:43 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <e865e2e71a39c86a8afb6af49d9ebcf6839a9a2a.camel@codeconstruct.com.au>
Hi Andrew,
Too bad, I didn't looked at the right place.
Thank's !
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
From: Dmitry Baryshkov @ 2026-06-12 7:49 UTC (permalink / raw)
To: Vikash Garodia
Cc: Bryan O'Donoghue, Dikshita Agarwal, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-media, devicetree, linux-kernel
In-Reply-To: <bc9a8075-db42-4de1-a3cc-4f6816681290@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 01:20:59PM +0530, Vikash Garodia wrote:
>
> On 6/10/2026 2:07 AM, Bryan O'Donoghue wrote:
> > On 09/06/2026 17:15, Vikash Garodia wrote:
> > > Document the iris video accelerator used on shikra platforms by adding
> > > the qcom,shikra-iris compatible.
> > >
> > > Although QCM2290 and shikra share the same video hardware and overall
> > > integration, their SMMU programming differs. QCM2290 exposes separate
> > > stream IDs for the video hardware and the Xtensa path, requiring two
> > > explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
> > > equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
> > > and Xtensa isolation requirements, such SMR masking is not applicable on
> > > QCM2290 platforms.
> > > Since shikra uses the same video hardware as QCM2290 and shares the same
> > > programming model and capabilities, it is added as a fallback compatible
> > > to qcom,qcm2290-venus, with conditional handling to allow either one or
> > > two IOMMU entries.
> > >
> > > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > > ---
> > > .../bindings/media/qcom,qcm2290-venus.yaml | 20
> > > ++++++++++ ++++++----
> > > 1 file changed, 16 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-
> > > venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-
> > > venus.yaml
> > > index 5977e7d0a71b4fb5681f1c2094439c251366f01f..895533b9756690d075fd7729e3f805c8e72ff0df
> > > 100644
> > > --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> > > +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> > > @@ -15,12 +15,27 @@ description:
> > >
> > > allOf:
> > > - $ref: qcom,venus-common.yaml#
> > > + - if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + const: qcom,shikra-iris
> >
> > Should this be "iris" in a venus yaml ?
>
> given the vpu core was first enabled on venus and now it same core on a
> different SOC being enabled on iris. There are 2 ways to do this
> 1. Add the compat to existing schema which defines the binding for that core
> i.e existing patch
> 2. Write a new schema (or say duplicate it) with ...shikra-iris.yaml, but
> again, the shikra compat would fallback to "qcom,qcm2290-venus" compat.
> hence even iris yaml would then need to carry the venus *string*.
>
> I followed the first option.
It is a correct approach. However the block should not be called Iris.
If I remember correctly, the core is still named Venus.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Dmitry Baryshkov @ 2026-06-12 7:50 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Stephan Gerhold, Mark Pearson, Rob Herring, Manivannan Sadhasivam,
Greg KH, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Derek J . Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86@vger.kernel.org, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm,
linux-acpi@vger.kernel.org
In-Reply-To: <eftahohsx3bbvmgxuciofjjcrybnsm2qc752hwyt65rb2uwaon@h32nh5fcpo7p>
On Wed, Jun 10, 2026 at 06:44:59PM +0200, Manivannan Sadhasivam wrote:
> On Tue, Mar 31, 2026 at 06:29:51PM +0200, Stephan Gerhold wrote:
> > On Wed, Mar 25, 2026 at 05:36:08PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, Mar 23, 2026 at 01:23:07PM -0400, Mark Pearson wrote:
> > > > On Mon, Mar 23, 2026, at 12:52 PM, Manivannan Sadhasivam wrote:
> > > > > On Mon, Mar 23, 2026 at 06:45:15PM +0200, Dmitry Baryshkov wrote:
> > > > >> On Mon, Mar 23, 2026 at 09:26:04PM +0530, Manivannan Sadhasivam wrote:
> > > > >> > On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
> > > > >> > > On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> > > > >> > > > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > > > >> > > > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >> > > > > >
> > > > >> > > > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > > >> > > > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > >> > > > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > >> > > > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > >> > > > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > >> > > > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > >> > > > > > > > to reuse the Key E binding.
> > > > >> > > > > > >
> > > > >> > > > > > > What is LGA?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Land Grid Array
> > > > >> > > > > >
> > > > >> > > > > > > If not in the spec, is it really something generic?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > > > >> > > > > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > > > >> > > > > > the spec gives room for hardware designers to be as innovative as possible to
> > > > >> > > > > > save the BOM cost.
> > > > >> > > > >
> > > > >> > > > > innovation == incompatible changes
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > Yes, I was trying to sound nice :)
> > > > >> > > >
> > > > >> > > > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > > > >> > > > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> > > > >> > > > >
> > > > >> > > > > Depends if you think that s/w needs to know the differences. Hard to
> > > > >> > > > > say with a sample size of 1.
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > Sure. Will add the 'lenovo' prefix then.
> > > > >> > >
> > > > >> > > Is it really Lenovo? Or is it some other module vendor, whose LGAs are
> > > > >> > > being used by Lenovo?
> > > > >> > >
> > > > >> > > I remember that DB820c also used some kind of a module for the WiFi card
> > > > >> > > (which might be M.2 compatible or might not, I can't find exact docs at
> > > > >> > > this point).
> > > > >> > >
> > > > >> >
> > > > >> > I don't know. These kind of designs might be reused by several vendors. But
> > > > >> > considering that we should not make it generic, I'd go with Lenovo as that's
> > > > >> > the only vendor we know as of now.
> > > > >>
> > > > >> ... and later we learn that other vendors use the same idea /pinout,
> > > > >> then nothing stops us from still telling that it's a
> > > > >> "lenovo,pcie-m2-something-lga".
> > > > >>
> > > > >
> > > > > How do you possibly know whether a single vendor has introduced this form factor
> > > > > or reused by multiple ones? Atleast, I don't have access to such a source to
> > > > > confirm.
> > > > >
> > > > I've not really been following this thread/patchset in detail; but want me to try and check with the T14s platform team if this device is specifically made for us (Lenovo) or not?
> > > > I doubt it is - we just don't do that usually, but I can go and ask the question if it will help resolve this (with the caveat that it could hold up the review for a bit and I may not be able to get a straight answer)
> > > >
> > >
> > > I can drop this specific patch in the meantime.
> > >
> > > > My vote (for what little it's worth) would be to make it non-Lenovo specific. Then when the same part causes issues on another vendors platform I won't get asked questions about why Lenovo is breaking <other vendor> :)
> > > >
> > >
> > > Even if Lenovo prefix is used, it won't break other vendors. Just that we will
> > > end up adding more compatibles.
> > >
> > > Anyhow, I'll wait for your reply and drop this patch for next revision.
> > >
> >
> > If you need a vendor prefix, I think "qcom," would be more appropriate
> > than Lenovo. This form factor is used by most vendors for recent
> > soldered Qualcomm-based wireless cards, not just Lenovo:
> >
> > - Dell XPS 13 9345 has exactly the same soldered M.2 card, I assume
> > there are several other vendors as well.
> >
> > - https://www.sparklan.com/product/wnsq-290be/ is a third-party
> > (Qualcomm-based) M.2 LGA 1620 card, in the block diagram the
> > pinout is called "QM.2 1620 LGA 168pin".
> >
> > - If you press F9 while booting the ThinkPad T14s, you should get to a
> > screen with "Regulatory Information". For the T14s, this screen says
> > "Contains FCC ID: J9C-QCNCM825". This is the WiFi/BT module in the
> > soldered form factor. If you look that up on the FCC website, the
> > applicant for this module is "Qualcomm Technologies, Inc.". This
> > seems to be some kind of "modular certification" that vendors can
> > reuse/adapt without going through the whole process again.
> >
> > Perhaps you should ask around inside Qualcomm? :-)
> >
>
> Sorry for getting back after this long. I did ask around, but our HW folks are
> saying that Qcom is not the first one to use LGA M.2 modules. They claim that
> other vendors also do that.
I think, the idea was that there is no single standard for LGA modules
(please correct me if I'm wrong, I haven't checked the latest PCIe
standards).
>
> But for this specific card, it should be fine to use the 'qcom' prefix as
> apparently the module was supplied by Qcom.
>
> I'll submit the bindings patch together with DTS change for T14s.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
--
With best wishes
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox