linux-kernel - Re: [GIT PULL] sound updates for 4.21

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]

Date:   Mon, 31 Dec 2018 04:24:41 -0600
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] sound updates for 4.21


On 12/31/18 2:11 AM, Takashi Iwai wrote:
> On Mon, 31 Dec 2018 00:17:58 +0100,
> Pierre-Louis Bossart wrote:
>>> BTW, one thing I'd really like to avoid is to rearrange the probe
>>> procedure of the legacy HDA driver (so that we can get codec_mask
>>> during pci probe() call).  The async probe is the result of the many
>>> struggles with the various and complex configurations.   Moving the
>>> codec probe to the beginning isn't trivial and quite risky to break
>>> something else.
>> Agree, mucking with the probe isn't something we should look into,
>> especially with this Skylake driver being eventually deprecated once
>> SOF is at feature parity. This set of autodetection patches for 4.21
>> was really targeting CFL/WHL+ devices, where the DSP usage is
>> mandatory when directly-attached digital microphones are used. For
>> Skylake and kabylake using the legacy by default is just fine.
> OK, then how about applying the PCI class check only for such ones
> like the patch below?  The macro isn't sexy and can be replaced with
> another way, but you have an idea.

The two patches which added the PCI class checks were supposed to be a 
simple bullet-proof way of detecting the DSP presence and solving a 
problem of coexistence between two drivers. At this point if we start 
adding quirks and still have unclear issues with HDMI support which 
isn't different for CFL+, it may be wiser to revert them to let the 4.21 
merge window progress? It's frustrating but I'd rather solve this 
problem the right way than with multiple iterations rushed because of 
the merge window timing.

>
>
> thanks,
>
> Takashi
>
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -380,6 +380,13 @@ enum {
>   #define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)
>   #define IS_CFL(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa348)
>   
> +/* CFL and later models, preferring ASoC when DSP is available */
> +#define IS_CFL_PLUS(pci)	     \
> +	((pci)->vendor == 0x8086 &&  \
> +	 ((pci)->device == 0xa348 || \
> +	  (pci)->device == 0x9dc8 || \
> +	  (pci)->device == 0x34c8))
> +
>   static char *driver_short_names[] = {
>   	[AZX_DRIVER_ICH] = "HDA Intel",
>   	[AZX_DRIVER_PCH] = "HDA Intel PCH",
> @@ -2056,7 +2063,7 @@ static int azx_probe(struct pci_dev *pci,
>   	if (pci_id->driver_data & AZX_DCAPS_INTEL_SHARED) {
>   		switch (skl_pci_binding) {
>   		case SND_SKL_PCI_BIND_AUTO:
> -			if (pci->class != 0x040300) {
> +			if (pci->class != 0x040300 && IS_CFL_PLUS(pci)) {
>   				dev_info(&pci->dev, "The DSP is enabled on this platform, aborting probe\n");
>   				return -ENODEV;
>   			}
>
>