Patchwork [1/5] ARM: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)

login
register
mail settings
Submitter Brian Norris
Date April 17, 2014, 7:21 a.m.
Message ID <1397719309-2022-2-git-send-email-computersforpeace@gmail.com>
Download mbox | patch
Permalink /patch/339794/
State New
Headers show

Comments

Brian Norris - April 17, 2014, 7:21 a.m.
These defconfigs contain the CONFIG_M25P80 symbol, which is now
dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
relevant defconfigs.

At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
This change is based on l2-mtd.git/spinor, which is based on 3.15-rc1:

  git://git.infradead.org/l2-mtd.git +spinor

 arch/arm/configs/bockw_defconfig     | 2 +-
 arch/arm/configs/dove_defconfig      | 2 +-
 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 arch/arm/configs/keystone_defconfig  | 1 +
 arch/arm/configs/kirkwood_defconfig  | 1 +
 arch/arm/configs/koelsch_defconfig   | 1 +
 arch/arm/configs/lager_defconfig     | 1 +
 arch/arm/configs/lpc32xx_defconfig   | 2 +-
 arch/arm/configs/multi_v5_defconfig  | 1 +
 arch/arm/configs/multi_v7_defconfig  | 1 +
 arch/arm/configs/mvebu_v5_defconfig  | 1 +
 arch/arm/configs/mvebu_v7_defconfig  | 1 +
 arch/arm/configs/mxs_defconfig       | 1 +
 arch/arm/configs/sama5_defconfig     | 2 +-
 arch/arm/configs/shmobile_defconfig  | 1 +
 arch/arm/configs/tegra_defconfig     | 1 +
 16 files changed, 16 insertions(+), 4 deletions(-)
Marek Vasut - April 17, 2014, 11:08 a.m.
On Thursday, April 17, 2014 at 09:21:45 AM, Brian Norris wrote:
> These defconfigs contain the CONFIG_M25P80 symbol, which is now
> dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> relevant defconfigs.
> 
> At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
> 
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Shawn Guo <shawn.guo@freescale.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---

mxs_defconfig is
Reviewed-by: Marek Vasut <marex@denx.de>

Best regards,
Marek Vasut
Huang Shijie - April 21, 2014, 2:32 a.m.
On Thu, Apr 17, 2014 at 12:21:45AM -0700, Brian Norris wrote:
> These defconfigs contain the CONFIG_M25P80 symbol, which is now
> dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> relevant defconfigs.
> 
> At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
> 
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Shawn Guo <shawn.guo@freescale.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> This change is based on l2-mtd.git/spinor, which is based on 3.15-rc1:
> 
>   git://git.infradead.org/l2-mtd.git +spinor
> 
>  arch/arm/configs/bockw_defconfig     | 2 +-
>  arch/arm/configs/dove_defconfig      | 2 +-
>  arch/arm/configs/imx_v6_v7_defconfig | 1 +
>  arch/arm/configs/keystone_defconfig  | 1 +
>  arch/arm/configs/kirkwood_defconfig  | 1 +
>  arch/arm/configs/koelsch_defconfig   | 1 +
>  arch/arm/configs/lager_defconfig     | 1 +
>  arch/arm/configs/lpc32xx_defconfig   | 2 +-
>  arch/arm/configs/multi_v5_defconfig  | 1 +
>  arch/arm/configs/multi_v7_defconfig  | 1 +
>  arch/arm/configs/mvebu_v5_defconfig  | 1 +
>  arch/arm/configs/mvebu_v7_defconfig  | 1 +
>  arch/arm/configs/mxs_defconfig       | 1 +
>  arch/arm/configs/sama5_defconfig     | 2 +-
>  arch/arm/configs/shmobile_defconfig  | 1 +
>  arch/arm/configs/tegra_defconfig     | 1 +
>  16 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/configs/bockw_defconfig b/arch/arm/configs/bockw_defconfig
> index e816140d81c5..28339e072a71 100644
> --- a/arch/arm/configs/bockw_defconfig
> +++ b/arch/arm/configs/bockw_defconfig
> @@ -50,11 +50,11 @@ CONFIG_DEVTMPFS_MOUNT=y
>  # CONFIG_PREVENT_FIRMWARE_BUILD is not set
>  # CONFIG_FW_LOADER is not set
>  CONFIG_MTD=y
> -CONFIG_MTD_CHAR=y
>  CONFIG_MTD_BLOCK=y
>  CONFIG_MTD_CFI=y
>  CONFIG_MTD_CFI_AMDSTD=y
>  CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_SCSI=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_NETDEVICES=y
> diff --git a/arch/arm/configs/dove_defconfig b/arch/arm/configs/dove_defconfig
> index f15955144175..701677f9248c 100644
> --- a/arch/arm/configs/dove_defconfig
> +++ b/arch/arm/configs/dove_defconfig
> @@ -37,7 +37,6 @@ CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_MTD=y
>  CONFIG_MTD_CMDLINE_PARTS=y
> -CONFIG_MTD_CHAR=y
>  CONFIG_MTD_BLOCK=y
>  CONFIG_MTD_CFI=y
>  CONFIG_MTD_JEDECPROBE=y
> @@ -48,6 +47,7 @@ CONFIG_MTD_CFI_INTELEXT=y
>  CONFIG_MTD_CFI_STAA=y
>  CONFIG_MTD_PHYSMAP=y
>  CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_BLK_DEV_RAM=y
>  CONFIG_BLK_DEV_RAM_COUNT=1
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
> index 09e974392fa1..c098195e9bd3 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -89,6 +89,7 @@ CONFIG_MTD_SST25L=y
>  CONFIG_MTD_NAND=y
>  CONFIG_MTD_NAND_GPMI_NAND=y
>  CONFIG_MTD_NAND_MXC=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_MTD_UBI=y
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_BLK_DEV_RAM=y
> diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
> index ec9a41d50680..b3057730689f 100644
> --- a/arch/arm/configs/keystone_defconfig
> +++ b/arch/arm/configs/keystone_defconfig
> @@ -112,6 +112,7 @@ CONFIG_MTD_PLATRAM=y
>  CONFIG_MTD_M25P80=y
>  CONFIG_MTD_NAND=y
>  CONFIG_MTD_NAND_DAVINCI=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_MTD_UBI=y
>  CONFIG_PROC_DEVICETREE=y
>  CONFIG_BLK_DEV_LOOP=y
> diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
> index 2e762d94e94b..b9e480c10b10 100644
> --- a/arch/arm/configs/kirkwood_defconfig
> +++ b/arch/arm/configs/kirkwood_defconfig
> @@ -61,6 +61,7 @@ CONFIG_MTD_PHYSMAP=y
>  CONFIG_MTD_M25P80=y
>  CONFIG_MTD_NAND=y
>  CONFIG_MTD_NAND_ORION=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_EEPROM_AT24=y
>  # CONFIG_SCSI_PROC_FS is not set
> diff --git a/arch/arm/configs/koelsch_defconfig b/arch/arm/configs/koelsch_defconfig
> index 86faab565a96..dcd55f20d36e 100644
> --- a/arch/arm/configs/koelsch_defconfig
> +++ b/arch/arm/configs/koelsch_defconfig
> @@ -42,6 +42,7 @@ CONFIG_ATA=y
>  CONFIG_SATA_RCAR=y
>  CONFIG_MTD=y
>  CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_NETDEVICES=y
>  # CONFIG_NET_VENDOR_ARC is not set
>  # CONFIG_NET_CADENCE is not set
> diff --git a/arch/arm/configs/lager_defconfig b/arch/arm/configs/lager_defconfig
> index 58702440472a..c4dbd778458b 100644
> --- a/arch/arm/configs/lager_defconfig
> +++ b/arch/arm/configs/lager_defconfig
> @@ -53,6 +53,7 @@ CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_MTD=y
>  CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_ATA=y
>  CONFIG_SATA_RCAR=y
> diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
> index 398a367ffce8..2de54c35fb47 100644
> --- a/arch/arm/configs/lpc32xx_defconfig
> +++ b/arch/arm/configs/lpc32xx_defconfig
> @@ -53,12 +53,12 @@ CONFIG_DEVTMPFS_MOUNT=y
>  # CONFIG_FW_LOADER is not set
>  CONFIG_MTD=y
>  CONFIG_MTD_CMDLINE_PARTS=y
> -CONFIG_MTD_CHAR=y
>  CONFIG_MTD_BLOCK=y
>  CONFIG_MTD_M25P80=y
>  CONFIG_MTD_NAND=y
>  CONFIG_MTD_NAND_SLC_LPC32XX=y
>  CONFIG_MTD_NAND_MLC_LPC32XX=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_BLK_DEV_CRYPTOLOOP=y
>  CONFIG_BLK_DEV_RAM=y
> diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
> index aa3dfb084fed..aaf23933fb91 100644
> --- a/arch/arm/configs/multi_v5_defconfig
> +++ b/arch/arm/configs/multi_v5_defconfig
> @@ -56,6 +56,7 @@ CONFIG_MTD_PHYSMAP=y
>  CONFIG_MTD_M25P80=y
>  CONFIG_MTD_NAND=y
>  CONFIG_MTD_NAND_ORION=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_EEPROM_AT24=y
>  # CONFIG_SCSI_PROC_FS is not set
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index d4e8a47a2f7c..9937db16050c 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -108,6 +108,7 @@ CONFIG_CMA_SIZE_MBYTES=64
>  CONFIG_OMAP_OCP2SCP=y
>  CONFIG_MTD=y
>  CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_ICS932S401=y
>  CONFIG_APDS9802ALS=y
> diff --git a/arch/arm/configs/mvebu_v5_defconfig b/arch/arm/configs/mvebu_v5_defconfig
> index 36484a37a1ca..85d20666cef5 100644
> --- a/arch/arm/configs/mvebu_v5_defconfig
> +++ b/arch/arm/configs/mvebu_v5_defconfig
> @@ -50,6 +50,7 @@ CONFIG_MTD_PHYSMAP=y
>  CONFIG_MTD_M25P80=y
>  CONFIG_MTD_NAND=y
>  CONFIG_MTD_NAND_ORION=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_EEPROM_AT24=y
>  # CONFIG_SCSI_PROC_FS is not set
> diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
> index a34713d8db9f..ae45bf05fa00 100644
> --- a/arch/arm/configs/mvebu_v7_defconfig
> +++ b/arch/arm/configs/mvebu_v7_defconfig
> @@ -53,6 +53,7 @@ CONFIG_I2C_MV64XXX=y
>  CONFIG_MTD=y
>  CONFIG_MTD_CHAR=y
>  CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_MTD_CFI=y
>  CONFIG_MTD_CFI_INTELEXT=y
>  CONFIG_MTD_CFI_AMDSTD=y
> diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
> index 6150108e15de..eac87f4fae07 100644
> --- a/arch/arm/configs/mxs_defconfig
> +++ b/arch/arm/configs/mxs_defconfig
> @@ -55,6 +55,7 @@ CONFIG_MTD_M25P80=y
>  CONFIG_MTD_SST25L=y
>  CONFIG_MTD_NAND=y
>  CONFIG_MTD_NAND_GPMI_NAND=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_MTD_UBI=y
>  # CONFIG_BLK_DEV is not set
>  CONFIG_EEPROM_AT24=y
> diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
> index dc3881e07630..8282ebab6e52 100644
> --- a/arch/arm/configs/sama5_defconfig
> +++ b/arch/arm/configs/sama5_defconfig
> @@ -65,12 +65,12 @@ CONFIG_DEVTMPFS_MOUNT=y
>  # CONFIG_PREVENT_FIRMWARE_BUILD is not set
>  CONFIG_MTD=y
>  CONFIG_MTD_CMDLINE_PARTS=y
> -CONFIG_MTD_CHAR=y
>  CONFIG_MTD_BLOCK=y
>  CONFIG_MTD_CFI=y
>  CONFIG_MTD_M25P80=y
>  CONFIG_MTD_NAND=y
>  CONFIG_MTD_NAND_ATMEL=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_MTD_UBI=y
>  CONFIG_MTD_UBI_GLUEBI=y
>  CONFIG_PROC_DEVICETREE=y
> diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
> index 83b07258a385..ddfdc36be9c8 100644
> --- a/arch/arm/configs/shmobile_defconfig
> +++ b/arch/arm/configs/shmobile_defconfig
> @@ -43,6 +43,7 @@ CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_MTD=y
>  CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_ATA=y
>  CONFIG_SATA_RCAR=y
> diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
> index 2926281368ab..e4464986d7b4 100644
> --- a/arch/arm/configs/tegra_defconfig
> +++ b/arch/arm/configs/tegra_defconfig
> @@ -90,6 +90,7 @@ CONFIG_DMA_CMA=y
>  CONFIG_CMA_SIZE_MBYTES=64
>  CONFIG_MTD=y
>  CONFIG_MTD_M25P80=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_PROC_DEVICETREE=y
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_AD525X_DPOT=y
> -- 
I think we should not use the "select", since the SPI-NOR framework also depends
on the MTD code.

For the mxs_defconfig and imx_v6_v7_defconfig

Acked-by: Huang Shijie <b32955@freescale.com>
Stephen Warren - April 25, 2014, 4:39 p.m.
On 04/17/2014 01:21 AM, Brian Norris wrote:
> These defconfigs contain the CONFIG_M25P80 symbol, which is now
> dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> relevant defconfigs.
> 
> At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.

I hadn't realized that the problem this patch solves was already present
in the code, so this patch is simply catching up the defconfigs rather
than part of a series which changed the code to cause the problem.

So, this needs to be applied ASAP.

I think this should be split it up so that each defconfig can go through
the tree that owns it to avoid conflicts. If you repost split up, I can
apply the tegra_defconfig change to the Tegra tree.
Ezequiel Garcia - April 29, 2014, 5:22 p.m.
On Apr 25, Stephen Warren wrote:
> On 04/17/2014 01:21 AM, Brian Norris wrote:
> > These defconfigs contain the CONFIG_M25P80 symbol, which is now
> > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> > relevant defconfigs.
> > 
> > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
> 
> I hadn't realized that the problem this patch solves was already present
> in the code, so this patch is simply catching up the defconfigs rather
> than part of a series which changed the code to cause the problem.
> 
> So, this needs to be applied ASAP.
> 

What's the status of this?

> I think this should be split it up so that each defconfig can go through
> the tree that owns it to avoid conflicts. If you repost split up, I can
> apply the tegra_defconfig change to the Tegra tree.
> 

Probably the same for mvebu (Ccing Jason).
Jason - April 29, 2014, 5:48 p.m.
On Tue, Apr 29, 2014 at 02:22:27PM -0300, Ezequiel Garcia wrote:
> On Apr 25, Stephen Warren wrote:
> > On 04/17/2014 01:21 AM, Brian Norris wrote:
> > > These defconfigs contain the CONFIG_M25P80 symbol, which is now
> > > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> > > relevant defconfigs.
> > > 
> > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.

Excuse my ignorance of the history of this bug, but shouldn't this be
solved in the Kconfig logic?  Since when do we solve config symbol
dependency bugs in the defconfigs?

> > I hadn't realized that the problem this patch solves was already present
> > in the code, so this patch is simply catching up the defconfigs rather
> > than part of a series which changed the code to cause the problem.
> > 
> > So, this needs to be applied ASAP.
> > 
> 
> What's the status of this?
> 
> > I think this should be split it up so that each defconfig can go through
> > the tree that owns it to avoid conflicts. If you repost split up, I can
> > apply the tegra_defconfig change to the Tegra tree.
> > 
> 
> Probably the same for mvebu (Ccing Jason).

confused.

Jason.
Ezequiel Garcia - April 29, 2014, 6:28 p.m.
On Apr 29, Jason Cooper wrote:
> On Tue, Apr 29, 2014 at 02:22:27PM -0300, Ezequiel Garcia wrote:
> > On Apr 25, Stephen Warren wrote:
> > > On 04/17/2014 01:21 AM, Brian Norris wrote:
> > > > These defconfigs contain the CONFIG_M25P80 symbol, which is now
> > > > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> > > > relevant defconfigs.
> > > > 
> > > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
> 
> Excuse my ignorance of the history of this bug, but shouldn't this be
> solved in the Kconfig logic?  Since when do we solve config symbol
> dependency bugs in the defconfigs?
> 

Long story short: it was decided that select'ing this new symbol was not
appropriate. Instead, it must be explicitly selected by the user, hence
the defconfig fix.

The full story: https://lkml.org/lkml/2014/4/17/45

And in particular: https://lkml.org/lkml/2014/4/21/425
Jason - April 29, 2014, 6:55 p.m.
On Tue, Apr 29, 2014 at 03:28:15PM -0300, Ezequiel Garcia wrote:
> On Apr 29, Jason Cooper wrote:
> > On Tue, Apr 29, 2014 at 02:22:27PM -0300, Ezequiel Garcia wrote:
> > > On Apr 25, Stephen Warren wrote:
> > > > On 04/17/2014 01:21 AM, Brian Norris wrote:
> > > > > These defconfigs contain the CONFIG_M25P80 symbol, which is now
> > > > > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> > > > > relevant defconfigs.
> > > > > 
> > > > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
> > 
> > Excuse my ignorance of the history of this bug, but shouldn't this be
> > solved in the Kconfig logic?  Since when do we solve config symbol
> > dependency bugs in the defconfigs?
> > 
> 
> Long story short: it was decided that select'ing this new symbol was not
> appropriate. Instead, it must be explicitly selected by the user, hence
> the defconfig fix.
> 
> The full story: https://lkml.org/lkml/2014/4/17/45

ahhh, it already depend's on MTD_SPI_NOR in Kconfig

  http://git.infradead.org/l2-mtd.git/blobdiff/254592db612aeb55d80399a04995b68f7da48c99..e43b20619bdb6c851dd7b49cbd15e52875a785d4:/drivers/mtd/devices/Kconfig

ok, now it makes sense.

Acked-by: Jason Cooper <jason@lakedaemon.net>

thx,

Jason.
Brian Norris - April 29, 2014, 7:06 p.m.
Hi Stephen,

On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:
> On 04/17/2014 01:21 AM, Brian Norris wrote:
> > These defconfigs contain the CONFIG_M25P80 symbol, which is now
> > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> > relevant defconfigs.
> > 
> > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
> 
> I hadn't realized that the problem this patch solves was already present
> in the code, so this patch is simply catching up the defconfigs rather
> than part of a series which changed the code to cause the problem.

Yes, this is "catching up the defconfigs." The SPI_NOR framework is new,
and I didn't want to generate defconfig noise until a few things
stabilized (particularly, its Kconfig symbol name).

> So, this needs to be applied ASAP.
> 
> I think this should be split it up so that each defconfig can go through
> the tree that owns it to avoid conflicts. If you repost split up, I can
> apply the tegra_defconfig change to the Tegra tree.

OK, I'll try to split it up. Is ARM unique in tracking defconfigs in
separate trees? I assume MIPS, PowerPC, and Blackfin won't require the
same splitting? I'd like to avoid 31 patches when <20 could suffice.

I'll also rebase on linux-next. I think there may be a few conflicts.

Thanks,
Brian
Ezequiel Garcia - April 29, 2014, 7:22 p.m.
On Apr 29, Brian Norris wrote:
> Hi Stephen,
> 
> On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:
> > On 04/17/2014 01:21 AM, Brian Norris wrote:
> > > These defconfigs contain the CONFIG_M25P80 symbol, which is now
> > > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> > > relevant defconfigs.
> > > 
> > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
> > 
> > I hadn't realized that the problem this patch solves was already present
> > in the code, so this patch is simply catching up the defconfigs rather
> > than part of a series which changed the code to cause the problem.
> 
> Yes, this is "catching up the defconfigs." The SPI_NOR framework is new,
> and I didn't want to generate defconfig noise until a few things
> stabilized (particularly, its Kconfig symbol name).
> 
> > So, this needs to be applied ASAP.
> > 
> > I think this should be split it up so that each defconfig can go through
> > the tree that owns it to avoid conflicts. If you repost split up, I can
> > apply the tegra_defconfig change to the Tegra tree.
> 
> OK, I'll try to split it up. Is ARM unique in tracking defconfigs in
> separate trees? I assume MIPS, PowerPC, and Blackfin won't require the
> same splitting? I'd like to avoid 31 patches when <20 could suffice.
> 
> I'll also rebase on linux-next. I think there may be a few conflicts.
> 

FWIW, I can take care of the patch for mvebu. Just drop it from your set
and I'll prepare one for Jason.
Stephen Warren - April 29, 2014, 7:42 p.m.
On 04/29/2014 01:06 PM, Brian Norris wrote:
> Hi Stephen,
> 
> On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:
>> On 04/17/2014 01:21 AM, Brian Norris wrote:
>>> These defconfigs contain the CONFIG_M25P80 symbol, which is now
>>> dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
>>> relevant defconfigs.
>>>
>>> At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
...
>> I think this should be split it up so that each defconfig can go through
>> the tree that owns it to avoid conflicts. If you repost split up, I can
>> apply the tegra_defconfig change to the Tegra tree.
> 
> OK, I'll try to split it up. Is ARM unique in tracking defconfigs in
> separate trees? I assume MIPS, PowerPC, and Blackfin won't require the
> same splitting? I'd like to avoid 31 patches when <20 could suffice.

Sorry, I have no idea how the other arches handle defconfigs:-(

I guess you could also just see if arm-soc (arm@kernel.org) will take
this patch, and deal with any merge conflicts that arise when they merge
all the sub-arch defconfig changes. I CC'd them to find out if they
think that's a better idea.
Huang Shijie - April 30, 2014, 5:39 a.m.
On Tue, Apr 29, 2014 at 12:06:03PM -0700, Brian Norris wrote:
> OK, I'll try to split it up. Is ARM unique in tracking defconfigs in
> separate trees? I assume MIPS, PowerPC, and Blackfin won't require the
> same splitting? I'd like to avoid 31 patches when <20 could suffice.
> 
> I'll also rebase on linux-next. I think there may be a few conflicts.
Hi Brian:
  If we need to split the patch, please keep the mxs_defconfig and 
  imx_v6_v7_defconfig in a single patch,
  Shawn will review and merge or ack that patch.

  thanks
  Huang Shijie
Jason - April 30, 2014, 11:45 a.m.
On Tue, Apr 29, 2014 at 12:06:03PM -0700, Brian Norris wrote:
> Hi Stephen,
> 
> On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:
> > On 04/17/2014 01:21 AM, Brian Norris wrote:
> > > These defconfigs contain the CONFIG_M25P80 symbol, which is now
> > > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> > > relevant defconfigs.
> > > 
> > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
> > 
> > I hadn't realized that the problem this patch solves was already present
> > in the code, so this patch is simply catching up the defconfigs rather
> > than part of a series which changed the code to cause the problem.
> 
> Yes, this is "catching up the defconfigs." The SPI_NOR framework is new,
> and I didn't want to generate defconfig noise until a few things
> stabilized (particularly, its Kconfig symbol name).
> 
> > So, this needs to be applied ASAP.
> > 
> > I think this should be split it up so that each defconfig can go through
> > the tree that owns it to avoid conflicts. If you repost split up, I can
> > apply the tegra_defconfig change to the Tegra tree.
> 
> OK, I'll try to split it up. Is ARM unique in tracking defconfigs in
> separate trees? I assume MIPS, PowerPC, and Blackfin won't require the
> same splitting? I'd like to avoid 31 patches when <20 could suffice.

wrt arm-soc, typically they take all changes to multi_v7_defconfig
directly since it is prone to conflicts.  All the other ones are managed
by the individual sub-arch maintainers.

> I'll also rebase on linux-next. I think there may be a few conflicts.

I can't speak for the other sub-archs, but I typically prefer that
patches be based on an -rc tag, -rc1 if possible.

thx,

Jason.
Brian Norris - May 1, 2014, 6:04 a.m.
On Tue, Apr 29, 2014 at 04:22:08PM -0300, Ezequiel Garcia wrote:
> FWIW, I can take care of the patch for mvebu. Just drop it from your set
> and I'll prepare one for Jason.

I'm splitting all the others out, so I'll just keep the mvebu one
(combined with Jason's other Marvell platforms) all together in my
series, if you don't mind. Thanks for the offer though.

Brian
Brian Norris - May 1, 2014, 6:07 a.m.
On Tue, Apr 29, 2014 at 01:42:50PM -0600, Stephen Warren wrote:
> I guess you could also just see if arm-soc (arm@kernel.org) will take
> this patch, and deal with any merge conflicts that arise when they merge
> all the sub-arch defconfig changes. I CC'd them to find out if they
> think that's a better idea.

I'm preparing a split patch series and should send v2 shortly. A few of
the unaccounted platforms + the multi-platform are lumped together for
direct inclusion in arm-soc (?).

What is this arm@kernel.org you speak of? My Google-fu doesn't turn up a
separate arm-soc email / mailing list, and it's not in MAINTAINERS.

Brian
Brian Norris - May 1, 2014, 6:08 a.m.
On Wed, Apr 30, 2014 at 07:45:48AM -0400, Jason Cooper wrote:
> On Tue, Apr 29, 2014 at 12:06:03PM -0700, Brian Norris wrote:
> > I'll also rebase on linux-next. I think there may be a few conflicts.
> 
> I can't speak for the other sub-archs, but I typically prefer that
> patches be based on an -rc tag, -rc1 if possible.

OK, this was already based on -rc1. I'll leave it as-is, and maintainers
can easily work out the conflicts.

Thanks,
Brian
Stephen Warren - May 1, 2014, 4:48 p.m.
On 05/01/2014 12:07 AM, Brian Norris wrote:
> On Tue, Apr 29, 2014 at 01:42:50PM -0600, Stephen Warren wrote:
>> I guess you could also just see if arm-soc (arm@kernel.org) will take
>> this patch, and deal with any merge conflicts that arise when they merge
>> all the sub-arch defconfig changes. I CC'd them to find out if they
>> think that's a better idea.
> 
> I'm preparing a split patch series and should send v2 shortly. A few of
> the unaccounted platforms + the multi-platform are lumped together for
> direct inclusion in arm-soc (?).
> 
> What is this arm@kernel.org you speak of? My Google-fu doesn't turn up a
> separate arm-soc email / mailing list, and it's not in MAINTAINERS.

It's the email address of the ARM SoC maintainers (Arnd, Olof, Kevin).
All the ARM sub-architecture maintainers send their pull requests there,
which all get aggregated and forwarded to Linus. They also take some
patches directly, for cross-sub-architecture stuff like
multi_v7_defconfig, or small amounts of bug-fixes after the main pull
requests are sent.
Olof Johansson - May 3, 2014, 10:51 p.m.
On Wed, Apr 30, 2014 at 4:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Tue, Apr 29, 2014 at 12:06:03PM -0700, Brian Norris wrote:
>> Hi Stephen,
>>
>> On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:
>> > On 04/17/2014 01:21 AM, Brian Norris wrote:
>> > > These defconfigs contain the CONFIG_M25P80 symbol, which is now
>> > > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
>> > > relevant defconfigs.
>> > >
>> > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
>> >
>> > I hadn't realized that the problem this patch solves was already present
>> > in the code, so this patch is simply catching up the defconfigs rather
>> > than part of a series which changed the code to cause the problem.
>>
>> Yes, this is "catching up the defconfigs." The SPI_NOR framework is new,
>> and I didn't want to generate defconfig noise until a few things
>> stabilized (particularly, its Kconfig symbol name).
>>
>> > So, this needs to be applied ASAP.
>> >
>> > I think this should be split it up so that each defconfig can go through
>> > the tree that owns it to avoid conflicts. If you repost split up, I can
>> > apply the tegra_defconfig change to the Tegra tree.
>>
>> OK, I'll try to split it up. Is ARM unique in tracking defconfigs in
>> separate trees? I assume MIPS, PowerPC, and Blackfin won't require the
>> same splitting? I'd like to avoid 31 patches when <20 could suffice.
>
> wrt arm-soc, typically they take all changes to multi_v7_defconfig
> directly since it is prone to conflicts.  All the other ones are managed
> by the individual sub-arch maintainers.
>
>> I'll also rebase on linux-next. I think there may be a few conflicts.
>
> I can't speak for the other sub-archs, but I typically prefer that
> patches be based on an -rc tag, -rc1 if possible.

This is making a trivial patch a pain to get merged.

Cases like these are easiest that we just take the patch directly in
an early-merge branch (i.e. cleanup or fixes-non-critical, or a
generic depends branch), and if there's conflicts as topics are merged
in from subplatforms we can deal with it then.


-Olof
Jason - May 4, 2014, 5:42 p.m.
On Sat, May 03, 2014 at 03:51:11PM -0700, Olof Johansson wrote:
> On Wed, Apr 30, 2014 at 4:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Tue, Apr 29, 2014 at 12:06:03PM -0700, Brian Norris wrote:
> >> Hi Stephen,
> >>
> >> On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:
> >> > On 04/17/2014 01:21 AM, Brian Norris wrote:
> >> > > These defconfigs contain the CONFIG_M25P80 symbol, which is now
> >> > > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> >> > > relevant defconfigs.
> >> > >
> >> > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
> >> >
> >> > I hadn't realized that the problem this patch solves was already present
> >> > in the code, so this patch is simply catching up the defconfigs rather
> >> > than part of a series which changed the code to cause the problem.
> >>
> >> Yes, this is "catching up the defconfigs." The SPI_NOR framework is new,
> >> and I didn't want to generate defconfig noise until a few things
> >> stabilized (particularly, its Kconfig symbol name).
> >>
> >> > So, this needs to be applied ASAP.
> >> >
> >> > I think this should be split it up so that each defconfig can go through
> >> > the tree that owns it to avoid conflicts. If you repost split up, I can
> >> > apply the tegra_defconfig change to the Tegra tree.
> >>
> >> OK, I'll try to split it up. Is ARM unique in tracking defconfigs in
> >> separate trees? I assume MIPS, PowerPC, and Blackfin won't require the
> >> same splitting? I'd like to avoid 31 patches when <20 could suffice.
> >
> > wrt arm-soc, typically they take all changes to multi_v7_defconfig
> > directly since it is prone to conflicts.  All the other ones are managed
> > by the individual sub-arch maintainers.
> >
> >> I'll also rebase on linux-next. I think there may be a few conflicts.
> >
> > I can't speak for the other sub-archs, but I typically prefer that
> > patches be based on an -rc tag, -rc1 if possible.
> 
> This is making a trivial patch a pain to get merged.

Sorry.

> Cases like these are easiest that we just take the patch directly in
> an early-merge branch (i.e. cleanup or fixes-non-critical, or a
> generic depends branch), and if there's conflicts as topics are merged
> in from subplatforms we can deal with it then.

Are you referring to basing on -rc1, or the series being split up to
the individual sub-arch maintainers?

*slightly* confused,

Jason.
Olof Johansson - May 4, 2014, 6:53 p.m.
On Sun, May 4, 2014 at 10:42 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Sat, May 03, 2014 at 03:51:11PM -0700, Olof Johansson wrote:
>> On Wed, Apr 30, 2014 at 4:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
>> > On Tue, Apr 29, 2014 at 12:06:03PM -0700, Brian Norris wrote:
>> >> Hi Stephen,
>> >>
>> >> On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:
>> >> > On 04/17/2014 01:21 AM, Brian Norris wrote:
>> >> > > These defconfigs contain the CONFIG_M25P80 symbol, which is now
>> >> > > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
>> >> > > relevant defconfigs.
>> >> > >
>> >> > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
>> >> >
>> >> > I hadn't realized that the problem this patch solves was already present
>> >> > in the code, so this patch is simply catching up the defconfigs rather
>> >> > than part of a series which changed the code to cause the problem.
>> >>
>> >> Yes, this is "catching up the defconfigs." The SPI_NOR framework is new,
>> >> and I didn't want to generate defconfig noise until a few things
>> >> stabilized (particularly, its Kconfig symbol name).
>> >>
>> >> > So, this needs to be applied ASAP.
>> >> >
>> >> > I think this should be split it up so that each defconfig can go through
>> >> > the tree that owns it to avoid conflicts. If you repost split up, I can
>> >> > apply the tegra_defconfig change to the Tegra tree.
>> >>
>> >> OK, I'll try to split it up. Is ARM unique in tracking defconfigs in
>> >> separate trees? I assume MIPS, PowerPC, and Blackfin won't require the
>> >> same splitting? I'd like to avoid 31 patches when <20 could suffice.
>> >
>> > wrt arm-soc, typically they take all changes to multi_v7_defconfig
>> > directly since it is prone to conflicts.  All the other ones are managed
>> > by the individual sub-arch maintainers.
>> >
>> >> I'll also rebase on linux-next. I think there may be a few conflicts.
>> >
>> > I can't speak for the other sub-archs, but I typically prefer that
>> > patches be based on an -rc tag, -rc1 if possible.
>>
>> This is making a trivial patch a pain to get merged.
>
> Sorry.

No worries.

>> Cases like these are easiest that we just take the patch directly in
>> an early-merge branch (i.e. cleanup or fixes-non-critical, or a
>> generic depends branch), and if there's conflicts as topics are merged
>> in from subplatforms we can deal with it then.
>
> Are you referring to basing on -rc1, or the series being split up to
> the individual sub-arch maintainers?
>
> *slightly* confused,

I'm referring to us taking the patch into something like our cleanup
branch, and any branches that come in from you or other subplatforms
will be merged on top, so we can resolve conflicts there and then.
We'll merge in the cleanup branch into other next/* branches as needed
to resolve the conflicts in our tree instead of percolating them all
the way up.



-Olof
Brian Norris - May 6, 2014, 5:05 p.m.
On Sun, May 04, 2014 at 11:53:22AM -0700, Olof Johansson wrote:
> On Sun, May 4, 2014 at 10:42 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Sat, May 03, 2014 at 03:51:11PM -0700, Olof Johansson wrote:
> >> Cases like these are easiest that we just take the patch directly in
> >> an early-merge branch (i.e. cleanup or fixes-non-critical, or a
> >> generic depends branch), and if there's conflicts as topics are merged
> >> in from subplatforms we can deal with it then.
> >
> > Are you referring to basing on -rc1, or the series being split up to
> > the individual sub-arch maintainers?
> >
> > *slightly* confused,
> 
> I'm referring to us taking the patch into something like our cleanup
> branch, and any branches that come in from you or other subplatforms
> will be merged on top, so we can resolve conflicts there and then.
> We'll merge in the cleanup branch into other next/* branches as needed
> to resolve the conflicts in our tree instead of percolating them all
> the way up.

In case you didn't notice, I already had split up the patch series a
little more for v2 (based on -rc1 still), and most of it seems to be
going through the sub-arch trees, I think. There is one patch targeted
directly at arm-soc (that's you, Olof?).

Let me know if v2 has any problems.

Thanks,
Brian

Patch

diff --git a/arch/arm/configs/bockw_defconfig b/arch/arm/configs/bockw_defconfig
index e816140d81c5..28339e072a71 100644
--- a/arch/arm/configs/bockw_defconfig
+++ b/arch/arm/configs/bockw_defconfig
@@ -50,11 +50,11 @@  CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FW_LOADER is not set
 CONFIG_MTD=y
-CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_CFI=y
 CONFIG_MTD_CFI_AMDSTD=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
diff --git a/arch/arm/configs/dove_defconfig b/arch/arm/configs/dove_defconfig
index f15955144175..701677f9248c 100644
--- a/arch/arm/configs/dove_defconfig
+++ b/arch/arm/configs/dove_defconfig
@@ -37,7 +37,6 @@  CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_CFI=y
 CONFIG_MTD_JEDECPROBE=y
@@ -48,6 +47,7 @@  CONFIG_MTD_CFI_INTELEXT=y
 CONFIG_MTD_CFI_STAA=y
 CONFIG_MTD_PHYSMAP=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_COUNT=1
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 09e974392fa1..c098195e9bd3 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -89,6 +89,7 @@  CONFIG_MTD_SST25L=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_GPMI_NAND=y
 CONFIG_MTD_NAND_MXC=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index ec9a41d50680..b3057730689f 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -112,6 +112,7 @@  CONFIG_MTD_PLATRAM=y
 CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_DAVINCI=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_MTD_UBI=y
 CONFIG_PROC_DEVICETREE=y
 CONFIG_BLK_DEV_LOOP=y
diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 2e762d94e94b..b9e480c10b10 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -61,6 +61,7 @@  CONFIG_MTD_PHYSMAP=y
 CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_ORION=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_EEPROM_AT24=y
 # CONFIG_SCSI_PROC_FS is not set
diff --git a/arch/arm/configs/koelsch_defconfig b/arch/arm/configs/koelsch_defconfig
index 86faab565a96..dcd55f20d36e 100644
--- a/arch/arm/configs/koelsch_defconfig
+++ b/arch/arm/configs/koelsch_defconfig
@@ -42,6 +42,7 @@  CONFIG_ATA=y
 CONFIG_SATA_RCAR=y
 CONFIG_MTD=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_ARC is not set
 # CONFIG_NET_CADENCE is not set
diff --git a/arch/arm/configs/lager_defconfig b/arch/arm/configs/lager_defconfig
index 58702440472a..c4dbd778458b 100644
--- a/arch/arm/configs/lager_defconfig
+++ b/arch/arm/configs/lager_defconfig
@@ -53,6 +53,7 @@  CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_MTD=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_SATA_RCAR=y
diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
index 398a367ffce8..2de54c35fb47 100644
--- a/arch/arm/configs/lpc32xx_defconfig
+++ b/arch/arm/configs/lpc32xx_defconfig
@@ -53,12 +53,12 @@  CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_SLC_LPC32XX=y
 CONFIG_MTD_NAND_MLC_LPC32XX=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_CRYPTOLOOP=y
 CONFIG_BLK_DEV_RAM=y
diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index aa3dfb084fed..aaf23933fb91 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -56,6 +56,7 @@  CONFIG_MTD_PHYSMAP=y
 CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_ORION=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_EEPROM_AT24=y
 # CONFIG_SCSI_PROC_FS is not set
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index d4e8a47a2f7c..9937db16050c 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -108,6 +108,7 @@  CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_OMAP_OCP2SCP=y
 CONFIG_MTD=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_ICS932S401=y
 CONFIG_APDS9802ALS=y
diff --git a/arch/arm/configs/mvebu_v5_defconfig b/arch/arm/configs/mvebu_v5_defconfig
index 36484a37a1ca..85d20666cef5 100644
--- a/arch/arm/configs/mvebu_v5_defconfig
+++ b/arch/arm/configs/mvebu_v5_defconfig
@@ -50,6 +50,7 @@  CONFIG_MTD_PHYSMAP=y
 CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_ORION=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_EEPROM_AT24=y
 # CONFIG_SCSI_PROC_FS is not set
diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index a34713d8db9f..ae45bf05fa00 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -53,6 +53,7 @@  CONFIG_I2C_MV64XXX=y
 CONFIG_MTD=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_MTD_CFI=y
 CONFIG_MTD_CFI_INTELEXT=y
 CONFIG_MTD_CFI_AMDSTD=y
diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index 6150108e15de..eac87f4fae07 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -55,6 +55,7 @@  CONFIG_MTD_M25P80=y
 CONFIG_MTD_SST25L=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_GPMI_NAND=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_MTD_UBI=y
 # CONFIG_BLK_DEV is not set
 CONFIG_EEPROM_AT24=y
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index dc3881e07630..8282ebab6e52 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -65,12 +65,12 @@  CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_CFI=y
 CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_ATMEL=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_MTD_UBI=y
 CONFIG_MTD_UBI_GLUEBI=y
 CONFIG_PROC_DEVICETREE=y
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 83b07258a385..ddfdc36be9c8 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -43,6 +43,7 @@  CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_MTD=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_SATA_RCAR=y
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 2926281368ab..e4464986d7b4 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -90,6 +90,7 @@  CONFIG_DMA_CMA=y
 CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_MTD=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
 CONFIG_PROC_DEVICETREE=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_AD525X_DPOT=y