linux-kernel - Re: [PATCH 00/15] ASoC/soundwire: Realtek codecs: wait codec init in hw

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: <fa12aacd-a8ef-4f3f-9d1f-3ae42c25b7e0@linux.dev>
Date: Tue, 1 Jul 2025 12:33:02 +0200
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>
To: "Liao, Bard" <bard.liao@...el.com>,
 Bard Liao <yung-chuan.liao@...ux.intel.com>,
 "broonie@...nel.org" <broonie@...nel.org>, "tiwai@...e.de" <tiwai@...e.de>,
 "linux-sound@...r.kernel.org" <linux-sound@...r.kernel.org>,
 "vkoul@...nel.org" <vkoul@...nel.org>
Cc: "vinod.koul@...aro.org" <vinod.koul@...aro.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/15] ASoC/soundwire: Realtek codecs: wait codec init in
 hw_params

>> The main issue is that the codec could be attached after the codec resume.
>> Sometimes, it could take 100 ms or longer.
> 
> I don't really see the problem here. The codec device (in the Linux sense) is trying to resume, and you want to wait until the hardware device is fully configured, no?
> 
> Moving the waiting part is asking for trouble: the device will be reported as pm_runtime active, but it may not even be attached on the bus, and thus any register access will lead to invalid read/writes.
> 
> For example, starting a register dump via debugfs would fail if the codec is not attached. The machine driver could also set jack status that would fail as well.

exhibit A for the last part: see rt700_set_jack_detect(). We absolutely want to make sure the device is attached *before* configuring the jack, that means waiting until pm_runtime_resume_and_get() is done.

So at at minimum, you would need to keep a wait_for_completion() in the resume method, but it could be demoted to a wait for the enumeration only. We do have to complete() for end of enumeration and end of initialization. 

If it's the initialization that takes time, it could indeed be handled in a more asynchronous way, but I don't think you want to even think of a case where the codec finishes successfully its resume routine before the device is enumerated and can be used for register read/writes.