linux-kernel - Re: [PATCH v12] ASoc: tas2783: Add tas2783 codec driver

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]

Date: Tue, 2 Apr 2024 18:59:33 +0100
From: Mark Brown <broonie@...nel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc: Shenghao Ding <shenghao-ding@...com>, andriy.shevchenko@...ux.intel.com,
	lgirdwood@...il.com, perex@...ex.cz, 13916275206@....com,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
	liam.r.girdwood@...el.com, bard.liao@...el.com,
	yung-chuan.liao@...ux.intel.com, kevin-lu@...com, tiwai@...e.de,
	baojun.xu@...com, soyer@....hu, Baojun.Xu@....com, navada@...com,
	v-po@...com
Subject: Re: [PATCH v12] ASoc: tas2783: Add tas2783 codec driver

On Mon, Apr 01, 2024 at 08:50:24AM -0500, Pierre-Louis Bossart wrote:

> > +static int tasdevice_comp_probe(struct snd_soc_component *comp)
> > +{

> > +	ret = request_firmware(&fw_entry, dspfw_binaryname, tas_dev->dev);
> > +	if (ret) {
> > +		dev_err(tas_dev->dev,
> > +			"%s: request_firmware %x open status: %d.\n", __func__,
> > +			tas_dev->sdw_peripheral->id.unique_id, ret);
> > +		goto out;
> > +	}
> > +
> > +	tasdevice_dspfw_ready(fw_entry, tas_dev);

> Question: is there a specific reason why all this functionality needs to
> be done in a component probe instead of when the device reports as ATTACHED?

> Since you have an interaction with userspace for the firmware, and
> firmware download takes time, you would want to do this as early as
> possible.

> Usually the component probe is part of the card creation, so you could
> add card-related or control related things. Downloading firmware does
> not strike me as a card-related activity?

This does have the effect of ensuring that the card won't instantiate
without firmware.  Given how utterly dependent on firmware this device
seems to be I can see a case for blocking card registration until the
firmware is ready, there's a usability thing there but it feels like
there's a usability issue with any error handling for missing firmware
on these devices and not registering the card does seem like a valid
choice.  That said it would still be nicer to initiate the firmware
process earlier in order to minimise latency and then either defer
registration of the component until we've managed to load firmware or
have a check at component probe to make sure that the firmware is ready.

> Another question is whether the firmware needs to be downloaded again
> during system/pm_runtime resume? That may depend on how power is managed
> at the hardware level, but in theory an SDCA device should report to the
> host whether the firmware is still valid or needs to be downloaded.

That does seem like a concern too.

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