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

[Neil Armstrong]

On 4/13/26 09:30, Krzysztof Kozlowski wrote:
> On 13/04/2026 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.
>>
>>>
>>>>
>>>> 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

Stop this nonsense, there's a very high probability release are done after rc7,
but it's not a strict rule at all.

> 
> 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.
> 
> Feel free to ignore that explanation and take other one: avoid sending
> pulls a one working day before new release, because it is considered a
> late pull.

I understood your explanation, crystal clear.

Neil

> 
> Best regards,
> Krzysztof