linux-kernel - Re: [EXTERNAL] Re: [PATCH v2 1/4] ASoc: PCM6240: Create PCM6240 Family driver code

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 for Android: free password hash cracker in your pocket

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

Message-ID: <00acc379-2812-43da-aa14-4a43a0d25f79@sirena.org.uk>
Date: Mon, 29 Jan 2024 13:40:42 +0000
From: Mark Brown <broonie@...nel.org>
To: "Ding, Shenghao" <shenghao-ding@...com>
Cc: "conor+dt@...nel.org" <conor+dt@...nel.org>,
	"krzysztof.kozlowski@...aro.org" <krzysztof.kozlowski@...aro.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>,
	"Lu, Kevin" <kevin-lu@...com>, "Xu, Baojun" <baojun.xu@...com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"P O, Vijeth" <v-po@...com>,
	"lgirdwood@...il.com" <lgirdwood@...il.com>,
	"perex@...ex.cz" <perex@...ex.cz>,
	"pierre-louis.bossart@...ux.intel.com" <pierre-louis.bossart@...ux.intel.com>,
	"13916275206@....com" <13916275206@....com>,
	"Chawla, Mohit" <mohit.chawla@...com>,
	"linux-sound@...r.kernel.org" <linux-sound@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"liam.r.girdwood@...el.com" <liam.r.girdwood@...el.com>,
	"soyer@....hu" <soyer@....hu>, "Huang, Jonathan" <jkhuang3@...com>,
	"tiwai@...e.de" <tiwai@...e.de>, "Djuandi, Peter" <pdjuandi@...com>,
	"McPherson, Jeff" <j-mcpherson@...com>,
	"Navada Kanyana, Mukund" <navada@...com>
Subject: Re: [EXTERNAL] Re: [PATCH v2 1/4] ASoc: PCM6240: Create PCM6240
 Family driver code

On Mon, Jan 29, 2024 at 05:03:48AM +0000, Ding, Shenghao wrote:

> > It might be better to request the firmware in the I2C probe rather than in the
> > ASoC level probe, that way there's more time for the firmware to be loaded
> > before we actually need it.  That does mean you can't register the controls
> > immediately though so it may be more trouble than it's worth.

> I once put request_firmware_nowait in i2c_probe, but it sometimes returned 
> error in some platforms. So my customer suggest that it would be moved into 
> the codec_probe. It seemed filesystem is not completely ready in some 
> platform during calling the i2c_probe.

That indicates that this is still racy - shuffling things around has
papered over a timing issue on their particular system but it's still
possible to have the card come up before the filesystems are fully ready
(especially if all the drivers are built in).  If the DSP firmware is
essential to the device's operation the driver should defer registration
with the core until the firmware has loaded.  wm8958 should have an
example of this IIRC.

> > Similarly for the reset, if we reset as early as possible that seems better.

> As to reset, it is also from my customers' suggestion. they found the issue that 
> i2c access error in i2c_probe in some platform. So they put it into codec_probe.

That suggests the reset might be missing some delays or something and
again there might be some issues.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)