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

[Dinh Nguyen <dinguyen@kernel.org>]

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.

DInh