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

Krzysztof Kozlowski
2026-02-05T08:49:58Z

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