[PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[neil.armstrong at linaro.org]

On 14/12/2023 21:15, Tom Rini wrote:
> On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote:
>> On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini at konsulko.com> wrote:
>>>
>>> On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong at linaro.org wrote:
>>>> Hi,
>>>>
>>>> On 14/12/2023 14:50, Sumit Garg wrote:
>>>>> Prerquisite
>>>>
>>>> s/Prerquisite/Prerequisite/
>>>>
>>>>> -----------
>>>>>
>>>>> This patch series requires devicetree-rebasing git repo to be added as a
>>>>> subtree to the main U-boot repo via:
>>>>>
>>>>> $ git subtree add --prefix devicetree-rebasing \
>>>>>         git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \
>>>>>         v6.6-dts --squash
>>>>
>>>> So I think the big question is: when should the subtree be updated ?
>>>>
>>>> Because as we discussed in the previous GH pull request, if a bindings changes
>>>> was made in the upstream Linux DT, then the subtree update should wait until
>>>> the u-boot support is merged before updating. This could cause a lot of frustration.
>>>>
>>>> And this could cause a lot of regressions, even more if both Linux and U-boot are
>>>> not maintained by the same people.
>>>
>>> I think some of the important questions to ask are, how often / likely
>>> are the breakages to occur? It seems like these days it's either:
>>> - U-Boot had an early version of the binding and we already state we
>>>    don't support backwards compatibility here. It should be on the
>>>    maintainer to be proactive in this case.
>>> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
>>>    incompatible DTS change now". This too is hopefully the kind of thing
>>>    that at least board maintainers will be more actively aware of needing
>>>    to deal with in U-Boot, if it's really a problem.
>>
>> A common issue in the kernel is with forward compatibility when
>> platforms add new resources from a new provider. Then the kernel
>> expects a driver for the provider and waits for the dependency. Of
>> course, older kernels don't have that provider driver and so the
>> dependency is never met. Not sure if u-boot will have similar issues?
>> At least you should/could know if the provider driver exists or not.
>> (The kernel doesn't because modules.)
> 
> I think we'll be fine, but time will tell. And perhaps the more frequent
> re-syncing will make any sort of corner cases show up more quickly and
> be something we can figure out how to resolve going forward really.
> 

Sure, I suppose I'll only switch the stable boards, and keep the in-progress ones
with manual sync.
And I'll need to make a prerequisite to any breaking DT change to have the corresponding
U-Boot change submitted before (and probably other OSes like *BSD*s)

Neil