[U-Boot] [RFC for-v2019.01 1/4] dm: MIGRATION: Add migration plan for DM_MMC

[U-Boot] [RFC for-v2019.01 1/4] dm: MIGRATION: Add migration plan for DM_MMC

[Tom Rini]

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
 ----------
-- 
2.7.4

[U-Boot] [RFC for-v2019.01 2/4] dm: MIGRATION: Add migration plan for DM_USB

[Tom Rini]

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
 ----------
 
-- 
2.7.4

[U-Boot] [RFC for-v2019.01 3/4] dm: MIGRATION: Add migration plan for CONFIG_SATA

[Tom Rini]

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
 ----------
 
-- 
2.7.4

[U-Boot] [RFC for-v2019.01 4/4] dm: MIGRATION: Update migration plan for BLK

[Tom Rini]

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

[U-Boot] [RFC for-v2019.01 3/4] dm: MIGRATION: Add migration plan for CONFIG_SATA

[Chris Packham]

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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC for-v2019.01 3/4] dm: MIGRATION: Add migration plan for CONFIG_SATA

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181126/d721e01d/attachment.sig>

[U-Boot] [RFC for-v2019.01 1/4] dm: MIGRATION: Add migration plan for DM_MMC

[Adam Ford]

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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC for-v2019.01 1/4] dm: MIGRATION: Add migration plan for DM_MMC

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181126/755c9f8a/attachment.sig>

[U-Boot] [RFC for-v2019.01 3/4] dm: MIGRATION: Add migration plan for CONFIG_SATA

[Chris Packham]

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.

[U-Boot] [RFC for-v2019.01 4/4] dm: MIGRATION: Update migration plan for BLK

[Simon Glass]

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

[U-Boot] [RFC for-v2019.01 4/4] dm: MIGRATION: Update migration plan for BLK

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181129/c2944744/attachment.sig>

[U-Boot] [RFC for-v2019.01 4/4] dm: MIGRATION: Update migration plan for BLK

[Simon Glass]

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

[U-Boot] [RFC for-v2019.01 4/4] dm: MIGRATION: Update migration plan for BLK

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181129/e05a41d9/attachment.sig>

[U-Boot] [RFC for-v2019.01 4/4] dm: MIGRATION: Update migration plan for BLK

[Simon Goldschmidt]

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

[U-Boot] [RFC for-v2019.01 4/4] dm: MIGRATION: Update migration plan for BLK

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181129/a0c564e7/attachment.sig>