linux-kernel - Re: [PATCH 2/4] regulator: Enable compile testing for Maxim and Samsung PMIC 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: <20161004093056.GA8832@kozik-book>
Date:   Tue, 4 Oct 2016 11:30:56 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Lee Jones <lee.jones@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        rtc-linux@...glegroups.com
Subject: Re: [PATCH 2/4] regulator: Enable compile testing for Maxim and
 Samsung PMIC drivers

On Tue, Oct 04, 2016 at 04:40:55AM +0200, Mark Brown wrote:
> On Sun, Oct 02, 2016 at 10:58:15PM +0200, Krzysztof Kozlowski wrote:
> > Most of Maxim and Samsung PMIC/MUIC regulator drivers can be compile
> > tested to increase build coverage.
> 
> All these drivers already just depend on the MFDs which don't have any
> weird architecture dependencies - the main goal with COMPILE_TEST is
> usually to eliminate dependencies which just can't be selected so they
> can be built at all.  Given that there's no easy way to select
> everything in a subsystem otherwise does this buy us a lot?

Initially I thought similar - if parent MFD driver can be
compile-tested, then these children do not need that flag...

However the MFD drivers depend on I2C which (currently) cannot be
removed for compile testing. On the other hand, regulator drivers do not
need that dependency so you can compile-test them with I2C=n. That is
the main benefit. If you wish, I can add this information to the commit
msg.

Best regards,
Krzysztof