[PATCH v2 00/16] add AUXADC, EFUSE and thermal drivers for the MediaTek mt6323 PMIC

[PATCH v2 00/16] add AUXADC, EFUSE and thermal drivers for the MediaTek mt6323 PMIC

[Roman Vivchar via B4 Relay]

This series adds support for AUXADC, EFUSE and thermal drivers for the
MediaTek mt6323 PMIC

Usually vendor downstream kernels for devices with mt6323 include various
useful drivers like AUXADC, thermal, fuel gauge etc. Bring it to the
upstream kernel by rewriting some drivers from 3.18 vendor tree.

Currently dt-bindings limit some values like ADC channel count and names
to what mt6323 has, but the drivers were designed in a way to support
other PMICs like mt6358 (which has very similar thermal logic).

Tested on the MediaTek mt6572 and mt8163 SoCs, both paired with mt6323.

Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
Changes in v2:
- dt-bindings:
    - Drop Tested-by tags (Krzysztof)
    - AUXADC: drop mt6323 standalone binding and merge into mt6359 (Krzysztof)
    - EFUSE: drop mt6323 standalone binding and merge into mt6397 (Krzysztof)
    - Thermal: drop iio-channel-names, nvmem-cells description, unused label (Rob)
    - Thermal: Merge into mt6397 mfd
- AUXADC driver:
    - Fix formatting for macro, OF table, etc (Andy, Jonathan)
    - Drop dev field from the mt6323_auxadc struct (Andy)
    - Use dt-bindings constants for channels instead of raw numbers
    - Simplify mt6323_auxadc_check_if_stuck implemenetation with iopoll (Andy)
    - Drop untested audio channel support (Andy, Jonathan)
    - Replace check for chan->address with chan->channel to avoid confusion (Jonathan)
    - Replace scoped_guard with guard in mt6323_auxadc_read_raw (Andy)
    - Replace mutex_init with devm helper in probe (Andy)
- EFUSE driver:
    - Add comments about read function (Andy)
    - Use sizeof() (Andy)
- Thermal driver:
    - Rename to mtk_pmic_thermal for proper module name
    - Add module name to Kconfig
    - Use bitfield.h APIs for efuse extraction (Andy)
    - Drop nvmem cell name for consistency with devicetree bindings
    - Replace raw numbers with constants (Andy)
    - Add comments to read function, remove redundant parentheses (Andy)
    - Add comments to precalc function, simplify it for readability (Andy)
    - Reorder struct fields (Andy)
    - Drop cali_val field, since per-PMIC functions are used
    - Use __free for nvmem_cell_read cleanup (Andy)
- Maintainers:
    - Split patch into 3 for different subsystems (Krzysztof)
    - Downgrade to "Odd fixes"
- Note: Signing key has been changed since v1. Sorry for inconvenience
- Link to v1: https://patch.msgid.link/20260504-mt6323-v1-0-799b58b355ff@protonmail.com

---
Roman Vivchar (16):
      dt-bindings: iio: adc: mt6359: generalize description for mt63xx series
      dt-bindings: iio: adc: mt6359: add mt6323 PMIC AUXADC
      dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
      dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC thermal
      iio: adc: mediatek: add mt6323 PMIC AUXADC driver
      nvmem: add mt6323 PMIC EFUSE driver
      thermal: mediatek: add PMIC thermal support
      mfd: mt6397-core: add mt6323 AUXADC support
      mfd: mt6397-core: add mt6323 EFUSE support
      mfd: mt6397-core: add mt6323 thermal support
      ARM: dts: mediatek: mt6323: add AUXADC support
      ARM: dts: mediatek: mt6323: add EFUSE support
      ARM: dts: mediatek: mt6323: add thermal support
      MAINTAINERS: add MediaTek mt6323 PMIC AUXADC driver maintainer
      MAINTAINERS: add MediaTek mt6323 PMIC EFUSE driver maintainer
      MAINTAINERS: add MediaTek mt6323 PMIC thermal driver maintainer

 .../bindings/iio/adc/mediatek,mt6359-auxadc.yaml   |   3 +-
 .../devicetree/bindings/mfd/mediatek,mt6397.yaml   |  65 +++++
 MAINTAINERS                                        |  15 +
 arch/arm/boot/dts/mediatek/mt6323.dtsi             |  40 +++
 drivers/iio/adc/Kconfig                            |  11 +
 drivers/iio/adc/Makefile                           |   1 +
 drivers/iio/adc/mt6323-auxadc.c                    | 319 +++++++++++++++++++++
 drivers/mfd/mt6397-core.c                          |   9 +
 drivers/nvmem/Kconfig                              |  11 +
 drivers/nvmem/Makefile                             |   2 +
 drivers/nvmem/mt6323-efuse.c                       |  86 ++++++
 drivers/thermal/mediatek/Kconfig                   |  12 +
 drivers/thermal/mediatek/Makefile                  |   1 +
 drivers/thermal/mediatek/mtk_pmic_thermal.c        | 316 ++++++++++++++++++++
 .../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h   |  24 ++
 15 files changed, 914 insertions(+), 1 deletion(-)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260502-mt6323-94e1f2d2abb3

Best regards,
--  
Roman Vivchar <rva333@protonmail.com>

[PATCH v2 01/16] dt-bindings: iio: adc: mt6359: generalize description for mt63xx series

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

Update binding title to the MT63xx, since the list of compatibles already
includes mt6363 and mt6373 which don't belong to the mt6350 family.

Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
 Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 2 +-
 1 file changed, 1 insertion(+), 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..2e8857e104f5 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 MT63xx series PMIC AUXADC
 
 maintainers:
   - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

-- 
2.54.0

Re: [PATCH v2 01/16] dt-bindings: iio: adc: mt6359: generalize description for mt63xx series

[Jonathan Cameron]

On Tue, 12 May 2026 08:18:15 +0300
Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:

> From: Roman Vivchar <rva333@protonmail.com>
> 
> Update binding title to the MT63xx, since the list of compatibles already
> includes mt6363 and mt6373 which don't belong to the mt6350 family.
Hi Roman,

Wild cards have a nasty habit of going wrong.  I'd prefer to see
language like: MT6359 and similar PMIC AUXADC

It is less important here than in many other places because the
file has an explicit list soon after this, but none the less
we've been bitten by this too often to think manufacturers won't
throw a completely non compatible part in the middle of a wild
card covered range.

> 
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
>  Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 2 +-
>  1 file changed, 1 insertion(+), 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..2e8857e104f5 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 MT63xx series PMIC AUXADC
>  
>  maintainers:
>    - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> 

Re: [PATCH v2 01/16] dt-bindings: iio: adc: mt6359: generalize description for mt63xx series

[Roman Vivchar]

On Tuesday, May 12th, 2026 at 4:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:

> On Tue, 12 May 2026 08:18:15 +0300
> Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:
> 
> > From: Roman Vivchar <rva333@protonmail.com>
> >
> > Update binding title to the MT63xx, since the list of compatibles already
> > includes mt6363 and mt6373 which don't belong to the mt6350 family.
> Hi Roman,
> 
> Wild cards have a nasty habit of going wrong.  I'd prefer to see
> language like: MT6359 and similar PMIC AUXADC

Hi Jonathan,

I agree that it would be better to specify the exact PMIC models, however
'similar' wording might be a bit misleading here. As far as I know,
the mt6363 and mt6373 use SPMI, while mt635x (and older models, like
most of the mt63xx series) use PWRAP (a custom SPI-based protocol).
The mt6323 has an older AUXADC revision which is not compatible
with the mt635x driver.

Would you prefer more explicit list like 'MT6323, MT6350 series, MT6363
and MT6373 PMIC AUXADC'? It's a bit mess because some mt63xx
(like mt6333) are sub-PMICs and use I2C instead of PWRAP.

> It is less important here than in many other places because the
> file has an explicit list soon after this, but none the less
> we've been bitten by this too often to think manufacturers won't
> throw a completely non compatible part in the middle of a wild
> card covered range.
> 

Best regards,
Roman

Re: [PATCH v2 01/16] dt-bindings: iio: adc: mt6359: generalize description for mt63xx series

[Jonathan Cameron]

On Tue, 12 May 2026 13:55:26 +0000
Roman Vivchar <rva333@protonmail.com> wrote:

> On Tuesday, May 12th, 2026 at 4:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> 
> > On Tue, 12 May 2026 08:18:15 +0300
> > Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:
> >   
> > > From: Roman Vivchar <rva333@protonmail.com>
> > >
> > > Update binding title to the MT63xx, since the list of compatibles already
> > > includes mt6363 and mt6373 which don't belong to the mt6350 family.  
> > Hi Roman,
> > 
> > Wild cards have a nasty habit of going wrong.  I'd prefer to see
> > language like: MT6359 and similar PMIC AUXADC  
> 
> Hi Jonathan,
> 
> I agree that it would be better to specify the exact PMIC models, however
> 'similar' wording might be a bit misleading here. As far as I know,
> the mt6363 and mt6373 use SPMI, while mt635x (and older models, like
> most of the mt63xx series) use PWRAP (a custom SPI-based protocol).
> The mt6323 has an older AUXADC revision which is not compatible
> with the mt635x driver.
> 
> Would you prefer more explicit list like 'MT6323, MT6350 series, MT6363
> and MT6373 PMIC AUXADC'? It's a bit mess because some mt63xx
> (like mt6333) are sub-PMICs and use I2C instead of PWRAP.
Complete lists don't work because sooner or later they become too long
for a title (though they should be there elsewhere in the dt-binding!)

Perhaps something around: mt6359 and similar SoC ADCs including those accessed via ....
 
> 
> > It is less important here than in many other places because the
> > file has an explicit list soon after this, but none the less
> > we've been bitten by this too often to think manufacturers won't
> > throw a completely non compatible part in the middle of a wild
> > card covered range.
> >   
> 
> Best regards,
> Roman

[PATCH v2 02/16] dt-bindings: iio: adc: mt6359: add mt6323 PMIC AUXADC

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
temperature, and other internal measurements.

Add the devicetree binding documentation and the associated header file
defining the ADC channel constants.

Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
 .../bindings/iio/adc/mediatek,mt6359-auxadc.yaml   |  1 +
 .../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h   | 24 ++++++++++++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
index 2e8857e104f5..1cafc314b8ab 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
@@ -19,6 +19,7 @@ description:
 properties:
   compatible:
     enum:
+      - mediatek,mt6323-auxadc
       - mediatek,mt6357-auxadc
       - mediatek,mt6358-auxadc
       - mediatek,mt6359-auxadc
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

[PATCH v2 03/16] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

The MediaTek mt6323 PMIC includes an EFUSE used for storing calibration
data.

Add the devicetree binding documentation for the MediaTek mt6323 EFUSE.

Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
 .../devicetree/bindings/mfd/mediatek,mt6397.yaml    | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 05c121b0cb3d..beaa67bf0df2 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -145,6 +145,23 @@ properties:
     required:
       - compatible
 
+  efuse:
+    type: object
+    unevaluatedProperties: false
+    description:
+      The efuse is responsible for storing calibration data, such as thermal
+      sensor calibration.
+
+    properties:
+      compatible:
+        const: mediatek,mt6323-efuse
+
+      nvmem-layout:
+        $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+
+    required:
+      - compatible
+
   leds:
     type: object
     additionalProperties: false
@@ -243,6 +260,10 @@ examples:
         interrupt-controller;
         #interrupt-cells = <2>;
 
+        efuse {
+          compatible = "mediatek,mt6323-efuse";
+        };
+
         leds {
             compatible = "mediatek,mt6323-led";
             #address-cells = <1>;

-- 
2.54.0

[PATCH v2 04/16] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC thermal

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

The MediaTek mt6323 PMIC temperature can be read using AUXADC channel.

Add the devicetree binding documentation for the MediaTek mt6323 thermal.

While mt6323 exposes only a single thermal sensor, newer PMICs like
mt6358 provide more than one sensor. Therefore define #thermal-sensor-cells
as 1 to avoid breaking devicetree ABI in the future.

Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
 .../devicetree/bindings/mfd/mediatek,mt6397.yaml   | 44 ++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index beaa67bf0df2..2c826737189e 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -242,6 +242,31 @@ properties:
     description:
       Pin controller
 
+  thermal:
+    type: object
+    unevaluatedProperties: false
+    description:
+      PMIC thermal monitoring
+
+    properties:
+      compatible:
+        const: mediatek,mt6323-thermal
+
+      io-channels:
+        description:
+          IIO channel for the AUXADC to read raw data from.
+        maxItems: 1
+
+      nvmem-cells:
+        maxItems: 1
+
+      "#thermal-sensor-cells":
+        const: 1
+    required:
+      - compatible
+      - io-channels
+      - "#thermal-sensor-cells"
+
 required:
   - compatible
   - regulators
@@ -250,6 +275,7 @@ additionalProperties: false
 
 examples:
   - |
+    #include <dt-bindings/iio/adc/mediatek,mt6323-auxadc.h>
     #include <dt-bindings/interrupt-controller/arm-gic.h>
     #include <dt-bindings/leds/common.h>
 
@@ -262,6 +288,16 @@ examples:
 
         efuse {
           compatible = "mediatek,mt6323-efuse";
+
+          nvmem-layout {
+            compatible = "fixed-layout";
+            #address-cells = <1>;
+            #size-cells = <1>;
+
+            mt6323_thermal_calibration_data: thermal-data@14 {
+              reg = <0x14 0x4>;
+            };
+          };
         };
 
         leds {
@@ -511,6 +547,14 @@ examples:
         rtc {
             compatible = "mediatek,mt6323-rtc";
         };
+
+        thermal {
+          compatible = "mediatek,mt6323-thermal";
+          nvmem-cells = <&mt6323_thermal_calibration_data>;
+
+          io-channels = <&mt6323_adc MT6323_AUXADC_CHIP_TEMP>;
+          #thermal-sensor-cells = <1>;
+        };
     };
 
   - |

-- 
2.54.0

[PATCH v2 05/16] iio: adc: mediatek: add mt6323 PMIC AUXADC driver

[Roman Vivchar via B4 Relay]

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>
---
 drivers/iio/adc/Kconfig         |  11 ++
 drivers/iio/adc/Makefile        |   1 +
 drivers/iio/adc/mt6323-auxadc.c | 319 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 331 insertions(+)

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..2c2b495e3d38
--- /dev/null
+++ b/drivers/iio/adc/mt6323-auxadc.c
@@ -0,0 +1,319 @@
+// 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/property.h>
+#include <linux/regmap.h>
+#include <linux/stringify.h>
+#include <linux/types.h>
+
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6323/registers.h>
+
+#include <dt-bindings/iio/adc/mediatek,mt6323-auxadc.h>
+
+#define AUXADC_RSTB_SEL		BIT(7)
+#define AUXADC_RSTB_SW		BIT(5)
+
+#define AUXADC_CTL_CK		BIT(5)
+
+#define AUXADC_TRIM_CH2		(3 << 10)
+#define AUXADC_TRIM_CH4		(3 << 8)
+#define AUXADC_TRIM_CH5		(3 << 4)
+#define AUXADC_TRIM_CH6		(3 << 2)
+
+#define AUXADC_VREF18_ENB_MD	BIT(15)
+#define AUXADC_MD_STATUS	BIT(0)
+
+#define AUXADC_GPS_STATUS	BIT(1)
+
+#define AUXADC_VREF18_SELB	BIT(1)
+#define AUXADC_DECI_GDLY_SEL	BIT(0)
+
+#define AUXADC_VBUF_EN		BIT(4)
+
+#define AUXADC_DECI_GDLY_MASK		GENMASK(15, 14)
+#define AUXADC_ADC19_BUSY_MASK		GENMASK(15, 1)
+#define AUXADC_RDY_MASK			BIT(15)
+#define AUXADC_DATA_MASK		GENMASK(14, 0)
+
+#define AUXADC_OSR_MASK			GENMASK(12, 10)
+#define AUXADC_DEFAULT_OSR		3
+
+#define AUXADC_LOW_CHANNEL_MASK		GENMASK(9, 0)
+#define AUXADC_AUDIO_CHANNEL_MASK	GENMASK(8, 0)
+
+#define VOLTAGE_FULL_RANGE	1800
+#define AUXADC_PRECISE		32768
+
+#define MTK_PMIC_IIO_CHAN(_name, _idx, _ch_type)       \
+{                                                      \
+	.type = _ch_type,                              \
+	.indexed = 1,                                  \
+	.channel = _idx,                               \
+	.address = _idx,                               \
+	.datasheet_name = __stringify(_name),          \
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+			      BIT(IIO_CHAN_INFO_SCALE) \
+}
+
+static const struct iio_chan_spec mt6323_auxadc_channels[] = {
+	MTK_PMIC_IIO_CHAN(baton2, MT6323_AUXADC_BATON2, IIO_VOLTAGE),
+	MTK_PMIC_IIO_CHAN(ch6, MT6323_AUXADC_CH6, IIO_VOLTAGE),
+	MTK_PMIC_IIO_CHAN(bat_temp, MT6323_AUXADC_BAT_TEMP, IIO_TEMP),
+	MTK_PMIC_IIO_CHAN(chip_temp, MT6323_AUXADC_CHIP_TEMP, IIO_TEMP),
+	MTK_PMIC_IIO_CHAN(vcdt, MT6323_AUXADC_VCDT, IIO_VOLTAGE),
+	MTK_PMIC_IIO_CHAN(baton1, MT6323_AUXADC_BATON1, IIO_VOLTAGE),
+	MTK_PMIC_IIO_CHAN(isense, MT6323_AUXADC_ISENSE, IIO_VOLTAGE),
+	MTK_PMIC_IIO_CHAN(batsns, MT6323_AUXADC_BATSNS, IIO_VOLTAGE),
+	MTK_PMIC_IIO_CHAN(accdet, MT6323_AUXADC_ACCDET, IIO_VOLTAGE),
+};
+
+/**
+ * struct mt6323_auxadc - Main driver structure
+ * @regmap:        Regmap from PWRAP
+ * @lock:          Mutex to serialize AUXADC reading vs configuration
+ *
+ * The MediaTek MT6323 (as well as lot of other PMICs) have the following hierarchy:
+ * PMIC AUXADC <- PMIC MFD <- SoC PWRAP (wrapper for PWRAP FSM)
+ *
+ * Therefore, PWRAP regmap should be get using dev->parent->parent.
+ */
+struct mt6323_auxadc {
+	struct regmap *regmap;
+	struct mutex lock;
+};
+
+static u32 mt6323_auxadc_channel_to_reg(unsigned long channel)
+{
+	switch (channel) {
+	case MT6323_AUXADC_BATON2:
+		return MT6323_AUXADC_ADC6;
+	case MT6323_AUXADC_CH6:
+		return MT6323_AUXADC_ADC11;
+	case MT6323_AUXADC_BAT_TEMP:
+		return MT6323_AUXADC_ADC5;
+	case MT6323_AUXADC_CHIP_TEMP:
+		return MT6323_AUXADC_ADC4;
+	case MT6323_AUXADC_VCDT:
+		return MT6323_AUXADC_ADC2;
+	case MT6323_AUXADC_BATON1:
+		return MT6323_AUXADC_ADC3;
+	case MT6323_AUXADC_ISENSE:
+		return MT6323_AUXADC_ADC1;
+	case MT6323_AUXADC_BATSNS:
+		return MT6323_AUXADC_ADC0;
+	case MT6323_AUXADC_ACCDET:
+		return MT6323_AUXADC_ADC7;
+	default:
+		return MT6323_AUXADC_ADC17;
+	}
+}
+
+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_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_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_VBUF_EN);
+	if (ret)
+		return ret;
+
+	ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+	if (ret)
+		return ret;
+
+	return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+}
+
+static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
+			      const struct iio_chan_spec *chan, int *out)
+{
+	struct regmap *map = auxadc->regmap;
+	u32 val, reg = mt6323_auxadc_channel_to_reg(chan->address);
+	int ret;
+
+	ret = regmap_read_poll_timeout(map, reg, val, (val & AUXADC_RDY_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 = 1;
+
+	if (mask == IIO_CHAN_INFO_RAW) {
+		guard(mutex)(&auxadc->lock);
+		ret = mt6323_auxadc_prepare_channel(auxadc);
+		if (ret)
+			return ret;
+
+		ret = mt6323_auxadc_request(auxadc, chan->address);
+		if (ret)
+			return ret;
+
+		fsleep(300);
+
+		ret = mt6323_auxadc_read(auxadc, chan, val);
+		if (ret)
+			return ret;
+		return IIO_VAL_INT;
+	} else if (mask == IIO_CHAN_INFO_SCALE) {
+		if (chan->channel == MT6323_AUXADC_ISENSE ||
+		    chan->channel == MT6323_AUXADC_BATSNS)
+			mult = 4;
+
+		*val = mult * VOLTAGE_FULL_RANGE;
+		*val2 = AUXADC_PRECISE;
+
+		return IIO_VAL_FRACTIONAL;
+	} else
+		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_RSTB_SW | AUXADC_RSTB_SEL);
+	if (ret)
+		return ret;
+
+	ret = regmap_set_bits(map, MT6323_TOP_CKPDN2, AUXADC_CTL_CK);
+	if (ret)
+		return ret;
+
+	ret = regmap_set_bits(map, MT6323_AUXADC_CON10,
+			      AUXADC_TRIM_CH2 | AUXADC_TRIM_CH4 |
+				      AUXADC_TRIM_CH5 | AUXADC_TRIM_CH6);
+	if (ret)
+		return ret;
+
+	ret = regmap_set_bits(map, MT6323_AUXADC_CON27,
+			      AUXADC_VREF18_ENB_MD | AUXADC_MD_STATUS);
+	if (ret)
+		return ret;
+
+	ret = regmap_set_bits(map, MT6323_AUXADC_CON19, AUXADC_GPS_STATUS);
+	if (ret)
+		return ret;
+
+	ret = regmap_set_bits(map, MT6323_AUXADC_CON26,
+			      AUXADC_VREF18_SELB | AUXADC_DECI_GDLY_SEL);
+	if (ret)
+		return ret;
+
+	ret = regmap_update_bits(map, MT6323_AUXADC_CON9, AUXADC_OSR_MASK,
+				 FIELD_PREP(AUXADC_OSR_MASK,
+					    AUXADC_DEFAULT_OSR));
+	return ret;
+}
+
+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 iio_dev *iio;
+	struct regmap *regmap;
+	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 dev_err_probe(dev, ret, "failed to initialize mutex\n");
+
+	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);
+
+	ret = devm_iio_device_register(dev, iio);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to register iio device\n");
+
+	return 0;
+}
+
+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

Re: [PATCH v2 05/16] iio: adc: mediatek: add mt6323 PMIC AUXADC driver

[Andy Shevchenko]

On Tue, May 12, 2026 at 8:21 AM Roman Vivchar via B4 Relay
<devnull+rva333.protonmail.com@kernel.org> wrote:
>
> 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.

...

> +#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/property.h>
> +#include <linux/regmap.h>
> +#include <linux/stringify.h>

+ time.h // USEC_PER_MSEC

> +#include <linux/types.h>

...

> +#define AUXADC_TRIM_CH2                (3 << 10)
> +#define AUXADC_TRIM_CH4                (3 << 8)
> +#define AUXADC_TRIM_CH5                (3 << 4)
> +#define AUXADC_TRIM_CH6                (3 << 2)

Without a comment it's hard to say if these are like masks or actual
values. Can you clarify that in the comment on top of these four?

> +#define VOLTAGE_FULL_RANGE     1800

Are there any units? Are they millivolts or is it just some scale?

...

> +#define MTK_PMIC_IIO_CHAN(_name, _idx, _ch_type)       \
> +{                                                      \
> +       .type = _ch_type,                              \
> +       .indexed = 1,                                  \
> +       .channel = _idx,                               \
> +       .address = _idx,                               \
> +       .datasheet_name = __stringify(_name),          \
> +       .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> +                             BIT(IIO_CHAN_INFO_SCALE) \

Keep the trailing comma as this is not a terminator.

> +}

...

> +/**
> + * struct mt6323_auxadc - Main driver structure
> + * @regmap:        Regmap from PWRAP
> + * @lock:          Mutex to serialize AUXADC reading vs configuration
> + *
> + * The MediaTek MT6323 (as well as lot of other PMICs) have the following hierarchy:
> + * PMIC AUXADC <- PMIC MFD <- SoC PWRAP (wrapper for PWRAP FSM)
> + *
> + * Therefore, PWRAP regmap should be get using dev->parent->parent.

get --> obtained

> + */

...

> +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_DECI_GDLY_MASK))
> +               return 0;
> +
> +       ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19, val,
> +                                      !(val & AUXADC_ADC19_BUSY_MASK), 10, 500);

It's better to have a logical split

       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_DECI_GDLY_MASK);
> +}

...

> +static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
> +                             const struct iio_chan_spec *chan, int *out)
> +{
> +       struct regmap *map = auxadc->regmap;
> +       u32 val, reg = mt6323_auxadc_channel_to_reg(chan->address);
> +       int ret;
> +
> +       ret = regmap_read_poll_timeout(map, reg, val, (val & AUXADC_RDY_MASK),

Parentheses are not needed in this case. But I'm fine with it here as
it probably makes it easier to get the idea.

> +                                      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)

Logical split

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 = 1;

Decouple assignment and definition. These types of assignments are
hard to maintain and might lead to subtle mistakes in the future.

> +       if (mask == IIO_CHAN_INFO_RAW) {
> +               guard(mutex)(&auxadc->lock);
> +               ret = mt6323_auxadc_prepare_channel(auxadc);
> +               if (ret)
> +                       return ret;
> +
> +               ret = mt6323_auxadc_request(auxadc, chan->address);
> +               if (ret)
> +                       return ret;

Please, add a comment with the reference to a datasheet (ideally)
explaining this sleep.

> +               fsleep(300);
> +
> +               ret = mt6323_auxadc_read(auxadc, chan, val);
> +               if (ret)
> +                       return ret;
> +               return IIO_VAL_INT;
> +       } else if (mask == IIO_CHAN_INFO_SCALE) {

Redundant 'else'

> +               if (chan->channel == MT6323_AUXADC_ISENSE ||
> +                   chan->channel == MT6323_AUXADC_BATSNS)
> +                       mult = 4;
> +
> +               *val = mult * VOLTAGE_FULL_RANGE;
> +               *val2 = AUXADC_PRECISE;
> +
> +               return IIO_VAL_FRACTIONAL;

> +       } else

Ditto, and it's the wrong style. Read the Coding Style documentation
to clarify this.

> +               return -EINVAL;
> +}

...

> +       ret = devm_mutex_init(dev, &auxadc->lock);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "failed to initialize mutex\n");

Unneeded error message. Most likely it's -ENOMEM, which will be
ignored by dev_err_probe() anyway.

...

> +       ret = devm_iio_device_register(dev, iio);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "failed to register iio device\n");

If you don't see the device, it's failed to register, do we need this message?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 05/16] iio: adc: mediatek: add mt6323 PMIC AUXADC driver

[Jonathan Cameron]

On Tue, 12 May 2026 08:18:19 +0300
Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:

> 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>
Hi Roman

Various comments inline - mostly naming related.

Jonathan

> diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
> new file mode 100644
> index 000000000000..2c2b495e3d38
> --- /dev/null
> +++ b/drivers/iio/adc/mt6323-auxadc.c
> @@ -0,0 +1,319 @@
> +// 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/property.h>
> +#include <linux/regmap.h>
> +#include <linux/stringify.h>
> +#include <linux/types.h>
> +
> +#include <linux/mfd/mt6397/core.h>
> +#include <linux/mfd/mt6323/registers.h>
> +
> +#include <dt-bindings/iio/adc/mediatek,mt6323-auxadc.h>
> +
> +#define AUXADC_RSTB_SEL		BIT(7)
> +#define AUXADC_RSTB_SW		BIT(5)
> +
> +#define AUXADC_CTL_CK		BIT(5)
> +
> +#define AUXADC_TRIM_CH2		(3 << 10)
> +#define AUXADC_TRIM_CH4		(3 << 8)
> +#define AUXADC_TRIM_CH5		(3 << 4)
> +#define AUXADC_TRIM_CH6		(3 << 2)
> +
> +#define AUXADC_VREF18_ENB_MD	BIT(15)
> +#define AUXADC_MD_STATUS	BIT(0)
> +
> +#define AUXADC_GPS_STATUS	BIT(1)
> +
> +#define AUXADC_VREF18_SELB	BIT(1)
> +#define AUXADC_DECI_GDLY_SEL	BIT(0)
> +
> +#define AUXADC_VBUF_EN		BIT(4)
> +
> +#define AUXADC_DECI_GDLY_MASK		GENMASK(15, 14)
Why you can it is much better to clearly associate a field mask
definition with which register it is in. Lets us quickly spot
if there is a missmatch.

#define AUXADC_CON19_DECI_GDLY_MASK  for example.

THough DECI_GDLY isn't exactly easy to understand as abbreviations
go!

> +#define AUXADC_ADC19_BUSY_MASK		GENMASK(15, 1)
> +#define AUXADC_RDY_MASK			BIT(15)
> +#define AUXADC_DATA_MASK		GENMASK(14, 0)
> +
> +#define AUXADC_OSR_MASK			GENMASK(12, 10)
> +#define AUXADC_DEFAULT_OSR		3
> +
> +#define AUXADC_LOW_CHANNEL_MASK		GENMASK(9, 0)
> +#define AUXADC_AUDIO_CHANNEL_MASK	GENMASK(8, 0)
> +
> +#define VOLTAGE_FULL_RANGE	1800
Probably better to have this inline - however if you do keep it
prefix t he define  VOLTAGE_FULL_RANGE sounds too generic!

> +#define AUXADC_PRECISE		32768
I'd put that inline.  Little benefit it in having it up here...
> +
> +#define MTK_PMIC_IIO_CHAN(_name, _idx, _ch_type)       \
> +{                                                      \
> +	.type = _ch_type,                              \
> +	.indexed = 1,                                  \
> +	.channel = _idx,                               \
> +	.address = _idx,                               \

Why put an index in address?  Seems to me that complicates things
vs putting the relevant register address in there.

> +	.datasheet_name = __stringify(_name),          \
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> +			      BIT(IIO_CHAN_INFO_SCALE) \
> +}
> +
> +static const struct iio_chan_spec mt6323_auxadc_channels[] = {
> +	MTK_PMIC_IIO_CHAN(baton2, MT6323_AUXADC_BATON2, IIO_VOLTAGE),
> +	MTK_PMIC_IIO_CHAN(ch6, MT6323_AUXADC_CH6, IIO_VOLTAGE),
> +	MTK_PMIC_IIO_CHAN(bat_temp, MT6323_AUXADC_BAT_TEMP, IIO_TEMP),
> +	MTK_PMIC_IIO_CHAN(chip_temp, MT6323_AUXADC_CHIP_TEMP, IIO_TEMP),
> +	MTK_PMIC_IIO_CHAN(vcdt, MT6323_AUXADC_VCDT, IIO_VOLTAGE),
> +	MTK_PMIC_IIO_CHAN(baton1, MT6323_AUXADC_BATON1, IIO_VOLTAGE),
> +	MTK_PMIC_IIO_CHAN(isense, MT6323_AUXADC_ISENSE, IIO_VOLTAGE),
> +	MTK_PMIC_IIO_CHAN(batsns, MT6323_AUXADC_BATSNS, IIO_VOLTAGE),
> +	MTK_PMIC_IIO_CHAN(accdet, MT6323_AUXADC_ACCDET, IIO_VOLTAGE),
> +};
> +
> +/**
> + * struct mt6323_auxadc - Main driver structure
> + * @regmap:        Regmap from PWRAP
> + * @lock:          Mutex to serialize AUXADC reading vs configuration
> + *
> + * The MediaTek MT6323 (as well as lot of other PMICs) have the following hierarchy:
> + * PMIC AUXADC <- PMIC MFD <- SoC PWRAP (wrapper for PWRAP FSM)
> + *
> + * Therefore, PWRAP regmap should be get using dev->parent->parent.
> + */
> +struct mt6323_auxadc {
> +	struct regmap *regmap;
> +	struct mutex lock;
> +};
> +
> +static u32 mt6323_auxadc_channel_to_reg(unsigned long channel)
> +{
> +	switch (channel) {
> +	case MT6323_AUXADC_BATON2:
> +		return MT6323_AUXADC_ADC6;

You should put these in chan->address perhaps to avoid
need for a separate lookup function.

> +	case MT6323_AUXADC_CH6:
> +		return MT6323_AUXADC_ADC11;
> +	case MT6323_AUXADC_BAT_TEMP:
> +		return MT6323_AUXADC_ADC5;
> +	case MT6323_AUXADC_CHIP_TEMP:
> +		return MT6323_AUXADC_ADC4;
> +	case MT6323_AUXADC_VCDT:
> +		return MT6323_AUXADC_ADC2;
> +	case MT6323_AUXADC_BATON1:
> +		return MT6323_AUXADC_ADC3;
> +	case MT6323_AUXADC_ISENSE:
> +		return MT6323_AUXADC_ADC1;
> +	case MT6323_AUXADC_BATSNS:
> +		return MT6323_AUXADC_ADC0;
> +	case MT6323_AUXADC_ACCDET:
> +		return MT6323_AUXADC_ADC7;
> +	default:
> +		return MT6323_AUXADC_ADC17;
> +	}
> +}

> +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_VBUF_EN);

As above. I'd like that field name to include which register it is in.
That makes it easier to spot mismatches.

> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
> +	if (ret)
> +		return ret;
> +
> +	return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
> +}
> +
> +static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
> +			      const struct iio_chan_spec *chan, int *out)
> +{
> +	struct regmap *map = auxadc->regmap;
> +	u32 val, reg = mt6323_auxadc_channel_to_reg(chan->address);

Don't mix elements that assign with ones that don't. Doesn't make for easy
to read code.

> +	int ret;
> +
> +	ret = regmap_read_poll_timeout(map, reg, val, (val & AUXADC_RDY_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 = 1;
> +
> +	if (mask == IIO_CHAN_INFO_RAW) {
> +		guard(mutex)(&auxadc->lock);
> +		ret = mt6323_auxadc_prepare_channel(auxadc);
> +		if (ret)
> +			return ret;
> +
> +		ret = mt6323_auxadc_request(auxadc, chan->address);
> +		if (ret)
> +			return ret;
> +
> +		fsleep(300);
> +
> +		ret = mt6323_auxadc_read(auxadc, chan, val);
> +		if (ret)
> +			return ret;
> +		return IIO_VAL_INT;
> +	} else if (mask == IIO_CHAN_INFO_SCALE) {
Andy covered not having the else etc already I think. A switch might
work better though.
> +		if (chan->channel == MT6323_AUXADC_ISENSE ||
> +		    chan->channel == MT6323_AUXADC_BATSNS)
> +			mult = 4;
> +
> +		*val = mult * VOLTAGE_FULL_RANGE;
> +		*val2 = AUXADC_PRECISE;

IIO_VAL_FRACTIONAL_LOG2 probably more appropriate here
(which would be more obvious with the values down here.


> +
> +		return IIO_VAL_FRACTIONAL;
> +	} else
> +		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_RSTB_SW | AUXADC_RSTB_SEL);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_set_bits(map, MT6323_TOP_CKPDN2, AUXADC_CTL_CK);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_set_bits(map, MT6323_AUXADC_CON10,
> +			      AUXADC_TRIM_CH2 | AUXADC_TRIM_CH4 |
> +				      AUXADC_TRIM_CH5 | AUXADC_TRIM_CH6);

	ret = regmap_set_bits(map, MT6323_AUXADC_CON10,
			      AUXADC_TRIM_CH2 | AUXADC_TRIM_CH4 |
			      AUXADC_TRIM_CH5 | AUXADC_TRIM_CH6);
is fine.

> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_set_bits(map, MT6323_AUXADC_CON27,
> +			      AUXADC_VREF18_ENB_MD | AUXADC_MD_STATUS);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_set_bits(map, MT6323_AUXADC_CON19, AUXADC_GPS_STATUS);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_set_bits(map, MT6323_AUXADC_CON26,
> +			      AUXADC_VREF18_SELB | AUXADC_DECI_GDLY_SEL);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_update_bits(map, MT6323_AUXADC_CON9, AUXADC_OSR_MASK,
> +				 FIELD_PREP(AUXADC_OSR_MASK,
> +					    AUXADC_DEFAULT_OSR));
> +	return ret;

Might as well do
	return regmap_update_bits()

> +}

Re: [PATCH v2 05/16] iio: adc: mediatek: add mt6323 PMIC AUXADC driver

[Roman Vivchar]

On Tuesday, May 12th, 2026 at 4:29 PM, Jonathan Cameron <jic23@kernel.org> wrote:

> On Tue, 12 May 2026 08:18:19 +0300
> Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:

...

> > +#define VOLTAGE_FULL_RANGE	1800
> Probably better to have this inline - however if you do keep it
> prefix t he define  VOLTAGE_FULL_RANGE sounds too generic!
> 
> > +#define AUXADC_PRECISE		32768
> I'd put that inline.  Little benefit it in having it up here...

There was a mention about magic values in the v1 for the thermal patch [1].
Andy, would it be better to use an inline style or a #define here?
If the former, I'll rename the first constant to something like
AUXADC_VOLTAGE_FULL_RANGE.

[1]: https://lore.kernel.org/linux-mediatek/afmnUG8dG0N0HpV6@ashevche-desk.local/

Best regards,
Roman

Re: [PATCH v2 05/16] iio: adc: mediatek: add mt6323 PMIC AUXADC driver

[Andy Shevchenko]

On Tue, May 12, 2026 at 02:34:55PM +0000, Roman Vivchar wrote:
> On Tuesday, May 12th, 2026 at 4:29 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> > On Tue, 12 May 2026 08:18:19 +0300
> > Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:

...

> > > +#define VOLTAGE_FULL_RANGE	1800
> > Probably better to have this inline - however if you do keep it
> > prefix t he define  VOLTAGE_FULL_RANGE sounds too generic!
> > 
> > > +#define AUXADC_PRECISE		32768
> > I'd put that inline.  Little benefit it in having it up here...
> 
> There was a mention about magic values in the v1 for the thermal patch [1].
> Andy, would it be better to use an inline style or a #define here?
> If the former, I'll rename the first constant to something like
> AUXADC_VOLTAGE_FULL_RANGE.

If you use it inline, add a comment to explain the magic.
It will be a good compromise.

> [1]: https://lore.kernel.org/linux-mediatek/afmnUG8dG0N0HpV6@ashevche-desk.local/

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 05/16] iio: adc: mediatek: add mt6323 PMIC AUXADC driver

[Jonathan Cameron]

On Tue, 12 May 2026 14:34:55 +0000
Roman Vivchar <rva333@protonmail.com> wrote:

> On Tuesday, May 12th, 2026 at 4:29 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> 
> > On Tue, 12 May 2026 08:18:19 +0300
> > Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:  
> 
> ...
> 
> > > +#define VOLTAGE_FULL_RANGE	1800  
> > Probably better to have this inline - however if you do keep it
> > prefix t he define  VOLTAGE_FULL_RANGE sounds too generic!
> >   
> > > +#define AUXADC_PRECISE		32768  
> > I'd put that inline.  Little benefit it in having it up here...  
> 
> There was a mention about magic values in the v1 for the thermal patch [1].
> Andy, would it be better to use an inline style or a #define here?
> If the former, I'll rename the first constant to something like
> AUXADC_VOLTAGE_FULL_RANGE.
FWIW that isn't a magic value - it's 2**resolution and the one is  a voltage
in mV.  Those aren't normally the ones people care about defines for - those
apply when they are weird and wonderful things not related directly to physical
quantities.

Jonathan
> 
> [1]: https://lore.kernel.org/linux-mediatek/afmnUG8dG0N0HpV6@ashevche-desk.local/
> 
> Best regards,
> Roman

[PATCH v2 06/16] nvmem: add mt6323 PMIC EFUSE driver

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

Add support for the EFUSE controller found in the Mediatek MT6323 PMIC.
The MT6323 EFUSE stores 24 bytes of hardware-related data, such as
thermal sensor calibration values.

Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
 drivers/nvmem/Kconfig        | 11 ++++++
 drivers/nvmem/Makefile       |  2 ++
 drivers/nvmem/mt6323-efuse.c | 86 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 99 insertions(+)

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..db248a3c4e87 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -227,6 +227,17 @@ config NVMEM_MTK_EFUSE
 	  This driver can also be built as a module. If so, the module
 	  will be called efuse-mtk.
 
+config NVMEM_MT6323_EFUSE
+	tristate "Mediatek MT6323 PMIC EFUSE support"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	depends on MFD_MT6397
+	help
+	  This is a driver to access hardware related data like sensor
+	  calibration, etc.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called efuse-mt6323.
+
 config NVMEM_MXS_OCOTP
 	tristate "Freescale MXS On-Chip OTP Memory Support"
 	depends on ARCH_MXS || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d4..0e2b73f42b25 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -48,6 +48,8 @@ obj-$(CONFIG_NVMEM_MICROCHIP_OTPC)	+= nvmem-microchip-otpc.o
 nvmem-microchip-otpc-y			:= microchip-otpc.o
 obj-$(CONFIG_NVMEM_MTK_EFUSE)		+= nvmem_mtk-efuse.o
 nvmem_mtk-efuse-y			:= mtk-efuse.o
+obj-$(CONFIG_NVMEM_MT6323_EFUSE)		+= nvmem_mt6323-efuse.o
+nvmem_mt6323-efuse-y			:= mt6323-efuse.o
 obj-$(CONFIG_NVMEM_MXS_OCOTP)		+= nvmem-mxs-ocotp.o
 nvmem-mxs-ocotp-y			:= mxs-ocotp.o
 obj-$(CONFIG_NVMEM_NINTENDO_OTP)	+= nvmem-nintendo-otp.o
diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
new file mode 100644
index 000000000000..52db62784add
--- /dev/null
+++ b/drivers/nvmem/mt6323-efuse.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2026 Roman Vivchar <rva333@protonmail.com>
+ */
+
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+#include <linux/mfd/mt6323/registers.h>
+
+#define MT6323_EFUSE_DOUT_BASE	MT6323_EFUSE_DOUT_0_15
+#define MT6323_EFUSE_SIZE	24
+
+static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
+			     size_t bytes)
+{
+	struct regmap *map = context;
+	u32 tmp;
+	u16 *buf = val;
+	int ret;
+
+	/*
+	 * Manual regmap_read with loop is needed, because PWRAP is not
+	 * a continuous MMIO space, but rather FSM which doesn't implement
+	 * necessary read callback for the regmap_read_raw and regmap_read_bulk
+	 * functions.
+	 */
+	for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
+		ret = regmap_read(map, MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
+		if (ret)
+			return ret;
+
+		*buf++ = (u16)tmp;
+	}
+
+	return 0;
+}
+
+static int mt6323_efuse_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct nvmem_config config = {
+		.name = "mt6323-efuse",
+		.stride = 2,
+		.word_size = 2,
+		.size = MT6323_EFUSE_SIZE,
+		.reg_read = mt6323_efuse_read,
+	};
+	struct nvmem_device *nvmem;
+	struct regmap *regmap;
+
+	/* efuse -> mfd -> pwrap */
+	regmap = dev_get_regmap(dev->parent->parent, NULL);
+	if (!regmap)
+		return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
+
+	config.dev = dev;
+	config.priv = regmap;
+
+	nvmem = devm_nvmem_register(dev, &config);
+	return PTR_ERR_OR_ZERO(nvmem);
+}
+
+static const struct of_device_id mt6323_efuse_of_match[] = {
+	{ .compatible = "mediatek,mt6323-efuse" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, mt6323_efuse_of_match);
+
+static struct platform_driver mt6323_efuse_driver = {
+	.probe = mt6323_efuse_probe,
+	.driver = {
+		.name = "mt6323-efuse",
+		.of_match_table = mt6323_efuse_of_match,
+	},
+};
+module_platform_driver(mt6323_efuse_driver);
+
+MODULE_DESCRIPTION("Mediatek MT6323 PMIC EFUSE driver");
+MODULE_LICENSE("GPL");

-- 
2.54.0

Re: [PATCH v2 06/16] nvmem: add mt6323 PMIC EFUSE driver

[Andy Shevchenko]

On Tue, May 12, 2026 at 8:21 AM Roman Vivchar via B4 Relay
<devnull+rva333.protonmail.com@kernel.org> wrote:
>
> Add support for the EFUSE controller found in the Mediatek MT6323 PMIC.
> The MT6323 EFUSE stores 24 bytes of hardware-related data, such as
> thermal sensor calibration values.

...

> +#include <linux/err.h>

> +#include <linux/errno.h>

Doesn't seem to be used as err.h implies asm/errno.h that provides
basic error codes.

> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/types.h>

...

> +static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
> +                            size_t bytes)
> +{
> +       struct regmap *map = context;
> +       u32 tmp;
> +       u16 *buf = val;
> +       int ret;
> +
> +       /*
> +        * Manual regmap_read with loop is needed, because PWRAP is not
> +        * a continuous MMIO space, but rather FSM which doesn't implement
> +        * necessary read callback for the regmap_read_raw and regmap_read_bulk
> +        * functions.
> +        */
> +       for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
> +               ret = regmap_read(map, MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
> +               if (ret)
> +                       return ret;

> +               *buf++ = (u16)tmp;

Why explicit casting?

> +       }
> +
> +       return 0;
> +}

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 07/16] thermal: mediatek: add PMIC thermal support

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

Add a new driver to support thermal monitoring on MediaTek PMICs.

The driver retrieves calibration data from EFUSE, calculates the
temperature using a linear interpolation, and registers the device with
the thermal framework.

Initial support is added for the mt6323 PMIC.

Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
 drivers/thermal/mediatek/Kconfig            |  12 ++
 drivers/thermal/mediatek/Makefile           |   1 +
 drivers/thermal/mediatek/mtk_pmic_thermal.c | 316 ++++++++++++++++++++++++++++
 3 files changed, 329 insertions(+)

diff --git a/drivers/thermal/mediatek/Kconfig b/drivers/thermal/mediatek/Kconfig
index d82c86d9be56..8320d109fde6 100644
--- a/drivers/thermal/mediatek/Kconfig
+++ b/drivers/thermal/mediatek/Kconfig
@@ -34,4 +34,16 @@ config MTK_LVTS_THERMAL_DEBUGFS
        help
          Enable this option to debug the internals of the device driver.
 
+config MTK_PMIC_THERMAL
+	tristate "AUXADC temperature sensor driver for MediaTek PMICs"
+	depends on MFD_MT6397
+	help
+	  Enable this option if you want to get PMIC temperature
+	  information for MediaTek platforms.
+	  This driver configures thermal controllers to collect
+	  temperature via AUXADC interface.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called mtk_pmic_thermal.
+
 endif
diff --git a/drivers/thermal/mediatek/Makefile b/drivers/thermal/mediatek/Makefile
index 1c6daa1e644b..bfb3b6f02539 100644
--- a/drivers/thermal/mediatek/Makefile
+++ b/drivers/thermal/mediatek/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_MTK_SOC_THERMAL)	+= auxadc_thermal.o
 obj-$(CONFIG_MTK_LVTS_THERMAL)	+= lvts_thermal.o
+obj-$(CONFIG_MTK_PMIC_THERMAL)	+= mtk_pmic_thermal.o
diff --git a/drivers/thermal/mediatek/mtk_pmic_thermal.c b/drivers/thermal/mediatek/mtk_pmic_thermal.c
new file mode 100644
index 000000000000..f644dad15fc2
--- /dev/null
+++ b/drivers/thermal/mediatek/mtk_pmic_thermal.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Roman Vivchar <rva333@protonmail.com>
+ *
+ * Based on drivers/thermal/mediatek/auxadc_thermal.c
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/cleanup.h>
+#include <linux/err.h>
+#include <linux/iio/consumer.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/thermal.h>
+#include <linux/units.h>
+
+#include <linux/mfd/mt6323/registers.h>
+
+#define MAX_SENSORS			1
+
+#define MT6323_TEMP_MIN			(-20 * MILLIDEGREE_PER_DEGREE)
+#define MT6323_TEMP_MAX			(50 * MILLIDEGREE_PER_DEGREE)
+
+/* Layout of the fuses providing the calibration data */
+#define CALIB_BUF0_VTS_MASK		GENMASK(15, 8)
+#define CALIB_BUF0_DEGC_CALI_MASK	GENMASK(7, 2)
+#define CALIB_BUF0_ADC_CALI_EN_MASK	BIT(1)
+
+#define CALIB_BUF1_ID_20_MASK		BIT(14)
+#define CALIB_BUF1_ID_10_MASK		BIT(12)
+#define CALIB_BUF1_O_SLOPE_20_HI	GENMASK(13, 11)
+#define CALIB_BUF1_O_SLOPE_20_LO	GENMASK(8, 6)
+#define CALIB_BUF1_O_SLOPE_10_MASK	GENMASK(11, 6)
+#define CALIB_BUF1_O_SLOPE_SIGN_MASK	BIT(5)
+#define CALIB_BUF1_VTS_MASK		GENMASK(4, 0)
+
+#define MT6323_CALIBRATION		171
+#define MT6323_ADC_VOLTAGE_RANGE	1800
+#define MT6323_ADC_RESOLUTION		32768
+#define MT6323_ADC_VBE_OFFSET		9102
+
+#define MT6323_DEFAULT_VTS		3698
+#define MT6323_DEFAULT_DEGC_CALI	50
+#define MT6323_DEFAULT_SLOPE		0
+#define MT6323_DEFAULT_SLOPE_SIGN	0
+
+struct mtk_pmic_thermal;
+
+struct mtk_thermal_data {
+	const char *const *sensors;
+	s32 num_sensors;
+
+	int (*extract_efuse)(struct mtk_pmic_thermal *mt, u16 *buf);
+	void (*precalc)(struct mtk_pmic_thermal *mt, s32 vts, s32 degc_cali,
+			s32 o_slope, s32 o_slope_sign);
+};
+
+struct mtk_pmic_sensor {
+	struct mtk_pmic_thermal *mt;
+	struct iio_channel *adc_channel;
+	struct thermal_zone_device *tzdev;
+
+	int id;
+};
+
+struct mtk_pmic_thermal {
+	struct device *dev;
+	struct regmap *regmap;
+	const struct mtk_thermal_data *data;
+
+	struct mtk_pmic_sensor sensors[MAX_SENSORS];
+
+	s32 t_slope1;
+	s32 t_slope2;
+	s32 t_intercept;
+};
+
+static bool mtk_pmic_thermal_temp_is_valid(int temp)
+{
+	return (temp >= MT6323_TEMP_MIN) && (temp <= MT6323_TEMP_MAX);
+}
+
+static int mtk_pmic_read_temp(struct thermal_zone_device *tz, int *temperature)
+{
+	struct mtk_pmic_sensor *sensor = thermal_zone_device_priv(tz);
+	int ret, raw, temp;
+
+	ret = iio_read_channel_processed(sensor->adc_channel, &raw);
+	if (ret < 0) {
+		dev_err(sensor->mt->dev, "failed to read iio channel: %d\n",
+			ret);
+		return ret;
+	}
+
+	/*
+	 *                 slope1 * V
+	 * t = Intercept + ----------
+	 *                   slope2
+	 */
+	temp = sensor->mt->t_intercept +
+	       (sensor->mt->t_slope1 * raw) / sensor->mt->t_slope2;
+
+	if (!mtk_pmic_thermal_temp_is_valid(temp))
+		return -EINVAL;
+
+	*temperature = temp;
+	return 0;
+}
+
+static const struct thermal_zone_device_ops mtk_pmic_thermal_ops = {
+	.get_temp = mtk_pmic_read_temp,
+};
+
+static void mtk_pmic_thermal_precalc_mt6323(struct mtk_pmic_thermal *mt,
+					    s32 vts, s32 degc_cali, s32 o_slope,
+					    s32 o_slope_sign)
+{
+	s32 vbe_t;
+
+	mt->t_slope1 = 100 * MILLIDEGREE_PER_DEGREE;
+
+	/*
+	 * Temperature coefficient. The o_slope is a trim value applied to
+	 * the base calibration
+	 */
+	if (o_slope_sign == 0)
+		mt->t_slope2 = -(MT6323_CALIBRATION + o_slope);
+	else
+		mt->t_slope2 = -(MT6323_CALIBRATION - o_slope);
+
+	/*
+	 *                 (Vraw + offset) * Vref
+	 * Vbe (mV) = -1 * ---------------------- * 1000
+	 *                      adc_resolution
+	 */
+	vbe_t = (vts + MT6323_ADC_VBE_OFFSET) * MT6323_ADC_VOLTAGE_RANGE;
+	vbe_t = -1 * (vbe_t / MT6323_ADC_RESOLUTION) * MILLIDEGREE_PER_DEGREE;
+
+	/* Intercept adjusts minimal temperature margin with degc_cali offset */
+	mt->t_intercept = vbe_t * 100 / mt->t_slope2;
+	mt->t_intercept += degc_cali * MILLIDEGREE_PER_DEGREE / 2;
+}
+
+static int mtk_pmic_thermal_extract_efuse_mt6323(struct mtk_pmic_thermal *mt,
+						 u16 *buf)
+{
+	u32 reg;
+	s32 vts, degc_cali, o_slope, o_slope_sign, id;
+	int ret;
+
+	if (!FIELD_GET(CALIB_BUF0_ADC_CALI_EN_MASK, buf[0]))
+		return -EINVAL;
+
+	/* Voltage offset */
+	vts = (FIELD_GET(CALIB_BUF1_VTS_MASK, buf[1]) << 8) |
+	      FIELD_GET(CALIB_BUF0_VTS_MASK, buf[0]);
+
+	/* Reference temperature for the vts */
+	degc_cali = FIELD_GET(CALIB_BUF0_DEGC_CALI_MASK, buf[0]);
+
+	o_slope_sign = FIELD_GET(CALIB_BUF1_O_SLOPE_SIGN_MASK, buf[1]);
+
+	ret = regmap_read(mt->regmap, MT6323_CID, &reg);
+	if (ret) {
+		dev_err(mt->dev, "failed to read chip id\n");
+		return ret;
+	}
+
+	if (reg == 0x1023) {
+		o_slope = FIELD_GET(CALIB_BUF1_O_SLOPE_10_MASK, buf[1]);
+		id = FIELD_GET(CALIB_BUF1_ID_10_MASK, buf[1]);
+	} else if (reg == 0x2023) {
+		o_slope = (FIELD_GET(CALIB_BUF1_O_SLOPE_20_HI, buf[1]) << 3) |
+			  FIELD_GET(CALIB_BUF1_O_SLOPE_20_LO, buf[1]);
+		id = FIELD_GET(CALIB_BUF1_ID_20_MASK, buf[1]);
+	} else {
+		dev_err(mt->dev, "invalid chip id: 0x%x\n", reg);
+		return -EINVAL;
+	}
+
+	if (id == 0)
+		o_slope = 0;
+
+	mt->data->precalc(mt, vts, degc_cali, o_slope, o_slope_sign);
+
+	return 0;
+}
+
+static int mtk_pmic_thermal_get_calib_data(struct device *dev,
+					   struct mtk_pmic_thermal *mt)
+{
+	void *buf __free(kfree) = NULL;
+	struct nvmem_cell *cell;
+	size_t len;
+	int ret;
+
+	cell = nvmem_cell_get(dev, NULL);
+	if (IS_ERR(cell))
+		return PTR_ERR(cell);
+
+	buf = nvmem_cell_read(cell, &len);
+	nvmem_cell_put(cell);
+
+	if (IS_ERR(buf)) {
+		ret = PTR_ERR(buf);
+		buf = NULL;
+		return ret;
+	}
+
+	if (len < 2 * sizeof(u16)) {
+		dev_err(dev, "invalid calibration data length\n");
+		return -EINVAL;
+	}
+
+	ret = mt->data->extract_efuse(mt, buf);
+	if (ret) {
+		dev_info(dev, "device not calibrated, using default values\n");
+		mt->data->precalc(mt, MT6323_DEFAULT_VTS,
+				  MT6323_DEFAULT_DEGC_CALI,
+				  MT6323_DEFAULT_SLOPE,
+				  MT6323_DEFAULT_SLOPE_SIGN);
+	}
+
+	return 0;
+}
+
+static int mtk_pmic_thermal_init_sensor(struct mtk_pmic_thermal *mt, int id)
+{
+	struct mtk_pmic_sensor *sensor = &mt->sensors[id];
+	struct device *dev = mt->dev;
+
+	sensor->id = id;
+	sensor->mt = mt;
+
+	if (mt->data->num_sensors > 1)
+		sensor->adc_channel = devm_iio_channel_get(dev, mt->data->sensors[id]);
+	else
+		sensor->adc_channel = devm_iio_channel_get(dev, NULL);
+
+	if (IS_ERR(sensor->adc_channel))
+		return dev_err_probe(dev, PTR_ERR(sensor->adc_channel),
+				     "failed to get channel %s\n",
+				     mt->data->sensors[id]);
+
+	sensor->tzdev = devm_thermal_of_zone_register(dev, id, sensor,
+						      &mtk_pmic_thermal_ops);
+	if (IS_ERR(sensor->tzdev))
+		return dev_err_probe(dev, PTR_ERR(sensor->tzdev),
+				     "failed to register thermal zone %d\n", id);
+
+	return 0;
+}
+
+static int mtk_pmic_thermal_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_pmic_thermal *mt;
+	int ret;
+
+	mt = devm_kzalloc(dev, sizeof(*mt), GFP_KERNEL);
+	if (!mt)
+		return -ENOMEM;
+
+	mt->regmap = dev_get_regmap(dev->parent->parent, NULL);
+	if (!mt->regmap)
+		return dev_err_probe(dev, -ENODEV, "failed to get regmap");
+
+	mt->dev = dev;
+	mt->data = device_get_match_data(dev);
+
+	ret = mtk_pmic_thermal_get_calib_data(dev, mt);
+	if (ret)
+		return ret;
+
+	for (int i = 0; i < mt->data->num_sensors; i++) {
+		ret = mtk_pmic_thermal_init_sensor(mt, i);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static const char *const mt6323_adc_channels[] = { "vts" };
+
+static const struct mtk_thermal_data mt6323_thermal_data = {
+	.sensors = mt6323_adc_channels,
+	.num_sensors = ARRAY_SIZE(mt6323_adc_channels),
+	.extract_efuse = mtk_pmic_thermal_extract_efuse_mt6323,
+	.precalc = mtk_pmic_thermal_precalc_mt6323,
+};
+
+static const struct of_device_id mtk_pmic_thermal_of_match[] = {
+	{ .compatible = "mediatek,mt6323-thermal",
+	  .data = &mt6323_thermal_data },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mtk_pmic_thermal_of_match);
+
+static struct platform_driver mtk_pmic_thermal_driver = {
+	.probe = mtk_pmic_thermal_probe,
+	.driver = {
+		.name = "mtk-pmic-thermal",
+		.of_match_table = mtk_pmic_thermal_of_match,
+	},
+};
+module_platform_driver(mtk_pmic_thermal_driver);
+
+MODULE_DESCRIPTION("MediaTek PMIC thermal driver");
+MODULE_LICENSE("GPL");

-- 
2.54.0

Re: [PATCH v2 07/16] thermal: mediatek: add PMIC thermal support

[Andy Shevchenko]

On Tue, May 12, 2026 at 8:21 AM Roman Vivchar via B4 Relay
<devnull+rva333.protonmail.com@kernel.org> wrote:
>
> Add a new driver to support thermal monitoring on MediaTek PMICs.
>
> The driver retrieves calibration data from EFUSE, calculates the
> temperature using a linear interpolation, and registers the device with
> the thermal framework.
>
> Initial support is added for the mt6323 PMIC.

...

+ array_size.h

> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/cleanup.h>
> +#include <linux/err.h>
> +#include <linux/iio/consumer.h>

> +#include <linux/kernel.h>

No way the driver(s) nowadays use this header. Please, drop it and add
the ones that are really in use (there are missing ones).

> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/regmap.h>

> +#include <linux/slab.h>

Is it used?

> +#include <linux/thermal.h>

Missing types.h

> +#include <linux/units.h>

...

> +#define MT6323_ADC_VOLTAGE_RANGE       1800
> +#define MT6323_ADC_RESOLUTION          32768

These two ring a bell with the first code patch. Are they the same?
Can they be deduplicated?

...

> +       ret = iio_read_channel_processed(sensor->adc_channel, &raw);
> +       if (ret < 0) {

Do we need that ' < 0' part? What is the meaning of positive returned
value (if any) and why do we ignore that? Same question to all similar
checks in the whole series.

> +               dev_err(sensor->mt->dev, "failed to read iio channel: %d\n",
> +                       ret);
> +               return ret;
> +       }

...

> +       /*
> +        * Temperature coefficient. The o_slope is a trim value applied to
> +        * the base calibration

Respect English grammar and punctuation. Here is the period missing.

> +        */

...

> +static int mtk_pmic_thermal_extract_efuse_mt6323(struct mtk_pmic_thermal *mt,
> +                                                u16 *buf)
> +{
> +       u32 reg;
> +       s32 vts, degc_cali, o_slope, o_slope_sign, id;
> +       int ret;

Better to keep reversed xmas tree order.

> +       return 0;
> +}

...

> +static int mtk_pmic_thermal_get_calib_data(struct device *dev,
> +                                          struct mtk_pmic_thermal *mt)
> +{

> +       void *buf __free(kfree) = NULL;

This is a discouraged way of defining variables with __free(). See below.

> +       struct nvmem_cell *cell;
> +       size_t len;
> +       int ret;
> +
> +       cell = nvmem_cell_get(dev, NULL);
> +       if (IS_ERR(cell))
> +               return PTR_ERR(cell);

> +       buf = nvmem_cell_read(cell, &len);

Should be rather here

       void *buf __free(kfree) = nvmem_cell_read(cell, &len);

> +       nvmem_cell_put(cell);
> +
> +       if (IS_ERR(buf)) {
> +               ret = PTR_ERR(buf);
> +               buf = NULL;
> +               return ret;
> +       }
> +
> +       if (len < 2 * sizeof(u16)) {
> +               dev_err(dev, "invalid calibration data length\n");
> +               return -EINVAL;

return dev_err_probe(...);

> +       }
> +
> +       ret = mt->data->extract_efuse(mt, buf);
> +       if (ret) {
> +               dev_info(dev, "device not calibrated, using default values\n");
> +               mt->data->precalc(mt, MT6323_DEFAULT_VTS,
> +                                 MT6323_DEFAULT_DEGC_CALI,
> +                                 MT6323_DEFAULT_SLOPE,
> +                                 MT6323_DEFAULT_SLOPE_SIGN);
> +       }
> +
> +       return 0;
> +}
> +
> +static int mtk_pmic_thermal_init_sensor(struct mtk_pmic_thermal *mt, int id)
> +{
> +       struct mtk_pmic_sensor *sensor = &mt->sensors[id];
> +       struct device *dev = mt->dev;
> +
> +       sensor->id = id;
> +       sensor->mt = mt;
> +
> +       if (mt->data->num_sensors > 1)
> +               sensor->adc_channel = devm_iio_channel_get(dev, mt->data->sensors[id]);
> +       else
> +               sensor->adc_channel = devm_iio_channel_get(dev, NULL);

> +

Unneeded blank line as the above and below are coupled semantically.

> +       if (IS_ERR(sensor->adc_channel))
> +               return dev_err_probe(dev, PTR_ERR(sensor->adc_channel),
> +                                    "failed to get channel %s\n",
> +                                    mt->data->sensors[id]);
> +
> +       sensor->tzdev = devm_thermal_of_zone_register(dev, id, sensor,
> +                                                     &mtk_pmic_thermal_ops);
> +       if (IS_ERR(sensor->tzdev))
> +               return dev_err_probe(dev, PTR_ERR(sensor->tzdev),
> +                                    "failed to register thermal zone %d\n", id);
> +
> +       return 0;
> +}

...

> +static const struct of_device_id mtk_pmic_thermal_of_match[] = {
> +       { .compatible = "mediatek,mt6323-thermal",
> +         .data = &mt6323_thermal_data },
> +       { /* sentinel */ },

No comma for the terminator entry.

> +};

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 07/16] thermal: mediatek: add PMIC thermal support

[Roman Vivchar]

On Tuesday, May 12th, 2026 at 10:05 AM, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Tue, May 12, 2026 at 8:21 AM Roman Vivchar via B4 Relay
> <devnull+rva333.protonmail.com@kernel.org> wrote:

...

> > +#include <linux/kernel.h>
>
> No way the driver(s) nowadays use this header. Please, drop it and add
> the ones that are really in use (there are missing ones).

Is there a tool or script that can check for IWYU? For example,
the u32 and s32 types are defined in the asm-generic/int-ll64.h, which
is not used by any device driver. Instead, types.h should be used.
It's difficult to guess which header to use for a given type/function.

I've tried include-what-you-use [1], but it gives bad results like
"add #include <asm-generic/int-ll64.h> // for u32".

> > +#include <linux/module.h>
> > +#include <linux/nvmem-consumer.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/property.h>
> > +#include <linux/regmap.h>
>
> > +#include <linux/slab.h>
>
> Is it used?

Yes, without slab.h the __free would complain about missing __free_kfree,
which is DEFINE_FREE(kfree, void *, if (!IS_ERR_OR_NULL(_T)) kfree(_T)).

...

> > +#define MT6323_ADC_VOLTAGE_RANGE       1800
> > +#define MT6323_ADC_RESOLUTION          32768
>
> These two ring a bell with the first code patch. Are they the same?
> Can they be deduplicated?

They can, but I doubt it's worth creating a header just for 2 constants.
It would look too small compared to the other headers in the include/linux/iio/adc.

1: https://github.com/include-what-you-use/include-what-you-use

Best regards,
Roman

Re: [PATCH v2 07/16] thermal: mediatek: add PMIC thermal support

[Andy Shevchenko]

On Tue, May 12, 2026 at 08:55:44AM +0000, Roman Vivchar wrote:
> On Tuesday, May 12th, 2026 at 10:05 AM, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Tue, May 12, 2026 at 8:21 AM Roman Vivchar via B4 Relay
> > <devnull+rva333.protonmail.com@kernel.org> wrote:

...

> > > +#include <linux/kernel.h>
> >
> > No way the driver(s) nowadays use this header. Please, drop it and add
> > the ones that are really in use (there are missing ones).
> 
> Is there a tool or script that can check for IWYU?

The `iwyu` tool with customised configuration is the closest what we have
(but quite far from ideal), you can read this thread [2].

> For example,
> the u32 and s32 types are defined in the asm-generic/int-ll64.h, which
> is not used by any device driver. Instead, types.h should be used.
> It's difficult to guess which header to use for a given type/function.

I know. I got this knowledge because:
- I do a lot of reviews and patches and gathered it from the experience
- I am the one who reshuffled *some* of the headers

> I've tried include-what-you-use [1], but it gives bad results like
> "add #include <asm-generic/int-ll64.h> // for u32".

See above.

> > > +#include <linux/module.h>
> > > +#include <linux/nvmem-consumer.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/property.h>
> > > +#include <linux/regmap.h>
> >
> > > +#include <linux/slab.h>
> >
> > Is it used?
> 
> Yes, without slab.h the __free would complain about missing __free_kfree,
> which is DEFINE_FREE(kfree, void *, if (!IS_ERR_OR_NULL(_T)) kfree(_T)).

Ah, indeed. I forgot that this is not the part of cleanup.h.

...

> 1: https://github.com/include-what-you-use/include-what-you-use
[2]: https://lore.kernel.org/all/20260512073505.1310-1-joshua.crofts1@gmail.com/

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 07/16] thermal: mediatek: add PMIC thermal support

[Jonathan Cameron]

On Tue, 12 May 2026 14:02:50 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Tue, May 12, 2026 at 08:55:44AM +0000, Roman Vivchar wrote:
> > On Tuesday, May 12th, 2026 at 10:05 AM, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:  
> > > On Tue, May 12, 2026 at 8:21 AM Roman Vivchar via B4 Relay
> > > <devnull+rva333.protonmail.com@kernel.org> wrote:  
> 
> ...
> 
> > > > +#include <linux/kernel.h>  
> > >
> > > No way the driver(s) nowadays use this header. Please, drop it and add
> > > the ones that are really in use (there are missing ones).  
> > 
> > Is there a tool or script that can check for IWYU?  
> 
> The `iwyu` tool with customised configuration is the closest what we have
> (but quite far from ideal), you can read this thread [2].

For what it is worth the various AI tools don't do badly if you ask
them and Sasiko often comments on this now (running on all of linux-iio)
This series is pending though - might be done tomorrow:
https://sashiko.dev/#/patchset/20260512-mt6323-v2-0-3efcba579e88%40protonmail.com

> 
> > For example,
> > the u32 and s32 types are defined in the asm-generic/int-ll64.h, which
> > is not used by any device driver. Instead, types.h should be used.
> > It's difficult to guess which header to use for a given type/function.  
> 
> I know. I got this knowledge because:
> - I do a lot of reviews and patches and gathered it from the experience
> - I am the one who reshuffled *some* of the headers
> 
> > I've tried include-what-you-use [1], but it gives bad results like
> > "add #include <asm-generic/int-ll64.h> // for u32".  
> 
> See above.
> 
> > > > +#include <linux/module.h>
> > > > +#include <linux/nvmem-consumer.h>
> > > > +#include <linux/platform_device.h>
> > > > +#include <linux/property.h>
> > > > +#include <linux/regmap.h>  
> > >  
> > > > +#include <linux/slab.h>  
> > >
> > > Is it used?  
> > 
> > Yes, without slab.h the __free would complain about missing __free_kfree,
> > which is DEFINE_FREE(kfree, void *, if (!IS_ERR_OR_NULL(_T)) kfree(_T)).  
> 
> Ah, indeed. I forgot that this is not the part of cleanup.h.
> 
> ...
> 
> > 1: https://github.com/include-what-you-use/include-what-you-use  
> [2]: https://lore.kernel.org/all/20260512073505.1310-1-joshua.crofts1@gmail.com/
> 

[PATCH v2 08/16] mfd: mt6397-core: add mt6323 AUXADC support

[Roman Vivchar via B4 Relay]

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

[PATCH v2 09/16] mfd: mt6397-core: add mt6323 EFUSE support

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

The mt6323 PMIC includes an EFUSE. Register the EFUSE 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 013b0857fb54..2d9419b80a5c 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -127,6 +127,9 @@ static const struct mfd_cell mt6323_devs[] = {
 	{
 		.name = "mt6323-auxadc",
 		.of_compatible = "mediatek,mt6323-auxadc",
+	}, {
+		.name = "mt6323-efuse",
+		.of_compatible = "mediatek,mt6323-efuse",
 	}, {
 		.name = "mt6323-rtc",
 		.num_resources = ARRAY_SIZE(mt6323_rtc_resources),

-- 
2.54.0

[PATCH v2 10/16] mfd: mt6397-core: add mt6323 thermal support

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

The mt6323 PMIC temperature can be measured using AUXADC channel.
Register the thermal 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 2d9419b80a5c..061ac242f1f8 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -151,6 +151,9 @@ static const struct mfd_cell mt6323_devs[] = {
 		.num_resources = ARRAY_SIZE(mt6323_pwrc_resources),
 		.resources = mt6323_pwrc_resources,
 		.of_compatible = "mediatek,mt6323-pwrc"
+	}, {
+		.name = "mt6323-thermal",
+		.of_compatible = "mediatek,mt6323-thermal",
 	},
 };
 

-- 
2.54.0

Re: [PATCH v2 10/16] mfd: mt6397-core: add mt6323 thermal support

[Andy Shevchenko]

On Tue, May 12, 2026 at 8:21 AM Roman Vivchar via B4 Relay
<devnull+rva333.protonmail.com@kernel.org> wrote:
>
> The mt6323 PMIC temperature can be measured using AUXADC channel.
> Register the thermal in the mt6323 devices array to allow the
> corresponding driver to probe using compatible string.

Wouldn't it be better to interleave these MFD patches to enable each
driver just immediately after the driver provided? However, in
previous review somebody ( IIRC it was Krzysztof) asked how dependent
are they and it has something to do with the device tree bindings.
Take into account that one as well.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 11/16] ARM: dts: mediatek: mt6323: add AUXADC support

[Roman Vivchar via B4 Relay]

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

[PATCH v2 12/16] ARM: dts: mediatek: mt6323: add EFUSE support

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

Add the efuse node for the mt6323 efuse.

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 | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index c070f4b0936c..435936b477fa 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -19,6 +19,10 @@ mt6323_adc: adc {
 			#io-channel-cells = <1>;
 		};
 
+		mt6323_efuse: efuse {
+			compatible = "mediatek,mt6323-efuse";
+		};
+
 		mt6323_leds: leds {
 			compatible = "mediatek,mt6323-led";
 			#address-cells = <1>;

-- 
2.54.0

[PATCH v2 13/16] ARM: dts: mediatek: mt6323: add thermal support

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

Add the devicetree node for the mt6323 thermal.

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 | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index 435936b477fa..9825e15ab4e4 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -6,6 +6,8 @@
  *
  */
 
+#include <dt-bindings/iio/adc/mediatek,mt6323-auxadc.h>
+
 &pwrap {
 	pmic: mt6323 {
 		compatible = "mediatek,mt6323";
@@ -21,6 +23,16 @@ mt6323_adc: adc {
 
 		mt6323_efuse: efuse {
 			compatible = "mediatek,mt6323-efuse";
+
+			nvmem-layout {
+				compatible = "fixed-layout";
+				#address-cells = <1>;
+				#size-cells = <1>;
+
+				mt6323_thermal_calibration_data: thermal-data@14 {
+					reg = <0x14 0x4>;
+				};
+			};
 		};
 
 		mt6323_leds: leds {
@@ -274,5 +286,24 @@ power-controller {
 		rtc {
 			compatible = "mediatek,mt6323-rtc";
 		};
+
+		mt6323_thermal: thermal {
+			compatible = "mediatek,mt6323-thermal";
+			nvmem-cells = <&mt6323_thermal_calibration_data>;
+
+			io-channels = <&mt6323_adc MT6323_AUXADC_CHIP_TEMP>;
+			#thermal-sensor-cells = <1>;
+		};
+	};
+};
+
+/ {
+	thermal-zones {
+		pmic_vts_thermal {
+			polling-delay-passive = <1000>;
+			polling-delay = <1000>;
+
+			thermal-sensors = <&mt6323_thermal 0>;
+		};
 	};
 };

-- 
2.54.0

[PATCH v2 14/16] MAINTAINERS: add MediaTek mt6323 PMIC AUXADC driver maintainer

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

Add myself as MediaTek mt6323 AUXADC driver maintainer.

Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..52249c301633 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16337,6 +16337,11 @@ S:	Orphan
 F:	Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml
 F:	drivers/mtd/nand/raw/mtk_*
 
+MEDIATEK PMIC AUXADC DRIVER
+M:	Roman Vivchar <rva333@protonmail.com>
+S:	Odd Fixes
+F:	drivers/iio/adc/mt6323-auxadc.c
+
 MEDIATEK PMIC LED DRIVER
 M:	Sen Chu <sen.chu@mediatek.com>
 M:	Sean Wang <sean.wang@mediatek.com>

-- 
2.54.0

Re: [PATCH v2 14/16] MAINTAINERS: add MediaTek mt6323 PMIC AUXADC driver maintainer

[Jonathan Cameron]

On Tue, 12 May 2026 08:18:28 +0300
Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:

> From: Roman Vivchar <rva333@protonmail.com>
> 
> Add myself as MediaTek mt6323 AUXADC driver maintainer.
> 
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
>  MAINTAINERS | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d1cc0e12fe1f..52249c301633 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16337,6 +16337,11 @@ S:	Orphan
>  F:	Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml
>  F:	drivers/mtd/nand/raw/mtk_*
>  
> +MEDIATEK PMIC AUXADC DRIVER

Given this is one of quite a few Mediatek PMIC drivers, you either
need to be more specific in that title or offer to handle them all.

> +M:	Roman Vivchar <rva333@protonmail.com>
> +S:	Odd Fixes
> +F:	drivers/iio/adc/mt6323-auxadc.c
> +
>  MEDIATEK PMIC LED DRIVER
>  M:	Sen Chu <sen.chu@mediatek.com>
>  M:	Sean Wang <sean.wang@mediatek.com>
> 

[PATCH v2 15/16] MAINTAINERS: add MediaTek mt6323 PMIC EFUSE driver maintainer

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

Add myself as MediaTek mt6323 EFUSE driver maintainer.

Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 52249c301633..bf2e066f377d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16342,6 +16342,11 @@ M:	Roman Vivchar <rva333@protonmail.com>
 S:	Odd Fixes
 F:	drivers/iio/adc/mt6323-auxadc.c
 
+MEDIATEK PMIC EFUSE DRIVER
+M:	Roman Vivchar <rva333@protonmail.com>
+S:	Odd Fixes
+F:	drivers/nvmem/mt6323-efuse.c
+
 MEDIATEK PMIC LED DRIVER
 M:	Sen Chu <sen.chu@mediatek.com>
 M:	Sean Wang <sean.wang@mediatek.com>

-- 
2.54.0

[PATCH v2 16/16] MAINTAINERS: add MediaTek mt6323 PMIC thermal driver maintainer

[Roman Vivchar via B4 Relay]

From: Roman Vivchar <rva333@protonmail.com>

Add myself as MediaTek mt6323 thermal driver maintainer.

Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index bf2e066f377d..3001a713b083 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16355,6 +16355,11 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
 F:	drivers/leds/leds-mt6323.c
 
+MEDIATEK PMIC THERMAL DRIVER
+M:	Roman Vivchar <rva333@protonmail.com>
+S:	Odd Fixes
+F:	drivers/thermal/mediatek/mtk_pmic_thermal.c
+
 MEDIATEK RANDOM NUMBER GENERATOR SUPPORT
 M:	Sean Wang <sean.wang@mediatek.com>
 S:	Maintained

-- 
2.54.0