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

[Simon Glass]

Hi again,

On Mon, 19 Nov 2018 at 14:58, Simon Glass <sjg at chromium.org> wrote:
>
> Hi,
>
> On Mon, 19 Nov 2018 at 14:54, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote:
> > > On 11/19/2018 08:45 PM, Adam Ford wrote:
> > > > On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini at konsulko.com> wrote:
> > > >>
> > > >> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg at chromium.org> 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.
> > > >>>
> > > >>> The goal is to have all boards use driver model. But so far, we do allow
> > > >>> CONFIG_DM to not be defined.
> > > >>>
> > > >>> PLEASE NOTE: This is not an easy process. It is possible that your board
> > > >>> does work, or works with only minor changes. Please try to understand that
> > > >>> the removal of a board is not done because people don't like your board.
> > > >>> In fact the board might have been the first one I used when trying out
> > > >>> U-Boot! It's just that we expect maintainers to keep up with the migration
> > > >>> to driver model which has been running now for 4 years. It just isn't
> > > >>> possible for a few people to migrate and test hundreds of boards.
> > > >>>
> > > >>> So, send a patch!
> > > >>
> > > >> OK, so with the intention of "need to light a fire", consider the fire
> > > >> lit!  But, I think v2 of this series needs to:
> > > >> - Address the bug that's been noted of you checking on "DM_BLK" when
> > > >>   it's really just "BLK".
> > > >> - Do a test build with BLK just being unconditional now.  For example,
> > > >>   you're deleting the am335x_evm family but it builds fine with BLK
> > > >>   being enabled now.  I even gave it a run time test via test.py and
> > > >>   we're fine.  So, I think a new run where you see what fails to build
> > > >>   with BLK enabled by default now is in order to come up with a new
> > > >>   delete list.
> > > >>
> > > >
> > > > When we were migrating toward GCC 6, we introduced a warning message
> > > > that was displayed at build indicating older versions of GCC would be
> > > > unsupported, and GCC 6 would become a requirement.  The
> > > > CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be
> > > > removed.  I would like to propose that in the future, when setting
> > > > deadlines, we insert something into the build mechanism that generates
> > > > a warning to tell people that something is going to happen.
> > >
> > > I agree, that sounds good.
> > >
> > > I am extremely unhappy by how Simon decided, unilaterally, some
> > > arbitrary deadline, told pretty much no one about that deadline and then
> > > put a knife on many peoples' throats by sending out this series which
> > > removes boards that are actively used and maintained, demanding they be
> > > converted right this instant.
> >
> > OK, lets step back for a moment.  Part of the problem is that yes, we
> > (I) never found a good way to make a big scary build warning happen.
> > But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a
> > moment, which is when we set this deadline, and we had a good bit of
> > discussion about related issues to make it happen.
> >
> > I also know that around the v2018.05 release I said, in public, but no I
> > can't find a link right this moment, that we were pushing off a little
> > bit on dropping _everything_ right then as there was basically some
> > fairly important / widely used USB stuff that hadn't been converted yet
> > (which has since been, I think, otherwise am335x_evm & co wouldn't have
> > been happy?).  I know I did since I can see in the archives a number of
> > series where maintainers did a bunch of changes to various platforms /
> > SoCs to turn on BLK right then.
> >
> > So, no, I don't want to drop a bunch of platforms _right_now_.  But we
> > really need to see what doesn't link anymore with BLK forced on, and
> > plan from there.
>
> Yes, I need to ignore warnings. I saw some boards trying to call
> non-DM functions and assumed they all did, but they were just DTC
> warnings. I'll see if I can figure out how to turn those off.
>
> So if you didn't know about CONFIG_BLK migration from the June email,
> hopefully you see this one :-) If your board is already converted,
> please don't worry, I will try to get this right in the v2 series,
> which hopefully will be much smaller.
>
> Thank you very much to the many maintainers who have met the deadline
> and converted their boards. Apologies to those who converted, and
> still got this email.
>
> And please read my note in the cover letter.

I went back to what I did many months ago  - simply checking for
CONFIG_BLK=y being enabled (using buildman -D).

Unfortunately, for ARM, this results in 517 out of 833 boards being removed!

This seems worse that the approach used in this series, checking
whether boards build with CONFIG_BLK forced on.

I do have another idea. I got a very large number of bounces from
maintainer emails from this series. I could collect all of those and
figure out which boards don't have maintainers with working emails,
and then remove them first.

The best solution IMO is for maintainers to take a little time to
convert boards over. I don't think this is a lot of work, particularly
if the board uses drivers which are already converted.

Regards,
Simon