Re: [GIT PULL] arm/arm64: dts: socfpga: updates for v6.20

[Krzysztof Kozlowski <krzk@kernel.org>]

On 30/01/2026 13:12, Dinh Nguyen wrote:
> 
> 
> On 1/28/26 12:48, Krzysztof Kozlowski wrote:
>> On 24/01/2026 21:01, Dinh Nguyen wrote:
>>> The following changes since commit 8f0b4cce4481fb22653697cced8d0d04027cb1e8:
>>>
>>>    Linux 6.19-rc1 (2025-12-14 16:05:07 +1200)
>>>
>>> are available in the Git repository at:
>>>
>>>    git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_dts_updates_for_v6.20
>>>
>>> for you to fetch changes up to 1a457681c075e1bd894df753087cb4268ce9f9e9:
>>>
>>>    arm64: dts: intel: agilex5: Add simple-bus node on top of dma controller node (2026-01-02 07:52:44 -0600)
>>>
>>> ----------------------------------------------------------------
>>> SoCFPGA DTS updates for v6.20
>>> - dt-bindings updates:
>>> 	- Add dma-coherent for cdns,hp-nfc and snps,dw-axi-dmac
>>> 	- Add intel,socfpga-agilex5-socdk-modular for the Agilex5 mod board
>>> 	- Move entries in intel,socfpga.yaml into altera.yaml
>>> 	- Add syscon as a fallback for sys-mgr
>>>
>>> - Add dma-cohrerent property for Agilex5 NAND and DMA
>>> - Add support for the Agilex5 modular board
>>> - Add IOMMUS property for ethernet nodes for Agilex5
>>> - Use lowercase hex for dts files
>>> - Add #address-cells and #size-cells for sram
>>> - Fix dtbs_check warning for fpga-region
>>> - Move dma controller node for Agilex5 under simple-bus
>>>
>>> ----------------------------------------------------------------
>>> Dinh Nguyen (4):
>>>        dt-bindings: arm: altera: combine Intel's SoCFPGA into altera.yaml
>>>        dt-bindings: altera: document syscon as fallback for sys-mgr
>>>        ARM: dts: socfpga: add #address-cells and #size-cells for sram node
>>>        ARM: dts: socfpga: fix dtbs_check warning for fpga-region
>>>
>>> Khairul Anuar Romli (4):
>>>        dt-bindings: mtd: cdns,hp-nfc: Add dma-coherent property
>>>        dt-bindings: dma: snps,dw-axi-dmac: add dma-coherent property
>>
>>
>> These are not SoC patches, unless maintainers are unresponsive which I
>> believe is not a case here, so they should not be going via this tree.
>>
>> None of this, merged on 15th Dec, was fed to linux-next, so you don't
>> even know if this conflicts with maintainer trees thus pushing conflict
>> discover unto soc tree.
>>
>> Not being in the next is already a problem but gets more serious when
>> taking other subsystem patches.
>>
>> That's my comment, but Arnd was looking at these whether to merge.
>>
> 
> Apologies! I did not hear any feedback from those maintainers nor did I 
> remind them, so that's my fault. Let me rework this PR and take those 
> patches through the respective maintainer's tree.


The bigger problem is that none of these were in the next. You need to
solve this problem.

Best regards,
Krzysztof