On Thu, Nov 29, 2018 at 08:17:11PM +0100, Simon Goldschmidt wrote: > On 29.11.2018 20:06, Tom Rini wrote: > >On Thu, Nov 29, 2018 at 11:43:14AM -0700, Simon Glass wrote: > >>Hi Tom, > >> > >>On Thu, 29 Nov 2018 at 11:34, Tom Rini <tr...@konsulko.com> wrote: > >>>On Thu, Nov 29, 2018 at 10:10:01AM -0700, Simon Glass wrote: > >>>>Hi Tom, > >>>> > >>>>On Sun, 25 Nov 2018 at 11:19, Tom Rini <tr...@konsulko.com> wrote: > >>>>>The biggest part of migration to using CONFIG_BLK is that we need to > >>>>>have the various subsystems migrated first, so reword the plan here to > >>>>>reference the new deadlines. > >>>>> > >>>>>Cc: Simon Glass <s...@chromium.org> > >>>>>Signed-off-by: Tom Rini <tr...@konsulko.com> > >>>>>--- > >>>>> doc/driver-model/MIGRATION.txt | 12 +++++------- > >>>>> 1 file changed, 5 insertions(+), 7 deletions(-) > >>>>> > >>>>>diff --git a/doc/driver-model/MIGRATION.txt > >>>>>b/doc/driver-model/MIGRATION.txt > >>>>>index 6df7e02a63de..6b691338b4e7 100644 > >>>>>--- a/doc/driver-model/MIGRATION.txt > >>>>>+++ b/doc/driver-model/MIGRATION.txt > >>>>>@@ -39,14 +39,12 @@ CONFIG_BLK > >>>>> ---------- > >>>>> > >>>>> Status: In progress > >>>>>-Deadline: 2018.05 > >>>>>- > >>>>>-Maintainers should submit patches for enabling CONFIG_BLK on all boards > >>>>>in > >>>>>-time for inclusion in the 2018.05 release. Boards not converted by this > >>>>>-time may be removed in a subsequent release. > >>>>>+Deadline: 2019.07 > >>>>> > >>>>>-Note that this implies use of driver model for all block devices (e.g. > >>>>>-MMC, USB, SCSI, SATA). > >>>>>+In concert with maintainers migrating their block device usage to the > >>>>>+appropriate DM driver, CONFIG_BLK needs to be set as well. The final > >>>>>deadline > >>>>>+here coincides with the final deadline for migration of the various > >>>>>block > >>>>>+subsystems. > >>>>> > >>>>> CONFIG_DM_SPI > >>>>> CONFIG_DM_SPI_FLASH > >>>>My only concern here is the long deadline, more than a year after the > >>>>original one. Granted I should have been more proactive in sending > >>>>patches in May/June, but this has been fairly widely telegraphed IMO. > >>>>I know that opinions different on this matter. > >>>> > >>>>I'm also concerned about dealing with the SPL size issues that are > >>>>likely to come up, but with two implementations these problems are > >>>>masked. > >>>Yes, but I think I've been overly optimistic in my mental map of what > >>>has/hasn't been converted. While I hope we have what we need to make > >>>things work in SPL, or maybe only need to do some tweaking, I want a big > >>>enough window ahead that people aren't too stressed out when it turns > >>>out that we need, perhaps as came up in the SPI-nor series just now, a > >>>"tiny $something" subsystem and to work a bit more on the "tiny mmc" > >>>subsystem or what have you. I do plan to make noise and deadlines about > >>>SPL but since "everyone else" got to worry about U-Boot first and SPL > >>>second, I don't want to add more stress to the folks just now seeing > >>>urgency here. > >>> > >>>>Can I suggest an earlier deadline of 2019.01 instead? That effectively > >>>>gives people until about March/April to send patches. > >>>The problem is that we cannot make BLK be declared done until these > >>>other subsystems are also marked done. That was to me one of the big > >>>take-aways from the big series you did. We have enough boards that > >>>aren't so much broken at the board level (we do have those) but are > >>>broken at the driver-needs-converting level. And since it's really only > >>>"now" that everyone is seeing some of these, I don't think we can do > >>>things earlier than that. > >>> > >>>But that said, my meaning of deadline is that we drop things. So a > >>>v2019.01 deadline means that second week of January we would be dropping > >>>things, if we pushed BLK up. Since you said March/April there, I assume > >>>you're thinking that means a bit later on we drop things. If I re-word > >>>things to be clearer that stuff will be dropped post v2019.07 will that > >>>be better? > >> > >>OK I see. Yes that seems reasonable. > >> > >>Reviewed-by: Simon Glass <s...@chromium.org> > >> > >>It's been very quiet on this thread. > >That it's been so quiet is a bit worrying to me, yes. I am going to fix > >the warning message that Chris pointed out and push this out for -rc1, > >which will I suppose be the next starting point for "We need more time!" > >requests. > > I can't speak for everyone affected, but maybe I can give an example why > it's so quiet: > > At first I was shocked to see that all the socfpga boards should be removed. > Then I read that Simon got something wrong and that it's unclear which > boards were false positives. And now I'm confused and I'm waiting for you to > decide on action to tell what's actually to be done. > > I think we need a clear message of *what* needs to be upgraded. I do think > it's hard to see that for developers that aren't involved everyday with > U-Boot development. > > I think a build warning would be best. But maybe this is already pushed and > I'm not seeing it because socfpga was a false positive?
This series, which I just now v2'd is adding the build warnings with a formal deadline. We had only had BLK spelled out in the document but now I'm adding DM_MMC, DM_USB and moving-to-DM_SCSI, each with their own warning. BLK is only allowed once the subsystems that need BLK are done. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
