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

[Neil Armstrong]

On 4/13/26 09:17, Krzysztof Kozlowski wrote:
> On 13/04/2026 09:10, Neil Armstrong wrote:
>> On 4/11/26 11:32, Krzysztof Kozlowski wrote:
>>> On Fri, Apr 10, 2026 at 10:50:58AM +0200, Neil Armstrong wrote:
>>>> Hi,
>>>>
>>>> Here's the Amlogic ARM64 DT changes for v7.1, including a bunch of fixes
>>>> and improvements for the Khadas VIM4 and VIM1s SBCs, plus some additions
>>>> for the Phicomm N1 and a couple of low priority fixes.
>>>>
>>>> Thanks,
>>>> Neil
>>>>
>>>> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>>>>
>>>>     Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>     https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git tags/amlogic-arm64-dt-for-v7.1
>>>>
>>>> for you to fetch changes up to 401e5c73eedde8225e87bd11c794b8409248ff41:
>>>>
>>>>     arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number (2026-04-08 14:27:20 +0200)
>>>
>>> Days in linux-next:
>>> ----------------------------------------
>>>    1 | ++++++++ (8)
>>>    ...
>>>
>>> So a few things were just applied, unless this was rebased?
>>
>> This one has been applied lately, but this is news for me, I always took
>> in account the time spent in the lists, not in linux-next.
>> I made sure this one landed at least once in -next to trigger CIs.
>>
>> So if there’s new rules, we should be made aware of those.
> 
> How is it a new rule? Linus posting from 2023:
> 
> https://lore.kernel.org/all/CAHk-=wgXDTfWFbn-481=it6W_B0KTQsOhdgXL6mweVm6ewtSvA@mail.gmail.com/
> 
> Plus this is simply logic - why soc tree should be the first tree
> exposed to integration issues and robot reports? If soc tree merges
> stuff which was not on next, all such reports will be applicable to soc
> tree as well. That's nothing new about this.

1) It was in next
2) My tree is clean, review and bindings are tested
3) My PR is a minor PR, low priority change, low impact, no risk

There's still people sending commits to Linux which didn't even go to the lists,
so it's irrelevant to apply this vague rule to me in a strict way with not reasoning.

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

Yes I've been late, my bad, not the first time, never been rejected before for that.

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

No, I'm surprised because there's still a lot of subsystems not in -next
and I've always made sure my tree were in next before sending PRs, were
building properly with no warning and bindings checked.

Neil

> 
> 
> Best regards,
> Krzysztof