[PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0

[Marek Vasut]

On 12/4/22 13:59, Thorsten Leemhuis wrote:
> On 04.12.22 13:50, Marek Vasut wrote:
>> On 12/2/22 16:56, Thorsten Leemhuis wrote:
>>> On 02.12.22 15:31, Marek Vasut wrote:
>>>> On 12/2/22 15:05, Miquel Raynal wrote:
>>>> [...]
>>>>> 3. To fix the current situation:
>>>>>       Immediately revert commit (and prevent it from being backported):
>>>>>       753395ea1e45 ("ARM: dts: imx7: Fix NAND controller size-cells")
>>>>>       This way your own boot flow is fixed in the short term.
>>>>
>>>> Here I disagree, the fix is correct and I think we shouldn't proliferate
>>>> incorrect DTs which don't match the binding document. Rather, if a
>>>> bootloader generates incorrect (new) DT entries, I believe the driver
>>>> should implement a fixup and warn user about this. PC does that as well
>>>> with broken ACPI tables as far as I can tell.
>>>
>>> Well, that might be the right solution in the long run, that's up for
>>> others to decide, but we need to fix this *quickly*. For two reasons
>>> actually: the 6.1 release is near and the change was backported to
>>> stable already.
>>>
>>> For details wrt to the "quickly", see "Prioritize work on fixing
>>> regressions" here:
>>> https://docs.kernel.org/process/handling-regressions.html
>>>
>>> IOW: Ideally it should be fixed by Sunday.
>>>
>>> I'll hence likely soon will point Linus to this and suggest to revert
>>> this, unless there are strong reasons against that or some sort of
>>> agreement on a better solution.
>>
>> You might want to wait until everyone is back on Monday, the discussion
>> is still ongoing, but it seems to be getting to a conclusion.
> 
> Yeah, came to a similar conclusion, but want to mentioned it
> nevertheless and already have this prepared (together will appropriate
> links to the discussion):
> 
> ```
> A regression causing boot failures on iMX7 (due to a backport this is
> also affecting 6.0.y) could be fixed with a quick revert as well. But
> looks like there is no need for it, after some back and forth the
> developers that care are close to come to an agreement how to fix the
> problem properly soonish:
> ```

ACK, thanks