[PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)

[PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)

[Brian Norris]

Hi all,

We are introducing a new SPI-NOR library/framework for MTD, to support various
types of SPI-NOR flash controllers which require (or benefit from) intimate
knowledge of the flash interface, rather than just the relatively dumb SPI
interface. This library borrows much of the m25p80 driver for its abstraction
and moves this code into a spi-nor module.

This means CONFIG_M25P80 now has a dependency on CONFIG_MTD_SPI_NOR, which
should be added to the defconfigs. I'm not sure what is the best process for
doing this. Should each $ARCH maintainer just take their respective patch, even
if the MTD_SPI_NOR Kconfig symbol is not defined for them yet? Or should
maintainers plan on merging the relevant SPI-NOR code into their trees during
the development cycle? Or some third option?

Anyway, the patches are here. Please keep general comments to the cover letter,
so all parties can see.

This series is based on the development repo for MTD, in the 'spinor' branch:

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

This series is available in the same repo at:

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

I tried locally merging this into linux-next and saw a trivial conflict in
arch/arm/configs/shmobile_defconfig. I can resubmit based on an appropriate
tree, if requested.

Thanks,
Brian

P.S. I was going to purely automatically generate this diff as follows, but
it generated a lot of defconfig noise:

	#!/bin/sh
	for i in arm blackfin mips powerpc sh
	do 
		for j in `git grep -l M25P80 arch/$i/configs`
		do 
			echo $j
			cp $j .config
			echo CONFIG_MTD_SPI_NOR=y >> .config
			make ARCH=$i savedefconfig
			mv defconfig $j
		done
	done

So I did a mixed approach, where I filtered most of the noise out of the diff.

Brian Norris (5):
  ARM: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
  blackfin: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
  mips: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
  powerpc: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
  sh: defconfig: add MTD_SPI_NOR (new dependency for M25P80)

 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 +
 arch/blackfin/configs/BF526-EZBRD_defconfig    | 2 +-
 arch/blackfin/configs/BF527-EZKIT-V2_defconfig | 2 +-
 arch/blackfin/configs/BF527-EZKIT_defconfig    | 2 +-
 arch/blackfin/configs/BF548-EZKIT_defconfig    | 2 +-
 arch/blackfin/configs/BF609-EZKIT_defconfig    | 2 +-
 arch/blackfin/configs/BlackStamp_defconfig     | 3 +--
 arch/blackfin/configs/H8606_defconfig          | 3 +--
 arch/mips/configs/ath79_defconfig              | 3 +--
 arch/mips/configs/db1xxx_defconfig             | 1 +
 arch/mips/configs/rt305x_defconfig             | 2 +-
 arch/powerpc/configs/corenet32_smp_defconfig   | 2 +-
 arch/powerpc/configs/corenet64_smp_defconfig   | 2 +-
 arch/powerpc/configs/mpc85xx_defconfig         | 2 +-
 arch/powerpc/configs/mpc85xx_smp_defconfig     | 2 +-
 arch/sh/configs/sh7757lcr_defconfig            | 2 +-
 31 files changed, 31 insertions(+), 21 deletions(-)

-- 
1.8.3.2

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

[Brian Norris]

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 at lists.infradead.org
Cc: linux-kernel at 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
-- 
1.8.3.2

[PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)

[Thierry Reding]

On Thu, Apr 17, 2014 at 12:21:44AM -0700, Brian Norris wrote:
> Hi all,
> 
> We are introducing a new SPI-NOR library/framework for MTD, to support various
> types of SPI-NOR flash controllers which require (or benefit from) intimate
> knowledge of the flash interface, rather than just the relatively dumb SPI
> interface. This library borrows much of the m25p80 driver for its abstraction
> and moves this code into a spi-nor module.

If this is a common library, then the more common approach to solve this
would be to have each driver that uses it to select MTD_SPI_NOR rather
than depend on it. That way you can drop this whole series to update the
default configurations.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140417/d37d6536/attachment-0001.sig>

[PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)

[Marek Vasut]

On Thursday, April 17, 2014 at 09:21:44 AM, Brian Norris wrote:
> Hi all,
> 
> We are introducing a new SPI-NOR library/framework for MTD, to support
> various types of SPI-NOR flash controllers which require (or benefit from)
> intimate knowledge of the flash interface, rather than just the relatively
> dumb SPI interface. This library borrows much of the m25p80 driver for its
> abstraction and moves this code into a spi-nor module.
> 
> This means CONFIG_M25P80 now has a dependency on CONFIG_MTD_SPI_NOR, which
> should be added to the defconfigs. I'm not sure what is the best process
> for doing this. Should each $ARCH maintainer just take their respective
> patch, even if the MTD_SPI_NOR Kconfig symbol is not defined for them yet?
> Or should maintainers plan on merging the relevant SPI-NOR code into their
> trees during the development cycle? Or some third option?

Shouldn't the M25P80 driver just "select" the SPI NOR framework? Then you won't 
need the adjustment to defconfigs at all I think.

Best regards,
Marek Vasut

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

[Marek Vasut]

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 at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---

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

Best regards,
Marek Vasut

[PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)

[Brian Norris]

Hi,

On Thu, Apr 17, 2014 at 12:53:03PM +0200, Thierry Reding wrote:
> On Thu, Apr 17, 2014 at 12:21:44AM -0700, Brian Norris wrote:
> > We are introducing a new SPI-NOR library/framework for MTD, to support various
> > types of SPI-NOR flash controllers which require (or benefit from) intimate
> > knowledge of the flash interface, rather than just the relatively dumb SPI
> > interface. This library borrows much of the m25p80 driver for its abstraction
> > and moves this code into a spi-nor module.
> 
> If this is a common library, then the more common approach to solve this
> would be to have each driver that uses it to select MTD_SPI_NOR rather
> than depend on it. That way you can drop this whole series to update the
> default configurations.

But does MTD_SPI_NOR (and drivers/mtd/spi-nor/) qualify as a "library"
or as a "subsystem"? I thought the latter were typically expected to be
user-selectable options, not automatically-"select"ed.

I would say that, except for its age, MTD_SPI_NOR is very similar in to
MTD_NAND (driver/mtd/nand/), which I'd consider a kind of subsystem, and
which users must select before they are asked about drivers which fall
under its category.

Perhaps my usage of the word "library" in the description was a mistake,
as I don't exactly consider it like a library in the sense of many other
"select"ed libraries.

Brian

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

[Huang Shijie]

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 at lists.infradead.org
> Cc: linux-kernel at 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>

[PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)

[Marek Vasut]

On Friday, April 18, 2014 at 08:30:54 AM, Brian Norris wrote:
> Hi,
> 
> On Thu, Apr 17, 2014 at 12:53:03PM +0200, Thierry Reding wrote:
> > On Thu, Apr 17, 2014 at 12:21:44AM -0700, Brian Norris wrote:
> > > We are introducing a new SPI-NOR library/framework for MTD, to support
> > > various types of SPI-NOR flash controllers which require (or benefit
> > > from) intimate knowledge of the flash interface, rather than just the
> > > relatively dumb SPI interface. This library borrows much of the m25p80
> > > driver for its abstraction and moves this code into a spi-nor module.
> > 
> > If this is a common library, then the more common approach to solve this
> > would be to have each driver that uses it to select MTD_SPI_NOR rather
> > than depend on it. That way you can drop this whole series to update the
> > default configurations.
> 
> But does MTD_SPI_NOR (and drivers/mtd/spi-nor/) qualify as a "library"
> or as a "subsystem"? I thought the latter were typically expected to be
> user-selectable options, not automatically-"select"ed.

I agree the "subsystem" is user-selectable while the "library" is to be 
'select'ed .

> I would say that, except for its age, MTD_SPI_NOR is very similar in to
> MTD_NAND (driver/mtd/nand/), which I'd consider a kind of subsystem, and
> which users must select before they are asked about drivers which fall
> under its category.
> 
> Perhaps my usage of the word "library" in the description was a mistake,
> as I don't exactly consider it like a library in the sense of many other
> "select"ed libraries.

It did look like a library to me at first, but it's rather a subsystem that 
contains a small library in it. Thus, I retract my previous comment about using 
'select' and add :

Acked-by: Marek Vasut <marex@denx.de>

Best regards,
Marek Vasut

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

[Stephen Warren]

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.

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

[Ezequiel Garcia]

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).
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

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

[Jason Cooper]

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.

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

[Ezequiel Garcia]

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
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

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

[Jason Cooper]

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.

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

[Brian Norris]

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

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

[Ezequiel Garcia]

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.
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

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

[Stephen Warren]

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.

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

[Huang Shijie]

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

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

[Jason Cooper]

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.

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

[Brian Norris]

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

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

[Brian Norris]

On Tue, Apr 29, 2014 at 01:42:50PM -0600, Stephen Warren wrote:
> I guess you could also just see if arm-soc (arm at 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 at 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

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

[Brian Norris]

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

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

[Stephen Warren]

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

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

[Olof Johansson]

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

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

[Jason Cooper]

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.

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

[Olof Johansson]

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

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

[Brian Norris]

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