Re: [PATCH net-next] MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig

[Paul Burton]

Hi Horatiu,

On Wed, Apr 03, 2019 at 05:27:36PM +0200, Horatiu Vultur wrote:
> diff --git a/arch/mips/configs/generic/board-ocelot.config b/arch/mips/configs/generic/board-ocelot.config
> index f607888..3215741 100644
> --- a/arch/mips/configs/generic/board-ocelot.config
> +++ b/arch/mips/configs/generic/board-ocelot.config
>%
> +# CONFIG_HID is not set
> +# CONFIG_USB_SUPPORT is not set
> +# CONFIG_VIRTIO_MENU is not set
> +# CONFIG_SCSI is not set

Unfortunately this part won't work so well. If board-ocelot.config
disables these things, then what should happen if another board that's
also included in a generic kernel enables them?

eg. if you run 'make ARCH=mips 32r2el_defconfig' then we merge all of
the following:

  board-boston.config enables USB
  board-sead-3.config enables USB
  board-ocelot.config disables USB

These are mutually exclusive, and it seems that on my system we
currently end up disabling USB due to board-ocelot.config. That will of
course break USB support for Boston or SEAD-3 which are also supported
by the same kernel binary. In practice which one 'wins' will depend on
the order the files are listed by make's wildcard function - so far as
I'm aware that doesn't guarantee any particular order so if it ends up
depending on the order the filesystem lists the files or something like
that then configurations might even differ when used on different
machines.

So to avoid that the best we can do is leave these enabled and the
general rule is that board-*.config files can only enable extra things,
not disable them.

You might be tempted to disable the options in generic_defconfig &
update any board configs that actually need them to enable them, but
that doesn't work too well for things which are 'default y' because
kconfig then warns about the conflict between generic_defconfig & the
board config being merged with it. That applies to the first 3 of the
entries you disable, leaving only CONFIG_SCSI that could potentially be
dealt with that way...

Thanks,
    Paul