* Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-01 11:03 UTC (permalink / raw)
To: Guangliu Ding, Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB4707D758EC8B08C6D42F3A82F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On 01/04/2026 13:01, Guangliu Ding wrote:
> Hi Krzysztof
>
>> On 01/04/2026 12:31, Guangliu Ding wrote:
>>>> Either add the patch(es) that use the compatible to this series in
>>>> v2, or put a comment in the commit message on where we can see the
>> driver changes.
>>>>
>>>
>>> According to discussions with the GPU vendor, this is a hardware
>>> limitation of Mali-G310 rather than a hardware bug, and it has been
>>> addressed in newer Mali GPU families.
>>>
>>> In addition, ipa_counters are not enabled in the current Panthor
>>> driver. We observed this issue with the private Mali DDK where ipa_counters
>> were enabled.
>>> Therefore, keeping the compatible string is necessary to allow for future
>> divergence.
>>
>> No one discusses here whether you need separate compatible string.
>> writing bindings and all my talks are (e.g. DTS 101) are clearly expecting you.
>>
>> We discuss only the lack of compatibility in terms of DT, how DT sees
>> compatible devices.
>>
>> And lack of driver code is clear indication that devices are compatible in terms
>> how DT understands it. Feel encouraged to bring actual arguments in commit
>> msgs in the future.
>>
>> Best regards,
>> Krzysztof
>
> So the best approach is only reserve "arm,mali-valhall-csf" for now, since currently there is
> no need for an additional compatible entry from a DT compatibility perspective.
> We can introduce "nxp,imx952-mali" in future commits if hardware or driver differences
> actually require it, and include more detailed justification in the commit message. Right?
So does that mean you decided not to read writing bindings document?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Krzysztof Kozlowski @ 2026-04-01 11:12 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君]
Cc: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <8a4f558fdc6649be8c6239403e706621@realtek.com>
On 01/04/2026 13:10, Yu-Chun Lin [林祐君] wrote:
>>> + compatible = "realtek,rtd1625-isom-gpio";
>>> + reg = <0x89120 0x10>,
>>
>> 0x10 feels very short range.
>>
>>> + <0x89100 0x20>;
>>
>> And this means it's continuous. Are you sure these are two separate address
>> spaces?
>>
>> Best regards,
>> Krzysztof
>
> Agreed, they are continuous. I will merge them into a single region in v2.
I assume you checked in the datasheet/manual.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 1/3] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Yu-Chun Lin [林祐君] @ 2026-04-01 11:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <20260401-idealistic-grinning-wallaby-8c3cd5@quoll>
> On Tue, Mar 31, 2026 at 07:38:33PM +0800, Yu-Chun Lin wrote:
> > + reg:
> > + items:
> > + - description: GPIO controller registers
> > + - description: GPIO interrupt registers
> > +
> > + interrupts:
> > + items:
> > + - description: Interrupt number of the assert GPIO interrupt, which
> is
> > + triggered when there is a rising edge.
> > + - description: Interrupt number of the deassert GPIO interrupt,
> which is
> > + triggered when there is a falling edge.
> > + - description: Interrupt number of the level-sensitive GPIO interrupt,
> > + triggered by a configured logic level.
> > +
> > + interrupt-controller: true
> > +
> > + "#interrupt-cells":
> > + const: 2
> > +
> > + gpio-ranges: true
> > +
> > + gpio-controller: true
> > +
> > + "#gpio-cells":
> > + const: 2
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - gpio-ranges
> > + - gpio-controller
> > + - "#gpio-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + gpio@89120 {
> > + compatible = "realtek,rtd1625-isom-gpio";
> > + reg = <0x89120 0x10>,
>
> 0x10 feels very short range.
>
> > + <0x89100 0x20>;
>
> And this means it's continuous. Are you sure these are two separate address
> spaces?
>
> Best regards,
> Krzysztof
Agreed, they are continuous. I will merge them into a single region in v2.
Best regards,
Yu-Chun
^ permalink raw reply
* [PATCH] clk: bcm: rpi: Mark VEC clock as CLK_IGNORE_UNUSED
From: Maíra Canal @ 2026-04-01 11:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Florian Fainelli,
Broadcom internal kernel review list, Mark Brown, Maxime Ripard,
Stefan Wahren, Dom Cobley, Dave Stevenson
Cc: linux-clk, linux-rpi-kernel, linux-arm-kernel, kernel-dev,
Maíra Canal
On Raspberry Pi 3B, the VEC clock is used by the VideoCore firmware
display driver, which remains active until the vc4 driver loads and
sends NOTIFY_DISPLAY_DONE. If this clock is disabled during boot, a bus
lockup happens and the firmware becomes unresponsive, causing a complete
system lockup.
Mark the VEC clock with CLK_IGNORE_UNUSED so it survives the unused
clock disablement and remains available until the vc4 driver takes over
display management.
Fixes: 672299736af6 ("clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks")
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
---
drivers/clk/bcm/clk-raspberrypi.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index df2d246eb6ef..f1a99de6de4f 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -160,6 +160,13 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = {
[RPI_FIRMWARE_VEC_CLK_ID] = {
.export = true,
.minimize = true,
+
+ /*
+ * If this clock is disabled during boot, it causes a bus
+ * lockup in RPi 3B. Therefore, make sure it's left enabled
+ * during boot.
+ */
+ .flags = CLK_IGNORE_UNUSED,
},
[RPI_FIRMWARE_DISP_CLK_ID] = {
.export = true,
--
2.53.0
^ permalink raw reply related
* [PATCH] firmware: arm_ffa: Use the correct buffer size during RXTX_MAP
From: Sebastian Ene @ 2026-04-01 11:17 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, android-kvm; +Cc: sudeep.holla, Sebastian Ene
Don't use the discovered buffer size from an FFA_FEATURES call directly
since we can run on a system that has the PAGE_SIZE larger than the
returned size which makes the alloc_pages_exact for the buffer to be
rounded up.
Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()")
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index f2f94d4d533e..d0c926aca120 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2078,7 +2078,7 @@ static int __init ffa_init(void)
ret = ffa_rxtx_map(virt_to_phys(drv_info->tx_buffer),
virt_to_phys(drv_info->rx_buffer),
- rxtx_bufsz / FFA_PAGE_SIZE);
+ DIV_ROUND_UP(rxtx_bufsz, PAGE_SIZE) / FFA_PAGE_SIZE);
if (ret) {
pr_err("failed to register FFA RxTx buffers\n");
goto free_pages;
--
2.53.0.1185.g05d4b7b318-goog
^ permalink raw reply related
* Re: [GIT PULL 2/2] Broadcom devicetree-arm64 changes for 7.1
From: Krzysztof Kozlowski @ 2026-04-01 11:18 UTC (permalink / raw)
To: Florian Fainelli
Cc: soc, Rob Herring, Gregor Herburger, Maíra Canal,
Stefan Wahren, linux-arm-kernel, arnd, khilman,
bcm-kernel-feedback-list
In-Reply-To: <20260323190239.1890505-2-florian.fainelli@broadcom.com>
On Mon, Mar 23, 2026 at 12:02:39PM -0700, Florian Fainelli wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-7.1/devicetree-arm64
>
> for you to fetch changes up to 0acb1de2b4df426a62dba33bcd80f3939636f97b:
>
> arm64: dts: broadcom: bcm2712: Move non simple-bus nodes to root level (2026-03-20 10:17:30 -0700)
Patches were good, I wanted to merge them, but then merge complained:
Can't check signature: No public key
I refreshed now my keyring with kernel.org and the same.
I think the same issue was last time and repo is non korg, so nothing
seems to improve.
I am moving on.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 2/3] arm64: dts: realtek: Add GPIO support for RTD1625
From: Yu-Chun Lin [林祐君] @ 2026-04-01 11:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <20260401-liberal-nondescript-muskrat-0ebe93@quoll>
> On Tue, Mar 31, 2026 at 07:38:34PM +0800, Yu-Chun Lin wrote:
> > Add the GPIO node for the Realtek RTD1625 SoC.
> >
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > arch/arm64/boot/dts/realtek/kent.dtsi | 43
> ++++++++++++++++++++++++
> > arch/arm64/boot/dts/realtek/rtd1501.dtsi | 8 +++++
> > arch/arm64/boot/dts/realtek/rtd1861.dtsi | 8 +++++
> > arch/arm64/boot/dts/realtek/rtd1920.dtsi | 8 +++++
> > 4 files changed, 67 insertions(+)
> >
>
> Why the DTS is in the middle? Drivers cannot depend on it. Please read
> submitting patches (both documents).
>
I will move DTS to the end in v2.
> > diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi
> > b/arch/arm64/boot/dts/realtek/kent.dtsi
> > index 8d4293cd4c03..746932c26724 100644
> > --- a/arch/arm64/boot/dts/realtek/kent.dtsi
> > +++ b/arch/arm64/boot/dts/realtek/kent.dtsi
> > @@ -151,6 +151,39 @@ uart0: serial@7800 {
> > status = "disabled";
> > };
> >
> > + gpio: gpio@31100 {
> > + compatible = "realtek,rtd1625-iso-gpio";
> > + reg = <0x31100 0x398>,
> > + <0x31000 0x100>;
> > + gpio-controller;
> > + gpio-ranges = <&isom_pinctrl 0 0 2>,
> > + <&ve4_pinctrl 2 0 6>,
> > + <&iso_pinctrl 8 0 4>,
> > + <&ve4_pinctrl 12 6 2>,
> > + <&main2_pinctrl 14 0
> 2>,
> > + <&ve4_pinctrl 16 8 4>,
> > + <&main2_pinctrl 20 2
> 3>,
> > + <&ve4_pinctrl 23 12
> 3>,
> > + <&iso_pinctrl 26 4 2>,
> > + <&isom_pinctrl 28 2
> 2>,
> > + <&ve4_pinctrl 30 15
> 6>,
> > + <&main2_pinctrl 36 5
> 6>,
> > + <&ve4_pinctrl 42 21
> 3>,
> > + <&iso_pinctrl 45 6 6>,
> > + <&ve4_pinctrl 51 24
> 1>,
> > + <&iso_pinctrl 52 12
> 1>,
> > + <&ve4_pinctrl 53 25
> 11>,
> > + <&main2_pinctrl 64
> 11 28>,
> > + <&ve4_pinctrl 92 36
> 2>,
> > + <&iso_pinctrl 94 13
> 19>,
> > + <&iso_pinctrl 128 32
> 4>,
> > + <&ve4_pinctrl 132 38
> 13>,
> > + <&iso_pinctrl 145 36
> 19>,
> > + <&ve4_pinctrl 164 51
> 2>;
> > + #gpio-cells = <2>;
> > + status = "disabled";
>
> Why is it disabled? What is missing in the SoC? Which resources are missing?
>
Nothing is missing, so I will remove status = "disabled".
> > + };
> > +
> > iso_pinctrl: pinctrl@4e000 {
> > compatible =
> "realtek,rtd1625-iso-pinctrl";
> > reg = <0x4e000 0x1a4>; @@ -161,6
> +194,16
> > @@ main2_pinctrl: pinctrl@4f200 {
> > reg = <0x4f200 0x50>;
> > };
> >
> > + iso_m_gpio: gpio@89120 {
> > + compatible =
> "realtek,rtd1625-isom-gpio";
> > + reg = <0x89120 0x10>,
> > + <0x89100 0x20>;
> > + gpio-controller;
> > + gpio-ranges = <&isom_pinctrl 0 0 4>;
> > + #gpio-cells = <2>;
> > + status = "disabled";
> > + };
> > +
> > isom_pinctrl: pinctrl@146200 {
> > compatible =
> "realtek,rtd1625-isom-pinctrl";
> > reg = <0x146200 0x34>; diff --git
> > a/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > b/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > index 65f7ede3df73..ae246a01f126 100644
> > --- a/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > +++ b/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > @@ -10,3 +10,11 @@
> > &uart0 {
> > status = "okay";
> > };
> > +
> > +&gpio {
>
> Why aren't you following DTS coding style? What style is applicable for
> Realtek?
>
> Best regards,
> Krzysztof
I should sort them in alphabetical order. But after removing the status property,
the board-level node will be removed entirely.
Best regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH v6 0/2] TQ-Systems TQMa62xx SoM and MBa62xx board
From: Nora Schiffer @ 2026-04-01 11:22 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kees Cook,
Tony Luck, Guilherme G. Piccoli, linux-arm-kernel, devicetree,
linux-kernel, linux
In-Reply-To: <6e34ecefae8e2f187c5ecfdfd343fb717711c21d.camel@ew.tq-group.com>
On Tue, 2026-03-17 at 10:08 +0100, Nora Schiffer wrote:
> On Mon, 2026-03-02 at 11:14 +0100, Nora Schiffer wrote:
> > This adds Device Trees for our AM62x-based SoM TQMa62xx and its
> > reference carrier board MBa62xx.
> >
> > Not yet included are overlays to enable LVDS display output and MIPI-CSI
> > camera input.
>
> Hi Nishanth,
>
> do you have any further comments on these patches? Can we get the series into
> v7.1?
>
> Best,
> Nora
Hi Vignesh,
ti-k3-dt-for-v7.1 is tagged now, does that mean we missed the window to get this
series applied again? If there are still any issues, I'll gladly fix them up,
but we have not received any review comments on this last revision of the
patches.
Best,
Nora
>
>
>
>
> >
> > Changed in v6:
> > - Update author information following name change
> > - Rebase onto latest ti-k3-dts-next
> > - Disable incomplete panel node
> > - Add various comments to explain why nodes are disabled
> > - Extend comment explaining disabled 1400MHz OPP
> > - Use consistent comment style for pinmux
> >
> > Changes in v5:
> > - Rebase onto latest ti-k3-dts-next
> >
> > Changes in v4:
> > - Rebase onto latest ti-k3-dts-next
> > - Reorder boot phase tags after other standard DT properties
> > - Add missing supply regulators in SPI-NOR flash and USB hub
> > - Set status = "okay" in &cpsw3g, as it is disabled in k3-am62-main.dtsi
> > now
> > - Add disabled 1400MHz OPP entry (will be enabled by bootloader if
> > supported by PMIC configuration)
> > - Update copyright years in new files
> >
> > Changes in v3:
> > - Rebased onto ti-k3-dt-for-v6.18
> > - 3 of the 5 patches in v2 have been applied already and are dropped
> > - Include k3-am62-ti-ipc-firmware.dtsi, drop now redundant configuration
> > - Change node name for MCU reserved memory to 'memory'
> > - Use rgmii-id PHY mode
> > - Drop now redundant ti,rx-internal-delay
> > - Update simple-audio-card,name to match other TQ SOMs with compatible
> > configuration
> > - Reference dss_pins in dss node (actual display support will be added
> > in a follow-up patch series)
> > - Consistently use GPIO_ACTIVE_HIGH define
> > - Drop unneeded usb0 quirk flags
> > - Add boot phase tags
> >
> > Changes in v2:
> > - Collected acks and reviews
> > - Rebased onto v6.13-rc1
> >
> >
> > Nora Schiffer (2):
> > dt-bindings: arm: ti: Add compatible for AM625-based TQMa62xx SOM
> > family and carrier board
> > arm64: dts: ti: Add TQ-Systems TQMa62xx SoM and MBa62xx carrier board
> > Device Trees
> >
> > .../devicetree/bindings/arm/ti/k3.yaml | 7 +
> > arch/arm64/boot/dts/ti/Makefile | 1 +
> > .../boot/dts/ti/k3-am625-tqma62xx-mba62xx.dts | 1034 +++++++++++++++++
> > arch/arm64/boot/dts/ti/k3-am625-tqma62xx.dtsi | 360 ++++++
> > 4 files changed, 1402 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/ti/k3-am625-tqma62xx-mba62xx.dts
> > create mode 100644 arch/arm64/boot/dts/ti/k3-am625-tqma62xx.dtsi
> >
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* [PATCH v3 1/2] arm64: dts: ti: k3-am62-lp-sk: Add system-power-controller
From: Akashdeep Kaur @ 2026-04-01 11:22 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy
Cc: vishalm, sebin.francis, d-gole, k-willis, a-kaur
In-Reply-To: <20260401112257.1248437-1-a-kaur@ti.com>
On AM62-LP-SK, the TPS65219 PMIC is the system power controller
responsible for handling system poweroff. Add the "system-power-controller"
property to the PMIC node to explicitly designate it as such.
Among all in-tree device trees using the TPS65219 PMIC (verified via
compatible string), AM62-LP-SK was the only one missing this property.
This patch corrects that omission.
This property will be used by the PMIC driver to conditionally register
the poweroff handler, ensuring only the designated power controller
registers for system poweroff operations.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts b/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts
index 3e2d8f669535..786a7d695b33 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts
@@ -206,6 +206,7 @@ tps65219: pmic@30 {
interrupt-parent = <&gic500>;
interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ system-power-controller;
regulators {
buck1_reg: buck1 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Pranjal Shrivastava @ 2026-04-01 11:23 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
Jon Hunter, patches, Robin Murphy, Samiullah Khawaja, stable,
Vasant Hegde
In-Reply-To: <0-v1-664d3acaabb9+78b-iommu_gather_always_jgg@nvidia.com>
On Tue, Mar 31, 2026 at 04:56:22PM -0300, Jason Gunthorpe wrote:
> The fixed commit assumed that the gather would always be populated if
> an iotlb_sync was required.
>
> arm-smmu-v3, amd, VT-d, riscv, s390, mtk all use information from the
> gather during their iotlb_sync() and this approach works for them.
>
> However, arm-smmu, qcom_iommu, ipmmu-vmsa, sun50i, sprd, virtio,
> apple-dart all ignore the gather during their iotlb_sync(). They
> mostly issue a full flush.
>
> Unfortunately the latter set of drivers often don't bother to add
> anything to the gather since they don't intend on using it. Since the
> core code now blocks gathers that were never filled, this caused those
> drivers to stop getting their iotlb_sync() calls and breaks them.
>
> Since it is impossible to tell the difference between gathers that are
> empty because there is nothing to do and gathers that are empty
> because they are not used, fill in the gathers for the missing cases.
>
I believe the problem is a fundamental disagreement between the core
layer and these drivers. The core assumes an empty gather means there
is no work to do, while these drivers expect a sync regardless. With
this, it seems we're forcing the drivers to lie to the core by
populating a gather they don't actually use just to trigger the sync.
I was wondering if, as a longer-term direction, having an explicit flag
for these drivers to indicate they always require a sync would be a
cleaner way to handle this than the trivial population?
Just a thought, not a hard disagreement with the current approach..
> io-pgtable might have intended to allow the driver to choose between
> gather or immediate flush because it passed gather to
> ops->tlb_add_page(), however no driver does anything with it.
>
> mtk uses io-pgtable-arm-v7s but added the range to the gather in the
> unmap callback. Move this into the io-pgtable-arm unmap itself. That
> will fix all the armv7 using drivers (arm-smmu, qcom_iommu,
> ipmmu-vmsa).
>
> arm-smmu uses both ARM_V7S and ARM LPAE formats. The LPAE formats
> already have the gather population because SMMUv3 requires it, so it
> becomes consistent.
>
> Add a trivial gather population to io-pgtable-dart.
>
> Add trivial populations to sprd, sun50i and virtio-iommu in their
> unmap functions.
>
> Fixes: 90c5def10bea ("iommu: Do not call drivers for empty gathers")
> Reported-by: Jon Hunter <jonathanh@nvidia.com>
> Closes: https://lore.kernel.org/r/8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 4 +++-
> drivers/iommu/io-pgtable-dart.c | 3 +++
> drivers/iommu/mtk_iommu.c | 1 -
> drivers/iommu/sprd-iommu.c | 1 +
> drivers/iommu/sun50i-iommu.c | 1 +
> drivers/iommu/virtio-iommu.c | 2 ++
> 6 files changed, 10 insertions(+), 2 deletions(-)
>
Acked-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v2 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Akashdeep Kaur @ 2026-04-01 11:24 UTC (permalink / raw)
To: Lee Jones
Cc: praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy, vishalm,
sebin.francis, d-gole, k-willis
In-Reply-To: <20260331101203.GA3795166@google.com>
Hi Lee,
On 31/03/26 15:42, Lee Jones wrote:
> ---
>
> On Tue, 24 Mar 2026, Akashdeep Kaur wrote:
>
>> Currently, the TPS65219 driver unconditionally registers a poweroff
>> handler. This causes issues on systems where a different component
>> (such as TF-A firmware) should handle system poweroff instead.
>>
>> Make the poweroff handler registration conditional based on the
>> "system-power-controller" device tree property. This follows the
>> standard kernel pattern where only the designated power controller
>> registers for system poweroff operations.
>>
>> On systems where the property is absent, the PMIC will not register
>> a poweroff handler, allowing other poweroff mechanisms to function.
>>
>> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
>> ---
>> drivers/mfd/tps65219.c | 14 ++++++++------
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
>> index 7275dcdb7c44..6fa202339a0c 100644
>> --- a/drivers/mfd/tps65219.c
>> +++ b/drivers/mfd/tps65219.c
>> @@ -541,13 +541,15 @@ static int tps65219_probe(struct i2c_client *client)
>> return ret;
>> }
>>
>> - ret = devm_register_power_off_handler(tps->dev,
>> - tps65219_power_off_handler,
>> - tps);
>> - if (ret) {
>> - dev_err(tps->dev, "failed to register power-off handler: %d\n", ret);
>> - return ret;
>> + if (of_device_is_system_power_controller(tps->dev->of_node)) {
>> + ret = devm_register_power_off_handler(tps->dev,
>> + tps65219_power_off_handler,
>> + tps);
>> + if (ret)
>> + return dev_err_probe(tps->dev, ret,
>> + "failed to register power-off handler\n");
>
> Couple of nits to fix.
>
> The `"` should be aligned with the `(` and the `failed` should be capitalised.
Fixed the formatting issues.
>
>> }
>> +
>> return 0;
>> }
>>
>> --
>> 2.34.1
>>
>
Regards,
Akashdeep Kaur
^ permalink raw reply
* Re: [GIT PULL] Reset controller fixes for v7.0, part 2
From: Krzysztof Kozlowski @ 2026-04-01 11:24 UTC (permalink / raw)
To: Philipp Zabel; +Cc: soc, linux-arm-kernel, kernel
In-Reply-To: <39b18202a275168eb4344a2515f7c18723eaf8b0.camel@pengutronix.de>
On Tue, Mar 24, 2026 at 10:55:47AM +0100, Philipp Zabel wrote:
> On Di, 2026-03-24 at 10:42 +0100, Philipp Zabel wrote:
> > Dear arm-soc maintainers,
> >
> > The following changes since commit e0cf84109bc6c6768337123f1de24ff56b41c91b:
> >
> > reset: rzg2l-usbphy-ctrl: Check pwrrdy is valid before using it (2026-02-23 17:03:28 +0100)
> >
> > are available in the Git repository at:
> >
> > https://git.pengutronix.de/git/pza/linux.git tags/reset-fixes-for-v7.0-2
> >
> > for you to fetch changes up to a0e0c2f8c5f32b675f58e25a9338283cedb5ad2b:
> >
> > reset: spacemit: k3: Decouple composite reset lines (2026-03-23 12:25:47 +0100)
> >
> > ----------------------------------------------------------------
> > Reset controller fixes for v7.0, part 2
> >
> > * Decouple spacemit K3 reset lines that were incorrectly coupled
> > together as one, but are in fact separate resets in hardware.
>
> It is important that this makes v7.0, as it fixes an incorrect binding
> that has not been part of a release and which has no users yet.
>
> > * Fix a double free in the reset_add_gpio_aux_device() error path.
> > This has already been fixed on reset/next by commit a9b95ce36de4
> > ("reset: gpio: add a devlink between reset-gpio and its consumer").
>
> Because of this, commit fbffb8c7c7bb ("reset: gpio: fix double free in
> reset_add_gpio_aux_device() error path") introduces a merge conflict
> with reset/next:
>
> https://lore.kernel.org/all/acFRVzvV9Dww47v_@sirena.org.uk/
>
> Should I resolve this myself by merging this tag in to reset/next as
> well, before submitting reset updates for v7.1?
Yes, please merge the fixes to your next branch. Or base next branch on
top of fixes commit, when starting next as new branch.
This merge conflict looks quite significant.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Reset controller fixes for v7.0, part 2
From: Krzysztof Kozlowski @ 2026-04-01 11:26 UTC (permalink / raw)
To: Philipp Zabel; +Cc: soc, linux-arm-kernel, kernel
In-Reply-To: <20260324094255.3538772-1-p.zabel@pengutronix.de>
On Tue, Mar 24, 2026 at 10:42:55AM +0100, Philipp Zabel wrote:
> Dear arm-soc maintainers,
>
> The following changes since commit e0cf84109bc6c6768337123f1de24ff56b41c91b:
>
> reset: rzg2l-usbphy-ctrl: Check pwrrdy is valid before using it (2026-02-23 17:03:28 +0100)
>
> are available in the Git repository at:
>
> https://git.pengutronix.de/git/pza/linux.git tags/reset-fixes-for-v7.0-2
>
> for you to fetch changes up to a0e0c2f8c5f32b675f58e25a9338283cedb5ad2b:
>
> reset: spacemit: k3: Decouple composite reset lines (2026-03-23 12:25:47 +0100)
>
> ----------------------------------------------------------------
> Reset controller fixes for v7.0, part 2
>
> * Decouple spacemit K3 reset lines that were incorrectly coupled
> together as one, but are in fact separate resets in hardware.
> * Fix a double free in the reset_add_gpio_aux_device() error path.
> This has already been fixed on reset/next by commit a9b95ce36de4
> ("reset: gpio: add a devlink between reset-gpio and its consumer").
> * Fix the MODULE_AUTHOR string in the rzg2l-usbphy-ctrl driver.
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* RE: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 11:27 UTC (permalink / raw)
To: Krzysztof Kozlowski, Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <253608f3-8b47-428d-a703-97dcd9731628@kernel.org>
Hi Krzysztof
> On 01/04/2026 13:01, Guangliu Ding wrote:
> > Hi Krzysztof
> >
> >> On 01/04/2026 12:31, Guangliu Ding wrote:
> >>>> Either add the patch(es) that use the compatible to this series in
> >>>> v2, or put a comment in the commit message on where we can see the
> >> driver changes.
> >>>>
> >>>
> >>> According to discussions with the GPU vendor, this is a hardware
> >>> limitation of Mali-G310 rather than a hardware bug, and it has been
> >>> addressed in newer Mali GPU families.
> >>>
> >>> In addition, ipa_counters are not enabled in the current Panthor
> >>> driver. We observed this issue with the private Mali DDK where
> >>> ipa_counters
> >> were enabled.
> >>> Therefore, keeping the compatible string is necessary to allow for
> >>> future
> >> divergence.
> >>
> >> No one discusses here whether you need separate compatible string.
> >> writing bindings and all my talks are (e.g. DTS 101) are clearly expecting
> you.
> >>
> >> We discuss only the lack of compatibility in terms of DT, how DT sees
> >> compatible devices.
> >>
> >> And lack of driver code is clear indication that devices are
> >> compatible in terms how DT understands it. Feel encouraged to bring
> >> actual arguments in commit msgs in the future.
> >>
> >> Best regards,
> >> Krzysztof
> >
> > So the best approach is only reserve "arm,mali-valhall-csf" for now,
> > since currently there is no need for an additional compatible entry from a DT
> compatibility perspective.
> > We can introduce "nxp,imx952-mali" in future commits if hardware or
> > driver differences actually require it, and include more detailed justification
> in the commit message. Right?
>
> So does that mean you decided not to read writing bindings document?
Actually, I followed the compatible string of gpu node in imx952.dtsi during
code work since they share the same GPU IP.
gpu: gpu@4d900000 {
compatible = "nxp,imx95-mali", "arm,mali-valhall-csf"; >
Is this line in writing bindings document that you want to mention about?
Could you please share more suggestions about the patch optimization?
DO add new compatibles in case there are new features or bugs.
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc aliases
From: Nora Schiffer @ 2026-04-01 11:31 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexander Stein,
linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <bfd19beec4ccbe296cdc1da865b15caf3ad1e5cc.camel@ew.tq-group.com>
On Tue, 2026-03-17 at 09:29 +0100, Nora Schiffer wrote:
> On Tue, 2026-02-24 at 16:25 +0100, Nora Schiffer wrote:
> > All modern TQ-Systems boards follow the convention that mmc0 is the eMMC
> > and mmc1 is the SD-card when both interfaces exist, reducing differences
> > between boards for both documentation and U-Boot code (which uses the
> > same Device Trees). Adjust the recently added MBLS1028A Device Tree
> > accordingly.
> >
> > Fixes: 0538ca1f102d ("arm64: dts: ls1028a: Add mbls1028a and mbls1028a-ind devicetrees")
> > Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> > Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > ---
> >
> > v2:
> > - updated author information after name change
> > - collected review tags
> >
> > As mentioned in the v1 submission, it would be great to get this in
> > before v7.0, as the TQMLS1028A/MBLS1028A was just added in the current
> > development cycle, and we'd like to avoid changing the aliases after the
> > DTS was part of a mainline kernel release.
> >
> > Best,
> > Nora
>
>
> Hi Frank,
>
> can we get this applied, so the change makes it into v7.0?
>
> Best,
> Nora
Hi Frank,
is there still time for this patch to make it into v7.0? If not, it would be
great to have this applied early in the v7.1 development cycle, so it can get
backported to 7.0.y before anyone starts relying on the current order of mmc
devices.
Best,
Nora
>
>
>
> >
> >
> > .../boot/dts/freescale/fsl-ls1028a-tqmls1028a-mbls1028a.dtsi | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-tqmls1028a-mbls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a-tqmls1028a-mbls1028a.dtsi
> > index cf338b2e80064..426a81e1743f1 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-tqmls1028a-mbls1028a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-tqmls1028a-mbls1028a.dtsi
> > @@ -17,8 +17,8 @@ aliases {
> > gpio0 = &gpio1;
> > gpio1 = &gpio2;
> > gpio2 = &gpio3;
> > - mmc0 = &esdhc; /* SD-Card */
> > - mmc1 = &esdhc1; /* eMMC */
> > + mmc0 = &esdhc1; /* eMMC */
> > + mmc1 = &esdhc; /* SD-Card */
> > serial0 = &duart0;
> > serial1 = &duart1;
> > };
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH] dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
From: Gupta, Suraj @ 2026-04-01 11:15 UTC (permalink / raw)
To: Alex Bereza, Vinod Koul, Frank Li, Michal Simek,
Geert Uytterhoeven, Ulf Hansson, Arnd Bergmann, Tony Lindgren
Cc: dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <DHHOCNHDN27K.RIE745OFAACD@bereza.email>
On 4/1/2026 1:57 PM, Alex Bereza wrote:
> [You don't often get email from alex@bereza.email. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Wed Apr 1, 2026 at 7:23 AM CEST, Suraj Gupta wrote:
>
>>> Rename XILINX_DMA_LOOP_COUNT to XILINX_DMA_POLL_TIMEOUT_US because the
>>> former is incorrect. It is a timeout value for polling various register
>>> bits in microseconds. It is not a loop count. Add a constant
>>> XILINX_DMA_POLL_DELAY_US for delay_us value.
>>
>> Please split this change in a new patch.
>
> Ok, will send a v2.
>
>>> Fixes: 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()")
>>
>> This patch doesn't fixes anything in iopoll, please use correct fixes tag.
>
> Ok, but I'm not sure what would be the correct fixes tag then? I though I need to reference
> 7349a69cf312 in fixes tag because this is the actual change that surfaced the CPU stall issue that I
> want to fix in this driver. I'm fixing the call sites of xilinx_dma_poll_timeout but they were added
> in different commits. Should I add all of them? That would be the following then:
>
> Fixes: 9495f2648287 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's")
> Fixes: 676f9c26c330 ("dmaengine: xilinx: fix device_terminate_all() callback for AXI CDMA")
>
> Three call sites with delay_us=0 were first introduced by 9495f2648287, then 676f9c26c330 added the
> fourth call site when introducing xilinx_cdma_stop_transfer (probably copy paste from
> xilinx_dma_stop_transfer). Would adding these two fixes tags be correct?
>
>>> Hi, in addition to this patch I also have a question: what is the point
>>> of atomically polling for the HALTED or IDLE bit in the stop_transfer
>>> functions? Does device_terminate_all really need to be callable from
>>> atomic context? If not, one could switch to polling non-atomically and
>>> avoid burning CPU cycles.
>>>
>>
>> dmaengine_terminate_async(), which directly calls device_terminate_all
>> can be called from atomic context.
>
> Right, thanks! Just for my understanding: I still think there is potential for improvement, because
> from my understanding it would be beneficial to do the waiting for the bits in the status register
> and the freeing of descriptors in xilinx_dma_synchronize. Do I understand correctly that this is
> currently not possible due to how the DMA engine API is structured? To make this possible I think
> the deprecated dmaengine_terminate_all would have to be removed and all users of this API would have
> to be adapted accordingly, correct? So this would be a patch of much larger scope than xilinx_dma
> driver alone.
Yes, your understanding of xilinx_dma_synchronize()and proposed changes
looks correct.
Regards,
Suraj
^ permalink raw reply
* Re: [GIT PULL] aspeed: first batch of fixes for v7.0
From: Krzysztof Kozlowski @ 2026-04-01 11:33 UTC (permalink / raw)
To: Andrew Jeffery
Cc: soc, linux-arm-kernel, linux-aspeed, linux-kernel, Joel Stanley
In-Reply-To: <4afeb8eaa663835725cebaeb8c1b6f50dce184dd.camel@codeconstruct.com.au>
On Thu, Mar 26, 2026 at 01:25:03PM +1030, Andrew Jeffery wrote:
> Hello SoC maintainers,
>
> I've been intending to send out this fix PR for a while now, but time
> has escaped me recently.
>
> Andrew
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git tags/aspeed-7.0-fixes-0
>
> for you to fetch changes up to 7ec1bd3d9be671d04325b9e06149b8813f6a4836:
>
> soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching (2026-02-23 09:43:21 +1030)
>
> ----------------------------------------------------------------
> aspeed: first batch of fixes for v7.0
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] aspeed: first batch of devicetree changes for v7.1
From: Krzysztof Kozlowski @ 2026-04-01 11:35 UTC (permalink / raw)
To: Andrew Jeffery
Cc: soc, linux-arm-kernel, linux-aspeed, linux-kernel, Joel Stanley
In-Reply-To: <df8ef5ea7b9e254658934c18de20fd9805a82d74.camel@codeconstruct.com.au>
On Thu, Mar 26, 2026 at 01:39:52PM +1030, Andrew Jeffery wrote:
> Hello SoC maintainers,
>
> Here's the first batch of ASPEED devicetree changes for v7.1.
>
> Please pull.
>
> Cheers,
>
> Andrew
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git tags/aspeed-7.1-devicetree-0
>
> for you to fetch changes up to 76b4ec8efdc3887cdbf730da2e55881fc1a18770:
>
> ARM: dts: aspeed: anacapa: Add retimer EEPROMs (2026-02-23 12:02:22 +1030)
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 0/2] Make TPS65219 poweroff handler conditional
From: Akashdeep Kaur @ 2026-04-01 11:22 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy
Cc: vishalm, sebin.francis, d-gole, k-willis, a-kaur
This series makes the TPS65219 PMIC poweroff handler registration
conditional based on device tree configuration, following standard
kernel patterns.
Currently, the TPS65219 driver unconditionally registers as the system
poweroff handler. This creates conflicts on platforms where alternative
poweroff mechanisms (such as TF-A firmware or other power controllers)
should handle system shutdown instead.
The standard kernel approach is to use the "system-power-controller"
device tree property to explicitly designate which component is
responsible for system poweroff operations.
Patch 1: Add "system-power-controller" property to AM62-LP-SK device
tree, explicitly designating the TPS65219 PMIC as the system
power controller for this platform. This property was missing
only on AM62-LP-SK among all in-tree TPS65219-based devices.
Patch 2: Update TPS65219 driver to only register poweroff handler when
"system-power-controller" property is present. This allows
other systems using this PMIC to use alternative poweroff
mechanisms.
Impact:
- AM62-LP-SK: No functional change (property added, handler still
registers)
- Other TPS65219-based systems: Poweroff handler registration becomes
opt-in via DT property
Tested on AM62-LP-SK - system poweroff works correctly.
Changes in v3:
- Fixed minor formatting issues in PMIC driver
- Link to v2: https://lore.kernel.org/all/20260324101419.95616-1-a-kaur@ti.com/
Changes in v2:
- Addressed review feedback by removing comment on self explanatory code
- Link to v1: https://lore.kernel.org/all/20260310111846.1084623-1-a-kaur@ti.com/
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
Akashdeep Kaur (2):
arm64: dts: ti: k3-am62-lp-sk: Add system-power-controller
mfd: tps65219: Make poweroff handler conditional on
system-power-controller
arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts | 1 +
drivers/mfd/tps65219.c | 14 ++++++++------
2 files changed, 9 insertions(+), 6 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [GIT PULL] nuvoton: first batch of arm64 devicetree changes for v7.1
From: Krzysztof Kozlowski @ 2026-04-01 11:38 UTC (permalink / raw)
To: Andrew Jeffery; +Cc: soc, linux-arm-kernel, openbmc, linux-kernel, Joel Stanley
In-Reply-To: <8d8d5f9f7f8ee803ab14c4b3405d74b305a2ab81.camel@codeconstruct.com.au>
On Thu, Mar 26, 2026 at 01:56:03PM +1030, Andrew Jeffery wrote:
> Hello SoC maintainers,
>
> Just the one Nuvoton devicetree change for v7.1
>
> Please pull.
>
> Andrew
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git tags/nuvoton-arm64-7.1-devicetree-0
>
> for you to fetch changes up to 6ee3f20368a4a6198988a54c1a744cbae1354359:
>
> arm64: dts: nuvoton: drop unused syscon property from watchdog node (2026-02-23 09:43:36 +1030)
>
> ----------------------------------------------------------------
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Akashdeep Kaur @ 2026-04-01 11:22 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy
Cc: vishalm, sebin.francis, d-gole, k-willis, a-kaur
In-Reply-To: <20260401112257.1248437-1-a-kaur@ti.com>
Currently, the TPS65219 driver unconditionally registers a poweroff
handler. This causes issues on systems where a different component
(such as TF-A firmware) should handle system poweroff instead.
Make the poweroff handler registration conditional based on the
"system-power-controller" device tree property. This follows the
standard kernel pattern where only the designated power controller
registers for system poweroff operations.
On systems where the property is absent, the PMIC will not register
a poweroff handler, allowing other poweroff mechanisms to function.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/mfd/tps65219.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
index 7275dcdb7c44..e52fbf1481fe 100644
--- a/drivers/mfd/tps65219.c
+++ b/drivers/mfd/tps65219.c
@@ -541,13 +541,15 @@ static int tps65219_probe(struct i2c_client *client)
return ret;
}
- ret = devm_register_power_off_handler(tps->dev,
- tps65219_power_off_handler,
- tps);
- if (ret) {
- dev_err(tps->dev, "failed to register power-off handler: %d\n", ret);
- return ret;
+ if (of_device_is_system_power_controller(tps->dev->of_node)) {
+ ret = devm_register_power_off_handler(tps->dev,
+ tps65219_power_off_handler,
+ tps);
+ if (ret)
+ return dev_err_probe(tps->dev, ret,
+ "Failed to register power-off handler\n");
}
+
return 0;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
From: Alex Bereza @ 2026-04-01 11:41 UTC (permalink / raw)
To: Gupta, Suraj, Alex Bereza, Vinod Koul, Frank Li, Michal Simek,
Geert Uytterhoeven, Ulf Hansson, Arnd Bergmann, Tony Lindgren
Cc: dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <f5a8ac32-3c65-4703-87fc-d0990839887d@amd.com>
Hi Suraj,
On Wed Apr 1, 2026 at 1:15 PM CEST, Suraj Gupta wrote:
>>>> Hi, in addition to this patch I also have a question: what is the point
>>>> of atomically polling for the HALTED or IDLE bit in the stop_transfer
>>>> functions? Does device_terminate_all really need to be callable from
>>>> atomic context? If not, one could switch to polling non-atomically and
>>>> avoid burning CPU cycles.
>>>>
>>>
>>> dmaengine_terminate_async(), which directly calls device_terminate_all
>>> can be called from atomic context.
>>
>> Right, thanks! Just for my understanding: I still think there is potential for improvement, because
>> from my understanding it would be beneficial to do the waiting for the bits in the status register
>> and the freeing of descriptors in xilinx_dma_synchronize. Do I understand correctly that this is
>> currently not possible due to how the DMA engine API is structured? To make this possible I think
>> the deprecated dmaengine_terminate_all would have to be removed and all users of this API would have
>> to be adapted accordingly, correct? So this would be a patch of much larger scope than xilinx_dma
>> driver alone.
>
> Yes, your understanding of xilinx_dma_synchronize()and proposed changes
> looks correct.
Thank you for the feedback on this. It is really helpful since I'm quite new to
writing patches for the kernel. I was thinking about whether I can improve the
xilinx_dma driver in this regard, but given the large scope of changing the
whole DMA engine API and all its users unfortunately this task is too big for
me.
BR
Alex
^ permalink raw reply
* [PATCH 00/33] rust: bump minimum Rust and `bindgen` versions
From: Miguel Ojeda @ 2026-04-01 11:45 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
we are going to follow Debian Stable's Rust versions as our minimum
supported version.
Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it
still uses to this day [3] (i.e. no update to Rust 1.85.1).
Debian Trixie was released with `bindgen` 0.71.1, which it also still
uses to this day [4].
Debian Trixie's release happened on 2025-08-09 [5], which means that a
fair amount of time has passed since its release for kernel developers
to upgrade.
Thus bump the minimum to the new versions, i.e.
- Rust: 1.78.0 -> 1.85.0
- bindgen: 0.65.1 -> 0.71.1
There are a few main parts to the series, in this order:
- The Rust bump (and cleanups).
- The bindgen bump (and cleanups).
- Documentation updates.
- The `cfi_encoding` patch, added here, which needs the bump.
- The per-version flags support and a Clippy cleanup on top.
Link: https://lwn.net/Articles/1050174/ [1]
Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]
Link: https://packages.debian.org/trixie/rustc [3]
Link: https://packages.debian.org/trixie/bindgen [4]
Link: https://www.debian.org/releases/trixie/ [5]
---
The cleanups should cover most of it -- there may be more we can do
later e.g. in linux-next.
Most patches are optional, so if there are concerns with any, they can
be dropped or be done later. Most are straightforward, though, and e.g.
a couple of them update TODO comments to keep the series even simpler.
The patches have been split as much as possible to be able to add as
much context as possible and to make it easier to review and to drop any
if needed.
All in all, it is a nice `--stat` of deletions I think :)
Alice Ryhl (1):
rust: declare cfi_encoding for lru_status
Miguel Ojeda (32):
rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
rust: bump Clippy's MSRV and clean `incompatible_msrv` allows
rust: simplify `RUSTC_VERSION` Kconfig conditions
rust: remove `RUSTC_HAS_SLICE_AS_FLATTENED` and simplify code
rust: remove `RUSTC_HAS_COERCE_POINTEE` and simplify code
rust: kbuild: remove skipping of `-Wrustdoc::unescaped_backticks`
rust: kbuild: remove `feature(...)`s that are now stable
rust: kbuild: simplify `--remap-path-prefix` workaround
rust: kbuild: make `--remap-path-prefix` workaround conditional
rust: transmute: simplify code with Rust 1.80.0 `split_at_*checked()`
rust: alloc: simplify with `NonNull::add()` now that it is stable
rust: macros: update `extract_if` MSRV TODO comment
rust: block: update `const_refs_to_static` MSRV TODO comment
rust: bump `bindgen` minimum supported version to 0.71.1 (Debian
Trixie)
rust: rust_is_available: remove warning for 0.66.[01] buggy versions
rust: rust_is_available: remove warning for < 0.69.5 && libclang >=
19.1
rust: kbuild: update `bindgen --rust-target` version and replace
comment
rust: kbuild: remove "dummy parameter" workaround for `bindgen` <
0.71.1
rust: kbuild: remove "`try` keyword" workaround for `bindgen` < 0.59.2
rust: kbuild: remove unneeded old `allow`s for generated layout tests
gpu: nova-core: bindings: remove unneeded `cfg_attr`
docs: rust: quick-start: openSUSE provides `rust-src` package nowadays
docs: rust: quick-start: update Ubuntu versioned packages
docs: rust: quick-start: update minimum Ubuntu version
docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection
title
docs: rust: quick-start: remove Gentoo "testing" note
docs: rust: quick-start: remove Nix "unstable channel" note
docs: rust: quick-start: remove GDB/Binutils mention
docs: rust: general-information: simplify Kconfig example
docs: rust: general-information: use real example
rust: kbuild: support global per-version flags
rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0
.clippy.toml | 2 +-
Documentation/process/changes.rst | 4 +-
Documentation/rust/general-information.rst | 4 +-
Documentation/rust/quick-start.rst | 52 +++++++----------
Makefile | 9 +++
arch/Kconfig | 3 +-
arch/arm64/Kconfig | 8 ---
arch/riscv/Kconfig | 3 -
drivers/android/binder/Makefile | 3 +-
drivers/android/binder/page_range.rs | 6 +-
drivers/android/binder/page_range_helper.c | 24 --------
drivers/android/binder/page_range_helper.h | 15 -----
drivers/gpu/nova-core/gsp/cmdq.rs | 6 +-
drivers/gpu/nova-core/gsp/fw/r570_144.rs | 3 -
init/Kconfig | 15 +----
rust/Makefile | 36 ++++--------
rust/bindgen_parameters | 8 +--
rust/bindings/bindings_helper.h | 1 -
rust/bindings/lib.rs | 5 +-
rust/kernel/alloc/allocator/iter.rs | 8 +--
rust/kernel/alloc/kbox.rs | 29 +---------
rust/kernel/block/mq/gen_disk.rs | 4 +-
rust/kernel/lib.rs | 30 +---------
rust/kernel/list/arc.rs | 22 +------
rust/kernel/prelude.rs | 3 -
rust/kernel/ptr.rs | 1 -
rust/kernel/slice.rs | 49 ----------------
rust/kernel/sync/arc.rs | 21 +------
rust/kernel/transmute.rs | 35 ++---------
rust/macros/kunit.rs | 2 +-
rust/uapi/lib.rs | 5 +-
scripts/Makefile.build | 6 +-
scripts/min-tool-version.sh | 4 +-
scripts/rust_is_available.sh | 36 +-----------
scripts/rust_is_available_bindgen_0_66.h | 2 -
...ust_is_available_bindgen_libclang_concat.h | 3 -
scripts/rust_is_available_test.py | 58 +------------------
37 files changed, 79 insertions(+), 446 deletions(-)
delete mode 100644 drivers/android/binder/page_range_helper.c
delete mode 100644 drivers/android/binder/page_range_helper.h
delete mode 100644 rust/kernel/slice.rs
delete mode 100644 scripts/rust_is_available_bindgen_0_66.h
delete mode 100644 scripts/rust_is_available_bindgen_libclang_concat.h
--
2.53.0
^ permalink raw reply
* [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Miguel Ojeda @ 2026-04-01 11:45 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-1-ojeda@kernel.org>
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
we are going to follow Debian Stable's Rust versions as our minimum
supported version.
Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it
still uses to this day [3] (i.e. no update to Rust 1.85.1).
Debian Trixie's release happened on 2025-08-09 [4], which means that a
fair amount of time has passed since its release for kernel developers
to upgrade.
Thus bump the minimum to the new version.
Then, in later commits, clean up most of the workarounds and other bits
that this upgrade of the minimum allows us.
pin-init was left as-is since the patches come from upstream. And the
vendored crates are unmodified, since we do not want to change those.
Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the
Rust upstream binaries use LLVM 19.1.7), thus e.g. `RUSTC_LLVM_VERSION`
tests can also be updated, but there are no suitable ones to simplify.
Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also
provide versioned packages with a Rust 1.85.1 toolchain even back to
Ubuntu 22.04 LTS [6].
Link: https://lwn.net/Articles/1050174/ [1]
Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]
Link: https://packages.debian.org/trixie/rustc [3]
Link: https://www.debian.org/releases/trixie/ [4]
Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5]
Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [6]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Documentation/process/changes.rst | 2 +-
scripts/min-tool-version.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 6b373e193548..474594bd4831 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -31,7 +31,7 @@ you probably needn't concern yourself with pcmciautils.
====================== =============== ========================================
GNU C 8.1 gcc --version
Clang/LLVM (optional) 15.0.0 clang --version
-Rust (optional) 1.78.0 rustc --version
+Rust (optional) 1.85.0 rustc --version
bindgen (optional) 0.65.1 bindgen --version
GNU make 4.0 make --version
bash 4.2 bash --version
diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
index 99b5575c1ef7..a270ec761f64 100755
--- a/scripts/min-tool-version.sh
+++ b/scripts/min-tool-version.sh
@@ -31,7 +31,7 @@ llvm)
fi
;;
rustc)
- echo 1.78.0
+ echo 1.85.0
;;
bindgen)
echo 0.65.1
--
2.53.0
^ permalink raw reply related
* [PATCH 02/33] rust: bump Clippy's MSRV and clean `incompatible_msrv` allows
From: Miguel Ojeda @ 2026-04-01 11:45 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-1-ojeda@kernel.org>
Following the Rust compiler bump, we can now update Clippy's MSRV we
set in the configuration, which will improve the diagnostics it generates.
Thus do so and clean a few of the `allow`s that are not needed anymore.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
.clippy.toml | 2 +-
drivers/gpu/nova-core/gsp/cmdq.rs | 6 +-----
rust/kernel/ptr.rs | 1 -
rust/kernel/transmute.rs | 2 --
4 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/.clippy.toml b/.clippy.toml
index a51de9a46380..b0a78cc8be20 100644
--- a/.clippy.toml
+++ b/.clippy.toml
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
-msrv = "1.78.0"
+msrv = "1.85.0"
check-private-items = true
diff --git a/drivers/gpu/nova-core/gsp/cmdq.rs b/drivers/gpu/nova-core/gsp/cmdq.rs
index 46819a82a51a..d9f69366642a 100644
--- a/drivers/gpu/nova-core/gsp/cmdq.rs
+++ b/drivers/gpu/nova-core/gsp/cmdq.rs
@@ -281,7 +281,6 @@ fn allocate_command(&mut self, size: usize) -> Result<GspCommand<'_>> {
let (slice_1, slice_2) = {
let (slice_1, slice_2) = self.driver_write_area();
- #[allow(clippy::incompatible_msrv)]
(slice_1.as_flattened_mut(), slice_2.as_flattened_mut())
};
@@ -572,10 +571,7 @@ fn wait_for_msg(&self, timeout: Delta) -> Result<GspMessage<'_>> {
Delta::from_millis(1),
timeout,
)
- .map(|(slice_1, slice_2)| {
- #[allow(clippy::incompatible_msrv)]
- (slice_1.as_flattened(), slice_2.as_flattened())
- })?;
+ .map(|(slice_1, slice_2)| (slice_1.as_flattened(), slice_2.as_flattened()))?;
// Extract the `GspMsgElement`.
let (header, slice_1) = GspMsgElement::from_bytes_prefix(slice_1).ok_or(EIO)?;
diff --git a/rust/kernel/ptr.rs b/rust/kernel/ptr.rs
index 512e2eabe3ad..bd669e74e1cc 100644
--- a/rust/kernel/ptr.rs
+++ b/rust/kernel/ptr.rs
@@ -81,7 +81,6 @@ pub const fn new_checked(align: usize) -> Option<Self> {
/// This is equivalent to [`align_of`], but with the return value provided as an [`Alignment`].
#[inline(always)]
pub const fn of<T>() -> Self {
- #![allow(clippy::incompatible_msrv)]
// This cannot panic since alignments are always powers of two.
//
// We unfortunately cannot use `new` as it would require the `generic_const_exprs` feature.
diff --git a/rust/kernel/transmute.rs b/rust/kernel/transmute.rs
index 5711580c9f9b..b9e6eadc08f5 100644
--- a/rust/kernel/transmute.rs
+++ b/rust/kernel/transmute.rs
@@ -49,7 +49,6 @@ fn from_bytes(bytes: &[u8]) -> Option<&Self>
let slice_ptr = bytes.as_ptr().cast::<Self>();
let size = size_of::<Self>();
- #[allow(clippy::incompatible_msrv)]
if bytes.len() == size && slice_ptr.is_aligned() {
// SAFETY: Size and alignment were just checked.
unsafe { Some(&*slice_ptr) }
@@ -92,7 +91,6 @@ fn from_bytes_mut(bytes: &mut [u8]) -> Option<&mut Self>
let slice_ptr = bytes.as_mut_ptr().cast::<Self>();
let size = size_of::<Self>();
- #[allow(clippy::incompatible_msrv)]
if bytes.len() == size && slice_ptr.is_aligned() {
// SAFETY: Size and alignment were just checked.
unsafe { Some(&mut *slice_ptr) }
--
2.53.0
^ 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