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

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

[Neil Armstrong]

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)

----------------------------------------------------------------
Amlogic ARM64 DT for v7.1:
- Khadas VIM4 (T7 SoC) Fixes and features:
  - Memory layout fixup
  - GIC register range
  - Model name fixup
  - PWM, eMMC, SD card and SDIO support
- Khadas VIM1s Features
  - Bluetooth
  - PWM LED
  - Power Key
  - Function Key via SARADC
  - RTC
  - Remote control keymap
- Bluetooth node for Phicomm N1
- Misc fixes:
  - Drop CPU masks from GICv3 PPI interrupts
  - Fix ethernet PHY gpio irq index for P230

----------------------------------------------------------------
Anand Moon (1):
       arm64: dts: amlogic: meson-axg: Add missing cache information to cpu0

Geert Uytterhoeven (1):
       arm64: dts: amlogic: s6: Drop CPU masks from GICv3 PPI interrupts

Jian Hu (1):
       arm64: dts: amlogic: t7: Add clock controller nodes

Jun Yan (2):
       arm64: dts: amlogic: meson-gxl-s905d-phicomm-n1: add bluetooth node
       arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number

Nick Xie (11):
       arm64: dts: amlogic: t7: khadas-vim4: fix memory layout for 8GB RAM
       arm64: dts: amlogic: t7: khadas-vim4: fix board model name
       arm64: dts: amlogic: meson-s4: add UART_A node
       arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: enable bluetooth
       arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: add PWM LED support
       arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: add POWER key support
       arm64: dts: amlogic: meson-s4: add internal SARADC controller
       arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: add Function key support
       arm64: dts: amlogic: meson-s4: add VRTC node
       arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: enable HYM8563 RTC
       arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: use rc-khadas keymap

Ronald Claveau (10):
       arm64: dts: amlogic: Fix GIC register ranges for Amlogic T7
       arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
       arm64: dts: amlogic: t7: Add PWM pinctrl nodes
       arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
       arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
       arm64: dts: amlogic: t7: Add MMC controller nodes
       arm64: dts: amlogic: t7: Add PWM controller nodes
       arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
       arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
       arm64: dts: amlogic: t7: Fix missing required reset property

  arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi        |  10 +-
  .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts  | 205 ++++++++-
  arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi        | 468 ++++++++++++++++++++-
  arch/arm64/boot/dts/amlogic/meson-axg.dtsi         |   6 +
  .../boot/dts/amlogic/meson-gxl-s905d-p230.dts      |   3 +-
  .../dts/amlogic/meson-gxl-s905d-phicomm-n1.dts     |  15 +
  .../dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts   |  81 ++++
  arch/arm64/boot/dts/amlogic/meson-s4.dtsi          |  45 ++
  8 files changed, 824 insertions(+), 9 deletions(-)

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

[Krzysztof Kozlowski]

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?

I will wait with this. It might miss the merge window if v7.0 is
released this weekend.

Best regards,
Krzysztof

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

[Neil Armstrong]

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.

> 
> 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
new platforms and the incriminated commit is a low priority fix for
10y old development boards...

Neil

> 
> Best regards,
> Krzysztof
> 

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

[Krzysztof Kozlowski]

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


Best regards,
Krzysztof

Re: [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

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

[Krzysztof Kozlowski]

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

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.

Best regards,
Krzysztof

Re: [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

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

[Krzysztof Kozlowski]

On 13/04/2026 09:45, Neil Armstrong wrote:
> 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.

What is the "nonsense" here (except my mistake 13th April -> 12th, and
earlier "before v7.1" were I meant v7.0 obviously)?

$ git show v7.0
tag v7.0
Tagger: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Apr 12 13:48:06 2026 -0700

Earlier wrote:
" if v7.0 is released this weekend."

I said before that if release is made this Sunday, then this pull might
miss it. If release was not made, the pull would have time, that is
implied by the "if" part in my sentence.

Best regards,
Krzysztof

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

[Arnd Bergmann]

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

Re: [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

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

[Arnd Bergmann]

On Mon, Apr 20, 2026, at 19:31, Neil Armstrong wrote:
> On 4/20/26 17:25, Arnd Bergmann wrote:
>> On Mon, Apr 13, 2026, at 09:30, Krzysztof Kozlowski wrote:
>> - 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.

Ok, thanks! Note that I rarely complain about a follow-up PR
being late. If you have the majority of the content queued up
early enough and have a few more things or even just a single
fix later, that's not an issue at all.

     Arnd