* [GIT PULL] i.MX arm64 defconfig change for v7.2
From: Frank.Li @ 2026-06-08 15:36 UTC (permalink / raw)
To: soc, arm; +Cc: Frank.Li, kernel, imx, linux-arm-kernel
From: Frank.Li@nxp.com
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-defconfig-7.2
for you to fetch changes up to 27b93b1a2857586bc422994bf1b9f986841edeb3:
arm64: defconfig: Enable DP83822 PHY driver (2026-06-05 13:25:31 -0400)
----------------------------------------------------------------
i.MX arm64 defconfig for v7.2
- Enable DP83822 PHY driver.
----------------------------------------------------------------
Stefan Wahren (1):
arm64: defconfig: Enable DP83822 PHY driver
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [PATCH v1] ARM: actions: Drop OF node references after mapping
From: Yuho Choi @ 2026-06-08 15:46 UTC (permalink / raw)
To: Andreas Färber, Manivannan Sadhasivam, Russell King
Cc: linux-arm-kernel, linux-actions, linux-kernel, Yuho Choi
of_find_compatible_node() returns a device node with its reference
count incremented. of_iomap() uses the node to map the register range,
but does not consume that reference.
Drop the node references after mapping the timer, SPS and SCU
registers in s500_smp_prepare_cpus().
Fixes: 172067e0bc87 ("ARM: owl: Implement CPU enable-method for S500")
Fixes: b6a0e18ca690 ("ARM: owl: smp: Implement SPS power-gating for CPU2 and CPU3")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
arch/arm/mach-actions/platsmp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-actions/platsmp.c b/arch/arm/mach-actions/platsmp.c
index 7b208e96fbb6..a0d0c1621bd0 100644
--- a/arch/arm/mach-actions/platsmp.c
+++ b/arch/arm/mach-actions/platsmp.c
@@ -105,6 +105,7 @@ static void __init s500_smp_prepare_cpus(unsigned int max_cpus)
}
timer_base_addr = of_iomap(node, 0);
+ of_node_put(node);
if (!timer_base_addr) {
pr_err("%s: could not map timer registers\n", __func__);
return;
@@ -117,6 +118,7 @@ static void __init s500_smp_prepare_cpus(unsigned int max_cpus)
}
sps_base_addr = of_iomap(node, 0);
+ of_node_put(node);
if (!sps_base_addr) {
pr_err("%s: could not map sps registers\n", __func__);
return;
@@ -130,6 +132,7 @@ static void __init s500_smp_prepare_cpus(unsigned int max_cpus)
}
scu_base_addr = of_iomap(node, 0);
+ of_node_put(node);
if (!scu_base_addr) {
pr_err("%s: could not map scu registers\n", __func__);
return;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] KVM: arm64: Replace memslot_is_logging() with kvm_slot_dirty_track_enabled()
From: Leonardo Bras @ 2026-06-08 15:55 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: Leonardo Bras, linux-arm-kernel, kvmarm, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Gavin Shan
In-Reply-To: <20260605153248.2412064-2-weilin.chang@arm.com>
Hi Wei Lin,
On Fri, Jun 05, 2026 at 04:32:47PM +0100, Wei-Lin Chang wrote:
> When checking whether a memslot has dirty logging enabled, the
> KVM_MEM_LOG_DIRTY_PAGES flag is the source of truth. Previously we were
> using memslot_is_logging() which only tests dirty bitmap and did not
> consider dirty ring. This was not detected because
> KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP was introduced together with KVM
> arm64 dirty ring, and users need to enable it to ensure dirty
> information is not lost for the case of VGIC LPI/ITS table changes.
>
> Fix this by using kvm_slot_dirty_track_enabled() instead which checks
> KVM_MEM_LOG_DIRTY_PAGES.
>
> Note that memslot_is_logging() also treats a memslot as not logging if
> KVM_MEM_READONLY is set, hence a memslot with both dirty logging and
> read only would be seen as not logging for memslot_is_logging(), but
> logging for kvm_slot_dirty_track_enabled(). This allows a read only
> mapping of size > PAGE_SIZE to be built when memslot_is_logging() is
> used, leading to a better read performance compared to
> kvm_slot_dirty_track_enabled(). However memslots that have both
> KVM_MEM_LOG_DIRTY_PAGES and KVM_MEM_READONLY set do not really make
> sense as dirty logging is essentially nop for a read only memslot, so
> this shouldn't affect real workloads much.
It worries me a bit that we are ignoring the KVM_MEM_READONLY flag...
I have not yet gone through the whole s2_mmu code but IIUC we can have
scenarios on which a memslot can be read-only and have dirty-logging
enabled. If a memslot is not faulted yet, IIUC it is marked as read-only
(so it can be mapped on write fault), and we can have dirty-logging
enabled for it as well (as the VMM has no idea).
Would not that change impact this scenario?
I will take a better look in that part of the code as well, to properly
understand it.
Thanks!
Leo
>
> Fixes: 9cb1096f8590 ("KVM: arm64: Enable ring-based dirty memory tracking")
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> It took me a long investigation to acquire the context needed to
> understand this change, however the reason for this problem not being
> detected is an educated guess. Please let me know if this is wrong or
> if there are other issues, thanks!
>
> arch/arm64/kvm/mmu.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 4da9281312eb..06c46124d3e7 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -161,11 +161,6 @@ static int kvm_mmu_split_huge_pages(struct kvm *kvm, phys_addr_t addr,
> return ret;
> }
>
> -static bool memslot_is_logging(struct kvm_memory_slot *memslot)
> -{
> - return memslot->dirty_bitmap && !(memslot->flags & KVM_MEM_READONLY);
> -}
> -
> /**
> * kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8
> * @kvm: pointer to kvm structure.
> @@ -1748,7 +1743,7 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
> {
> short vma_shift;
>
> - if (memslot_is_logging(s2fd->memslot)) {
> + if (kvm_slot_dirty_track_enabled(s2fd->memslot)) {
> s2vi->max_map_size = PAGE_SIZE;
> vma_shift = PAGE_SHIFT;
> } else {
> @@ -1953,7 +1948,7 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
> *prot = KVM_PGTABLE_PROT_R;
>
> if (s2vi->map_writable && (s2vi->device ||
> - !memslot_is_logging(s2fd->memslot) ||
> + !kvm_slot_dirty_track_enabled(s2fd->memslot) ||
> kvm_is_write_fault(s2fd->vcpu)))
> *prot |= KVM_PGTABLE_PROT_W;
>
> @@ -2084,7 +2079,7 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
> * and a write fault needs to collapse a block entry into a table.
> */
> memcache = get_mmu_memcache(s2fd->vcpu);
> - if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
> + if (!perm_fault || (kvm_slot_dirty_track_enabled(s2fd->memslot) &&
> kvm_is_write_fault(s2fd->vcpu))) {
> ret = topup_mmu_memcache(s2fd->vcpu, memcache);
> if (ret)
> --
> 2.43.0
>
^ permalink raw reply
* [GIT PULL] i.MX arm64 dts for v7.2
From: Frank.Li @ 2026-06-08 15:57 UTC (permalink / raw)
To: soc, arm; +Cc: Frank.Li, kernel, imx, linux-arm-kernel
From: Frank.Li@nxp.com
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-dt64-7.2
for you to fetch changes up to c10cfc952215644956284a42fa7b7860dfbcb5f5:
arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlays (2026-06-05 13:21:22 -0400)
----------------------------------------------------------------
i.MX dt64 changes for v7.2
New Board Support:
Added 15+ new boards including i.MX95 (FRDM PRO, Aquila, Audio Board v2),
i.MX93/91 (Variscite DART/VAR-SOM), i.MX8 (TQMa8QM, SolidRun i.MX8DXL
HummingBoard), Toradex Verdin Zinnia variants, and LX2160A Half Twins.
PCIe Improvements:
Added Root Port nodes and PERST properties across
iMX8MM/MP/MQ/DXL/QM/QXP/95, new PCIe support for iMX94/943, common M.2
PCIe overlay, fixed outbound address space configuration
Graphics, Camera and Display:
Mali G310 GPU for iMX952, HDMI for iMX8MP PhyBoard, extensive DH
Electronics panel overlays, Extensive overlay ecosystem for DH
Electronics iMX8MP boards, PhyBoard PEB-AV-18, camera (OV5640), and
ethernet configuration overlays
Peripheral Support:
S32G2/G3 PIT/ADC/PWM, iMX8ULP CSI/ISI, iMX943 SD WiFi, USB hub for
LX2160A, TPM/CAN/ADC support for Variscite boards, Bluetooth and UART
enhancements for Toradex SMARC boards.
Enhancements
Added gpio-line-namesacross PhyBOARD platforms. Watchdog reset pinctrl
configurations for iMX91 boards, Ethernet PHY reset GPIO support.
Bug Fixes:
Corrected DDR PMU interrupts, SMMU registers, watchdog addresses,
interrupt flags, GPIO configurations, PHY reset handling, and RS485
polarity, USDHC signal configurations for PhyCORE SoMs.
----------------------------------------------------------------
Alexander Stein (3):
arm64: dts: freescale: add initial device tree for TQMa8x
arm64: dts: imx8qm-tqma8qm-mba8x: Disable Cortex-A72 cluster
arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as well
Alice Guo (2):
arm64: dts: imx94: fix DDR PMU interrupt number
arm64: dts: freescale: add bootph-all to watchdog nodes for i.MX platforms
Antoine Gouby (2):
arm64: dts: freescale: imx95-toradex-smarc: replace deprecated gpio property
arm64: dts: freescale: imx95-aquila: Add Clover carrier board
Christoph Stoidner (1):
arm64: dts: freescale: imx{91,93}-phycore-som: Improve USDHC signals
Florijan Plohl (6):
arm64: dts: freescale: imx91-phycore-som: Add gpio-line-names
arm64: dts: freescale: imx91-phyboard-segin: Add gpio-line-names
arm64: dts: freescale: imx93-phycore-som: Add gpio-line-names
arm64: dts: freescale: imx93-phyboard-nash: Add gpio-line-names
arm64: dts: freescale: imx93-phyboard-segin: Add gpio-line-names
arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlays
Francesco Dolcini (8):
dt-bindings: arm: fsl: Add verdin imx8m[mp] and imx95 zinnia board
arm64: dts: freescale: imx8mm-verdin: Split UART_2 pinctrl group
arm64: dts: freescale: imx8mm-verdin: Add Zinnia
arm64: dts: freescale: imx8mp-verdin: Split UART_2 pinctrl group
arm64: dts: freescale: imx8mp-verdin: Add Zinnia
arm64: dts: freescale: imx95-verdin: Split UART_2 pinctrl group
arm64: dts: freescale: imx95-verdin: Add Zinnia
arm64: dts: freescale: imx95-verdin-ivy: fix RS485 RTS polarity
Franz Schnyder (4):
arm64: dts: freescale: imx95-toradex-smarc: Add SER2 interface
arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on lpuart5
arm64: dts: freescale: imx95-toradex-smarc: Use gpio-hog for WIFI_UART_EN
dt-bindings: arm: fsl: add Aquila iMX95
Frieder Schrempf (2):
arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequency
arm64: dts: imx8mp-kontron: Fix GPIO for display power switch
Guangliu Ding (1):
arm64: dts: imx952: Describe Mali G310 GPU
Guoniu Zhou (1):
arm64: dts: imx8ulp: Add CSI and ISI Nodes
Joseph Guo (2):
dt-bindings: arm: fsl: Add i.MX95 19x19 FRDM PRO board
arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
Josua Mayer (11):
arm64: dts: lx2160a-rev2: extend 32-bit and add 64-bit pci regions
arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi
arm64: dts: lx2162a-clearfog: cleanup superfluous status properties
arm64: dts: lx2162a-clearfog: specify sfp ports led colour and function
dt-bindings: arm: fsl: Add solidrun lx2160a twins board
arm64: dts: lx2160a-clearfog-itx: remove redundant dts version tag
arm64: dts: lx2160a-clearfog-itx: move shared includes to dts
arm64: dts: lx2160a-cex7: add usb hub
arm64: dts: Add support for LX2160 Twins board in single configuration
dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
Joy Zou (10):
dt-bindings: arm: fsl: add i.MX91 9x9 QSB board
arm64: dts: imx91-11x11-evk: remove unused property clock-frequency from mdio node
arm64: dts: imx93-11x11-evk: remove unused property clock-frequency from mdio node
arm64: dts: imx93-9x9-qsb: remove unused property clock-frequency from mdio node
arm64: dts: freescale: add i.MX91 9x9 QSB basic support
arm64: dts: imx91-9x9-qsb: remove unused property clock-frequency from mdio node
arm64: dts: imx91-9x9-qsb: add pinctrl for wdog3 reset
arm64: dts: imx91-11x11-evk: add pinctrl for wdog3 reset
arm64: dts: imx91-11x11-evk: add reset gpios for ethernet PHYs
arm64: dts: imx91-9x9-qsb: add reset gpios for ethernet PHYs
João Paulo Gonçalves (1):
arm64: dts: freescale: add Aquila iMX95 support
Khristine Andreea Barbulescu (3):
arm64: dts: s32g: add PIT support for s32g2 and s32g3
arm64: dts: s32g: add SAR ADC support for s32g2 and s32g3
arm64: dts: s32g: add PWM support for s32g2 and s32g3
Krzysztof Kozlowski (5):
arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags
arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags
arm64: dts: imx8mp-ab2: Correct interrupt flags
arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags
arm64: dts: s32g3: Fix SWT8 watchdog address
Liu Ying (1):
arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
Marek Vasut (2):
arm64: dts: imx8mn: Sort ifm VHIP4 EvalBoard Makefile entries
arm64: dts: imx8mp: Add DT overlays for DH i.MX8M Plus DHCOM SoM and boards
Maud Spierings (2):
arm64: dts: freescale: moduline-display-av101hdt-a10: add backlight
arm64: dts: freescale: moduline-display-av123z7m-n17: add backlight
Nora Schiffer (1):
arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc aliases
Paul Kocialkowski (1):
arm64: dts: imx8mp-phyboard-pollux: Add HDMI support
Peng Fan (5):
arm64: dts: imx8x-colibri: Correct SODIMM PAD settings
Revert "arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL signal"
Revert "arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL signal"
arm64: dts: imx95: Correct SMMU reg
arm64: dts: imx95: Add SMMU PMU nodes
Primoz Fiser (2):
arm64: dts: freescale: imx{91,93}-phycore-som: Set BUCK5 in FPWM mode
arm64: dts: freescale: imx{91,93}-phycore-som: Adjust PHY RST drive-strength
Richard Zhu (4):
arm64: dts: imx94: Add pcie0 and pcie0-ep supports
arm64: dts: imx943: Add pcie1 and pcie1-ep supports
arm64: dts: imx943-evk: Add pcie[0,1] and pcie-ep[0,1] support
arm64: dts: imx95: Correct PCIe outbound address space configuration
Shengjiu Wang (2):
dt-bindings: arm: fsl: Add compatible for i.MX95 15x15 audio board (version 2)
arm64: dts: add support for NXP i.MX95 15x15 audio board (version 2)
Sherry Sun (13):
arm64: dts: imx8mp-evk: Disable PCIe bus in the default dts
arm64: dts: imx95-15x15-evk: Disable PCIe bus in the default dts
arm64: dts: imx: Add common imx-m2-pcie.dtso to enable PCIe on M.2 connector
arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP properties
arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supply
arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supply
arm64: dts: imx8mm: Add Root Port node and PERST property
arm64: dts: imx8mp: Add Root Port node and PERST property
arm64: dts: imx8mq: Add Root Port node and PERST property
arm64: dts: imx8dxl/qm/qxp: Add Root Port node and PERST property
arm64: dts: imx95: Add Root Port node and PERST property
arm64: dts: imx943-evk: Fix PCIe EP vpcie-supply
arm64: dts: imx943-evk-sdwifi: add a new dtso to support SDIW612 WiFi
Stefano Radaelli (15):
arm64: dts: imx91-var-dart-sonata: add RGB enable supply for PCA6408
dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
arm64: dts: freescale: Add support for Variscite DART-MX93
arm64: dts: imx93-var-dart: Add support for Variscite Sonata board
dt-bindings: arm: fsl: add Variscite VAR-SOM-MX91 Boards
arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
arm64: dts: imx91-var-som: Add support for Variscite Symphony board
arm64: dts: imx95-var-dart-sonata: add TPM reset GPIO
arm64: dts: imx95-var-dart-sonata: add CAN controller
arm64: dts: imx91-var-som-symphony: fix RGB_SEL handling
arm64: dts: imx93-var-som-symphony: add TPM support
arm64: dts: imx93-var-som-symphony: enable UART7
arm64: dts: imx93-var-som-symphony: keep RGB_SEL low
arm64: dts: imx93-var-som-symphony: enable TPM3 PWM
arm64: dts: imx93-var-som-symphony: enable ADC
Documentation/devicetree/bindings/arm/fsl.yaml | 37 +
arch/arm64/boot/dts/freescale/Makefile | 163 ++-
.../fsl-ls1028a-tqmls1028a-mbls1028a.dtsi | 4 +-
.../arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi | 41 +-
.../boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts | 2 +
.../dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 7 +-
.../boot/dts/freescale/fsl-lx2160a-half-twins.dts | 830 ++++++++++++++
.../boot/dts/freescale/fsl-lx2160a-honeycomb.dts | 2 +
.../arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi | 48 +-
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 24 +-
.../boot/dts/freescale/fsl-lx2162a-clearfog.dts | 37 +-
arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso | 15 +
arch/arm64/boot/dts/freescale/imx8-ss-hsio.dtsi | 11 +
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 7 +-
.../freescale/imx8dxl-hummingboard-telematics.dts | 560 ++++++++++
arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi | 458 ++++++++
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 5 +
.../arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 10 +-
.../boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 7 +-
.../dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts | 21 +
.../dts/freescale/imx8mm-verdin-wifi-zinnia.dts | 21 +
.../boot/dts/freescale/imx8mm-verdin-zinnia.dtsi | 383 +++++++
arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi | 16 +-
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 11 +
.../dts/freescale/imx8mn-vhip4-evalboard-v1.dts | 2 +-
.../dts/freescale/imx8mn-vhip4-evalboard-v2.dts | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-ab2.dts | 2 +-
.../imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi | 37 +
.../imx8mp-dhcom-overlay-panel-clock.dtsi | 33 +
.../imx8mp-dhcom-overlay-panel-common.dtsi | 31 +
.../freescale/imx8mp-dhcom-overlay-panel-dpi.dtsi | 35 +
.../imx8mp-dhcom-overlay-panel-etm0700g0edh6.dtsi | 53 +
.../freescale/imx8mp-dhcom-overlay-panel-lvds.dtsi | 22 +
.../imx8mp-dhcom-pdk-overlay-eth2xfast.dtso | 10 +
...dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso | 40 +
.../imx8mp-dhcom-pdk2-overlay-531-100-x21.dtso | 32 +
.../imx8mp-dhcom-pdk2-overlay-531-100-x22.dtso | 32 +
.../imx8mp-dhcom-pdk2-overlay-560-300-x12.dtso | 25 +
.../arm64/boot/dts/freescale/imx8mp-dhcom-pdk2.dts | 2 +-
...dhcom-pdk3-overlay-505-200-x36-ch101olhlwh.dtso | 53 +
.../imx8mp-dhcom-pdk3-overlay-531-100-x40.dtso | 32 +
.../imx8mp-dhcom-pdk3-overlay-531-100-x41.dtso | 32 +
.../imx8mp-dhcom-pdk3-overlay-560-300-x36.dtso | 24 +
.../imx8mp-dhcom-pdk3-overlay-732-100-x36.dtso | 36 +
...mx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtso | 56 +
...m-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29.dtso | 32 +
...m-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31.dtso | 32 +
...dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640.dtsi | 64 ++
.../arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts | 2 +-
...com-picoitx-overlay-626-100-x2-ch101olhlwh.dtso | 77 ++
.../boot/dts/freescale/imx8mp-dhcom-picoitx.dts | 3 +
.../imx8mp-dhcom-som-overlay-eth1xfast.dtso | 85 ++
.../imx8mp-dhcom-som-overlay-eth2xfast.dtso | 29 +
.../arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi | 4 +-
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 9 +-
.../boot/dts/freescale/imx8mp-kontron-bl-osm-s.dts | 14 +-
.../boot/dts/freescale/imx8mp-kontron-osm-s.dtsi | 7 +-
.../dts/freescale/imx8mp-phyboard-pollux-rdk.dts | 62 ++
.../dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts | 3 +
...x8p-ml81-moduline-display-106-av101hdt-a10.dtso | 24 +
...x8p-ml81-moduline-display-106-av123z7m-n17.dtso | 19 +-
.../dts/freescale/imx8mp-verdin-nonwifi-zinnia.dts | 21 +
.../dts/freescale/imx8mp-verdin-wifi-zinnia.dts | 21 +
.../boot/dts/freescale/imx8mp-verdin-zinnia.dtsi | 422 +++++++
arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi | 14 +-
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 11 +
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 10 +
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 22 +
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 10 +
arch/arm64/boot/dts/freescale/imx8qm-ss-hsio.dtsi | 22 +
.../boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts | 871 +++++++++++++++
arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi | 325 ++++++
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 6 +-
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 4 +-
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 67 ++
arch/arm64/boot/dts/freescale/imx8x-colibri.dtsi | 4 +-
arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts | 15 +-
.../imx91-93-phyboard-segin-peb-av-18.dtsi | 93 ++
arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts | 435 ++++++++
.../freescale/imx91-phyboard-segin-peb-av-18.dtso | 57 +
.../boot/dts/freescale/imx91-phyboard-segin.dts | 24 +-
.../boot/dts/freescale/imx91-phycore-som.dtsi | 39 +-
.../boot/dts/freescale/imx91-var-dart-sonata.dts | 9 +
.../boot/dts/freescale/imx91-var-som-symphony.dts | 527 +++++++++
arch/arm64/boot/dts/freescale/imx91-var-som.dtsi | 456 ++++++++
arch/arm64/boot/dts/freescale/imx91_93_common.dtsi | 3 +
.../boot/dts/freescale/imx93-11x11-evk-common.dtsi | 1 -
.../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 ++
.../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-
.../freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso | 14 +
arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts | 1 -
.../boot/dts/freescale/imx93-phyboard-nash.dts | 39 +-
.../freescale/imx93-phyboard-segin-peb-av-18.dtso | 57 +
.../boot/dts/freescale/imx93-phyboard-segin.dts | 24 +-
.../boot/dts/freescale/imx93-phycore-som.dtsi | 39 +-
.../boot/dts/freescale/imx93-var-dart-sonata.dts | 654 +++++++++++
arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi | 461 ++++++++
.../boot/dts/freescale/imx93-var-som-symphony.dts | 61 +
arch/arm64/boot/dts/freescale/imx94.dtsi | 102 +-
.../boot/dts/freescale/imx943-evk-sdwifi.dtso | 15 +
arch/arm64/boot/dts/freescale/imx943-evk.dts | 85 +-
arch/arm64/boot/dts/freescale/imx943.dtsi | 75 ++
arch/arm64/boot/dts/freescale/imx95-15x15-ab2.dts | 669 +++++++++++
arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts | 9 +-
arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts | 12 +-
.../boot/dts/freescale/imx95-19x19-frdm-pro.dts | 1021 +++++++++++++++++
.../boot/dts/freescale/imx95-aquila-clover.dts | 285 +++++
arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts | 389 +++++++
arch/arm64/boot/dts/freescale/imx95-aquila.dtsi | 1160 ++++++++++++++++++++
.../boot/dts/freescale/imx95-toradex-smarc-dev.dts | 5 +
.../boot/dts/freescale/imx95-toradex-smarc.dtsi | 46 +-
.../boot/dts/freescale/imx95-var-dart-sonata.dts | 29 +-
.../arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi | 1 -
.../dts/freescale/imx95-verdin-nonwifi-zinnia.dts | 21 +
.../dts/freescale/imx95-verdin-wifi-zinnia.dts | 21 +
.../boot/dts/freescale/imx95-verdin-zinnia.dtsi | 429 ++++++++
arch/arm64/boot/dts/freescale/imx95-verdin.dtsi | 18 +-
arch/arm64/boot/dts/freescale/imx95.dtsi | 129 ++-
arch/arm64/boot/dts/freescale/imx952.dtsi | 47 +
arch/arm64/boot/dts/freescale/s32g2.dtsi | 66 +-
arch/arm64/boot/dts/freescale/s32g3.dtsi | 70 +-
arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi | 78 +-
122 files changed, 13347 insertions(+), 267 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-clock.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-common.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-dpi.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-etm0700g0edh6.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-lvds.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk-overlay-eth2xfast.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x21.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x22.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-560-300-x12.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-505-200-x36-ch101olhlwh.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x40.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x41.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-560-300-x36.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-732-100-x36.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth1xfast.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth2xfast.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx91-93-phyboard-segin-peb-av-18.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx91-var-som-symphony.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx91-var-som.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx943-evk-sdwifi.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx95-15x15-ab2.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-aquila.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-zinnia.dtsi
^ permalink raw reply
* Re: [PATCH 06/18] pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function
From: Bartosz Golaszewski @ 2026-06-08 16:13 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-7-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:42 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> phy4_led1 pin function maps led incorrectly. It uses the same map as
> phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
>
> Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 17/18] pinctrl: airoha: prepare for en7523 adding
From: Bartosz Golaszewski @ 2026-06-08 16:15 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-18-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:53 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> en7523 a bit differs from an7581/an7583. It has different register
> offsets and slightly different bitfield masks.
>
> Let's adapt common header and existing drivers for the future addition
> of en7523.
>
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Looks good to me.
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 16/18] pinctrl: airoha: an7583: remove an7583 prefix from variable names
From: Bartosz Golaszewski @ 2026-06-08 16:17 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-17-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:52 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> We have only an7583 specific code in the pinctrl-an7583 kernel module,
> so 'an75831_' prefix is not necessary anymore. Remove it.
>
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 1/6] ACPI: RISC-V: Fix riscv_acpi_irq_get_dep() loop termination
From: Sunil V L @ 2026-06-08 16:24 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260603-gic-v5-acpi-iwb-probe-deferral-v2-1-23ffa16b6ebb@kernel.org>
Hi Lorenzo,
On Wed, Jun 3, 2026 at 1:51 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> In riscv_acpi_add_irq_dep() the main loop condition would currently stop
> the loop if an interrupt descriptor contains an interrupt for which the
> respective GSI handle is NULL, which is not correct because subsequent
> interrupts in the interrupt descriptor might still have a GSI dependency
> that must not be skipped.
>
> Rework riscv_acpi_add_irq_dep() and the riscv_acpi_irq_get_dep() call chain
> to fix it - by not forcing the loop to stop in order to guarantee
> dependency detection for all the interrupt entries in the CRS descriptor.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> ---
> drivers/acpi/riscv/irq.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
> index 9b88d0993e88..cd83c3035cf6 100644
> --- a/drivers/acpi/riscv/irq.c
> +++ b/drivers/acpi/riscv/irq.c
> @@ -299,6 +299,7 @@ static acpi_status riscv_acpi_irq_get_parent(struct acpi_resource *ares, void *c
> return AE_OK;
>
> ctx->handle = riscv_acpi_get_gsi_handle(eirq->interrupts[ctx->index]);
> + ctx->rc = 0;
> return AE_CTRL_TERMINATE;
> }
>
> @@ -314,10 +315,8 @@ static int riscv_acpi_irq_get_dep(acpi_handle handle, unsigned int index, acpi_h
>
> acpi_walk_resources(handle, METHOD_NAME__CRS, riscv_acpi_irq_get_parent, &ctx);
> *gsi_handle = ctx.handle;
> - if (*gsi_handle)
> - return 1;
>
> - return 0;
> + return ctx.rc;
> }
>
> static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> @@ -381,8 +380,11 @@ static u32 riscv_acpi_add_irq_dep(acpi_handle handle)
> int i;
>
> for (i = 0;
> - riscv_acpi_irq_get_dep(handle, i, &gsi_handle);
> + !riscv_acpi_irq_get_dep(handle, i, &gsi_handle);
> i++) {
> + if (!gsi_handle)
> + continue;
> +
> dep_devices.count = 1;
> dep_devices.handles = kzalloc_objs(*dep_devices.handles, 1);
> if (!dep_devices.handles) {
>
Do these fixes need the Fixes tag?
Otherwise, LGTM.
Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
Thanks!
Sunil
^ permalink raw reply
* Re: [PATCHv2] dmaengine: st_fdma: simplify allocation
From: Frank Li @ 2026-06-08 16:25 UTC (permalink / raw)
To: Rosen Penev
Cc: dmaengine, Patrice Chotard, Vinod Koul, Frank Li, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/STI ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be|_ptr)?b
In-Reply-To: <20260608051829.7390-1-rosenp@gmail.com>
On Sun, Jun 07, 2026 at 10:18:29PM -0700, Rosen Penev wrote:
Nit: dmaengine: st_fdma: simplify allocation by using flexible array
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Use a flexible array member to combine kzalloc and kcalloc to a single
> allocation.
>
> Add __counted_by for extra runtime analysis. Assign counting variable
> after allocation before any array accesses.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>
^ permalink raw reply
* Re: [PATCH] dmaengine: qcom: hidma: use sysfs_emit() in sysfs show callbacks
From: Frank Li @ 2026-06-08 16:27 UTC (permalink / raw)
To: Hungyu Lin
Cc: okaya, vkoul, Frank.Li, linux-arm-kernel, linux-arm-msm,
dmaengine, linux-kernel
In-Reply-To: <20260607163119.78717-1-dennylin0707@gmail.com>
On Sun, Jun 07, 2026 at 04:31:19PM +0000, Hungyu Lin wrote:
> [You don't often get email from dennylin0707@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Replace sprintf() and strlen() patterns in sysfs show callbacks
> with sysfs_emit().
>
> sysfs_emit() is the preferred helper for formatting sysfs output
> and simplifies the implementation.
>
> Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/dma/qcom/hidma.c | 6 ++----
> drivers/dma/qcom/hidma_mgmt_sys.c | 19 ++++++++-----------
> 2 files changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index 5a8dca8db5ce..7a7f302a9699 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -624,12 +624,10 @@ static ssize_t hidma_show_values(struct device *dev,
> {
> struct hidma_dev *mdev = dev_get_drvdata(dev);
>
> - buf[0] = 0;
> -
> if (strcmp(attr->attr.name, "chid") == 0)
> - sprintf(buf, "%d\n", mdev->chidx);
> + return sysfs_emit(buf, "%d\n", mdev->chidx);
>
> - return strlen(buf);
> + return 0;
> }
>
> static inline void hidma_sysfs_uninit(struct hidma_dev *dev)
> diff --git a/drivers/dma/qcom/hidma_mgmt_sys.c b/drivers/dma/qcom/hidma_mgmt_sys.c
> index 930eae0a6257..9672ef9ee8fc 100644
> --- a/drivers/dma/qcom/hidma_mgmt_sys.c
> +++ b/drivers/dma/qcom/hidma_mgmt_sys.c
> @@ -102,15 +102,12 @@ static ssize_t show_values(struct device *dev, struct device_attribute *attr,
> struct hidma_mgmt_dev *mdev = dev_get_drvdata(dev);
> unsigned int i;
>
> - buf[0] = 0;
> -
> for (i = 0; i < ARRAY_SIZE(hidma_mgmt_files); i++) {
> - if (strcmp(attr->attr.name, hidma_mgmt_files[i].name) == 0) {
> - sprintf(buf, "%d\n", hidma_mgmt_files[i].get(mdev));
> - break;
> - }
> + if (strcmp(attr->attr.name, hidma_mgmt_files[i].name) == 0)
> + return sysfs_emit(buf, "%d\n",
> + hidma_mgmt_files[i].get(mdev));
> }
> - return strlen(buf);
> + return 0;
> }
>
> static ssize_t set_values(struct device *dev, struct device_attribute *attr,
> @@ -143,15 +140,15 @@ static ssize_t show_values_channel(struct kobject *kobj,
> struct hidma_chan_attr *chattr;
> struct hidma_mgmt_dev *mdev;
>
> - buf[0] = 0;
> chattr = container_of(attr, struct hidma_chan_attr, attr);
> mdev = chattr->mdev;
> +
> if (strcmp(attr->attr.name, "priority") == 0)
> - sprintf(buf, "%d\n", mdev->priority[chattr->index]);
> + return sysfs_emit(buf, "%d\n", mdev->priority[chattr->index]);
> else if (strcmp(attr->attr.name, "weight") == 0)
> - sprintf(buf, "%d\n", mdev->weight[chattr->index]);
> + return sysfs_emit(buf, "%d\n", mdev->weight[chattr->index]);
>
> - return strlen(buf);
> + return 0;
> }
>
> static ssize_t set_values_channel(struct kobject *kobj,
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Suzuki K Poulose @ 2026-06-08 16:27 UTC (permalink / raw)
To: Sudeep Holla, Aneesh Kumar K.V
Cc: linux-coco, linux-arm-kernel, linux-kernel, Catalin Marinas,
Greg KH, Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi,
Mark Rutland, Will Deacon, Steven Price
In-Reply-To: <20260608-hot-fascinating-tortoise-cccc61@sudeepholla>
On 08/06/2026 13:32, Sudeep Holla wrote:
> On Mon, Jun 08, 2026 at 04:56:29PM +0530, Aneesh Kumar K.V wrote:
>> Suzuki K Poulose <suzuki.poulose@arm.com> writes:
>>
>>> On 08/06/2026 09:19, Aneesh Kumar K.V wrote:
>>>> Sudeep Holla <sudeep.holla@kernel.org> writes:
>>>>
>>>>> On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote:
>>>>>> Sudeep Holla <sudeep.holla@kernel.org> writes:
>>>>>>
>>>>>> ...
>>
>> ...
>>
>>>>> I was trying to avoid conditional compilation altogether and hence the
>>>>> reason for keeping it as simple as possible. Also IS_ENABLED(CONFIG_ARM64)
>>>>> in above snippet must come as some condition to this generic probe.
>>>>>
>>>>> Adding any more logic or callback defeats the bus idea here if we need
>>>>> to rely/depend on multiple conditional compilation or callbacks IMO.
>>>>>
>>>>> Let's find see if it can work with what we are adding now and may add in
>>>>> near future and then decide.
>>>>>
>>>>
>>>> If we move all the conditional checks to the driver probe path, then I
>>>> think this can work. Something like the below:
>>>>
>>>> struct smccc_device_info {
>>>> u32 func_id;
>>>> bool requires_smc;
>>>> const char *device_name;
>>>> };
>>>>
>>>> static const struct smccc_device_info smccc_devices[] __initconst = {
>>>> {
>>>> .func_id = ARM_SMCCC_TRNG_VERSION,
>>>> .requires_smc = false,
>>>> .device_name = "arm-smccc-trng",
>>>> },
>>>>
>>>> {
>>>> .func_id = RSI_ABI_VERSION,
>>>
>>> Don't we need parameters passed to this (Requested Interface version for
>>> e.g.) ? See more below.
>>>
>>
>> The idea is that we only check whether the function ID is supported. All
>> other conditional logic should be handled in the driver probe path, as
>> demonstrated by the changes in drivers/char/hw_random/arm_smccc_trng.c.
>>
>
> +1. Yes, we just want to know whether the firmware is aware of that feature
> before creating the `smccc_device` for it. The device probe can then perform a
> more thorough, feature-specific check to determine whether the device/feature
> is usable.
>
> That is the main idea behind the approach I suggested. Please let me know if
> you still see any issues or think this may not work.
Ok, yea, I kind of forgot that we are boot strapping a driver based on
this "smccc device" and the device is only an indication of the firmware
service, the driver would decide if the service matches its expectation.
Thanks for the clarification, apologies for the noise.
Suzuki
>
^ permalink raw reply
* Re: [PATCH 00/39] Add i.MX95 DPU/DSI/LVDS support
From: Marek Vasut @ 2026-06-08 16:29 UTC (permalink / raw)
To: Liu Ying, Piyush Patle
Cc: dri-devel, imx, linux-arm-kernel, linux-clk, devicetree,
Shawn Guo, Fabio Estevam, Peng Fan, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lucas Stach, Laurent Pinchart,
Thomas Zimmermann, Abel Vesa, Pengutronix Kernel Team
In-Reply-To: <aiZzxhljfyYQ68Gl@raspi>
On 6/8/26 9:48 AM, Liu Ying wrote:
Hello everyone,
>> I brought this series up on the i.MX95 15x15 FRDM (IT6263 LVDS-to-HDMI on
>> LVDS ch1). It mostly works, but I ran into a few issues around DI routing,
>> LVDS format handling, and DC enable sequencing which needed rework before
>> HDMI would come up reliably on the board.
>>
>> I don't see a v2 of the series and things seem to have been quiet since
>> November. Are you planning to post an updated version?
>
> My plan was to enable prefetch engine support[1] for i.MX8QXP display
> controller and add device tree for a whole i.MX8QXP LVDS display pipeline,
> before adding i.MX95 display controller support.
>
> Unfortunately, it seems that Marek is not a big fan of [1]
I am fine with [1] as long as it can be isolated and does not affect
every SoC that might reuse this driver, which I think it can be done.
> and I'm busy
> with downstream development so the plan doesn't move forward well. I still
> think [1] makes sense(maybe I need to rebase it on latest drm-misc-next),
> so I'd like to see review comments on [1] and hopefully people think that
> the overall idea of [1] is ok.
My only concern is, to keep it isolated to MX8Q, so this driver can be
reused by MX95.
>> I've accumulated a fair amount of rework while getting this running on the
>> FRDM. If you're not planning a v2, I can clean things up and send one based
>> on the current series.
>
> I still think that i.MX95 display controller driver should be in a separate
> driver, rather than sharing the same driver with i.MX8QXP display controller
> like this patch series does, because the two display controllers are quite
> different as I mentioned in comments on this patch series and in discussion
> in [1]. Also, the common part between the two display controllers should
> be extracted to a common helper library as I mentioned there too.
Are they really? It seems this series adds support for the MX95 DC
without that many changes, so are the DCs really that different ? It
seems the MX95 DC is simply a reuse/evolution of the MX8Q DC blocks, so
duplicating the code seems like the wrong direction, it will only lead
to disparate sets of bugs in two drivers, which isn't desired.
(I might not fully understand what you have in mind with the helper
library though?)
^ permalink raw reply
* Re: [PATCH v2 3/6] ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling
From: Sunil V L @ 2026-06-08 16:30 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260603-gic-v5-acpi-iwb-probe-deferral-v2-3-23ffa16b6ebb@kernel.org>
On Wed, Jun 3, 2026 at 2:18 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> The loop in riscv_acpi_add_prt_dep() includes error conditions that are
> handled in a dubious - if not outright wrong - way, by continuining the
> loop (which skips and misses the entry pointer update to point to the next
> entry).
>
> Rewrite the loop as a for loop (that handles the continuation correctly)
> and wrap the condition and update statements using helper functions to make
> it cleaner.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> ---
> drivers/acpi/riscv/irq.c | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
> index 75170151c614..0cdec5dd575e 100644
> --- a/drivers/acpi/riscv/irq.c
> +++ b/drivers/acpi/riscv/irq.c
> @@ -319,6 +319,20 @@ static int riscv_acpi_irq_get_dep(acpi_handle handle, unsigned int index, acpi_h
> return ctx.rc;
> }
>
> +static bool acpi_prt_entry_valid(void *prt_entry)
> +{
> + struct acpi_pci_routing_table *entry = prt_entry;
> +
> + return entry && entry->length > 0;
> +}
> +
> +static void *acpi_prt_next_entry(void *prt_entry)
> +{
> + struct acpi_pci_routing_table *entry = prt_entry;
> +
> + return prt_entry + entry->length;
> +}
> +
> static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> {
> struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> @@ -337,7 +351,7 @@ static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> }
>
> entry = buffer.pointer;
> - while (entry && (entry->length > 0)) {
> + for (; acpi_prt_entry_valid(entry); entry = acpi_prt_next_entry(entry)) {
> if (entry->source[0]) {
> status = acpi_get_handle(handle, entry->source, &link_handle);
> if (ACPI_FAILURE(status))
> @@ -365,9 +379,6 @@ static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> dep_devices.handles[0] = gsi_handle;
> count += acpi_scan_add_dep(handle, &dep_devices);
> }
> -
> - entry = (struct acpi_pci_routing_table *)
> - ((unsigned long)entry + entry->length);
> }
>
Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 2/6] ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep()
From: Sunil V L @ 2026-06-08 16:31 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260603-gic-v5-acpi-iwb-probe-deferral-v2-2-23ffa16b6ebb@kernel.org>
On Wed, Jun 3, 2026 at 1:52 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> In riscv_acpi_add_prt_dep(), the acpi_get_handle() call can fail which
> would leave link_handle uninitialized.
>
> Fix it by checking the acpi_get_handle() return status and skip the entry
> if it fails.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> ---
> drivers/acpi/riscv/irq.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
> index cd83c3035cf6..75170151c614 100644
> --- a/drivers/acpi/riscv/irq.c
> +++ b/drivers/acpi/riscv/irq.c
> @@ -339,7 +339,9 @@ static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> entry = buffer.pointer;
> while (entry && (entry->length > 0)) {
> if (entry->source[0]) {
> - acpi_get_handle(handle, entry->source, &link_handle);
> + status = acpi_get_handle(handle, entry->source, &link_handle);
> + if (ACPI_FAILURE(status))
> + continue;
> dep_devices.count = 1;
>
Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Add kvm_for_each_vncr_tlb() helper
From: Oliver Upton @ 2026-06-08 16:33 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, kvm, linux-arm-kernel, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Hyunwoo Kim, stable
In-Reply-To: <20260607175745.297793-1-maz@kernel.org>
Hey Marc,
Especially since this is a stable-worthy fix, it might be worth calling
out the bug in the shortlog, e.g.
KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB
On Sun, Jun 07, 2026 at 06:57:45PM +0100, Marc Zyngier wrote:
> VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions,
> and either can race against a vcpu not being onlined yet (no pseudo-TLB
> allocated). Similarly, the TLB might be invalid, and the invalidation
> should be skipped in this case.
>
> Both kvm_invalidate_vncr_ipa() and kvm_invalidate_vncr_va() are
> expected to perform the same checks, except that the latter doesn't
> check for the allocation and blindly dereferences the pointer.
>
> Solve this by introducing a new iterator built on top of the usual
> kvm_for_each_vcpu() that checks for both of the above conditions,
> and convert the two users to it.
>
> Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/r/aiUvSbrWndQeUPc8@v4bel
> Fixes: 4ffa72ad8f37 ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2")
> Cc: stable@vger.kernel.org
Looks good
Reviewed-by: Oliver Upton <oupton@kernel.org>
Thanks,
Oliver
> ---
> arch/arm64/kvm/nested.c | 36 +++++++++++++++---------------------
> 1 file changed, 15 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index f8d3f3a723282..690b8e8564166 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -908,9 +908,21 @@ static void invalidate_vncr(struct vncr_tlb *vt)
> clear_fixmap(vncr_fixmap(vt->cpu));
> }
>
> +/*
> + * VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and
> + * either can race against a vcpu not being onlined yet (no pseudo-TLB
> + * allocated). Similarly, the TLB might be invalid. Skip those, as they
> + * obviously don't participate in the invalidation at this stage.
> + */
> +#define kvm_for_each_vncr_tlb(idx, vcpup, tlbp, kvm) \
> + kvm_for_each_vcpu(idx, vcpup, kvm) \
> + if (((tlbp) = vcpup->arch.vncr_tlb) && \
> + (tlbp)->valid)
> +
> static void kvm_invalidate_vncr_ipa(struct kvm *kvm, u64 start, u64 end)
> {
> struct kvm_vcpu *vcpu;
> + struct vncr_tlb *vt;
> unsigned long i;
>
> lockdep_assert_held_write(&kvm->mmu_lock);
> @@ -918,24 +930,9 @@ static void kvm_invalidate_vncr_ipa(struct kvm *kvm, u64 start, u64 end)
> if (!kvm_has_feat(kvm, ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY))
> return;
>
> - kvm_for_each_vcpu(i, vcpu, kvm) {
> - struct vncr_tlb *vt = vcpu->arch.vncr_tlb;
> + kvm_for_each_vncr_tlb(i, vcpu, vt, kvm) {
> u64 ipa_start, ipa_end, ipa_size;
>
> - /*
> - * Careful here: We end-up here from an MMU notifier,
> - * and this can race against a vcpu not being onlined
> - * yet, without the pseudo-TLB being allocated.
> - *
> - * Skip those, as they obviously don't participate in
> - * the invalidation at this stage.
> - */
> - if (!vt)
> - continue;
> -
> - if (!vt->valid)
> - continue;
> -
> ipa_size = ttl_to_size(pgshift_level_to_ttl(vt->wi.pgshift,
> vt->wr.level));
> ipa_start = vt->wr.pa & ~(ipa_size - 1);
> @@ -965,17 +962,14 @@ static void invalidate_vncr_va(struct kvm *kvm,
> struct s1e2_tlbi_scope *scope)
> {
> struct kvm_vcpu *vcpu;
> + struct vncr_tlb *vt;
> unsigned long i;
>
> lockdep_assert_held_write(&kvm->mmu_lock);
>
> - kvm_for_each_vcpu(i, vcpu, kvm) {
> - struct vncr_tlb *vt = vcpu->arch.vncr_tlb;
> + kvm_for_each_vncr_tlb(i, vcpu, vt, kvm) {
> u64 va_start, va_end, va_size;
>
> - if (!vt->valid)
> - continue;
> -
> va_size = ttl_to_size(pgshift_level_to_ttl(vt->wi.pgshift,
> vt->wr.level));
> va_start = vt->gva & ~(va_size - 1);
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Hold kvm->mmu_lock while initialising vcpu->arch.vncr_tlb
From: Oliver Upton @ 2026-06-08 16:34 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, kvm, linux-arm-kernel, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Zenghui Yu
In-Reply-To: <20260608081108.2244133-1-maz@kernel.org>
On Mon, Jun 08, 2026 at 09:11:08AM +0100, Marc Zyngier wrote:
> Sashiko reports that there is a race between initialising vncr_tlb
> and making use of it, as we don't hold the mmu_lock at this point.
>
> Additionally, it identifies a memory leak, should userspace repeatedly
> invokes the KVM_RUN ioctl after a failure of kvm_arch_vcpu_run_pid_change(),
> as we assign vncr_tlb blindly on first run, irrespective of prior
> allocations.
>
> Slap the two bugs in one go by taking the kvm->mmu_lock on assigning
> vncr_tlb, preventing the race for good, and by checking that vncr_tlb
> is indeed NULL prior to allocation.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/r/20260607180815.85FBC1F00893@smtp.kernel.org
Reviewed-by: Oliver Upton <oupton@kernel.org>
Thanks,
Oliver
> ---
> arch/arm64/kvm/nested.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 690b8e8564166..d11e36b3cfcc2 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -1253,8 +1253,14 @@ int kvm_vcpu_allocate_vncr_tlb(struct kvm_vcpu *vcpu)
> if (!kvm_has_feat(vcpu->kvm, ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY))
> return 0;
>
> - vcpu->arch.vncr_tlb = kzalloc_obj(*vcpu->arch.vncr_tlb,
> - GFP_KERNEL_ACCOUNT);
> + if (!vcpu->arch.vncr_tlb) {
> + struct vncr_tlb *vt = kzalloc_obj(*vcpu->arch.vncr_tlb,
> + GFP_KERNEL_ACCOUNT);
> +
> + scoped_guard(write_lock, &vcpu->kvm->mmu_lock)
> + vcpu->arch.vncr_tlb = vt;
> + }
> +
> if (!vcpu->arch.vncr_tlb)
> return -ENOMEM;
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2 4/6] ACPI: irq: Move RISC-V interrupt controllers autodep to ACPI IRQ code
From: Sunil V L @ 2026-06-08 16:38 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260603-gic-v5-acpi-iwb-probe-deferral-v2-4-23ffa16b6ebb@kernel.org>
On Wed, Jun 3, 2026 at 1:54 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> RISC-V implements arch code to detect probe dependencies for devices and
> the interrupt controller the devices GSIs are routed to.
>
> The code itself is arch agnostic apart from an arch specific helper
> function required to retrieve the acpi_handle of the interrupt controller
> that manages the device GSI interrupt.
>
> In order to enable IRQ probe dependencies detection on other architectures,
> move RISC-V IRQ probe dependency detection code to generic ACPI IRQ code.
>
> Allow interrupt controller drivers to register an arch specific function to
> determine the acpi_handle for a specific GSI number to use the mechanism if
> needed by the respective interrupt controller drivers.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Anup Patel <anup@brainfault.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> Cc: Marc Zyngier <maz@kernel.org>
> ---
> arch/riscv/include/asm/acpi.h | 1 +
> drivers/acpi/irq.c | 172 +++++++++++++++++++++++++++++++++++-
> drivers/acpi/riscv/irq.c | 156 +-------------------------------
> drivers/irqchip/irq-gic-v3.c | 2 +-
> drivers/irqchip/irq-gic-v5.c | 2 +-
> drivers/irqchip/irq-gic.c | 2 +-
> drivers/irqchip/irq-loongarch-cpu.c | 2 +-
> drivers/irqchip/irq-riscv-intc.c | 3 +-
> include/linux/acpi.h | 5 +-
> 9 files changed, 181 insertions(+), 164 deletions(-)
>
LGTM.
Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Ethan Nelson-Moore @ 2026-06-08 16:40 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Dmitry Torokhov, Jiri Slaby,
Russell King (Oracle), Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weissschuh,
Peter Zijlstra
In-Reply-To: <CAD++jLmUW4KjxEjwv7_an_dEMTSOtvG=q2MjhqKvnuGrWaaCsQ@mail.gmail.com>
Hi, Linus,
On Mon, Jun 8, 2026 at 1:50 AM Linus Walleij <linusw@kernel.org> wrote:
> Have you tested this on real hardware?
> The commit doesn't really say.
No, I haven't. I can try to test it in GXemul, but I'm not sure if it
can boot Linux. The developer only lists it as capable of booting
NetBSD.
Ethan
^ permalink raw reply
* Re: [RFC PATCH 2/2] firmware: arm_scmi: Add bus support for autoloading
From: Cristian Marussi @ 2026-06-08 16:51 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Cristian Marussi, arm-scmi, guomin_chen, linux-arm-kernel,
peng.fan, quic_xinqzhan, sudeep.holla
In-Reply-To: <aibW10NMmzw3QnZ5@mai.linaro.org>
On Mon, Jun 08, 2026 at 04:51:03PM +0200, Daniel Lezcano wrote:
> On Mon, Feb 03, 2025 at 10:01:54AM +0000, Cristian Marussi wrote:
> > Emit proper MODALIAS uevents when SCMI devices are created and make sure
> > all the standard protocol devices are requested when the bus is
> > initialized.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
>
> Hi Cristian,
>
Hi Daniel,
nice to hear from you in the SCMI land :P
> what is the status of this patch ?
....I'd say forgotten/abandoned...I worked on that a bit when I realized
only part of the stack was autoloaded...then it did NOT received much
love and then I forgot it....buried by other prios....
Indeed I have still the local branch...but after a quick check I think
is the same as the RFC posted.
bbd14b0f7733 firmware: arm_scmi: Add bus support for autoloading
8d982393b505 firmware: arm_scmi: Generate aliases for SCMI modules
383c127faa97 (scmi_vendors_autoload_V2) firmware: arm_scmi: Add aliases to transport modules
00caa894bce2 firmware: arm_scmi: Add module aliases to i.MX vendor protocols
d900620c46bb firmware: arm_scmi: Support vendor protocol modules autoloading
4fe57bbeb6dc firmware: arm_scmi: Allow transport properties for multiple instances
ad236e5a7f01 Linux 6.13-rc1
...where scmi_vendors_autoload_V2 is merged already...
Thoughts ? Plans ?
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v3] coresight: etm3x: Fix cntr_val_show() to match cntr_val_store() behavior
From: Kuan-Wei Chiu @ 2026-06-08 16:55 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: James Clark, mike.leach, alexander.shishkin, gregkh,
mathieu.poirier, leo.yan, Al.Grant, jserv, marscheng, ericchancf,
milesjiang, nickpan, coresight, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <ac-BEX0Rfe9RBJJn@google.com>
Hi Suzuki,
On Fri, Apr 03, 2026 at 04:57:59PM +0800, Kuan-Wei Chiu wrote:
> Hi Suzuki,
>
> On Mon, Feb 02, 2026 at 09:33:59AM +0000, Suzuki K Poulose wrote:
> > Hello
> >
> > On 02/02/2026 05:09, Kuan-Wei Chiu wrote:
> > > On Tue, Dec 02, 2025 at 09:26:19AM +0000, James Clark wrote:
> > > >
> > > >
> > > > On 02/12/2025 8:26 am, Kuan-Wei Chiu wrote:
> > > > > The cntr_val_show() function was intended to print the values of all
> > > > > counters using a loop. However, due to a buffer overwrite issue with
> > > > > sprintf(), it effectively only displayed the value of the last counter.
> > > > >
> > > > > The companion function, cntr_val_store(), allows users to modify a
> > > > > specific counter selected by 'cntr_idx'. To maintain consistency
> > > > > between read and write operations and to align with the ETM4x driver
> > > > > behavior, modify cntr_val_show() to report only the value of the
> > > > > currently selected counter.
> > > > >
> > > > > This change removes the loop and the "counter %d:" prefix, printing
> > > > > only the hexadecimal value. It also adopts sysfs_emit() for standard
> > > > > sysfs output formatting.
> > > > >
> > > > > Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver")
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> > > > > ---
> > > > > Build test only.
> > > > >
> > > > > Changes in v3:
> > > > > - Switch format specifier to %#x to include the 0x prefix.
> > > > > - Add Cc stable
> > > > >
> > > > > v2: https://lore.kernel.org/lkml/20251201095228.1905489-1-visitorckw@gmail.com/
> > > > >
> > > > > .../hwtracing/coresight/coresight-etm3x-sysfs.c | 15 ++++-----------
> > > > > 1 file changed, 4 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> > > > > index 762109307b86..b3c67e96a82a 100644
> > > > > --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> > > > > +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> > > > > @@ -717,26 +717,19 @@ static DEVICE_ATTR_RW(cntr_rld_event);
> > > > > static ssize_t cntr_val_show(struct device *dev,
> > > > > struct device_attribute *attr, char *buf)
> > > > > {
> > > > > - int i, ret = 0;
> > > > > u32 val;
> > > > > struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > > > > struct etm_config *config = &drvdata->config;
> > > > > if (!coresight_get_mode(drvdata->csdev)) {
> > > > > spin_lock(&drvdata->spinlock);
> > > > > - for (i = 0; i < drvdata->nr_cntr; i++)
> > > > > - ret += sprintf(buf, "counter %d: %x\n",
> > > > > - i, config->cntr_val[i]);
> > > > > + val = config->cntr_val[config->cntr_idx];
> > > > > spin_unlock(&drvdata->spinlock);
> > > > > - return ret;
> > > > > - }
> > > > > -
> > > > > - for (i = 0; i < drvdata->nr_cntr; i++) {
> > > > > - val = etm_readl(drvdata, ETMCNTVRn(i));
> > > > > - ret += sprintf(buf, "counter %d: %x\n", i, val);
> > > > > + } else {
> > > > > + val = etm_readl(drvdata, ETMCNTVRn(config->cntr_idx));
> > > > > }
> > > > > - return ret;
> > > > > + return sysfs_emit(buf, "%#x\n", val);
> > > > > }
> > > > > static ssize_t cntr_val_store(struct device *dev,
> > > >
> > > > Reviewed-by: James Clark <james.clark@linaro.org>
> > > >
> > > Thanks for the review!
> > > Is there anything else I need to do for this fix to land?
> >
> > Thanks for the patch, I will queue this for the next release (v7.1).
> >
> Just a gentle ping.
>
> Since the v7.1 merge window is presumably opening in about a week, I
> noticed this patch isn't in linux-next yet and wanted to send a quick
> reminder. Thanks.
>
This patch still applies cleanly on top of linux-next.
I suspect this patch may have fallen through the cracks.
Would you still be willing to pick it up?
Regards,
Kuan-Wei
^ permalink raw reply
* [PATCH v2 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Remove the FFA_NOTIFICATION* calls from the blocklist used by the pKVM
FF-A proxy. This restriction was preventing the use of asynchronous
signaling mechanisms defined by the Arm FF-A specification to
communicate with the secure services.
While these calls are markes as optional, there is no reason why the
hypervisor proxy would block them because:
1. Host is the Sole Non-Secure Endpoint: The Host operates as the
only Non-Secure VM ID (VM ID 0) recognized by the Secure World.
Because all forwarded notifications are inherently attributed to
the Host by the SPMC, there is no risk of VM ID spoofing
originating from the Normal World.
2. No Memory Pointers or Addresses: The FFA_NOTIFICATION_* ABIs
operate strictly via register-based parameters, passing only
VM IDs, VCPU IDs, flags, and bitmaps. Because these calls do
not contain memory addresses, offsets, or pointers, forwarding
them doesn't pose a risk of memory-based confused deputy attack
(e.g., tricking the SPMC into overwriting protected memory).
While the pKVM proxy behaves as a relayer, it doesn't currently have its
own FF-A ID(only the host has the ID 0). The behavior of the setup
flow is covered by the spec in the: '10.9 Notification support without
a Hypervisor'.
---
Changes in v2:
- enforce the MBZ/SBZ fields
- split the calls into separate patches
- rebase on 7.1-rc7
Link to v1:
https://lore.kernel.org/all/20260501114447.2389222-2-sebastianene@google.com/
Sebastian Ene (7):
KVM: arm64: Support FFA_NOTIFICATION_BITMAP_CREATE in host handler
KVM: arm64: Support FFA_NOTIFICATION_BITMAP_DESTROY in host handler
KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
KVM: arm64: Support FFA_NOTIFICATION_UNBIND in host handler
KVM: arm64: Support FFA_NOTIFICATION_SET in host handler
KVM: arm64: Support FFA_NOTIFICATION_GET in host handler
KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
arch/arm64/kvm/hyp/nvhe/ffa.c | 190 ++++++++++++++++++++++++++++++++--
1 file changed, 182 insertions(+), 8 deletions(-)
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply
* [PATCH v2 1/7] KVM: arm64: Support FFA_NOTIFICATION_BITMAP_CREATE in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Allow FF-A notification bitmap creation messages to be forwarded to
Trustzone from the host and introduce a helper to check for SBZ
register fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 36 ++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 1af722771178..c20d45191085 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -71,6 +71,18 @@ static u32 hyp_ffa_version;
static bool has_version_negotiated;
static hyp_spinlock_t version_lock;
+static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
+{
+ int reg;
+
+ for (reg = first_reg; reg < 17; reg++) {
+ if (cpu_reg(ctxt, reg))
+ return true;
+ }
+
+ return false;
+}
+
static void ffa_to_smccc_error(struct arm_smccc_1_2_regs *res, u64 ffa_errno)
{
*res = (struct arm_smccc_1_2_regs) {
@@ -676,7 +688,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_BITMAP_CREATE:
case FFA_NOTIFICATION_BITMAP_DESTROY:
case FFA_NOTIFICATION_BIND:
case FFA_NOTIFICATION_UNBIND:
@@ -862,6 +873,26 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
hyp_spin_unlock(&host_buffers.lock);
}
+static void do_ffa_notif_bitmap_create(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, vmid, ctxt, 1);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 3)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (vmid != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -920,6 +951,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_PARTITION_INFO_GET:
do_ffa_part_get(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_BITMAP_CREATE:
+ do_ffa_notif_bitmap_create(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* [PATCH v2 5/7] KVM: arm64: Support FFA_NOTIFICATION_SET in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Allow FF-A notification SET messages to be proxied from the pKVM
hypervisor to Trustzone and enforce MBZ/SBZ fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index ca285e89516e..3270381679b4 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -690,7 +690,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_SET:
case FFA_NOTIFICATION_GET:
case FFA_NOTIFICATION_INFO_GET:
/* Optional interfaces added in FF-A 1.2 */
@@ -959,6 +958,32 @@ static void do_ffa_notif_unbind(struct arm_smccc_1_2_regs *res,
arm_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_set(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, flags, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (flags & GENMASK(15, 2)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1029,6 +1054,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_UNBIND:
do_ffa_notif_unbind(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_SET:
+ do_ffa_notif_set(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* [PATCH v2 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Verify the arguments of the FF-A notification bind call and forward the
message to Trustzone.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 91e89d889c44..eedb01955a45 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -42,6 +42,8 @@
*/
#define HOST_FFA_ID 0
+#define FFA_NOTIF_SENDER_ENDP_MASK GENMASK(31, 16)
+
/*
* A buffer to hold the maximum descriptor size we can see from the host,
* which is required when the SPMD returns a fragmented FFA_MEM_RETRIEVE_RESP
@@ -688,7 +690,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_BIND:
case FFA_NOTIFICATION_UNBIND:
case FFA_NOTIFICATION_SET:
case FFA_NOTIFICATION_GET:
@@ -912,6 +913,32 @@ static void do_ffa_notif_bitmap_destroy(struct arm_smccc_1_2_regs *res,
arm_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_bind(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, flags, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (flags & GENMASK(31, 1)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -976,6 +1003,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_BITMAP_DESTROY:
do_ffa_notif_bitmap_destroy(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_BIND:
+ do_ffa_notif_bind(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* [PATCH v2 4/7] KVM: arm64: Support FFA_NOTIFICATION_UNBIND in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Verify the arguments of the FF-A notification unbind call and forward
the message to Trustzone.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index eedb01955a45..ca285e89516e 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -690,7 +690,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_UNBIND:
case FFA_NOTIFICATION_SET:
case FFA_NOTIFICATION_GET:
case FFA_NOTIFICATION_INFO_GET:
@@ -939,6 +938,27 @@ static void do_ffa_notif_bind(struct arm_smccc_1_2_regs *res,
arm_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_unbind(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, reserved, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 5) || reserved) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1006,6 +1026,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_BIND:
do_ffa_notif_bind(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_UNBIND:
+ do_ffa_notif_unbind(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
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