[U-Boot] [RFC for-v2019.01 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.
Cc: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com --- Makefile | 7 +++++++ doc/driver-model/MIGRATION.txt | 9 +++++++++ 2 files changed, 16 insertions(+)
diff --git a/Makefile b/Makefile index aeb1c1455b9d..7005d76ad4d8 100644 --- a/Makefile +++ b/Makefile @@ -918,6 +918,13 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) @echo "before sending patches to the mailing list." @echo "====================================================" endif +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 "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 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.
Cc: Marek Vasut marex@denx.de Cc: Simon Glass sjg@chromium.org Signed-off-by: Tom Rini trini@konsulko.com --- Makefile | 7 +++++++ doc/driver-model/MIGRATION.txt | 10 ++++++++++ 2 files changed, 17 insertions(+)
diff --git a/Makefile b/Makefile index 7005d76ad4d8..28ea46820b30 100644 --- a/Makefile +++ b/Makefile @@ -925,6 +925,13 @@ ifneq ($(CONFIG_DM_MMC)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "See doc/driver-model/MIGRATION.txt for more info." @echo "====================================================" endif +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 "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 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 ----------
As the core of the subsystem has been converted along with some of the drivers, formalize a deadline for migration.
Cc: Tuomas Tynkkynen tuomas.tynkkynen@iki.fi Cc: Simon Glass sjg@chromium.org Cc: Bin Meng bmeng.cn@gmail.com Cc: Nikita Kiryanov nikita@compulab.co.il Cc: York Sun york.sun@nxp.com Cc: Fabio Estevam festevam@gmail.com Cc: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Signed-off-by: Tom Rini trini@konsulko.com --- 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 | 7 +++++++ doc/driver-model/MIGRATION.txt | 10 ++++++++++ 2 files changed, 17 insertions(+)
diff --git a/Makefile b/Makefile index 28ea46820b30..1f8ae23971bf 100644 --- a/Makefile +++ b/Makefile @@ -932,6 +932,13 @@ ifneq ($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "See doc/driver-model/MIGRATION.txt for more info." @echo "====================================================" 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_USB before the v2019.07 release." + @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 ----------
Hi Tom,
On Mon, Nov 26, 2018 at 7:20 AM Tom Rini trini@konsulko.com wrote:
As the core of the subsystem has been converted along with some of the drivers, formalize a deadline for migration.
Cc: Tuomas Tynkkynen tuomas.tynkkynen@iki.fi Cc: Simon Glass sjg@chromium.org Cc: Bin Meng bmeng.cn@gmail.com Cc: Nikita Kiryanov nikita@compulab.co.il Cc: York Sun york.sun@nxp.com Cc: Fabio Estevam festevam@gmail.com Cc: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Signed-off-by: Tom Rini trini@konsulko.com
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 | 7 +++++++ doc/driver-model/MIGRATION.txt | 10 ++++++++++ 2 files changed, 17 insertions(+)
diff --git a/Makefile b/Makefile index 28ea46820b30..1f8ae23971bf 100644 --- a/Makefile +++ b/Makefile @@ -932,6 +932,13 @@ ifneq ($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "See doc/driver-model/MIGRATION.txt for more info." @echo "====================================================" 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_USB before the v2019.07 release."
Should that be CONFIG_DM_SCSI on the 2nd line?
@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
-- 2.7.4
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Mon, Nov 26, 2018 at 07:32:38PM +1300, Chris Packham wrote:
Hi Tom,
On Mon, Nov 26, 2018 at 7:20 AM Tom Rini trini@konsulko.com wrote:
As the core of the subsystem has been converted along with some of the drivers, formalize a deadline for migration.
Cc: Tuomas Tynkkynen tuomas.tynkkynen@iki.fi Cc: Simon Glass sjg@chromium.org Cc: Bin Meng bmeng.cn@gmail.com Cc: Nikita Kiryanov nikita@compulab.co.il Cc: York Sun york.sun@nxp.com Cc: Fabio Estevam festevam@gmail.com Cc: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Signed-off-by: Tom Rini trini@konsulko.com
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 | 7 +++++++ doc/driver-model/MIGRATION.txt | 10 ++++++++++ 2 files changed, 17 insertions(+)
diff --git a/Makefile b/Makefile index 28ea46820b30..1f8ae23971bf 100644 --- a/Makefile +++ b/Makefile @@ -932,6 +932,13 @@ ifneq ($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "See doc/driver-model/MIGRATION.txt for more info." @echo "====================================================" 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_USB before the v2019.07 release."Should that be CONFIG_DM_SCSI on the 2nd line?
Yes, thanks. Now, ah, I believe you have access to some of the Marvell hardware that has drivers that need converting? Does this deadline sound reasonable to you?
On Tue, Nov 27, 2018 at 1:25 AM Tom Rini trini@konsulko.com wrote:
On Mon, Nov 26, 2018 at 07:32:38PM +1300, Chris Packham wrote:
Hi Tom,
On Mon, Nov 26, 2018 at 7:20 AM Tom Rini trini@konsulko.com wrote:
As the core of the subsystem has been converted along with some of the drivers, formalize a deadline for migration.
Cc: Tuomas Tynkkynen tuomas.tynkkynen@iki.fi Cc: Simon Glass sjg@chromium.org Cc: Bin Meng bmeng.cn@gmail.com Cc: Nikita Kiryanov nikita@compulab.co.il Cc: York Sun york.sun@nxp.com Cc: Fabio Estevam festevam@gmail.com Cc: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de Cc: Stefan Roese sr@denx.de Signed-off-by: Tom Rini trini@konsulko.com
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 | 7 +++++++ doc/driver-model/MIGRATION.txt | 10 ++++++++++ 2 files changed, 17 insertions(+)
diff --git a/Makefile b/Makefile index 28ea46820b30..1f8ae23971bf 100644 --- a/Makefile +++ b/Makefile @@ -932,6 +932,13 @@ ifneq ($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo "See doc/driver-model/MIGRATION.txt for more info." @echo "====================================================" 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_USB before the v2019.07 release."Should that be CONFIG_DM_SCSI on the 2nd line?
Yes, thanks. Now, ah, I believe you have access to some of the Marvell hardware that has drivers that need converting? Does this deadline sound reasonable to you?
Can't say I've looked closely at the SATA stuff. For USB there's not much stopping the kirkwood boards from using DM_USB it just needs to use some of the mbus support that already exists for mvebu. This might be the final nail in the coffin for orion5x.
None of the alliedtelesis boards that use kirkwood have usb hardware fitted. They'll do for testing the mbus changes. I do have an old kirkwood eval board which I think has both USB and SATA. I'll need to dust it off and see if it still works (I know the actual u-boot support for it was dropped I while back).
I think the USB migration is definitely doable by the deadline. Even if it ends up build test only for some boards. I can take a look at SATA but it's not a subsystem I've dealt with before.
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.
Cc: 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
Hi Tom,
On Sun, 25 Nov 2018 at 11:19, Tom Rini trini@konsulko.com 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.
Cc: 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 -- 2.7.4
My only concern here is the long deadline, more than a year after the original one. Granted I should have been more proactive in sending patches in May/June, but this has been fairly widely telegraphed IMO. I know that opinions different on this matter.
I'm also concerned about dealing with the SPL size issues that are likely to come up, but with two implementations these problems are masked.
Can I suggest an earlier deadline of 2019.01 instead? That effectively gives people until about March/April to send patches.
Regards, Simon
On Thu, Nov 29, 2018 at 10:10:01AM -0700, Simon Glass wrote:
Hi Tom,
On Sun, 25 Nov 2018 at 11:19, Tom Rini trini@konsulko.com 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.
Cc: 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
My only concern here is the long deadline, more than a year after the original one. Granted I should have been more proactive in sending patches in May/June, but this has been fairly widely telegraphed IMO. I know that opinions different on this matter.
I'm also concerned about dealing with the SPL size issues that are likely to come up, but with two implementations these problems are masked.
Yes, but I think I've been overly optimistic in my mental map of what has/hasn't been converted. While I hope we have what we need to make things work in SPL, or maybe only need to do some tweaking, I want a big enough window ahead that people aren't too stressed out when it turns out that we need, perhaps as came up in the SPI-nor series just now, a "tiny $something" subsystem and to work a bit more on the "tiny mmc" subsystem or what have you. I do plan to make noise and deadlines about SPL but since "everyone else" got to worry about U-Boot first and SPL second, I don't want to add more stress to the folks just now seeing urgency here.
Can I suggest an earlier deadline of 2019.01 instead? That effectively gives people until about March/April to send patches.
The problem is that we cannot make BLK be declared done until these other subsystems are also marked done. That was to me one of the big take-aways from the big series you did. We have enough boards that aren't so much broken at the board level (we do have those) but are broken at the driver-needs-converting level. And since it's really only "now" that everyone is seeing some of these, I don't think we can do things earlier than that.
But that said, my meaning of deadline is that we drop things. So a v2019.01 deadline means that second week of January we would be dropping things, if we pushed BLK up. Since you said March/April there, I assume you're thinking that means a bit later on we drop things. If I re-word things to be clearer that stuff will be dropped post v2019.07 will that be better?
Hi Tom,
On Thu, 29 Nov 2018 at 11:34, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 29, 2018 at 10:10:01AM -0700, Simon Glass wrote:
Hi Tom,
On Sun, 25 Nov 2018 at 11:19, Tom Rini trini@konsulko.com 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.
Cc: 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
My only concern here is the long deadline, more than a year after the original one. Granted I should have been more proactive in sending patches in May/June, but this has been fairly widely telegraphed IMO. I know that opinions different on this matter.
I'm also concerned about dealing with the SPL size issues that are likely to come up, but with two implementations these problems are masked.
Yes, but I think I've been overly optimistic in my mental map of what has/hasn't been converted. While I hope we have what we need to make things work in SPL, or maybe only need to do some tweaking, I want a big enough window ahead that people aren't too stressed out when it turns out that we need, perhaps as came up in the SPI-nor series just now, a "tiny $something" subsystem and to work a bit more on the "tiny mmc" subsystem or what have you. I do plan to make noise and deadlines about SPL but since "everyone else" got to worry about U-Boot first and SPL second, I don't want to add more stress to the folks just now seeing urgency here.
Can I suggest an earlier deadline of 2019.01 instead? That effectively gives people until about March/April to send patches.
The problem is that we cannot make BLK be declared done until these other subsystems are also marked done. That was to me one of the big take-aways from the big series you did. We have enough boards that aren't so much broken at the board level (we do have those) but are broken at the driver-needs-converting level. And since it's really only "now" that everyone is seeing some of these, I don't think we can do things earlier than that.
But that said, my meaning of deadline is that we drop things. So a v2019.01 deadline means that second week of January we would be dropping things, if we pushed BLK up. Since you said March/April there, I assume you're thinking that means a bit later on we drop things. If I re-word things to be clearer that stuff will be dropped post v2019.07 will that be better?
OK I see. Yes that seems reasonable.
Reviewed-by: Simon Glass sjg@chromium.org
It's been very quiet on this thread.
Regards, Simon
On Thu, Nov 29, 2018 at 11:43:14AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 29 Nov 2018 at 11:34, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 29, 2018 at 10:10:01AM -0700, Simon Glass wrote:
Hi Tom,
On Sun, 25 Nov 2018 at 11:19, Tom Rini trini@konsulko.com 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.
Cc: 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
My only concern here is the long deadline, more than a year after the original one. Granted I should have been more proactive in sending patches in May/June, but this has been fairly widely telegraphed IMO. I know that opinions different on this matter.
I'm also concerned about dealing with the SPL size issues that are likely to come up, but with two implementations these problems are masked.
Yes, but I think I've been overly optimistic in my mental map of what has/hasn't been converted. While I hope we have what we need to make things work in SPL, or maybe only need to do some tweaking, I want a big enough window ahead that people aren't too stressed out when it turns out that we need, perhaps as came up in the SPI-nor series just now, a "tiny $something" subsystem and to work a bit more on the "tiny mmc" subsystem or what have you. I do plan to make noise and deadlines about SPL but since "everyone else" got to worry about U-Boot first and SPL second, I don't want to add more stress to the folks just now seeing urgency here.
Can I suggest an earlier deadline of 2019.01 instead? That effectively gives people until about March/April to send patches.
The problem is that we cannot make BLK be declared done until these other subsystems are also marked done. That was to me one of the big take-aways from the big series you did. We have enough boards that aren't so much broken at the board level (we do have those) but are broken at the driver-needs-converting level. And since it's really only "now" that everyone is seeing some of these, I don't think we can do things earlier than that.
But that said, my meaning of deadline is that we drop things. So a v2019.01 deadline means that second week of January we would be dropping things, if we pushed BLK up. Since you said March/April there, I assume you're thinking that means a bit later on we drop things. If I re-word things to be clearer that stuff will be dropped post v2019.07 will that be better?
OK I see. Yes that seems reasonable.
Reviewed-by: Simon Glass sjg@chromium.org
It's been very quiet on this thread.
That it's been so quiet is a bit worrying to me, yes. I am going to fix the warning message that Chris pointed out and push this out for -rc1, which will I suppose be the next starting point for "We need more time!" requests.
On 29.11.2018 20:06, Tom Rini wrote:
On Thu, Nov 29, 2018 at 11:43:14AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 29 Nov 2018 at 11:34, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 29, 2018 at 10:10:01AM -0700, Simon Glass wrote:
Hi Tom,
On Sun, 25 Nov 2018 at 11:19, Tom Rini trini@konsulko.com 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.
Cc: 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
My only concern here is the long deadline, more than a year after the original one. Granted I should have been more proactive in sending patches in May/June, but this has been fairly widely telegraphed IMO. I know that opinions different on this matter.
I'm also concerned about dealing with the SPL size issues that are likely to come up, but with two implementations these problems are masked.
Yes, but I think I've been overly optimistic in my mental map of what has/hasn't been converted. While I hope we have what we need to make things work in SPL, or maybe only need to do some tweaking, I want a big enough window ahead that people aren't too stressed out when it turns out that we need, perhaps as came up in the SPI-nor series just now, a "tiny $something" subsystem and to work a bit more on the "tiny mmc" subsystem or what have you. I do plan to make noise and deadlines about SPL but since "everyone else" got to worry about U-Boot first and SPL second, I don't want to add more stress to the folks just now seeing urgency here.
Can I suggest an earlier deadline of 2019.01 instead? That effectively gives people until about March/April to send patches.
The problem is that we cannot make BLK be declared done until these other subsystems are also marked done. That was to me one of the big take-aways from the big series you did. We have enough boards that aren't so much broken at the board level (we do have those) but are broken at the driver-needs-converting level. And since it's really only "now" that everyone is seeing some of these, I don't think we can do things earlier than that.
But that said, my meaning of deadline is that we drop things. So a v2019.01 deadline means that second week of January we would be dropping things, if we pushed BLK up. Since you said March/April there, I assume you're thinking that means a bit later on we drop things. If I re-word things to be clearer that stuff will be dropped post v2019.07 will that be better?
OK I see. Yes that seems reasonable.
Reviewed-by: Simon Glass sjg@chromium.org
It's been very quiet on this thread.
That it's been so quiet is a bit worrying to me, yes. I am going to fix the warning message that Chris pointed out and push this out for -rc1, which will I suppose be the next starting point for "We need more time!" requests.
I can't speak for everyone affected, but maybe I can give an example why it's so quiet:
At first I was shocked to see that all the socfpga boards should be removed. Then I read that Simon got something wrong and that it's unclear which boards were false positives. And now I'm confused and I'm waiting for you to decide on action to tell what's actually to be done.
I think we need a clear message of *what* needs to be upgraded. I do think it's hard to see that for developers that aren't involved everyday with U-Boot development.
I think a build warning would be best. But maybe this is already pushed and I'm not seeing it because socfpga was a false positive?
Regards, Simon
On Thu, Nov 29, 2018 at 08:17:11PM +0100, Simon Goldschmidt wrote:
On 29.11.2018 20:06, Tom Rini wrote:
On Thu, Nov 29, 2018 at 11:43:14AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 29 Nov 2018 at 11:34, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 29, 2018 at 10:10:01AM -0700, Simon Glass wrote:
Hi Tom,
On Sun, 25 Nov 2018 at 11:19, Tom Rini trini@konsulko.com 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.
Cc: 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
My only concern here is the long deadline, more than a year after the original one. Granted I should have been more proactive in sending patches in May/June, but this has been fairly widely telegraphed IMO. I know that opinions different on this matter.
I'm also concerned about dealing with the SPL size issues that are likely to come up, but with two implementations these problems are masked.
Yes, but I think I've been overly optimistic in my mental map of what has/hasn't been converted. While I hope we have what we need to make things work in SPL, or maybe only need to do some tweaking, I want a big enough window ahead that people aren't too stressed out when it turns out that we need, perhaps as came up in the SPI-nor series just now, a "tiny $something" subsystem and to work a bit more on the "tiny mmc" subsystem or what have you. I do plan to make noise and deadlines about SPL but since "everyone else" got to worry about U-Boot first and SPL second, I don't want to add more stress to the folks just now seeing urgency here.
Can I suggest an earlier deadline of 2019.01 instead? That effectively gives people until about March/April to send patches.
The problem is that we cannot make BLK be declared done until these other subsystems are also marked done. That was to me one of the big take-aways from the big series you did. We have enough boards that aren't so much broken at the board level (we do have those) but are broken at the driver-needs-converting level. And since it's really only "now" that everyone is seeing some of these, I don't think we can do things earlier than that.
But that said, my meaning of deadline is that we drop things. So a v2019.01 deadline means that second week of January we would be dropping things, if we pushed BLK up. Since you said March/April there, I assume you're thinking that means a bit later on we drop things. If I re-word things to be clearer that stuff will be dropped post v2019.07 will that be better?
OK I see. Yes that seems reasonable.
Reviewed-by: Simon Glass sjg@chromium.org
It's been very quiet on this thread.
That it's been so quiet is a bit worrying to me, yes. I am going to fix the warning message that Chris pointed out and push this out for -rc1, which will I suppose be the next starting point for "We need more time!" requests.
I can't speak for everyone affected, but maybe I can give an example why it's so quiet:
At first I was shocked to see that all the socfpga boards should be removed. Then I read that Simon got something wrong and that it's unclear which boards were false positives. And now I'm confused and I'm waiting for you to decide on action to tell what's actually to be done.
I think we need a clear message of *what* needs to be upgraded. I do think it's hard to see that for developers that aren't involved everyday with U-Boot development.
I think a build warning would be best. But maybe this is already pushed and I'm not seeing it because socfpga was a false positive?
This series, which I just now v2'd is adding the build warnings with a formal deadline. We had only had BLK spelled out in the document but now I'm adding DM_MMC, DM_USB and moving-to-DM_SCSI, each with their own warning. BLK is only allowed once the subsystems that need BLK are done.
On Sun, Nov 25, 2018 at 12:19 PM 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.
Cc: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com
Out of curiosity, the series of patches are forcing various block devices to comply with CONFIG_BLK by a certain deadline. What about the more fundamental CONIFG_DM requirement? I know the CONFIG_BLK implies CONFIG_DM is enabled, but if people don't have block devices for some reason, there might be a few devices missed, so a warning indicating CONFIG_DM isn't enabled might also be useful.
My other concern about SPL devices where disabling DM in SPL saves space, or in some cases is required to fit.
adam
Makefile | 7 +++++++ doc/driver-model/MIGRATION.txt | 9 +++++++++ 2 files changed, 16 insertions(+)
diff --git a/Makefile b/Makefile index aeb1c1455b9d..7005d76ad4d8 100644 --- a/Makefile +++ b/Makefile @@ -918,6 +918,13 @@ ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y) @echo "before sending patches to the mailing list." @echo "====================================================" endif +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 "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 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 Mon, Nov 26, 2018 at 09:09:50AM -0600, Adam Ford wrote:
On Sun, Nov 25, 2018 at 12:19 PM 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.
Cc: Simon Glass sjg@chromium.org Cc: Jaehoon Chung jh80.chung@samsung.com Signed-off-by: Tom Rini trini@konsulko.com
Out of curiosity, the series of patches are forcing various block devices to comply with CONFIG_BLK by a certain deadline. What about the more fundamental CONIFG_DM requirement? I know the CONFIG_BLK implies CONFIG_DM is enabled, but if people don't have block devices for some reason, there might be a few devices missed, so a warning indicating CONFIG_DM isn't enabled might also be useful.
So, yes, we have not yet set a deadline on basic DM conversion. I haven't yet, and there's a few arches that haven't started and I'm talking with privately to see where things stand there.
My other concern about SPL devices where disabling DM in SPL saves space, or in some cases is required to fit.
Yes, what to do when switching to platform data isn't enough is an open question and I'm of a few minds still on if we should: - Allow some drivers to retain non-DM for SPL-only. - Declare that "TPL" is where the truly small and board/SoC/etc specific drivers need to reside. - Something else.
As there's pros and cons to both of those approaches.
participants (5)
-
Adam Ford -
Chris Packham -
Simon Glass -
Simon Goldschmidt -
Tom Rini