linux-kernel - Re: [RFC PATCH 0/7] Fix Intel audio Kconfig issues

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, 20 Nov 2017 14:28:12 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        alsa-devel@...a-project.org, Mark Brown <broonie@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Vinod Koul <vinod.koul@...el.com>,
        liam.r.girdwood@...ux.intel.com,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/7] Fix Intel audio Kconfig issues

On Sat, Nov 18, 2017 at 10:25 AM, Takashi Iwai <tiwai@...e.de> wrote:
> On Sat, 18 Nov 2017 01:01:55 +0100,
> Pierre-Louis Bossart wrote:
>>
>> At the risk of being scolded for the third time in two days by
>> Linux overlords (no hard feelings), here's an attempt to clean
>> things up.
>>
>> The first patch *should* implement what Linus, Takashi and Mark
>> tried to explain by email. There should be no functionality change
>> and could be merged if deemed ok.
>>
>> The rest of the patch series does a more in-depth cleanup and should not
>> be merged without more testing (hence the RFC).
>>
>> The 4th patch is really the most important one, there were nested
>> configs which made no sense to me. I don't know the history which led
>> to such complicated stuff but simpler is better.
>>
>> The last 3 patches are just clean-ups of the machine driver configs,
>> for some reason there is no consistency in the settings so I tried to
>> apply common sense. There might be additional cleanup needed since I
>> don't really get why we need references to LPSS or DESIGNWARE for things
>> which are not visible to a machine driver, we should only depend on IC2 or
>> SPI in my opinion - depending on what the control interface is.
>>
>> I tried to keep things to a minimum in each patch to make the reviews
>> easier, if people want them squashed that's fine by me.
>>
>> I'll do some more testing on my side but I could use feedback. Thanks!
>
> FYI, I've put these to a test branch, test/asoc-intel-kconfig, so that
> 0day bot can catch issues.  Let's see.

I've found several problems in this area in the past with the randconfig
builds, so I've now added that branch to my build setup as well, and
should be able to run a few hundred x86 randconfig builds today on it.
If you don't hear back from me later today, it's probably ok.

       Arnd