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

Neil Armstrong
2026-04-20T17:31:35Z

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