[U-Boot] [PATCH 00/93] dm: Move towards completing CONFIG_BLK migration

[Simon Glass]

Hi Tom,

On Thu, 22 Nov 2018 at 16:31, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Nov 22, 2018 at 01:50:34PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 21 Nov 2018 at 08:10, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Nov 20, 2018 at 08:53:12AM -0500, Tom Rini wrote:
> > > > On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote:
> > > > > On 11/20/2018 02:42 PM, Tom Rini wrote:
> > > > > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote:
> > > > > >> On 11/20/2018 02:37 PM, Tom Rini wrote:
> > > > > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote:
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On 19.11.18 16:52, Simon Glass wrote:
> > > > > >>>>> All boards should now be migrated to use CONFIG_BLK. This series removes
> > > > > >>>>> those with build problems using this option.
> > > > > >>>>>
> > > > > >>>>> If maintainers want to keep these boards in they should send a patch in
> > > > > >>>>> the next week or two. Otherwise the board will be removed in the next
> > > > > >>>>> release, and will need to be added and re-reviewed later.
> > > > > >>>> Fabio, Stefano,
> > > > > >>>>
> > > > > >>>> it seems (almost?) all i.mx6 boards should be removed within two weeks.
> > > > > >>>> But would it not make more sense to convert the reference boards first
> > > > > >>>> (mx6sabresd
> > > > > >>>> in my case for tbs2910), and let hobbyist maintainers like me take this
> > > > > >>>> as example for
> > > > > >>>> their own modifications?
> > > > > >>>
> > > > > >>> So, I replied to the main thread earlier but no, we're not going to drop
> > > > > >>> everything in 2 weeks, especially since there's a lot of false positives
> > > > > >>> in this series.
> > > > > >>>
> > > > > >>>> Simon, Tom,
> > > > > >>>>
> > > > > >>>> is this really the usual u-boot working style to remove about hundred
> > > > > >>>> boards within
> > > > > >>>> two weeks without prior warning? As hobbyist board maintainer I try to
> > > > > >>>> follow
> > > > > >>>> new developments, and more than once I fixed up regressions introduced
> > > > > >>>> by others
> > > > > >>>> in general code.
> > > > > >>>> But I cannot follow all development details without any heads-up. And
> > > > > >>>> even the
> > > > > >>>> NXP folks seem to be surprised about this.
> > > > > >>>>
> > > > > >>>> All problems with this transition seem to be located around usbstorage
> > > > > >>>> and sata.
> > > > > >>>> This is for sure not really very board specific. Is there any migration
> > > > > >>>> guide, or
> > > > > >>>> examples how other SoC architectures did this conversion?
> > > > > >>>
> > > > > >>> I'll admit this hasn't been our best notification.  But, the deadline
> > > > > >>> was discussed about a year ago (and then no, I didn't get a build-time
> > > > > >>> warning in).  Then around v2018.05 I said it wasn't going to be a
> > > > > >>> removal type problem yet as we had a lot of boards to fixup still, and
> > > > > >>> repeated that at v2018.07.  That did lead to a lot of things getting
> > > > > >>> addressed.  But yes, we still have some large areas that after a few
> > > > > >>> years still have not been converted, and that puts me in a hard spot
> > > > > >>> too.
> > > > > >>
> > > > > >> Build time warning for a year would be good ?
> > > > > >
> > > > > > A year for this?  No.  New deadlines?  That's not too far off from what
> > > > > > we've done historically, so yes.
> > > > >
> > > > > Give people some sort of breathing space to get the conversion done.
> > > > > Stressing people out by arbitrary deadlines will lead nowhere.
> > > >
> > > > Sure, agreed.  I didn't say we're going to drop all these boards, nor
> > > > are we going to drop SATA and USB Storage (if those are still all that's
> > > > left to convert) for this release.  But given that we proposed a
> > > > deadline in August 2017, made email-but-not-build noise about it between
> > > > May and July/August of this year, no, I also don't think setting a new
> > > > deadline of November 2019 is the right call either.
> > > >
> > > > So, really, lets see what the fails to build boards are with BLK being
> > > > on when we have block devices.  Then assess what a good deadline is.
> > > >
> > > > > >> Maybe we need some generic Makefile macro to set those up.
> > > > > >
> > > > > > It would be nice, yes.  I think the problem here is (or, was) the
> > > > > > complex set of options that didn't work.
> > > > >
> > > > > The problem was many people didn't know about the conversion deadline or
> > > > > simply forgot. And reminding them with a 100-patch series removing half
> > > > > of the boards is like splashing icy water bucket in their sleeping faces.
> > > >
> > > > Alright.  But we've already tried less shocking approaches to
> > > > conversion, but in public (over the summer when Simon listed most of
> > > > these boards in a series but I _think_ his script failed to CC the
> > > > universe and didn't follow up with a repost that did email everyone) and
> > > > perhaps private too (I honestly don't recall if I did, or just intended
> > > > to, ask you about the USB side of this on IRC).
> > >
> > > And, for the record, the USB side I had in mind here was converted, and
> > > I just forgot, my fault.  In fact, as I go through some hack-and-slash
> > > to see what needs a real conversion (either board updated, or drivers
> > > updated) at least some part of this is needing to adjust dependencies to
> > > force things on with BLK.  For example, if we have MMC we must have
> > > DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.
> >
> > Well, once we are through the migration we can remove BLK.
>
> I don't think BLK the symbol goes away, really.  We don't want more
> objects built unconditionally and we will continue to have block
> device-less builds.

Yes that's right - but it becomes an optional feature rather than an
indication of completed migration.

>
> > Yes all the block devices are related, and we should use DM for all of
> > them to make this work.
> >
> > I am not sure if there is a better way to do this with Kconfig.
> >
> > Thanks for helping with all of this. I have found it quite tricky to
> > plot a path forward which is why I am been putting it off for several
> > months.
>
> Thanks for starting it off.  I think part of the big problem we'll have
> here is that unfortunately we can't key off of the BLK migration itself
> as it's short-hand for having started using OF_CONTROL.  What I'm
> currently working through is being able to have all block drivers using
> BLK and everything is still building / linking as unconverted drivers
> now depend on BROKEN.  This is showing we have a few widely used but
> unconverted drivers over in Freescale/NXP land.

That's a good idea. Does it work OK with DM_MMC and DM_USB? Is this a
way we can keep unconverted boards around for a while without holding
up migration? They won't work properly but will build?

Regards,
Simon