[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(+)

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.