linux-kernel - Re: [PATCH] power: supply: max8997_charger: make EXTCON dependency unconditional

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: <CAK8P3a1ssi+S_axTKowKgszqBkBNdh4+bi-UCUOb2jWiVu18Ag@mail.gmail.com>
Date:   Mon, 8 Mar 2021 17:07:25 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     "Vaittinen, Matti" <matti.vaittinen@...rohmeurope.com>
Cc:     Sebastian Reichel <sre@...nel.org>,
        Timon Baetz <timon.baetz@...tonmail.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Linux PM list <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] power: supply: max8997_charger: make EXTCON dependency unconditional

On Mon, Mar 8, 2021 at 4:52 PM Matti Vaittinen
<matti.vaittinen@...rohmeurope.com> wrote:
>
> Hello Arnd,
>
> On Mon, 2021-03-08 at 16:29 +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@...db.de>
> >
> > I assume there is no reason to actually build this driver without
> > extcon
> > support, so a hard dependency is the easiest fix. Alternatively the
> > header file could be extended to provide additional inline stubs.
>
> I am absolutely not insisting this but it would be better if there was
> no hard dependency. I've tried couple of times to do changes to bunch
> of drivers (added some devm-functionality or generic definitions or -
> you name it) and I always end up at least compile-testing changes to
> multiple drivers. I always repeat following:
>
> 1. Manually hack the Makefiles to compile changed drivers as modules
>
> 2. Try CONFIG_COMPLILE_TEST
>  - unfortunately not too widely supported
>
> 3. Manually hack more to get drivers with 'hard dependencies' compiled
> - occasionally ending up to commenting out the calls with dependencies.
>
> So, if adding the stub is straightforward I'd vote for it.
>
> But I guess you know this quite well so I am just giving my 10 cents -
> decision can be yours :)

As Krzysztof said, he's already fixed this in linux-next the way you
prefer. Both approaches are common, and subsystem maintainers
have different preferences. I more or less picked one at random
here.

The main downside of the 'depends on FOO || !FOO' dependency is
that new developers tend to be confused by the syntax. It also
means you don't easily catch the problem with building the driver as
built-in if the dependency is missing, these can go unnoticed for a
long time until someone runs into the wrong randconfig build.

      Arnd