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. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
