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

Arnd Bergmann
2021-03-08T16:08:31Z

On Mon, Mar 8, 2021 at 4:52 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:
>
> Hello Arnd,
>
> On Mon, 2021-03-08 at 16:29 +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.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