kernel/linux.git/Documentation/devicetree/bindings/memory-controllers, branch v7.0-rc7

Merge tag 'soc-dt-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2026-02-11T05:11:08+00:00

Pull SoC devicetree updates from Arnd Bergmann: "There are a handful of new SoCs this time, all of these are more or less related to chips in a wider family: - SpacemiT Key Stone K3 is an 8-core risc-v chip, and the first widely available RVA23 implementation. Note that this is entirely unrelated with the similarly named Texas Instruments K3 chip family that follwed the TI Keystone2 SoC. - The Realtek Kent family of SoCs contains three chip models rtd1501s, rtd1861b and rtd1920s, and is related to their earlier Set-top-box and NAS products such as rtd1619, but is built on newer Arm Cortex-A78 cores. - The Qualcomm Milos family includes the Snapdragon 7s Gen 3 (SM7635) mobile phone SoC built around Armv9 Kryo cores of the Arm Cortex-A720 generation. This one is used in the Fairphone Gen 6 - Qualcomm Kaanapali is a new SoC based around eight high performance Oryon CPU cores - NXP i.MX8QP and i.MX952 are both feature reduced versions of chips we already support, i.e. the i.MX8QM and i.MX952, with fewer CPU cores and I/O interfaces. As part of a cleanup, a number of SoC specific devicetree files got removed because they did not have a single board using the .dtsi files and they were never compile tested as a result: Samsung s3c6400, ST spear320s, ST stm32mp21xc/stm32mp23xc/stm32mp25xc, Renesas r8a779m0/r8a779m2/r8a779m4/r8a779m6/r8a779m7/r8a779m8/r8a779mb/ r9a07g044c1/r9a07g044l1/r9a07g054l1/r9a09g047e37, and TI am3703/am3715. All of these could be restored easily if a new board gets merged. Broadcom/Cavium/Marvell ThunderX2 gets removed along with its only machine, as all remaining users are assumed to be using ACPI based firmware. A relatively small number of 43 boards get added this time, and almost all of them for arm64. Aside from the reference boards for the newly added SoCs, this includes: - Three server boards use 32-bit ASpeed BMCs - One more reference board for 32-bit Microchip LAN9668 - 64-bit Arm single-board computers based on Amlogic s905y4, CIX sky1, NXP ls1028a/imx8mn/imx8mp/imx91/imx93/imx95, Qualcomm qcs6490/qrb2210 and Rockchip rk3568/rk3588s - Carrier board for SOMs using Intel agilex5, Marvell Armada 7020, NXP iMX8QP, Mediatek mt8370/mt8390 and rockchip rk3588 - Two mobile phones using Snapdragon 845 - A gaming device and a NAS box, both based on Rockchips rk356x On top of the newly added boards and SoCs, there is a lot of background activity going into cleanups, in particular towards getting a warning-free dtc build, and the usual work on adding support for more hardware on the previously added machines" * tag 'soc-dt-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (757 commits) dt-bindings: intel: Add Agilex eMMC support arm64: dts: socfpga: agilex: add emmc support arm64: dts: intel: agilex5: Add simple-bus node on top of dma controller node ARM: dts: socfpga: fix dtbs_check warning for fpga-region ARM: dts: socfpga: add #address-cells and #size-cells for sram node dt-bindings: altera: document syscon as fallback for sys-mgr arm64: dts: altera: Use lowercase hex dt-bindings: arm: altera: combine Intel's SoCFPGA into altera.yaml arm64: dts: socfpga: agilex5: Add IOMMUS property for ethernet nodes arm64: dts: socfpga: agilex5: add support for modular board dt-bindings: intel: Add Agilex5 SoCFPGA modular board arm64: dts: socfpga: agilex5: Add dma-coherent property arm64: dts: realtek: Add Kent SoC and EVB device trees dt-bindings: arm: realtek: Add Kent Soc family compatibles ARM: dts: samsung: Drop s3c6400.dtsi ARM: dts: nuvoton: Minor whitespace cleanup MAINTAINERS: Add Falcon DB arm64: dts: a7k: add COM Express boards ARM: dts: microchip: Drop usb_a9g20-dab-mmx.dtsi arm64: dts: rockchip: Fix rk3588 PCIe range mappings ...

Merge tag 'memory-controller-drv-6.20' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers

2026-01-29T09:13:55+00:00

Memory controller drivers for v6.20 1. Mediatek SMI: Fix old struct device reference leaks during error paths and device unbinding. 2. Memory Devicetree bindings: refactor existing LPDDR bindings and add bindings for DDR4 SDRAM. These will be used for example in stm32mp257f-ev1 DTS. * tag 'memory-controller-drv-6.20' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: dt-bindings: memory: SDRAM channel: standardise node name dt-bindings: memory: add DDR4 channel compatible dt-bindings: memory: factorise LPDDR channel binding into SDRAM channel dt-bindings: memory: introduce DDR4 dt-bindings: memory: factorise LPDDR props into SDRAM props memory: mtk-smi: clean up device link creation memory: mtk-smi: fix device leak on larb probe memory: mtk-smi: fix device leaks on common probe Signed-off-by: Arnd Bergmann

Merge tag 'tegra-for-6.20-dt-bindings-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt

2026-01-28T15:56:11+00:00

dt-bindings: Changes for v6.20-rc1 This series updates various DT bindings for Tegra architecture, primarily focusing on schema validation fixes and new feature documentation for Tegra234 and Tegra264 SoCs. Key changes include converting Tegra20 NAND bindings to YAML, and updating memory, DMA, and IOMMU definitions for Tegra264 (introducing CMDQV and DBB clock support). Additionally, it resolves legacy warnings for Tegra30/132 display and VI interfaces. * tag 'tegra-for-6.20-dt-bindings-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: dt-bindings: display: tegra: document Tegra30 VI and VIP dt-bindings: display: tegra: document Tegra132 MIPI calibration device dt-bindings: mtd: nvidia,tegra20-nand: convert to DT schema dt-bindings: dma: Update ADMA bindings for tegra264 dt-bindings: iommu: Add NVIDIA Tegra CMDQV support dt-bindings: memory: tegra: Document DBB clock for Tegra264 dt-bindings: tegra: pmc: Update aotag as an optional aperture

dt-bindings: memory: tegra: Document DBB clock for Tegra264

2026-01-16T12:28:22+00:00

Accesses to external memory are routed through the data backbone (DBB) on Tegra264. A separate clock feeds this path and needs to be enabled whenever an IP block makes an access to external memory. The external memory controller driver is the best place to control this clock since it knows how many devices are actively accessing memory. Document the presence of this clock on Tegra264 only. Acked-by: Rob Herring (Arm) Signed-off-by: Thierry Reding

dt-bindings: memory: SDRAM channel: standardise node name

2025-12-18T16:10:05+00:00

Add a pattern for sdram channel node name. Signed-off-by: Clément Le Goffic Reviewed-by: Rob Herring (Arm) Signed-off-by: Clément Le Goffic Link: https://patch.msgid.link/20251118-b4-ddr-bindings-v9-5-a033ac5144da@gmail.com Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory: add DDR4 channel compatible

2025-12-18T16:10:00+00:00

Add in the memory channel binding the DDR4 compatible to support DDR4 memory channel. Signed-off-by: Clément Le Goffic Reviewed-by: Rob Herring (Arm) Signed-off-by: Clément Le Goffic Link: https://patch.msgid.link/20251118-b4-ddr-bindings-v9-4-a033ac5144da@gmail.com Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory: factorise LPDDR channel binding into SDRAM channel

2025-12-18T16:09:39+00:00

LPDDR, DDR and so SDRAM channels exist and share the same properties, they have a compatible, ranks, and an io-width. Signed-off-by: Clément Le Goffic Reviewed-by: Rob Herring (Arm) Signed-off-by: Clément Le Goffic Link: https://patch.msgid.link/20251118-b4-ddr-bindings-v9-3-a033ac5144da@gmail.com Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory: introduce DDR4

2025-12-18T16:09:39+00:00

Introduce JEDEC compliant DDR bindings, that use new memory-props binding. The DDR4 compatible can be made of explicit vendor names and part numbers or be of the form "ddrX-YYYY,AAAA...-ZZ" when associated with an SPD, where (according to JEDEC SPD4.1.2.L-6): - YYYY is the manufacturer ID - AAAA... is the part number - ZZ is the revision ID The former form is useful when the SDRAM vendor and part number are known, for example, when memory is soldered on the board. The latter form is useful when SDRAM nodes are created at runtime by boot firmware that doesn't have access to static part number information. Signed-off-by: Clément Le Goffic Signed-off-by: Clément Le Goffic Reviewed-by: Rob Herring (Arm) Link: https://patch.msgid.link/20251118-b4-ddr-bindings-v9-2-a033ac5144da@gmail.com Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory: factorise LPDDR props into SDRAM props

2025-12-18T16:09:38+00:00

LPDDR and DDR bindings are SDRAM types and are likely to share the same properties (at least for density, io-width and reg). To avoid bindings duplication, factorise the properties. The compatible description has been updated because the MR (Mode registers) used to get manufacturer ID and revision ID are not present in case of DDR. Those information should be in a SPD (Serial Presence Detect) EEPROM in case of DIMM module or are known in case of soldered memory chips as they are in the datasheet of the memory chips. Signed-off-by: Clément Le Goffic Reviewed-by: Krzysztof Kozlowski Signed-off-by: Clément Le Goffic Link: https://patch.msgid.link/20251118-b4-ddr-bindings-v9-1-a033ac5144da@gmail.com Signed-off-by: Krzysztof Kozlowski

dt-bindings: Updates Linus Walleij's mail address

2025-12-16T16:17:59+00:00

My name is stamped into maintainership for a big slew of DT bindings. Now that it is changing, switch it over to my kernel.org mail address, which will hopefully be stable for the rest of my life. Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20251216-maintainers-dt-v1-1-0b5ab102c9bb@kernel.org Signed-off-by: Rob Herring (Arm)