linux-kernel - Re: [PATCH v2 7/9] ALSA: hda/intel: Move snd_hdac_i915_init to before probe

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: <35720f76-e8b0-578b-e326-ebfce536be04@linux.intel.com>
Date:   Tue, 25 Jul 2023 12:13:20 +0200
From:   Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        alsa-devel@...a-project.org
Cc:     sound-open-firmware@...a-project.org, linux-kernel@...r.kernel.org,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Cezary Rojewski <cezary.rojewski@...el.com>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
        Bard Liao <yung-chuan.liao@...ux.intel.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        Mark Brown <broonie@...nel.org>,
        Daniel Baluta <daniel.baluta@....com>
Subject: Re: [PATCH v2 7/9] ALSA: hda/intel: Move snd_hdac_i915_init to before
 probe_work.

Hey,

On 2023-07-24 12:58, Pierre-Louis Bossart wrote:
> 
> 
> On 7/19/23 18:41, Maarten Lankhorst wrote:
>> Now that we can use -EPROBE_DEFER, it's no longer required to spin off
>> the snd_hdac_i915_init into a workqueue.
>>
>> Use the -EPROBE_DEFER mechanism instead, which must be returned in the
>> probe function.
>>
>> Changes since v1:
>> - Use dev_err_probe()
>> - Don't move probed_devs bitmap unnecessarily. (tiwai)
>> - Move snd_hdac_i915_init slightly upward, to ensure
>>    it's always initialised before vga-switcheroo is called.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
>> ---
>>   sound/pci/hda/hda_intel.c | 59 ++++++++++++++++++++-------------------
>>   1 file changed, 30 insertions(+), 29 deletions(-)
>>
>> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
>> index 11cf9907f039f..e3128d7d742e7 100644
>> --- a/sound/pci/hda/hda_intel.c
>> +++ b/sound/pci/hda/hda_intel.c
>> @@ -2147,6 +2147,36 @@ static int azx_probe(struct pci_dev *pci,
>>   
>>   	pci_set_drvdata(pci, card);
>>   
>> +#ifdef CONFIG_SND_HDA_I915
>> +	/* bind with i915 if needed */
>> +	if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
>> +		err = snd_hdac_i915_init(azx_bus(chip), false);
>> +		if (err < 0) {
>> +			/* if the controller is bound only with HDMI/DP
>> +			 * (for HSW and BDW), we need to abort the probe;
>> +			 * for other chips, still continue probing as other
>> +			 * codecs can be on the same link.
>> +			 */
>> +			if (CONTROLLER_IN_GPU(pci)) {
>> +				dev_err_probe(card->dev, err,
>> +					     "HSW/BDW HD-audio HDMI/DP requires binding with gfx driver\n");
>> +
>> +				goto out_free;
>> +			} else {
>> +				/* don't bother any longer */
>> +				chip->driver_caps &= ~AZX_DCAPS_I915_COMPONENT;
>> +			}
>> +		}
>> +
>> +		/* HSW/BDW controllers need this power */
>> +		if (CONTROLLER_IN_GPU(pci))
>> +			hda->need_i915_power = true;
>> +	}
>> +#else
>> +	if (CONTROLLER_IN_GPU(pci))
>> +		dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in CONFIG_SND_HDA_I915\n");
>> +#endif
> 
> Is it intentional that the display_power() is left in the probe workqueue?
> 
> this piece of code follows the stuff above in the existing code?
> 
> /* Request display power well for the HDA controller or codec. For
>   * Haswell/Broadwell, both the display HDA controller and codec need
>   * this power. For other platforms, like Baytrail/Braswell, only the
>   * display codec needs the power and it can be released after probe.
>   */
> display_power(chip, true);

I think for the binding itself, there isn't any harm. We are not poking 
any hardware when binding,
only software. This appears to be true on the i915 side as well.

Cheers,
~Maarten