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

Message-ID: <s5hef9zl69r.wl-tiwai@suse.de>
Date:   Sun, 30 Dec 2018 10:21:04 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Takashi Iwai <tiwai@...e.de>, Ingo Molnar <mingo@...nel.org>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        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 Fri, 28 Dec 2018 20:04:48 +0100,
Linus Torvalds wrote:
> 
> On Fri, Dec 28, 2018 at 9:07 AM Takashi Iwai <tiwai@...e.de> wrote:
> >
> > 1) Whether ASoC driver cannot work with these Dell machines at all
> 
> I'm willing to test patches.
> 
> Right now, the reason it fails to even load is that "codec_mask" is 0x0001.
> 
> And the skl_hda_dsp_generic.c code requires
> 
>         // This will be 1 for 0x0001
>         codec_count = hweight_long(codec_mask);
> 
>         if (codec_count == 1 && codec_mask & IDISP_CODEC_MASK) {
>            .. this is ok ..
>         } else if (codec_count == 2 && codec_mask & IDISP_CODEC_MASK) {
>            .. as is this ..
>         } else {
>            .. but here we return -EINVAL;
>         }
> 
> and that basically requires that IDISP_CODEC_MASK be part of
> codec_mask. Which it isn't (IDISP_CODEC_MASK is 0x4).
> 
> Anyway, as long as the ASoC driver refuses to touch this, the default
> pretty much *has* to be the legacy PCI driver.

Thanks, the above seems to be the likely cause.

This is a good news and a bad news, actually.  The good news is that
we know the cause, and this can be detected earlier, too.  The bad
news is that the possible detection (the probe of codec mask) is done
in an async probe work in the legacy HDA driver, hence the PCI driver
probe() call cannot return -ENODEV for this.

And, it brings me a question: does the audio routing work without
iDISP at all?  The current code looks mandating the iDISP, and I
thought this is a core part of HD-audio routing on DSP.

Intel people, could you clarify this?

If iDISP is mandatory and really missing on these machines, we need
another way to identify such systems without codec mask checks.
Maybe DMI or such listing; ugly but should be still manageable since
the number of devices hitting the problem must be fairly low.

Or, an alternative is to let ASoC driver bind at first, e.g. by
changing the driver name from snd-soc-skl to snd-hda-asoc, and drop
the selective binding from snd-hda-intel, so that it'd work as
catch-all after binding with ASoC fails.

The above would work for the modules, but for built-in, we need to
rearrange the link order, too, supposedly.
(For the mixed case with built-in and module?  I don't know, maybe we
 may forgive us by the presence of module options to control the
 binding.)

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.

thanks,

Takashi