[PATCH v2 0/2] ASoC: nau8822: add support for supply regulators

[PATCH v2 0/2] ASoC: nau8822: add support for supply regulators

[Alexey Charkov]

The Nuvoton NAU8822 codec has four power supply pins: VDDA, VDDB, VDDC
and VDDSPK, which must be online and stable before the device can be
accessed over I2C. On boards where these rails are software-controlled,
probing the codec before the regulators are up results in -ENXIO errors
during register access.

This short series adds optional regulator support to both the device
tree binding and the driver, so platforms that need explicit power
sequencing can describe and enforce it:

Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
Changes in v2:
- Added the regulators to the DT binding example (thanks Krzysztof)
- Switch to regulator_bulk_* APIs instead of "optional" (thanks Mark)
- Enable and disable the regulators at probe/remove and suspend/resume (thanks Sashiko)
- Include the required regulator header (thanks Sashiko)
- Add a power on reset stabilization delay before register access (thanks Sashiko)
- Link to v1: https://lore.kernel.org/r/20260513-nau8822-reg-v1-0-c532e18e92ad@flipper.net

---
Alexey Charkov (2):
      ASoC: dt-bindings: nau8822: Add supply regulators
      ASoC: codecs: nau8822: add support for supply regulators

 .../devicetree/bindings/sound/nuvoton,nau8822.yaml | 18 +++++++++
 sound/soc/codecs/nau8822.c                         | 46 ++++++++++++++++++++--
 sound/soc/codecs/nau8822.h                         |  3 ++
 3 files changed, 64 insertions(+), 3 deletions(-)
---
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
change-id: 20260513-nau8822-reg-becf5b766d80

Best regards,
-- 
Alexey Charkov <alchark@flipper.net>

[PATCH v2 1/2] ASoC: dt-bindings: nau8822: Add supply regulators

[Alexey Charkov]

NAU8822 has 4 power supply pins: VDDA, VDDB, VDDC and VDDSPK, which need
to be online and stable before communication with the device is attempted.

List them (as optional) so that device tree users can ensure correct power
sequencing.

Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 .../devicetree/bindings/sound/nuvoton,nau8822.yaml     | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
index cb8182bbc491..cf4c13038241 100644
--- a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
@@ -30,6 +30,20 @@ properties:
   clock-names:
     const: mclk
 
+  vdda-supply:
+    description: Analog power supply
+
+  vddb-supply:
+    description: Digital buffer (input/output) supply
+
+  vddc-supply:
+    description: Digital core supply
+
+  vddspk-supply:
+    description:
+      Speaker supply (power supply pin for RSPKOUT, LSPKOUT, AUXOUT2 and
+      AUXTOUT1 output drivers)
+
   nuvoton,spk-btl:
     description:
       If set, configure the two loudspeaker outputs as a Bridge Tied Load output
@@ -54,5 +68,9 @@ examples:
         codec@1a {
             compatible = "nuvoton,nau8822";
             reg = <0x1a>;
+            vdda-supply = <&vcca_3v3_s0>;
+            vddb-supply = <&vcca_3v3_s0>;
+            vddc-supply = <&vcca_3v3_s0>;
+            vddspk-supply = <&vcca_3v3_s0>;
         };
     };

-- 
2.52.0

[PATCH v2 2/2] ASoC: codecs: nau8822: add support for supply regulators

[Alexey Charkov]

NAU8822 has four power supply pins: VDDA, VDDB, VDDC, and VDDSPK, which
need to be online and stable before communication with the device is
attempted.

Request and enable these regulators at init time, if provided. Also wait
for 100 us after powering up the supply regulators before attempting to
access the device registers, as recommended by the datasheet.

This helps avoid -ENXIO errors when the codec is probed before the
regulators are ready.

Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 sound/soc/codecs/nau8822.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
 sound/soc/codecs/nau8822.h |  3 +++
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c
index 19fee5f4bf5f..830164e991a7 100644
--- a/sound/soc/codecs/nau8822.c
+++ b/sound/soc/codecs/nau8822.c
@@ -19,6 +19,7 @@
 #include <linux/pm.h>
 #include <linux/i2c.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 #include <sound/core.h>
 #include <sound/pcm.h>
@@ -108,6 +109,10 @@ static const struct reg_default nau8822_reg_defaults[] = {
 	{ NAU8822_REG_OUTPUT_TIEOFF, 0x0000 },
 };
 
+static const char * const nau8822_supply_names[NAU8822_NUM_SUPPLIES] = {
+	"vdda", "vddb", "vddc", "vddspk",
+};
+
 static bool nau8822_readable_reg(struct device *dev, unsigned int reg)
 {
 	switch (reg) {
@@ -1056,6 +1061,7 @@ static int nau8822_suspend(struct snd_soc_component *component)
 	struct snd_soc_dapm_context *dapm = snd_soc_component_to_dapm(component);
 
 	snd_soc_dapm_force_bias_level(dapm, SND_SOC_BIAS_OFF);
+	regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
 
 	regcache_mark_dirty(nau8822->regmap);
 
@@ -1066,6 +1072,15 @@ static int nau8822_resume(struct snd_soc_component *component)
 {
 	struct nau8822 *nau8822 = snd_soc_component_get_drvdata(component);
 	struct snd_soc_dapm_context *dapm = snd_soc_component_to_dapm(component);
+	int ret = regulator_bulk_enable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
+
+	if (ret) {
+		dev_err(component->dev,
+			"Failed to enable regulators: %d\n", ret);
+		return ret;
+	}
+
+	fsleep(100);
 
 	regcache_sync(nau8822->regmap);
 
@@ -1153,7 +1168,7 @@ static int nau8822_i2c_probe(struct i2c_client *i2c)
 {
 	struct device *dev = &i2c->dev;
 	struct nau8822 *nau8822 = dev_get_platdata(dev);
-	int ret;
+	int ret, i;
 
 	if (!nau8822) {
 		nau8822 = devm_kzalloc(dev, sizeof(*nau8822), GFP_KERNEL);
@@ -1167,6 +1182,13 @@ static int nau8822_i2c_probe(struct i2c_client *i2c)
 		return dev_err_probe(&i2c->dev, PTR_ERR(nau8822->mclk),
 			"Error getting mclk\n");
 
+	for (i = 0; i < NAU8822_NUM_SUPPLIES; i++)
+		nau8822->supplies[i].supply = nau8822_supply_names[i];
+
+	ret = devm_regulator_bulk_get(dev, NAU8822_NUM_SUPPLIES, nau8822->supplies);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to get regulators\n");
+
 	nau8822->regmap = devm_regmap_init_i2c(i2c, &nau8822_regmap_config);
 	if (IS_ERR(nau8822->regmap)) {
 		ret = PTR_ERR(nau8822->regmap);
@@ -1175,21 +1197,38 @@ static int nau8822_i2c_probe(struct i2c_client *i2c)
 	}
 	nau8822->dev = dev;
 
+	ret = regulator_bulk_enable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to enable regulators\n");
+
+	fsleep(100);
+
 	/* Reset the codec */
 	ret = regmap_write(nau8822->regmap, NAU8822_REG_RESET, 0x00);
 	if (ret != 0) {
 		dev_err(&i2c->dev, "Failed to issue reset: %d\n", ret);
-		return ret;
+		goto err_reg;
 	}
 
 	ret = devm_snd_soc_register_component(dev, &soc_component_dev_nau8822,
 						&nau8822_dai, 1);
 	if (ret != 0) {
 		dev_err(&i2c->dev, "Failed to register CODEC: %d\n", ret);
-		return ret;
+		goto err_reg;
 	}
 
 	return 0;
+
+err_reg:
+	regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
+	return ret;
+}
+
+static void nau8822_i2c_remove(struct i2c_client *i2c)
+{
+	struct nau8822 *nau8822 = i2c_get_clientdata(i2c);
+
+	regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
 }
 
 static const struct i2c_device_id nau8822_i2c_id[] = {
@@ -1212,6 +1251,7 @@ static struct i2c_driver nau8822_i2c_driver = {
 		.of_match_table = of_match_ptr(nau8822_of_match),
 	},
 	.probe = nau8822_i2c_probe,
+	.remove = nau8822_i2c_remove,
 	.id_table = nau8822_i2c_id,
 };
 module_i2c_driver(nau8822_i2c_driver);
diff --git a/sound/soc/codecs/nau8822.h b/sound/soc/codecs/nau8822.h
index 13fe0a091e9e..24799c7b5931 100644
--- a/sound/soc/codecs/nau8822.h
+++ b/sound/soc/codecs/nau8822.h
@@ -211,6 +211,8 @@ struct nau8822_pll {
 	int freq_out;
 };
 
+#define NAU8822_NUM_SUPPLIES	4
+
 /* Codec Private Data */
 struct nau8822 {
 	struct device *dev;
@@ -219,6 +221,7 @@ struct nau8822 {
 	struct nau8822_pll pll;
 	int sysclk;
 	int div_id;
+	struct regulator_bulk_data supplies[NAU8822_NUM_SUPPLIES];
 };
 
 #endif	/* __NAU8822_H__ */

-- 
2.52.0

Re: [PATCH v2 1/2] ASoC: dt-bindings: nau8822: Add supply regulators

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Typo in the description for `vddspk-supply`.
--

commit 2a0698dd10cf90a92b31e252ae2cfd2a236cf2d9
Author: Alexey Charkov <alchark@flipper.net>
ASoC: dt-bindings: nau8822: Add supply regulators

This commit adds optional power supply pins (VDDA, VDDB, VDDC, and VDDSPK)
to the NAU8822 device tree binding. This allows device tree users to ensure
correct power sequencing before communicating with the device.

> diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
> index cb8182bbc491f..cf4c130382411 100644
> --- a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
> +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml

[ ... ]

> @@ -30,6 +30,20 @@ properties:
>    clock-names:
>      const: mclk
>  
> +  vdda-supply:
> +    description: Analog power supply
> +
> +  vddb-supply:
> +    description: Digital buffer (input/output) supply
> +
> +  vddc-supply:
> +    description: Digital core supply
> +
> +  vddspk-supply:
> +    description:
> +      Speaker supply (power supply pin for RSPKOUT, LSPKOUT, AUXOUT2 and
> +      AUXTOUT1 output drivers)

[Severity: Low]
This isn't a bug, but there appears to be a typo here. Should this be
AUXOUT1 instead of AUXTOUT1 to match the actual pin and driver definition?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525-nau8822-reg-v2-0-7d37ae393e46@flipper.net?part=1

Re: [PATCH v2 2/2] ASoC: codecs: nau8822: add support for supply regulators

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Manually disabling regulators in the I2C `remove` callback breaks the LIFO teardown order, causing I2C operations to fail during `devm` component teardown.
- [Medium] Unconditional regulator disable in the `remove` callback can cause an unbalanced disable if the device is removed following a resume failure.
--

commit 9b4fbe6b13298617ee870787131ce69e29d799b3
Author: Alexey Charkov <alchark@flipper.net>

ASoC: codecs: nau8822: add support for supply regulators

This commit adds support for the four power supply pins on the NAU8822
codec by requesting and enabling them at init time. It also adds a brief
delay after power up to allow the device to stabilize before register access.

> diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c
> --- a/sound/soc/codecs/nau8822.c
> +++ b/sound/soc/codecs/nau8822.c
[ ... ]
>  	ret = devm_snd_soc_register_component(dev, &soc_component_dev_nau8822,
>  						&nau8822_dai, 1);
>  	if (ret != 0) {
>  		dev_err(&i2c->dev, "Failed to register CODEC: %d\n", ret);
> -		return ret;
> +		goto err_reg;
>  	}
>  
>  	return 0;
> +
> +err_reg:
> +	regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
> +	return ret;
> +}
> +
> +static void nau8822_i2c_remove(struct i2c_client *i2c)
> +{
> +	struct nau8822 *nau8822 = i2c_get_clientdata(i2c);
> +
> +	regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);

[Severity: High]
Can this manual regulator disable cause I2C bus errors during teardown?

The ASoC component is registered with devm_snd_soc_register_component(),
which means the subsystem will unregister the component during the devres
cleanup phase. This happens after nau8822_i2c_remove() has already
returned.

Because the regulators are disabled here, the hardware will be unpowered
while the ASoC component is still active. During devres cleanup, the
subsystem will call snd_soc_dapm_shutdown() and transition the bias level
to SND_SOC_BIAS_OFF.

Will the resulting I2C register writes to the unpowered codec fail or
time out, potentially stalling the driver unbind?

[Severity: Medium]
Could this unconditional regulator disable also result in an unbalanced
disable warning?

If the system resumes but nau8822_resume() fails to re-enable the
regulators, they will remain in the disabled state set during
nau8822_suspend().

If the driver is later unbound, this call will execute again. Will this
attempt to drop the regulator reference count below zero and trigger a
kernel warning?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525-nau8822-reg-v2-0-7d37ae393e46@flipper.net?part=2

Re: [PATCH v2 1/2] ASoC: dt-bindings: nau8822: Add supply regulators

[Alexey Charkov]

On Mon, May 25, 2026 at 1:29 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Typo in the description for `vddspk-supply`.
> --
>
> commit 2a0698dd10cf90a92b31e252ae2cfd2a236cf2d9
> Author: Alexey Charkov <alchark@flipper.net>
> ASoC: dt-bindings: nau8822: Add supply regulators
>
> This commit adds optional power supply pins (VDDA, VDDB, VDDC, and VDDSPK)
> to the NAU8822 device tree binding. This allows device tree users to ensure
> correct power sequencing before communicating with the device.
>
> > diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
> > index cb8182bbc491f..cf4c130382411 100644
> > --- a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
> > +++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
>
> [ ... ]
>
> > @@ -30,6 +30,20 @@ properties:
> >    clock-names:
> >      const: mclk
> >
> > +  vdda-supply:
> > +    description: Analog power supply
> > +
> > +  vddb-supply:
> > +    description: Digital buffer (input/output) supply
> > +
> > +  vddc-supply:
> > +    description: Digital core supply
> > +
> > +  vddspk-supply:
> > +    description:
> > +      Speaker supply (power supply pin for RSPKOUT, LSPKOUT, AUXOUT2 and
> > +      AUXTOUT1 output drivers)
>
> [Severity: Low]
> This isn't a bug, but there appears to be a typo here. Should this be
> AUXOUT1 instead of AUXTOUT1 to match the actual pin and driver definition?

Indeed, it's a typo in the datasheet text which I copied and hadn't
noticed (NAU8822 Datasheet Rev 3.3 page 3).

Best regards,
Alexey

Re: [PATCH v2 2/2] ASoC: codecs: nau8822: add support for supply regulators

[Alexey Charkov]

On Mon, May 25, 2026 at 1:51 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Manually disabling regulators in the I2C `remove` callback breaks the LIFO teardown order, causing I2C operations to fail during `devm` component teardown.
> - [Medium] Unconditional regulator disable in the `remove` callback can cause an unbalanced disable if the device is removed following a resume failure.
> --
>
> commit 9b4fbe6b13298617ee870787131ce69e29d799b3
> Author: Alexey Charkov <alchark@flipper.net>
>
> ASoC: codecs: nau8822: add support for supply regulators
>
> This commit adds support for the four power supply pins on the NAU8822
> codec by requesting and enabling them at init time. It also adds a brief
> delay after power up to allow the device to stabilize before register access.
>
> > diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c
> > --- a/sound/soc/codecs/nau8822.c
> > +++ b/sound/soc/codecs/nau8822.c
> [ ... ]
> >       ret = devm_snd_soc_register_component(dev, &soc_component_dev_nau8822,
> >                                               &nau8822_dai, 1);
> >       if (ret != 0) {
> >               dev_err(&i2c->dev, "Failed to register CODEC: %d\n", ret);
> > -             return ret;
> > +             goto err_reg;
> >       }
> >
> >       return 0;
> > +
> > +err_reg:
> > +     regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
> > +     return ret;
> > +}
> > +
> > +static void nau8822_i2c_remove(struct i2c_client *i2c)
> > +{
> > +     struct nau8822 *nau8822 = i2c_get_clientdata(i2c);
> > +
> > +     regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
>
> [Severity: High]
> Can this manual regulator disable cause I2C bus errors during teardown?
>
> The ASoC component is registered with devm_snd_soc_register_component(),
> which means the subsystem will unregister the component during the devres
> cleanup phase. This happens after nau8822_i2c_remove() has already
> returned.

While I can move the regulator disable to the component .remove
callback instead of i2c .remove, I'm wondering how the unregistration
is supposed to work at all with a removed i2c device if it's indeed
structured the way Sashiko implies. Doing so would make it
semantically unbalanced, which feels wrong (enable in i2c device
probe, but disable in component remove, where component lifetime is
less than i2c device lifetime? Ouch)

Any guidance would be appreciated.

I see existing drivers use both ways:
- Disable regulators in component .remove: e.g. [1]
- Disable regulators in i2c device .remove: e.g. [2]

[1] https://elixir.bootlin.com/linux/v6.19.9/source/sound/soc/codecs/es8328.c#L824
[2] https://elixir.bootlin.com/linux/v6.19.9/source/sound/soc/codecs/rt5645.c#L4300

Or maybe I should just switch to devm_regulator_bulk_get_enable and
forget about the remove callback altogether - unless I'm missing some
other subtlety here.

> Because the regulators are disabled here, the hardware will be unpowered
> while the ASoC component is still active. During devres cleanup, the
> subsystem will call snd_soc_dapm_shutdown() and transition the bias level
> to SND_SOC_BIAS_OFF.
>
> Will the resulting I2C register writes to the unpowered codec fail or
> time out, potentially stalling the driver unbind?
>
> [Severity: Medium]
> Could this unconditional regulator disable also result in an unbalanced
> disable warning?
>
> If the system resumes but nau8822_resume() fails to re-enable the
> regulators, they will remain in the disabled state set during
> nau8822_suspend().
>
> If the driver is later unbound, this call will execute again. Will this
> attempt to drop the regulator reference count below zero and trigger a
> kernel warning?

Most likely yes. I'm not sure though if coding around this case is
worth the trouble, and other drivers don't seem to bother. The system
must already be quite broken if it can't re-enable regulators at
resume, and in that case, another harmless kernel warning is probably
the least of the user's concerns.

Best regards,
Alexey