* [GIT PULL 1/4] i.MX arm64 dts changes for v7.1
From: Frank Li @ 2026-03-30 14:14 UTC (permalink / raw)
To: soc, arm
Cc: Frank.Li, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260330141444.3789193-1-Frank.Li@nxp.com>
From: Frank.Li@nxp.com
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-dt64-7.1
for you to fetch changes up to 825b8c7e1d2918d89eb378b761530d1e51dba82e:
arm64: dts: imx8qxp-mek: switch Type-C connector power-role to dual (2026-03-27 09:53:32 -0400)
----------------------------------------------------------------
i.MX arm64 device tree changes for 7.1:
- New Board Support
S32N79-RDB, Variscite DART-MX95, DART-MX91 with Sonata carrier boards,
Verdin iMX95 with multiple carrier boards (Yavia, Mallow, Ivy, Dahlia)
TQMa93xx/MBa93xxLA-MINI, SolidRun i.MX8MP HummingBoard IIoT,
SolidRun i.MX8MM SOM and EVB, SolidRun SolidSense-N8 board
Ka-Ro Electronics tx8m-1610 COM, GOcontroll Moduline IV and Moduline Mini,
NXP FRDM-IMX91S board, i.MX93 Wireless EVK board with Wireless SiP,
NXP i.MX8MP audio board v2.
- USB & Type-C Support
Type-C and USB nodes for imx943, correct power-fole for
imx8qxp-mek/imx8qm-mek.
- Audio Enhancements
PDM microphone, bt-sco, and WM8962 sound card support for i.MX952. AONMIX
MQS for i.MX95. Use audio-graph-card2 for imx8dxl-evk. WM8904 audio codec
for imx8mm-var-som.
- Thermal & Cooling
PF09/53 thermal zone, fan node, active cooling on A55, SCMI
sensor/lmm/cpu for imx943/imx94.
- Display Support
Multiple LVDS and parallel display overlays for TQ boards (imx91/imx93).
Parallel display for i.MX93. ontat,kd50g21-40nt-a1 panel for
imx93-9x9-qsb. pixpaper display overlay for i.MX93 FRDM.
- Networking
Multiple queue configuration on eqos for TQMa8MPxL.
MaxLinear PHY support, MCP251xFD CAN controller for imx8mm-var-som.
SDIO WiFi support (imx91-evk, imx8mp-evk, imx943-evk)
- Bluetooth Support
imx943-evk, imx93-14x14-evk, imx95-19x19-evk, imx8mp-evk, imx8mn-evk,
imx8mm-evk.
- Miscellaneous
xspi and MT35XU01G SPI NOR flash for i.MX952.
V2X/ELE mailbox nodes, SCMI misc ctrl-ids for imx94.
eDMA channel reservation for V2X, Cortex M7 support for imx95.
Ethos-U65 NPU and SRAM nodes for imx93.
Wire up DMA IRQ for PCIe for imx8qm-ss-hsio.
- Bug Fixes & Improvements
Complete pinmux for rcwsr12 to fix I2C bus recovery affect other module
pinmux for layscape platform.
Multiple bug fixes for GPIO polarity, IRQ types, pinmux configurations.
GICv3 PPI interrupt CPU mask cleanup across multiple SoCs.
Fixed Ethernet PHY IRQ types on TQ boards.
Fixed UART RTS/CTS muxing issues.
Fixed SD card issues on Kontron boards.
Fixed touch reset configuration.
Removed fallback ethernet-phy-ieee802.3-c22 where appropriate.
Move funnel outside from soc.
TMU sensor ID cleanup.
Change usdhc tuning step for eMMC and SD.
Hexadecimal format, readability improvements, duplicate removal.
----------------------------------------------------------------
Alexander Stein (23):
arm64: dts: tqma8mpql-mba8mpxl: Configure multiple queues on eqos
arm64: dts: tqma8mpql-mba8mp-ras314: Configure multiple queues on eqos
arm64: dts: imx8qm-ss-hsio: Wire up DMA IRQ for PCIe
arm64: dts: tqma9352-mba93xx*: Change Ethernet PHY IRQ to IRQ_TYPE_LEVEL_LOW
arm64: dts: tqma9352-mba91xxca: Change Ethernet PHY IRQ to IRQ_TYPE_LEVEL_LOW
arm64: dts: imx91: Remove TMU's superfluous sensor ID
arm64: dts: imx8mp-tqma8mpql-mba8mpxl-g133han01: Remove compatible from overlay
arm64: dts: imx8mp-tqma8mpql-mba8mpxl-tm070jvhg33: Remove compatible from overlay
arm64: dts: imx8mq-tqma8mq-mba8mx-tm070jvhg33: Remove compatible from overlay
arm64: dts: imx8mn-tqma8mqnl-mba8mx-tm070jvhg33: Remove compatible from overlay
arm64: dts: imx8mm-tqma8mqml-mba8mx-tm070jvhg33: Remove compatible from overlay
arm64: dts: imx93-tqma9352-mba91xxca: Add parallel display overlay
arm64: dts: imx93-tqma9352-mba91xxca: Add LVDS display overlay
arm64: dts: imx91-tqma9131-mba91xxca: Add parallel display overlay
arm64: dts: imx91-tqma9131-mba91xxca: Add LVDS display overlay
arm64: dts: imx8mm: Explicitly set DSI_PHY_REF clock as a child of CLK_24M
arm64: dts: imx8mm-tqma8mqml-mba8mx: LVDS overlay: Reduce DSI burst clock to 600Mhz
arm64: dts: imx8mn-tqma8mqnl-mba8mx: LVDS overlay: Reduce DSI burst clock to 600Mhz
arm64: dts: imx95: Move funnel outside from soc
arm64: dts: mba8mx: Add DSI->LVDS bridge IRQ
arm64: dts: freescale: tqma8mqml/tqma8mxnl-mba8mx: Add dual-channel LVDS overlay
arm64: dts: imx8mp-tqma8mpql-mba8mp-ras314: add vcc supply for BT device
arm64: dts: imx8mp-tqma8mpql: Add DT overlays to explicit list
Andrej Picej (1):
arm64: dts: imx93-phyboard-segin: Add peb-av-02 overlay
Annette Kobou (1):
arm64: dts: imx8mp-kontron: Fix boot order for PMIC and RTC
Ciprian Marian Costea (2):
arm64: dts: freescale: Add NXP S32N79 SoC support
arm64: dts: freescale: Add NXP S32N79-RDB board support
Daniel Baluta (2):
arm64: dts: imx8mp: Make MX8MP_I2C_DEFAULT independent on drive strength
arm64: dts: imx8mp-frdm: Use symbolic macros for IOMUXC_SW_PAD_CTL_PAD
Eduard Bostina (1):
arm64: dts: imx8mp-dhcom-pdk3: Use symbolic macro for IOMUXC_SAI2_TXC__GPIO4_IO25
Emanuele Ghidoli (2):
arm64: dts: freescale: imx95-toradex-smarc: fix PMIC_SD2_VSEL label position
arm64: dts: freescale: imx95-toradex-smarc: Support Cortex M7
Ernest Van Hoecke (5):
arm64: dts: freescale: Add Verdin iMX95 support
arm64: dts: freescale: imx95-verdin: Add Dahlia carrier board
arm64: dts: freescale: imx95-verdin: Add Ivy carrier board
arm64: dts: freescale: imx95-verdin: Add Mallow carrier board
arm64: dts: freescale: imx95-verdin: Add Yavia carrier board
Fabian Pfitzner (1):
arm64: dts: imx8mp-frdm: add sd, ethernet, wifi, usb and hdmi support
Florin Leotescu (1):
arm64: dts: imx943-evk: Add fan node and enable active cooling on A55
Francesco Dolcini (3):
arm64: dts: imx8-apalis: Disable the audmix
arm64: dts: imx8-apalis: Remove obsolete TODO comment
arm64: dts: imx8-apalis: Fix LEDs name collision
Frank Li (3):
arm64: dts: imx8mm-evk: replace space with tab
arm64: dts: imx8mp-evk: replace space with tab
arm64: dts: imx8mp-beacon: remove fallback ethernet-phy-ieee802.3-c22
Frieder Schrempf (3):
arm64: dts: imx8mp-kontron: Fix touch reset configuration on DL devices
arm64: dts: imx8mp-kontron: Drop vmmc-supply to fix SD card on SMARC eval carrier
arm64: dts: imx8mp-kontron: Use GPIO/IRQ defines in DL devicetree
Fugang Duan (1):
arm64: dts: imx8mm-evk: add uart3 port
Geert Uytterhoeven (2):
arm64: dts: fsl-ls1028a: Drop CPU masks from GICv3 PPI interrupts
arm64: dts: freescale: imx: Drop CPU masks from GICv3 PPI interrupts
Haibo Chen (2):
arm64: dts: imx952: Add xspi node
arm64: dts: imx952-evk: add MT35XU01G spi nor flash
Josua Mayer (17):
arm64: dts: imx8mp-hummingboard-pulse/cubox-m: fix vmmc gpio polarity
arm64: dts: imx8mp-hummingboard-pulse: fix mini-hdmi dsi port reference
arm64: dts: imx8mp-sr-som: build dtbs with symbols for overlay support
arm64: dts: freescale: add support for SolidRun i.MX8MP HummingBoard IIoT
arm64: dts: imx8mp-hummingboard-iiot: add dt overlays for muxable ports
arm64: dts: freescale: add support for solidrun solidsense-n8 board
arm64: dts: freescale: add support for solidrun i.mx8mm som and evb
arm64: dts: lx2160a-cex7/lx2162a-sr-som: fix usd-cd & gpio pinmux
arm64: dts: lx2160a: change i2c0 (iic1) pinmux mask to one bit
arm64: dts: lx2160a: remove duplicate pinmux nodes
arm64: dts: lx2160a: rename pinmux nodes for readability
arm64: dts: lx2160a: add sda gpio references for i2c bus recovery
arm64: dts: lx2160a: change zeros to hexadecimal in pinmux nodes
arm64: dts: lx2160a: complete pinmux for rcwsr12 configuration word
arm64: dts: lx2160a-cex7: add rtc alias
arm64: dts: lx2162a-sr-som: add crypto & rtc aliases, model
arm64: dts: lx2162a-clearfog: set sfp connector leds function and source
Joy Zou (3):
arm64: dts: imx95: Reserve eDMA channels 0-1 for V2X
arm64: dts: imx95-evk: update the dma-channel-mask property
arm64: dts: imx943: Add thermal support
Laurentiu Mihalcea (2):
arm64: dts: imx95: add AONMIX MQS node
arm64: dts: imx95-15x15-frdm: support AONMIX MQS
Liu Ying (2):
arm64: dts: imx93-9x9-qsb: Add ontat,kd50g21-40nt-a1 panel
arm64: dts: imx8mp-evk: Specify ADV7535 register addresses
Luke Wang (2):
arm64: dts: imx91-11x11-evk: change usdhc tuning step for eMMC and SD
arm64: dts: imx93-11x11-evk: change usdhc tuning step for eMMC and SD
Marco Felsch (1):
arm64: dts: imx93: Add parallel display output nodes
Martin Schmiedel (2):
arm64: dts: freescale: add initial device tree for TQMa93xx/MBa93xxLA-MINI
arm64: dts: freescale: imx93-tqma9352-mba93xxla-mini: Add WLAN/BT overlay
Maud Spierings (4):
arm64: dts: imx8mm: Add pinctrl config definitions
arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM
arm64: dts: freescale: Add the GOcontroll Moduline IV
arm64: dts: freescale: Add the GOcontroll Moduline Mini
Nora Schiffer (1):
arm64: dts: freescale: imx8mp-tqma8mpql-mba8mp-ras314: fix UART1 RTS/CTS muxing
Peng Fan (4):
arm64: dts: imx94: Add V2X/ELE mailbox nodes
arm64: dts: imx94: Add SCMI sensor/lmm/cpu nodes
arm64: dts: imx943-evk: Add nxp,ctrl-ids for scmi_misc
arm64: dts: imx943-evk: Add pf09/53 thermal zone
Primoz Fiser (1):
arm64: dts: freescale: imx93-phy{core,board}: Add i2c bus recovery
Ranjani Vaidyanathan (1):
arm64: dts: imx94: Update pin headers
Rob Herring (Arm) (1):
arm64: dts: freescale: imx93: Add Ethos-U65 NPU and SRAM nodes
Shengjiu Wang (7):
arm64: dts: imx8mm-evk: correct the spdif compatible string
arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)
arm64: dts: imx952: Add audio device nodes
arm64: dts: imx952-evk: Add sound-wm8962 support
arm64: dts: imx952-evk: Add bt-sco sound card support
arm64: dts: imx952-evk: Add PDM microphone sound card support
arm64: dts: imx8dxl-evk: Use audio-graph-card2 for wm8960-2 and wm8960-3
Sherry Sun (16):
arm64: dts: imx8mm-evk: add uart1 and bluetooth node
arm64: dts: imx8mn-evk: add bluetooth dts node
arm64: dts: imx8mp-evk: add bluetooth dts node
arm64: dts: imx93-evk/qsb: add m2-pcm-level-shifter-hog to enable BT HFP
arm64: dts: imx95-19x19-evk: enable lpuart5 for Bluetooth support
arm64: dts: imx93-14x14-evk: enable lpuart5 for Bluetooth
arm64: dts: imx943-evk: enable lpuart6 for Bluetooth
arm64: dts: imx93: Extract common EVK description into shared dtsi
arm64: dts: imx93: Move 11x11 EVK specific parts back to imx93-11x11-evk.dts
arm64: dts: imx93: Add imx93w.dtsi for i.MX93 Wireless SiP
arm64: dts: imx93: Add i.MX93 Wireless EVK board support
arm64: dts: imx943-evk: add usdhc3 for SDIO WiFi support
arm64: dts: imx8mp-evk: Enable pull select bit for PCIe regulator GPIO (M.2 W_DISABLE1)
arm64: dts: imx8mp-evk: Add usdhc1 for SDIO WiFi support
arm64: dts: imx91-11x11-evk: Add usdhc3 for SDIO WiFi support
arm64: dts: imx95-15x15-evk: remove regulator-always-on for reg_m2_pwr
Stefano Radaelli (15):
arm64: dts: freescale: imx8mm-var-som: Move UART4 description to Symphony
arm64: dts: freescale: imx8mm-var-som: Align fsl,pins tables
arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY
arm64: dts: freescale: imx8mm-var-som: Add support for WM8904 audio codec
arm64: dts: freescale: imx8mm-var-som: Add MCP251xFD CAN controller
arm64: dts: freescale: imx8mm-var-som: Rework WiFi/BT and add legacy dts
arm64: dts: imx8mm-var-som-symphony: Move USB configuration from SOM
arm64: dts: imx8mm-var-som-symphony: Enable uSD on USDHC2
arm64: dts: imx8mm-var-som-symphony: Add TPM2 support
arm64: dts: imx8mm-var-som-symphony: Enable I2C4
arm64: dts: imx8mm-var-som-symphony: Enable PCIe
arm64: dts: freescale: Add support for Variscite DART-MX91
arm64: dts: imx91-var-dart: Add support for Variscite Sonata board
arm64: dts: freescale: Add support for Variscite DART-MX95
arm64: dts: imx95-var-dart: Add support for Variscite Sonata board
Wig Cheng (1):
arm64: dts: freescale: add pixpaper display overlay for i.MX93 FRDM
Xu Yang (5):
arm64: dts: imx94: add USB nodes
arm64: dts: imx943-evk: add Type-C and USB related nodes
arm64: dts: freescale: imx8mp-moduline-display-106: add typec-power-opmode property
arm64: dts: imx8qm-mek: switch Type-C connector power-role to dual
arm64: dts: imx8qxp-mek: switch Type-C connector power-role to dual
Yanan Yang (1):
arm64: dts: freescale: add NXP FRDM-IMX91S board support
arch/arm64/boot/dts/freescale/Makefile | 74 ++
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 15 +-
.../arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi | 10 +-
.../dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 2 +
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 183 ++-
.../boot/dts/freescale/fsl-lx2162a-clearfog.dts | 10 +
.../boot/dts/freescale/fsl-lx2162a-sr-som.dtsi | 19 +-
.../arm64/boot/dts/freescale/imx8-apalis-eval.dtsi | 4 -
.../boot/dts/freescale/imx8-apalis-ixora-v1.1.dtsi | 10 +-
.../boot/dts/freescale/imx8-apalis-ixora-v1.2.dtsi | 10 +-
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 114 +-
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 78 +-
.../dts/freescale/imx8mm-hummingboard-ripple.dts | 335 ++++++
arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h | 33 +
arch/arm64/boot/dts/freescale/imx8mm-sr-som.dtsi | 393 +++++++
.../imx8mm-tqma8mqml-mba8mx-lvds-g133han01.dtso | 86 ++
.../imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtso | 9 +-
.../boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts | 1 -
.../imx8mm-tx8m-1610-moduline-iv-306-d.dts | 799 ++++++++++++++
.../imx8mm-tx8m-1610-moduline-mini-111.dts | 687 ++++++++++++
.../arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi | 444 ++++++++
.../freescale/imx8mm-var-som-symphony-legacy.dts | 19 +
.../boot/dts/freescale/imx8mm-var-som-symphony.dts | 214 +++-
.../freescale/imx8mm-var-som-wifi-brcm-legacy.dtsi | 12 +
.../freescale/imx8mm-var-som-wifi-bt-iw61x.dtsi | 45 +
arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi | 366 +++---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 19 +-
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 4 +
.../dts/freescale/imx8mn-solidsense-n8-compact.dts | 851 ++++++++++++++
.../imx8mn-tqma8mqnl-mba8mx-lvds-tm070jvhg33.dtso | 7 +-
.../boot/dts/freescale/imx8mn-tqma8mqnl-mba8mx.dts | 1 -
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 11 +-
arch/arm64/boot/dts/freescale/imx8mp-ab2.dts | 912 +++++++++++++++
.../arm64/boot/dts/freescale/imx8mp-beacon-kit.dts | 3 +-
.../boot/dts/freescale/imx8mp-beacon-som.dtsi | 3 +-
arch/arm64/boot/dts/freescale/imx8mp-cubox-m.dts | 2 +-
.../arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 98 +-
arch/arm64/boot/dts/freescale/imx8mp-frdm.dts | 538 ++++++++-
...hummingboard-iiot-panel-dsi-WJ70N3TYJHMNG0.dtso | 67 ++
...ummingboard-iiot-panel-lvds-WF70A8SYJHLNGA.dtso | 97 ++
.../imx8mp-hummingboard-iiot-rs485-a.dtso | 18 +
.../imx8mp-hummingboard-iiot-rs485-b.dtso | 18 +
.../dts/freescale/imx8mp-hummingboard-iiot.dts | 716 ++++++++++++
.../imx8mp-hummingboard-pulse-common.dtsi | 2 +-
.../imx8mp-hummingboard-pulse-mini-hdmi.dtsi | 11 +-
.../boot/dts/freescale/imx8mp-kontron-dl.dtso | 26 +-
.../boot/dts/freescale/imx8mp-kontron-osm-s.dtsi | 6 +
.../imx8mp-kontron-smarc-eval-carrier.dts | 1 -
arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h | 2 +-
.../freescale/imx8mp-tqma8mpql-mba8mp-ras314.dts | 72 +-
.../imx8mp-tqma8mpql-mba8mpxl-lvds-g133han01.dtso | 6 +-
...imx8mp-tqma8mpql-mba8mpxl-lvds-tm070jvhg33.dtso | 6 +-
.../dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts | 67 ++
...x8p-ml81-moduline-display-106-av101hdt-a10.dtso | 1 +
.../imx8mp-tx8p-ml81-moduline-display-106.dts | 16 +-
.../arm64/boot/dts/freescale/imx8mp-tx8p-ml81.dtsi | 8 +-
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 11 +-
.../imx8mq-tqma8mq-mba8mx-lvds-tm070jvhg33.dtso | 6 +-
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 10 +-
arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi | 5 +-
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 10 +-
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 3 +-
arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts | 98 ++
.../boot/dts/freescale/imx91-11x11-frdm-s.dts | 769 +++++++++++++
.../boot/dts/freescale/imx91-var-dart-sonata.dts | 471 ++++++++
arch/arm64/boot/dts/freescale/imx91-var-dart.dtsi | 468 ++++++++
arch/arm64/boot/dts/freescale/imx91.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx91_93_common.dtsi | 64 +-
.../boot/dts/freescale/imx93-11x11-evk-common.dtsi | 861 +++++++++++++++
arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts | 855 +-------------
.../dts/freescale/imx93-11x11-frdm-pixpaper.dtso | 50 +
arch/arm64/boot/dts/freescale/imx93-14x14-evk.dts | 12 +
.../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 110 ++
arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts | 6 +
.../boot/dts/freescale/imx93-phyboard-nash.dts | 12 +-
.../freescale/imx93-phyboard-segin-peb-av-02.dtso | 146 +++
.../boot/dts/freescale/imx93-phyboard-segin.dts | 12 +-
.../boot/dts/freescale/imx93-phycore-som.dtsi | 12 +-
.../imx93-tqma9352-mba91xxca-lvds-tm070jvhg33.dtso | 56 +
.../imx93-tqma9352-mba91xxca-rgb-cdtech-dc44.dtso | 66 ++
.../dts/freescale/imx93-tqma9352-mba91xxca.dts | 4 +-
.../dts/freescale/imx93-tqma9352-mba93xxca.dts | 4 +-
.../imx93-tqma9352-mba93xxla-mini-ezurio-wlan.dtso | 35 +
.../freescale/imx93-tqma9352-mba93xxla-mini.dts | 598 ++++++++++
.../dts/freescale/imx93-tqma9352-mba93xxla.dts | 4 +-
arch/arm64/boot/dts/freescale/imx93.dtsi | 36 +
arch/arm64/boot/dts/freescale/imx93w-evk.dts | 28 +
arch/arm64/boot/dts/freescale/imx93w.dtsi | 110 ++
arch/arm64/boot/dts/freescale/imx94-pinfunc.h | 12 +
arch/arm64/boot/dts/freescale/imx94.dtsi | 127 ++-
arch/arm64/boot/dts/freescale/imx943-evk.dts | 292 +++++
arch/arm64/boot/dts/freescale/imx943.dtsi | 64 ++
arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts | 1 -
arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts | 73 ++
.../boot/dts/freescale/imx95-19x19-evk-sof.dts | 7 +-
arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts | 2 +-
.../boot/dts/freescale/imx95-toradex-smarc.dtsi | 49 +-
.../boot/dts/freescale/imx95-var-dart-sonata.dts | 595 ++++++++++
arch/arm64/boot/dts/freescale/imx95-var-dart.dtsi | 425 +++++++
.../boot/dts/freescale/imx95-verdin-dahlia.dtsi | 270 +++++
.../arm64/boot/dts/freescale/imx95-verdin-dev.dtsi | 250 +++++
.../arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi | 515 +++++++++
.../boot/dts/freescale/imx95-verdin-mallow.dtsi | 223 ++++
.../dts/freescale/imx95-verdin-nonwifi-dahlia.dts | 21 +
.../dts/freescale/imx95-verdin-nonwifi-dev.dts | 21 +
.../dts/freescale/imx95-verdin-nonwifi-ivy.dts | 21 +
.../dts/freescale/imx95-verdin-nonwifi-mallow.dts | 21 +
.../dts/freescale/imx95-verdin-nonwifi-yavia.dts | 21 +
.../boot/dts/freescale/imx95-verdin-nonwifi.dtsi | 16 +
.../dts/freescale/imx95-verdin-wifi-dahlia.dts | 21 +
.../boot/dts/freescale/imx95-verdin-wifi-dev.dts | 21 +
.../boot/dts/freescale/imx95-verdin-wifi-ivy.dts | 21 +
.../dts/freescale/imx95-verdin-wifi-mallow.dts | 21 +
.../boot/dts/freescale/imx95-verdin-wifi-yavia.dts | 21 +
.../boot/dts/freescale/imx95-verdin-wifi.dtsi | 50 +
.../boot/dts/freescale/imx95-verdin-yavia.dtsi | 217 ++++
arch/arm64/boot/dts/freescale/imx95-verdin.dtsi | 1162 ++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx95.dtsi | 109 +-
arch/arm64/boot/dts/freescale/imx952-evk.dts | 273 +++++
arch/arm64/boot/dts/freescale/imx952.dtsi | 232 +++-
arch/arm64/boot/dts/freescale/mba8mx.dtsi | 4 +-
arch/arm64/boot/dts/freescale/s32n79-rdb.dts | 70 ++
arch/arm64/boot/dts/freescale/s32n79.dtsi | 362 ++++++
124 files changed, 16770 insertions(+), 1337 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-hummingboard-ripple.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-sr-som.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx-lvds-g133han01.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-iv-306-d.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-mini-111.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony-legacy.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-som-wifi-brcm-legacy.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-som-wifi-bt-iw61x.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-solidsense-n8-compact.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot-panel-dsi-WJ70N3TYJHMNG0.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot-panel-lvds-WF70A8SYJHLNGA.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot-rs485-a.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot-rs485-b.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx91-11x11-frdm-s.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx91-var-dart.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx93-11x11-evk-common.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx93-11x11-frdm-pixpaper.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-02.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-tqma9352-mba91xxca-lvds-tm070jvhg33.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-tqma9352-mba91xxca-rgb-cdtech-dc44.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-tqma9352-mba93xxla-mini-ezurio-wlan.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-tqma9352-mba93xxla-mini.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx93w-evk.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx93w.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-var-dart.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-dahlia.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-dev.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-mallow.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-dahlia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-dev.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-ivy.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-mallow.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-yavia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi-dahlia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi-dev.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi-ivy.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi-mallow.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi-yavia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-yavia.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/s32n79-rdb.dts
create mode 100644 arch/arm64/boot/dts/freescale/s32n79.dtsi
^ permalink raw reply
* [GIT PULL 2/4] i.MX arm dts changes for v7.1
From: Frank Li @ 2026-03-30 14:14 UTC (permalink / raw)
To: soc, arm
Cc: Frank.Li, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260330141444.3789193-1-Frank.Li@nxp.com>
From: Frank.Li@nxp.com
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-dt-7.1
for you to fetch changes up to 7bc76d413dbe6631a207b38aa67b2d00fdc27b2c:
ARM: dts: imx: Add DT overlays for DH i.MX6 DHCOM SoM and boards (2026-03-25 13:00:22 -0400)
----------------------------------------------------------------
i.MX ARM device tree changes for 7.1:
- Device Tree Schema Compliance Fixes
Fixed numerous CHECK_DTBS warnings across multiple i.MX SoC families
Renamed nodes to match schema requirements (tcq→touchscreen,
uart8250→serial, iomuxc→pinmux, etc.). Fixed node naming conventions
(added "led-" prefix, proper addressing formats).
Corrected compatible strings and removed undocumented fallbacks. Added
required properties (clocks, clock-names, power supplies,
#sound-dai-cells).
- New Hardware Support
Added DT overlays for various expansion modules (i.MX6 DHCOM PDK2,
PicoITX display boards). Added support for muRata 1YN WiFi chip
(replacement for 1DX) on i.MX6ULL DHCOR board.
i.MX7ULP: Added CPU clock and OPP table support for frequency scaling.
- Boot Phase Properties
Added bootph.yaml properties to multiple TQ-Systems boards and SoCs:
imx7s, tqma7, mba7 imx6ul/ull, tqma6ul/ull, mba6ulx imx6qdl, tqma6, mba6.
- Bug Fixes & Corrections
Fixed interrupt property usage (interrupts→interrupts-extended where
needed). Corrected spelling ("TQ-Systems" with hyphen). Removed redundant
intermediate nodes in pinmux hierarchy. Fixed clock references and
naming.
----------------------------------------------------------------
Alexander Feilke (3):
ARM: dts: imx7s: add boot phase properties
ARM: dts: tqma7: add boot phase properties
ARM: dts: imx7-mba7: Deassert BOOT_EN after boot
Dario Binacchi (1):
ARM: dts: imx6ull-engicam-microgea-bmm: set touchscreen glitch threshold
Frank Li (24):
ARM: dts: imx35: rename emi to emi-bus to fix CHECK_DTBS warning
ARM: dts: imx35: rename i2c clock-names to ipg
ARM: dts: imx35: remove simple-bus 'usbphy'
ARM: dts: imx51-ts4800: rename fpga@0 to fpga@0,0
ARM: dts: imx51-babbage: rename at45db321d@1 to flash@1
ARM: dts: imx53: drop fallback compatible "dlg,da9052"
ARM: dts: imx6qdl-sr-som-ti: use fixed-clock instead of clock-frequency
ARM: dts: imx53-smd: Add power supply node for fsl,sgtl5000
ARM: dts: imx7s-warp: Remove data-lanes and clock-lanes for ov2680
ARM: dts: imx: rename iomuxc to pinmux
ARM: dts: imx: remove redundant intermediate node in pinmux hierarchy
ARM: dts: imx27-eukrea: replace interrupts with interrupts-extended
ARM: dts: imx27-eukrea-cpuimx27: rename uart8250 to serial
ARM: dts: imx27: remove fsl,imx-osc26m from fixed-clock node
ARM: dts: imx23: fix interrupt names for dma-controller@80024000
ARM: dts: imx23/28: add "led-" prefix to LED subnodes
ARM: dts: imx28: rename gpios-reset to reset-gpios of hx8357
ARM: dts: imx28-sps1: remove undocumented fallback compatible "mr25h256"
ARM: dts: imx28-tx28: rename compatible to "edt,edt-ft5206"
ARM: dts: imx28-tx28: remove undocumented aliases
ARM: dts: imx6qdl: add label for system clocks
ARM: dts: imx: add required clocks and clock-names for ccm
ARM: dts: imx25: rename node name tcq to touchscreen
ARM: dts: imx6sx: remove fallback compatible string fsl,imx28-lcdif
Ian Ray (5):
ARM: dts: imx: bx50v3: Configure switch PHY max-speed to 100Mbps
ARM: dts: imx: bx50v3: Configure phy-mode to eliminate a warning
ARM: dts: imx: b850v3: Use alphabetical sorting
ARM: dts: imx: b850v3: Define GPIO line names
ARM: dts: imx: b850v3: Disable unused usdhc4
Marek Vasut (2):
ARM: dts: imx6ull-dhcor: Handle both 1DX and 1YN WiFi on i.MX6ULL DHCOR
ARM: dts: imx: Add DT overlays for DH i.MX6 DHCOM SoM and boards
Max Merchel (8):
ARM: dts: imx6qdl-tqma6: add missing labels
ARM: dts: imx6qdl: add boot phase properties
ARM: dts: imx6qdl-tqma6: add boot phase properties
ARM: dts: imx6qdl-mba6: add boot phase properties
ARM: dts: imx6ul/imx6ull: add boot phase properties
ARM: dts: imx6ul[l]-tqma6ul[l]: add boot phase properties
ARM: dts: mba6ulx: add boot phase properties
ARM: dts: tqma6ul[l]: correct spelling of TQ-Systems
Peng Fan (1):
ARM: dts: imx7ulp: Add CPU clock and OPP table support
arch/arm/boot/dts/nxp/imx/Makefile | 37 ++++
arch/arm/boot/dts/nxp/imx/imx1-ads.dts | 108 +++++----
arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts | 92 ++++----
arch/arm/boot/dts/nxp/imx/imx1.dtsi | 2 +-
.../boot/dts/nxp/imx/imx25-eukrea-cpuimx25.dtsi | 38 ++--
.../imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts | 6 +-
.../nxp/imx/imx25-eukrea-mbimxsd25-baseboard.dts | 134 ++++++-----
arch/arm/boot/dts/nxp/imx/imx25-pdk.dts | 190 ++++++++--------
arch/arm/boot/dts/nxp/imx/imx25.dtsi | 4 +-
arch/arm/boot/dts/nxp/imx/imx27-apf27.dts | 58 +++--
arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts | 194 ++++++++--------
.../boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi | 244 ++++++++++-----------
.../nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts | 196 ++++++++---------
arch/arm/boot/dts/nxp/imx/imx27-pdk.dts | 132 ++++++-----
.../dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts | 92 ++++----
.../dts/nxp/imx/imx27-phytec-phycard-s-som.dtsi | 174 ++++++++-------
.../boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts | 206 +++++++++--------
.../boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi | 154 +++++++------
arch/arm/boot/dts/nxp/imx/imx27.dtsi | 4 +-
arch/arm/boot/dts/nxp/imx/imx31.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx35.dtsi | 30 +--
arch/arm/boot/dts/nxp/imx/imx51-babbage.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx51-ts4800.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx53-qsb.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 18 ++
.../arm/boot/dts/nxp/imx/imx53-voipac-dmm-668.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6dl-alti6p.dts | 4 +-
.../boot/dts/nxp/imx/imx6dl-eckelmann-ci4x10.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-lanmcu.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-plybas.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-plym2m.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-prtmvt.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-qmx6.dtsi | 5 +-
arch/arm/boot/dts/nxp/imx/imx6dl-victgo.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6q-b450v3.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-b650v3.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-b850v3.dts | 53 +++--
arch/arm/boot/dts/nxp/imx/imx6q-bx50v3.dtsi | 4 +
arch/arm/boot/dts/nxp/imx/imx6q-prtwd2.dts | 4 +-
...mx6qdl-dhcom-overlay-panel-dpi-ch101olhlwh.dtsi | 75 +++++++
.../nxp/imx/imx6qdl-dhcom-overlay-panel-dpi.dtsi | 61 ++++++
.../imx6qdl-dhcom-pdk2-overlay-497-200-x12.dtso | 28 +++
...dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso | 26 +++
.../imx6qdl-dhcom-pdk2-overlay-531-100-x21.dtso | 32 +++
.../imx6qdl-dhcom-pdk2-overlay-531-100-x22.dtso | 32 +++
.../imx6qdl-dhcom-pdk2-overlay-560-200-x12.dtso | 39 ++++
...com-picoitx-overlay-626-100-x2-ch101olhlwh.dtso | 8 +
arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-som.dtsi | 6 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-mba6.dtsi | 12 +
arch/arm/boot/dts/nxp/imx/imx6qdl-skov-cpu.dtsi | 4 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-sr-som-ti.dtsi | 8 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-tqma6.dtsi | 11 +
arch/arm/boot/dts/nxp/imx/imx6qdl-tqma6a.dtsi | 5 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-tqma6b.dtsi | 6 +-
arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi | 24 +-
arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 4 +-
.../boot/dts/nxp/imx/imx6ul-tqma6ul-common.dtsi | 10 +
arch/arm/boot/dts/nxp/imx/imx6ul-tqma6ul2.dtsi | 1 +
.../boot/dts/nxp/imx/imx6ul-tqma6ul2l-mba6ulx.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tqma6ul2l.dtsi | 1 +
.../boot/dts/nxp/imx/imx6ul-tqma6ulx-common.dtsi | 1 +
.../boot/dts/nxp/imx/imx6ul-tqma6ulxl-common.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx6ul.dtsi | 7 +
arch/arm/boot/dts/nxp/imx/imx6ull-dhcor-som.dtsi | 4 +-
.../dts/nxp/imx/imx6ull-engicam-microgea-bmm.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6ull-tqma6ull2.dtsi | 1 +
.../dts/nxp/imx/imx6ull-tqma6ull2l-mba6ulx.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ull-tqma6ull2l.dtsi | 3 +-
arch/arm/boot/dts/nxp/imx/imx6ull.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 13 ++
arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx7s-warp.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx7s.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi | 28 +++
arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi | 6 +
arch/arm/boot/dts/nxp/mxs/imx23-olinuxino.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx23.dtsi | 6 +-
arch/arm/boot/dts/nxp/mxs/imx28-apf28dev.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-apx4devkit.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-cfa10036.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-cfa10049.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-cfa10055.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-cfa10056.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-duckbill-2-485.dts | 4 +-
.../boot/dts/nxp/mxs/imx28-duckbill-2-enocean.dts | 6 +-
arch/arm/boot/dts/nxp/mxs/imx28-duckbill-2.dts | 4 +-
arch/arm/boot/dts/nxp/mxs/imx28-duckbill.dts | 4 +-
arch/arm/boot/dts/nxp/mxs/imx28-evk.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts | 4 +-
arch/arm/boot/dts/nxp/mxs/imx28-sps1.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts | 9 +-
91 files changed, 1609 insertions(+), 1142 deletions(-)
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-overlay-panel-dpi-ch101olhlwh.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-overlay-panel-dpi.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-497-200-x12.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-531-100-x21.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-531-100-x22.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-560-200-x12.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtso
^ permalink raw reply
* [GIT PULL 3/4] i.MX dt binding changes for v7.1
From: Frank Li @ 2026-03-30 14:14 UTC (permalink / raw)
To: soc, arm
Cc: Frank.Li, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
From: Frank.Li@nxp.com
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-bindings-7.1
for you to fetch changes up to e54390aae6887151ff67526af45382beb889f99a:
dt-bindings: arm: fsl: add Verdin iMX95 (2026-03-26 12:17:45 -0400)
----------------------------------------------------------------
i.MX dt-bindings update for 7.1:
- New board support: Verdin iMX95, MBa93xxLA-MINI, TQMa95xxLA, S32N79
SoC/RDB, i.MX8MP audio board (version 2), SolidRun i.MX8M, TQMa8x,
GOcontroll Moduline IV/Mini, FRDM-IMX91S, Variscite DART-MX91,
i.MX93 Wireless EVK, Variscite DART-MX95.
- fsl,irqsteer add nxp,s32n79-irqsteer support.
- fsl,imx93-media-blk-ctrl add dbi-bridge.
----------------------------------------------------------------
Alexander Stein (1):
dt-bindings: arm: fsl: add bindings for TQMa8x
Ciprian Marian Costea (2):
dt-bindings: interrupt-controller: fsl,irqsteer: add S32N79 support
dt-bindings: arm: fsl: Add NXP S32N79 SoC and RDB board
Ernest Van Hoecke (1):
dt-bindings: arm: fsl: add Verdin iMX95
Frank Li (1):
dt-bindings: arm: lpc: add missed lpc43xx board
Josua Mayer (1):
dt-bindings: arm: fsl: Add various solidrun i.MX8M boards
Liu Ying (1):
dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC subnode to schema and example
Markus Niebel (1):
dt-bindings: arm: add bindings for TQMa95xxLA
Martin Schmiedel (1):
dt-bindings: arm: fsl: add MBa93xxLA-MINI
Maud Spierings (1):
dt-bindings: arm: fsl: Add GOcontroll Moduline IV/Mini
Peng Fan (1):
dt-bindings: fsl: imx7ulp-smc1: Add #clock-cells property
Shengjiu Wang (1):
dt-bindings: arm: fsl: Add compatible for i.MX8MP audio board (version 2)
Sherry Sun (1):
dt-bindings: arm: fsl: Add i.MX93 Wireless EVK board
Stefano Radaelli (2):
dt-bindings: arm: fsl: add Variscite DART-MX95 Boards
dt-bindings: arm: fsl: add Variscite DART-MX91 Boards
Yanan Yang (1):
dt-bindings: arm: fsl: Add FRDM-IMX91S board
.../bindings/arm/freescale/fsl,imx7ulp-pm.yaml | 5 ++
Documentation/devicetree/bindings/arm/fsl.yaml | 86 ++++++++++++++++++++++
.../devicetree/bindings/arm/nxp/lpc32xx.yaml | 22 ++++++
.../interrupt-controller/fsl,irqsteer.yaml | 4 +-
.../bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml | 78 ++++++++++++++++++++
5 files changed, 194 insertions(+), 1 deletion(-)
^ permalink raw reply
* [GIT PULL 4/4] i.MX drivers/soc changes for v7.1
From: Frank Li @ 2026-03-30 14:14 UTC (permalink / raw)
To: soc, arm
Cc: Frank.Li, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260330141444.3789193-1-Frank.Li@nxp.com>
From: Frank.Li@nxp.com
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-soc-7.1
for you to fetch changes up to 1b7c834dedf9933447c424bfa01348f9dc3db4d1:
MAINTAINERS: Add i.MX team to all arm NXP platforms (2026-03-13 11:00:45 -0400)
----------------------------------------------------------------
i.MX SoC update for 7.1:
- Updates MAINTAINERS file to include i.MX team coverage for ARM NXP platforms
- Sets default values for OPACR (Off-Platform Peripheral Access Control
Register) in the i.MX AIPSTZ bus driver
----------------------------------------------------------------
Alexander Stein (1):
MAINTAINERS: Add i.MX team to all arm NXP platforms
Shengjiu Wang (1):
bus: imx-aipstz: set default value for opacr registers
MAINTAINERS | 3 +--
drivers/bus/imx-aipstz.c | 15 +++++++++++++++
2 files changed, 16 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH] usb: phy: mxs: manually reset phy regs after a warm reset
From: Greg KH @ 2026-03-30 14:19 UTC (permalink / raw)
To: Xu Yang
Cc: Frank.Li, s.hauer, kernel, festevam, linux-usb, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260330093133.973785-1-xu.yang_2@nxp.com>
On Mon, Mar 30, 2026 at 05:31:33PM +0800, Xu Yang wrote:
> The usb phy registers are not fully reset on warm reset under stress
> conditions. We need to manually reset those (CTRL, PWD, DEBUG, PLL_SIC)
> regs after a warm reset. This will reset DEBUG and PLL_SIC registers.
> CTRL and PWD register are handled by "SFT" bit in stmp_reset_block().
>
> ERR051269: USB PHY registers not fully resetting on warm reset under
> stress conditions
>
> The following USB PHY registers must be written by SW to restore the reset
> value after a warm reset:
>
> Reg: ctrl Addr: 0x29910030 Data: 0xc000_0000
> Reg: pwd Addr: 0x29910000 Data: 0x001e_1c00
> Reg: debug0 Addr: 0x29910050 Data: 0x7f18_0000
> Reg: pll_sic Addr: 0x299100a0 Data: 0x00d1_2000
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> ---
> drivers/usb/phy/phy-mxs-usb.c | 32 +++++++++++++++++++++++++++++---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index 7069dd3f4d0d..dd42db8a0829 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -209,6 +209,9 @@ static const struct mxs_phy_data imx6ul_phy_data = {
> static const struct mxs_phy_data imx7ulp_phy_data = {
> };
>
> +static const struct mxs_phy_data imx8ulp_phy_data = {
> +};
> +
> static const struct of_device_id mxs_phy_dt_ids[] = {
> { .compatible = "fsl,imx6sx-usbphy", .data = &imx6sx_phy_data, },
> { .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
> @@ -217,6 +220,7 @@ static const struct of_device_id mxs_phy_dt_ids[] = {
> { .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
> { .compatible = "fsl,imx6ul-usbphy", .data = &imx6ul_phy_data, },
> { .compatible = "fsl,imx7ulp-usbphy", .data = &imx7ulp_phy_data, },
> + { .compatible = "fsl,imx8ulp-usbphy", .data = &imx8ulp_phy_data, },
Why can't you use &imx7ulp_phy_data here as it's all just empty?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier
From: Bartosz Golaszewski @ 2026-03-30 14:19 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann, driver-core,
linux-kernel, linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <DHG5WQI26R5U.WTZW61VKJHF5@kernel.org>
On Mon, Mar 30, 2026 at 3:47 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> > diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> > index c8219505a79f98bc370e52997efc8af51833cfda..71b9086621c35b7e4ef99b9d3b6707db23faf58c 100644
> > --- a/include/linux/kobject.h
> > +++ b/include/linux/kobject.h
> > @@ -219,4 +219,6 @@ int kobject_synth_uevent(struct kobject *kobj, const char *buf, size_t count);
> > __printf(2, 3)
> > int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
> >
> > +void ksysfs_init(void);
>
> NIT: I'm aware there's also all the core kobjects in include/linux/kobject.h,
> but maybe a separate header would be a better fit.
Do you mean moving all the top-level kobject declarations
(kernel_kobj, firmware_kobj, etc.) out of kobject.h into this new
header (ksysfs.h?) along with their init functions?
Bart
^ permalink raw reply
* Re: [PATCH 1/4] media: rkvdec: Introduce a global bitwriter helper
From: Nicolas Dufresne @ 2026-03-30 14:17 UTC (permalink / raw)
To: Detlev Casanova, Ezequiel Garcia, Mauro Carvalho Chehab,
Heiko Stuebner, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Jonas Karlman
Cc: linux-kernel, linux-media, linux-rockchip, linux-arm-kernel, llvm,
kernel
In-Reply-To: <20260327-rkvdec-use-bitwriter-v1-1-982cf872b590@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]
Le vendredi 27 mars 2026 à 11:16 -0400, Detlev Casanova a écrit :
> The use of structures with bitfields is good when the values are
> somewhat aligned.
> More mis-alignement means that compilers need to do more gymanstics
> to edit the fields values.
>
> Some cases have been reported with CLang on specific architectures
> like armhf and hexagon, where the compiler would allocate a bigger
> local stack than needed or even completely freeze during compilation.
>
> Some fixes have been provided to ease the issues, but the real fix
> here is to use a bitwriter instead of heavily unaligned bitfields.
>
> This is a preparation commit to provide a global bitwriter interface
> for the whole driver.
>
> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
> ---
> drivers/media/platform/rockchip/rkvdec/Makefile | 1 +
> .../platform/rockchip/rkvdec/rkvdec-bitwriter.c | 30 ++++++++++++++++++++++
> .../platform/rockchip/rkvdec/rkvdec-bitwriter.h | 25 ++++++++++++++++++
> 3 files changed, 56 insertions(+)
>
> diff --git a/drivers/media/platform/rockchip/rkvdec/Makefile b/drivers/media/platform/rockchip/rkvdec/Makefile
> index e629d571e4d8..11e2122bcbbf 100644
> --- a/drivers/media/platform/rockchip/rkvdec/Makefile
> +++ b/drivers/media/platform/rockchip/rkvdec/Makefile
> @@ -2,6 +2,7 @@ obj-$(CONFIG_VIDEO_ROCKCHIP_VDEC) += rockchip-vdec.o
>
> rockchip-vdec-y += \
> rkvdec.o \
> + rkvdec-bitwriter.o \
Its just one function, with 10 lines of code, can we inline it in the header and
drop the object ?
> rkvdec-cabac.o \
> rkvdec-h264.o \
> rkvdec-h264-common.o \
> diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.c b/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.c
> new file mode 100644
> index 000000000000..673ebb89002b
> --- /dev/null
> +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.c
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip Video Decoder bit writer
> + *
> + * Copyright (C) 2026 Collabora, Ltd.
> + * Detlev Casanova <detlev.casanova@collabora.com>
> + * Copyright (C) 2019 Collabora, Ltd.
> + * Boris Brezillon <boris.brezillon@collabora.com>
> + */
> +
> +#include <linux/types.h>
> +#include <linux/bits.h>
> +
> +#include "rkvdec-bitwriter.h"
> +
> +void rkvdec_set_bw_field(u32 *buf, struct rkvdec_bw_field field, u32 value)
> +{
> + u8 bit = field.offset % 32;
> + u16 word = field.offset / 32;
> + u64 mask = GENMASK_ULL(bit + field.len - 1, bit);
> + u64 val = ((u64)value << bit) & mask;
> +
> + buf[word] &= ~mask;
> + buf[word] |= val;
> + if (bit + field.len > 32) {
> + buf[word + 1] &= ~(mask >> 32);
> + buf[word + 1] |= val >> 32;
> + }
> +}
> +
> diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.h b/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.h
> new file mode 100644
> index 000000000000..44154f1ebc65
> --- /dev/null
> +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Rockchip Video Decoder bit writer
> + *
> + * Copyright (C) 2026 Collabora, Ltd.
> + * Detlev Casanova <detlev.casanova@collabora.com>
> + * Copyright (C) 2019 Collabora, Ltd.
> + * Boris Brezillon <boris.brezillon@collabora.com>
> + */
> +
> +#ifndef RKVDEC_BIT_WRITER_H_
> +#define RKVDEC_BIT_WRITER_H_
> +
> +#include <linux/types.h>
> +
> +struct rkvdec_bw_field {
> + u16 offset;
> + u8 len;
> +};
> +
> +#define BW_FIELD(_offset, _len) ((struct rkvdec_bw_field){ _offset, _len })
> +
> +void rkvdec_set_bw_field(u32 *buf, struct rkvdec_bw_field field, u32 value);
> +
> +#endif /* RKVDEC_BIT_WRITER_H_ */
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-30 14:08 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann, driver-core,
linux-kernel, linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <CAMRc=MfG1ZF=4T2WAw71Zb+4BFD2_4VSNRQZQsoGLE8gZxWcHg@mail.gmail.com>
On Mon, Mar 30, 2026 at 3:52 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Mon, Mar 30, 2026 at 3:37 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> > > Bartosz Golaszewski (3):
> > > kernel: ksysfs: initialize kernel_kobj earlier
> > > driver core: make software nodes available earlier
> > > ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
> >
> > Looks good to me overall (one minor nit in the first patch); which tree should
> > this go through?
>
> If the first two patches can make v7.1 then I'm fine with postponing
> patch 3 until v7.2. Maybe Dmitry's changes allowing passing
> unregistered software nodes to new platform devices (where are we with
> this?) would also make it in and patch 3/3 could be smaller as a
> result.
>
In other words: patches 1 and 2 can go though the driver core tree
into v7.1 and patch 3/3 will be respun next cycle.
Bart
^ permalink raw reply
* Re: [PATCH v2 3/4] elf: align ET_DYN base to max folio size for PTE coalescing
From: Usama Arif @ 2026-03-30 14:00 UTC (permalink / raw)
To: Matthew Wilcox, WANG Rui
Cc: Liam.Howlett, ajd, akpm, apopple, baohua, baolin.wang, brauner,
catalin.marinas, david, dev.jain, jack, kees, kevin.brodsky,
lance.yang, linux-arm-kernel, linux-fsdevel, linux-kernel,
linux-mm, lorenzo.stoakes, mhocko, npache, pasha.tatashin,
rmclure, rppt, ryan.roberts, surenb, vbabka, viro
In-Reply-To: <acpy6DLjPVXXzwJX@casper.infradead.org>
On 30/03/2026 15:56, Matthew Wilcox wrote:
> On Sun, Mar 29, 2026 at 12:37:00PM +0800, WANG Rui wrote:
>>> mapping_max_folio_size() reflects what the page cache will actually
>>> allocate for a given filesystem, since readahead caps folio allocation
>>> at mapping_max_folio_order() (in page_cache_ra_order()). If btrfs
>>> reports PAGE_SIZE, readahead won't allocate large folios for it, so
>>> there are no large folios to coalesce PTEs for, aligning the binary
>>> beyond that would only reduce ASLR entropy for no benefit.
>>>
>>> I don't think we should over-align binaries on filesystems that can't
>>> take advantage of it.
>>
>> Ah, it looks like this might be overlooking another path that can create
>> huge page mappings for read-only code segments: even when the filesystem
>> (e.g. btrfs without experimental) didn't support large folios,
>> READ_ONLY_THP_FOR_FS still allowed read-only file-backed code segments
>> to be collapsed into huge page mappings via khugepaged.
ah yes, Thank you for pointing this out!
Maybe we should rename mapping_max_folio_size() to mapping_fault_max_folio_size().
>>
>> As Wilcox pointed out, it may take quite some time for many filesystems
>> to gain full large folio support? So what I'm trying to clarify is that
>> using mapping_max_folio_size() on this path is not favorable for
>> khugepaged-based optimizations.
ack
I am worried that 32M is too large and we lose out on a lot of ASLR bits.
Instead of PMD_ORDER, should we do max(SZ_2M, PMD_ORDER)?
> Nono, that's not what I'm pointing out! btrfs is simply not putting
> in the effort to support large folios, and that needs to change.
> READ_ONLY_THP_FOR_FS unnecessaily burdens the rest of the kernel.
> It was a great hack for its time and paved the path for a lot of what
> we have today, but it's time to remove it.
^ permalink raw reply
* Re: [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-30 13:52 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann, driver-core,
linux-kernel, linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <DHG5OX85I4LL.39U0RRBS0JXFP@kernel.org>
On Mon, Mar 30, 2026 at 3:37 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> > Bartosz Golaszewski (3):
> > kernel: ksysfs: initialize kernel_kobj earlier
> > driver core: make software nodes available earlier
> > ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
>
> Looks good to me overall (one minor nit in the first patch); which tree should
> this go through?
If the first two patches can make v7.1 then I'm fine with postponing
patch 3 until v7.2. Maybe Dmitry's changes allowing passing
unregistered software nodes to new platform devices (where are we with
this?) would also make it in and patch 3/3 could be smaller as a
result.
Bart
^ permalink raw reply
* Re: [PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier
From: Danilo Krummrich @ 2026-03-30 13:47 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Aaro Koskinen,
Janusz Krzysztofik, Tony Lindgren, Russell King, Dmitry Torokhov,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <20260330-nokia770-gpio-swnodes-v4-1-b68592e977d0@oss.qualcomm.com>
On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index c8219505a79f98bc370e52997efc8af51833cfda..71b9086621c35b7e4ef99b9d3b6707db23faf58c 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -219,4 +219,6 @@ int kobject_synth_uevent(struct kobject *kobj, const char *buf, size_t count);
> __printf(2, 3)
> int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
>
> +void ksysfs_init(void);
NIT: I'm aware there's also all the core kobjects in include/linux/kobject.h,
but maybe a separate header would be a better fit.
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 13:38 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFomzokuF+UL8d0+Syk1FCG3jnUfy7rVr+3iC1GPZmH1UQ@mail.gmail.com>
On 30/03/2026 15:30, Ulf Hansson wrote:
>
> Usually we want bindings to go along with their respective drivers on
> a subsystem basis.
>
> Both patch2 and patch4 updates DT bindings for the power-domain providers.
Patch 2 yes. Patch 4 not. That's why I did not take patch 2.
>
> Why shouldn't the bindings go along with the driver changes here?
Patch #2 is pmdomain, so with pmdomain drivers thus your tree. Patch #4
is not pmdomain, so not with pmdomain drivers, so not your tree... At
least I do not see any pmdomain parts in that patch #4. It's a Samsung
SoC PMU driver and none of further driver patches touch that PMU driver.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Danilo Krummrich @ 2026-03-30 13:37 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Aaro Koskinen,
Janusz Krzysztofik, Tony Lindgren, Russell King, Dmitry Torokhov,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <20260330-nokia770-gpio-swnodes-v4-0-b68592e977d0@oss.qualcomm.com>
On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> Bartosz Golaszewski (3):
> kernel: ksysfs: initialize kernel_kobj earlier
> driver core: make software nodes available earlier
> ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
Looks good to me overall (one minor nit in the first patch); which tree should
this go through?
^ permalink raw reply
* Re: [PATCH] coresight: platform: check the availability of the endpoint before parse
From: Jie Gan @ 2026-03-30 13:31 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
In-Reply-To: <20260320092337.GP8048@e132581.arm.com>
On 3/20/2026 5:23 PM, Leo Yan wrote:
> Hi Jie,
>
> On Fri, Mar 20, 2026 at 04:44:54PM +0800, Jie Gan wrote:
>
> [...]
>
>> It's about the coresight_find_device_by_fwnode() returns NULL, resulting in
>> -EPROBE_DEFER. So the probe process will re-start after several seconds, but
>> always failed because we have a "disabled" device node in DT(we can see this
>> device in DT, but it never becomes available). It's ok if the device only
>> has one remote device, but has issue with more than one remote devices.
>>
>> Consider below situation:
>>
>> device0
>> | |
>> device1 device2(status = "disabled")
>>
>> The probe of device0 succeeds only when device1 and device2 are available at
>> probe time. But I think it's ok to probe the device0 only with device1
>> available.
>
> Thanks a lot for details. We might need to report warning or error if
> all remote endpoints fail (e.g., device1/device2 both are disabled),
> this is a rare case so would be low priority.
>
> For this patch:
>
> Reviewed-by: Leo Yan <leo.yan@arm.com>
Gentle ping.
Thanks,
Jie
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 13:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <a417e45b-1632-4b14-9e3c-f7110db53190@kernel.org>
On Mon, 30 Mar 2026 at 13:24, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/03/2026 13:12, Ulf Hansson wrote:
> >
> >>
> >>>
> >>> Although, as I said, if you think it's best to funnel them through
> >>> your tree, please do and then share them via an immutable branch, so I
> >>> can apply the pmdomain driver changes.
> >>
> >> soc must go via my tree, but there is no reason to take the pmdomain
> >> binding patch. So I did not take.
> >
> > Yes, they belong to soc/platform, which is common for most
> > power-domain providers.
>
> What does belong to soc/platform? pmdomain changes? No, they do not...
I think you may have misunderstood me here. I was referring to the DT
bindings that describe power domain providers.
Generally speaking, these are often provided via some
SOC/platform-specific hardware (like a PMU for example).
>
> >
> > To allow us to merge/maintain power-domain provider *driver* changes
> > separately, we needed a way to manage the corresponding DT bindings.
>
> Nothing stops that, there is no dependency. For a week I am saying there
> are no dependencies. If there are, please provide any sort of
> argument/proof, otherwise there is nothing to do here.
>
> > That's why I am hosting the immutable "dt" branch for these, which
> > soc/platform maintainers can pull-in when they need it.
> >
> > Of course, doing it the other way around is also possible. Just let me
> > know what you prefer.
>
> Nothing like that is necessary.
Usually we want bindings to go along with their respective drivers on
a subsystem basis.
Both patch2 and patch4 updates DT bindings for the power-domain providers.
Why shouldn't the bindings go along with the driver changes here?
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Krzysztof Kozlowski @ 2026-03-30 13:22 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt, rafael, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <20260330120105.2985200-6-a-kaur@ti.com>
On 30/03/2026 14:01, Akashdeep Kaur wrote:
> opp_data->cpu_dev = get_cpu_device(0);
> if (!opp_data->cpu_dev) {
> @@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
> if (ret)
> goto fail_put_node;
>
> + /* Create device link to k3-socinfo if specified in DT */
> + if (opp_data->soc_data == &am625_soc_data ||
> + opp_data->soc_data == &am62a7_soc_data ||
> + opp_data->soc_data == &am62l3_soc_data ||
> + opp_data->soc_data == &am62p5_soc_data) {
> + struct device_node *socinfo_np;
> +
> + socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
Undocumented ABI.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC net-next] net: stmmac: qcom-ethqos: set clk_csr
From: Russell King (Oracle) @ 2026-03-30 13:21 UTC (permalink / raw)
To: Andrew Lunn
Cc: Konrad Dybcio, Mohd Ayaan Anwar, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-stm32, netdev, Paolo Abeni
In-Reply-To: <0d650de4-eb45-481b-8c39-1bf455b948c9@lunn.ch>
On Mon, Mar 30, 2026 at 02:35:39PM +0200, Andrew Lunn wrote:
> On Mon, Mar 30, 2026 at 01:20:18PM +0100, Russell King (Oracle) wrote:
> > On Mon, Mar 30, 2026 at 01:18:56PM +0200, Konrad Dybcio wrote:
> > > On 3/27/26 6:02 PM, Russell King (Oracle) wrote:
> > > > The clocks for qcom-ethqos return a rate of zero as firmware manages
> > > > their rate. According to hardware documentation, the clock which is
> > > > fed to the slave AHB interface can crange between 50 and 100MHz.
> > >
> > > FWIW this __may__ possibly differ between platforms, but I'm not sure
> > > to what degree. Will there be visible impact if we e.g. have a 200 or
> > > 300 MHz clock somewhere?
> >
> > When you add other platforms, you're going to have to deal with their
> > differences.
> >
> > IEEE 802.3 states that the maximum clock rate for the MDIO bus is
> > 2.5MHz. You need to ensure that is the case.
> >
> > Current qcom-ethqos code doesn't set clk_csr, and returns zero for
> > clk_get_rate() on the stmmac clocks because they are managed entirely
> > in firmware.
>
> Could a fixed clock be used in DT to represent clk_csr? Different
> platforms then set it to different frequencies, to represent whatever
> the firmware is doing.
Unfortunately, at hardware level, clk_csr isn't a separate clock input
as such. It can be one of many, depending on the synthesis options
chosen by the designer. It may be hclk (AHB clock), aclk (AXI clock)
clk_app (application clock) or a specific clk_csr input.
Nothing is simple with dwmac. :/
The problem with adding a ficticious clock to solve this is that it
adds to implementers confusion for what is already a very complicated
problem.
We've already seen that the stmmac clocks are a total trainwreck
because no one seems to really understnad what is what, and that goes
back to the days when that "apb" clock was added - and that made the
situation worse not better.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
From: Krzysztof Kozlowski @ 2026-03-30 13:21 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt, rafael, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <20260330120105.2985200-4-a-kaur@ti.com>
On 30/03/2026 14:01, Akashdeep Kaur wrote:
> Link CPU OPP table to k3-socinfo driver for dependency tracking.
>
> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> index b6e5eee99370..6d1459e9ea71 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> @@ -109,6 +109,7 @@ a53_opp_table: opp-table {
> compatible = "operating-points-v2-ti-cpu";
> opp-shared;
> syscon = <&opp_efuse_table>;
> + ti,soc-info = <&chipid>;
You should have tested this before sending. It obviously fails checks.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 phy-next 03/28] usb: add missing headers transitively included by <linux/phy/phy.h>
From: Greg Kroah-Hartman @ 2026-03-30 13:19 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, Thinh Nguyen, Peter Chen, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <20260327184706.1600329-4-vladimir.oltean@nxp.com>
On Fri, Mar 27, 2026 at 08:46:41PM +0200, Vladimir Oltean wrote:
> The chipidea ci_hdrc_imx driver uses regulator consumer API like
> regulator_enable() but does not include <linux/regulator/consumer.h>.
>
> The core USB HCD driver calls invalidate_kernel_vmap_range() and
> flush_kernel_vmap_range(), but does not include <linux/highmem.h>.
>
> The DWC3 gadget driver calls:
> - device_property_present()
> - device_property_count_u8()
> - device_property_read_u8_array()
> but does not include <linux/property.h>
>
> The dwc3-generic-plat driver uses of_device_get_match_data() but does
> not include <linux/of.h>.
>
> In all these cases, the necessary includes were still provided somehow,
> directly or indirectly, through <linux/phy/phy.h>. The latter header
> wants to drop those includes, so fill in the required headers to avoid
> any breakage.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> # dwc3
> ---
> Cc: Peter Chen <peter.chen@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Frank Li <Frank.Li@nxp.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
>
> v2->v6: none
> v1->v2: collect tag
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 1 +
> drivers/usb/core/hcd.c | 1 +
> drivers/usb/dwc3/dwc3-generic-plat.c | 1 +
> drivers/usb/dwc3/gadget.c | 1 +
> 4 files changed, 4 insertions(+)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] clk: kirkwood: use kzalloc_flex
From: Brian Masney @ 2026-03-30 13:13 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260326045555.240730-1-rosenp@gmail.com>
On Wed, Mar 25, 2026 at 09:55:55PM -0700, Rosen Penev wrote:
> Simplify allocation by using a flexible array member and kzalloc_flex to
> combine allocations.
>
> Add __counted_by for extra runtime analysis. Move counting variable
> assignment to right after allocation as required by __counted_by.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/clk/mvebu/kirkwood.c | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/mvebu/kirkwood.c b/drivers/clk/mvebu/kirkwood.c
> index ed061d82fb65..fc2972538008 100644
> --- a/drivers/clk/mvebu/kirkwood.c
> +++ b/drivers/clk/mvebu/kirkwood.c
> @@ -253,8 +253,8 @@ struct clk_muxing_soc_desc {
>
> struct clk_muxing_ctrl {
> spinlock_t *lock;
> - struct clk **muxes;
> int num_muxes;
> + struct clk *muxes[] __counted_by(num_muxes);
> };
>
> static const char *powersave_parents[] = {
> @@ -297,21 +297,18 @@ static void __init kirkwood_clk_muxing_setup(struct device_node *np,
> if (WARN_ON(!base))
> return;
>
> - ctrl = kzalloc_obj(*ctrl);
> - if (WARN_ON(!ctrl))
> - goto ctrl_out;
> -
> - /* lock must already be initialized */
> - ctrl->lock = &ctrl_gating_lock;
> -
> /* Count, allocate, and register clock muxes */
> for (n = 0; desc[n].name;)
> n++;
>
> + ctrl = kzalloc_flex(*ctrl, muxes, n);
> + if (WARN_ON(!ctrl))
> + goto ctrl_out;
> +
> ctrl->num_muxes = n;
> - ctrl->muxes = kzalloc_objs(struct clk *, ctrl->num_muxes);
> - if (WARN_ON(!ctrl->muxes))
> - goto muxes_out;
Question from Sashiko:
https://sashiko.dev/#/patchset/20260326045555.240730-1-rosenp%40gmail.com
This isn't a bug, but since the goto muxes_out error path was removed here,
should the muxes_out label and its kfree(ctrl) be removed at the end of the
function?
They appear to be dead code now and might cause an unused label warning:
return;
muxes_out:
kfree(ctrl);
ctrl_out:
iounmap(base);
}
Brian
> +
> + /* lock must already be initialized */
> + ctrl->lock = &ctrl_gating_lock;
>
> for (n = 0; n < ctrl->num_muxes; n++) {
> ctrl->muxes[n] = clk_register_mux(NULL, desc[n].name,
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH] clk: bcm: iproc-asiu: simplify allocation
From: Brian Masney @ 2026-03-30 13:10 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Ray Jui,
Scott Branden, Broadcom internal kernel review list,
moderated list:BROADCOM IPROC ARM ARCHITECTURE, open list
In-Reply-To: <20260326045324.240150-1-rosenp@gmail.com>
On Wed, Mar 25, 2026 at 09:53:24PM -0700, Rosen Penev wrote:
> Use kzalloc_flex and a flexible array member to combine allocations
>
> While at it, take clk_data out of the struct and move it into probe.
> It's not used anywhere else.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH v14 12/12] crypto: qce - Communicate the base physical address to the dmaengine
From: Manivannan Sadhasivam @ 2026-03-30 13:08 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Stephan Gerhold, Bjorn Andersson, Peter Ujfalusi, Michal Simek,
Frank Li, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, brgl, Bartosz Golaszewski
In-Reply-To: <20260323-qcom-qce-cmd-descr-v14-12-f323af411274@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 04:17:18PM +0100, Bartosz Golaszewski wrote:
> In order to communicate to the BAM DMA engine which address should be
> used as a scratchpad for dummy writes related to BAM pipe locking,
> fill out and attach the provided metadata struct to the descriptor as
> well as mark the RX channel as such using the slave config struct.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/crypto/qce/dma.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
> index 5c42fc7ddf01e11a6562d272ba7c90c906e0e312..635208947668667765e6accf9ef02100746c0f9a 100644
> --- a/drivers/crypto/qce/dma.c
> +++ b/drivers/crypto/qce/dma.c
> @@ -11,6 +11,7 @@
>
> #include "core.h"
> #include "dma.h"
> +#include "regs-v5.h"
>
> #define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
> #define QCE_BAM_CMD_SGL_SIZE 128
> @@ -43,6 +44,7 @@ void qce_clear_bam_transaction(struct qce_device *qce)
>
> int qce_submit_cmd_desc(struct qce_device *qce)
> {
> + struct bam_desc_metadata meta = { .scratchpad_addr = qce->base_phys + REG_VERSION };
> struct qce_desc_info *qce_desc = qce->dma.bam_txn->desc;
> struct qce_bam_transaction *bam_txn = qce->dma.bam_txn;
> struct dma_async_tx_descriptor *dma_desc;
> @@ -64,6 +66,12 @@ int qce_submit_cmd_desc(struct qce_device *qce)
> return -ENOMEM;
> }
>
> + ret = dmaengine_desc_attach_metadata(dma_desc, &meta, 0);
> + if (ret) {
> + dma_unmap_sg(qce->dev, bam_txn->wr_sgl, bam_txn->wr_sgl_cnt, DMA_TO_DEVICE);
> + return ret;
> + }
> +
> qce_desc->dma_desc = dma_desc;
> cookie = dmaengine_submit(qce_desc->dma_desc);
>
> @@ -107,7 +115,9 @@ void qce_write_dma(struct qce_device *qce, unsigned int offset, u32 val)
> int devm_qce_dma_request(struct qce_device *qce)
> {
> struct qce_dma_data *dma = &qce->dma;
> + struct dma_slave_config cfg = { };
> struct device *dev = qce->dev;
> + int ret;
>
> dma->txchan = devm_dma_request_chan(dev, "tx");
> if (IS_ERR(dma->txchan))
> @@ -119,6 +129,11 @@ int devm_qce_dma_request(struct qce_device *qce)
> return dev_err_probe(dev, PTR_ERR(dma->rxchan),
> "Failed to get RX DMA channel\n");
>
> + cfg.direction = DMA_MEM_TO_DEV;
> + ret = dmaengine_slave_config(dma->rxchan, &cfg);
> + if (ret)
> + return ret;
> +
I don't think this part is necessary. You are already passing the metadata above
and that should be sufficient for the BAM DMA driver to get the scratchpad
address. If any client drivers call dmaengine_slave_config() without
dmaengine_desc_attach_metadata(), and if the BAM DMA supports locking, then the
BAM driver should fail. Otherwise, continuing so would cause race conditions
among the BAM clients, which we are seeing right now on Qcom SDX targets with
both NAND driver in Linux and Modem trying to access NAND memory over BAM.
So please drop this and just use dmaengine_desc_attach_metadata().
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] clk: visconti: pll: use kzalloc_flex
From: Brian Masney @ 2026-03-30 13:07 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Nobuhiro Iwamatsu,
Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/TOSHIBA VISCONTI ARCHITECTURE, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260326042317.122536-1-rosenp@gmail.com>
On Wed, Mar 25, 2026 at 09:23:17PM -0700, Rosen Penev wrote:
> Simplify allocation by using a flexible array member and kzalloc_flex.
>
> Add __counted_by for extra runtime analysis. Assign after allocation as
> required by __counted_by.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Note: Sashiko reported a separate issue related to the struct clk_init_data
not fully initialized to zero, and parent_data and parent_hws fields are
left containing stack garbage.
https://sashiko.dev/#/patchset/20260326042317.122536-1-rosenp%40gmail.com
I'll post a fix for this.
Brian
^ permalink raw reply
* Re: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Jason Gunthorpe @ 2026-03-30 12:48 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, bhelgaas, joro, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl
In-Reply-To: <a0dd3e4cc5260f55bbec5b3ed6791def33028735.1772833963.git.nicolinc@nvidia.com>
On Fri, Mar 06, 2026 at 03:41:15PM -0800, Nicolin Chen wrote:
> Controlled by the IOMMU driver, ATS is usually enabled "on demand" when a
> device requests a translation service from its associated IOMMU HW running
> on the channel of a given PASID. This is working even when a device has no
> translation on its RID (i.e., the RID is IOMMU bypassed).
>
> However, certain PCIe devices require non-PASID ATS on their RID even when
> the RID is IOMMU bypassed. Call this "always on".
>
> For instance, the CXL spec notes in "3.2.5.13 Memory Type on CXL.cache":
> "To source requests on CXL.cache, devices need to get the Host Physical
> Address (HPA) from the Host by means of an ATS request on CXL.io."
>
> In other words, the CXL.cache capability requires ATS; otherwise, it can't
> access host physical memory.
>
> Introduce a new pci_ats_always_on() helper for the IOMMU driver to scan a
> PCI device and shift ATS policies between "on demand" and "always on".
>
> Add the support for CXL.cache devices first. Pre-CXL devices will be added
> in quirks.c file.
>
> Note that pci_ats_always_on() validates against pci_ats_supported(), so we
> ensure that untrusted devices (e.g. external ports) will not be always on.
> This maintains the existing ATS security policy regarding potential side-
> channel attacks via ATS.
>
> Cc: linux-cxl@vger.kernel.org
> Suggested-by: Vikram Sethi <vsethi@nvidia.com>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> include/linux/pci-ats.h | 3 +++
> include/uapi/linux/pci_regs.h | 1 +
> drivers/pci/ats.c | 42 +++++++++++++++++++++++++++++++++++
> 3 files changed, 46 insertions(+)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH 4/5] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Christoph Hellwig @ 2026-03-30 13:02 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Christoph Hellwig, Ard Biesheuvel, linux-raid, linux-arm-kernel,
linux-crypto, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <6bedf98e-a424-4baa-890c-806345c067c1@app.fastmail.com>
On Mon, Mar 30, 2026 at 11:38:15AM +0200, Ard Biesheuvel wrote:
> > This avoid the including of .c files which is always a bit ugly.
> > But if there is a strong argument to prefer including of the .c file I
> > can live with that as well.
> >
>
> I've respun it without the include. Instead, I've added this to arm/xor-neon.c
>
> +#ifdef CONFIG_ARM64
> +extern typeof(__xor_neon_2) __xor_eor3_2 __alias(__xor_neon_2);
> +#endif
>
> so that __xor_eor3_2() exists in the arm64 build as an alias. That way, the arm64-only EOR3 implementation can just remain a separate compilation unit.
Ok.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox