[U-Boot] [RFC for-v2019.01 4/4] dm: MIGRATION: Update migration plan for BLK

[Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>]

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 <trini@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 <trini@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 <sjg@chromium.org>
>>>>> Signed-off-by: Tom Rini <trini@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 <sjg@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?

Regards,
Simon