* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-26 7:22 UTC (permalink / raw)
To: Conor Dooley
Cc: Joey Lu, zhengxingda, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260625-bobbing-annotate-d1c4d6874ee2@spud>
[-- Attachment #1: Type: text/plain, Size: 4397 bytes --]
On Thu, Jun 25, 2026 at 05:33:37PM +0100, Conor Dooley wrote:
> On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> > The verisilicon,dc binding was originally written for the T-Head TH1520
> > SoC carrying a DC8200, and hard-codes five clocks, three resets and two
> > output ports.
> >
> > Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to the binding.
> > The DCUltraLite uses only two clocks (core, pix0) and one reset (core),
> > with a single output port.
> >
> > Use allOf/if blocks to express per-variant constraints rather than
> > hard-coding the DC8200 topology at the top level. Each compatible's
> > block constrains the clock and reset item counts; the nuvoton block
> > additionally overrides clock-names to the two names it actually uses.
> >
> > Signed-off-by: Joey Lu <a0987203069@gmail.com>
> > ---
> > .../bindings/display/verisilicon,dc.yaml | 57 +++++++++++++++++++
> > 1 file changed, 57 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > index 9dc35ab973f2..1e751f3c7ce8 100644
> > --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > @@ -17,6 +17,7 @@ properties:
> > items:
> > - enum:
> > - thead,th1520-dc8200
> > + - nuvoton,ma35d1-dcu
> > - const: verisilicon,dc # DC IPs have discoverable ID/revision registers
> >
> > reg:
> > @@ -77,6 +78,62 @@ required:
> > - clock-names
> > - ports
> >
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: thead,th1520-dc8200
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 5
> > + maxItems: 5
> > +
> > + clock-names:
> > + minItems: 5
> > + maxItems: 5
>
> All the maxItems here repeat the maximum constraint and do nothing.
>
> Since you didn't change the minimum constraint at the top level, your
> minItems also do nothing.
>
> > +
> > + resets:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + reset-names:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + required:
> > + - resets
> > + - reset-names
>
> Both conditional sections have this, but the original binding doesn't
> require these for the thead device. This is a functional change
> therefore and shouldn't be in a patch calling itself "generalise for
> single ended variants".
>
> FWIW, adding your new compatible shouldn't really be in a patch with
> that subject either, it really should say "add support for nuvoton
> ma35d1" or something.
>
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: nuvoton,ma35d1-dcu
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
>
> Anything that updates the minimum constraint should be done at the top
> level of this schema. The conditional section should then tighten the
> constraint, in this case that means only having maxItems.
>
> > + maxItems: 2
> > +
> > + clock-names:
> > + items:
> > + - const: core
> > + - const: pix0
>
> Does this even work when the top level schema thinks clock 2 should be
> called axi?
Additionally here, only have core and pix0 seems like it might be an
oversimplification. I doubt removing the second output port means that
the axi and ahb clocks are no longer needed.
Is it the case that your device supplies the same clock to core, ahb and
axi? If so, then you should fill those clocks in in your devicetree and
this can just constrain the number of clocks/clock-names to 4.
>
> > +
> > + resets:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: core
>
> This is just maxItems: 1.
>
> pw-bot: changes-requested
>
> Thanks,
> Conor.
>
> > +
> > + required:
> > + - resets
> > + - reset-names
> > +
> > additionalProperties: false
> >
> > examples:
> > --
> > 2.43.0
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 3/9] hwmon: adm1275: Detect coefficient overflow
From: Matti Vaittinen @ 2026-06-26 7:23 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: 2645 bytes --]
From: Matti Vaittinen <mazziesaccount@gmail.com>
Sashiko detected potential coefficient overflow if large shunt resistor
is used. When going unnoticed it can cause "drastically incorrect
telemetry scaling factors" as Sashiko put it.
I am not convinced such "drastically incorrect telemetry scaling
factors" could have gone unnoticed, so I suspect such large shunt
resistors aren't really used. Well, it shouldn't hurt to detect the
error and abort the probe before Really Wrong current / power -values
are reported to user by the hwmon.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
Revision history:
v1 => v2:
- New patch
This patch returns -EOVERFLOW with an error print if overflow is
detected. IF there really are systems where the overflow truly occurs,
then this change will cause the probe to fail - which might hurt the
boot process. It might be safer to only print the warning. One could
also try changing the order of the shunt resistor value division (/1000)
and the multiplication and see if overflow goes away - but it'll be
somewhat more complex then. Hence, I just decided to error-out if this
happens, and leave this for the people facing the real overflow to fix
(if needed)... It's still fair to mention this might cause issues.
---
drivers/hwmon/pmbus/adm1275.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
index 43baa5ded35e..ccc3ad21e38e 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))) {
+ 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))) {
+ dev_err(&client->dev, "Power coefficient overflow\n");
+ return -EOVERFLOW;
+ }
+ info->m[PSC_POWER] = m / 1000;
info->b[PSC_POWER] = coefficients[pindex].b;
info->R[PSC_POWER] = coefficients[pindex].R;
}
--
2.54.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* [PATCH v2 4/9] hwmon: adm1275: Support module auto-loading
From: Matti Vaittinen @ 2026-06-26 7:24 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: 1948 bytes --]
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>
---
Revision history:
v1 => v2:
- New patch as discussed with Guenter here:
https://lore.kernel.org/all/f080e20e-6ec7-4744-9794-0a92d03f48d8@roeck-us.net/
---
drivers/hwmon/pmbus/adm1275.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
index ccc3ad21e38e..1ea2037711e1 100644
--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -870,9 +870,25 @@ static int adm1275_probe(struct i2c_client *client)
return pmbus_do_probe(client, info);
}
+static const struct of_device_id adm1275_of_match[] = {
+ { .compatible = "adi,adm1075", },
+ { .compatible = "adi,adm1272", },
+ { .compatible = "adi,adm1273", },
+ { .compatible = "adi,adm1275", },
+ { .compatible = "adi,adm1276", },
+ { .compatible = "adi,adm1278", },
+ { .compatible = "adi,adm1281", },
+ { .compatible = "adi,adm1293", },
+ { .compatible = "adi,adm1294", },
+ { .compatible = "silergy,mc09c", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, adm1275_of_match);
+
static struct i2c_driver adm1275_driver = {
.driver = {
.name = "adm1275",
+ .of_match_table = adm1275_of_match,
},
.probe = adm1275_probe,
.id_table = adm1275_id,
--
2.54.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* [PATCH v2 5/9] doc: Add ROHM BD12780 and BD12780A
From: Matti Vaittinen @ 2026-06-26 7:24 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: 1186 bytes --]
From: Matti Vaittinen <mazziesaccount@gmail.com>
Add the ROHM BD12780 and the BD12780A to the list of the ICs supported by
the adm1275 driver.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
Revision history:
v1 => :
- No changes
---
Documentation/hwmon/adm1275.rst | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst
index cf923f20fa52..8a793dd2b412 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'
+
+ Addresses scanned: -
+
+ Datasheet: https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780amuv-lb-e.pdf
+
* Silergy SQ24905C
Prefix: 'mc09c'
--
2.54.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* [PATCH v2 6/9] hwmon: adm1275: Support ROHM BD12780
From: Matti Vaittinen @ 2026-06-26 7:24 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: 6290 bytes --]
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>
---
Revision history:
v1 => v2: Changes based on the review by Guenter:
- Drop i2c_device_id for bd12780a
- Add own 'case' for the bd12780 instead of overloading the existing
one and still having an 'if (id == bd12780)' inside the case.
---
drivers/hwmon/pmbus/Kconfig | 2 +-
drivers/hwmon/pmbus/adm1275.c | 55 ++++++++++++++++++++++++++++++-----
2 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 8f4bff375ecb..b3c27f3b2712 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -52,7 +52,7 @@ 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 and SQ24905C Hot-Swap Controller and
+ ADM1293, ADM1294, ROHM BD12780, and SQ24905C Hot-Swap Controller and
Digital Power Monitors.
This driver can also be built as a module. If so, the module will
diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
index 1ea2037711e1..81c50fab7687 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, sq24905c };
+ adm1293, adm1294, bd12780, sq24905c };
#define ADM1275_MFR_STATUS_IOUT_WARN2 BIT(0)
#define ADM1293_MFR_STATUS_VAUX_UV_WARN BIT(5)
@@ -47,6 +47,8 @@ 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. */
+#define BD12780_PMON_DEFCONFIG (ADM1278_VOUT_EN | ADM1278_TEMP1_EN)
#define ADM1293_IRANGE_25 0
#define ADM1293_IRANGE_50 BIT(6)
@@ -487,6 +489,7 @@ static const struct i2c_device_id adm1275_id[] = {
{ "adm1281", adm1281 },
{ "adm1293", adm1293 },
{ "adm1294", adm1294 },
+ { "bd12780", bd12780 },
{ "mc09c", sq24905c },
{ }
};
@@ -494,12 +497,13 @@ MODULE_DEVICE_TABLE(i2c, adm1275_id);
/* Enable VOUT & TEMP1 if not enabled (disabled by default) */
static int adm1275_enable_vout_temp(struct adm1275_data *data,
- struct i2c_client *client, int config)
+ struct i2c_client *client, int config,
+ u16 defconfig)
{
int ret;
- if ((config & ADM1278_PMON_DEFCONFIG) != ADM1278_PMON_DEFCONFIG) {
- config |= ADM1278_PMON_DEFCONFIG;
+ if ((config & defconfig) != defconfig) {
+ config |= defconfig;
ret = adm1275_write_pmon_config(data, client, config);
if (ret < 0) {
dev_err(&client->dev, "Failed to enable VOUT/TEMP1 monitoring\n");
@@ -535,7 +539,8 @@ static int adm1275_probe(struct i2c_client *client)
return ret;
}
if ((ret != 3 || strncmp(block_buffer, "ADI", 3)) &&
- (ret != 2 || strncmp(block_buffer, "SY", 2))) {
+ (ret != 2 || strncmp(block_buffer, "SY", 2)) &&
+ (ret != 4 || strncmp(block_buffer, "ROHM", 4))) {
dev_err(&client->dev, "Unsupported Manufacturer ID\n");
return -ENODEV;
}
@@ -562,7 +567,7 @@ 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 == sq24905c)
+ mid->driver_data == bd12780 || mid->driver_data == sq24905c)
config_read_fn = i2c_smbus_read_word_data;
else
config_read_fn = i2c_smbus_read_byte_data;
@@ -666,7 +671,8 @@ static int adm1275_probe(struct i2c_client *client)
PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
- ret = adm1275_enable_vout_temp(data, client, config);
+ ret = adm1275_enable_vout_temp(data, client, config,
+ ADM1278_PMON_DEFCONFIG);
if (ret)
return ret;
@@ -728,13 +734,45 @@ static int adm1275_probe(struct i2c_client *client)
PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
- ret = adm1275_enable_vout_temp(data, client, config);
+ ret = adm1275_enable_vout_temp(data, client, config,
+ ADM1278_PMON_DEFCONFIG);
if (ret)
return ret;
if (config & ADM1278_VIN_EN)
info->func[0] |= PMBUS_HAVE_VIN;
break;
+
+ /*
+ * The BD12780 is almost functionally identical with the adm1278 above.
+ * Only differences visible to the driver are lack of TSFILT bits and
+ * different identification register contents.
+ */
+ case bd12780:
+ data->have_vout = true;
+ data->have_pin_max = true;
+ data->have_temp_max = true;
+ data->have_power_sampling = true;
+
+ coefficients = adm1278_coefficients;
+ vindex = 0;
+ cindex = 1;
+ pindex = 2;
+ tindex = 3;
+
+ 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 adm1293:
case adm1294:
data->have_iout_min = true;
@@ -880,6 +918,7 @@ static const struct of_device_id adm1275_of_match[] = {
{ .compatible = "adi,adm1281", },
{ .compatible = "adi,adm1293", },
{ .compatible = "adi,adm1294", },
+ { .compatible = "rohm,bd12780", },
{ .compatible = "silergy,mc09c", },
{ }
};
--
2.54.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* [PATCH v2 7/9] dt-bindings: adm1275: ROHM BD12790 hot-swap controller
From: Matti Vaittinen @ 2026-06-26 7:25 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: 1581 bytes --]
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>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Revision history:
v1 => :
- Fixed double space from description
---
Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml
index 503e93756584..283cd1662689 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml
@@ -33,6 +33,9 @@ description: |
https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780muv-lb-e.pdf
https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780amuv-lb-e.pdf
+ The BD12790 is a ROHM hot-swap controller, functionally similar to the
+ ADM1272.
+
properties:
compatible:
oneOf:
@@ -47,6 +50,7 @@ properties:
- adi,adm1293
- adi,adm1294
- rohm,bd12780
+ - rohm,bd12790
- silergy,mc09c
# Require BD12780 as a fall-back for BD12780A.
@@ -103,6 +107,7 @@ allOf:
enum:
- adi,adm1272
- adi,adm1273
+ - rohm,bd12790
then:
properties:
adi,volt-curr-sample-average:
--
2.54.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* [PATCH v2 8/9] doc: adm1275: Add ROHM BD12790
From: Matti Vaittinen @ 2026-06-26 7:25 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: 864 bytes --]
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>
---
Revision history:
v1 => :
- No changes
---
Documentation/hwmon/adm1275.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst
index 8a793dd2b412..d8495be313b8 100644
--- a/Documentation/hwmon/adm1275.rst
+++ b/Documentation/hwmon/adm1275.rst
@@ -83,6 +83,14 @@ Supported chips:
Datasheet: https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780amuv-lb-e.pdf
+ * ROHM Semiconductor BD12790
+
+ Prefix: 'bd12790'
+
+ Addresses scanned: -
+
+ Datasheet: -
+
* Silergy SQ24905C
Prefix: 'mc09c'
--
2.54.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* [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
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