[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 at 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 at 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 at chromium.org>
> > > Signed-off-by: Tom Rini <trini at 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 at chromium.org>

It's been very quiet on this thread.

Regards,
Simon