[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 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.

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>