From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 21 Nov 2018 08:26:14 -0500 Subject: [U-Boot] [PATCH 00/93] dm: Move towards completing CONFIG_BLK migration In-Reply-To: References: <20181119155413.158098-1-sjg@chromium.org> <20181119215427.GP11247@bill-the-cat> Message-ID: <20181121132614.GQ11247@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Nov 20, 2018 at 09:43:04PM -0700, Simon Glass wrote: > Hi again, > > On Mon, 19 Nov 2018 at 14:58, Simon Glass wrote: > > > > Hi, > > > > On Mon, 19 Nov 2018 at 14:54, Tom Rini 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 wrote: > > > > >> > > > > >> On Mon, Nov 19, 2018 at 10:54 AM 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. > > > > >>> > > > > >>> 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. I think this is going the wrong way still. So I'll go and kick off a test set of builds where we make BLK be default y for DM and see what breaks. That will show us what subsystems / drivers haven't been converted yet and that in turn is what we need to deal with removing or converting. This isn't exactly a "board" issue but rather a driver issue and while there is some overlap I think aiming at boards is the wrong way. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: