* [PATCH v4 4/4] ARM: dts: mediatek: mt6323: add AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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: <20260623-mt6323-adc-v4-0-299680ad3194@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 v4 3/4] mfd: mt6397-core: add mt6323 AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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: <20260623-mt6323-adc-v4-0-299680ad3194@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 v4 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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, Conor Dooley
In-Reply-To: <20260623-mt6323-adc-v4-0-299680ad3194@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.
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.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
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 v4 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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: <20260623-mt6323-adc-v4-0-299680ad3194@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..c450fb6f09cb
--- /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 v4 0/4] AUXADC driver for the MediaTek mt6323 PMIC
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 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, Conor Dooley,
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.
[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 v4:
- dt-bindings: Drop separate driver mention from the commit message (Conor)
- AUXADC driver: Break one more time 'regmap_read_poll_timeout' on logical boundaries (Andy)
- Link to v3: https://patch.msgid.link/20260616-mt6323-adc-v3-0-1c27c588185d@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 1/2] dt-bindings: pwm: add Axiado AX3000 PWM
From: Petar Stepanovic @ 2026-06-23 8:17 UTC (permalink / raw)
To: Krzysztof Kozlowski, Akhila Kavi, Prasad Bolisetty,
Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-pwm, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <c4f3875c-4f39-44bf-857f-10c50a2ca6f4@kernel.org>
On 6/22/2026 2:50 PM, Krzysztof Kozlowski wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 18/06/2026 14:26, Petar Stepanovic wrote:
>> +
>> +description:
>> + The Axiado PWM controller found on AX3000 and AX3005 SoCs.
>> +
>> +allOf:
>> + - $ref: pwm.yaml#
>> +
>> +properties:
>> + compatible:
>> + const: axiado,ax3000-pwm
> Description mentions AX3005, but there is no ax3005 compatible here.
> This is confusing.
Thank you for the review.
I will address all your comments in the next version.
Regards,
Petar
^ permalink raw reply
* Re: [PATCH 5/13] ASoC: qcom: Add QAIF shared data structures and variant interface
From: Harendra Gautam @ 2026-06-23 8:11 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Srinivas Kandagatla, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <CAC-tS8BvfQOLhwicBJ986UqTTZGmiYDbg5MVA54ScUsYLb-dog@mail.gmail.com>
On Tue, Jun 23, 2026 at 1:34 PM Harendra Gautam
<harendra.gautam@oss.qualcomm.com> wrote:
>
>
>
> On Wed, Jun 17, 2026 at 1:58 AM Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 6/5/26 11:37 AM, Harendra Gautam wrote:
>> >
>> > + struct reg_field cif_rddma_shram_wm;
>> > + struct reg_field cif_rddma_active_ch_en;
>> > + struct reg_field cif_rddma_fs_sel;
>> > + struct reg_field cif_rddma_fs_delay;
>> > + struct reg_field cif_rddma_fs_out_gate;
>> > + struct reg_field cif_rddma_intf_dyncclk;
>> > + struct reg_field cif_rddma_en_16bit_unpack;
>> > +
>> Why do we need to use reg_field?, currently this patchset only supports
>> one SoC. reg_field makes sense only when there is change in bit
>> positions across SoCs and if we want to leverage from existing driver.
>>
>> --srini
>>
> Thanks for your comment, change in bit position won't happen for a IP across SoCs. But these bit fields are added with intention to configure bits based on defined value from device tree or based on usecase. Please let me know your thoughts.
> -Harendra
<<resending as last mail was not delivered for a few lists as it was
not plain-text>>
Thanks for your comment, change in bit position won't happen for an IP
across SoCs. But these bit fields are added with the intention to
configure bits based on defined value from device tree or based on
usecase. Please let me know your thoughts.
--Harendra
^ permalink raw reply
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Andrew Lunn @ 2026-06-23 8:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Luo Jie,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lei Wei, Suruchi Agarwal, Pavithra R, linux-kernel,
linux-arm-msm, linux-clk, devicetree, netdev
In-Reply-To: <20260623073307.36483-2-krzysztof.kozlowski@oss.qualcomm.com>
> Driver is not supported - in terms of how netdev understands supported
> commitment - if maintainer does not care to receive the patches for its
> code, so demote it to "maintained" to reflect true status.
Maybe "Orphan" would be better, if the listed Maintainer is not doing
any Maintainer work?
Andrew
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Rodrigo Alencar @ 2026-06-23 8:09 UTC (permalink / raw)
To: Nuno Sá, Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <ajklksIDLsj0BZul@nsa>
On 22/06/26 13:20, Nuno Sá wrote:
> On Mon, Jun 22, 2026 at 12:51:20PM +0100, Rodrigo Alencar wrote:
> > On 22/06/26 11:29, Nuno Sá wrote:
> > > On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> > > > On 21/06/26 15:33, Jonathan Cameron wrote:
> > > > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > > >
> > > > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > > > >
> > > > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + required:
> > > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > +required:
> > > > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > > > + - |
> > > > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > ...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > spi {
> > > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > };
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > };
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > };
> > > > > > > > > > > > > > }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > };
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > };
> > > > > > > > > > > > > > }
> > > > > > > > > > > > > > };
> > > > > > > > > > > > > > };
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > > > >
> > > > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > > > >
> > > > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > > > >
> > > > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > > > see if I can find what I am thinking of...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > > > slightly different properties.
> > > > > > > > >
> > > > > > > > > microchip,device-addr:
> > > > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > > enum: [0, 1, 2, 3]
> > > > > > > > > default: 0
> > > > > > > > >
> > > > > > > > > and
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > microchip,hw-device-address:
> > > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > > minimum: 0
> > > > > > > > > maximum: 3
> > > > > > > > > description:
> > > > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > > > The device address is part of the device markings to avoid
> > > > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > > > which is first one on the wire).
> > > > > > > > >
> > > > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > > > here?
> > > > > > > > >
> > > > > > > >
> > > > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > > > about solving this at the spi level.
> > > > > > > >
> > > > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > > > together in the same bus.
> > > > > > >
> > > > > > > I'm definitely missing something, because that property for the
> > > > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > > > are completely different devices with different drivers. They have
> > > > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > > > spi bus.
> > > > > >
> > > > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > > > devices on the same CS right? Because for this chip we would need
> > > > > > something like:
> > > > > >
> > > > > > spi {
> > > > > > dac@0 {
> > > > > > reg = <0>;
> > > > > > adi,pin-id = <0>;
> > > > > > };
> > > > > >
> > > > > > dac@1 {
> > > > > > reg = <0>; // which seems already problematic?
> > > > > > adi,pin-id <1>;
> > > > > > };
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > //up to 4
> > > > > > };
> > > > > Yeah. It's not clear to me how that works for the microchip devices
> > > > > (I suspect it doesn't!)
> > > > >
> > > > > Just thinking as I type, but could we do something a bit nasty with
> > > > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > > > shared? Given this is all tied to the spi bus that should all happen
> > > > > under serializing locks.
> > > > >
> > > > > Agreed though that this would be nicer as an SPI thing that let
> > > > > us specify that a single CS is share by multiple devices and their
> > > > > is some other signal acting to select which one we are talking to.
> > > > >
> > > >
> > > > If the device-addressing on the same chip-select is to be handled
> > > > by the spi framework, wouldn't we lose device-specific features?
> > > >
> > > > I understand that this multi-device feature is there mostly to extend the
> > > > channel count from 16 to 32, 48 or 64. I suppose the command:
> > > >
> > > > "MULTI DEVICE SW LDAC MODE"
> > > >
> > > > exists so that software can update channel values accross multiple devices.
> > >
> > > Right! You do have a point! I agree the main driver for a feature like
> > > this is likely to extend the channel count and effectively "aggregate"
> > > devices.
> > >
> > > But I would say that even with the spi solution the MULTI DEVICE stuff
> > > should be doable (as we still need a sort of adi,pin-id property).
> >
> > I don't think we can have something like an IIO buffer shared by multiple
> > devices. Synchronizing separate devices would be doable with proper hardware
> > support for this (probably involving an FGPA).
>
> True!
>
> >
> > > But yes, I do feel that the whole feature is for aggregation so seeing
> > > one device with 32 channels is the expectation here? Rather than seeing
> > > two devices with 16 channels.
> >
> > Yes, I think aggregation is the whole point there... so that the IIO driver
> > is multi-device-aware.
>
> Which makes me feel that different pins per device might be possible
> from an HW point of view but does not make much sense. For example, for
> the buffer example I would expect LDAC to be shared between all the
> devices.
That is why I would still suggest the multi-dac node in the middle...
the parent node can hold shared resources, while the dac children can
have their own, overriding or inheriting stuff.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: watchdog: npcm: add GCR syscon property
From: Krzysztof Kozlowski @ 2026-06-23 8:05 UTC (permalink / raw)
To: Tomer Maimon
Cc: andrew, wim, linux, robh, krzk+dt, conor+dt, openbmc,
linux-watchdog, linux-doc, devicetree, linux-kernel, avifishman70,
tali.perry1, venture, yuenn, benjaminfair, corbet, skhan, joel
In-Reply-To: <20260622083046.3189603-2-tmaimon77@gmail.com>
On Mon, Jun 22, 2026 at 11:30:44AM +0300, Tomer Maimon wrote:
> Describe syscon property that handles general control registers (GCR) in
> Nuvoton BMC NPCM watchdog driver.
Why? Well, you try to answer by saying something about driver, but we do
not add bindings for drivers. Instead hardware should be the reason.
Anyway, why is this needed now?
>
> Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
> ---
> .../devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
> index 7aa30f5b5c49..4f00f099b2d2 100644
> --- a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
> @@ -40,6 +40,12 @@ properties:
> clock-frequency:
> description: Frequency in Hz of the clock that drives the NPCM timer.
>
> + nuvoton,sysgcr:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + a phandle to access GCR registers on NPCM750 and NPCM845 watchdog
> + instances.
Here you write also for what purpose.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: interconnect: qcom: document the RPMh Network-On-Chip interconnect in Maili SoC
From: Krzysztof Kozlowski @ 2026-06-23 7:55 UTC (permalink / raw)
To: Raviteja Laggyshetty
Cc: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jingyi Wang, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Odelu Kukatla
In-Reply-To: <20260622-maili_icc-v2-1-18b5ac08c04f@oss.qualcomm.com>
On Mon, Jun 22, 2026 at 06:34:45AM +0000, Raviteja Laggyshetty wrote:
> Document the RPMh Network-On-Chip interconnect for the Qualcomm Maili
> SoC.
>
> Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
> ---
> .../bindings/interconnect/qcom,maili-rpmh.yaml | 127 +++++++++++++++
> include/dt-bindings/interconnect/qcom,maili-rpmh.h | 171 +++++++++++++++++++++
> 2 files changed, 298 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver
From: Maxime Ripard @ 2026-06-23 7:55 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, tzimmermann, airlied, simona, robh,
krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam, chintanlike,
dri-devel, devicetree, linux-kernel, linux-fbdev, linux-staging
In-Reply-To: <20260622152506.78627-5-amit.barzilai22@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
Hi,
On Mon, Jun 22, 2026 at 06:25:06PM +0300, Amit Barzilai wrote:
> The SSD1351 support was added to the ssd130x DRM driver. To avoid
> confusion and irrelevant updates, the staging fb_ssd1351 driver is
> removed.
>
> Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
fbtft uses a different dt binding iirc, and has a different uABI, so we
should probably keep it around.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: qcom: install DT overlays via dtbs_install
From: Krzysztof Kozlowski @ 2026-06-23 7:46 UTC (permalink / raw)
To: Vishwas Udupa, andersson
Cc: vudupa, conor+dt, devicetree, kbajaj, konradybcio, krzk+dt,
linux-arm-msm, robh, snb, lminier
In-Reply-To: <20260622055226.4085891-1-vishwas.udupa@oss.qualcomm.com>
On 22/06/2026 07:52, Vishwas Udupa wrote:
> Overlay binaries (.dtbo) are currently only built implicitly as
> dependencies of composite firmware images and are therefore absent from the
> kernel install output.
>
> Even when final DTBs are produced at build time, some distributions rely on
> standalone DTBOs for runtime selection and application by bootloaders or
> firmware. Without explicit install targets, DTBOs are not picked up by the
> standard dtbs_install flow and therefore cannot be packaged alongside DTBs.
>
> Add explicit dtb-$(CONFIG_ARCH_QCOM) entries for DT overlays defined in
> this Makefile so they are installed via dtbs_install, matching existing DTB
> install behaviour, while excluding EL2 DTBOs as they are not intended for
> independent use and are only meaningful in conjunction with their base DTBs.
>
> Signed-off-by: Vishwas Udupa <vishwas.udupa@oss.qualcomm.com>
> ---
> Changes in v3:
> - Address review feedback from sashiko on commit message
> - Link to v2: https://lore.kernel.org/all/20260619180951.325272-1-vishwas.udupa@oss.qualcomm.com/
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Krzysztof Kozlowski @ 2026-06-23 7:33 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Luo Jie,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lei Wei, Suruchi Agarwal, Pavithra R, linux-kernel,
linux-arm-msm, linux-clk, devicetree, netdev
Cc: Krzysztof Kozlowski
Emails to the maintainer of Qualcomm PPE Ethernet driver (Luo Jie
<quic_luoj@quicinc.com>) bounce permanently (full mailbox), because the
"quicinc.com" addresses were deprecated for public work. All Qualcomm
contributors are aware of that and were asked to fix their addresses.
Driver is not supported - in terms of how netdev understands supported
commitment - if maintainer does not care to receive the patches for its
code, so demote it to "maintained" to reflect true status.
Fix all occurences of Luo Jie email address to preferred and working
domain.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.mailmap | 3 ++-
.../devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml | 2 +-
Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml | 2 +-
MAINTAINERS | 4 ++--
5 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/.mailmap b/.mailmap
index 1f23ea6e8ce1..23eb9a4b04f4 100644
--- a/.mailmap
+++ b/.mailmap
@@ -530,7 +530,8 @@ Luca Ceresoli <luca.ceresoli@bootlin.com> <luca@lucaceresoli.net>
Luca Weiss <luca@lucaweiss.eu> <luca@z3ntu.xyz>
Lucas De Marchi <demarchi@kernel.org> <lucas.demarchi@intel.com>
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
-Luo Jie <quic_luoj@quicinc.com> <luoj@codeaurora.org>
+Luo Jie <jie.luo@oss.qualcomm.com> <luoj@codeaurora.org>
+Luo Jie <jie.luo@oss.qualcomm.com> <quic_luoj@quicinc.com>
Lance Yang <lance.yang@linux.dev> <ioworker0@gmail.com>
Lance Yang <lance.yang@linux.dev> <mingzhe.yang@ly.com>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml
index b9c3650e5c4c..a4f9af8fa187 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml
@@ -8,7 +8,7 @@ title: Qualcomm CMN PLL Clock Controller on IPQ SoC
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- - Luo Jie <quic_luoj@quicinc.com>
+ - Luo Jie <jie.luo@oss.qualcomm.com>
description:
The CMN (or common) PLL clock controller expects a reference
diff --git a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
index 3da10c364a85..8d7a58609372 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
@@ -8,7 +8,7 @@ title: Qualcomm NSS Clock & Reset Controller on QCA8386/QCA8084
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- - Luo Jie <quic_luoj@quicinc.com>
+ - Luo Jie <jie.luo@oss.qualcomm.com>
description: |
Qualcomm NSS clock control module provides the clocks and resets
diff --git a/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml b/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
index 753f370b7605..6d0b21a10732 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm IPQ packet process engine (PPE)
maintainers:
- - Luo Jie <quic_luoj@quicinc.com>
+ - Luo Jie <jie.luo@oss.qualcomm.com>
- Lei Wei <quic_leiwei@quicinc.com>
- Suruchi Agarwal <quic_suruchia@quicinc.com>
- Pavithra R <quic_pavir@quicinc.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 895a87b571c3..e173828acfe1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22324,9 +22324,9 @@ F: Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml
F: drivers/power/supply/qcom_smbx.c
QUALCOMM PPE DRIVER
-M: Luo Jie <quic_luoj@quicinc.com>
+M: Luo Jie <jie.luo@oss.qualcomm.com>
L: netdev@vger.kernel.org
-S: Supported
+S: Maintained
F: Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
F: Documentation/networking/device_drivers/ethernet/qualcomm/ppe/ppe.rst
F: drivers/net/ethernet/qualcomm/ppe/
--
2.53.0
^ permalink raw reply related
* [PATCH v2] dt-bindings: clock: Replace bouncing emails
From: Krzysztof Kozlowski @ 2026-06-23 7:30 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sylwester Nawrocki, Chanwoo Choi, Peter Griffin, Alim Akhtar,
Barnabas Czeman, Tomasz Figa, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-samsung-soc, linux-arm-kernel
Cc: Krzysztof Kozlowski
Replace permanently bouncing email addresses (550 5.1.1 Recipient address
rejected) of Adam Skladowski, Chanho Park, Anusha Rao and Sireesh
Kodali. There are no new messages from them via other email addresses,
so drop them permanently. Add Alim Akhtar to Samsung ExynosAutov9 SoC
clocks, because he looks at other Samsung clock hardware and drivers.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Stephen, can you take this directly?
Changes in v2:
1. Also Anusha Rao.
---
Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml | 2 --
Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml | 1 -
Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml | 1 -
.../devicetree/bindings/clock/samsung,exynosautov9-clock.yaml | 2 +-
4 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
index fc0360554f68..9f2b970bfb48 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
@@ -7,8 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller on MSM8937, MSM8940, MSM8953 and SDM439
maintainers:
- - Adam Skladowski <a_skl39@protonmail.com>
- - Sireesh Kodali <sireeshkodali@protonmail.com>
- Barnabas Czeman <barnabas.czeman@mainlining.org>
description: |
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
index 5b128fa841aa..1337bd87fddd 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
@@ -8,7 +8,6 @@ title: Qualcomm Global Clock & Reset Controller on IPQ9574
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- - Anusha Rao <quic_anusha@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml
index 7ff4ff3587ca..a35bbc7b1924 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml
@@ -8,7 +8,6 @@ title: Qualcomm Networking Sub System Clock & Reset Controller on IPQ9574 and IP
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- - Anusha Rao <quic_anusha@quicinc.com>
description: |
Qualcomm networking sub system clock control module provides the clocks,
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
index e9d17d48b4f3..3dcdfa7a8792 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos Auto v9 SoC clock controller
maintainers:
- - Chanho Park <chanho61.park@samsung.com>
+ - Alim Akhtar <alim.akhtar@samsung.com>
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzk@kernel.org>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v8 3/3] pwm: dwc: add of/platform support
From: sashiko-bot @ 2026-06-23 7:28 UTC (permalink / raw)
To: dongxuyang; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260623071516.2251-1-dongxuyang@eswincomputing.com>
Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider:
New issues:
- [High] Incorrect PWM polarity mapping and violation of the atomic PWM API by using pwm->args instead of state for 0N100PWM-capable hardware.
- [High] System suspend unconditionally fails if any PWM channel is enabled, breaking system-wide sleep transitions.
- [High] PM runtime usage counter leak in dwc_pwm_resume when system resume fails.
- [High] The function dwc_pwm_get_state() divides by the clock rate without verifying if it is zero, leading to a kernel panic.
- [High] The driver ignores the return value of pm_runtime_get_sync() in dwc_pwm_plat_remove(), leading to potential bus faults.
- [Medium] The error handling path in dwc_pwm_plat_probe() double-disables the device clocks if no PWM channels are initially enabled.
Pre-existing issues:
- [High] Unchecked pm_runtime_get_sync failure and leaked reference in dwc_pwm_apply.
--
commit 061974fbba26ee19760c596a4145184402b90275
Author: Xuyang Dong <dongxuyang@eswincomputing.com>
pwm: dwc: add of/platform support
The dwc pwm controller can be used in non-PCI systems, so allow
either platform or OF based probing.
The controller is reset only when no PWM channel is enabled.
Otherwise, clocks are enabled and the runtime PM state is updated
to reflect the active hardware configuration.
> diff --git a/drivers/pwm/pwm-dwc-core.c b/drivers/pwm/pwm-dwc-core.c
> index 6dabec93a3c64..b9a9d6ae0b45b 100644
> --- a/drivers/pwm/pwm-dwc-core.c
> +++ b/drivers/pwm/pwm-dwc-core.c
> @@ -44,21 +46,55 @@ static int __dwc_pwm_configure_timer(struct dwc_pwm *dwc,
[ ... ]
> + if (dwc->features & DWC_TIM_CTRL_0N100PWM_EN) {
> + /*
> + * Calculate width of low and high period in terms of input
> + * clock periods and check are the result within HW limits
> + * between 0 and 2^32 periods.
> + * Use mul_u64_u64_div_u64() to avoid overflowing the 64-bit
> + * intermediate result and to round down to the nearest
> + * achievable hardware value, as required by the PWM core.
> + */
> + tmp = mul_u64_u64_div_u64(state->duty_cycle, dwc->clk_rate,
> + NSEC_PER_SEC);
> + if (tmp >= (1ULL << 32))
> + return -ERANGE;
> +
> + if (pwm->args.polarity == PWM_POLARITY_INVERSED)
> + high = tmp;
> + else
> + low = tmp;
[Severity: High]
Is it correct to evaluate the static default pwm->args.polarity here
instead of state->polarity?
If the args polarity is INVERSED, this logic maps the duty_cycle to the
HIGH period. This causes the signal to be active-high, directly violating
the requested INVERSED state from the PWM core.
[ ... ]
> @@ -121,10 +161,19 @@ static int dwc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> struct pwm_state *state)
> {
> struct dwc_pwm *dwc = to_dwc_pwm(chip);
> + unsigned long clk_rate;
> u64 duty, period;
> u32 ctrl, ld, ld2;
> + int ret;
> +
> + ret = pm_runtime_resume_and_get(pwmchip_parent(chip));
> + if (ret)
> + return ret;
[Severity: High]
This is a pre-existing issue, but while looking at the runtime PM handling
here, I noticed that dwc_pwm_apply() (not modified by this patch) calls
pm_runtime_get_sync(pwmchip_parent(chip)) without checking its return value.
If resuming the parent device fails, dwc_pwm_apply() proceeds to call
__dwc_pwm_configure_timer(), which attempts to access hardware registers
while clocks might be disabled, potentially leading to a synchronous external
abort. It also permanently leaks the PM usage reference on failure. Should
dwc_pwm_apply() also be updated to check for failure?
> - pm_runtime_get_sync(pwmchip_parent(chip));
> + if (dwc->clk)
> + dwc->clk_rate = clk_get_rate(dwc->clk);
> +
> + clk_rate = dwc->clk_rate;
[ ... ]
> if (ctrl & DWC_TIM_CTRL_PWM) {
> - duty = (ld + 1) * dwc->clk_ns;
> - period = (ld2 + 1) * dwc->clk_ns;
> - period += duty;
> + if (dwc->features & DWC_TIM_CTRL_0N100PWM_EN) {
> + if (pwm->args.polarity == PWM_POLARITY_INVERSED)
> + duty = ld2;
[Severity: High]
Similar to the issue above in __dwc_pwm_configure_timer(), should this
check state->polarity instead of pwm->args.polarity to correctly report
the active duty cycle?
> + else
> + duty = ld;
> + period = (u64)ld + ld2;
> + } else {
> + duty = ld + 1;
> + period = ld2 + 1;
> + period += duty;
> + }
> } else {
> - duty = (ld + 1) * dwc->clk_ns;
> + duty = ld + 1;
> period = duty * 2;
> }
>
> state->polarity = PWM_POLARITY_INVERSED;
> - state->period = period;
> - state->duty_cycle = duty;
> + state->period = mul_u64_u64_div_u64(period, NSEC_PER_SEC, clk_rate);
> + state->duty_cycle = mul_u64_u64_div_u64(duty, NSEC_PER_SEC, clk_rate);
[Severity: High]
Could clk_rate be zero here if the device tree provides an uninitialized or
dummy clock?
dwc->clk_rate is initialized using clk_get_rate() during probe without
verifying if it is non-zero. If it is 0, these divisions will cause a kernel
panic when the PWM core calls get_state() during pwmchip_add().
> diff --git a/drivers/pwm/pwm-dwc-of.c b/drivers/pwm/pwm-dwc-of.c
> new file mode 100644
> index 0000000000000..34713cb7299e6
> --- /dev/null
> +++ b/drivers/pwm/pwm-dwc-of.c
[ ... ]
> + /*
> + * If any PWM channel is enabled, mark device active and hold runtime PM
> + * references for each enabled channel. Otherwise, gate the clocks.
> + */
> + if (pwm_en) {
> + pm_runtime_set_active(dev);
> + for (i = 0; i < chip->npwm; i++) {
> + if (ctrl[i])
> + pm_runtime_get_noresume(dev);
> + }
> + } else {
> + clk_disable_unprepare(dwc->clk);
> + clk_disable_unprepare(dwc->bus_clk);
> + }
> +
> + pm_runtime_enable(dev);
> +
> + ret = pwmchip_add(chip);
> + if (ret) {
> + dev_err(dev, "failed to add pwm chip\n");
> + goto pm_disable;
> + }
> +
> + return 0;
> +
> +pm_disable:
> + pm_runtime_disable(dev);
> + if (pwm_en) {
> + for (i = 0; i < chip->npwm; i++) {
> + if (ctrl[i])
> + pm_runtime_put_noidle(dev);
> + }
> + }
> +disable_clk:
> + clk_disable_unprepare(dwc->clk);
> +disable_busclk:
> + clk_disable_unprepare(dwc->bus_clk);
[Severity: Medium]
If pwmchip_add() fails when pwm_en is false, will this error path
double-disable the clocks?
During probe, if no PWM channels are enabled, dwc->clk and dwc->bus_clk
are explicitly disabled in the else branch above. If pwmchip_add() then
fails, the execution jumps to pm_disable and falls through to disable_clk
and disable_busclk, executing clk_disable_unprepare() on both clocks a
second time. This causes a clock reference count underflow.
[ ... ]
> +static void dwc_pwm_plat_remove(struct platform_device *pdev)
> +{
> + struct dwc_pwm_drvdata *data = platform_get_drvdata(pdev);
> + struct pwm_chip *chip = data->chips[0];
> + struct dwc_pwm *dwc = to_dwc_pwm(chip);
> + unsigned int idx;
> + int ret;
> +
> + pm_runtime_get_sync(&pdev->dev);
[Severity: High]
Does pm_runtime_get_sync() need its return value checked here?
If the PM framework fails to resume the device during removal (e.g., due to a
power domain failure), the device's clocks or power will remain off.
> + pwmchip_remove(chip);
> +
> + for (idx = 0; idx < chip->npwm; idx++) {
> + if (dwc_pwm_readl(dwc, DWC_TIM_CTRL(idx)) & DWC_TIM_CTRL_EN)
[Severity: High]
This isn't a bug introduced in this exact line, but as a continuation of the
previous concern: if pm_runtime_get_sync() failed, this dwc_pwm_readl()
will access unclocked memory-mapped I/O, which triggers a bus fault.
[ ... ]
> +static int dwc_pwm_suspend(struct device *dev)
> +{
> + struct dwc_pwm_drvdata *data = dev_get_drvdata(dev);
> + struct pwm_chip *chip = data->chips[0];
> + struct dwc_pwm *dwc = to_dwc_pwm(chip);
> + unsigned int idx;
> + int ret;
> +
> + if (pm_runtime_status_suspended(dev)) {
> + ret = dwc_pwm_runtime_resume(dev);
> + if (ret)
> + return ret;
> + }
> +
> + for (idx = 0; idx < chip->npwm; idx++) {
> + if (chip->pwms[idx].state.enabled)
> + return -EBUSY;
[Severity: High]
Does returning -EBUSY when a PWM channel is enabled unintentionally break
system-wide sleep transitions?
If a userspace sysfs client or a consumer device leaves a PWM running, this
aborts the entire system suspend sequence.
[ ... ]
> +static int dwc_pwm_resume(struct device *dev)
> +{
> + struct dwc_pwm_drvdata *data = dev_get_drvdata(dev);
> + struct pwm_chip *chip = data->chips[0];
> + struct dwc_pwm *dwc = to_dwc_pwm(chip);
> + unsigned int idx;
> + bool pm_flags;
> + int ret;
> +
> + /* Check if device was runtime suspended before system resume */
> + pm_flags = pm_runtime_status_suspended(dev);
> + if (pm_flags) {
> + /*
> + * Use PM framework to resume device
> + * (calls dwc_pwm_runtime_resume)
> + */
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0)
> + return ret;
[Severity: High]
Can this leak the PM usage counter on failure?
pm_runtime_get_sync() increments the PM usage counter even if it returns an
error. If this call fails, propagating the error early leaves the device's
usage counter incremented, preventing it from ever entering runtime suspend
again. Should pm_runtime_put_noidle() be called before returning?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623071329.2034-1-dongxuyang@eswincomputing.com?part=3
^ permalink raw reply
* Re: Re: [PATCH v7 2/2] hwmon: Add Eswin EIC7700 PVT sensor driver
From: Huan He @ 2026-06-23 7:24 UTC (permalink / raw)
To: Guenter Roeck; +Cc: sashiko-reviews, robh, devicetree, linux-hwmon, conor+dt
In-Reply-To: <2d1ae3b5-bc52-4043-9090-a78f30390024@roeck-us.net>
Hi Sashiko, Guenter,
Thank you very much for your detailed review. We appreciate the feedback.
>
> On 6/11/26 02:17, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > - [High] The IRQ is requested before the PM runtime cleanup action is registered, leading to a possible use-after-disable of the hardware clock in the ISR on driver removal.
> > - [Medium] The interrupt handler `eic7700_pvt_hard_isr` does not check the hardware interrupt status bit to verify if the device actually generated the interrupt.
> > --
> >
> > commit 0f4c8aefb83780ee09652639eb2843f01c2baf38
> > Author: Huan He <hehuan1@eswincomputing.com>
> >
> > hwmon: Add Eswin EIC7700 PVT sensor driver
> >
> > Add support for ESWIN EIC7700 Voltage and Temperature sensor. The driver
> > supports temperature and voltage monitoring with polynomial conversion,
> > and provides sysfs interface for sensor data access.
> >
> >> diff --git a/drivers/hwmon/eic7700-pvt.c b/drivers/hwmon/eic7700-pvt.c
> >> new file mode 100644
> >> index 0000000000000..3b3aed74c3941
> >> --- /dev/null
> >> +++ b/drivers/hwmon/eic7700-pvt.c
> >
> > [ ... ]
> >
> >> +static irqreturn_t eic7700_pvt_hard_isr(int irq, void *data)
> >> +{
> >> + struct pvt_hwmon *pvt = data;
> >> + int active;
> >> + u32 val;
> >> +
> >> + if (IS_ENABLED(CONFIG_PM)) {
> >> + active = pm_runtime_get_if_active(pvt->dev);
> >> + if (active <= 0)
> >> + return IRQ_NONE;
> >> + }
> >> +
> >> + eic7700_pvt_update(pvt->regs + PVT_INT, PVT_INT_CLR, PVT_INT_CLR);
> >> + /*
> >> + * Read the data, update the cache and notify a waiter of this event.
> >> + */
> >> + val = readl(pvt->regs + PVT_DATA);
> >> + WRITE_ONCE(pvt->data_cache, FIELD_GET(PVT_DATA_OUT, val));
> >> + complete(&pvt->conversion);
> >
> > [Severity: Medium]
> > Does this unconditionally process the interrupt without checking if the device
> > actually generated it?
> >
> > If a spurious interrupt occurs, the ISR will prematurely clear the interrupt,
> > read whatever stale value is in PVT_DATA, and call complete(&pvt->conversion).
> > This will cause the waiting thread in eic7700_pvt_read_data() to wake up early
> > and return stale or garbage data to userspace.
> >
> > Should the ISR read the status register and return IRQ_NONE if its device did
> > not assert the interrupt?
I will modify the ISR to read PVT_INT first and return IRQ_NONE when
PVT_INT_STAT is not set.
> >
> > [ ... ]
> >
> >> + ret = eic7700_pvt_request_irq(pvt);
> >> + if (ret) {
> >> + if (!IS_ENABLED(CONFIG_PM))
> >> + clk_disable_unprepare(pvt->clk);
> >> + return ret;
> >> + }
> >> +
> >> + pm_runtime_enable(&pdev->dev);
> >> + pm_runtime_set_autosuspend_delay(&pdev->dev, 3000);
> >> + pm_runtime_use_autosuspend(&pdev->dev);
> >> + pm_runtime_get_noresume(&pdev->dev);
> >> +
> >> + ret = devm_add_action_or_reset(pvt->dev, eic7700_pvt_disable_pm_runtime,
> >> + pvt);
> >
> > [Severity: High]
> > Can this devres setup lead to accessing unclocked registers during device
> > removal?
> >
> > Because devres executes teardown callbacks in reverse order of their
> > registration, eic7700_pvt_disable_pm_runtime() will run before the IRQ
> > is freed by devm_request_threaded_irq()'s teardown.
> >
> > During removal, eic7700_pvt_disable_pm_runtime() disables the clock:
> >
> > eic7700_pvt_disable_pm_runtime() {
> > ...
> > if (!pm_runtime_status_suspended(pvt->dev)) {
> > clk_disable_unprepare(pvt->clk);
> > pm_runtime_set_suspended(pvt->dev);
> > }
> > }
> >
> > If an interrupt fires concurrently and the ISR executes past the
> > pm_runtime_get_if_active() check before the clock is disabled, the ISR
> > will attempt to access hardware registers while unclocked, which can lead
> > to an external abort or kernel panic:
> >
> > eic7700_pvt_hard_isr() {
> > ...
> > eic7700_pvt_update(pvt->regs + PVT_INT, ...);
> > }
> >
> > Should the PM runtime cleanup action be registered before the IRQ is requested?
> >
I will modify the probe sequence to register the PM runtime cleanup action
before requesting the IRQ.
Best regards,
Huan He
>
> If not solved, these questions will at least have to be answered.
>
> Thanks,
> Guenter
>
> >> + if (ret) {
> >> + pm_runtime_put_noidle(&pdev->dev);
> >> + return dev_err_probe(&pdev->dev, ret,
> >> + "Can't register PM cleanup\n");
> >> + }
> >
^ permalink raw reply
* Re: [PATCH v6 3/4] reset: cix: add sky1 audss auxiliary reset driver
From: sashiko-bot @ 2026-06-23 7:20 UTC (permalink / raw)
To: joakim.zhang; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260623070805.211019-4-joakim.zhang@cixtech.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] `sky1_audss_reset_status()` incorrectly reports the reset state due to an inverted active-low logic check, violating the reset controller API.
--
commit 432f7b3656f374ab11511fbdd94e2169a520d3bc
Author: Joakim Zhang <joakim.zhang@cixtech.com>
reset: cix: add sky1 audss auxiliary reset driver
This patch adds an auxiliary reset controller driver for the Cix Sky1 AUDSS
CRU. It registers 16 software reset lines for audio peripherals that are
controlled through a single register.
> diff --git a/drivers/reset/reset-sky1-audss.c b/drivers/reset/reset-sky1-audss.c
> new file mode 100644
> index 0000000000000..20870f37d7d73
> --- /dev/null
> +++ b/drivers/reset/reset-sky1-audss.c
[ ... ]
> +static int sky1_audss_reset_set(struct reset_controller_dev *rcdev,
> + unsigned long id, bool assert)
> +{
> + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> + const struct sky1_audss_reset_map *signal = &priv->map[id];
> + unsigned int value = assert ? 0 : signal->mask;
> +
> + return regmap_update_bits(priv->regmap, signal->offset, signal->mask, value);
> +}
[ ... ]
> +static int sky1_audss_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> + const struct sky1_audss_reset_map *signal = &priv->map[id];
> + unsigned int value;
> +
> + regmap_read(priv->regmap, signal->offset, &value);
> + return !!(value & signal->mask);
[Severity: High]
Since sky1_audss_reset_set() establishes that the hardware uses active-low
logic by writing 0 when assert is true, does this status function return an
inverted result?
The reset controller API requires returning a positive value when the line
is asserted and zero when deasserted. Should the return statement be inverted
to !(value & signal->mask) to correctly report the asserted state?
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623070805.211019-1-joakim.zhang@cixtech.com?part=3
^ permalink raw reply
* Re: [PATCH v6 2/4] clk: cix: add sky1 audss clock controller
From: sashiko-bot @ 2026-06-23 7:19 UTC (permalink / raw)
To: joakim.zhang; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260623070805.211019-3-joakim.zhang@cixtech.com>
Thank you for your contribution! Sashiko AI review found 8 potential issue(s) to consider:
- [High] Manual unregistration of composite clocks creates a Use-After-Free vulnerability due to premature freeing of clk_hw pointers.
- [High] Clock operations access hardware registers without runtime resuming the provider device, causing bus faults.
- [High] Forceful suspend in remove() breaks PM guarantees for devres-managed child reset controller device.
- [Medium] Probe and resume error paths leak the PM runtime usage counter and leave the hardware reset deasserted.
- [Medium] Hardware register state is saved to a shared global static array during suspend, causing cross-device memory corruption.
- [Medium] Return value of reset_control_deassert() is ignored during probe.
- [Medium] Clock operations read hardware registers using regmap_read() without checking the return value, risking the use of uninitialized stack variables.
- [Low] Unconditional assignment of the dev_pm_ops structure bypasses dead code elimination when CONFIG_PM is disabled.
--
commit 2a293298bf161f9032ad5d5ba5c782ee20a8e27c
Author: Joakim Zhang <joakim.zhang@cixtech.com>
clk: cix: add sky1 audss clock controller
This commit adds a platform driver for the Cix Sky1 AUDSS CRU. It provides
mux, divider, and gate clocks for the DSP, SRAM, and other audio subsystem
blocks. It also handles the AUDSS NOC reset and initializes an auxiliary
reset device.
> diff --git a/drivers/clk/cix/clk-sky1-audss.c b/drivers/clk/cix/clk-sky1-audss.c
> index 0000000000000..25341be4f5bf6
> --- /dev/null
> +++ b/drivers/clk/cix/clk-sky1-audss.c
> @@ -0,0 +1,1201 @@
[ ... ]
> +static u32 sky1_reg_save[][2] = {
> + { INFO_HIFI0, 0 },
> + { INFO_CLK_GATE, 0 },
> + { INFO_CLK_DIV, 0 },
> + { INFO_CLK_MUX, 0 },
> + { INFO_MCLK, 0 },
> +};
[Severity: Medium]
Since sky1_reg_save is declared as a global static array, won't multiple
instances of this device overwrite each other's saved register states during
sky1_audss_clk_runtime_suspend()?
[ ... ]
> +static void sky1_audss_clk_gate_endisable(struct clk_hw *hw, int enable)
> +{
> + struct clk_gate *gate = to_clk_gate(hw);
> + struct sky1_clk_gate *sky1_gate = to_sky1_clk_gate(gate);
> + int set = gate->flags & CLK_GATE_SET_TO_DISABLE ? 1 : 0;
> + unsigned long flags = 0;
> + u32 reg;
> +
> + set ^= enable;
> +
> + if (gate->lock)
> + spin_lock_irqsave(gate->lock, flags);
> + else
> + __acquire(gate->lock);
> +
> + if (gate->flags & CLK_GATE_HIWORD_MASK) {
> + reg = BIT(gate->bit_idx + 16);
> + if (set)
> + reg |= BIT(gate->bit_idx);
> + } else {
> + regmap_read(sky1_gate->regmap, sky1_gate->offset, ®);
[Severity: High]
Does this code access hardware registers while the device might be runtime
suspended?
At the end of sky1_audss_clk_probe(), pm_runtime_put_sync() is called, which
powers off the hardware. If a clock operation like
sky1_audss_clk_gate_endisable() is later invoked (for example, by reading
/sys/kernel/debug/clk/clk_summary), couldn't this cause a bus fault?
[ ... ]
> +static unsigned long sky1_audss_clk_divider_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct clk_divider *divider = to_clk_divider(hw);
> + struct sky1_clk_divider *sky1_div = to_sky1_clk_divider(divider);
> + unsigned int val;
> +
> + regmap_read(sky1_div->regmap, sky1_div->offset, &val);
> + val = val >> divider->shift;
[Severity: Medium]
Can this lead to the use of an uninitialized variable?
If regmap_read() fails, val remains uninitialized, but it is immediately
shifted and used. Should the return value of regmap_read() be checked here
and in sky1_audss_clk_mux_get_parent()?
[ ... ]
> +static int sky1_audss_clk_probe(struct platform_device *pdev)
> +{
[ ... ]
> + priv->rst_noc = devm_reset_control_get_exclusive(dev, NULL);
> + if (IS_ERR(priv->rst_noc))
> + return dev_err_probe(dev, PTR_ERR(priv->rst_noc),
> + "failed to get audss noc reset");
> +
> + reset_control_deassert(priv->rst_noc);
[Severity: Medium]
Is it safe to ignore the return value of reset_control_deassert() here? If
the reset fails to deassert, might subsequent MMIO accesses hang the system?
[ ... ]
> + for (i = 0; i < devtype_data->clk_cfg_size; i++) {
> + clk_table[devtype_data->clk_cfg[i].id] =
> + sky1_audss_clk_register(dev,
[ ... ]
> + if (IS_ERR(clk_table[devtype_data->clk_cfg[i].id])) {
> + ret = PTR_ERR(clk_table[devtype_data->clk_cfg[i].id]);
> + dev_err(dev, "failed to register clock %d, ret:%d\n",
> + devtype_data->clk_cfg[i].id, ret);
> + goto fail_array_clk;
> + }
> + }
> +
> + ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, priv->clk_data);
> + if (ret) {
> + dev_err(dev, "failed to add clock provider: %d\n", ret);
> + goto fail_register;
> + }
[ ... ]
> +fail_register:
> +fail_array_clk:
> + while (i--)
> + clk_hw_unregister_composite(clk_table[devtype_data->clk_cfg[i].id]);
[Severity: High]
Could this cause a use-after-free?
Since devm_of_clk_add_hw_provider() is devres-managed, the OF clock provider
will be unregistered automatically after the probe error path completes. If we
manually free the composite clocks here before the provider is unregistered,
couldn't concurrent clock lookups access the freed clk_hw pointers?
[ ... ]
> +fail_fixed_clk:
> +fail_clks_set:
> + pm_runtime_put_sync(dev);
> +err_pm:
> + pm_runtime_disable(dev);
> + return ret;
> +}
[Severity: Medium]
Does this error path leak the PM runtime usage counter?
Earlier in sky1_audss_clk_probe(), pm_runtime_get_noresume() increments the
counter, but the err_pm path does not call pm_runtime_put_noidle(). Also,
should the rst_noc reset be re-asserted here to match the expected
powered-down state?
[ ... ]
> +static void sky1_audss_clk_remove(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct sky1_audss_clks_priv *priv = dev_get_drvdata(dev);
> + const struct sky1_audss_clks_devtype_data *devtype_data = priv->devtype_data;
> + int i = 0;
> +
> + for (i = 0; i < devtype_data->clk_cfg_size; i++)
> + clk_hw_unregister_composite(priv->clk_data->hws[devtype_data->clk_cfg[i].id]);
[Severity: High]
Similar to the probe error path, does this manual unregistration open a
use-after-free window during unbind, since the devm-registered OF provider is
still active until after sky1_audss_clk_remove() finishes?
> +
> + if (!pm_runtime_status_suspended(dev))
> + pm_runtime_force_suspend(dev);
> +
> + pm_runtime_disable(dev);
> +}
[Severity: High]
Can this forceful suspend break the devres-managed child reset controller?
The child reset controller device created by devm_auxiliary_device_create()
is unregistered after sky1_audss_clk_remove() returns. If we forcefully
suspend the hardware here, wouldn't the child driver access powered-down
registers if it attempts hardware cleanup during its own teardown?
[ ... ]
> +static int __maybe_unused sky1_audss_clk_runtime_resume(struct device *dev)
> +{
> + struct sky1_audss_clks_priv *priv = dev_get_drvdata(dev);
[ ... ]
> + ret = reset_control_deassert(priv->rst_noc);
> + if (ret)
> + return ret;
> +
> + ret = sky1_audss_clks_enable(priv);
> + if (ret) {
> + dev_err(dev, "failed to enable clocks\n");
> + return ret;
> + }
[Severity: Medium]
If sky1_audss_clks_enable() fails, shouldn't we assert priv->rst_noc before
returning, so that the hardware reset state correctly matches the runtime
suspended state?
[ ... ]
> +static struct platform_driver sky1_audss_clk_driver = {
> + .probe = sky1_audss_clk_probe,
> + .remove = sky1_audss_clk_remove,
> + .driver = {
> + .name = "sky1-audss-clk",
> + .suppress_bind_attrs = true,
> + .of_match_table = sky1_audss_clk_of_match,
> + .pm = &sky1_audss_clk_pm_ops,
> + },
> +};
[Severity: Low]
Should the assignment to .pm be wrapped with pm_ptr()? Without it, the
sky1_audss_clk_pm_ops structure and its callbacks will not be eliminated as
dead code when CONFIG_PM is disabled.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623070805.211019-1-joakim.zhang@cixtech.com?part=2
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: pwm: st,pwm: convert to DT schema
From: Krzysztof Kozlowski @ 2026-06-23 7:17 UTC (permalink / raw)
To: Charan Pedumuru
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pal Singh, linux-pwm, devicetree, linux-kernel
In-Reply-To: <20260618-st-pwm-v2-1-c792d5795ce2@gmail.com>
On Thu, Jun 18, 2026 at 12:42:07PM +0000, Charan Pedumuru wrote:
> +description:
> + The STiH41x PWM controller supports both PWM output and input capture
> + functionality. It provides multiple PWM output channels for generating
> + variable duty-cycle waveforms, and multiple input capture channels for
> + measuring external signal periods and pulse widths. PWM output channels
> + and input capture channels are configured independently via
> + st,pwm-num-chan and st,capture-num-chan respectively.
> +
> +allOf:
> + - $ref: pwm.yaml#
Where is this compatible used?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/3] spi: dt-bindings: snps,dw-apb-ssi: add 'power-domains' property
From: Krzysztof Kozlowski @ 2026-06-23 7:16 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Herve Codina, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-spi, devicetree
In-Reply-To: <20260622174806.74450-6-wsa+renesas@sang-engineering.com>
On Mon, Jun 22, 2026 at 07:48:07PM +0200, Wolfram Sang wrote:
> On the Renesas RZ/N1D SoC, this SPI controller belongs to a power
> domain. Enable the property to describe it in DTs.
>
> Reported-by: Herve Codina <herve.codina@bootlin.com>
No bug to be fixed here. Usually incomplete hardware description is not
a reported bug.
> Closes: https://lore.kernel.org/r/20260622132842.7e0d772c@bootlin.com
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Change since v2:
> * new patch (Thanks, Herve!)
>
> Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> index 8ebebcebca16..3896ee02d7b6 100644
> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> @@ -88,6 +88,9 @@ properties:
> - const: ssi_clk
> - const: pclk
>
> + power-domains:
> + maxItems: 1
You should explain in the commit msg that likely other devices belong to
power domain as well or likely can belong. Otherwise based on the commit
msg I would suggest restricting it per variant... except that indeed
these other variants could have a power domain.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v8 3/3] pwm: dwc: add of/platform support
From: dongxuyang @ 2026-06-23 7:15 UTC (permalink / raw)
To: ukleinek, robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel,
linux-pwm, devicetree, linux-kernel
Cc: ningyu, linmin, xuxiang, wangguosheng, pinkesh.vaghela,
Xuyang Dong
In-Reply-To: <20260623071329.2034-1-dongxuyang@eswincomputing.com>
From: Xuyang Dong <dongxuyang@eswincomputing.com>
The dwc pwm controller can be used in non-PCI systems, so allow
either platform or OF based probing.
The controller is reset only when no PWM channel is enabled.
Otherwise, clocks are enabled and the runtime PM state is updated
to reflect the active hardware configuration.
Co-developed-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Xiang Xu <xuxiang@eswincomputing.com>
Signed-off-by: Guosheng Wang <wangguosheng@eswincomputing.com>
Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-dwc-core.c | 103 ++++++++---
drivers/pwm/pwm-dwc-of.c | 346 +++++++++++++++++++++++++++++++++++++
drivers/pwm/pwm-dwc.h | 25 ++-
5 files changed, 455 insertions(+), 30 deletions(-)
create mode 100644 drivers/pwm/pwm-dwc-of.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index e8886a9b64d9..fd1d68beab67 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -249,6 +249,16 @@ config PWM_DWC
To compile this driver as a module, choose M here: the module
will be called pwm-dwc.
+config PWM_DWC_OF
+ tristate "DesignWare PWM Controller (OF bus)"
+ depends on HAS_IOMEM && (OF || COMPILE_TEST)
+ select PWM_DWC_CORE
+ help
+ PWM driver for Synopsys DWC PWM Controller on an OF bus or
+ a platform bus.
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-dwc-of.
+
config PWM_EP93XX
tristate "Cirrus Logic EP93xx PWM support"
depends on ARCH_EP93XX || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 5630a521a7cf..acd7dfe98dff 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PWM_CRC) += pwm-crc.o
obj-$(CONFIG_PWM_CROS_EC) += pwm-cros-ec.o
obj-$(CONFIG_PWM_DWC_CORE) += pwm-dwc-core.o
obj-$(CONFIG_PWM_DWC) += pwm-dwc.o
+obj-$(CONFIG_PWM_DWC_OF) += pwm-dwc-of.o
obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o
obj-$(CONFIG_PWM_FSL_FTM) += pwm-fsl-ftm.o
obj-$(CONFIG_PWM_GPIO) += pwm-gpio.o
diff --git a/drivers/pwm/pwm-dwc-core.c b/drivers/pwm/pwm-dwc-core.c
index 6dabec93a3c6..b9a9d6ae0b45 100644
--- a/drivers/pwm/pwm-dwc-core.c
+++ b/drivers/pwm/pwm-dwc-core.c
@@ -12,8 +12,10 @@
#define DEFAULT_SYMBOL_NAMESPACE "dwc_pwm"
#include <linux/bitops.h>
+#include <linux/clk.h>
#include <linux/export.h>
#include <linux/kernel.h>
+#include <linux/math64.h>
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/pm_runtime.h>
@@ -44,21 +46,55 @@ static int __dwc_pwm_configure_timer(struct dwc_pwm *dwc,
u32 high;
u32 low;
- /*
- * Calculate width of low and high period in terms of input clock
- * periods and check are the result within HW limits between 1 and
- * 2^32 periods.
- */
- tmp = DIV_ROUND_CLOSEST_ULL(state->duty_cycle, dwc->clk_ns);
- if (tmp < 1 || tmp > (1ULL << 32))
- return -ERANGE;
- low = tmp - 1;
-
- tmp = DIV_ROUND_CLOSEST_ULL(state->period - state->duty_cycle,
- dwc->clk_ns);
- if (tmp < 1 || tmp > (1ULL << 32))
- return -ERANGE;
- high = tmp - 1;
+ if (dwc->clk)
+ dwc->clk_rate = clk_get_rate(dwc->clk);
+
+ if (dwc->features & DWC_TIM_CTRL_0N100PWM_EN) {
+ /*
+ * Calculate width of low and high period in terms of input
+ * clock periods and check are the result within HW limits
+ * between 0 and 2^32 periods.
+ * Use mul_u64_u64_div_u64() to avoid overflowing the 64-bit
+ * intermediate result and to round down to the nearest
+ * achievable hardware value, as required by the PWM core.
+ */
+ tmp = mul_u64_u64_div_u64(state->duty_cycle, dwc->clk_rate,
+ NSEC_PER_SEC);
+ if (tmp >= (1ULL << 32))
+ return -ERANGE;
+
+ if (pwm->args.polarity == PWM_POLARITY_INVERSED)
+ high = tmp;
+ else
+ low = tmp;
+
+ tmp = mul_u64_u64_div_u64(state->period - state->duty_cycle,
+ dwc->clk_rate, NSEC_PER_SEC);
+ if (tmp >= (1ULL << 32))
+ return -ERANGE;
+
+ if (pwm->args.polarity == PWM_POLARITY_INVERSED)
+ low = tmp;
+ else
+ high = tmp;
+ } else {
+ /*
+ * Calculate width of low and high period in terms of input
+ * clock periods and check are the result within HW limits
+ * between 1 and 2^32 periods.
+ */
+ tmp = mul_u64_u64_div_u64(state->duty_cycle, dwc->clk_rate,
+ NSEC_PER_SEC);
+ if (tmp < 1 || tmp > (1ULL << 32))
+ return -ERANGE;
+ low = tmp - 1;
+
+ tmp = mul_u64_u64_div_u64(state->period - state->duty_cycle,
+ dwc->clk_rate, NSEC_PER_SEC);
+ if (tmp < 1 || tmp > (1ULL << 32))
+ return -ERANGE;
+ high = tmp - 1;
+ }
/*
* Specification says timer usage flow is to disable timer, then
@@ -74,6 +110,7 @@ static int __dwc_pwm_configure_timer(struct dwc_pwm *dwc,
* width of low period and latter the width of high period in terms
* multiple of input clock periods:
* Width = ((Count + 1) * input clock period).
+ * Width = (Count * input clock period) : supported 0% and 100%.
*/
dwc_pwm_writel(dwc, low, DWC_TIM_LD_CNT(pwm->hwpwm));
dwc_pwm_writel(dwc, high, DWC_TIM_LD_CNT2(pwm->hwpwm));
@@ -85,6 +122,9 @@ static int __dwc_pwm_configure_timer(struct dwc_pwm *dwc,
* periods are set by Load Count registers.
*/
ctrl = DWC_TIM_CTRL_MODE_USER | DWC_TIM_CTRL_PWM;
+ if (dwc->features & DWC_TIM_CTRL_0N100PWM_EN)
+ ctrl |= DWC_TIM_CTRL_0N100PWM_EN;
+
dwc_pwm_writel(dwc, ctrl, DWC_TIM_CTRL(pwm->hwpwm));
/*
@@ -121,10 +161,19 @@ static int dwc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state)
{
struct dwc_pwm *dwc = to_dwc_pwm(chip);
+ unsigned long clk_rate;
u64 duty, period;
u32 ctrl, ld, ld2;
+ int ret;
+
+ ret = pm_runtime_resume_and_get(pwmchip_parent(chip));
+ if (ret)
+ return ret;
- pm_runtime_get_sync(pwmchip_parent(chip));
+ if (dwc->clk)
+ dwc->clk_rate = clk_get_rate(dwc->clk);
+
+ clk_rate = dwc->clk_rate;
ctrl = dwc_pwm_readl(dwc, DWC_TIM_CTRL(pwm->hwpwm));
ld = dwc_pwm_readl(dwc, DWC_TIM_LD_CNT(pwm->hwpwm));
@@ -137,17 +186,25 @@ static int dwc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
* based on the timer load-count only.
*/
if (ctrl & DWC_TIM_CTRL_PWM) {
- duty = (ld + 1) * dwc->clk_ns;
- period = (ld2 + 1) * dwc->clk_ns;
- period += duty;
+ if (dwc->features & DWC_TIM_CTRL_0N100PWM_EN) {
+ if (pwm->args.polarity == PWM_POLARITY_INVERSED)
+ duty = ld2;
+ else
+ duty = ld;
+ period = (u64)ld + ld2;
+ } else {
+ duty = ld + 1;
+ period = ld2 + 1;
+ period += duty;
+ }
} else {
- duty = (ld + 1) * dwc->clk_ns;
+ duty = ld + 1;
period = duty * 2;
}
state->polarity = PWM_POLARITY_INVERSED;
- state->period = period;
- state->duty_cycle = duty;
+ state->period = mul_u64_u64_div_u64(period, NSEC_PER_SEC, clk_rate);
+ state->duty_cycle = mul_u64_u64_div_u64(duty, NSEC_PER_SEC, clk_rate);
pm_runtime_put_sync(pwmchip_parent(chip));
@@ -169,7 +226,7 @@ struct pwm_chip *dwc_pwm_alloc(struct device *dev)
return chip;
dwc = to_dwc_pwm(chip);
- dwc->clk_ns = 10;
+ dwc->clk_rate = NSEC_PER_SEC / 10;
chip->ops = &dwc_pwm_ops;
return chip;
diff --git a/drivers/pwm/pwm-dwc-of.c b/drivers/pwm/pwm-dwc-of.c
new file mode 100644
index 000000000000..34713cb7299e
--- /dev/null
+++ b/drivers/pwm/pwm-dwc-of.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DesignWare PWM Controller driver OF
+ *
+ * Copyright (C) 2026 SiFive, Inc.
+ */
+
+#define DEFAULT_SYMBOL_NAMESPACE "dwc_pwm_of"
+
+#include <linux/clk.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/pwm.h>
+#include <linux/reset.h>
+
+#include "pwm-dwc.h"
+
+struct dwc_pwm_plat_data {
+ bool reset_required;
+};
+
+static int dwc_pwm_plat_probe(struct platform_device *pdev)
+{
+ const struct dwc_pwm_plat_data *pdata;
+ struct device *dev = &pdev->dev;
+ struct dwc_pwm_drvdata *data;
+ u32 ctrl[DWC_TIMERS_TOTAL];
+ struct pwm_chip *chip;
+ struct dwc_pwm *dwc;
+ bool pwm_en = false;
+ u32 nr_pwm, tim_id;
+ unsigned int i;
+ int ret;
+
+ data = devm_kzalloc(dev, struct_size(data, chips, 1), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ chip = dwc_pwm_alloc(dev);
+ if (IS_ERR(chip))
+ return dev_err_probe(dev, PTR_ERR(chip),
+ "failed to alloc pwm\n");
+
+ dwc = to_dwc_pwm(chip);
+
+ dwc->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(dwc->base))
+ return PTR_ERR(dwc->base);
+
+ if (!device_property_read_u32(dev, "snps,pwm-number", &nr_pwm)) {
+ if (nr_pwm > DWC_TIMERS_TOTAL)
+ dev_warn(dev, "too many PWMs (%d), capping at %d\n",
+ nr_pwm, chip->npwm);
+ else
+ chip->npwm = nr_pwm;
+ }
+
+ dwc->bus_clk = devm_clk_get(dev, "bus");
+ if (IS_ERR(dwc->bus_clk))
+ return dev_err_probe(dev, PTR_ERR(dwc->bus_clk),
+ "failed to get bus clock\n");
+
+ dwc->clk = devm_clk_get(dev, "timer");
+ if (IS_ERR(dwc->clk))
+ return dev_err_probe(dev, PTR_ERR(dwc->clk),
+ "failed to get timer clock\n");
+
+ ret = devm_clk_rate_exclusive_get(dev, dwc->clk);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to get exclusive rate\n");
+
+ dwc->clk_rate = clk_get_rate(dwc->clk);
+
+ pdata = device_get_match_data(dev);
+ if (pdata && pdata->reset_required)
+ dwc->rst = devm_reset_control_get_exclusive(dev, NULL);
+ else
+ dwc->rst = devm_reset_control_array_get_optional_exclusive(dev);
+
+ if (IS_ERR(dwc->rst))
+ return dev_err_probe(dev, PTR_ERR(dwc->rst),
+ "failed to get reset control\n");
+
+ ret = clk_prepare_enable(dwc->bus_clk);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to enable bus clock\n");
+
+ ret = clk_prepare_enable(dwc->clk);
+ if (ret) {
+ dev_err(dev, "failed to enable timer clock\n");
+ goto disable_busclk;
+ }
+
+ /*
+ * Check all channels to see if any channel is enabled.
+ * Read the control register of each channel and extract the enable bit
+ */
+ for (i = 0; i < chip->npwm; i++) {
+ ctrl[i] = dwc_pwm_readl(dwc, DWC_TIM_CTRL(i)) & DWC_TIM_CTRL_EN;
+ if (ctrl[i])
+ pwm_en = true;
+ }
+
+ /*
+ * Only issue a reset pulse when all channels are disabled, so a PWM
+ * channel already running (e.g. configured by firmware before Linux
+ * took over) is left undisturbed.
+ */
+ if (!pwm_en) {
+ ret = reset_control_reset(dwc->rst);
+ if (ret) {
+ dev_err(dev, "failed to reset\n");
+ goto disable_clk;
+ }
+ }
+
+ /* init PWM feature */
+ dwc->features = 0;
+ /*
+ * Support for 0% and 100% duty cycle mode was added in version 2.11a
+ * and later.
+ */
+ tim_id = dwc_pwm_readl(dwc, DWC_TIMERS_COMP_VERSION);
+ if (tim_id >= DWC_TIM_VERSION_ID_2_11A)
+ dwc->features |= DWC_TIM_CTRL_0N100PWM_EN;
+
+ data->chips[0] = chip;
+ dev_set_drvdata(dev, data);
+
+ /*
+ * If any PWM channel is enabled, mark device active and hold runtime PM
+ * references for each enabled channel. Otherwise, gate the clocks.
+ */
+ if (pwm_en) {
+ pm_runtime_set_active(dev);
+ for (i = 0; i < chip->npwm; i++) {
+ if (ctrl[i])
+ pm_runtime_get_noresume(dev);
+ }
+ } else {
+ clk_disable_unprepare(dwc->clk);
+ clk_disable_unprepare(dwc->bus_clk);
+ }
+
+ pm_runtime_enable(dev);
+
+ ret = pwmchip_add(chip);
+ if (ret) {
+ dev_err(dev, "failed to add pwm chip\n");
+ goto pm_disable;
+ }
+
+ return 0;
+
+pm_disable:
+ pm_runtime_disable(dev);
+ if (pwm_en) {
+ for (i = 0; i < chip->npwm; i++) {
+ if (ctrl[i])
+ pm_runtime_put_noidle(dev);
+ }
+ }
+disable_clk:
+ clk_disable_unprepare(dwc->clk);
+disable_busclk:
+ clk_disable_unprepare(dwc->bus_clk);
+
+ return ret;
+}
+
+static void dwc_pwm_plat_remove(struct platform_device *pdev)
+{
+ struct dwc_pwm_drvdata *data = platform_get_drvdata(pdev);
+ struct pwm_chip *chip = data->chips[0];
+ struct dwc_pwm *dwc = to_dwc_pwm(chip);
+ unsigned int idx;
+ int ret;
+
+ pm_runtime_get_sync(&pdev->dev);
+ pwmchip_remove(chip);
+
+ for (idx = 0; idx < chip->npwm; idx++) {
+ if (dwc_pwm_readl(dwc, DWC_TIM_CTRL(idx)) & DWC_TIM_CTRL_EN)
+ pm_runtime_put_noidle(&pdev->dev);
+ }
+ pm_runtime_put_sync(&pdev->dev);
+
+ if (!pm_runtime_status_suspended(&pdev->dev)) {
+ clk_disable_unprepare(dwc->clk);
+ clk_disable_unprepare(dwc->bus_clk);
+ }
+ pm_runtime_disable(&pdev->dev);
+
+ if (dwc->rst) {
+ ret = reset_control_assert(dwc->rst);
+ if (ret)
+ dev_warn(&pdev->dev, "failed to assert reset: %d\n",
+ ret);
+ }
+}
+
+static int dwc_pwm_runtime_suspend(struct device *dev)
+{
+ struct dwc_pwm_drvdata *data = dev_get_drvdata(dev);
+ struct pwm_chip *chip = data->chips[0];
+ struct dwc_pwm *dwc = to_dwc_pwm(chip);
+
+ clk_disable_unprepare(dwc->clk);
+ clk_disable_unprepare(dwc->bus_clk);
+
+ return 0;
+}
+
+static int dwc_pwm_runtime_resume(struct device *dev)
+{
+ struct dwc_pwm_drvdata *data = dev_get_drvdata(dev);
+ struct pwm_chip *chip = data->chips[0];
+ struct dwc_pwm *dwc = to_dwc_pwm(chip);
+ int ret;
+
+ ret = clk_prepare_enable(dwc->bus_clk);
+ if (ret) {
+ dev_err(dev, "failed to enable bus clock: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(dwc->clk);
+ if (ret) {
+ dev_err(dev, "failed to enable timer clock: %d\n", ret);
+ clk_disable_unprepare(dwc->bus_clk);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int dwc_pwm_suspend(struct device *dev)
+{
+ struct dwc_pwm_drvdata *data = dev_get_drvdata(dev);
+ struct pwm_chip *chip = data->chips[0];
+ struct dwc_pwm *dwc = to_dwc_pwm(chip);
+ unsigned int idx;
+ int ret;
+
+ if (pm_runtime_status_suspended(dev)) {
+ ret = dwc_pwm_runtime_resume(dev);
+ if (ret)
+ return ret;
+ }
+
+ for (idx = 0; idx < chip->npwm; idx++) {
+ if (chip->pwms[idx].state.enabled)
+ return -EBUSY;
+
+ dwc->ctx[idx].cnt = dwc_pwm_readl(dwc, DWC_TIM_LD_CNT(idx));
+ dwc->ctx[idx].cnt2 = dwc_pwm_readl(dwc, DWC_TIM_LD_CNT2(idx));
+ dwc->ctx[idx].ctrl = dwc_pwm_readl(dwc, DWC_TIM_CTRL(idx));
+ }
+
+ ret = dwc_pwm_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int dwc_pwm_resume(struct device *dev)
+{
+ struct dwc_pwm_drvdata *data = dev_get_drvdata(dev);
+ struct pwm_chip *chip = data->chips[0];
+ struct dwc_pwm *dwc = to_dwc_pwm(chip);
+ unsigned int idx;
+ bool pm_flags;
+ int ret;
+
+ /* Check if device was runtime suspended before system resume */
+ pm_flags = pm_runtime_status_suspended(dev);
+ if (pm_flags) {
+ /*
+ * Use PM framework to resume device
+ * (calls dwc_pwm_runtime_resume)
+ */
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0)
+ return ret;
+ } else {
+ /*
+ * Device was active, but clocks might be off after system sleep
+ * Call runtime_resume directly to restore hardware state
+ */
+ ret = dwc_pwm_runtime_resume(dev);
+ if (ret)
+ return ret;
+ }
+
+ for (idx = 0; idx < chip->npwm; idx++) {
+ dwc_pwm_writel(dwc, dwc->ctx[idx].cnt, DWC_TIM_LD_CNT(idx));
+ dwc_pwm_writel(dwc, dwc->ctx[idx].cnt2, DWC_TIM_LD_CNT2(idx));
+ dwc_pwm_writel(dwc, dwc->ctx[idx].ctrl, DWC_TIM_CTRL(idx));
+ }
+
+ if (pm_flags) {
+ /*
+ * Balance the refcount taken by pm_runtime_get_sync
+ * if it was used
+ */
+ pm_runtime_put_sync(dev);
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops dwc_pwm_pm_ops = {
+ RUNTIME_PM_OPS(dwc_pwm_runtime_suspend, dwc_pwm_runtime_resume, NULL)
+ SYSTEM_SLEEP_PM_OPS(dwc_pwm_suspend, dwc_pwm_resume)
+};
+
+static const struct dwc_pwm_plat_data pwm_eic7700_pdata = {
+ .reset_required = true,
+};
+
+static const struct of_device_id dwc_pwm_dt_ids[] = {
+ { .compatible = "snps,dw-apb-timers-pwm2" },
+ { .compatible = "eswin,eic7700-pwm", .data = &pwm_eic7700_pdata },
+ { }
+};
+MODULE_DEVICE_TABLE(of, dwc_pwm_dt_ids);
+
+static struct platform_driver dwc_pwm_plat_driver = {
+ .driver = {
+ .name = "dwc-pwm",
+ .pm = pm_ptr(&dwc_pwm_pm_ops),
+ .of_match_table = dwc_pwm_dt_ids,
+ },
+ .probe = dwc_pwm_plat_probe,
+ .remove = dwc_pwm_plat_remove,
+};
+
+module_platform_driver(dwc_pwm_plat_driver);
+
+MODULE_ALIAS("platform:dwc-pwm-of");
+MODULE_AUTHOR("Ben Dooks <ben.dooks@codethink.co.uk>");
+MODULE_DESCRIPTION("DesignWare PWM Controller");
+MODULE_LICENSE("GPL");
diff --git a/drivers/pwm/pwm-dwc.h b/drivers/pwm/pwm-dwc.h
index 1562594e7f85..75f7c2d031c4 100644
--- a/drivers/pwm/pwm-dwc.h
+++ b/drivers/pwm/pwm-dwc.h
@@ -26,12 +26,19 @@ MODULE_IMPORT_NS("dwc_pwm");
#define DWC_TIMERS_TOTAL 8
/* Timer Control Register */
-#define DWC_TIM_CTRL_EN BIT(0)
-#define DWC_TIM_CTRL_MODE BIT(1)
-#define DWC_TIM_CTRL_MODE_FREE (0 << 1)
-#define DWC_TIM_CTRL_MODE_USER (1 << 1)
-#define DWC_TIM_CTRL_INT_MASK BIT(2)
-#define DWC_TIM_CTRL_PWM BIT(3)
+#define DWC_TIM_CTRL_EN BIT(0)
+#define DWC_TIM_CTRL_MODE BIT(1)
+#define DWC_TIM_CTRL_MODE_FREE (0 << 1)
+#define DWC_TIM_CTRL_MODE_USER BIT(1)
+#define DWC_TIM_CTRL_INT_MASK BIT(2)
+#define DWC_TIM_CTRL_PWM BIT(3)
+#define DWC_TIM_CTRL_0N100PWM_EN BIT(4)
+
+/*
+ * The version 2.11a and later add "Pulse Width Modulation with
+ * 0% and 100% Duty Cycle".
+ */
+#define DWC_TIM_VERSION_ID_2_11A 0x3231312a
struct dwc_pwm_info {
unsigned int nr;
@@ -52,8 +59,12 @@ struct dwc_pwm_ctx {
struct dwc_pwm {
void __iomem *base;
- unsigned int clk_ns;
+ struct clk *bus_clk;
+ struct clk *clk;
+ unsigned long clk_rate;
+ struct reset_control *rst;
struct dwc_pwm_ctx ctx[DWC_TIMERS_TOTAL];
+ u32 features;
};
static inline struct dwc_pwm *to_dwc_pwm(struct pwm_chip *chip)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 0/5] Shikra: Add DT support for ice, rng and qce
From: Bartosz Golaszewski @ 2026-06-23 7:15 UTC (permalink / raw)
To: Eric Biggers
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Andy Gross, Harshal Dev, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, dmaengine, Kuldeep Singh,
Bartosz Golaszewski
In-Reply-To: <20260622181909.GA1250822@google.com>
On Mon, 22 Jun 2026 20:19:09 +0200, Eric Biggers <ebiggers@kernel.org> said:
> On Mon, Jun 22, 2026 at 04:25:12AM -0400, Bartosz Golaszewski wrote:
>> On Fri, 19 Jun 2026 18:45:06 +0200, Eric Biggers <ebiggers@kernel.org> said:
>> > On Fri, Jun 19, 2026 at 02:13:28PM +0530, Kuldeep Singh wrote:
>> >> On 21-05-2026 18:47, Kuldeep Singh wrote:
>> >> > This patchseries attempt to enable sdhc-ice, rng and qce on shikra
>> >> > platform similar to other platforms.
>> >> >
>> >> > Previously, the 3 dt-bindigs/DT changes were sent as individual series
>> >> > and with feedback received, clubbed them together as all belong to same
>> >> > crypto subsystem.
>> >> >
>> >> > Here's link to old patchsets.
>> >> > QCE: https://lore.kernel.org/lkml/20260515-shikra_qcrypto-v1-0-80f07b345c29@oss.qualcomm.com/
>> >>
>> >> Hi Eric,
>> >>
>> >> As selftests issues for QCE are now fixed[1], so shikra series should be
>> >> good to proceed? as your concerns[2] are now addressed.
>> >> I am waiting for merge window to end and will send next rev post that.
>> >>
>> >> [1]
>> >> https://lore.kernel.org/linux-arm-msm/20260617-qce-fix-self-tests-v3-0-ecc2b4dedcfd@oss.qualcomm.com/
>> >> [2] https://lore.kernel.org/lkml/20260522024912.GC5937@quark/
>> >
>> > If you think that then it sounds like you need to read what I actually
>> > said. The fixes are appreciated but don't change the big picture.
>> >
>> > - Eric
>> >
>>
>> Eric,
>>
>> I mentioned it in another thread[1]. This series is not adding any new features
>> to the QCE driver, it describes the hardware. The SoC *does have* this IP and
>> no matter the state of the support in the kernel, there's nothing wrong in
>> extending the existing bindings and adding new dts nodes.
>>
>> Thanks,
>> Bartosz
>
> It enables the driver on a new platform. So it very much has a real
> effect. It's not just adding a hardware description without a user.
>
The driver can be disabled by not building it. The hardware description in dts
must reflect the reality. This is what dt-bindings and devicetree sources do:
they *describe* the hardware. It's up to the systems integrator to build the
relevant driver or not.
Let's wait for DT maintainers to respond to v2 once it's out.
Bartosz
^ permalink raw reply
* [PATCH v8 2/3] dt-bindings: pwm: dwc: Add eswin compatible
From: dongxuyang @ 2026-06-23 7:14 UTC (permalink / raw)
To: ukleinek, robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel,
linux-pwm, devicetree, linux-kernel
Cc: ningyu, linmin, xuxiang, wangguosheng, pinkesh.vaghela,
Xuyang Dong
In-Reply-To: <20260623071329.2034-1-dongxuyang@eswincomputing.com>
From: Xuyang Dong <dongxuyang@eswincomputing.com>
EIC7700 integrates the DesignWare PWM IP described by the generic
snps,dw-apb-timers-pwm2 binding. On this SoC, the presetn and
timer_N_resetn inputs are physically tied together to a single reset
line, so exactly one reset is both required and sufficient, unlike
the generic binding where up to two independent lines are optional.
Add the eswin,eic7700-pwm compatible string and constrain its resets
property to exactly one entry.
Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
---
.../bindings/pwm/snps,dw-apb-timers-pwm2.yaml | 32 ++++++++++++++++---
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
index 213fdaef25d9..9a9a24ddc61b 100644
--- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
+++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
@@ -20,12 +20,11 @@ description:
instead of having to encode the IP version number in the device tree
compatible.
-allOf:
- - $ref: pwm.yaml#
-
properties:
compatible:
- const: snps,dw-apb-timers-pwm2
+ enum:
+ - snps,dw-apb-timers-pwm2
+ - eswin,eic7700-pwm
reg:
maxItems: 1
@@ -44,6 +43,7 @@ properties:
- const: timer
resets:
+ minItems: 1
items:
- description: Interface bus (presetn) reset
- description: PWM timer logic (timer_N_resetn) reset
@@ -59,6 +59,21 @@ required:
- clocks
- clock-names
+allOf:
+ - $ref: pwm.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: eswin,eic7700-pwm
+ then:
+ properties:
+ resets:
+ maxItems: 1
+ required:
+ - resets
+
additionalProperties: false
examples:
@@ -70,3 +85,12 @@ examples:
clocks = <&bus>, <&timer>;
clock-names = "bus", "timer";
};
+ - |
+ pwm@50818000 {
+ compatible = "eswin,eic7700-pwm";
+ reg = <0x50818000 0x4000>;
+ #pwm-cells = <3>;
+ clocks = <&bus>, <&timer>;
+ clock-names = "bus", "timer";
+ resets = <&reset>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v8 1/3] dt-bindings: pwm: dwc: Document optional resets property
From: dongxuyang @ 2026-06-23 7:14 UTC (permalink / raw)
To: ukleinek, robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel,
linux-pwm, devicetree, linux-kernel
Cc: ningyu, linmin, xuxiang, wangguosheng, pinkesh.vaghela,
Xuyang Dong
In-Reply-To: <20260623071329.2034-1-dongxuyang@eswincomputing.com>
From: Xuyang Dong <dongxuyang@eswincomputing.com>
The DesignWare PWM IP has two active-low reset inputs: presetn resets
the register interface logic in the pclk (bus) domain, and
timer_N_resetn resets the counter/timer logic in the timer_N_clk
domain. The existing snps,dw-apb-timers-pwm2 binding does not
describe either of these lines.
Add the resets property and describe the function of each reset to
support future use of resets.
Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
---
.../devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
index 7523a89a1773..213fdaef25d9 100644
--- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
+++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
@@ -43,6 +43,11 @@ properties:
- const: bus
- const: timer
+ resets:
+ items:
+ - description: Interface bus (presetn) reset
+ - description: PWM timer logic (timer_N_resetn) reset
+
snps,pwm-number:
$ref: /schemas/types.yaml#/definitions/uint32
description: The number of PWM channels configured for this instance
--
2.34.1
^ permalink raw reply related
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