| Message ID | 20220214094231.3753686-2-clg@kaod.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | spi: spi-mem: Add driver for Aspeed SMC controllers | expand |
On 14/02/22 10:42AM, Cédric Le Goater wrote: > To prepare transition to the new Aspeed SMC SPI controller driver using > the spi-mem interface, change the kernel CONFIG option of the current > driver to reflect that the implementation uses the MTD SPI-NOR interface. > Once the new driver is sufficiently exposed, we should remove the old one. I don't quite understand the reasoning behind this. Why keep the old driver around? Why not directly replace it with the new one? Does the new one have any limitations that this one doesn't?
On 2/25/22 08:31, Pratyush Yadav wrote: > On 14/02/22 10:42AM, Cédric Le Goater wrote: >> To prepare transition to the new Aspeed SMC SPI controller driver using >> the spi-mem interface, change the kernel CONFIG option of the current >> driver to reflect that the implementation uses the MTD SPI-NOR interface. >> Once the new driver is sufficiently exposed, we should remove the old one. > > I don't quite understand the reasoning behind this. Why keep the old > driver around? Why not directly replace it with the new one? Does the > new one have any limitations that this one doesn't? No. The old one has more limitations than the new one. The old one in mainline is half baked since we could never merge the necessary bits for training. We have been keeping a full version on the OpenBMC tree. Joel, could we simply drop the old driver in mainline and keep the old one in the OpenBMC tree until we feel comfortable ? I guess we need more testing. Thanks, C. >
On Sun, 27 Feb 2022 at 18:50, Cédric Le Goater <clg@kaod.org> wrote: > > On 2/25/22 08:31, Pratyush Yadav wrote: > > On 14/02/22 10:42AM, Cédric Le Goater wrote: > >> To prepare transition to the new Aspeed SMC SPI controller driver using > >> the spi-mem interface, change the kernel CONFIG option of the current > >> driver to reflect that the implementation uses the MTD SPI-NOR interface. > >> Once the new driver is sufficiently exposed, we should remove the old one. > > > > I don't quite understand the reasoning behind this. Why keep the old > > driver around? Why not directly replace it with the new one? Does the > > new one have any limitations that this one doesn't? > > No. The old one has more limitations than the new one. The old one in > mainline is half baked since we could never merge the necessary bits > for training. We have been keeping a full version on the OpenBMC tree. > > Joel, could we simply drop the old driver in mainline and keep the old > one in the OpenBMC tree until we feel comfortable ? I guess we need > more testing. I would answer Pratyush's question with: the old one is well tested, and the new one is not. We would intend to keep the old one around for a release cycle or two, and once we're confident the new one is stable we would remove the old.
On 2/28/22 07:07, Joel Stanley wrote: > On Sun, 27 Feb 2022 at 18:50, Cédric Le Goater <clg@kaod.org> wrote: >> >> On 2/25/22 08:31, Pratyush Yadav wrote: >>> On 14/02/22 10:42AM, Cédric Le Goater wrote: >>>> To prepare transition to the new Aspeed SMC SPI controller driver using >>>> the spi-mem interface, change the kernel CONFIG option of the current >>>> driver to reflect that the implementation uses the MTD SPI-NOR interface. >>>> Once the new driver is sufficiently exposed, we should remove the old one. >>> >>> I don't quite understand the reasoning behind this. Why keep the old >>> driver around? Why not directly replace it with the new one? Does the >>> new one have any limitations that this one doesn't? >> >> No. The old one has more limitations than the new one. The old one in >> mainline is half baked since we could never merge the necessary bits >> for training. We have been keeping a full version in the OpenBMC tree. >> >> Joel, could we simply drop the old driver in mainline and keep the old >> one in the OpenBMC tree until we feel comfortable ? I guess we need >> more testing. > > I would answer Pratyush's question with: the old one is well tested, > and the new one is not. We would intend to keep the old one around for > a release cycle or two, and once we're confident the new one is stable > we would remove the old. yes but we could handle the transition in the OpenBMC tree without putting the burden on mainline. mainline would only have the newer spi-mem based driver, the OpenBMC tree would have it also, along with the older SPI-NOR based driver. So this patch renaming the Kconfig option would only apply to the OpenBMC tree. C.
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig index b4a1b2ed1a17..964536444cd7 100644 --- a/arch/arm/configs/aspeed_g4_defconfig +++ b/arch/arm/configs/aspeed_g4_defconfig @@ -64,7 +64,7 @@ CONFIG_MTD_BLOCK=y CONFIG_MTD_PARTITIONED_MASTER=y CONFIG_MTD_SPI_NOR=y # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set -CONFIG_SPI_ASPEED_SMC=y +CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_BLOCK=y diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig index ccc4240ee4b5..e809236ca88b 100644 --- a/arch/arm/configs/aspeed_g5_defconfig +++ b/arch/arm/configs/aspeed_g5_defconfig @@ -103,7 +103,7 @@ CONFIG_MTD_BLOCK=y CONFIG_MTD_PARTITIONED_MASTER=y CONFIG_MTD_SPI_NOR=y # CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set -CONFIG_SPI_ASPEED_SMC=y +CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_BLOCK=y diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig index 80a3ae02d759..49083ef05fb0 100644 --- a/arch/arm/configs/multi_v5_defconfig +++ b/arch/arm/configs/multi_v5_defconfig @@ -103,7 +103,7 @@ CONFIG_MTD_RAW_NAND=y CONFIG_MTD_NAND_ATMEL=y CONFIG_MTD_NAND_ORION=y CONFIG_MTD_SPI_NOR=y -CONFIG_SPI_ASPEED_SMC=y +CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=y CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_ATMEL_SSC=m diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 33572998dbbe..fc1b69256b64 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -217,7 +217,7 @@ CONFIG_MTD_NAND_DAVINCI=y CONFIG_MTD_NAND_STM32_FMC2=y CONFIG_MTD_NAND_PL35X=y CONFIG_MTD_SPI_NOR=y -CONFIG_SPI_ASPEED_SMC=m +CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR=m CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y diff --git a/drivers/mtd/spi-nor/controllers/Kconfig b/drivers/mtd/spi-nor/controllers/Kconfig index 5c0e0ec2e6d1..876a47042fec 100644 --- a/drivers/mtd/spi-nor/controllers/Kconfig +++ b/drivers/mtd/spi-nor/controllers/Kconfig @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only -config SPI_ASPEED_SMC +config SPI_ASPEED_SMC_MTD_SPI_NOR tristate "Aspeed flash controllers in SPI mode" depends on ARCH_ASPEED || COMPILE_TEST depends on HAS_IOMEM && OF diff --git a/drivers/mtd/spi-nor/controllers/Makefile b/drivers/mtd/spi-nor/controllers/Makefile index e7abba491d98..1e28297fb1e8 100644 --- a/drivers/mtd/spi-nor/controllers/Makefile +++ b/drivers/mtd/spi-nor/controllers/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o +obj-$(CONFIG_SPI_ASPEED_SMC_MTD_SPI_NOR) += aspeed-smc.o obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o obj-$(CONFIG_SPI_INTEL_SPI) += intel-spi.o
To prepare transition to the new Aspeed SMC SPI controller driver using the spi-mem interface, change the kernel CONFIG option of the current driver to reflect that the implementation uses the MTD SPI-NOR interface. Once the new driver is sufficiently exposed, we should remove the old one. Signed-off-by: Cédric Le Goater <clg@kaod.org> --- arch/arm/configs/aspeed_g4_defconfig | 2 +- arch/arm/configs/aspeed_g5_defconfig | 2 +- arch/arm/configs/multi_v5_defconfig | 2 +- arch/arm/configs/multi_v7_defconfig | 2 +- drivers/mtd/spi-nor/controllers/Kconfig | 2 +- drivers/mtd/spi-nor/controllers/Makefile | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-)