On 11/19/2018 11:02 PM, Adam Ford wrote: > On Mon, Nov 19, 2018 at 3:54 PM Tom Rini <tr...@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 <tr...@konsulko.com> wrote: >>>>> >>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <s...@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. > > I remember the discussion, but it seems rather arbitrary for one > person to unilaterally start deleting boards. I think a more > appropriate approach would be to start a dialog instead of deleting > boards and then giving people a fairly short notice to respond - > especially this close to the US Thanksgiving holiday, several > religious holidays and New Years. Many people have planed time off > and/or end-of-year deadlines to hit without getting an abrupt suprise.
ACK -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
