* [PATCH v2 9/9] hwmon: adm1275: Support ROHM BD12790
From: Matti Vaittinen @ 2026-06-26 7:26 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen, Matti Vaittinen
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, Wensheng Wang, Matti Vaittinen,
Ashish Yadav, Vasileios Amoiridis, Kim Seer Paller, ChiShih Tsai,
Chris Packham, Robert Coulson, linux-hwmon, devicetree,
linux-kernel, linux-doc
In-Reply-To: <cover.1782458224.git.mazziesaccount@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7213 bytes --]
From: Matti Vaittinen <mazziesaccount@gmail.com>
Add support for ROHM BD12790 hot-swap controller which is largely
similar to Analog Devices adm1272.
The BD12790 uses the same selectable 60V/100V voltage ranges and
15mV/30mV current-sense ranges as the ADM1272, and the same VRANGE
(bit 5) and IRANGE (bit 0) layout in PMON_CONFIG. It therefore uses
a dedicated coefficient table that mirrors adm1272_coefficients, with
the following differences derived from BD12790 datasheet Table 1 (p.18):
- power 60V/30mV: m=17560 (vs. 17561)
- power 100V/30mV: m=10536 (vs. 10535)
- temperature: b=31880 (vs. 31871, reflecting T[11:0] = 4.2*T + 3188)
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Assisted-by: GitHub Copilot:claude-sonnet-4.6
---
Revision history:
v1 => v2: Changes mostly based on the review by Guenter:
- Add own 'case' for the bd12790.
- Don't use wildcard in the macro name.
- Fix the coefficient computation comment for power to take the
shunt-resistor scale into account.
---
drivers/hwmon/pmbus/Kconfig | 4 +-
drivers/hwmon/pmbus/adm1275.c | 79 +++++++++++++++++++++++++++++++++--
2 files changed, 78 insertions(+), 5 deletions(-)
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index b3c27f3b2712..6ebc01e26db3 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -52,8 +52,8 @@ config SENSORS_ADM1275
help
If you say yes here you get hardware monitoring support for Analog
Devices ADM1075, ADM1272, ADM1273, ADM1275, ADM1276, ADM1278, ADM1281,
- ADM1293, ADM1294, ROHM BD12780, and SQ24905C Hot-Swap Controller and
- Digital Power Monitors.
+ ADM1293, ADM1294, ROHM BD12780, ROHM BD12790, and SQ24905C
+ Hot-Swap Controller and Digital Power Monitors.
This driver can also be built as a module. If so, the module will
be called adm1275.
diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
index 81c50fab7687..406b44852376 100644
--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -19,7 +19,7 @@
#include "pmbus.h"
enum chips { adm1075, adm1272, adm1273, adm1275, adm1276, adm1278, adm1281,
- adm1293, adm1294, bd12780, sq24905c };
+ adm1293, adm1294, bd12780, bd12790, sq24905c };
#define ADM1275_MFR_STATUS_IOUT_WARN2 BIT(0)
#define ADM1293_MFR_STATUS_VAUX_UV_WARN BIT(5)
@@ -47,7 +47,7 @@ enum chips { adm1075, adm1272, adm1273, adm1275, adm1276, adm1278, adm1281,
#define ADM1278_VOUT_EN BIT(1)
#define ADM1278_PMON_DEFCONFIG (ADM1278_VOUT_EN | ADM1278_TEMP1_EN | ADM1278_TSFILT)
-/* The BD12780 data sheets mark TSFILT bit as reserved. */
+/* The BD127[89]0 data sheets mark TSFILT bit as reserved. */
#define BD12780_PMON_DEFCONFIG (ADM1278_VOUT_EN | ADM1278_TEMP1_EN)
#define ADM1293_IRANGE_25 0
@@ -136,6 +136,30 @@ static const struct coefficients adm1272_coefficients[] = {
};
+/*
+ * BD12790 coefficients derived from preliminary datasheet, Table 1 (p.18)
+ * and the PMBus direct-format relationship X = (Y * 10^(-R) - b) / m.
+ *
+ * Voltage: V[V] = 14.77e-3 * code (60V) / 24.62e-3 * code (100V)
+ * -> m = 6770, R=-2 / m = 4062, R=-2
+ * Current: code = I[A] * RS * 132802.1 + 2048 (15mV) / * 66401.06 + 2048 (30mV)
+ * -> m = 1328, b = 2048 * 10^(-R) = 20480, R=-1 / m = 664, same b and R
+ * Power: code = k * RS * PIN, k = 35119.94 / 17559.97 / 21071.44 / 10535.72
+ * -> m = round(k / 10^(-3-R)), R=-2 for 60V/15mV, R=-3 for the other three
+ * Temperature: code = 4.2 * T + 3188 -> m = 42, b = 3188 * 10 = 31880, R=-1
+ */
+static const struct coefficients bd12790_coefficients[] = {
+ [0] = { 6770, 0, -2 }, /* voltage, vrange 60V */
+ [1] = { 4062, 0, -2 }, /* voltage, vrange 100V */
+ [2] = { 1328, 20480, -1 }, /* current, vsense range 15mV */
+ [3] = { 664, 20480, -1 }, /* current, vsense range 30mV */
+ [4] = { 3512, 0, -2 }, /* power, vrange 60V, irange 15mV */
+ [5] = { 21071, 0, -3 }, /* power, vrange 100V, irange 15mV */
+ [6] = { 17560, 0, -3 }, /* power, vrange 60V, irange 30mV */
+ [7] = { 10536, 0, -3 }, /* power, vrange 100V, irange 30mV */
+ [8] = { 42, 31880, -1 }, /* temperature */
+};
+
static const struct coefficients adm1275_coefficients[] = {
[0] = { 19199, 0, -2 }, /* voltage, vrange set */
[1] = { 6720, 0, -1 }, /* voltage, vrange not set */
@@ -490,6 +514,7 @@ static const struct i2c_device_id adm1275_id[] = {
{ "adm1293", adm1293 },
{ "adm1294", adm1294 },
{ "bd12780", bd12780 },
+ { "bd12790", bd12790 },
{ "mc09c", sq24905c },
{ }
};
@@ -567,7 +592,8 @@ static int adm1275_probe(struct i2c_client *client)
if (mid->driver_data == adm1272 || mid->driver_data == adm1273 ||
mid->driver_data == adm1278 || mid->driver_data == adm1281 ||
mid->driver_data == adm1293 || mid->driver_data == adm1294 ||
- mid->driver_data == bd12780 || mid->driver_data == sq24905c)
+ mid->driver_data == bd12780 || mid->driver_data == bd12790 ||
+ mid->driver_data == sq24905c)
config_read_fn = i2c_smbus_read_word_data;
else
config_read_fn = i2c_smbus_read_byte_data;
@@ -647,6 +673,7 @@ static int adm1275_probe(struct i2c_client *client)
data->have_power_sampling = true;
coefficients = adm1272_coefficients;
+
vindex = (config & ADM1275_VRANGE) ? 1 : 0;
cindex = (config & ADM1272_IRANGE) ? 3 : 2;
/* pindex depends on the combination of the above */
@@ -679,6 +706,51 @@ static int adm1275_probe(struct i2c_client *client)
if (config & ADM1278_VIN_EN)
info->func[0] |= PMBUS_HAVE_VIN;
break;
+
+ /*
+ * The BD12790 is almost identical to the adm1272. Only the defconfig
+ * and coefficients have minor differences.
+ */
+ case bd12790:
+ data->have_vout = true;
+ data->have_pin_max = true;
+ data->have_temp_max = true;
+ data->have_power_sampling = true;
+
+ coefficients = bd12790_coefficients;
+
+ vindex = (config & ADM1275_VRANGE) ? 1 : 0;
+ cindex = (config & ADM1272_IRANGE) ? 3 : 2;
+ /* pindex depends on the combination of the above */
+ switch (config & (ADM1275_VRANGE | ADM1272_IRANGE)) {
+ case 0:
+ default:
+ pindex = 4;
+ break;
+ case ADM1275_VRANGE:
+ pindex = 5;
+ break;
+ case ADM1272_IRANGE:
+ pindex = 6;
+ break;
+ case ADM1275_VRANGE | ADM1272_IRANGE:
+ pindex = 7;
+ break;
+ }
+ tindex = 8;
+
+ info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
+ PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
+
+ ret = adm1275_enable_vout_temp(data, client, config,
+ BD12780_PMON_DEFCONFIG);
+ if (ret)
+ return ret;
+
+ if (config & ADM1278_VIN_EN)
+ info->func[0] |= PMBUS_HAVE_VIN;
+ break;
case adm1275:
if (device_config & ADM1275_IOUT_WARN2_SELECT)
data->have_oc_fault = true;
@@ -919,6 +991,7 @@ static const struct of_device_id adm1275_of_match[] = {
{ .compatible = "adi,adm1293", },
{ .compatible = "adi,adm1294", },
{ .compatible = "rohm,bd12780", },
+ { .compatible = "rohm,bd12790", },
{ .compatible = "silergy,mc09c", },
{ }
};
--
2.54.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH v2 1/9] dt-bindings: adm1275: ROHM BD12780 hot-swap controller
From: sashiko-bot @ 2026-06-26 7:31 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: devicetree, robh, conor+dt, linux-hwmon
In-Reply-To: <2b7d5bb8cba773d0bba1d6779f0e6daa6a40eed4.1782458224.git.mazziesaccount@gmail.com>
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> Support ROHM BD12780 and BD12780A hot-swap controllers, which are largely
> compatible with the Analog Devices adm1278. Main difference between
> the BD12780 and the BD12780A is, that the BD12780 has one I2C address
> configuration pin more (ADDR3) than the BD12780A.
>
> Introduce own compatibles for both variants but require the BD12780A to
> always have the BD12780 as a fall-back.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782458224.git.mazziesaccount@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v2 4/9] hwmon: adm1275: Support module auto-loading
From: sashiko-bot @ 2026-06-26 7:31 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: devicetree, linux-hwmon, conor+dt, robh
In-Reply-To: <9eca6831f9fe2d781bb88337397c39b10e36f5c6.1782458224.git.mazziesaccount@gmail.com>
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> Populating the i2c_device_id -table is not enough to make the
> driver module automatically load when device-tree node for the
> power-monitor is parsed at boot.
>
> Adding the of_device_id tables causes the driver module to be
> automatically load at boot. Testing has been done with rather old Debian
> system.
>
> When inspecting the generated module-aliases with the insmod, following
> entries seem to be the difference:
>
> alias: of:N*T*Cadi,adm1075C*
> alias: of:N*T*Cadi,adm1075
>
> I suspect these are required for the module loading to work.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782458224.git.mazziesaccount@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v2 6/9] hwmon: adm1275: Support ROHM BD12780
From: sashiko-bot @ 2026-06-26 7:32 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: linux-hwmon, devicetree, conor+dt, robh
In-Reply-To: <e1e6e6218c08b562311356ef9c57378d32c26b08.1782458224.git.mazziesaccount@gmail.com>
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> ROHM BD12780 and BD12780A are hot-swap controllers. They are largely
> similar to Analog Devices ADM1278. Besides the ID registers and some
> added functionality, the BD12780 and BD12780A mark PMON_CONFIG bits
> [15:14] as reserved. Hence TSFILT setting must be omitted on these ICs.
>
> The BD12780 has 3 pins usable for configuring the I2C address. The
> BD12780A lists the ADDR3-pin as "not connect".
>
> Support ROHM BD12780 and BD12780A controllers.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782458224.git.mazziesaccount@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v2 8/9] doc: adm1275: Add ROHM BD12790
From: sashiko-bot @ 2026-06-26 7:32 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: devicetree, conor+dt, robh, linux-hwmon
In-Reply-To: <9bafcfe37190b5a3925e8dcfa3b59f8d240234ba.1782458224.git.mazziesaccount@gmail.com>
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> Add the ROHM BD12790 to the list of the ICs supported by the adm1275
> driver.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782458224.git.mazziesaccount@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH v2 2/9] hwmon: adm1275: Prevent reading uninitialized stack
From: sashiko-bot @ 2026-06-26 7:32 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: linux-hwmon, robh, devicetree, conor+dt
In-Reply-To: <c8ad38e0cdb347261c6245de2b7965e747f28d22.1782458224.git.mazziesaccount@gmail.com>
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> While adding support for the ROHM BD127X0 hot-swap controllers, sashiko
> reported an error in device-name comparison, which can lead to reading
> uninitialized stack memory.
>
> Quoting Sashiko:
>
> This is a pre-existing issue, but I noticed that just before this block in
> adm1275_probe(), there might be an out-of-bounds stack read:
>
> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer);
> if (ret < 0) { ... }
> for (mid = adm1275_id; mid->name[0]; mid++) {
> if (!strncasecmp(mid->name, block_buffer, strlen(mid->name)))
> break;
> }
>
> Since i2c_smbus_read_block_data() reads up to 32 bytes into the
> uninitialized stack array block_buffer without appending a null
> terminator, strncasecmp() could read past the valid bytes returned in ret.
>
> For example, if the device returns a shorter string like "adm12", checking
> it against "adm1275" up to the length of "adm1275" will continue reading
> into uninitialized stack bounds.
>
> Prevent reading uninitialized memory by zeroing the stack array.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782458224.git.mazziesaccount@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 9/9] hwmon: adm1275: Support ROHM BD12790
From: sashiko-bot @ 2026-06-26 7:33 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: linux-hwmon, robh, conor+dt, devicetree
In-Reply-To: <b209c1b47712b69f17b52cfd7a7a38ed76024ca7.1782458224.git.mazziesaccount@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The mathematical formula documented in the comment for computing the power coefficient contradicts the actual mathematically correct implementation in the code.
--
commit 7dff114234776369f1046124af65696c292fcd41
Author: Matti Vaittinen <mazziesaccount@gmail.com>
hwmon: adm1275: Support ROHM BD12790
This commit adds support for the ROHM BD12790 hot-swap controller to the
adm1275 driver. It introduces a dedicated coefficient table for the new
device based on its voltage and current-sense ranges.
> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
> index 81c50fab7687b..406b448523769 100644
> --- a/drivers/hwmon/pmbus/adm1275.c
> +++ b/drivers/hwmon/pmbus/adm1275.c
[ ... ]
> @@ -136,6 +136,30 @@ static const struct coefficients adm1272_coefficients[] = {
>
> };
>
> +/*
> + * BD12790 coefficients derived from preliminary datasheet, Table 1 (p.18)
> + * and the PMBus direct-format relationship X = (Y * 10^(-R) - b) / m.
> + *
> + * Voltage: V[V] = 14.77e-3 * code (60V) / 24.62e-3 * code (100V)
> + * -> m = 6770, R=-2 / m = 4062, R=-2
> + * Current: code = I[A] * RS * 132802.1 + 2048 (15mV) / * 66401.06 + 2048 (30mV)
> + * -> m = 1328, b = 2048 * 10^(-R) = 20480, R=-1 / m = 664, same b and R
> + * Power: code = k * RS * PIN, k = 35119.94 / 17559.97 / 21071.44 / 10535.72
> + * -> m = round(k / 10^(-3-R)), R=-2 for 60V/15mV, R=-3 for the other three
[Severity: Low]
This isn't a bug, but does the formula in this comment correctly document
how the power coefficients are calculated?
If we evaluate m = round(k / 10^(-3-R)) for a value of R=-2 and k=35119.94,
it yields 351199.4. However, the actual code below correctly implements the
value as 3512, which implies the formula should use multiplication rather
than division.
> + * Temperature: code = 4.2 * T + 3188 -> m = 42, b = 3188 * 10 = 31880, R=-1
> + */
> +static const struct coefficients bd12790_coefficients[] = {
> + [0] = { 6770, 0, -2 }, /* voltage, vrange 60V */
> + [1] = { 4062, 0, -2 }, /* voltage, vrange 100V */
> + [2] = { 1328, 20480, -1 }, /* current, vsense range 15mV */
> + [3] = { 664, 20480, -1 }, /* current, vsense range 30mV */
> + [4] = { 3512, 0, -2 }, /* power, vrange 60V, irange 15mV */
> + [5] = { 21071, 0, -3 }, /* power, vrange 100V, irange 15mV */
> + [6] = { 17560, 0, -3 }, /* power, vrange 60V, irange 30mV */
> + [7] = { 10536, 0, -3 }, /* power, vrange 100V, irange 30mV */
> + [8] = { 42, 31880, -1 }, /* temperature */
> +};
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782458224.git.mazziesaccount@gmail.com?part=9
^ permalink raw reply
* [PATCH 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: Gregor Herburger @ 2026-06-26 7:35 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
In-Reply-To: <20260626-rpi-tryboot-v1-0-490b1c4c4970@linutronix.de>
The Raspberry Pi firmware allows to set a reboot mode called tryboot
that allows to try booting from a different partition to allow updating
of the boot partition. Allow reboot mode properties by referencing the
reboot-mode schema.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 983ea80eaec97..30b490e0d9fb3 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -133,11 +133,14 @@ properties:
required:
- compatible
+allOf:
+ - $ref: /schemas/power/reset/reboot-mode.yaml#
+
required:
- compatible
- mboxes
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
--
2.47.3
^ permalink raw reply related
* [PATCH 1/4] firmware: raspberrypi: reorder rpi_firmware_property_tag enum
From: Gregor Herburger @ 2026-06-26 7:35 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
In-Reply-To: <20260626-rpi-tryboot-v1-0-490b1c4c4970@linutronix.de>
The enum was once ordered by tags. The later added tags where added in
a different order. Reorder the tags again.
No functional change intended.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
include/soc/bcm2835/raspberrypi-firmware.h | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe5542..66cc5a426c3c5 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -72,26 +72,26 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
RPI_FIRMWARE_GET_CUSTOMER_OTP = 0x00030021,
RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
+ RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
+ RPI_FIRMWARE_GET_GPIO_CONFIG = 0x00030043,
+ RPI_FIRMWARE_GET_PERIPH_REG = 0x00030045,
RPI_FIRMWARE_GET_THROTTLED = 0x00030046,
RPI_FIRMWARE_GET_CLOCK_MEASURED = 0x00030047,
RPI_FIRMWARE_NOTIFY_REBOOT = 0x00030048,
+ RPI_FIRMWARE_GET_POE_HAT_VAL = 0x00030049,
+ RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
+ RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
+ RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
RPI_FIRMWARE_SET_VOLTAGE = 0x00038003,
RPI_FIRMWARE_SET_TURBO = 0x00038009,
RPI_FIRMWARE_SET_CUSTOMER_OTP = 0x00038021,
RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
- RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
RPI_FIRMWARE_SET_SDHOST_CLOCK = 0x00038042,
- RPI_FIRMWARE_GET_GPIO_CONFIG = 0x00030043,
RPI_FIRMWARE_SET_GPIO_CONFIG = 0x00038043,
- RPI_FIRMWARE_GET_PERIPH_REG = 0x00030045,
RPI_FIRMWARE_SET_PERIPH_REG = 0x00038045,
- RPI_FIRMWARE_GET_POE_HAT_VAL = 0x00030049,
- RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
- RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
- RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
@@ -107,7 +107,6 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_FRAMEBUFFER_GET_PALETTE = 0x0004000b,
RPI_FIRMWARE_FRAMEBUFFER_GET_TOUCHBUF = 0x0004000f,
RPI_FIRMWARE_FRAMEBUFFER_GET_GPIOVIRTBUF = 0x00040010,
- RPI_FIRMWARE_FRAMEBUFFER_RELEASE = 0x00048001,
RPI_FIRMWARE_FRAMEBUFFER_TEST_PHYSICAL_WIDTH_HEIGHT = 0x00044003,
RPI_FIRMWARE_FRAMEBUFFER_TEST_VIRTUAL_WIDTH_HEIGHT = 0x00044004,
RPI_FIRMWARE_FRAMEBUFFER_TEST_DEPTH = 0x00044005,
@@ -117,6 +116,7 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_FRAMEBUFFER_TEST_OVERSCAN = 0x0004400a,
RPI_FIRMWARE_FRAMEBUFFER_TEST_PALETTE = 0x0004400b,
RPI_FIRMWARE_FRAMEBUFFER_TEST_VSYNC = 0x0004400e,
+ RPI_FIRMWARE_FRAMEBUFFER_RELEASE = 0x00048001,
RPI_FIRMWARE_FRAMEBUFFER_SET_PHYSICAL_WIDTH_HEIGHT = 0x00048003,
RPI_FIRMWARE_FRAMEBUFFER_SET_VIRTUAL_WIDTH_HEIGHT = 0x00048004,
RPI_FIRMWARE_FRAMEBUFFER_SET_DEPTH = 0x00048005,
@@ -125,10 +125,10 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_FRAMEBUFFER_SET_VIRTUAL_OFFSET = 0x00048009,
RPI_FIRMWARE_FRAMEBUFFER_SET_OVERSCAN = 0x0004800a,
RPI_FIRMWARE_FRAMEBUFFER_SET_PALETTE = 0x0004800b,
- RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF = 0x0004801f,
- RPI_FIRMWARE_FRAMEBUFFER_SET_GPIOVIRTBUF = 0x00048020,
RPI_FIRMWARE_FRAMEBUFFER_SET_VSYNC = 0x0004800e,
RPI_FIRMWARE_FRAMEBUFFER_SET_BACKLIGHT = 0x0004800f,
+ RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF = 0x0004801f,
+ RPI_FIRMWARE_FRAMEBUFFER_SET_GPIOVIRTBUF = 0x00048020,
RPI_FIRMWARE_VCHIQ_INIT = 0x00048010,
--
2.47.3
^ permalink raw reply related
* [PATCH 0/4] firmware: raspberrypi: Add support for the tryboot mode
From: Gregor Herburger @ 2026-06-26 7:35 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
This adds support for the tryboot mode on Raspberry Pis. As there is no
documentation other than the downstream implementation [0] the
implementation is based on this.
I tested this on Raspberry Pi 5 and therefore I only added the
properties to this devicetree. But afaik this should work on all
Raspberry Pis. I will add it to the correspondings dts if I get some
hardware to test it.
[0] https://github.com/raspberrypi/linux/commit/eb56da0c1925c07e8929ce4c9fe8aeafa7cb8c7b
---
Gregor Herburger (4):
firmware: raspberrypi: reorder rpi_firmware_property_tag enum
dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
firmware: raspberrypi: Add reboot mode support
arm64: dts: broadcom: bcm2712: Add reboot modes to firmware node
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 5 ++++-
.../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 2 ++
drivers/firmware/Kconfig | 1 +
drivers/firmware/raspberrypi.c | 25 ++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 22 ++++++++++---------
5 files changed, 44 insertions(+), 11 deletions(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260623-rpi-tryboot-4292c92b0727
Best regards,
--
Gregor Herburger <gregor.herburger@linutronix.de>
^ permalink raw reply
* [PATCH 3/4] firmware: raspberrypi: Add reboot mode support
From: Gregor Herburger @ 2026-06-26 7:35 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
In-Reply-To: <20260626-rpi-tryboot-v1-0-490b1c4c4970@linutronix.de>
The Raspberry Pi firmware has a tryboot mode where it tries to boot from
another partition. This can be used to create a A/B update schema.
To enable this on the next boot the RPI_FIRMWARE_SET_REBOOT_FLAGS
message must be send to the firmware.
Add support for this by registering a reboot mode driver.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/firmware/Kconfig | 1 +
drivers/firmware/raspberrypi.c | 25 +++++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
3 files changed, 28 insertions(+)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index bbd2155d84838..04bc8263e0017 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -115,6 +115,7 @@ config ISCSI_IBFT
config RASPBERRYPI_FIRMWARE
tristate "Raspberry Pi Firmware Driver"
depends on BCM2835_MBOX
+ select REBOOT_MODE
help
This option enables support for communicating with the firmware on the
Raspberry Pi.
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 0aa322e9a2e73..ba4f723751ef8 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -14,6 +14,7 @@
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/reboot-mode.h>
#include <linux/slab.h>
#include <soc/bcm2835/raspberrypi-firmware.h>
@@ -29,6 +30,7 @@ struct rpi_firmware {
struct mbox_client cl;
struct mbox_chan *chan; /* The property channel. */
struct completion c;
+ struct reboot_mode_driver reboot_mode;
u32 enabled;
struct kref consumers;
@@ -273,10 +275,25 @@ static void devm_rpi_firmware_put(void *data)
rpi_firmware_put(fw);
}
+static int rpi_firmware_reboot_mode_write(struct reboot_mode_driver *reboot,
+ unsigned int magic)
+{
+ struct rpi_firmware *fw = container_of(reboot, struct rpi_firmware,
+ reboot_mode);
+ int ret = 0;
+
+ if (magic)
+ ret = rpi_firmware_property(fw, RPI_FIRMWARE_SET_REBOOT_FLAGS,
+ &magic, sizeof(magic));
+
+ return ret;
+}
+
static int rpi_firmware_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct rpi_firmware *fw;
+ int ret;
/*
* Memory will be freed by rpi_firmware_delete() once all users have
@@ -306,6 +323,12 @@ static int rpi_firmware_probe(struct platform_device *pdev)
rpi_register_hwmon_driver(dev, fw);
rpi_register_clk_driver(dev);
+ fw->reboot_mode.dev = dev;
+ fw->reboot_mode.write = rpi_firmware_reboot_mode_write;
+ ret = devm_reboot_mode_register(dev, &fw->reboot_mode);
+ if (ret)
+ dev_err(dev, "Failed to register reboot mode: %d\n", ret);
+
return 0;
}
@@ -323,6 +346,8 @@ static void rpi_firmware_remove(struct platform_device *pdev)
{
struct rpi_firmware *fw = platform_get_drvdata(pdev);
+ reboot_mode_unregister(&fw->reboot_mode);
+
platform_device_unregister(rpi_hwmon);
rpi_hwmon = NULL;
platform_device_unregister(rpi_clk);
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index 66cc5a426c3c5..f905bff0fb3ea 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -81,6 +81,7 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_GET_POE_HAT_VAL = 0x00030049,
RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
+ RPI_FIRMWARE_GET_REBOOT_FLAGS = 0x00030064,
RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
@@ -92,6 +93,7 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_SDHOST_CLOCK = 0x00038042,
RPI_FIRMWARE_SET_GPIO_CONFIG = 0x00038043,
RPI_FIRMWARE_SET_PERIPH_REG = 0x00038045,
+ RPI_FIRMWARE_SET_REBOOT_FLAGS = 0x00038064,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
--
2.47.3
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: broadcom: bcm2712: Add reboot modes to firmware node
From: Gregor Herburger @ 2026-06-26 7:35 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
In-Reply-To: <20260626-rpi-tryboot-v1-0-490b1c4c4970@linutronix.de>
The raspberry pi firmware driver allows the tryboot reboot mode. Add
this mode and normal boot mode to the node.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
index b7a6bc34ae1ab..67095c7ff770d 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
@@ -49,6 +49,8 @@ firmware: rpi-firmware {
compatible = "raspberrypi,bcm2835-firmware", "simple-mfd";
mboxes = <&mailbox>;
+ mode-normal = <0>;
+ mode-tryboot = <1>;
firmware_clocks: clocks {
compatible = "raspberrypi,firmware-clocks";
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 3/9] hwmon: adm1275: Detect coefficient overflow
From: sashiko-bot @ 2026-06-26 7:35 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: linux-hwmon, conor+dt, robh, devicetree
In-Reply-To: <d9e3320dbd62e094ff89598cb3aac5b5e716f9e7.1782458224.git.mazziesaccount@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch introduces spurious probe failures by restricting the intermediate `shunt * m` multiplication to a 32-bit limit instead of using a 64-bit calculation, needlessly rejecting perfectly valid shunt resistor configurations.
--
commit 02af229d429dc5c77e875edeb815b9caba7e6da2
Author: Matti Vaittinen <mazziesaccount@gmail.com>
hwmon: adm1275: Detect coefficient overflow
This commit detects potential coefficient overflow when a large shunt
resistor is used and aborts the probe if an overflow is detected.
> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
> index 43baa5ded35e5..ccc3ad21e38e7 100644
> --- a/drivers/hwmon/pmbus/adm1275.c
> +++ b/drivers/hwmon/pmbus/adm1275.c
> @@ -839,15 +839,25 @@ static int adm1275_probe(struct i2c_client *client)
> info->R[PSC_VOLTAGE_OUT] = coefficients[voindex].R;
> }
> if (cindex >= 0) {
> + u32 m;
> +
> /* Scale current with sense resistor value */
> - info->m[PSC_CURRENT_OUT] =
> - coefficients[cindex].m * shunt / 1000;
> + if (unlikely(check_mul_overflow(coefficients[cindex].m, shunt, &m))) {
[Severity: High]
Does this code introduce a spurious probe failure for valid setups?
By checking for overflow on the intermediate product using a 32-bit
unsigned integer, the probe will fail for configurations where the
product exceeds U32_MAX, but the final scaled value after dividing by
1000 would safely fit into the 32-bit signed integer target field.
Could we use a 64-bit intermediate calculation instead, such as
div_s64((s64)coefficients[cindex].m * shunt, 1000), to prevent this
regression and avoid needlessly rejecting valid shunt resistor setups?
> + dev_err(&client->dev, "Current coefficient overflow\n");
> + return -EOVERFLOW;
> + }
> + info->m[PSC_CURRENT_OUT] = m / 1000;
> info->b[PSC_CURRENT_OUT] = coefficients[cindex].b;
> info->R[PSC_CURRENT_OUT] = coefficients[cindex].R;
> }
> if (pindex >= 0) {
> - info->m[PSC_POWER] =
> - coefficients[pindex].m * shunt / 1000;
> + u32 m;
> +
> + if (unlikely(check_mul_overflow(coefficients[pindex].m, shunt, &m))) {
[Severity: High]
Can this similarly cause the probe to abort prematurely?
For example, configuring an ADM1293 on the 100mV range with a 250000 uOhm
shunt resistor yields a power coefficient product of 26042 * 250000, which
is 6,510,500,000. This mathematically overflows the 32-bit check here, but
the final value of 6,510,500 easily fits in the target field.
Would it be better to calculate this using 64-bit math so the device can
successfully initialize all of its sensors?
> + dev_err(&client->dev, "Power coefficient overflow\n");
> + return -EOVERFLOW;
> + }
> + info->m[PSC_POWER] = m / 1000;
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782458224.git.mazziesaccount@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v2 7/9] dt-bindings: adm1275: ROHM BD12790 hot-swap controller
From: sashiko-bot @ 2026-06-26 7:35 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: conor+dt, linux-hwmon, devicetree, robh
In-Reply-To: <753a6ded3e1aff1aaba7d932f0a883f789d9dfaa.1782458224.git.mazziesaccount@gmail.com>
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> Support ROHM BD12790 hot-swap controller which is largely compatible
> with the Analog Devices adm1272.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782458224.git.mazziesaccount@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH v2 5/9] doc: Add ROHM BD12780 and BD12780A
From: sashiko-bot @ 2026-06-26 7:36 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: conor+dt, linux-hwmon, devicetree, robh
In-Reply-To: <5ff4a4a7a939cd642522fde407b5c9fa123a7089.1782458224.git.mazziesaccount@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Incorrect hwmon sysfs prefix documented for the BD12780A device.
--
commit f0582b872b8ac6d6f116162797af818e8508125f
Author: Matti Vaittinen <mazziesaccount@gmail.com>
doc: Add ROHM BD12780 and BD12780A
This commit updates the adm1275 hardware monitoring driver documentation to
include support for the ROHM Semiconductor BD12780 and BD12780A power switch
ICs.
> diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst
> index cf923f20fa523..8a793dd2b412b 100644
> --- a/Documentation/hwmon/adm1275.rst
> +++ b/Documentation/hwmon/adm1275.rst
[ ... ]
> @@ -67,6 +67,22 @@ Supported chips:
>
> Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADM1293_1294.pdf
>
> + * ROHM Semiconductor BD12780
> +
> + Prefix: 'bd12780'
> +
> + Addresses scanned: -
> +
> + Datasheet: https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780muv-lb-e.pdf
> +
> + * ROHM Semiconductor BD12780A
> +
> + Prefix: 'bd12780'
^^^^^^^^^
[Severity: Low]
Is this prefix accurate for the BD12780A?
When the device is instantiated via Device Tree using the compatible string
"rohm,bd12780a", the I2C core's of_i2c_get_board_info() function extracts
this string, strips the vendor prefix, and sets client->name to "bd12780a".
The pmbus_do_probe() function then uses client->name to register the hwmon
device, which results in the prefix being "bd12780a" instead of the
documented "bd12780".
Could this cause issues for userspace tools relying on the documentation to
find the device?
> +
> + Addresses scanned: -
> +
> + Datasheet: https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780amuv-lb-e.pdf
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782458224.git.mazziesaccount@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-26 7:38 UTC (permalink / raw)
To: Sunyun Yang
Cc: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard,
Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <CAFQXuNZtzBu+WiG8n0BeN47zagQmL-iz_6Af7prk-xHLAeRBwg@mail.gmail.com>
On 26/06/2026 04:15, Sunyun Yang wrote:
> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 21:51写道：
>>
>> On 25/06/2026 15:40, Sunyun Yang wrote:
>>> Sunyun Yang <syyang@lontium.com> 于2026年6月25日周四 21:26写道：
>>>>
>>>> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 21:17写道：
>>>>>
>>>>> On 25/06/2026 15:14, Sunyun Yang wrote:
>>>>>> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 20:54写道：
>>>>>>>
>>>>>>> On 08/05/2026 15:40, syyang@lontium.com wrote:
>>>>>>>> +
>>>>>>>> +static void lt9611c_reset(struct lt9611c *lt9611c)
>>>>>>>> +{
>>>>>>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
>>>>>>>> + msleep(20);
>>>>>>>> +
>>>>>>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
>>>>>>>> + msleep(20);
>>>>>>>> +
>>>>>>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
>>>>>>>
>>>>>>> This is just plain wrong. Why do you assert, then de-assert and then
>>>>>>> finally assert AGAIN the reset leaving the device in powerdown stage?
>>>>>>>
>>>>>> I am using software to emulate the hardware RESET button on our EVB.
>>>>>> When the hardware RESET button is pressed while our chip is running,
>>>>>> the signal level changes from HIGH to LOW and then back to HIGH.
>>>>>>
>>>>>> Of course, we can also use the following:
>>>>>> static void lt9611c_reset(struct lt9611c *lt9611c)
>>>>>> {
>>>>>> gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
>>>>>> msleep(50);
>>>>>> gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
>>>>>> msleep(20);
>>>>>> }
>>>>>
>>>>> Makes no sense either and you just did not get the point and did not
>>>>> answer my question. I asked WHY you leave asserted. Answer "we emulate"
>>>>> is just plain wrong.
>>>>>
>>>>> So again please answer:
>>>>>
>>>>> Why do you leave device with reset asserted?
>>>>>
>>>>
>>>> devicetree: reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
>>>>
>>>> GPIO_ACTIVE_HIGH:
>>>>
>>>> gpiod_set_value_cansleep(lt9611c->reset_gpio, 0); ------ reset pin
>>>> is Low level : Clear the register configuration in the chip to stop
>>>> the chip from working.
>>>>
>>>> gpiod_set_value_cansleep(lt9611c->reset_gpio, 1); ------ reset pin
>>>> is high level: The chip resumes operation.
>>>>
>>>>
>>>
>>> Our purpose is: pull the level low to clear the register configuration
>>> in the chip, and then pull it high to allow the MCU inside the chip to
>>> re‑initialize the registers.
>>
>>
>> And you do completely opposite... so that confirms your code is just wrong.
>>
>
> The lontium-lt9611.yaml uses GPIO_ACTIVE_HIGH. I am just following the
> rule of this device tree. If I modify the device tree to use
> GPIO_ACTIVE_LOW,
> and use the following code in my driver, then my driver would be correct.
> However, would the existing kernel drivers lontium-lt9611uxc.c and
> lontium-lt9611.c be affected?
DT has nothing to do here. 1 is assert, 0 is de-assert. Your code does
things opposite to any logic, because you finish function with reset
asserted.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-26 7:40 UTC (permalink / raw)
To: Sunyun Yang, Dmitry Baryshkov
Cc: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
maarten.lankhorst, rfoss, mripard, Laurent.pinchart, tzimmermann,
jonas, jernej.skrabec, devicetree, dri-devel, linux-kernel, xmzhu,
xmzhu, rlyu, xbpeng
In-Reply-To: <CAFQXuNaOkDADrnUNMWt9JL0R9yAPrSUN1M08Z5CT=J3uXqwhkw@mail.gmail.com>
On 26/06/2026 03:55, Sunyun Yang wrote:
> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年6月25日周四 22:57写道：
>>
>> On Thu, Jun 25, 2026 at 09:26:47PM +0800, Sunyun Yang wrote:
>>> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 21:17写道：
>>>>
>>>> On 25/06/2026 15:14, Sunyun Yang wrote:
>>>>> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 20:54写道：
>>>>>>
>>>>>> On 08/05/2026 15:40, syyang@lontium.com wrote:
>>>>>>> +
>>>>>>> +static void lt9611c_reset(struct lt9611c *lt9611c)
>>>>>>> +{
>>>>>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
>>>>>>> + msleep(20);
>>>>>>> +
>>>>>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
>>>>>>> + msleep(20);
>>>>>>> +
>>>>>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
>>>>>>
>>>>>> This is just plain wrong. Why do you assert, then de-assert and then
>>>>>> finally assert AGAIN the reset leaving the device in powerdown stage?
>>>>>>
>>>>> I am using software to emulate the hardware RESET button on our EVB.
>>>>> When the hardware RESET button is pressed while our chip is running,
>>>>> the signal level changes from HIGH to LOW and then back to HIGH.
>>>>>
>>>>> Of course, we can also use the following:
>>>>> static void lt9611c_reset(struct lt9611c *lt9611c)
>>>>> {
>>>>> gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
>>>>> msleep(50);
>>>>> gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
>>>>> msleep(20);
>>>>> }
>>>>
>>>> Makes no sense either and you just did not get the point and did not
>>>> answer my question. I asked WHY you leave asserted. Answer "we emulate"
>>>> is just plain wrong.
>>>>
>>>> So again please answer:
>>>>
>>>> Why do you leave device with reset asserted?
>>>>
>>>
>>> devicetree: reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
>>
>> It should be GPIO_ACTIVE_LOW, if the pin as active-low.
>>
>
> Yes, I understand that.
>
> I used GPIO_ACTIVE_HIGH intentionally, because I did not want to
> modify the existing reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>
> property in the lontium-lt9611.yaml device tree file that was
The example there does not matter. You must write correct driver.
That is it.
If you cannot bring the arguments why reset must be asserted for the
normal operation of the device, then this is the end of discussion.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Krzysztof Kozlowski @ 2026-06-26 7:42 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: David Heidelberg, Krzysztof Kozlowski, Konrad Dybcio, Rob Herring,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio, linux-input,
devicetree, linux-kernel, linux-arm-msm, phone-devel
In-Reply-To: <aj1OhZQjO5nNYlAo@google.com>
On 25/06/2026 18:57, Dmitry Torokhov wrote:
> Hi Krzysztof,
>
> On Thu, Jun 25, 2026 at 10:23:54AM +0200, Krzysztof Kozlowski wrote:
>> On 25/06/2026 06:53, Dmitry Torokhov wrote:
>>> On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
>>>> On 24/06/2026 06:28, Dmitry Torokhov wrote:
>>>>> Hi David,
>>>>>
>>>>> On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
>>>>>> On 28/05/2026 00:13, David Heidelberg wrote:
>>>>>>> On 27/05/2026 23:56, Dmitry Torokhov wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
>>>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>>>
>>>>>>>>> We know the driver is reporting s3706b, introduce the compatible so we
>>>>>>>>> can more easily introduce quirks for weird touchscreen replacements in
>>>>>>>>> followup series.
>>>>>>>>>
>>>>>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>>>>>>> ---
>>>>>>>>> arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
>>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>>> b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>>> index 6b7378cf4d493..148164d456a5a 100644
>>>>>>>>> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>>> @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
>>>>>>>>> };
>>>>>>>>> };
>>>>>>>>> &i2c12 {
>>>>>>>>> status = "okay";
>>>>>>>>> clock-frequency = <400000>;
>>>>>>>>> synaptics-rmi4-i2c@20 {
>>>>>>>>> - compatible = "syna,rmi4-i2c";
>>>>>>>>> + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
>>>>>>>>
>>>>>>>> So I believe we established that this device (s3706b) does not in fact
>>>>>>>> implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
>>>>>>>> fallback? Shouldn't it be just "syna,rmi4-s3706b"?
>>>>>>>
>>>>>>> The vendor supplies s3706b which does implement the RMI4 properly.
>>>>>>>
>>>>>>> The 3rd party replacement impersonating original parts may not implement
>>>>>>> it properly, but I don't address this issue in this initial submission.
>>>>>>>
>>>>>>> With this compatible we know which original part is used by the vendor
>>>>>>> and installed in the phones, so later we can deduct specific sequences
>>>>>>> for the replacement aftermarket parts to keep phone touchscreen working
>>>>>>> same as they do on Android without affecting other devices.
>>>>>>
>>>>>> Hello Dmitry.
>>>>>>
>>>>>> May I ask what is currently preventing this series from moving forward?
>>>>>>
>>>>>> The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
>>>>>> and am now on the 9th iteration (this patchset). At this point, the series
>>>>>> has been under discussion for well over a year, with relatively little
>>>>>> feedback and increasingly long gaps between review rounds.
>>>>>>
>>>>>> The current approach is based on the guidance I have received so far,
>>>>>> including suggestions from the device-tree maintainers. When concerns were
>>>>>> raised, I tried to address them and rework the series accordingly.
>>>>>>
>>>>>> What I am struggling with is understanding what specific issue still needs
>>>>>> to be resolved before these patches can be accepted. If there are remaining
>>>>>> requirements, objections to the approach, or technical concerns that I have
>>>>>> not addressed, I would appreciate having them stated explicitly so I can
>>>>>> work on them.
>>>>>>
>>>>>> I also split out the straightforward, self-contained changes in the hope
>>>>>> that at least those could progress independently while I continued working
>>>>>> on any follow-up requirements. However, even those patches do not appear to
>>>>>> be moving forward.
>>>>>>
>>>>>> Could you please clarify what outcome you would like to see from this
>>>>>> series, and what concrete changes would be required to get it accepted?
>>>>>
>>>>> I am still confused about how you want to differentiate between the full
>>>>> RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
>>>>> mentioned, implements RMI4 protocol properly, so we do not need to
>>>>> actually have it documented neither in binding nor in DTS.
>>>>
>>>> --- part 1 ---
>>>>
>>>> This series addresses identification within device-tree. It's normal
>>>> recommended practice.
>>>>
>>>> If we know, the device ships specific, but **compliant** variant, we just
>>>> put it as compatible = "more-specific", "less-specific"; in this case
>>>> "syna,rmi4-s3706b", "syna,rmi4-i2c"
>>>>
>>>> This approach is used everywhere. This has nothing to do with after-market parts.
>>>
>>> We do this in many cases, sometimes when a part has different timings or
>>> maybe additional functionality compared to the base model.
>>
>> Generic expectation is to have always dedicated front compatible for
>> every device. rmi4-i2c is not really specific enough, more like a
>> family, thus a specific device compatible is essential by the DT rules.
>
> Essential in what way? What will break if such compatible is not there?
Essential by the rules we defined for DT and documented in writing-bindings.
> We have lived without it for many years and will continue live happily
> without it for years to come.
Does not matter if compatible is used or not. The rules are dictating that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: sashiko-bot @ 2026-06-26 7:43 UTC (permalink / raw)
To: Gregor Herburger; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260626-rpi-tryboot-v1-2-490b1c4c4970@linutronix.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing Device Tree Schema Restriction for reboot mode pattern properties
--
commit d367af481cae3dea3dd1bb270d9e4466fb383031
Author: Gregor Herburger <gregor.herburger@linutronix.de>
dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
This commit updates the Raspberry Pi firmware binding to reference the
reboot-mode schema. This allows reboot mode properties to be used to set
reboot modes like tryboot.
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index 983ea80eaec97..30b490e0d9fb3 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -133,11 +133,14 @@ properties:
> required:
> - compatible
>
> +allOf:
> + - $ref: /schemas/power/reset/reboot-mode.yaml#
[Severity: Low]
Should this schema restrict the reboot mode pattern properties to a single
item?
The generic reboot-mode.yaml schema defines ^mode-.*$ as a uint32-array
without a length restriction. Because this binding doesn't override it with
maxItems: 1, the device tree schema will accept arrays of arbitrary length,
for example:
mode-tryboot = <1 2>;
Since the reboot-mode.c driver only evaluates a single 32-bit value using
of_property_read_u32(), this could lead to silent truncation of multi-cell
properties without any validation errors. Does it make sense to add a
patternProperties block here to restrict maxItems to 1?
> +
> required:
> - compatible
> - mboxes
>
> -additionalProperties: false
> +unevaluatedProperties: false
>
> examples:
> - |
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626-rpi-tryboot-v1-0-490b1c4c4970@linutronix.de?part=2
^ permalink raw reply
* Re: [PATCH 3/4] firmware: raspberrypi: Add reboot mode support
From: sashiko-bot @ 2026-06-26 7:43 UTC (permalink / raw)
To: Gregor Herburger; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260626-rpi-tryboot-v1-3-490b1c4c4970@linutronix.de>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Mixing managed (devm) and manual API calls for reboot mode registration causes a double-free and a use-after-free on device removal.
- [High] Ignoring the return value of `devm_reboot_mode_register` leads to a NULL pointer dereference or double free if registration fails.
--
commit c4eb702fd9dc0d615bc8a99fbb83befc50f8971f
Author: Gregor Herburger <gregor.herburger@linutronix.de>
firmware: raspberrypi: Add reboot mode support
The Raspberry Pi firmware has a tryboot mode where it tries to boot from
another partition. This patch adds support for this by registering a reboot
mode driver.
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -306,6 +323,12 @@ static int rpi_firmware_probe(struct platform_device *pdev)
> rpi_register_hwmon_driver(dev, fw);
> rpi_register_clk_driver(dev);
>
> + fw->reboot_mode.dev = dev;
> + fw->reboot_mode.write = rpi_firmware_reboot_mode_write;
> + ret = devm_reboot_mode_register(dev, &fw->reboot_mode);
> + if (ret)
> + dev_err(dev, "Failed to register reboot mode: %d\n", ret);
> +
> return 0;
> }
[Severity: High]
Should we return the error code here instead of returning 0?
If devm_reboot_mode_register() fails, the probe succeeds but the internal
list head for the reboot mode might remain uninitialized.
Later during device removal, rpi_firmware_remove() calls
reboot_mode_unregister() unconditionally. This could lead to a null pointer
dereference when iterating the uninitialized list, or a double free if the
failure occurred inside the register function and it already freed the
resources.
[ ... ]
> @@ -323,6 +346,8 @@ static void rpi_firmware_remove(struct platform_device *pdev)
> {
> struct rpi_firmware *fw = platform_get_drvdata(pdev);
>
> + reboot_mode_unregister(&fw->reboot_mode);
> +
[Severity: High]
Could this manual unregister cause a double-free and use-after-free?
Since devm_reboot_mode_register() is used in probe, the devres cleanup will
automatically unregister the reboot mode when the device is removed.
By manually calling reboot_mode_unregister() here:
1. It frees the strings in the list.
2. rpi_firmware_put(fw) drops the reference, potentially freeing the fw
structure.
3. The devres cleanup runs devm_reboot_mode_release() upon returning,
accessing the freed fw structure and attempting to unregister and free
the strings a second time.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626-rpi-tryboot-v1-0-490b1c4c4970@linutronix.de?part=3
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: broadcom: bcm2712: Add reboot modes to firmware node
From: sashiko-bot @ 2026-06-26 7:44 UTC (permalink / raw)
To: Gregor Herburger; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260626-rpi-tryboot-v1-4-490b1c4c4970@linutronix.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Adding `mode-*` properties activates a dormant Use-After-Free and Double-Free vulnerability in the driver's unbind path.
--
commit cd92f6ce5b48afd036127289b2412bed6be015fc
Author: Gregor Herburger <gregor.herburger@linutronix.de>
arm64: dts: broadcom: bcm2712: Add reboot modes to firmware node
The raspberry pi firmware driver allows the tryboot reboot mode. Add
this mode and normal boot mode to the node.
> diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
> index b7a6bc34ae1ab..67095c7ff770d 100644
> --- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
> @@ -49,6 +49,8 @@ firmware: rpi-firmware {
> compatible = "raspberrypi,bcm2835-firmware", "simple-mfd";
>
> mboxes = <&mailbox>;
> + mode-normal = <0>;
> + mode-tryboot = <1>;
[Severity: Critical]
This is a pre-existing issue, but does adding these properties to the
device tree activate a dormant use-after-free and double-free vulnerability
in the driver's unbind path?
Looking at drivers/firmware/raspberrypi.c, the driver registers the reboot
mode using the devm variant during probe, but also manually unregisters it
during remove:
drivers/firmware/raspberrypi.c:rpi_firmware_remove() {
...
reboot_mode_unregister(&fw->reboot_mode);
rpi_firmware_put(fw);
...
}
The call to rpi_firmware_put() drops the reference and frees the fw object.
Because devm_reboot_mode_register() was used during probe, the devres cleanup
will eventually run devm_reboot_mode_release() which calls
reboot_mode_unregister() a second time. This passes the now-freed
fw->reboot_mode pointer.
Furthermore, the list strings are freed during the first unregister call:
drivers/power/reset/reboot-mode.c:reboot_mode_unregister() {
...
list_for_each_entry(info, &reboot->head, list)
kfree_const(info->mode);
...
}
Because the list pointers are not cleared and the list elements are preserved,
the second unregister call will iterate over the list again. Since this patch
populates that list by adding mode-normal and mode-tryboot, the second call
will try to free the already-freed info->mode pointers.
Should the manual reboot_mode_unregister() call be removed from
rpi_firmware_remove() before adding these device tree properties?
>
> firmware_clocks: clocks {
> compatible = "raspberrypi,firmware-clocks";
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626-rpi-tryboot-v1-0-490b1c4c4970@linutronix.de?part=4
^ permalink raw reply
* Re: [PATCH v6 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-06-26 7:45 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
linux-input, devicetree, linux-kernel
In-Reply-To: <aj28fvj34b4_VI3k@google.com>
пт, 26 черв. 2026 р. о 02:45 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
>
> Hi Svyatoslav,
>
> On Wed, Jun 17, 2026 at 10:05:27AM +0300, Svyatoslav Ryhel wrote:
> > From: Linus Walleij <linusw@kernel.org>
> >
> > The ISA1200 is a haptic feedback unit from Imagis Technology using two
> > motors for haptic feedback in mobile phones. Used in many mobile devices
> > c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> > GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
> >
> > The exact datasheet for the ISA1200 is not available; all data was modeled
> > based on available downstream kernel sources for various devices and
> > fragments of information scattered across the internet.
> >
> > Tested-by: Linus Walleij <linusw@kernel.org> # GT-I9070 Janice
> > Signed-off-by: Linus Walleij <linusw@kernel.org>
> > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>
>
> Sashiko convinced me that using mutex_trylock() in the playback work
> handler will result in dropping requests and that we are safe not taking
> the lock there at all. Can you please try the following modification?
>
> diff --git a/drivers/input/misc/isa1200.c b/drivers/input/misc/isa1200.c
> index c61adc4b605c..fb7f68fa0a2b 100644
> --- a/drivers/input/misc/isa1200.c
> +++ b/drivers/input/misc/isa1200.c
> @@ -253,15 +253,12 @@ static void isa1200_stop(struct isa1200 *isa)
> static void isa1200_play_work(struct work_struct *work)
> {
> struct isa1200 *isa = container_of(work, struct isa1200, play_work);
> - struct input_dev *input = isa->input;
> -
> - scoped_guard(mutex_try, &input->mutex) {
> - if (!isa->suspended) {
> - if (isa->level)
> - isa1200_start(isa);
> - else
> - isa1200_stop(isa);
> - }
> +
> + if (!READ_ONCE(isa->suspended)) {
> + if (isa->level)
> + isa1200_start(isa);
> + else
> + isa1200_stop(isa);
> }
> }
>
>
> If this works no need to resend, I'll fold on my side.
>
It does work fine. Thank you.
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Maxime Ripard @ 2026-06-26 7:49 UTC (permalink / raw)
To: Sunyun Yang
Cc: Krzysztof Kozlowski, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, dmitry.baryshkov, maarten.lankhorst, rfoss,
Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <CAFQXuNZtzBu+WiG8n0BeN47zagQmL-iz_6Af7prk-xHLAeRBwg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3937 bytes --]
On Fri, Jun 26, 2026 at 10:15:03AM +0800, Sunyun Yang wrote:
> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 21:51写道：
> >
> > On 25/06/2026 15:40, Sunyun Yang wrote:
> > > Sunyun Yang <syyang@lontium.com> 于2026年6月25日周四 21:26写道：
> > >>
> > >> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 21:17写道：
> > >>>
> > >>> On 25/06/2026 15:14, Sunyun Yang wrote:
> > >>>> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 20:54写道：
> > >>>>>
> > >>>>> On 08/05/2026 15:40, syyang@lontium.com wrote:
> > >>>>>> +
> > >>>>>> +static void lt9611c_reset(struct lt9611c *lt9611c)
> > >>>>>> +{
> > >>>>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> > >>>>>> + msleep(20);
> > >>>>>> +
> > >>>>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> > >>>>>> + msleep(20);
> > >>>>>> +
> > >>>>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> > >>>>>
> > >>>>> This is just plain wrong. Why do you assert, then de-assert and then
> > >>>>> finally assert AGAIN the reset leaving the device in powerdown stage?
> > >>>>>
> > >>>> I am using software to emulate the hardware RESET button on our EVB.
> > >>>> When the hardware RESET button is pressed while our chip is running,
> > >>>> the signal level changes from HIGH to LOW and then back to HIGH.
> > >>>>
> > >>>> Of course, we can also use the following:
> > >>>> static void lt9611c_reset(struct lt9611c *lt9611c)
> > >>>> {
> > >>>> gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> > >>>> msleep(50);
> > >>>> gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> > >>>> msleep(20);
> > >>>> }
> > >>>
> > >>> Makes no sense either and you just did not get the point and did not
> > >>> answer my question. I asked WHY you leave asserted. Answer "we emulate"
> > >>> is just plain wrong.
> > >>>
> > >>> So again please answer:
> > >>>
> > >>> Why do you leave device with reset asserted?
> > >>>
> > >>
> > >> devicetree: reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
> > >>
> > >> GPIO_ACTIVE_HIGH:
> > >>
> > >> gpiod_set_value_cansleep(lt9611c->reset_gpio, 0); ------ reset pin
> > >> is Low level : Clear the register configuration in the chip to stop
> > >> the chip from working.
> > >>
> > >> gpiod_set_value_cansleep(lt9611c->reset_gpio, 1); ------ reset pin
> > >> is high level: The chip resumes operation.
> > >>
> > >>
> > >
> > > Our purpose is: pull the level low to clear the register configuration
> > > in the chip, and then pull it high to allow the MCU inside the chip to
> > > re‑initialize the registers.
> >
> >
> > And you do completely opposite... so that confirms your code is just wrong.
> >
>
> The lontium-lt9611.yaml uses GPIO_ACTIVE_HIGH. I am just following the
> rule of this device tree. If I modify the device tree to use
> GPIO_ACTIVE_LOW,
> and use the following code in my driver, then my driver would be correct.
> However, would the existing kernel drivers lontium-lt9611uxc.c and
> lontium-lt9611.c be affected?
It might, but then it's a DT problem. The GPIO API for drivers always
considers the logical state of a GPIO, so if you need to assert a
signal, you'll always need to set 1. That's what Krzysztof was trying to
explain.
The DT will provide with GPIO_ACTIVE_* how that logical state translates
to a physical GPIO state.
If the DT says that this particular GPIO is active-high, then it means
that we need to set the GPIO to 1 to assert reset. Now of course, it
might not make sense for the controller itself, but it might for the
board if there's a GPIO inverter in the middle for example.
Anyway, in the case you're raising, the issue definitely lies in the DT,
and that's what would need to be fixed.
I also wouldn't be too concerned about lontium-lt9611.yaml, it's just an
example.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 9/9] hwmon: adm1275: Support ROHM BD12790
From: Matti Vaittinen @ 2026-06-26 7:49 UTC (permalink / raw)
To: sashiko-reviews; +Cc: linux-hwmon, robh, conor+dt, devicetree
In-Reply-To: <20260626073347.A06981F000E9@smtp.kernel.org>
On 26/06/2026 10:33, sashiko-bot@kernel.org wrote:
> If we evaluate m = round(k / 10^(-3-R)) for a value of R=-2 and k=35119.94,
> it yields 351199.4. However, the actual code below correctly implements the
> value as 3512, which implies the formula should use multiplication rather
> than division.
Gah. I think Sashiko is right. The fixed comment should say:
m = round(k * 10^(-3-R))
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v1 1/2] Documentation: dt: reset: add mediatek,syscon-reset binding
From: sashiko-bot @ 2026-06-26 7:53 UTC (permalink / raw)
To: peter.wang; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260626074820.2537772-2-peter.wang@mediatek.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The YAML binding schema is missing the mandatory `$id` field.
--
commit 010ce9609c338d8282471debb7c3cd606956e201
Author: Peter Wang <peter.wang@mediatek.com>
Documentation: dt: reset: add mediatek,syscon-reset binding
This commit adds Device Tree binding documentation for the MediaTek SYSCON
reset controller. The binding describes a reset controller that is part of
a MediaTek SYSCON MFD block and manages multiple reset lines via the
mediatek,reset-bits property.
> diff --git a/Documentation/devicetree/bindings/reset/mediatek,syscon-reset.yaml b/Documentation/devicetree/bindings/reset/mediatek,syscon-reset.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/mediatek,syscon-reset.yaml
> @@ -0,0 +1,93 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
[Severity: Medium]
Is the mandatory $id field missing from this schema definition?
Without the $id field, the schema cross-reference system ($ref resolution)
can break, and dt_binding_check might silently skip validation or report
misleading errors. Should it be added to the top-level schema header?
> +
> +title: MediaTek SYSCON Reset Controller
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626074820.2537772-1-peter.wang@mediatek.com?part=1
^ 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