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

Thu Nov 29 19:19:33 UTC 2018

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