linux-kernel - Re: [PATCH] ASoC: codecs: allow compile testing without MFD drivers

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: <a5266af6-af19-48f9-8bc6-94c171ba6d0c@linaro.org>
Date:   Sat, 27 Aug 2022 12:02:39 +0300
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: codecs: allow compile testing without MFD drivers

On 26/08/2022 21:35, Mark Brown wrote:
> On Fri, Aug 26, 2022 at 12:36:59PM +0300, Krzysztof Kozlowski wrote:
>> Motorola CPCAP, Lochnagar Sound, Rockchip RK817 and Qualcomm
>> WCD9340/WCD9341 do not depend on parent MFD driver in build time and can
>> be compile tested without respective MFD part for increased build
>> coverage.
> 
> Although generally it's easy enough to just turn on the MFDs
> themselves, it's not the same base platform issue as the firmware
> interfaces can be.

True, it's not the same build coverage need as subsystem/interface
dependencies, but still:
1. Drivers can be built independently, so why not?
2. There is no drawback in allowing to building them independently
(compile test).
3. The parent MFD device could also depend on something (RK817 and
MFD_LOCHNAGAR depends on I2C and OF; CPCAP on SPI), so it's not always
the case of just enabling parent. IOW, you can compile test codecs
without I2C and SPI which is valuable itself.

I find the last reason actually quite valid and applicable here. If you
wish I can add it to the commit msg.

Best regards,
Krzysztof