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] [day] [month] [year] [list]

Message-ID: <SJ2PR11MB84247FEBDB94949224315ADEFF41A@SJ2PR11MB8424.namprd11.prod.outlook.com>
Date: Tue, 1 Jul 2025 11:42:32 +0000
From: "Liao, Bard" <bard.liao@...el.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>, 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



> -----Original Message-----
> From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>
> Sent: Tuesday, July 1, 2025 6:33 PM
> To: Liao, Bard <bard.liao@...el.com>; Bard Liao <yung-
> chuan.liao@...ux.intel.com>; broonie@...nel.org; tiwai@...e.de; linux-
> sound@...r.kernel.org; vkoul@...nel.org
> Cc: vinod.koul@...aro.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.


Thanks Pierre. Fair point. You convinced me. Let's drop this series.