dm: Move towards completing CONFIG_BLK migration

Hi Tom,

Quoted 103 lines · Tom Rini

Quoted 101 lines · Simon Glass

Hi Tom,

Quoted 97 lines · Tom Rini

Quoted 82 lines · Tom Rini

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 lines · Simon Glass

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.

Quoted 8 lines

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.

Quoted 13 lines

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.

Quoted 5 lines

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.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

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.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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.

Quoted 6 lines

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.

Quoted 5 lines

Quoted 1 line

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.

Quoted 10 lines

Quoted 9 lines

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.

Quoted 7 lines

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?