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]

Message-ID: <s5ho991k1g9.wl-tiwai@suse.de>
Date:   Mon, 31 Dec 2018 19:15:02 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     Takashi Iwai <tiwai@...e.de>,
        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 Mon, 31 Dec 2018 11:24:41 +0100,
Pierre-Louis Bossart wrote:
> 
> 
> 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.

Fair enough, let's revert them for now.  I'm going to submit the
revert patch.


thanks,

Takashi