[U-Boot] [PATCHv3 1/4] dm: MIGRATION: Add migration plan for DM_MMC
Given that at this point the MMC subsystem itself has been migrated along with a number of subsystem drivers, formalize a deadline for migration.
Reviewed-by: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com --- Changes in v3: - Ensure CONFIG_MMC is set Changes in v2: - Note that failure to migration may lead to removal. --- Makefile | 10 ++++++++++ doc/driver-model/MIGRATION.txt | 9 +++++++++ 2 files changed, 19 insertions(+)
diff --git a/Makefile b/Makefile index a4b1d1db5241..53046e763e0b 100644 --- a/Makefile +++ b/Makefile @@ -920,6 +920,16 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) @echo "before sending patches to the mailing list." @echo "====================================================" endif +ifeq ($(CONFIG_MMC),y) +ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) + @echo "===================== WARNING ======================" + @echo "This board does not use CONFIG_DM_MMC. Please update" + @echo "the board to use CONFIG_DM_MMC before the v2019.04 release." + @echo "Failure to update by the deadline may result in board removal." + @echo "See doc/driver-model/MIGRATION.txt for more info." + @echo "====================================================" +endif +endif @# Check that this build does not use CONFIG options that we do not @# know about unless they are in Kconfig. All the existing CONFIG @# options are whitelisted, so new ones should not be added. diff --git a/doc/driver-model/MIGRATION.txt b/doc/driver-model/MIGRATION.txt index 5ebefd608b99..71c26571828a 100644 --- a/doc/driver-model/MIGRATION.txt +++ b/doc/driver-model/MIGRATION.txt @@ -5,6 +5,15 @@ U-Boot has been migrating to a new driver model since its introduction in 2014. This file describes the schedule for deprecation of pre-driver-model features.
+CONFIG_DM_MMC +------------- + +Status: In progress +Deadline: 2019.04 + +The subsystem itself has been converted and maintainers should submit patches +switching over to using CONFIG_DM_MMC and other base driver model options in +time for inclusion in the 2019.04 rerelease.
CONFIG_BLK ----------
As much of the USB system has been migrated to DM now, formalize a deadline for migration.
Reviewed-by: Marek Vasut marex@denx.de Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Tom Rini trini@konsulko.com --- Changes in v3: - Ensure CONFIG_USB is set. Changes in v2: - Note that failure to migration may lead to removal. --- Makefile | 10 ++++++++++ doc/driver-model/MIGRATION.txt | 10 ++++++++++ 2 files changed, 20 insertions(+)
diff --git a/Makefile b/Makefile index 53046e763e0b..373939ddad94 100644 --- a/Makefile +++ b/Makefile @@ -930,6 +930,16 @@ ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "====================================================" endif endif +ifeq ($(CONFIG_USB),y) +ifneq ($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) + @echo "===================== WARNING ======================" + @echo "This board does not use CONFIG_DM_USB. Please update" + @echo "the board to use CONFIG_DM_USB before the v2019.07 release." + @echo "Failure to update by the deadline may result in board removal." + @echo "See doc/driver-model/MIGRATION.txt for more info." + @echo "====================================================" +endif +endif @# Check that this build does not use CONFIG options that we do not @# know about unless they are in Kconfig. All the existing CONFIG @# options are whitelisted, so new ones should not be added. diff --git a/doc/driver-model/MIGRATION.txt b/doc/driver-model/MIGRATION.txt index 71c26571828a..0b763f72a453 100644 --- a/doc/driver-model/MIGRATION.txt +++ b/doc/driver-model/MIGRATION.txt @@ -15,6 +15,16 @@ The subsystem itself has been converted and maintainers should submit patches switching over to using CONFIG_DM_MMC and other base driver model options in time for inclusion in the 2019.04 rerelease.
+CONFIG_DM_USB +------------- + +Status: In progress +Deadline: 2019.07 + +The subsystem itself has been converted along with many of the host controller +and maintainers should submit patches switching over to using CONFIG_DM_USB and +other base driver model options in time for inclusion in the 2019.07 rerelease. + CONFIG_BLK ----------
On Thu, Nov 29, 2018 at 06:21:12PM -0500, Tom Rini wrote:
As much of the USB system has been migrated to DM now, formalize a deadline for migration.
Reviewed-by: Marek Vasut marex@denx.de Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
Hi Tom,
On 04.12.18 05:49, Tom Rini wrote:
On Thu, Nov 29, 2018 at 06:21:12PM -0500, Tom Rini wrote:
As much of the USB system has been migrated to DM now, formalize a deadline for migration.
Reviewed-by: Marek Vasut marex@denx.de Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
Just a quick note on this, since I just tested compiling current mainline on MVEBU "theadorable_debug". Here I get:
===================== WARNING ====================== This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_SCSI. Please update the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ====================================================
The DM_SCSI warning seems to be okay, because of the not converted ATA driver sata_mv.c (the controller is unfortunately not AHCI compatible). I hope to find some time shortly to work on this.
But the board definitely uses DM_USB:
$ gg DM_USB configs/theadorable_debug_defconfig configs/theadorable_debug_defconfig:CONFIG_DM_USB=y
So the DM_USB warning seems to be wrong here.
Thanks, Stefan
On Wed, Dec 05, 2018 at 08:14:14AM +0100, Stefan Roese wrote:
Hi Tom,
On 04.12.18 05:49, Tom Rini wrote:
On Thu, Nov 29, 2018 at 06:21:12PM -0500, Tom Rini wrote:
As much of the USB system has been migrated to DM now, formalize a deadline for migration.
Reviewed-by: Marek Vasut marex@denx.de Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
Just a quick note on this, since I just tested compiling current mainline on MVEBU "theadorable_debug". Here I get:
===================== WARNING ====================== This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_SCSI. Please update the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ====================================================
The DM_SCSI warning seems to be okay, because of the not converted ATA driver sata_mv.c (the controller is unfortunately not AHCI compatible). I hope to find some time shortly to work on this.
But the board definitely uses DM_USB:
$ gg DM_USB configs/theadorable_debug_defconfig configs/theadorable_debug_defconfig:CONFIG_DM_USB=y
So the DM_USB warning seems to be wrong here.
I think you're "stuck" here because you can't turn on CONFIG_BLK to silence the CONFIG_DM_USB warning without then breaking sata_mv.c. The CONFIG_DM_USB migration isn't complete until you're also using CONFIG_BLK.
On Thu, Dec 6, 2018 at 1:23 AM Tom Rini trini@konsulko.com wrote:
On Wed, Dec 05, 2018 at 08:14:14AM +0100, Stefan Roese wrote:
Hi Tom,
On 04.12.18 05:49, Tom Rini wrote:
On Thu, Nov 29, 2018 at 06:21:12PM -0500, Tom Rini wrote:
As much of the USB system has been migrated to DM now, formalize a deadline for migration.
Reviewed-by: Marek Vasut marex@denx.de Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
Just a quick note on this, since I just tested compiling current mainline on MVEBU "theadorable_debug". Here I get:
===================== WARNING ====================== This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_SCSI. Please update the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ====================================================
The DM_SCSI warning seems to be okay, because of the not converted ATA driver sata_mv.c (the controller is unfortunately not AHCI compatible). I hope to find some time shortly to work on this.
But the board definitely uses DM_USB:
$ gg DM_USB configs/theadorable_debug_defconfig configs/theadorable_debug_defconfig:CONFIG_DM_USB=y
So the DM_USB warning seems to be wrong here.
I think you're "stuck" here because you can't turn on CONFIG_BLK to silence the CONFIG_DM_USB warning without then breaking sata_mv.c. The CONFIG_DM_USB migration isn't complete until you're also using CONFIG_BLK.
On a related note. I'm looking at adding a new board and have CONFIG_DM_USB and CONFIG_USB_STORAGE enabled but I trip over the same warning. This board doesn't enable SATA so I'm not trapped like the theadorable boards but enabling CONFIG_BLK just to silence the warning seems a bit wrong. Am I missing something?
On Fri, Dec 07, 2018 at 01:05:24PM +1300, Chris Packham wrote:
On Thu, Dec 6, 2018 at 1:23 AM Tom Rini trini@konsulko.com wrote:
On Wed, Dec 05, 2018 at 08:14:14AM +0100, Stefan Roese wrote:
Hi Tom,
On 04.12.18 05:49, Tom Rini wrote:
On Thu, Nov 29, 2018 at 06:21:12PM -0500, Tom Rini wrote:
As much of the USB system has been migrated to DM now, formalize a deadline for migration.
Reviewed-by: Marek Vasut marex@denx.de Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
Just a quick note on this, since I just tested compiling current mainline on MVEBU "theadorable_debug". Here I get:
===================== WARNING ====================== This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_SCSI. Please update the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ====================================================
The DM_SCSI warning seems to be okay, because of the not converted ATA driver sata_mv.c (the controller is unfortunately not AHCI compatible). I hope to find some time shortly to work on this.
But the board definitely uses DM_USB:
$ gg DM_USB configs/theadorable_debug_defconfig configs/theadorable_debug_defconfig:CONFIG_DM_USB=y
So the DM_USB warning seems to be wrong here.
I think you're "stuck" here because you can't turn on CONFIG_BLK to silence the CONFIG_DM_USB warning without then breaking sata_mv.c. The CONFIG_DM_USB migration isn't complete until you're also using CONFIG_BLK.
On a related note. I'm looking at adding a new board and have CONFIG_DM_USB and CONFIG_USB_STORAGE enabled but I trip over the same warning. This board doesn't enable SATA so I'm not trapped like the theadorable boards but enabling CONFIG_BLK just to silence the warning seems a bit wrong. Am I missing something?
No, enabling CONFIG_BLK is what's needed. We can't select/depend on it in all cases that we would like yet but enabling it enables other functionality.
As the core of the subsystem has been converted along with some of the drivers, formalize a deadline for migration.
Cc: Akshay Bhat akshaybhat@timesys.com Cc: Andreas Geisreiter ageisreiter@dh-electronics.de Cc: Bin Meng bmeng.cn@gmail.com Cc: Christian Gmeiner christian.gmeiner@gmail.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Jason Liu jason.hui.liu@nxp.com Cc: Ken Lin Ken.Lin@advantech.com.tw Cc: Ludwig Zenz lzenz@dh-electronics.de Cc: Marek Vasut marex@denx.de Cc: Max Krummenacher max.krummenacher@toradex.com Cc: Nikita Kiryanov nikita@compulab.co.il Cc: Otavio Salvador otavio@ossystems.com.br Cc: Peng Fan peng.fan@nxp.com Reviewed-by: Simon Glass sjg@chromium.org Cc: Soeren Moch smoch@web.de Cc: Stefan Roese sr@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Tim Harvey tharvey@gateworks.com Cc: Troy Kisky troy.kisky@boundarydevices.com Cc: Tuomas Tynkkynen tuomas.tynkkynen@iki.fi Cc: York Sun york.sun@nxp.com Signed-off-by: Tom Rini trini@konsulko.com --- Changes in v2: - Note that failure to migration may lead to removal. - Even more Ccs
Apologies for the scattershot CC list here. A problem with this particular migration is we have a number of drivers for older platforms without clear ownership. Please feel free to loop in other people you know that might have interest here. Thanks! --- Makefile | 8 ++++++++ doc/driver-model/MIGRATION.txt | 10 ++++++++++ 2 files changed, 18 insertions(+)
diff --git a/Makefile b/Makefile index 373939ddad94..5e377c3fd5a6 100644 --- a/Makefile +++ b/Makefile @@ -940,6 +940,14 @@ ifneq ($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "====================================================" endif endif +ifeq ($(CONFIG_LIBATA)$(CONFIG_DM_SCSI)$(CONFIG_MVSATA_IDE),y) + @echo "===================== WARNING ======================" + @echo "This board does not use CONFIG_DM_SCSI. Please update" + @echo "the storage controller to use CONFIG_DM_SCSI before the v2019.07 release." + @echo "Failure to update by the deadline may result in board removal." + @echo "See doc/driver-model/MIGRATION.txt for more info." + @echo "====================================================" +endif @# Check that this build does not use CONFIG options that we do not @# know about unless they are in Kconfig. All the existing CONFIG @# options are whitelisted, so new ones should not be added. diff --git a/doc/driver-model/MIGRATION.txt b/doc/driver-model/MIGRATION.txt index 0b763f72a453..6df7e02a63de 100644 --- a/doc/driver-model/MIGRATION.txt +++ b/doc/driver-model/MIGRATION.txt @@ -25,6 +25,16 @@ The subsystem itself has been converted along with many of the host controller and maintainers should submit patches switching over to using CONFIG_DM_USB and other base driver model options in time for inclusion in the 2019.07 rerelease.
+CONFIG_SATA +----------- + +Status: In progress +Deadline: 2019.07 + +The subsystem itself has been converted along with many of the host controller +and maintainers should submit patches switching over to using CONFIG_AHCI and +other base driver model options in time for inclusion in the 2019.07 rerelease. + CONFIG_BLK ----------
On Thu, Nov 29, 2018 at 06:21:13PM -0500, Tom Rini wrote:
As the core of the subsystem has been converted along with some of the drivers, formalize a deadline for migration.
Cc: Akshay Bhat akshaybhat@timesys.com Cc: Andreas Geisreiter ageisreiter@dh-electronics.de Cc: Bin Meng bmeng.cn@gmail.com Cc: Christian Gmeiner christian.gmeiner@gmail.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Jason Liu jason.hui.liu@nxp.com Cc: Ken Lin Ken.Lin@advantech.com.tw Cc: Ludwig Zenz lzenz@dh-electronics.de Cc: Marek Vasut marex@denx.de Cc: Max Krummenacher max.krummenacher@toradex.com Cc: Nikita Kiryanov nikita@compulab.co.il Cc: Otavio Salvador otavio@ossystems.com.br Cc: Peng Fan peng.fan@nxp.com Reviewed-by: Simon Glass sjg@chromium.org Cc: Soeren Moch smoch@web.de Cc: Stefan Roese sr@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Tim Harvey tharvey@gateworks.com Cc: Troy Kisky troy.kisky@boundarydevices.com Cc: Tuomas Tynkkynen tuomas.tynkkynen@iki.fi Cc: York Sun york.sun@nxp.com Signed-off-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
The biggest part of migration to using CONFIG_BLK is that we need to have the various subsystems migrated first, so reword the plan here to reference the new deadlines.
Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Tom Rini trini@konsulko.com --- doc/driver-model/MIGRATION.txt | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/doc/driver-model/MIGRATION.txt b/doc/driver-model/MIGRATION.txt index 6df7e02a63de..6b691338b4e7 100644 --- a/doc/driver-model/MIGRATION.txt +++ b/doc/driver-model/MIGRATION.txt @@ -39,14 +39,12 @@ CONFIG_BLK ----------
Status: In progress -Deadline: 2018.05 - -Maintainers should submit patches for enabling CONFIG_BLK on all boards in -time for inclusion in the 2018.05 release. Boards not converted by this -time may be removed in a subsequent release. +Deadline: 2019.07
-Note that this implies use of driver model for all block devices (e.g. -MMC, USB, SCSI, SATA). +In concert with maintainers migrating their block device usage to the +appropriate DM driver, CONFIG_BLK needs to be set as well. The final deadline +here coincides with the final deadline for migration of the various block +subsystems.
CONFIG_DM_SPI CONFIG_DM_SPI_FLASH
On Thu, Nov 29, 2018 at 06:21:14PM -0500, Tom Rini wrote:
The biggest part of migration to using CONFIG_BLK is that we need to have the various subsystems migrated first, so reword the plan here to reference the new deadlines.
Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
On Fri, Nov 30, 2018 at 12:21 AM Tom Rini trini@konsulko.com wrote:
Given that at this point the MMC subsystem itself has been migrated along with a number of subsystem drivers, formalize a deadline for migration.
Reviewed-by: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com
Reviewed-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
Changes in v3:
- Ensure CONFIG_MMC is set
Changes in v2:
- Note that failure to migration may lead to removal.
Makefile | 10 ++++++++++ doc/driver-model/MIGRATION.txt | 9 +++++++++ 2 files changed, 19 insertions(+)
diff --git a/Makefile b/Makefile index a4b1d1db5241..53046e763e0b 100644 --- a/Makefile +++ b/Makefile @@ -920,6 +920,16 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) @echo "before sending patches to the mailing list." @echo "====================================================" endif +ifeq ($(CONFIG_MMC),y) +ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy)
@echo "===================== WARNING ======================"@echo "This board does not use CONFIG_DM_MMC. Please update"@echo "the board to use CONFIG_DM_MMC before the v2019.04 release."@echo "Failure to update by the deadline may result in board removal."@echo "See doc/driver-model/MIGRATION.txt for more info."@echo "===================================================="+endif +endif @# Check that this build does not use CONFIG options that we do not @# know about unless they are in Kconfig. All the existing CONFIG @# options are whitelisted, so new ones should not be added. diff --git a/doc/driver-model/MIGRATION.txt b/doc/driver-model/MIGRATION.txt index 5ebefd608b99..71c26571828a 100644 --- a/doc/driver-model/MIGRATION.txt +++ b/doc/driver-model/MIGRATION.txt @@ -5,6 +5,15 @@ U-Boot has been migrating to a new driver model since its introduction in 2014. This file describes the schedule for deprecation of pre-driver-model features.
+CONFIG_DM_MMC +-------------
+Status: In progress +Deadline: 2019.04
+The subsystem itself has been converted and maintainers should submit patches +switching over to using CONFIG_DM_MMC and other base driver model options in +time for inclusion in the 2019.04 rerelease.
CONFIG_BLK
-- 2.7.4
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On 30.11.2018, at 09:10, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
On Fri, Nov 30, 2018 at 12:21 AM Tom Rini <trini@konsulko.com mailto:trini@konsulko.com> wrote:
Given that at this point the MMC subsystem itself has been migrated along with a number of subsystem drivers, formalize a deadline for migration.
Reviewed-by: Simon Glass <sjg@chromium.org mailto:sjg@chromium.org> Cc: Jaehoon Chung <jh80.chung@samsung.com mailto:jh80.chung@samsung.com> Signed-off-by: Tom Rini <trini@konsulko.com mailto:trini@konsulko.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com mailto:simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
On Thu, Nov 29, 2018 at 06:21:11PM -0500, Tom Rini wrote:
Given that at this point the MMC subsystem itself has been migrated along with a number of subsystem drivers, formalize a deadline for migration.
Reviewed-by: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
Applied to u-boot/master, thanks!
Hi Tom,
On Tue, Dec 4, 2018 at 5:51 AM Tom Rini trini@konsulko.com wrote:
On Thu, Nov 29, 2018 at 06:21:11PM -0500, Tom Rini wrote:
Given that at this point the MMC subsystem itself has been migrated along with a number of subsystem drivers, formalize a deadline for migration.
Reviewed-by: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
Applied to u-boot/master, thanks!
I have finally found the time to test current mainline on all our board configs and now I still get the warning "This board does not use CONFIG_DM_MMC". Supposedly this is because I have CONFIG_BLK disabled (because of size limitations: this U-Boot image runs from FPGA and just configures the eMMC without loading files from it).
Would it make sense to change the test like this:
diff --git a/Makefile b/Makefile index 0d11ff9797..41bde15b74 100644 --- a/Makefile +++ b/Makefile @@ -920,7 +920,7 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) @echo "before sending patches to the mailing list." @echo "====================================================" endif -ifeq ($(CONFIG_MMC),y) +ifeq ($(CONFIG_MMC)$(CONFIG_BLK),yy) ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "===================== WARNING ======================" @echo "This board does not use CONFIG_DM_MMC. Please update"
Is it intentional that CONFIG_BLK needs to be enabled?
Regards, Simon
Hi Simon,
On Thu, 13 Dec 2018 at 02:45, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Hi Tom,
On Tue, Dec 4, 2018 at 5:51 AM Tom Rini trini@konsulko.com wrote:
On Thu, Nov 29, 2018 at 06:21:11PM -0500, Tom Rini wrote:
Given that at this point the MMC subsystem itself has been migrated along with a number of subsystem drivers, formalize a deadline for migration.
Reviewed-by: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
Applied to u-boot/master, thanks!
I have finally found the time to test current mainline on all our board configs and now I still get the warning "This board does not use CONFIG_DM_MMC". Supposedly this is because I have CONFIG_BLK disabled (because of size limitations: this U-Boot image runs from FPGA and just configures the eMMC without loading files from it).
Would it make sense to change the test like this:
diff --git a/Makefile b/Makefile index 0d11ff9797..41bde15b74 100644 --- a/Makefile +++ b/Makefile @@ -920,7 +920,7 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) @echo "before sending patches to the mailing list." @echo "====================================================" endif -ifeq ($(CONFIG_MMC),y) +ifeq ($(CONFIG_MMC)$(CONFIG_BLK),yy) ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "===================== WARNING ======================" @echo "This board does not use CONFIG_DM_MMC. Please update"
Is it intentional that CONFIG_BLK needs to be enabled?
Yes it is, unless you don't actually use block devices. What is the goal of initing eMMC without using it?
Regards, Simon
Am Fr., 14. Dez. 2018, 04:10 hat Simon Glass sjg@chromium.org geschrieben:
Hi Simon,
On Thu, 13 Dec 2018 at 02:45, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Hi Tom,
On Tue, Dec 4, 2018 at 5:51 AM Tom Rini trini@konsulko.com wrote:
On Thu, Nov 29, 2018 at 06:21:11PM -0500, Tom Rini wrote:
Given that at this point the MMC subsystem itself has been migrated along with a number of subsystem drivers, formalize a deadline for migration.
Reviewed-by: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
Applied to u-boot/master, thanks!
I have finally found the time to test current mainline on all our board configs and now I still get the warning "This board does not use CONFIG_DM_MMC". Supposedly this is because I have CONFIG_BLK disabled (because of size limitations: this U-Boot image runs from FPGA and just configures the eMMC without loading files from it).
Would it make sense to change the test like this:
diff --git a/Makefile b/Makefile index 0d11ff9797..41bde15b74 100644 --- a/Makefile +++ b/Makefile @@ -920,7 +920,7 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) @echo "before sending patches to the mailing list." @echo "====================================================" endif -ifeq ($(CONFIG_MMC),y) +ifeq ($(CONFIG_MMC)$(CONFIG_BLK),yy) ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "===================== WARNING ======================" @echo "This board does not use CONFIG_DM_MMC. Please update"
Is it intentional that CONFIG_BLK needs to be enabled?
Yes it is, unless you don't actually use block devices. What is the goal of initing eMMC without using it?
We're only initializing pSLC mode in that configuration. The boot flow is via tftp. I know this might be a rare use case but I'm more or less forced to disable block devices because I only have ~200KiB for U-Boot when running from FPGA.
Regards, Simon
Hi Simon,
On Thu, 13 Dec 2018 at 22:15, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Am Fr., 14. Dez. 2018, 04:10 hat Simon Glass sjg@chromium.org geschrieben:
Hi Simon,
On Thu, 13 Dec 2018 at 02:45, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Hi Tom,
On Tue, Dec 4, 2018 at 5:51 AM Tom Rini trini@konsulko.com wrote:
On Thu, Nov 29, 2018 at 06:21:11PM -0500, Tom Rini wrote:
Given that at this point the MMC subsystem itself has been migrated along with a number of subsystem drivers, formalize a deadline for migration.
Reviewed-by: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
Applied to u-boot/master, thanks!
I have finally found the time to test current mainline on all our board configs and now I still get the warning "This board does not use CONFIG_DM_MMC". Supposedly this is because I have CONFIG_BLK disabled (because of size limitations: this U-Boot image runs from FPGA and just configures the eMMC without loading files from it).
Would it make sense to change the test like this:
diff --git a/Makefile b/Makefile index 0d11ff9797..41bde15b74 100644 --- a/Makefile +++ b/Makefile @@ -920,7 +920,7 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) @echo "before sending patches to the mailing list." @echo "====================================================" endif -ifeq ($(CONFIG_MMC),y) +ifeq ($(CONFIG_MMC)$(CONFIG_BLK),yy) ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "===================== WARNING ======================" @echo "This board does not use CONFIG_DM_MMC. Please update"
Is it intentional that CONFIG_BLK needs to be enabled?
Yes it is, unless you don't actually use block devices. What is the goal of initing eMMC without using it?
We're only initializing pSLC mode in that configuration. The boot flow is via tftp. I know this might be a rare use case but I'm more or less forced to disable block devices because I only have ~200KiB for U-Boot when running from FPGA.
Maybe disabling HAVE_BLOCK_DEVICE would provide a means to avoid the warning?
Regards, Simon
Am 20.12.2018 um 22:17 schrieb Simon Glass:
Hi Simon,
On Thu, 13 Dec 2018 at 22:15, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Am Fr., 14. Dez. 2018, 04:10 hat Simon Glass sjg@chromium.org geschrieben:
Hi Simon,
On Thu, 13 Dec 2018 at 02:45, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Hi Tom,
On Tue, Dec 4, 2018 at 5:51 AM Tom Rini trini@konsulko.com wrote:
On Thu, Nov 29, 2018 at 06:21:11PM -0500, Tom Rini wrote:
Given that at this point the MMC subsystem itself has been migrated along with a number of subsystem drivers, formalize a deadline for migration.
Reviewed-by: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Reviewed-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
Applied to u-boot/master, thanks!
I have finally found the time to test current mainline on all our board configs and now I still get the warning "This board does not use CONFIG_DM_MMC". Supposedly this is because I have CONFIG_BLK disabled (because of size limitations: this U-Boot image runs from FPGA and just configures the eMMC without loading files from it).
Would it make sense to change the test like this:
diff --git a/Makefile b/Makefile index 0d11ff9797..41bde15b74 100644 --- a/Makefile +++ b/Makefile @@ -920,7 +920,7 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) @echo "before sending patches to the mailing list." @echo "====================================================" endif -ifeq ($(CONFIG_MMC),y) +ifeq ($(CONFIG_MMC)$(CONFIG_BLK),yy) ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "===================== WARNING ======================" @echo "This board does not use CONFIG_DM_MMC. Please update"
Is it intentional that CONFIG_BLK needs to be enabled?
Yes it is, unless you don't actually use block devices. What is the goal of initing eMMC without using it?
We're only initializing pSLC mode in that configuration. The boot flow is via tftp. I know this might be a rare use case but I'm more or less forced to disable block devices because I only have ~200KiB for U-Boot when running from FPGA.
Maybe disabling HAVE_BLOCK_DEVICE would provide a means to avoid the warning?
Hmm, it might well be that I haven't disabled everything I can in that config. I'll check that next year ;-)
Regards, Simon
participants (6)
-
Chris Packham -
Philipp Tomsich -
Simon Glass -
Simon Goldschmidt -
Stefan Roese -
Tom Rini