* Re: [PATCH net-next v7 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct
From: sashiko-bot @ 2026-06-16 14:32 UTC (permalink / raw)
To: Christian Marangi; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260615122950.22281-2-ansuelsmth@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch makes a one-time copy of `supported_interfaces` during `phylink_create()`, which breaks drivers like `mtk_eth_soc` that modify `phylink_config.supported_interfaces` after calling `phylink_create()`.
--
commit c809e12abb9cfbf31d18f5e71f4e3d15bb4f6a01
Author: Christian Marangi <ansuelsmth@gmail.com>
net: phylink: keep and use MAC supported_interfaces in phylink struct
This patch introduces a cached copy of the supported_interfaces mask in the
phylink struct. It initializes this copy during phylink_create() and
transitions the phylink core to validate against this internal mask rather
than the original phylink_config.
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 087ac63f9193d..4d59c0dd78dbf 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
[ ... ]
> @@ -1868,6 +1873,9 @@ struct phylink *phylink_create(struct phylink_config *config,
> mutex_init(&pl->state_mutex);
> INIT_WORK(&pl->resolve, phylink_resolve);
>
> + phy_interface_copy(pl->supported_interfaces,
> + config->supported_interfaces);
> +
[Severity: High]
Does this one-time copy in phylink_create() break drivers that modify their
supported_interfaces after initialization?
For example, in drivers/net/ethernet/mediatek/mtk_eth_soc.c:mtk_add_mac(),
the driver appends PHY_INTERFACE_MODE_INTERNAL to
mac->phylink_config.supported_interfaces after phylink_create() has already
been called:
drivers/net/ethernet/mediatek/mtk_eth_soc.c:mtk_add_mac() {
...
mac->phylink = phylink_create(&mac->phylink_config, ...);
...
if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_2P5GPHY) &&
id == MTK_GMAC2_ID)
__set_bit(PHY_INTERFACE_MODE_INTERNAL,
mac->phylink_config.supported_interfaces);
...
}
Since phylink now validates against the cached pl->supported_interfaces mask,
will it reject PHY_INTERFACE_MODE_INTERNAL as unsupported and prevent the
internal 2.5G PHY from linking successfully on affected Mediatek platforms?
> pl->config = config;
> if (config->type == PHYLINK_NETDEV) {
> pl->netdev = to_net_dev(config->dev);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615122950.22281-1-ansuelsmth@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v3 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: sashiko-bot @ 2026-06-16 14:30 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260616-mt6323-adc-v3-2-1c27c588185d@protonmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The driver incorrectly powers down the AUXADC clock during initialization, preventing the ADC from functioning.
- [High] Unchecked dereference of `dev->parent` when fetching the regmap could lead to a kernel panic.
- [Medium] The voltage buffer (`VBUF_EN`) is permanently left enabled if an error occurs during channel request or release.
--
commit ec67a1445925e2d4ca9ef40c52f5417793b977c8
Author: Roman Vivchar <rva333@protonmail.com>
Subject: iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
provides support for reading various channels including battery and
charger voltages, battery and chip temperature, current sensing and
accessory detection. Add a driver for the AUXADC found in the MediaTek
mt6323 PMIC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch>
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
[ ... ]
> diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
> new file mode 100644
> index 0000000000000..572466c3f375f
> --- /dev/null
> +++ b/drivers/iio/adc/mt6323-auxadc.c
[ ... ]
> +static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
> + unsigned long channel)
> +{
> + struct regmap *map = auxadc->regmap;
> + int ret;
> +
> + ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
> + if (ret)
> + return ret;
> +
> + return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
[Severity: Medium]
If regmap_set_bits() for MT6323_AUXADC_CON22 fails here, does this
leave the AUXADC_CON11_VBUF_EN bit permanently enabled?
It looks like mt6323_auxadc_read_raw() aborts on a request error without
calling mt6323_auxadc_release().
> +}
> +
> +static int mt6323_auxadc_release(struct mt6323_auxadc *auxadc,
> + unsigned long channel)
> +{
> + struct regmap *map = auxadc->regmap;
> + int ret;
> +
> + ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
> + if (ret)
> + return ret;
> +
> + return regmap_clear_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
Similarly, if mt6323_auxadc_release() fails to clear the channel bit, it
returns early and skips disabling VBUF_EN. Should these error paths ensure
VBUF_EN is disabled before returning?
> +}
[ ... ]
> +static int mt6323_auxadc_init(struct mt6323_auxadc *auxadc)
> +{
> + struct regmap *map = auxadc->regmap;
> + int ret;
> +
> + ret = regmap_set_bits(map, MT6323_STRUP_CON10,
> + AUXADC_STRUP_CON10_RSTB_SW |
> + AUXADC_STRUP_CON10_RSTB_SEL);
> + if (ret)
> + return ret;
> +
> + ret = regmap_set_bits(map, MT6323_TOP_CKPDN2, AUXADC_TOP_CKPDN2_CTL_CK);
[Severity: High]
Does setting this bit actually disable the AUXADC clock?
In MediaTek PMICs, CKPDN typically stands for Clock Power Down. If setting
this bit to 1 disables the clock, and it is never cleared, wouldn't the
clock remain powered down indefinitely and cause all subsequent ADC reads
to time out or hang the hardware?
Should this use regmap_clear_bits() instead to enable the clock?
> + if (ret)
> + return ret;
[ ... ]
> +static int mt6323_auxadc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mt6323_auxadc *auxadc;
> + struct regmap *regmap;
> + struct iio_dev *iio;
> + int ret;
> +
> + regmap = dev_get_regmap(dev->parent->parent, NULL);
[Severity: High]
Can dev->parent or dev->parent->parent be NULL here if the device is
instantiated outside of its expected MFD hierarchy?
For example, if instantiated via a misconfigured Device Tree overlay or
direct sysfs binding, dev->parent could be &platform_bus, which has a NULL
parent.
Since dev_get_regmap() invokes devres_find() which unconditionally
dereferences the device pointer, would passing a NULL parent cause a
kernel panic during probe? Should the parent chain be validated before
dereferencing?
> + if (!regmap)
> + return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com?part=2
^ permalink raw reply
* Re: [PATCH v3 3/4] mfd: mt6397-core: add mt6323 AUXADC support
From: sashiko-bot @ 2026-06-16 14:28 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260616-mt6323-adc-v3-3-1c27c588185d@protonmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] mt6323_auxadc_init incorrectly powers down the AUXADC clock instead of enabling it.
- [Medium] Failure during mt6323_auxadc_request() does not revert the hardware voltage buffer enablement, leading to a permanent hardware state leak.
--
commit 6b92fe47672fd5e88ade7a2d9b916034b0dc7bca
Author: Roman Vivchar <rva333@protonmail.com>
mfd: mt6397-core: add mt6323 AUXADC support
The mt6323 PMIC includes an AUXADC. Register the AUXADC in the mt6323
devices array to allow the corresponding driver to probe using compatible
string.
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 3e58d0764c7e0..013b0857fb548 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
>
> static const struct mfd_cell mt6323_devs[] = {
> {
> + .name = "mt6323-auxadc",
> + .of_compatible = "mediatek,mt6323-auxadc",
> + }, {
[Severity: High]
While reviewing the driver this enables, does mt6323_auxadc_init()
incorrectly power down the AUXADC clock?
drivers/iio/adc/mt6323-auxadc.c:mt6323_auxadc_init() {
...
ret = regmap_set_bits(map, MT6323_TOP_CKPDN2, AUXADC_TOP_CKPDN2_CTL_CK);
...
}
The Mediatek PMIC TOP_CKPDN2 register is a "Clock Power Down" register,
meaning that setting a bit to 1 disables the corresponding clock. By using
regmap_set_bits() here, the clock appears to be explicitly powered down
instead of enabled. This would prevent the AUXADC hardware from functioning
and cause subsequent reads in mt6323_auxadc_read() to perpetually time out.
[Severity: Medium]
Also, does a failure during mt6323_auxadc_request() leak the hardware
voltage buffer state?
drivers/iio/adc/mt6323-auxadc.c:mt6323_auxadc_request() {
...
ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
if (ret)
return ret;
return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
}
If the second regmap_set_bits() fails, the function returns without undoing
the enablement of AUXADC_CON11_VBUF_EN.
This error then propagates up to mt6323_auxadc_read_raw():
drivers/iio/adc/mt6323-auxadc.c:mt6323_auxadc_read_raw() {
...
ret = mt6323_auxadc_request(auxadc, chan->channel);
if (ret)
return ret;
...
}
Because this returns immediately on error, it skips the
mt6323_auxadc_release() cleanup step. This leaves the hardware voltage
buffer permanently enabled until the device is reset or a subsequent read
succeeds.
> .name = "mt6323-rtc",
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com?part=3
^ permalink raw reply
* Re: [PATCH 6/7] hwmon: adm1275: Support ROHM BD12790
From: Guenter Roeck @ 2026-06-16 14:17 UTC (permalink / raw)
To: sashiko-reviews, Matti Vaittinen; +Cc: conor+dt, devicetree, linux-hwmon, robh
In-Reply-To: <20260616065944.95FF11F00A3A@smtp.kernel.org>
On 6/15/26 23:59, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] The driver compares the device-returned PMBUS_MFR_MODEL string using strncasecmp without verifying the returned length, leading to uninitialized stack memory reads.
> - [High] Multiplication of power and current coefficients by `shunt` overflows a 32-bit unsigned integer for larger shunt resistors.
> --
>
> commit 8dff4bf5659b589eabe7fc876665de9339faae1f
> Author: Matti Vaittinen <mazziesaccount@gmail.com>
>
> hwmon: adm1275: Support ROHM BD12790
>
> Add support for ROHM BD12790 hot-swap controller which is largely
> similar to Analog Devices adm1272.
>
>> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
>> --- a/drivers/hwmon/pmbus/adm1275.c
>> +++ b/drivers/hwmon/pmbus/adm1275.c
> [ ... ]
>> @@ -581,7 +606,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
>
> [Severity: High]
> 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;
> }
>
> Does this code read uninitialized stack memory if the device returns a
> string that matches a valid model name prefix, but is shorter than the valid
> model name length?
>
> 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.
>
> [ ... ]
>> @@ -685,12 +722,23 @@ static int adm1275_probe(struct i2c_client *client)
>> break;
>> case adm1272:
>> case adm1273:
>> + case bd12790:
>> + {
> [ ... ]
>
> [Severity: High]
> This isn't a bug introduced by this patch, but looking further down in
> adm1275_probe(), could the coefficient calculations for current and power
> overflow a 32-bit unsigned integer?
>
> info->m[PSC_CURRENT_OUT] =
> coefficients[cindex].m * shunt / 1000;
>
> info->m[PSC_POWER] =
> coefficients[pindex].m * shunt / 1000;
>
> If a larger shunt resistor value is provided via device tree
> (e.g., 200,000 micro-ohms to measure lower currents), multiplying this by
> larger coefficients like 30631 (used for ADM1293) evaluates to 6,126,200,000.
>
> Since shunt is a u32 and the coefficient promotes to int, this operation uses
> 32-bit unsigned arithmetic.
>
> Does this wrap-around the maximum 32-bit value of 4,294,967,295 and result
> in drastically incorrect telemetry scaling factors?
>
Feel freew to fix (or not to fix) those problems. They should get fixed, but
not necessarily as part of this series.
Thanks,
Guenter
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: mediatek: mt6323: add AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add the devicetree node for the mt6323 AUXADC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
arch/arm/boot/dts/mediatek/mt6323.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index c230c865116d..c070f4b0936c 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -14,6 +14,11 @@ pmic: mt6323 {
interrupt-controller;
#interrupt-cells = <2>;
+ mt6323_adc: adc {
+ compatible = "mediatek,mt6323-auxadc";
+ #io-channel-cells = <1>;
+ };
+
mt6323_leds: leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/4] mfd: mt6397-core: add mt6323 AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 PMIC includes an AUXADC. Register the AUXADC in the mt6323
devices array to allow the corresponding driver to probe using compatible
string.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
drivers/mfd/mt6397-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 3e58d0764c7e..013b0857fb54 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
static const struct mfd_cell mt6323_devs[] = {
{
+ .name = "mt6323-auxadc",
+ .of_compatible = "mediatek,mt6323-auxadc",
+ }, {
.name = "mt6323-rtc",
.num_resources = ARRAY_SIZE(mt6323_rtc_resources),
.resources = mt6323_rtc_resources,
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar, Andy Shevchenko
In-Reply-To: <20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
provides support for reading various channels including battery and
charger voltages, battery and chip temperature, current sensing and
accessory detection.
Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
MAINTAINERS | 1 +
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 314 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 327 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2551c8cd9e9d..fb40128451dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16260,6 +16260,7 @@ MEDIATEK MT6323 PMIC AUXADC DRIVER
M: Roman Vivchar <rva333@protonmail.com>
L: linux-iio@vger.kernel.org
S: Maintained
+F: drivers/iio/adc/mt6323-auxadc.c
F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
MEDIATEK MT6735 CLOCK & RESET DRIVERS
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 60038ae8dfc4..a03614b46041 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1137,6 +1137,17 @@ config MCP3911
This driver can also be built as a module. If so, the module will be
called mcp3911.
+config MEDIATEK_MT6323_AUXADC
+ tristate "MediaTek MT6323 PMIC AUXADC driver"
+ depends on MFD_MT6397
+ help
+ Say yes here to enable support for MediaTek MT6323 PMIC Auxiliary ADC.
+ This driver provides multiple channels for system monitoring,
+ such as battery voltage, PMIC temperature, and others.
+
+ This driver can also be built as a module. If so, the module will be
+ called mt6323-auxadc.
+
config MEDIATEK_MT6359_AUXADC
tristate "MediaTek MT6359 PMIC AUXADC driver"
depends on MFD_MT6397
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index c76550415ff1..58161750d6e3 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_MCP3564) += mcp3564.o
obj-$(CONFIG_MCP3911) += mcp3911.o
+obj-$(CONFIG_MEDIATEK_MT6323_AUXADC) += mt6323-auxadc.o
obj-$(CONFIG_MEDIATEK_MT6359_AUXADC) += mt6359-auxadc.o
obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o
diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
new file mode 100644
index 000000000000..572466c3f375
--- /dev/null
+++ b/drivers/iio/adc/mt6323-auxadc.c
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Roman Vivchar <rva333@protonmail.com>
+ *
+ * Based on drivers/iio/adc/mt6359-auxadc.c
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/iio/iio.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/stringify.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+#include <linux/mfd/mt6323/registers.h>
+
+#include <dt-bindings/iio/adc/mediatek,mt6323-auxadc.h>
+
+#define AUXADC_STRUP_CON10_RSTB_SEL BIT(7)
+#define AUXADC_STRUP_CON10_RSTB_SW BIT(5)
+
+#define AUXADC_TOP_CKPDN2_CTL_CK BIT(5)
+
+#define AUXADC_TRIM_CH2_MASK GENMASK(11, 10)
+#define AUXADC_TRIM_CH4_MASK GENMASK(9, 8)
+#define AUXADC_TRIM_CH5_MASK GENMASK(5, 4)
+#define AUXADC_TRIM_CH6_MASK GENMASK(3, 2)
+
+#define AUXADC_CON27_VREF18_ENB_MD BIT(15)
+#define AUXADC_CON27_MD_STATUS BIT(0)
+
+#define AUXADC_CON19_GPS_STATUS BIT(1)
+
+#define AUXADC_CON26_VREF18_SELB BIT(1)
+#define AUXADC_CON26_DECI_GDLY_SEL BIT(0)
+
+#define AUXADC_CON11_VBUF_EN BIT(4)
+
+#define AUXADC_CON19_DECI_GDLY_MASK GENMASK(15, 14)
+#define AUXADC_ADC19_BUSY_MASK GENMASK(15, 1)
+#define AUXADC_READY_MASK BIT(15)
+#define AUXADC_DATA_MASK GENMASK(14, 0)
+
+#define AUXADC_CON9_OSR_MASK GENMASK(12, 10)
+#define AUXADC_DEFAULT_OSR 3
+
+#define MTK_PMIC_IIO_CHAN(_name, _chan, _addr) \
+{ \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = _chan, \
+ .address = _addr, \
+ .datasheet_name = __stringify(_name), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+/*
+ * AUXADC reports everything in mV, including temperature and
+ * current channels. Channel macros are mapped such that their
+ * ID matches their respective hardware bit position in CON22.
+ */
+static const struct iio_chan_spec mt6323_auxadc_channels[] = {
+ MTK_PMIC_IIO_CHAN(baton2, MT6323_AUXADC_BATON2, MT6323_AUXADC_ADC6),
+ MTK_PMIC_IIO_CHAN(ch6, MT6323_AUXADC_CH6, MT6323_AUXADC_ADC11),
+ MTK_PMIC_IIO_CHAN(bat_temp, MT6323_AUXADC_BAT_TEMP, MT6323_AUXADC_ADC5),
+ MTK_PMIC_IIO_CHAN(chip_temp, MT6323_AUXADC_CHIP_TEMP, MT6323_AUXADC_ADC4),
+ MTK_PMIC_IIO_CHAN(vcdt, MT6323_AUXADC_VCDT, MT6323_AUXADC_ADC2),
+ MTK_PMIC_IIO_CHAN(baton1, MT6323_AUXADC_BATON1, MT6323_AUXADC_ADC3),
+ MTK_PMIC_IIO_CHAN(isense, MT6323_AUXADC_ISENSE, MT6323_AUXADC_ADC1),
+ MTK_PMIC_IIO_CHAN(batsns, MT6323_AUXADC_BATSNS, MT6323_AUXADC_ADC0),
+ MTK_PMIC_IIO_CHAN(accdet, MT6323_AUXADC_ACCDET, MT6323_AUXADC_ADC7),
+};
+
+/*
+ * The MediaTek MT6323 (as well as a lot of other PMICs) has the following hierarchy:
+ * PMIC AUXADC <- PMIC MFD <- SoC PWRAP (wrapper for PWRAP FSM)
+ *
+ * Therefore, PWRAP regmap should be obtained using dev->parent->parent.
+ */
+struct mt6323_auxadc {
+ struct regmap *regmap;
+ /* AUXADC doesn't support reading multiple channels simultaneously. */
+ struct mutex lock;
+};
+
+static int mt6323_auxadc_prepare_channel(struct mt6323_auxadc *auxadc)
+{
+ struct regmap *map = auxadc->regmap;
+ u32 val;
+ int ret;
+
+ ret = regmap_read(map, MT6323_AUXADC_CON19, &val);
+ if (ret)
+ return ret;
+
+ /* The ADC is idle. */
+ if (!(val & AUXADC_CON19_DECI_GDLY_MASK))
+ return 0;
+
+ ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19, val,
+ !(val & AUXADC_ADC19_BUSY_MASK),
+ 10, 500);
+ if (ret)
+ return ret;
+
+ return regmap_clear_bits(map, MT6323_AUXADC_CON19,
+ AUXADC_CON19_DECI_GDLY_MASK);
+}
+
+static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
+ unsigned long channel)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
+ if (ret)
+ return ret;
+
+ return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+}
+
+static int mt6323_auxadc_release(struct mt6323_auxadc *auxadc,
+ unsigned long channel)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+ if (ret)
+ return ret;
+
+ return regmap_clear_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
+}
+
+static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
+ const struct iio_chan_spec *chan, int *out)
+{
+ struct regmap *map = auxadc->regmap;
+ u32 val;
+ int ret;
+
+ ret = regmap_read_poll_timeout(map, chan->address,
+ val, (val & AUXADC_READY_MASK),
+ 1 * USEC_PER_MSEC, 100 * USEC_PER_MSEC);
+ if (ret)
+ return ret;
+
+ *out = FIELD_GET(AUXADC_DATA_MASK, val);
+
+ return 0;
+}
+
+static int mt6323_auxadc_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct mt6323_auxadc *auxadc = iio_priv(indio_dev);
+ int ret, mult;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ if (chan->channel == MT6323_AUXADC_ISENSE ||
+ chan->channel == MT6323_AUXADC_BATSNS)
+ mult = 4;
+ else
+ mult = 1;
+
+ /* 1800mV full range with 15-bit resolution. */
+ *val = mult * 1800;
+ *val2 = 15;
+
+ return IIO_VAL_FRACTIONAL_LOG2;
+ case IIO_CHAN_INFO_RAW: {
+ guard(mutex)(&auxadc->lock);
+
+ ret = mt6323_auxadc_prepare_channel(auxadc);
+ if (ret)
+ return ret;
+
+ ret = mt6323_auxadc_request(auxadc, chan->channel);
+ if (ret)
+ return ret;
+
+ /* Hardware limitation: the AUXADC needs a delay to become ready. */
+ fsleep(300);
+
+ ret = mt6323_auxadc_read(auxadc, chan, val);
+
+ if (mt6323_auxadc_release(auxadc, chan->channel))
+ dev_err(&indio_dev->dev,
+ "failed to release channel %d\n", chan->channel);
+
+ if (ret)
+ return ret;
+
+ return IIO_VAL_INT;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static int mt6323_auxadc_init(struct mt6323_auxadc *auxadc)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_set_bits(map, MT6323_STRUP_CON10,
+ AUXADC_STRUP_CON10_RSTB_SW |
+ AUXADC_STRUP_CON10_RSTB_SEL);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_TOP_CKPDN2, AUXADC_TOP_CKPDN2_CTL_CK);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(map, MT6323_AUXADC_CON10,
+ AUXADC_TRIM_CH2_MASK | AUXADC_TRIM_CH4_MASK |
+ AUXADC_TRIM_CH5_MASK | AUXADC_TRIM_CH6_MASK,
+ FIELD_PREP(AUXADC_TRIM_CH2_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH4_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH5_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH6_MASK, 1));
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON27,
+ AUXADC_CON27_VREF18_ENB_MD |
+ AUXADC_CON27_MD_STATUS);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON19, AUXADC_CON19_GPS_STATUS);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON26,
+ AUXADC_CON26_VREF18_SELB |
+ AUXADC_CON26_DECI_GDLY_SEL);
+ if (ret)
+ return ret;
+
+ return regmap_update_bits(map, MT6323_AUXADC_CON9, AUXADC_CON9_OSR_MASK,
+ FIELD_PREP(AUXADC_CON9_OSR_MASK, AUXADC_DEFAULT_OSR));
+}
+
+static const struct iio_info mt6323_auxadc_iio_info = {
+ .read_raw = mt6323_auxadc_read_raw,
+};
+
+static int mt6323_auxadc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mt6323_auxadc *auxadc;
+ struct regmap *regmap;
+ struct iio_dev *iio;
+ int ret;
+
+ regmap = dev_get_regmap(dev->parent->parent, NULL);
+ if (!regmap)
+ return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
+
+ iio = devm_iio_device_alloc(dev, sizeof(*auxadc));
+ if (!iio)
+ return -ENOMEM;
+
+ auxadc = iio_priv(iio);
+ auxadc->regmap = regmap;
+
+ ret = devm_mutex_init(dev, &auxadc->lock);
+ if (ret)
+ return ret;
+
+ ret = mt6323_auxadc_init(auxadc);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to initialize auxadc\n");
+
+ iio->name = "mt6323-auxadc";
+ iio->info = &mt6323_auxadc_iio_info;
+ iio->modes = INDIO_DIRECT_MODE;
+ iio->channels = mt6323_auxadc_channels;
+ iio->num_channels = ARRAY_SIZE(mt6323_auxadc_channels);
+
+ return devm_iio_device_register(dev, iio);
+}
+
+static const struct of_device_id mt6323_auxadc_of_match[] = {
+ { .compatible = "mediatek,mt6323-auxadc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mt6323_auxadc_of_match);
+
+static struct platform_driver mt6323_auxadc_driver = {
+ .driver = {
+ .name = "mt6323-auxadc",
+ .of_match_table = mt6323_auxadc_of_match,
+ },
+ .probe = mt6323_auxadc_probe,
+};
+module_platform_driver(mt6323_auxadc_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek MT6323 PMIC AUXADC Driver");
--
2.54.0
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
temperature, and other internal measurements. The IP block is not
register-compatible with mt6359 and should use a separate driver.
Add the devicetree binding documentation and the associated header file
defining the ADC channel constants.
Also change the description to 'MT6350 series and similar' because
the binding already includes more than mt635x series PMICs.
Finally, add the MAINTAINERS entry for the header with ADC constants.
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 ++-
MAINTAINERS | 6 ++++++
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++++++++++++++++++++++
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
index 5d4ab701f51a..852eb7336a5a 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek MT6350 series PMIC AUXADC
+title: MediaTek MT6350 series and similar PMIC AUXADC
maintainers:
- AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
@@ -19,6 +19,7 @@ description:
properties:
compatible:
enum:
+ - mediatek,mt6323-auxadc
- mediatek,mt6357-auxadc
- mediatek,mt6358-auxadc
- mediatek,mt6359-auxadc
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..2551c8cd9e9d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16256,6 +16256,12 @@ S: Maintained
F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
F: drivers/mmc/host/mtk-sd.c
+MEDIATEK MT6323 PMIC AUXADC DRIVER
+M: Roman Vivchar <rva333@protonmail.com>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
+
MEDIATEK MT6735 CLOCK & RESET DRIVERS
M: Yassine Oudjana <y.oudjana@protonmail.com>
L: linux-clk@vger.kernel.org
diff --git a/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
new file mode 100644
index 000000000000..6ee9a9ecffc1
--- /dev/null
+++ b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
+#define _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
+
+#define MT6323_AUXADC_BATON2 0
+#define MT6323_AUXADC_CH6 1
+#define MT6323_AUXADC_BAT_TEMP 2
+#define MT6323_AUXADC_CHIP_TEMP 3
+#define MT6323_AUXADC_VCDT 4
+#define MT6323_AUXADC_BATON1 5
+#define MT6323_AUXADC_ISENSE 6
+#define MT6323_AUXADC_BATSNS 7
+#define MT6323_AUXADC_ACCDET 8
+#define MT6323_AUXADC_AUDIO0 9
+#define MT6323_AUXADC_AUDIO1 10
+#define MT6323_AUXADC_AUDIO2 11
+#define MT6323_AUXADC_AUDIO3 12
+#define MT6323_AUXADC_AUDIO4 13
+#define MT6323_AUXADC_AUDIO5 14
+#define MT6323_AUXADC_AUDIO6 15
+#define MT6323_AUXADC_AUDIO7 16
+
+#endif
--
2.54.0
^ permalink raw reply related
* [PATCH v3 0/4] AUXADC driver for the MediaTek mt6323 PMIC
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar, Andy Shevchenko
This series adds support for the 15-bit AUXADC hardware block found on
the MediaTek mt6323 PMIC.
The previous version of the series for all AUXADC, EFUSE and thermal
drivers was split after Krzysztof's comment [1].
Tested on the MediaTek mt6572 and mt8163 SoCs (Ben), both paired with a
mt6323.
The other parts (EFUSE and thermal) will probably be sent this week.
[1]: https://lore.kernel.org/linux-mediatek/20260504-mt6323-v1-0-799b58b355ff@protonmail.com/T/#med30fad67a090be35f549231336b2dec295233f6
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
Changes in v3:
- AUXADC driver:
- Add comment for channels table about voltage and channel IDs (Jonathan)
- Add comment for mutex in the 'mt6323_auxadc' struct (Jonathan)
- Break 'regmap_read_poll_timeout' on logical boundaries (Andy)
- Switch to 'guard' from 'scoped_guard' (Andy)
- Link to v2: https://patch.msgid.link/20260609-mt6323-adc-v2-0-aa93a22309f9@protonmail.com
Changes in v2:
- AUXADC driver:
- Drop channel type from the MTK_PMIC_IIO_CHAN macro (Nuno)
- Drop kerneldoc for the mt6323_auxadc struct (Nuno)
- Add channel release to save power (Sashiko, Jonathan)
- Drop 'reg' variable in the mt6323_auxadc_read (Jonathan)
- Sort variables in the mt6323_auxadc_probe (Jonathan)
- Maintainers:
- Drop linux-mediatek list (Andy)
- Split between dt-bindings and driver to avoid missing file (Nuno)
- Link to v1: https://patch.msgid.link/20260602-mt6323-adc-v1-0-68ec737508ee@protonmail.com
Changes after split:
- dt-bindings: Change 'MT63xx' to 'MT6350 series and similar' (Jonathan)
- AUXADC driver:
- Add missing headers (Andy)
- Fix AUXADC_TRIM_CH* values (Andy)
- Rename masks to include their register name (Jonathan)
- Fix formatting (Andy, Jonathan)
- Replace channel address with actual register value (Jonathan), align the table
- Replace IIO_TEMP with IIO_VOLTAGE, since the actual output is still mV, not mC
- Rename constants to match their registers (Jonathan)
- Remove 'if/else if/else' in the mt6323_auxadc_read_raw (Andy)
- Add comments for fsleep, ADC range and resolution (Andy, Jonathan)
- Remove useless error messages (Andy)
- Maintainers:
- Explicitly include mt6323 in the name (Jonathan)
- Squash with AUXADC driver commit (Krzysztof)
- Set status back to 'Maintained'
- Link to a previous series: https://patch.msgid.link/20260512-mt6323-v2-0-3efcba579e88@protonmail.com
---
Roman Vivchar (4):
dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
mfd: mt6397-core: add mt6323 AUXADC support
ARM: dts: mediatek: mt6323: add AUXADC support
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 +-
MAINTAINERS | 7 +
arch/arm/boot/dts/mediatek/mt6323.dtsi | 5 +
drivers/iio/adc/Kconfig | 11 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 314 +++++++++++++++++++++
drivers/mfd/mt6397-core.c | 3 +
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++
8 files changed, 367 insertions(+), 1 deletion(-)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260525-mt6323-adc-3befce36cbf2
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply
* Re: [PATCH 6/7] hwmon: adm1275: Support ROHM BD12790
From: Guenter Roeck @ 2026-06-16 14:15 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen, Matti Vaittinen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Wensheng Wang, Ashish Yadav, Kim Seer Paller,
Cedric Encarnacion, Chris Packham, Yuxi Wang, Charles Hsu,
ChiShih Tsai, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <8ca875d21f2d9a4d53a87b47a5e6efab48266178.1781591132.git.mazziesaccount@gmail.com>
On 6/15/26 23:44, Matti Vaittinen wrote:
> 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
>
> ---
> Originally this patch was AI-generated. I did pretty much re-write the
> probe changes by hand, and also fixed some of the coefficient math
> afterwards :/ But yeah, this one was AI "assisted". :)
>
> drivers/hwmon/pmbus/Kconfig | 4 +--
> drivers/hwmon/pmbus/adm1275.c | 53 +++++++++++++++++++++++++++++------
> 2 files changed, 47 insertions(+), 10 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 838b8827eb76..9e21dd4083e9 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,8 +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)
> +/* The BD127x0 data sheets mark TSFILT bit as reserved. */
> +#define BD127X0_PMON_DEFCONFIG (ADM1278_VOUT_EN | ADM1278_TEMP1_EN)
Please don't use such placeholders. Just use BD12780_PMON_DEFCONFIG
for both chips, similar to how the defines for all other chips
are handled.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH RFC 3/9] net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass
From: Konrad Dybcio @ 2026-06-16 14:14 UTC (permalink / raw)
To: Andrew Lunn, Mohd Ayaan Anwar, Bjorn Andersson,
Bartosz Golaszewski, Eric Chanudet, Lucas Karpinski,
Andrew Halaney
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <82705420-771d-41bf-a4d9-ed94dff86ff0@lunn.ch>
On 6/15/26 6:48 PM, Andrew Lunn wrote:
> On Mon, Jun 15, 2026 at 09:24:07AM +0530, Mohd Ayaan Anwar wrote:
>> Hello Andrew,
>> On Thu, Jun 11, 2026 at 10:54:37PM +0200, Andrew Lunn wrote:
>>> On Fri, Jun 12, 2026 at 12:06:59AM +0530, Mohd Ayaan Anwar wrote:
>>>> When "rgmii-id" is selected the PHY supplies both TX and RX delays, so
>>>> the MAC must not add its own. The driver currently falls through to the
>>>> generic DLL initialisation path which programs it to add a delay.
>>>>
>>>> Power down the DLL and set DDR bypass mode for RGMII_ID, then program
>>>> the IO_MACRO via a new ethqos_rgmii_id_macro_init() helper. Also fix
>>>> ethqos_set_clk_tx_rate() to not double the clock rate in bypass mode at
>>>> 100M/10M, and remove RGMII_ID from the phase-shift suppression in
>>>> ethqos_rgmii_macro_init() since RGMII_ID no longer reaches that path.
>>>
>>> I'm curious how this works at the moment? Do no boards make use of
>>> RGMII ID? Are all current boards broken?
>>
>> Searching through the DTS, I found that we have two boards using "rgmii"
>> (qcs404-evb-4000.dts and sa8155-adp.dts) and another board using
>> "rgmii-txid" (sa8540p-ride.dts). No board which uses RGMII ID.
>
> So this causes problems. We cannot break existing boards, yet it would
> be good to fix the current broken behaviour.
These are a funny bunch.. QCS404 is a stuck in a perpetual cycle of
"no one has the hardware" and "someone has the hw but zero interest or
time". I think we've considered it for removal at one point..
I'm not sure to what degree the two SA8xxx boards are used. They
may have been stuck in some sort of a limbo. Maybe Bjorn knows?
Also +Cc some of the folks that contributed to them in the past
Konrad
^ permalink raw reply
* Re: [PATCH 3/7] hwmon: adm1275: Support ROHM BD12780
From: Guenter Roeck @ 2026-06-16 14:13 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen, Matti Vaittinen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Wensheng Wang, Ashish Yadav, Kim Seer Paller,
Cedric Encarnacion, Chris Packham, Yuxi Wang, Charles Hsu,
ChiShih Tsai, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <c92f1356fbf967dee3130f2eb0da08eb84800d47.1781591132.git.mazziesaccount@gmail.com>
On 6/15/26 23:36, Matti Vaittinen wrote:
> 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>
> ---
> drivers/hwmon/pmbus/Kconfig | 2 +-
> drivers/hwmon/pmbus/adm1275.c | 46 +++++++++++++++++++++++++++++------
> 2 files changed, 39 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 bc2a6a07dc3e..838b8827eb76 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,21 @@ static const struct i2c_device_id adm1275_id[] = {
> { "adm1281", adm1281 },
> { "adm1293", adm1293 },
> { "adm1294", adm1294 },
> + /*
> + * The BD12780a is functionally identical to BD12780(*). Even the pmbus ID
> + * register contents are same. When instantiated from the DT, it is required
> + * to have the bd12780 as a fall-back. We still need the bd12780a ID here,
> + * because the i2c_device_id is created from the first compatible, not from
> + * the fall-back entry.
> + * (*)Until proven to differ. I prefer having own compatible for these
> + * variants for that day. Please note that even though the probe is called
> + * based on the 'bd12780a' -entry, the ID is picked at probe based on the
> + * pmbus register contents and not by DT entry. Thus, if the bd12780 and
> + * bd12780a are found to require different handling, then this needs to be
> + * changed, or bd12780a is handled as bd12780.
> + */
> + { "bd12780", bd12780 },
> + { "bd12780a", /* driver data unused, see --^ */ },
We don't usually do that. There are various A/B/C variants for many chips,
and we just use the base name unless a difference is warranted. Either this
is needed, and driver data is needed as well, or it isn't. If it is not needed,
it should be dropped.
> { "mc09c", sq24905c },
> { }
> };
> @@ -494,12 +511,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 +553,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 +581,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 +685,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;
>
> @@ -712,7 +732,16 @@ static int adm1275_probe(struct i2c_client *client)
> break;
> case adm1278:
> case adm1281:
> + case bd12780:
> case sq24905c:
> + {
> + u16 defconfig;
> +
> + if (data->id == bd12780)
> + defconfig = BD12780_PMON_DEFCONFIG;
> + else
> + defconfig = ADM1278_PMON_DEFCONFIG;
> +
Please add a separate case statement for the new chip
and do not overload existing chip data.
> data->have_vout = true;
> data->have_pin_max = true;
> data->have_temp_max = true;
> @@ -728,13 +757,14 @@ 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, 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;
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: purwa: Drop the Hamoa workaround for PDC
From: Konrad Dybcio @ 2026-06-16 14:09 UTC (permalink / raw)
To: Maulik Shah, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260616-purwa-pdc-v2-2-8dda7ef25ce5@oss.qualcomm.com>
On 6/16/26 12:27 PM, Maulik Shah wrote:
> X1P42100 (Purwa) shares the X1E80100 (Hamoa) PDC device, but the hardware
> register bug addressed in commit e9a48ea4d90b ("irqchip/qcom-pdc:
> Workaround hardware register bug on X1E80100") is already fixed in
> X1P42100 silicon.
>
> X1E80100 compatible forces the software workaround. Use the X1P42100
> specific compatible string for the PDC node to remove the workaround.
>
> Fixes: f08edb529916 ("arm64: dts: qcom: Add X1P42100 SoC and CRD")
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: interrupt-controller: qcom,pdc: Document Purwa PDC
From: Konrad Dybcio @ 2026-06-16 14:09 UTC (permalink / raw)
To: Maulik Shah, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260616-purwa-pdc-v2-1-8dda7ef25ce5@oss.qualcomm.com>
On 6/16/26 12:27 PM, Maulik Shah wrote:
> X1P42100 (Purwa) shares the X1E80100 (Hamoa) PDC device, but the hardware
> register bug addressed in commit e9a48ea4d90b ("irqchip/qcom-pdc:
> Workaround hardware register bug on X1E80100") is already fixed in
> X1P42100 silicon.
>
> X1E80100 compatible forces the software workaround. Add PDC compatible
> for purwa as "qcom,x1p42100-pdc" to remove the workaround from Purwa.
>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 6/7] hwmon: adm1275: Support ROHM BD12790
From: Guenter Roeck @ 2026-06-16 14:08 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen, Matti Vaittinen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Wensheng Wang, Ashish Yadav, Kim Seer Paller,
Cedric Encarnacion, Chris Packham, Yuxi Wang, Charles Hsu,
ChiShih Tsai, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <8ca875d21f2d9a4d53a87b47a5e6efab48266178.1781591132.git.mazziesaccount@gmail.com>
On 6/15/26 23:44, Matti Vaittinen wrote:
> 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
>
> ---
> Originally this patch was AI-generated. I did pretty much re-write the
> probe changes by hand, and also fixed some of the coefficient math
> afterwards :/ But yeah, this one was AI "assisted". :)
>
> drivers/hwmon/pmbus/Kconfig | 4 +--
> drivers/hwmon/pmbus/adm1275.c | 53 +++++++++++++++++++++++++++++------
> 2 files changed, 47 insertions(+), 10 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 838b8827eb76..9e21dd4083e9 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,8 +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)
> +/* The BD127x0 data sheets mark TSFILT bit as reserved. */
> +#define BD127X0_PMON_DEFCONFIG (ADM1278_VOUT_EN | ADM1278_TEMP1_EN)
>
> #define ADM1293_IRANGE_25 0
> #define ADM1293_IRANGE_50 BIT(6)
> @@ -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^(-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 */
> @@ -504,6 +528,7 @@ static const struct i2c_device_id adm1275_id[] = {
> */
> { "bd12780", bd12780 },
> { "bd12780a", /* driver data unused, see --^ */ },
> + { "bd12790", bd12790 },
> { "mc09c", sq24905c },
> { }
> };
> @@ -581,7 +606,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;
> @@ -655,12 +681,23 @@ static int adm1275_probe(struct i2c_client *client)
> break;
> case adm1272:
> case adm1273:
> + case bd12790:
Please don't overload the existing case statements.
Just add separate case statements for the new chips.
Thanks,
Guenter
> + {
> + u16 defconfig;
> +
> data->have_vout = true;
> data->have_pin_max = true;
> data->have_temp_max = true;
> data->have_power_sampling = true;
>
> - coefficients = adm1272_coefficients;
> + if (data->id == bd12790) {
> + coefficients = bd12790_coefficients;
> + defconfig = BD127X0_PMON_DEFCONFIG;
> + } else {
> + coefficients = adm1272_coefficients;
> + defconfig = ADM1278_PMON_DEFCONFIG;
> + }
> +
> vindex = (config & ADM1275_VRANGE) ? 1 : 0;
> cindex = (config & ADM1272_IRANGE) ? 3 : 2;
> /* pindex depends on the combination of the above */
> @@ -685,14 +722,14 @@ 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,
> - ADM1278_PMON_DEFCONFIG);
> + ret = adm1275_enable_vout_temp(data, client, config, 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;
> @@ -738,7 +775,7 @@ static int adm1275_probe(struct i2c_client *client)
> u16 defconfig;
>
> if (data->id == bd12780)
> - defconfig = BD12780_PMON_DEFCONFIG;
> + defconfig = BD127X0_PMON_DEFCONFIG;
> else
> defconfig = ADM1278_PMON_DEFCONFIG;
>
^ permalink raw reply
* Re: [PATCH v8 5/5] iio: adc: versal-sysmon: add oversampling support
From: sashiko-bot @ 2026-06-16 14:08 UTC (permalink / raw)
To: Salih Erim; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260616131559.3029543-6-salih.erim@amd.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Static temperature channels are missing the oversampling ratio info mask, rendering it unavailable if no dynamic temperature satellites are present.
- [Medium] The driver's cached oversampling state is initialized to 1 without synchronizing with the hardware state.
--
commit 81f60069d7c6ab5d01862c8402ee14a0ef2ad23e
Author: Salih Erim <salih.erim@amd.com>
iio: adc: versal-sysmon: add oversampling support
Add support for reading and writing the oversampling ratio through
the IIO oversampling_ratio attribute. The hardware supports averaging
2, 4, 8, or 16 samples, plus a ratio of 1 (no averaging).
> diff --git a/drivers/iio/adc/versal-sysmon-core.c b/drivers/iio/adc/versal-sysmon-core.c
> index 8d567f9fa05d7..309c39b515f6d 100644
> --- a/drivers/iio/adc/versal-sysmon-core.c
> +++ b/drivers/iio/adc/versal-sysmon-core.c
[ ... ]
> @@ -787,7 +932,11 @@ static int sysmon_parse_fw(struct iio_dev *indio_dev, struct device *dev, int ir
> .address = SYSMON_TEMP_SAT_BASE +
> (reg - 1) * SYSMON_REG_STRIDE,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> - .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
> + .info_mask_shared_by_type =
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),
> + .info_mask_shared_by_type_available =
> + BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),
> .datasheet_name = label,
> };
> }
[Severity: Medium]
Since the dynamically parsed temperature channels get the oversampling ratio
masks here, should the static temperature channels defined via
SYSMON_CHAN_TEMP also be updated to include these masks?
If no dynamic temperature satellites are present, the static temperature
channels won't expose the in_temp_oversampling_ratio sysfs attribute,
preventing oversampling configuration for those default channels.
[ ... ]
> @@ -834,6 +983,8 @@ int devm_versal_sysmon_core_probe(struct device *dev, struct regmap *regmap)
>
> sysmon = iio_priv(indio_dev);
> sysmon->regmap = regmap;
> + sysmon->temp_oversampling = 1;
> + sysmon->supply_oversampling = 1;
[Severity: Medium]
Are these initial cached oversampling values guaranteed to match the hardware
state?
If a bootloader or a previous kernel instance left the SysMon configured with
a higher oversampling ratio, the IIO sysfs attribute will incorrectly report
1x oversampling while the hardware actively operates at the previous setting.
Should the driver read SYSMON_CONFIG to initialize this cache, or explicitly
write the default 1x value to the hardware to ensure the state is synchronized?
>
> ret = devm_mutex_init(dev, &sysmon->lock);
> if (ret)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616131559.3029543-1-salih.erim@amd.com?part=5
^ permalink raw reply
* Re: [PATCH RFC v4 2/9] dt-bindings: phy: qcom-qmp: Add PHY selector and Glymur link-mode macros
From: Konrad Dybcio @ 2026-06-16 14:07 UTC (permalink / raw)
To: Qiang Yu, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260518-link_mode_0519-v4-2-269cd73cc5d1@oss.qualcomm.com>
On 5/19/26 7:47 AM, Qiang Yu wrote:
> Add two sets of constants to phy-qcom-qmp.h to support upcoming multiple
> link mode QMP PHY:
>
> - QMP_PHY_SELECTOR_0 / QMP_PHY_SELECTOR_1: generic logical PHY index
> values for QMP providers that expose multiple PHY instances under a
> single DT node (i.e. #phy-cells = <1>).
>
> - QMP_PCIE_GLYMUR_MODE_X8 / QMP_PCIE_GLYMUR_MODE_X4X4: link-mode
> values for the Glymur Gen5x8 PCIe PHY "qcom,link-mode" syscon property,
> selecting between the x8 single-PHY and x4+x4 dual-PHY topologies.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> include/dt-bindings/phy/phy-qcom-qmp.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/dt-bindings/phy/phy-qcom-qmp.h b/include/dt-bindings/phy/phy-qcom-qmp.h
> index 6b43ea9e0051..befa76f8392f 100644
> --- a/include/dt-bindings/phy/phy-qcom-qmp.h
> +++ b/include/dt-bindings/phy/phy-qcom-qmp.h
> @@ -21,4 +21,12 @@
> #define QMP_PCIE_PIPE_CLK 0
> #define QMP_PCIE_PHY_AUX_CLK 1
>
> +/* Generic QMP logical PHY selectors */
> +#define QMP_PHY_SELECTOR_0 0
> +#define QMP_PHY_SELECTOR_1 1
Is this for the second phy cell? FWIW I think it's fine to use raw
numbers as they're just indices (i.e. "nth bifurcated phy") anyway
Konrad
^ permalink raw reply
* Re: [PATCH RFC v4 5/9] phy: qcom: qmp-pcie: Refactor pipe clk register and parse_dt helpers
From: Konrad Dybcio @ 2026-06-16 14:05 UTC (permalink / raw)
To: Qiang Yu, Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <ahk57lEoWQtkGsJt@hu-qianyu-lv.qualcomm.com>
On 5/29/26 9:02 AM, Qiang Yu wrote:
> On Thu, May 28, 2026 at 04:48:24PM +0300, Dmitry Baryshkov wrote:
>> On Fri, May 22, 2026 at 04:27:35PM +0530, Manivannan Sadhasivam wrote:
>>> On Wed, May 20, 2026 at 07:25:01PM +0300, Dmitry Baryshkov wrote:
>>>> On Mon, May 18, 2026 at 10:47:16PM -0700, Qiang Yu wrote:
>>>>> Some QMP PCIe PHY hardware blocks can be split into multiple sub-PHYs
>>>>> under a single DT node, each requiring its own pipe clock registration and
>>>>> DT resource mapping. The current helpers are tightly coupled to a single
>>>>> qmp_pcie instance, which prevents reuse across sub-PHY instances.
>>>>>
>>>>> Refactor __phy_pipe_clk_register() as a generic helper and reduce
>>>>> phy_pipe_clk_register() to a thin wrapper around it. Similarly, extract
>>>>> qmp_pcie_parse_dt_common() from qmp_pcie_parse_dt() to hold the register-
>>>>> mapping and pipe-clock setup that will be shared between sub-PHY instances,
>>>>> with pipe clock names parameterised per instance.
>>>>>
>>>>> This is a preparatory step before adding multi-PHY support. No functional
>>>>> change for existing platforms.
>>>>>
>>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>>>> ---
>>>>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 76 ++++++++++++++++++--------------
>>>>> 1 file changed, 44 insertions(+), 32 deletions(-)
>>>>
>>>> I'd suggest splitting the Glymur PHY to a separate driver. Otherwise we
>>>> end up having too many single-platform, single-device specifics which
>>>> don't apply to other platforms.
>>>>
>>>
>>> I don't think that's really needed. This shared PHY concept is going to be
>>> applicable to upcoming SoCs as well. And moreover, the split won't be clean
>>> either. We still need to reuse a lot of common logic in the 'phy-qcom-qmp-pcie'
>>> driver and may only end up keeping very minimal code in
>>> 'phy-qcom-qmp-pcie-glymur'.
>>
>> Then splitting makes even more sense. Let's not clutter the existing
>> driver with too many conditions and options.
>>
>>>
>>> If you are concerned about the file size of 'phy-qcom-qmp-pcie', then we should
>>> move the SoC specific 'cfg' structs into a separate file as that's what
>>> occupying majority of the space.
>>
>> No, it's really the 'shared' part.
>>
>
> To confirm, are you okay with some code duplication between the new
> Glymur-specific driver and phy-qcom-qmp-pcie driver.
That's a necessity, to some degree. See e.g. qmp-combo and qmp-usbc
Konrad
^ permalink raw reply
* Re: [PATCH 7/7] hwmon: adm1275: Support module auto-loading
From: Guenter Roeck @ 2026-06-16 14:04 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen, Matti Vaittinen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Wensheng Wang, Ashish Yadav, Kim Seer Paller,
Cedric Encarnacion, Chris Packham, Yuxi Wang, Charles Hsu,
ChiShih Tsai, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <634e76680ed93e58ebeb35db080138b791cb6c27.1781591132.git.mazziesaccount@gmail.com>
On 6/15/26 23:47, Matti Vaittinen wrote:
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> Populating the spi_device_id -table is not enough to make the
> driver module automatically load when device-tree node for the bd12780
> 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*Crohm,bd12780C*
> alias: of:N*T*Crohm,bd12780
>
> I suspect these are required for the module loading to work.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>
> ---
>
> I did not add of_device_ids for other supported ICs as I can't verify it
> doesn't cause side-effects. Please let me know if you think those IDs
> should be added as well. I would be glad if I got more educated opinion
> on adding the of-IDs :) (I can squash this to 3/7 and 6/7 in next
> revision, and add own patch for adding of-IDs for other ICs if
> required).
>
I don't know what those side effects might be. I am much more concerned
about side effects of having some of the devices in adm1275_of_match
and some in adm1275_id. So, yes, please add a patch to provide
adm1275_of_match for all chips supported by the driver.
Thanks,
Guenter
> ---
> drivers/hwmon/pmbus/adm1275.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
> index 9e21dd4083e9..c27bb0e49354 100644
> --- a/drivers/hwmon/pmbus/adm1275.c
> +++ b/drivers/hwmon/pmbus/adm1275.c
> @@ -927,9 +927,17 @@ static int adm1275_probe(struct i2c_client *client)
> return pmbus_do_probe(client, info);
> }
>
> +static const struct of_device_id adm1275_of_match[] = {
> + { .compatible = "rohm,bd12780", },
> + { .compatible = "rohm,bd12790", },
> + { }
> +};
> +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,
^ permalink raw reply
* Re: [PATCH RFC v4 1/9] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add glymur-qmp-gen5x8-pcie-phy compatible
From: Konrad Dybcio @ 2026-06-16 14:03 UTC (permalink / raw)
To: Qiang Yu, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260518-link_mode_0519-v4-1-269cd73cc5d1@oss.qualcomm.com>
On 5/19/26 7:47 AM, Qiang Yu wrote:
> The Glymur SoC uses a single PCIe Gen5 PHY hardware block for the
> PCIe3a/PCIe3b controllers. This block supports two link modes:
>
> 1. x4+x4: two 4-lane PHY instances are exposed
> 2. x8: one 8-lane PHY instance is exposed
>
> Add qcom,glymur-qmp-gen5x8-pcie-phy as a multi-mode PHY compatible and
> document the new link-mode property, which selects the active link mode
> via a TCSR syscon register.
>
> Document the required clocks, resets, and power-domains for both PHY
> instances active in x8 mode. Use #phy-cells = <1> for this compatible,
> where the cell value is the PHY index within the active link mode.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
[...]
> @@ -68,20 +69,29 @@ properties:
> - const: ref
> - enum: [rchng, refgen]
> - const: pipe
> - - const: pipediv2
> + - enum: [pipediv2, phy_b_aux]
I'm surprised to learn 3A doesnm'doesn't have a PIPE_DIV2 clk.. it does have
a non-div2 one though.
Seems like it's specifically not the case on Hamoa and Makena, so perhaps
it's better for maintainability if the Glymur list was separate
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: Add GPIO-locked fixed clock
From: Vyacheslav Yurkov @ 2026-06-16 14:02 UTC (permalink / raw)
To: Brian Masney, V.Yurkov.EXT
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-kernel, linux-clk, devicetree
In-Reply-To: <ajB2PhmxvdtsXNnm@redhat.com>
Hi Brian
On 16.06.2026 00:01, Brian Masney wrote:
> Hi Vyacheslav,
>
> On Wed, Jun 03, 2026 at 11:16:42AM +0000, Vyacheslav Yurkov via B4 Relay wrote:
>> From: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
>>
>> Some hardware designs provide fixed-frequency clocks generated outside
>> software control, such as by FPGA-resident PLLs. While the clock rate is
>> fixed, a separate GPIO signal indicates whether the clock source is
>> locked and producing a valid output.
>>
>> Describe a GPIO-locked fixed clock provider that exposes a fixed-rate
>> clock whose availability depends on one or more GPIO lock-status
>> signals.
>>
>> Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
>> Signed-off-by: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
>> ---
>> .../bindings/clock/gpio-locked-fixed-clock.yaml | 70 ++++++++++++++++++++++
>> 1 file changed, 70 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/gpio-locked-fixed-clock.yaml b/Documentation/devicetree/bindings/clock/gpio-locked-fixed-clock.yaml
>> new file mode 100644
>> index 000000000000..9106b800b673
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/gpio-locked-fixed-clock.yaml
>> @@ -0,0 +1,70 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/gpio-locked-fixed-clock.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: GPIO Locked Fixed Clock
>> +
>> +maintainers:
>> + - Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
>> +
>> +description: |
>> + Provides a clock output whose availability depends on a set of
>> + prerequisite conditions. These conditions include the presence of
>> + one or more parent clocks and the asserted state of one or more
>> + GPIO lock indicators. An example of such clocks is FPGA clock that
>> + are outside CPU control, with the lock status exposed through GPIO
>> + signal.
>> +
>> + The output clock is considered available only when all configured
>> + prerequisites are satisfied.
>
> I'm stepping outside my usual review of just the clk drivers. Krzysztof
> in v1 and v2 asked for more detailed hardware explanation. This feels to
> me like this is a policy that says to not use these clocks until the
> GPIO says they are ready. My gut feeling is that details like this
> should live in a clk driver instead of a dt-binding.
>
> Alternatively, if this is generic enough, then could
> Documentation/devicetree/bindings/clock/gated-fixed-clock.yaml be
> extended?
>
> Brian
Does it mean I should drop driver description from the DT schema?
So you are implying that gated-fixed-clock.yaml can be extended with
another compatibility string? When another compatibility string is used,
then some other bindings are expected by the driver, not what is used by
gated-fixed-clock driver. Is that a common pattern among dt-bindings to
share the bindings between different compatibility strings?
Slava
^ permalink raw reply
* Re: [PATCH v8 4/5] iio: adc: versal-sysmon: add threshold event support
From: sashiko-bot @ 2026-06-16 13:57 UTC (permalink / raw)
To: Salih Erim; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260616131559.3029543-5-salih.erim@amd.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [Critical] sysmon_write_event_value overwrites and destroys configuration bits in the supply voltage threshold registers.
- [High] sysmon_unmask_worker silently drops pending supply voltage alarms by clearing the entire SYSMON_ISR register.
- [High] Data races in sysmon_write_event_config can permanently disable or unintentionally re-enable temperature interrupts.
- [High] Requesting a hardirq without verifying if the regmap can sleep risks a kernel panic on I2C topologies.
- [High] Returning early in sysmon_handle_event on regmap failure bypasses clearing the hardware interrupt flag, causing an IRQ storm.
- [Medium] Supply voltage threshold alarms permanently self-disable after triggering, violating IIO threshold semantics.
--
commit 7bd7012fa9bf8b5241dc89218a9954a7531d4460
Author: Salih Erim <salih.erim@amd.com>
iio: adc: versal-sysmon: add threshold event support
Add threshold event support for temperature and supply voltage
channels.
[ ... ]
> diff --git a/drivers/iio/adc/versal-sysmon-core.c b/drivers/iio/adc/versal-sysmon-core.c
> index a1d4a13b72479..8d567f9fa05d7 100644
> --- a/drivers/iio/adc/versal-sysmon-core.c
> +++ b/drivers/iio/adc/versal-sysmon-core.c
[ ... ]
> @@ -69,6 +127,34 @@ static void sysmon_supply_rawtoprocessed(int raw_data, int *val)
> *val = (mantissa * (int)MILLI) >> exponent;
> }
>
> +static void sysmon_supply_processedtoraw(int val, u32 reg_val, u32 *raw_data)
> +{
> + int exponent = FIELD_GET(SYSMON_MODE_MASK, reg_val);
> + int format = FIELD_GET(SYSMON_FMT_MASK, reg_val);
> + int scale, tmp;
> +
> + scale = BIT(SYSMON_SUPPLY_MANTISSA_BITS - exponent);
> + tmp = (val * scale) / (int)MILLI;
> +
> + if (format)
> + tmp = clamp(tmp, S16_MIN, S16_MAX);
> + else
> + tmp = clamp(tmp, 0, U16_MAX);
> +
> + *raw_data = (u16)tmp;
[Severity: Critical]
Is it intended to cast tmp to (u16) here? By assigning this to a u32 pointer,
doesn't it clear the upper 16 bits of the target value?
Since SYSMON_FMT_MASK (bit 16) and SYSMON_MODE_MASK (bits 17-18) are stored
in the upper bits, will writing this back in sysmon_write_event_value() wipe
out the hardware configuration for the threshold?
> +}
[ ... ]
> +static int sysmon_write_event_config(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + enum iio_event_type type,
> + enum iio_event_direction dir,
> + bool state)
> +{
[ ... ]
> + case IIO_TEMP:
> + if (state) {
> + ret = regmap_write(sysmon->regmap, SYSMON_IER, ier);
> + if (ret)
> + return ret;
> +
> + scoped_guard(spinlock_irq, &sysmon->irq_lock)
> + sysmon->temp_mask &= ~ier;
[Severity: High]
Is there a race condition between updating the hardware register and the
software sysmon->temp_mask?
If the sysmon_unmask_worker() runs concurrently before temp_mask is updated,
could it see the event as disabled, write 0 to SYSMON_IER, and clear
masked_temp, permanently disabling the event?
> + } else {
> + ret = regmap_write(sysmon->regmap, SYSMON_IDR, ier);
> + if (ret)
> + return ret;
> +
> + scoped_guard(spinlock_irq, &sysmon->irq_lock)
> + sysmon->temp_mask |= ier;
[Severity: High]
Similarly, when disabling the event, if the delayed worker runs after
SYSMON_IDR is written but before temp_mask is updated, might it see the old
mask and erroneously write to SYSMON_IER, re-enabling the interrupt?
> + }
> + return 0;
[ ... ]
> +static int sysmon_handle_event(struct iio_dev *indio_dev, u32 event)
> +{
[ ... ]
> + case SYSMON_BIT_ALARM0:
> + case SYSMON_BIT_ALARM1:
> + case SYSMON_BIT_ALARM2:
> + case SYSMON_BIT_ALARM3:
> + case SYSMON_BIT_ALARM4:
> + ret = regmap_read(sysmon->regmap, alarm_flag_offset, ®_val);
> + if (ret)
> + return ret;
> +
> + alarm_flag_reg = reg_val;
> +
> + for_each_set_bit(bit, &alarm_flag_reg, SYSMON_ALARM_BITS_PER_REG) {
> + address = bit + SYSMON_ALARM_BITS_PER_REG * event;
> + sysmon_push_event(indio_dev, address);
> + ret = regmap_clear_bits(sysmon->regmap, alarm_reg_offset, BIT(bit));
[Severity: Medium]
Does this permanently disable the supply voltage alarm?
The code clears the alarm configuration bit here, but unlike the temperature
alarm, there doesn't seem to be a mechanism to re-arm the event once the
condition clears. Won't this break the expectation that IIO threshold events
remain enabled until explicitly disabled by userspace?
> + if (ret)
> + return ret;
[Severity: High]
If regmap_clear_bits() fails here, the early return bypasses the final
regmap_write() to alarm_flag_offset at the end of the function.
Does this mean the hardware interrupt condition is never acknowledged or
cleared? Could this leave the IRQ line asserted and cause an interrupt storm?
> + }
> +
> + return regmap_write(sysmon->regmap, alarm_flag_offset, alarm_flag_reg);
[ ... ]
> +static void sysmon_unmask_worker(struct work_struct *work)
> +{
> + struct sysmon *sysmon =
> + container_of(work, struct sysmon, sysmon_unmask_work.work);
> + unsigned int isr;
> +
> + /*
> + * If the ISR read fails, skip processing to avoid acting
> + * on undefined data.
> + */
> + scoped_guard(spinlock_irq, &sysmon->irq_lock) {
> + if (regmap_read(sysmon->regmap, SYSMON_ISR, &isr))
> + break;
> + regmap_write(sysmon->regmap, SYSMON_ISR, isr);
> + sysmon_unmask_temp(sysmon, isr);
> + }
[Severity: High]
Could this clear pending supply voltage alarms without handling them?
Since SYSMON_ISR is a write-1-to-clear register, if we read the full isr
and write it back unmodified, wouldn't it acknowledge and clear all pending
interrupts?
If a supply voltage alarm triggered concurrently, it seems its hardware flag
would be cleared but the software would ignore it, since the worker only
processes temperature alarms.
> +
> + if (sysmon->masked_temp)
> + schedule_delayed_work(&sysmon->sysmon_unmask_work,
> + msecs_to_jiffies(SYSMON_UNMASK_WORK_DELAY_MS));
> + else
> + regmap_write(sysmon->regmap, SYSMON_STATUS_RESET, 1);
> +}
[ ... ]
> +static int sysmon_init_interrupt(struct sysmon *sysmon,
> + struct device *dev,
> + struct iio_dev *indio_dev,
> + int irq)
> +{
[ ... ]
> + ret = devm_request_irq(dev, irq, sysmon_iio_irq, 0, "sysmon-irq", indio_dev);
[Severity: High]
Does this need to check if the underlying regmap can sleep before requesting
a hardirq?
If an I2C device node validly specifies an interrupt line, sysmon_iio_irq()
will call regmap_read() in an atomic context. Since I2C transfers require
taking a mutex, wouldn't this sleep in atomic context and trigger a panic?
Should we check regmap_might_sleep() before initializing interrupts?
> + if (ret)
> + return ret;
> +
> + return devm_add_action_or_reset(dev, sysmon_disable_interrupts, sysmon);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616131559.3029543-1-salih.erim@amd.com?part=4
^ permalink raw reply
* Re: [PATCH RESEND] dt-bindings: interrupt-controller: qcom,pdc: Add Maili compatible string
From: Rob Herring (Arm) @ 2026-06-16 13:53 UTC (permalink / raw)
To: Yijie Yang
Cc: linux-kernel, linux-arm-msm, Thomas Gleixner, Conor Dooley,
devicetree, Krzysztof Kozlowski, Bjorn Andersson
In-Reply-To: <20260615-maili-pdc-v1-1-add21e8eec3e@oss.qualcomm.com>
On Mon, 15 Jun 2026 16:28:37 +0800, Yijie Yang wrote:
> Register qcom,maili-pdc as a supported compatible string for the
> Qualcomm PDC interrupt controller binding.
>
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH RESEND] dt-bindings: remoteproc: qcom,sm8550-pas: Add Qualcomm Maili ADSP and CDSP
From: Rob Herring (Arm) @ 2026-06-16 13:52 UTC (permalink / raw)
To: Yijie Yang
Cc: Conor Dooley, linux-remoteproc, Bjorn Andersson,
Manivannan Sadhasivam, Krzysztof Kozlowski, linux-arm-msm,
linux-kernel, Mathieu Poirier, devicetree
In-Reply-To: <20260615-remoteproc-v1-1-67721b4b052a@oss.qualcomm.com>
On Mon, 15 Jun 2026 16:30:21 +0800, Yijie Yang wrote:
> Document compatible strings for the ADSP and CDSP Peripheral Authentication
> Services on the Qualcomm Maili SoC. Both are compatible with the Qualcomm
> SM8550 PAS and can fallback to SM8550 except for one additional interrupt
> ("shutdown-ack"). For CDSP, similar to Kaanapali, "global_sync_mem" is
> not managed by the kernel.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Rob Herring @ 2026-06-16 13:50 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Val Packett, Julien Massot,
Louis-Alexis Eyraud, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260615071836.362883-4-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 09:16:09AM +0200, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 234 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++
> 2 files changed, 258 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..197041df4ba1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,234 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 regulator
> +
> +maintainers:
> + - Luca Leonardo Scorcia <l.scorcia@gmail.com>
> +
> +description:
> + MT6392 is a power management system chip containing three buck converters and
> + 23 LDOs. All voltage regulators provided by the PMIC are described as
> + sub-nodes of this node.
> +
> +properties:
> + compatible:
> + items:
> + - const: mediatek,mt6392-regulator
> +
> + vproc-supply:
> + description: Supply for buck regulator vproc
> + vcore-supply:
> + description: Supply for buck regulator vcore
> + vsys-supply:
> + description: Supply for buck regulator vsys
> + avddldo-supply:
> + description: |
Don't need '|' if no formatting to preserve. Elsewhere too.
> + Supply for AVDD LDOs (vm, vio18, vcn18, vcamd, vcamio). According to the data sheet
> + this is an internal supply derived from vsys.
> + ldo1-supply:
> + description: Supply for LDOs group 1 (vaud28, vxo22, vaud22, vadc18, vcama, vrtc)
> + ldo2-supply:
> + description: Supply for LDOs group 2 (vcn35, vio28, vmc, vmch, vefuse, vdig18)
> + ldo3-supply:
> + description: Supply for LDOs group 3 (vusb, vemc3v3, vcamaf, vgp1, vgp2, vm25)
> +
> +patternProperties:
> + "^v(core|proc|sys)$":
> + description: Buck regulators
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + BUCK regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
minItems: 1
maxItems: 2
? Because if there are only 2 modes, can't have more entries than that,
right? Though wouldn't 2 entries be the same as no property present
because I would assume the default is all modes. I shouldn't have to
assume though.
> + unevaluatedProperties: false
Place this after $ref. Easier to read than after indented blocks.
> +
> + "^v(adc18|camio|cn18|io18|xo22|m25|aud28|io28|rtc|usb)$":
> + description: LDOs with fixed output and mode setting
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^v(cama|dig18)$":
> + description: LDOs with fixed output without mode setting
> + type: object
> + $ref: regulator.yaml#
> + unevaluatedProperties: false
> +
> + "^v(aud22|camaf|camd|cn35|efuse|emc3v3|gp1|gp2|m|mc|mch)$":
> + description: LDOs with adjustable output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes: false
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + regulators {
> + compatible = "mediatek,mt6392-regulator";
Drop the example. Put 1 complete example in the MFD schema rather than
incomplete examples.
Rob
^ 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