Re: [PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Robert Richter]

On 05.09.14 18:25:35, Arnd Bergmann wrote:
> On Friday 05 September 2014 15:22:46 Mark Rutland wrote:
> > 
> > > A common pattern these days is to do dependencies like
> > > 
> > > arch/*/Kconfig:
> > >       config ARCH_FOO
> > >       bool "Enable support for Foo platform"
> > >       help
> > >         ...
> > > 
> > > 
> > > drivers/*/Kconfig
> > >       config SUBSYS_FOO
> > >       bool "SUBSYS driver for Foo"
> > >       depends on ARCH_FOO || COMPILE_TEST
> > >       depends on OF && REGULATOR && GENERIC_PHY # or whatever
> >
> > Russell's comments w.r.t. Kconfig warnings when config names change
> > still holds regardless of select vs depends on.
> 
> Yes, that's what I wrote in my reply as well.
> 
> > > That way we can enable everything in the defconfig, but someone
> > > who likes to build a more specialized kernel can disable the
> > > other platforms and won't get the drivers that are specific to
> > > those.
> > > 
> > > I personally think this is a bit more verbose than what we need, but
> > > I don't strongly object doing it that way.
> > 
> > You'd still be able to do this without ARCH_FOO, though you would need
> > to know which drivers are necessary for a particular SoC. That seems to
> > be the way things are handled on x86; I don't recall having to select
> > support for specific machines there, just the individual drivers.

This is well hidden on x86, but each vendor has a config option. For
AMD systems we have had our own option to disable vendor specific
code, see CPU_SUP_AMD for example. Disabling this will remove all AMD
specific code in the kernel. Of course this is enabled per default.

With ARCH_THUNDER I intended to do the same (you could name this also
SOC_SUP_CAVIUM or so but I kept the current naming scheme). In patch
4/4 I have added the option to defconfig. This enables this per
default and nobody has to deal with any option manually, just running
make defconfig is fine.

Also, at least to disable building the dtb file for foo, you will need
ARCH_FOO too. How else would you deal with dtb files then?

Having ARCH_FOO might not be necessary for drivers. One could enable
drivers manually, but this option is still a good reference for the
drivers needed by foo. At some point you will carry tons of enabled
drivers in your defconfig and you don't know which platform actually
is using it. For generic drivers this might be fine.  But in my point
of few, each soc specific driver should have an soc specific option
too. Then you easily can remove an soc from the defconfig.

-Robert

> The main difference is that there are very few drivers on x86 that are
> specific to one of the two chip makers. Almost everything is a PCI
> device that can actually be plugged in anywhere.
> 
> On ARM64 there is going to be a lot of stuff that really makes sense
> only for one of the 50 licensees.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/