[GIT PULL] amlogic ARM64 DT updates for v7.1

[Neil Armstrong]

On 4/20/26 17:25, Arnd Bergmann wrote:
> On Mon, Apr 13, 2026, at 09:30, Krzysztof Kozlowski wrote:
>> On 13/04/2026 09:17, Krzysztof Kozlowski wrote:
>>> On 13/04/2026 09:10, Neil Armstrong wrote:
>>>>>
>>>>> I will wait with this. It might miss the merge window if v7.0 is
>>>>> released this weekend.
>>>>
>>>> Ok wow, just like that... I mean the amlogic DT is stable, all patches
>>>> patches bindings checks and none is critical since it mainly touches
>>>
>>> You sent your pull very late, just before v7.1, and skipping late
>>> posting is not a new rule. It was always going late pulls, which might
>>> make it or might not make it.
>>>
>>>> new platforms and the incriminated commit is a low priority fix for
>>>> 10y old development boards...
>>>
>>> I did not check which commit was not in next. You can provide feedback
>>> to my reply with actual argument, because such explanation was missing
>>> in tag. Instead you decided to be surprised that patches needs to be in
>>> next...
>>>
>>
>> And to clarify, I did not say that pull will not make it. Considering
>> the timeline:
>> 1. You sent the pull on 10th April, Friday
>> 2. v7.1 is released on 13th April, Sunday
>>
>> and that people are allowed to take weekends off, then there is simply
>> almost no way that pull can be merged before v7.1 is released, so by
>> definition it is a *late pull*. The policy for late pulls, like that,
>> did not change.
>>
>> Lack of exposure of a few commits to linux-next is only the explanation
>> why I did not pull it while doing last round of pulls.
> 
> I'm looking through the backlog for any missing fixes that should
> still make it into -rc1 or -rc2. Just a few more points to add
> from my end:
> 
> - I had in the past always trusted platform maintainers to only
>    send pull requests when they felt the contents had spent enough
>    time in linux-next already, but I did not have any scripting
>    to ensure this was done correctly.
> 
> - I see that only a few of the patches in the branch got applied
>    during the fineal days before the merge window, while the rest
>    had been part of next-20260330 or earlier. Aside from just
>    sending the bulk of the contents earlier, I think the best
>    solution on Neil's side would have been to send two separate
>    pull requests, for the earlier and the later contents
>    respectively, even if sending them on the same day

I never did a split because I don't have enought changes to justify
2 PRs and I had some contributors & other maintainers activity late
in the cycle.
Anyway I'll make sure to send the PRs earlier.

> 
> - I see that some of the late commits are clear bugfixes that
>    we should still merge as soon as possible. Neil, can you go
>    through the branch and send another PR for anything that
>    qualifies as a bugfix? While by now it's clearly too late
>    for any of the new features, there is no need to delay those
>    any further.

The fixes are clearly low priority, but I can lop over and send them as fixes.

Thanks,
Neil

> 
>        Arnd