| Message ID | 1397719309-2022-2-git-send-email-computersforpeace@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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>
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.
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).
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.
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
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.
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
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.
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.
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
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.
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
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
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
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.
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
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.
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
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
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
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(-)