Re: [PATCH] pinctrl: intel: wrap Intel pin control drivers in an architecture check

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, 2017-07-05 at 09:01 +0100, Peter Robinson wrote:
> On Tue, Jul 4, 2017 at 11:21 AM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, 2017-07-04 at 12:54 +0300, Heikki Krogerus wrote:
> > > On Tue, Jul 04, 2017 at 07:49:47AM +0100, Peter Robinson wrote:

> > > > --- a/drivers/pinctrl/intel/Kconfig
> > > > +++ b/drivers/pinctrl/intel/Kconfig
> > > > @@ -1,6 +1,7 @@
> > > >  #
> > > >  # Intel pin control drivers
> > > >  #
> > > > +if (X86 || COMPILE_TEST)
> > 
> > And what about ARM et al. architectures?
> 
> If you look in the various sub directories you'll see that the various
> arch sub directories have similar for their SoC eg ARCH_SUNXI or
> explicit depends on the SoC achieving the same outcome.

ARM world is too fragmented. I can't take it as a good example.
Most of distros would like to maintain less kernels (ideally one per
architecture). In the above example it's a sub-arch.

Yes, I know that x86 has 3 let's say "sub-arches" which require
different settings to kernel. (None of them makes difference to pin
control case though)

> > Instead I would propose to reorganize parent Kconfig to have
> > something
> > like
> 
> Well they're done in alphabetical and there's appropriate depends
> ARCH_ or SOC_ etc so that those architectures don't randomly pop up in
> configs for other unrelated things, the intel/ one is one of the only
> ones that doesn't do this (hence this patch)
> 
> > if (ARM || COMPILE_TEST)
> > ...ARM stuff...
> > endif
> > 
> > if (X86 || COMPILE_TEST)
> > ...X86 stuff...
> > endif
> > 
> > But personally I don't like any of the above. So, what's the issue
> > this
> > patch is targeting against?
> 
> So that every time (in my case a distro) they don't have to explicitly
> have unrelated "# CONFIG_PINCTRL_CHERRYVIEW is not set" style bits
> through all their configs because it's completely unrelated to the
> platform.

Okay, so, what's wrong with defining big blocks on per ARCH basis as I
pointed above?

ARM, ARM64, X86, etc.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy