linux-kernel - Re: [PATCH 0/9] arm64: dts: qcom: x1: Disable audio codecs by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aJ2jUDaBAgeRcYfz@linaro.org>
Date: Thu, 14 Aug 2025 10:50:24 +0200
From: Stephan Gerhold <stephan.gerhold@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
	Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, Abel Vesa <abel.vesa@...aro.org>,
	Johan Hovold <johan@...nel.org>
Subject: Re: [PATCH 0/9] arm64: dts: qcom: x1: Disable audio codecs by default

On Thu, Aug 14, 2025 at 08:07:17AM +0200, Krzysztof Kozlowski wrote:
> On 14/08/2025 01:09, Konrad Dybcio wrote:
> > On 8/13/25 5:58 PM, Stephan Gerhold wrote:
> >> Currently, the macro audio codecs are enabled by default in x1e80100.dtsi.
> >> However, they do not probe without the ADSP remoteproc, which is disabled
> >> by default.
> > 
> > FWIW if the ADSP doesn't start, you can't really consider the platform
> > working.. It just does oversees too much of the SoC to even seriously
> > consider using the device without it
> 
> 
> I agree. ADSP is supposed to come up for every or almost every platform,
> because it is crucial for USB and charging.
> 

I agree with that as well, especially because I have an upcoming patch
series that allows reusing the "lite" ADSP firmware from UEFI for USB
and charging, so you don't even need to have firmware present for that.

The question for this patch series is separate though: Should we enable
the SoC audio codecs by default? What happens if a board does not make
use of them?

> It's true that LPASS macro codec nodes need resources from ADSP, but
> still these are resources internal to the SoC. We disable nodes in DTI
> which need an external resource. That's not really the case for LPASS.

The reason that triggered this patch series is that I was seeing an
error from the va_macro when testing on x1e001de-devkit. That board does
not have DMICs defined, so it doesn't make direct use of the va_macro:

 va_macro 6d44000.codec: qcom,dmic-sample-rate dt entry missing

We should fix this in the lpass-va-macro driver. You could take this
case one step further though: What if a board uses none of the audio
functionality? Apparently, X1E is also going to be an IoT platform. It's
very well possible we will end up with a board that doesn't have any
audio functionality. I would argue it's valid to use a minimal kernel
config in that case that has all of the audio subsystem disabled. That
won't work though, since we need to probe all the enabled audio codecs
to reach sync_state().

This might be a Linux issue unrelated to the device tree, but in my
opinion an audio codec without audio inputs/outputs is not
"operational", it should not be status = "okay". That's quite subjective
though.

At the end, I realized that x1e001de-devkit actually does have DMICs and
I just need to enable them properly to get rid of the error. I only sent
this series because I believe it fits better to our conventions. Given
that I don't need it anymore, I'm also happy to just drop it. Let me
know what you prefer.

Thanks,
Stephan