Hi Tom, On Fri, 26 Mar 2021 at 13:14, Tom Rini <tr...@konsulko.com> wrote: > > On Thu, Mar 25, 2021 at 06:45:35PM -0400, Tom Rini wrote: > > On Fri, Mar 26, 2021 at 08:41:42AM +1300, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 26 Mar 2021 at 08:30, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > On Fri, Mar 26, 2021 at 08:11:30AM +1300, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Fri, 26 Mar 2021 at 08:05, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > > > > > On Fri, Mar 26, 2021 at 06:48:26AM +1300, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Fri, 26 Mar 2021 at 04:59, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > > > > > > > > > On Thu, Mar 25, 2021 at 01:39:28PM +1300, Simon Glass wrote: > > > > > > > > > > > > > > > > > This probably should have been done a while back since it is > > > > > > > > > a core > > > > > > > > > system. Add a migration deadline of later this year, to catch > > > > > > > > > the > > > > > > > > > stragglers. > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > > > > > > > > > > > > > > > What boards trigger this warning when done on top of say the > > > > > > > > WIP/remove-non-AHCI_LIBATA-drivers branch I've pushed to my > > > > > > > > github or > > > > > > > > WIP/make-DM_PCI-fatal which has more removals, but I need to > > > > > > > > cycle back > > > > > > > > to and finish removing even more boards I suspect. > > > > > > > > > > > > > > With us/WIP/make-DM_PCI-fatal it looks like 250. > > > > > > > > > > > > Ugh. Can you link me the CI run please? I'm curious about which. > > > > > > > > > > Sorry, I did it locally > > > > > > > > > > https://pastebin.com/Wq8vgtSx > > > > > > > > I'm having trouble with that, sorry. It looks like it's complaining > > > > about boards that with your series applied locally don't throw up a > > > > warning about I2C (but do for DM_ETH, which already has a soon > > > > deadline). > > > > > > Yes I was just going off the number of migration messages in the > > > output (using grep). > > > > > > > > > > > > > Then we can introduce this warning for v2021.04 (I'll grab it > > > > > > shortly) > > > > > > and set the deadline of v2022.04 (a year of being loud) and > > > > > > hopefully > > > > > > things are migrated / otherwise removed before v2024.04 and they get > > > > > > nuked like we're starting with now on v2019.xx deadlines. > > > > > > > > > > Do you mean 2022.04? My view has become that things that haven't been > > > > > done probably won't be, so we should save ourselves the trouble and > > > > > cost of maintaining the boards and just remove them now. For example, > > > > > the Kconfig migration would be in much better shape (although I > > > > > haven't analysed how much better). > > > > > > > > > > Note I sent a series to clean up the warnings, plus add I2C and GPIO, > > > > > so you should look at that instead of this patch. > > > > > > > > Well, lets get some numbers on what boards throw this I2C warning first. > > > > I did a quick merge of this series and pushed WIP/add-DM_I2C-warning > > > > right now and I'm doing the before/after build now. > > > > > > OK. > > > > So, the list of DM_I2C violators is: > > am335x_guardian am335x_shc am335x_shc_ict am335x_shc_netboot > > am335x_shc_sdboot cm_t335 cm_t43 chiliboard am335x_igep003x draco etamin > > rastaban thuban pxm2 rut am335x_sl50 am335x_baltos igep00x0 omap3_beagle > > omap3_evm devkit8000 omap4_panda omap4_sdp4430 omap5_uevm all of which > > are using the omap i2c driver, which has been converted. I've fired off > > a CI build now that just makes DM_I2C default y, lets see what still has > > a warning then. > > This brings us to https://source.denx.de/u-boot/u-boot/-/jobs/244066 > which shows sunxi throws an error...but I'll assume that's fixed in the > video update that's basically pending already. Then a handful of needed > migrations. I think a series that enables DM_I2C by default, disables > it on the boards it fails on and cc's the board maintainers to get them > to look (as I'm sure there's other migrations missing) would probably > help make sure this is all taken care of before a v2022.04 deadline. > > And I think v2022.04 is still right because the places this crops in are > boards with other, sooner, migration deadlines. There's no missing > driver migrations as best I can see. So if we say "you need to migrate > this thing you've had 3 years notice on, and also please take of these > other low-hanging quick migrations while you're here and testing on the > hardware" is going to be better received I think than "and we also just > added another super soon deadline too". And with enforcing some big > migrations just around the corner there'll be plenty of other "now we > can clean up and nuke the non-DM code that's not used for SPL/TPL" and > so on.
OK...will take a look. Regards, Simon