When enabling ES8390 via ACPI description, es8389 would fail to
obtain a clock source, causing the driver to fail to initialize.
This was not an issue with older kernels, but since commit
abae8e57e49a ("clk: generalize devm_clk_get() a bit"),
devm_clk_get() would return an error pointer when a clock source
was not detected (instead of falling back to a static clock),
causing the driver to fail early.

Use devm_clk_get_optional() instead to return to the previous
behaviour, allowing the use of a static clock source.

Cc: stable@vger.kernel.org
Fixes: abae8e57e49a ("clk: generalize devm_clk_get() a bit")
Signed-off-by: Li Jian <lazycat-xiao@foxmail.com>
---
 sound/soc/codecs/es8389.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
index 8d418cae3..449d9574b 100644
--- a/sound/soc/codecs/es8389.c
+++ b/sound/soc/codecs/es8389.c
@@ -892,7 +892,7 @@ static int es8389_probe(struct snd_soc_component *component)
 		return ret;
 	}
 
-	es8389->mclk = devm_clk_get(component->dev, "mclk");
+	es8389->mclk = devm_clk_get_optional(component->dev, "mclk");
 	if (IS_ERR(es8389->mclk))
 		return dev_err_probe(component->dev, PTR_ERR(es8389->mclk),
 			"ES8389 is unable to get mclk\n");
-- 
2.47.3

On Fri, 17 Apr 2026 18:53:14 +0800, Li Jian wrote:
> ASoC: ES8389: convert to devm_clk_get_optional() to get clock

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1

Thanks!

[1/1] ASoC: ES8389: convert to devm_clk_get_optional() to get clock
      https://git.kernel.org/broonie/sound/c/8ed331113107

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

On Mon, Apr 27, 2026 at 08:30:27AM +0900, Mark Brown wrote:
> On Fri, 17 Apr 2026 18:53:14 +0800, Li Jian wrote:
> > ASoC: ES8389: convert to devm_clk_get_optional() to get clock
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1
> 
> Thanks!
> 
> [1/1] ASoC: ES8389: convert to devm_clk_get_optional() to get clock
>       https://git.kernel.org/broonie/sound/c/8ed331113107

I see you dropped the Fixes: line, but I still think the commit log is
wrongly blaming abae8e57e49a. Unless I'm missing something, abae8e57e49a
didn't change behaviour of devm_clk_get() or devm_clk_get_optional(), so
"since commit abae8e57e49a ("clk: generalize devm_clk_get() a bit"),
devm_clk_get() would return an error pointer when a clock source was not
detected (instead of falling back to a static clock)," is wrong.

Best regards
Uwe

On Mon, Apr 27, 2026 at 07:00:59PM +0200, Uwe Kleine-König wrote:
> On Mon, Apr 27, 2026 at 08:30:27AM +0900, Mark Brown wrote:

> > [1/1] ASoC: ES8389: convert to devm_clk_get_optional() to get clock
> >       https://git.kernel.org/broonie/sound/c/8ed331113107

> I see you dropped the Fixes: line, but I still think the commit log is
> wrongly blaming abae8e57e49a. Unless I'm missing something, abae8e57e49a
> didn't change behaviour of devm_clk_get() or devm_clk_get_optional(), so
> "since commit abae8e57e49a ("clk: generalize devm_clk_get() a bit"),
> devm_clk_get() would return an error pointer when a clock source was not
> detected (instead of falling back to a static clock)," is wrong.

Yes, the changelog's description is likely wrong about the behaviour
changing here.

Hello,

On Fri, Apr 17, 2026 at 06:53:14PM +0800, Li Jian wrote:
> When enabling ES8390 via ACPI description, es8389 would fail to
> obtain a clock source, causing the driver to fail to initialize.
> This was not an issue with older kernels, but since commit
> abae8e57e49a ("clk: generalize devm_clk_get() a bit"),
> devm_clk_get() would return an error pointer when a clock source
> was not detected (instead of falling back to a static clock),
> causing the driver to fail early.
> 
> Use devm_clk_get_optional() instead to return to the previous
> behaviour, allowing the use of a static clock source.
> 
> Cc: stable@vger.kernel.org
> Fixes: abae8e57e49a ("clk: generalize devm_clk_get() a bit")

Are you sure you identified the breaking commit correctly? I intended
the patch not to introduce any semantic change, and even with your claim
I don't spot the issue in abae8e57e49a.

Best regards
Uwe

Hi Uwe

在 2026/4/17 21:34, Uwe Kleine-König 写道:

> Hello,
> 
> On Fri, Apr 17, 2026 at 06:53:14PM +0800, Li Jian wrote:
>> When enabling ES8390 via ACPI description, es8389 would fail to
>> obtain a clock source, causing the driver to fail to initialize.
>> This was not an issue with older kernels, but since commit
>> abae8e57e49a ("clk: generalize devm_clk_get() a bit"),
>> devm_clk_get() would return an error pointer when a clock source
>> was not detected (instead of falling back to a static clock),
>> causing the driver to fail early.
>>
>> Use devm_clk_get_optional() instead to return to the previous
>> behaviour, allowing the use of a static clock source.
>>
>> Cc: stable@vger.kernel.org
>> Fixes: abae8e57e49a ("clk: generalize devm_clk_get() a bit")
> 
> Are you sure you identified the breaking commit correctly? I intended
> the patch not to introduce any semantic change, and even with your claim
> I don't spot the issue in abae8e57e49a.
> 


There was a misunderstanding on how the Fixes: tag should be used - I 
meant to say that your commit changed a behaviour, not that it was 
broken. I should have pointed to a commit to this driver instead.

In my case, since the device was described in ACPI and it does not 
export a clock to the operating system, it was then necessary to utilize 
a fallback. Before your commit, missing clocks returned a NULL pointer. 
However, your commit correctly makes it return an error pointer instead 
- now, since the driver initialization checks for error pointers, so I 
switched to devm_clk_get_optional(), which falls back to a static clock 
source to avoid this issue on ACPI platforms.

Again, your commit is correct, but I was not using the Fixes: tag 
correct - indeed, a missing clock should return an error pointer, not 
NULL. Sorry about that and I will submit v2 to fix this.

Best regards,
Li Jian

 > Best regards
 > Uwe

Hello,

[Fixed address of loongarch mailing list]

On Sat, Apr 18, 2026 at 04:18:10PM +0800, Li Jian wrote:
> 在 2026/4/17 21:34, Uwe Kleine-König 写道:
> > On Fri, Apr 17, 2026 at 06:53:14PM +0800, Li Jian wrote:
> > > When enabling ES8390 via ACPI description, es8389 would fail to
> > > obtain a clock source, causing the driver to fail to initialize.
> > > This was not an issue with older kernels, but since commit
> > > abae8e57e49a ("clk: generalize devm_clk_get() a bit"),
> > > devm_clk_get() would return an error pointer when a clock source
> > > was not detected (instead of falling back to a static clock),
> > > causing the driver to fail early.
> > > 
> > > Use devm_clk_get_optional() instead to return to the previous
> > > behaviour, allowing the use of a static clock source.
> > > 
> > > Cc: stable@vger.kernel.org
> > > Fixes: abae8e57e49a ("clk: generalize devm_clk_get() a bit")
> > 
> > Are you sure you identified the breaking commit correctly? I intended
> > the patch not to introduce any semantic change, and even with your claim
> > I don't spot the issue in abae8e57e49a.
> 
> There was a misunderstanding on how the Fixes: tag should be used - I meant
> to say that your commit changed a behaviour, not that it was broken. I

In principle the usage is fine: *If* a commit changed behaviour and
failed to adapt a user relying on the old behaviour, that warrants a
Fixes line.

*But* I claim the commit didn't change behaviour. devm_clk_get()
returned and returns whatever clk_get() returned; with and without
abae8e57e49a. And clk_get() wasn't touched in my commit.

> should have pointed to a commit to this driver instead.
> 
> In my case, since the device was described in ACPI and it does not export a
> clock to the operating system, it was then necessary to utilize a fallback.
> Before your commit, missing clocks returned a NULL pointer.

So I'm pretty sure you're wrong here. Did you try reverting abae8e57e49a
on a broken state and confirm that fixes things for you?

Best regards
Uwe