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

["Arnd Bergmann" <arnd@arndb.de>]

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 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.

      Arnd