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

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

[Horatiu Vultur]

Some of the configuration were not selected by default anymore, therefore
enable them again. Also remove some configs which are used for MSCC Ocelot.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
---
 arch/mips/configs/generic/board-ocelot.config | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

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
@@ -1,6 +1,10 @@
 # require CONFIG_CPU_MIPS32_R2=y
 
 CONFIG_LEGACY_BOARD_OCELOT=y
+CONFIG_FIT_IMAGE_FDT_OCELOT=y
+
+CONFIG_BRIDGE=y
+CONFIG_GENERIC_PHY=y
 
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
@@ -19,6 +23,8 @@ CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
 
 CONFIG_NETDEVICES=y
+CONFIG_NET_SWITCHDEV=y
+CONFIG_NET_DSA=y
 CONFIG_MSCC_OCELOT_SWITCH=y
 CONFIG_MSCC_OCELOT_SWITCH_OCELOT=y
 CONFIG_MDIO_MSCC_MIIM=y
@@ -35,9 +41,22 @@ CONFIG_SPI_DESIGNWARE=y
 CONFIG_SPI_DW_MMIO=y
 CONFIG_SPI_SPIDEV=y
 
+CONFIG_PINCTRL_OCELOT=y
+
 CONFIG_GPIO_SYSFS=y
 
 CONFIG_POWER_RESET=y
 CONFIG_POWER_RESET_OCELOT_RESET=y
 
 CONFIG_MAGIC_SYSRQ=y
+
+CONFIG_MISC_FILESYSTEMS=y
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_XZ=y
+CONFIG_BLK_DEV_RAM_COUNT=2
+CONFIG_BLK_DEV_RAM_SIZE=16000
+
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_VIRTIO_MENU is not set
+# CONFIG_SCSI is not set
-- 
2.7.4

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

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

[Horatiu Vultur]

Hi Paul,

The 04/03/2019 23:23, Paul Burton wrote:
> External E-Mail
> 
> 
> 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

I didn't think about this scenario, because I didn't expect that
building a generic configuration will bring together all the board
configurations.

Anyway, I will send a new patch in which I will remove these
configurations.

> 
> 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
> 

-- 
/Horatiu