* Re: [GIT PULL 1/2] arm64: dts: ti: K3 updates for v7.1
From: Vignesh Raghavendra @ 2026-04-06 6:33 UTC (permalink / raw)
To: Arnd Bergmann, SoC, arm
Cc: SoC list, linux-arm-kernel, linux-kernel, Tero Kristo,
Nishanth Menon
In-Reply-To: <1ed625c0-e977-42d4-85f0-91e90a4c3547@app.fastmail.com>
Hi Arnd,
On 03/04/26 03:30, Arnd Bergmann wrote:
> On Wed, Apr 1, 2026, at 19:14, Vignesh Raghavendra wrote:
>
> Hi Vignesh,
>
> I've merged this now, but I see that there are a number of
> patches that look like they should have been part of an
> earlier pull request for 7.0 and possibly backports:
>
>> Generic Fixes/Cleanups:
>> - ti,min-output-impedance addition to all K3 board DT files
>>
>> AM69 Aquila:
>> - Fix DP regulator enable GPIO
>>
>> AM62A7-SK:
>> - Fix pin name in comment from M19 to N22
>>
>> AM62L3 EVM:
>> - Disable MMC1 internal pulls on data pins
>>
>> AM62P:
>> - SK: Disable MMC1 internal pulls on data pins and enable Main UART
>
> Can you have a look to see if my intuition is right on these
> ones, and make sure they get merged more quickly in the future?
>
Ah yes. These are non urgent fixes in terms of impact on functionality
(except AM69 Aquila one perhaps), so decided to club them into the v7.1.
But, will keep in mind to send them earlier next time. Thanks!
--
Regards
Vignesh
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v4 7/9] driver core: Replace dev->dma_coherent with dev_dma_coherent()
From: Vinod Koul @ 2026-04-06 5:49 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Saravana Kannan, Christoph Hellwig, Eric Dumazet,
Johan Hovold, Leon Romanovsky, Alexander Lobakin,
Alexey Kardashevskiy, Robin Murphy, Frank.Li, alex,
andre.przywara, andrew, aou, catalin.marinas, dmaengine,
driver-core, gregory.clement, iommu, jgg, kees, linux-arm-kernel,
linux-kernel, linux-mips, linux-riscv, linux-snps-arc, linux,
m.szyprowski, palmer, peter.ujfalusi, pjw, sebastian.hesselbarth,
tsbogend, vgupta, will, willy
In-Reply-To: <20260403170432.v4.7.If839f6dde98979fce177f70c6c74689a1904ee76@changeid>
On 03-04-26, 17:05, Douglas Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "dma_coherent" over to the "flags"
> field so modifications are safe.
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: qcom: msm8974pro-htc-m8: add NFC support
From: Alexandre Messier via B4 Relay @ 2026-04-06 5:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Luca Weiss, linux-arm-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, devicetree, linux-kernel,
Alexandre Messier
In-Reply-To: <20260406-m8-dts-additions-v2-0-c4c4bd50af48@me.ssier.org>
From: Alexandre Messier <alex@me.ssier.org>
Add the NFC chip used in the HTC One M8 to its device tree.
The downstream vendor kernel used an I2C frequency of 384 kHz
for this bus. Use the same value as the vendor.
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
---
arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
index 37df271dbdeb..f24882dbeef3 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
@@ -65,6 +65,22 @@ vreg_vph_pwr: vreg-vph-pwr {
};
};
+&blsp1_i2c3 {
+ clock-frequency = <384000>;
+
+ status = "okay";
+
+ nfc@28 {
+ compatible = "nxp,pn544-i2c";
+ reg = <0x28>;
+
+ interrupts-extended = <&tlmm 144 IRQ_TYPE_LEVEL_HIGH>;
+
+ enable-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+ firmware-gpios = <&tlmm 3 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&pm8941_lpg {
qcom,power-source = <1>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/4] Describe more hardware of the HTC One (M8)
From: Alexandre Messier via B4 Relay @ 2026-04-06 5:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Luca Weiss, linux-arm-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, devicetree, linux-kernel,
Alexandre Messier, Lee Jones, Pavel Machek, linux-leds,
Konrad Dybcio
Add hardware description for these parts of the HTC One (M8):
- Notification LEDs
- Bluetooth
- NFC
- Touchscreen
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
---
Changes in v2:
- Rebased on top of 7.0-rc6
- In patch 1, change color of one LED from amber to orange.
- In patch 1, use a multicolor LED to represent the logical grouping
of the LEDs.
- In patches 2 and 4, note in the commit message the usage of same
I2C bus frequency as the downstream kernel.
- In patch 3, gather Reviewed-by tag from Konrad Dybcio.
- Link to v1: https://lore.kernel.org/r/20251007-m8-dts-additions-v1-0-53d7ab3594e7@me.ssier.org
---
Alexandre Messier (4):
ARM: dts: qcom: msm8974pro-htc-m8: add status LEDs
ARM: dts: qcom: msm8974pro-htc-m8: add NFC support
ARM: dts: qcom: msm8974pro-htc-m8: add Bluetooth pins
ARM: dts: qcom: msm8974pro-htc-m8: add touchscreen
arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts | 94 ++++++++++++++++++++++-
1 file changed, 90 insertions(+), 4 deletions(-)
---
base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
change-id: 20251007-m8-dts-additions-ac20291afa24
Best regards,
--
Alexandre Messier <alex@me.ssier.org>
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: qcom: msm8974pro-htc-m8: add touchscreen
From: Alexandre Messier via B4 Relay @ 2026-04-06 5:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Luca Weiss, linux-arm-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, devicetree, linux-kernel,
Alexandre Messier
In-Reply-To: <20260406-m8-dts-additions-v2-0-c4c4bd50af48@me.ssier.org>
From: Alexandre Messier <alex@me.ssier.org>
Add the touchscreen device node for the HTC One (M8).
The downstream vendor kernel used an I2C frequency of 384 kHz
for this bus. Use the same value as the vendor.
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
---
arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts | 36 +++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
index 2edf407db567..66ad93e7dd20 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
@@ -65,6 +65,35 @@ vreg_vph_pwr: vreg-vph-pwr {
};
};
+&blsp1_i2c2 {
+ clock-frequency = <384000>;
+
+ status = "okay";
+
+ touch@20 {
+ compatible = "syna,rmi4-i2c";
+ reg = <0x20>;
+
+ interrupts-extended = <&tlmm 18 IRQ_TYPE_LEVEL_LOW>;
+
+ pinctrl-0 = <&ts_int_pin>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rmi4-f01@1 {
+ reg = <0x1>;
+ syna,nosleep-mode = <1>;
+ };
+
+ rmi4-f11@11 {
+ reg = <0x11>;
+ syna,sensor-type = <1>;
+ };
+ };
+};
+
&blsp1_i2c3 {
clock-frequency = <384000>;
@@ -353,6 +382,13 @@ cmd-data-pins {
};
};
+ ts_int_pin: ts-int-pin-state {
+ pins = "gpio18";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
wcnss_pin_a: wcnss-pin-active-state {
bt-pins {
pins = "gpio35", "gpio43", "gpio44";
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/4] ARM: dts: qcom: msm8974pro-htc-m8: add status LEDs
From: Alexandre Messier via B4 Relay @ 2026-04-06 5:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Luca Weiss, linux-arm-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, devicetree, linux-kernel,
Alexandre Messier, Lee Jones, Pavel Machek, linux-leds
In-Reply-To: <20260406-m8-dts-additions-v2-0-c4c4bd50af48@me.ssier.org>
From: Alexandre Messier <alex@me.ssier.org>
Add support for the notification LEDs on the HTC One M8.
Two LEDs are available, one orange and one green. Together,
they both form a single notification source, so use a
multicolor LED node to describe this arrangement.
Cc: Lee Jones <lee@kernel.org>
Cc: Pavel Machek <pavel@kernel.org>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
---
arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts | 25 +++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
index 402372834c53..37df271dbdeb 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
@@ -3,6 +3,7 @@
#include "pm8841.dtsi"
#include "pm8941.dtsi"
#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
/ {
model = "HTC One (M8)";
@@ -64,6 +65,30 @@ vreg_vph_pwr: vreg-vph-pwr {
};
};
+&pm8941_lpg {
+ qcom,power-source = <1>;
+
+ status = "okay";
+
+ multi-led {
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_STATUS;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@6 {
+ reg = <6>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@7 {
+ reg = <7>;
+ color = <LED_COLOR_ID_ORANGE>;
+ };
+ };
+};
+
&pm8941_vib {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: qcom: msm8974pro-htc-m8: add Bluetooth pins
From: Alexandre Messier via B4 Relay @ 2026-04-06 5:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Luca Weiss, linux-arm-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, devicetree, linux-kernel,
Alexandre Messier, Konrad Dybcio
In-Reply-To: <20260406-m8-dts-additions-v2-0-c4c4bd50af48@me.ssier.org>
From: Alexandre Messier <alex@me.ssier.org>
Add the required pin configuration to enable Bluetooth.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
---
arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
index f24882dbeef3..2edf407db567 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
@@ -354,10 +354,19 @@ cmd-data-pins {
};
wcnss_pin_a: wcnss-pin-active-state {
- pins = "gpio36", "gpio37", "gpio38", "gpio39", "gpio40";
- function = "wlan";
- drive-strength = <6>;
- bias-pull-down;
+ bt-pins {
+ pins = "gpio35", "gpio43", "gpio44";
+ function = "bt";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ wlan-pins {
+ pins = "gpio36", "gpio37", "gpio38", "gpio39", "gpio40";
+ function = "wlan";
+ drive-strength = <6>;
+ bias-pull-down;
+ };
};
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Frank Li @ 2026-04-06 2:56 UTC (permalink / raw)
To: Florijan Plohl
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel, upstream
In-Reply-To: <56b9e133-74b9-4e59-a40c-c7637c080fd8@norik.com>
On Fri, Apr 03, 2026 at 10:29:00AM +0200, Florijan Plohl wrote:
> Hello,
>
> On 4/2/26 15:50, Frank Li wrote:
> > On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
> > > Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
> > what's means PEB-AV-18? Is it random board name?
> The PEB-AV-18 is PHYTEC designation for Audio/Video adapter modules that can
> be used to connect displays on their boards.
>
> I will improve commit message to add more such information in v2.
>
> >
> >
> > > The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
> > >
> > > Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
> > > ---
> > > arch/arm64/boot/dts/freescale/Makefile | 4 +
> > > .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> > > .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> > Any difference between 91 and 93, can use one overlay file?
> >
> > Frank
>
> Can you suggest how to do so?
>
> There are imx93-pinfunc.h and imx91-pinfunc.h which are not unified
> between imx91 and imx93.
I suggest move pinmux setting to mainboard's dts files, which provide
plug adaptor header, signal should be descripted in mainboard's dts file,
which provide an unified label to overlay file.
Frank
>
> So we can only create common dtsi like so:
>
> imx91-93-phyboard-segin-peb-av-18.dtsi
>
> and still use separate dtsos:
>
> imx91-phyboard-segin-peb-av-18.dtso
> imx93-phyboard-segin-peb-av-18.dtso
>
> Is that your idea?
>
> BR,
>
> Florijan Plohl
>
> > > --
> > > 2.43.0
> > >
^ permalink raw reply
* [GIT PULL] i.MX arm dts changes for v7.1 (V2)
From: Frank Li @ 2026-04-06 2:08 UTC (permalink / raw)
To: soc, arm
Cc: Frank.Li, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
From: Frank.Li@nxp.com
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-dt-7.1
for you to fetch changes up to 0037d16644b15686eec420a90f05bcd2804edf6d:
ARM: dts: imx: Add DT overlays for DH i.MX6 DHCOM SoM and boards (2026-04-05 21:35:41 -0400)
Changes in v2:
drop patch: ARM: dts: imx53: drop fallback compatible "dlg,da9052"
----------------------------------------------------------------
i.MX ARM device tree changes for 7.1:
- Device Tree Schema Compliance Fixes
Fixed numerous CHECK_DTBS warnings across multiple i.MX SoC families
Renamed nodes to match schema requirements (tcq→touchscreen,
uart8250→serial, iomuxc→pinmux, etc.). Fixed node naming conventions
(added "led-" prefix, proper addressing formats).
Corrected compatible strings and removed undocumented fallbacks. Added
required properties (clocks, clock-names, power supplies,
#sound-dai-cells).
- New Hardware Support
Added DT overlays for various expansion modules (i.MX6 DHCOM PDK2,
PicoITX display boards). Added support for muRata 1YN WiFi chip
(replacement for 1DX) on i.MX6ULL DHCOR board.
i.MX7ULP: Added CPU clock and OPP table support for frequency scaling.
- Boot Phase Properties
Added bootph.yaml properties to multiple TQ-Systems boards and SoCs:
imx7s, tqma7, mba7 imx6ul/ull, tqma6ul/ull, mba6ulx imx6qdl, tqma6, mba6.
- Bug Fixes & Corrections
Fixed interrupt property usage (interrupts→interrupts-extended where
needed). Corrected spelling ("TQ-Systems" with hyphen). Removed redundant
intermediate nodes in pinmux hierarchy. Fixed clock references and
naming.
----------------------------------------------------------------
Alexander Feilke (3):
ARM: dts: imx7s: add boot phase properties
ARM: dts: tqma7: add boot phase properties
ARM: dts: imx7-mba7: Deassert BOOT_EN after boot
Dario Binacchi (1):
ARM: dts: imx6ull-engicam-microgea-bmm: set touchscreen glitch threshold
Frank Li (23):
ARM: dts: imx35: rename emi to emi-bus to fix CHECK_DTBS warning
ARM: dts: imx35: rename i2c clock-names to ipg
ARM: dts: imx35: remove simple-bus 'usbphy'
ARM: dts: imx51-ts4800: rename fpga@0 to fpga@0,0
ARM: dts: imx51-babbage: rename at45db321d@1 to flash@1
ARM: dts: imx6qdl-sr-som-ti: use fixed-clock instead of clock-frequency
ARM: dts: imx53-smd: Add power supply node for fsl,sgtl5000
ARM: dts: imx7s-warp: Remove data-lanes and clock-lanes for ov2680
ARM: dts: imx: rename iomuxc to pinmux
ARM: dts: imx: remove redundant intermediate node in pinmux hierarchy
ARM: dts: imx27-eukrea: replace interrupts with interrupts-extended
ARM: dts: imx27-eukrea-cpuimx27: rename uart8250 to serial
ARM: dts: imx27: remove fsl,imx-osc26m from fixed-clock node
ARM: dts: imx23: fix interrupt names for dma-controller@80024000
ARM: dts: imx23/28: add "led-" prefix to LED subnodes
ARM: dts: imx28: rename gpios-reset to reset-gpios of hx8357
ARM: dts: imx28-sps1: remove undocumented fallback compatible "mr25h256"
ARM: dts: imx28-tx28: rename compatible to "edt,edt-ft5206"
ARM: dts: imx28-tx28: remove undocumented aliases
ARM: dts: imx6qdl: add label for system clocks
ARM: dts: imx: add required clocks and clock-names for ccm
ARM: dts: imx25: rename node name tcq to touchscreen
ARM: dts: imx6sx: remove fallback compatible string fsl,imx28-lcdif
Ian Ray (5):
ARM: dts: imx: bx50v3: Configure switch PHY max-speed to 100Mbps
ARM: dts: imx: bx50v3: Configure phy-mode to eliminate a warning
ARM: dts: imx: b850v3: Use alphabetical sorting
ARM: dts: imx: b850v3: Define GPIO line names
ARM: dts: imx: b850v3: Disable unused usdhc4
Marek Vasut (2):
ARM: dts: imx6ull-dhcor: Handle both 1DX and 1YN WiFi on i.MX6ULL DHCOR
ARM: dts: imx: Add DT overlays for DH i.MX6 DHCOM SoM and boards
Max Merchel (8):
ARM: dts: imx6qdl-tqma6: add missing labels
ARM: dts: imx6qdl: add boot phase properties
ARM: dts: imx6qdl-tqma6: add boot phase properties
ARM: dts: imx6qdl-mba6: add boot phase properties
ARM: dts: imx6ul/imx6ull: add boot phase properties
ARM: dts: imx6ul[l]-tqma6ul[l]: add boot phase properties
ARM: dts: mba6ulx: add boot phase properties
ARM: dts: tqma6ul[l]: correct spelling of TQ-Systems
Peng Fan (1):
ARM: dts: imx7ulp: Add CPU clock and OPP table support
arch/arm/boot/dts/nxp/imx/Makefile | 37 ++++
arch/arm/boot/dts/nxp/imx/imx1-ads.dts | 108 +++++----
arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts | 92 ++++----
arch/arm/boot/dts/nxp/imx/imx1.dtsi | 2 +-
.../boot/dts/nxp/imx/imx25-eukrea-cpuimx25.dtsi | 38 ++--
.../imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts | 6 +-
.../nxp/imx/imx25-eukrea-mbimxsd25-baseboard.dts | 134 ++++++-----
arch/arm/boot/dts/nxp/imx/imx25-pdk.dts | 190 ++++++++--------
arch/arm/boot/dts/nxp/imx/imx25.dtsi | 4 +-
arch/arm/boot/dts/nxp/imx/imx27-apf27.dts | 58 +++--
arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts | 194 ++++++++--------
.../boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi | 244 ++++++++++-----------
.../nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts | 196 ++++++++---------
arch/arm/boot/dts/nxp/imx/imx27-pdk.dts | 132 ++++++-----
.../dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts | 92 ++++----
.../dts/nxp/imx/imx27-phytec-phycard-s-som.dtsi | 174 ++++++++-------
.../boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts | 206 +++++++++--------
.../boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi | 154 +++++++------
arch/arm/boot/dts/nxp/imx/imx27.dtsi | 4 +-
arch/arm/boot/dts/nxp/imx/imx31.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx35.dtsi | 30 +--
arch/arm/boot/dts/nxp/imx/imx51-babbage.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx51-ts4800.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 18 ++
arch/arm/boot/dts/nxp/imx/imx6dl-alti6p.dts | 4 +-
.../boot/dts/nxp/imx/imx6dl-eckelmann-ci4x10.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-lanmcu.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-plybas.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-plym2m.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-prtmvt.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6dl-qmx6.dtsi | 5 +-
arch/arm/boot/dts/nxp/imx/imx6dl-victgo.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6q-b450v3.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-b650v3.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-b850v3.dts | 53 +++--
arch/arm/boot/dts/nxp/imx/imx6q-bx50v3.dtsi | 4 +
arch/arm/boot/dts/nxp/imx/imx6q-prtwd2.dts | 4 +-
...mx6qdl-dhcom-overlay-panel-dpi-ch101olhlwh.dtsi | 75 +++++++
.../nxp/imx/imx6qdl-dhcom-overlay-panel-dpi.dtsi | 61 ++++++
.../imx6qdl-dhcom-pdk2-overlay-497-200-x12.dtso | 28 +++
...dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso | 26 +++
.../imx6qdl-dhcom-pdk2-overlay-531-100-x21.dtso | 32 +++
.../imx6qdl-dhcom-pdk2-overlay-531-100-x22.dtso | 32 +++
.../imx6qdl-dhcom-pdk2-overlay-560-200-x12.dtso | 39 ++++
...com-picoitx-overlay-626-100-x2-ch101olhlwh.dtso | 8 +
arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-som.dtsi | 6 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-mba6.dtsi | 12 +
arch/arm/boot/dts/nxp/imx/imx6qdl-skov-cpu.dtsi | 4 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-sr-som-ti.dtsi | 8 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-tqma6.dtsi | 11 +
arch/arm/boot/dts/nxp/imx/imx6qdl-tqma6a.dtsi | 5 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-tqma6b.dtsi | 6 +-
arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi | 24 +-
arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 4 +-
.../boot/dts/nxp/imx/imx6ul-tqma6ul-common.dtsi | 10 +
arch/arm/boot/dts/nxp/imx/imx6ul-tqma6ul2.dtsi | 1 +
.../boot/dts/nxp/imx/imx6ul-tqma6ul2l-mba6ulx.dts | 4 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tqma6ul2l.dtsi | 1 +
.../boot/dts/nxp/imx/imx6ul-tqma6ulx-common.dtsi | 1 +
.../boot/dts/nxp/imx/imx6ul-tqma6ulxl-common.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx6ul.dtsi | 7 +
arch/arm/boot/dts/nxp/imx/imx6ull-dhcor-som.dtsi | 4 +-
.../dts/nxp/imx/imx6ull-engicam-microgea-bmm.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6ull-tqma6ull2.dtsi | 1 +
.../dts/nxp/imx/imx6ull-tqma6ull2l-mba6ulx.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ull-tqma6ull2l.dtsi | 3 +-
arch/arm/boot/dts/nxp/imx/imx6ull.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 13 ++
arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx7s-warp.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx7s.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi | 28 +++
arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi | 6 +
arch/arm/boot/dts/nxp/mxs/imx23-olinuxino.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx23.dtsi | 6 +-
arch/arm/boot/dts/nxp/mxs/imx28-apf28dev.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-apx4devkit.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-cfa10036.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-cfa10049.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-cfa10055.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-cfa10056.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-duckbill-2-485.dts | 4 +-
.../boot/dts/nxp/mxs/imx28-duckbill-2-enocean.dts | 6 +-
arch/arm/boot/dts/nxp/mxs/imx28-duckbill-2.dts | 4 +-
arch/arm/boot/dts/nxp/mxs/imx28-duckbill.dts | 4 +-
arch/arm/boot/dts/nxp/mxs/imx28-evk.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts | 4 +-
arch/arm/boot/dts/nxp/mxs/imx28-sps1.dts | 2 +-
arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts | 9 +-
89 files changed, 1607 insertions(+), 1140 deletions(-)
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-overlay-panel-dpi-ch101olhlwh.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-overlay-panel-dpi.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-497-200-x12.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-531-100-x21.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-531-100-x22.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-pdk2-overlay-560-200-x12.dtso
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6qdl-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtso
^ permalink raw reply
* Re: [GIT PULL 1/4] i.MX arm64 dts changes for v7.1
From: Frank Li @ 2026-04-06 1:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: soc, arm, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260404-practical-purple-jackal-8e250d@quoll>
On Sat, Apr 04, 2026 at 04:34:37PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Mar 30, 2026 at 10:14:37AM -0400, Frank Li wrote:
> > From: Frank.Li@nxp.com
> >
> > The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
> >
> > Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-dt64-7.1
> >
> > for you to fetch changes up to 825b8c7e1d2918d89eb378b761530d1e51dba82e:
> >
> > arm64: dts: imx8qxp-mek: switch Type-C connector power-role to dual (2026-03-27 09:53:32 -0400)
> >
> > ----------------------------------------------------------------
> > i.MX arm64 device tree changes for 7.1:
> >
> > - New Board Support
> > S32N79-RDB, Variscite DART-MX95, DART-MX91 with Sonata carrier boards,
> > Verdin iMX95 with multiple carrier boards (Yavia, Mallow, Ivy, Dahlia)
> > TQMa93xx/MBa93xxLA-MINI, SolidRun i.MX8MP HummingBoard IIoT,
> > SolidRun i.MX8MM SOM and EVB, SolidRun SolidSense-N8 board
> > Ka-Ro Electronics tx8m-1610 COM, GOcontroll Moduline IV and Moduline Mini,
> > NXP FRDM-IMX91S board, i.MX93 Wireless EVK board with Wireless SiP,
> > NXP i.MX8MP audio board v2.
>
> You do not have any bindings for these.
It is in imx/bindings branch.
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?h=soc/drivers&id=e54390aae6887151ff67526af45382beb889f99a
>
> I found them in driver bindings (!!!) pull request so completely
> different branch. This is wrong. Bindings come with the user. Who is the
> user of board bindings? Not a driver, but exactly this pull request.
I followed previous guo shawn's method. Should binding's patch be in this
pull request?
I can do that next time, some binding already in soc tree, how to fix it
this time?
>
> This makes this branch full of warnings which is completely unnecessary.
> Plus this will spawn multiple checkpatch warnings if tested. It must
> have also cause warnings in your case, so probably you do not test your
> tree enough.
Some binding doc is not coming with soc driver tree, I tested this branch
by merge linux-next/master. No warning found. I will enhance my script to
run checkpatch. I focus on check DTB_warnings.
Frank
>
> ...
>
> > Marco Felsch (1):
> > arm64: dts: imx93: Add parallel display output nodes
> >
> > Martin Schmiedel (2):
> > arm64: dts: freescale: add initial device tree for TQMa93xx/MBa93xxLA-MINI
> > arm64: dts: freescale: imx93-tqma9352-mba93xxla-mini: Add WLAN/BT overlay
> >
> > Maud Spierings (4):
> > arm64: dts: imx8mm: Add pinctrl config definitions
> > arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM
> > arm64: dts: freescale: Add the GOcontroll Moduline IV
> > arm64: dts: freescale: Add the GOcontroll Moduline Mini
> >
> > Nora Schiffer (1):
> > arm64: dts: freescale: imx8mp-tqma8mpql-mba8mp-ras314: fix UART1 RTS/CTS muxing
> >
> > Peng Fan (4):
> > arm64: dts: imx94: Add V2X/ELE mailbox nodes
> > arm64: dts: imx94: Add SCMI sensor/lmm/cpu nodes
> > arm64: dts: imx943-evk: Add nxp,ctrl-ids for scmi_misc
> > arm64: dts: imx943-evk: Add pf09/53 thermal zone
> >
> > Primoz Fiser (1):
> > arm64: dts: freescale: imx93-phy{core,board}: Add i2c bus recovery
> >
> > Ranjani Vaidyanathan (1):
> > arm64: dts: imx94: Update pin headers
> >
> > Rob Herring (Arm) (1):
> > arm64: dts: freescale: imx93: Add Ethos-U65 NPU and SRAM nodes
> >
> > Shengjiu Wang (7):
> > arm64: dts: imx8mm-evk: correct the spdif compatible string
>
> This breaks users of DTS and explains nothing about impact or why this
> should be changed (corrected). It should not pass review of two people.
> Also I could not find explanation of the impact in the tag message.
>
> Device was apparently working fine, so it should have been made
> compatible. I know that 10 years ago we did not care that much about
> DTS users, but that changes for a few years already.
>
> I am merging this but next time I would postpone the pull till some
> clarifications are provided. Please pay attention to OF_UPSTREAM and
> other users impact next time.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 07/33] rust: allow globally `clippy::incompatible_msrv`
From: Gary Guo @ 2026-04-06 0:18 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: <20260405235309.418950-8-ojeda@kernel.org>
On Mon Apr 6, 2026 at 12:52 AM BST, Miguel Ojeda wrote:
> `clippy::incompatible_msrv` is not buying us much, and we discussed
> allowing it several times in the past.
>
> For instance, there was recently another patch sent to `allow` it where
> needed [1]. While that particular case would not be needed after the
> minimum version bump to 1.85.0, it is simpler to just allow it to prevent
> future instances.
>
> Thus do so, and remove the last instance of locally allowing it we have
> in the tree (except the one in the vendored `proc_macro2` crate).
>
> Note that we still keep the `msrv` config option in `clippy.toml` since
> that affects other lints as well.
>
> Link: https://lore.kernel.org/rust-for-linux/20260404212831.78971-4-jhubbard@nvidia.com/ [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Makefile | 1 +
> rust/macros/helpers.rs | 1 -
> 2 files changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH v2 01/33] rust: kbuild: remove `--remap-path-prefix` workarounds
From: Gary Guo @ 2026-04-06 0:18 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: <20260405235309.418950-2-ojeda@kernel.org>
On Mon Apr 6, 2026 at 12:52 AM BST, Miguel Ojeda wrote:
> Commit 8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix
> to make paths relative"") removed `--remap-path-prefix` from the build
> system, so the workarounds are not needed anymore.
>
> Thus remove them.
>
> Note that the flag has landed again in parallel in this cycle in
> commit dda135077ecc ("rust: build: remap path to avoid absolute path"),
> together with `--remap-path-scope=macro` [1]. However, they are gated on
> `rustc-option-yn, --remap-path-scope=macro`, which means they are both
> only passed starting with Rust 1.95.0 [2]:
>
> `--remap-path-scope` is only stable in Rust 1.95, so use `rustc-option`
> to detect its presence. This feature has been available as
> `-Zremap-path-scope` for all versions that we support; however due to
> bugs in the Rust compiler, it does not work reliably until 1.94. I opted
> to not enable it for 1.94 as it's just a single version that we missed.
>
> In turn, that means the workarounds removed here should not be needed
> again (even with the flag added again above), since:
>
> - `rustdoc` now recognizes the `--remap-path-prefix` flag since Rust
> 1.81.0 [3] (even if it is still an unstable feature [4]).
>
> - The Internal Compiler Error [5] that the comment mentions was fixed in
> Rust 1.87.0 [6]. We tested that was the case in a previous version
> of this series by making the workaround conditional [7][8].
>
> ...which are both older versions than Rust 1.95.0.
>
> We will still need to skip `--remap-path-scope` for `rustdoc` though,
> since `rustdoc` does not support that one yet [4].
>
> Link: https://github.com/rust-lang/rust/issues/111540 [1]
> Link: https://github.com/rust-lang/rust/pull/147611 [2]
> Link: https://github.com/rust-lang/rust/pull/107099 [3]
> Link: https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#--remap-path-prefix-remap-source-code-paths-in-output [4]
> Link: https://github.com/rust-lang/rust/issues/138520 [5]
> Link: https://github.com/rust-lang/rust/pull/138556 [6]
> Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-9-ojeda@kernel.org/ [7]
> Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-10-ojeda@kernel.org/ [8]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Gary Guo <gary@garyguo.net>
> ---
> rust/Makefile | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH v2 32/33] rust: kbuild: support global per-version flags
From: Miguel Ojeda @ 2026-04-05 23:53 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: <20260405235309.418950-1-ojeda@kernel.org>
Sometimes it is useful to gate global Rust flags per compiler version.
For instance, we may want to disable a lint that has false positives in
a single version [1].
We already had helpers like `rustc-min-version` for that, which we use
elsewhere, but we cannot currently use them for `rust_common_flags`,
which contains the global flags for all Rust code (kernel and host),
because `rustc-min-version` depends on `CONFIG_RUSTC_VERSION`, which
does not exist when `rust_common_flags` is defined.
Thus, to support that, introduce `rust_common_flags_per_version`,
defined after the `include/config/auto.conf` inclusion (where
`CONFIG_RUSTC_VERSION` becomes available), and append it to
`rust_common_flags`, `KBUILD_HOSTRUSTFLAGS` and `KBUILD_RUSTFLAGS`.
In addition, move the expansion of `HOSTRUSTFLAGS` to the same place,
so that users can also override per-version flags [2].
Link: https://lore.kernel.org/rust-for-linux/CANiq72mWdFU11GcCZRchzhy0Gi1QZShvZtyRkHV2O+WA2uTdVQ@mail.gmail.com/ [1]
Link: https://lore.kernel.org/rust-for-linux/CANiq72mTaA2tjhkLKf0-2hrrrt9rxWPgy6SfNSbponbGOegQvA@mail.gmail.com/ [2]
Link: https://patch.msgid.link/20260307170929.153892-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Makefile | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 78f5ee173eda..a305ae4be522 100644
--- a/Makefile
+++ b/Makefile
@@ -506,7 +506,7 @@ KBUILD_HOSTCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(HOST_LFS_CFLAGS) \
KBUILD_HOSTCXXFLAGS := -Wall -O2 $(HOST_LFS_CFLAGS) $(HOSTCXXFLAGS) \
-I $(srctree)/scripts/include
KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
- -Zallow-features= $(HOSTRUSTFLAGS)
+ -Zallow-features=
KBUILD_HOSTLDFLAGS := $(HOST_LFS_LDFLAGS) $(HOSTLDFLAGS)
KBUILD_HOSTLDLIBS := $(HOST_LFS_LIBS) $(HOSTLDLIBS)
KBUILD_PROCMACROLDFLAGS := $(or $(PROCMACROLDFLAGS),$(KBUILD_HOSTLDFLAGS))
@@ -836,6 +836,14 @@ endif # CONFIG_TRACEPOINTS
export WARN_ON_UNUSED_TRACEPOINTS
+# Per-version Rust flags. These are like `rust_common_flags`, but may
+# depend on the Rust compiler version (e.g. using `rustc-min-version`).
+rust_common_flags_per_version :=
+
+rust_common_flags += $(rust_common_flags_per_version)
+KBUILD_HOSTRUSTFLAGS += $(rust_common_flags_per_version) $(HOSTRUSTFLAGS)
+KBUILD_RUSTFLAGS += $(rust_common_flags_per_version)
+
include $(srctree)/arch/$(SRCARCH)/Makefile
ifdef need-config
--
2.53.0
^ permalink raw reply related
* [PATCH v2 31/33] rust: declare cfi_encoding for lru_status
From: Miguel Ojeda @ 2026-04-05 23:53 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: <20260405235309.418950-1-ojeda@kernel.org>
From: Alice Ryhl <aliceryhl@google.com>
By default bindgen will convert 'enum lru_status' into a typedef for an
integer. For the most part, an integer of the same size as the enum
results in the correct ABI, but in the specific case of CFI, that is not
the case. The CFI encoding is supposed to be the same as a struct called
'lru_status' rather than the name of the underlying native integer type.
To fix this, tell bindgen to generate a newtype and set the CFI type
explicitly. Note that we need to set the CFI attribute explicitly as
bindgen is using repr(transparent), which is otherwise identical to the
inner type for ABI purposes.
This allows us to remove the page range helper C function in Binder
without risking a CFI failure when list_lru_walk calls the provided
function pointer.
The --with-attribute-custom-enum argument requires bindgen v0.71 or
greater.
[ In particular, the feature was added in 0.71.0 [1][2].
In addition, `feature(cfi_encoding)` has been available since
Rust 1.71.0 [3].
Link: https://github.com/rust-lang/rust-bindgen/issues/2520 [1]
Link: https://github.com/rust-lang/rust-bindgen/pull/2866 [2]
Link: https://github.com/rust-lang/rust/pull/105452 [3]
- Miguel ]
My testing procedure was to add this to the android17-6.18 branch and
verify that rust_shrink_free_page is successfully called without crash,
and verify that it does in fact crash when the cfi_encoding is set to
other values. Note that I couldn't test this on android16-6.12 as that
branch uses a bindgen version that is too old.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260223-cfi-lru-status-v2-1-89c6448a63a4@google.com
Reviewed-by: Gary Guo <gary@garyguo.net>
[ Rebased on top of the minimum Rust version bump series which provide
the required `bindgen` version. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
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 --------------
rust/bindgen_parameters | 4 ++++
rust/bindings/bindings_helper.h | 1 -
rust/bindings/lib.rs | 1 +
rust/uapi/lib.rs | 1 +
8 files changed, 10 insertions(+), 45 deletions(-)
delete mode 100644 drivers/android/binder/page_range_helper.c
delete mode 100644 drivers/android/binder/page_range_helper.h
diff --git a/drivers/android/binder/Makefile b/drivers/android/binder/Makefile
index 09eabb527fa0..7e0cd9782a8b 100644
--- a/drivers/android/binder/Makefile
+++ b/drivers/android/binder/Makefile
@@ -5,5 +5,4 @@ obj-$(CONFIG_ANDROID_BINDER_IPC_RUST) += rust_binder.o
rust_binder-y := \
rust_binder_main.o \
rust_binderfs.o \
- rust_binder_events.o \
- page_range_helper.o
+ rust_binder_events.o
diff --git a/drivers/android/binder/page_range.rs b/drivers/android/binder/page_range.rs
index fdd97112ef5c..8e9f5c4819d0 100644
--- a/drivers/android/binder/page_range.rs
+++ b/drivers/android/binder/page_range.rs
@@ -642,15 +642,15 @@ fn drop(self: Pin<&mut Self>) {
unsafe {
bindings::list_lru_walk(
list_lru,
- Some(bindings::rust_shrink_free_page_wrap),
+ Some(rust_shrink_free_page),
ptr::null_mut(),
nr_to_scan,
)
}
}
-const LRU_SKIP: bindings::lru_status = bindings::lru_status_LRU_SKIP;
-const LRU_REMOVED_ENTRY: bindings::lru_status = bindings::lru_status_LRU_REMOVED_RETRY;
+const LRU_SKIP: bindings::lru_status = bindings::lru_status::LRU_SKIP;
+const LRU_REMOVED_ENTRY: bindings::lru_status = bindings::lru_status::LRU_REMOVED_RETRY;
/// # Safety
/// Called by the shrinker.
diff --git a/drivers/android/binder/page_range_helper.c b/drivers/android/binder/page_range_helper.c
deleted file mode 100644
index 496887723ee0..000000000000
--- a/drivers/android/binder/page_range_helper.c
+++ /dev/null
@@ -1,24 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-/* C helper for page_range.rs to work around a CFI violation.
- *
- * Bindgen currently pretends that `enum lru_status` is the same as an integer.
- * This assumption is fine ABI-wise, but once you add CFI to the mix, it
- * triggers a CFI violation because `enum lru_status` gets a different CFI tag.
- *
- * This file contains a workaround until bindgen can be fixed.
- *
- * Copyright (C) 2025 Google LLC.
- */
-#include "page_range_helper.h"
-
-unsigned int rust_shrink_free_page(struct list_head *item,
- struct list_lru_one *list,
- void *cb_arg);
-
-enum lru_status
-rust_shrink_free_page_wrap(struct list_head *item, struct list_lru_one *list,
- void *cb_arg)
-{
- return rust_shrink_free_page(item, list, cb_arg);
-}
diff --git a/drivers/android/binder/page_range_helper.h b/drivers/android/binder/page_range_helper.h
deleted file mode 100644
index 18dd2dd117b2..000000000000
--- a/drivers/android/binder/page_range_helper.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (C) 2025 Google, Inc.
- */
-
-#ifndef _LINUX_PAGE_RANGE_HELPER_H
-#define _LINUX_PAGE_RANGE_HELPER_H
-
-#include <linux/list_lru.h>
-
-enum lru_status
-rust_shrink_free_page_wrap(struct list_head *item, struct list_lru_one *list,
- void *cb_arg);
-
-#endif /* _LINUX_PAGE_RANGE_HELPER_H */
diff --git a/rust/bindgen_parameters b/rust/bindgen_parameters
index 112ec197ef0a..6f02d9720ad2 100644
--- a/rust/bindgen_parameters
+++ b/rust/bindgen_parameters
@@ -19,6 +19,10 @@
# warning. We don't need to peek into it anyway.
--opaque-type spinlock
+# enums that appear in indirect function calls should specify a cfi type
+--newtype-enum lru_status
+--with-attribute-custom-enum=lru_status='#[cfi_encoding="10lru_status"]'
+
# `seccomp`'s comment gets understood as a doctest
--no-doc-comments
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 083cc44aa952..faf3ee634ced 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -149,5 +149,4 @@ const vm_flags_t RUST_CONST_HELPER_VM_NOHUGEPAGE = VM_NOHUGEPAGE;
#if IS_ENABLED(CONFIG_ANDROID_BINDER_IPC_RUST)
#include "../../drivers/android/binder/rust_binder.h"
#include "../../drivers/android/binder/rust_binder_events.h"
-#include "../../drivers/android/binder/page_range_helper.h"
#endif
diff --git a/rust/bindings/lib.rs b/rust/bindings/lib.rs
index e18c160dad17..854e7c471434 100644
--- a/rust/bindings/lib.rs
+++ b/rust/bindings/lib.rs
@@ -19,6 +19,7 @@
unreachable_pub,
unsafe_op_in_unsafe_fn
)]
+#![feature(cfi_encoding)]
#[allow(dead_code)]
#[allow(clippy::cast_lossless)]
diff --git a/rust/uapi/lib.rs b/rust/uapi/lib.rs
index 821e286e0daa..b8a515de31ca 100644
--- a/rust/uapi/lib.rs
+++ b/rust/uapi/lib.rs
@@ -24,6 +24,7 @@
unsafe_op_in_unsafe_fn
)]
#![cfg_attr(CONFIG_RUSTC_HAS_UNNECESSARY_TRANSMUTES, allow(unnecessary_transmutes))]
+#![feature(cfi_encoding)]
// Manual definition of blocklisted types.
type __kernel_size_t = usize;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 15/33] rust: macros: simplify code using `feature(extract_if)`
From: Miguel Ojeda @ 2026-04-05 23:52 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: <20260405235309.418950-1-ojeda@kernel.org>
`feature(extract_if)` [1] was stabilized in Rust 1.87.0 [2], and the last
significant change happened in Rust 1.85.0 [3] when the range parameter
was added.
That is, with our new minimum version, we can start using the feature.
Thus simplify the code using the feature and remove the TODO comment.
Suggested-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/rust-for-linux/DHHVSX66206Y.3E7I9QUNTCJ8I@garyguo.net/
Link: https://github.com/rust-lang/rust/issues/43244 [1]
Link: https://github.com/rust-lang/rust/pull/137109 [2]
Link: https://github.com/rust-lang/rust/pull/133265 [3]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
rust/macros/kunit.rs | 9 +++++----
rust/macros/lib.rs | 3 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/rust/macros/kunit.rs b/rust/macros/kunit.rs
index 6be880d634e2..ae20ed6768f1 100644
--- a/rust/macros/kunit.rs
+++ b/rust/macros/kunit.rs
@@ -87,10 +87,11 @@ pub(crate) fn kunit_tests(test_suite: Ident, mut module: ItemMod) -> Result<Toke
continue;
};
- // TODO: Replace below with `extract_if` when MSRV is bumped above 1.85.
- let before_len = f.attrs.len();
- f.attrs.retain(|attr| !attr.path().is_ident("test"));
- if f.attrs.len() == before_len {
+ if f.attrs
+ .extract_if(.., |attr| attr.path().is_ident("test"))
+ .count()
+ == 0
+ {
processed_items.push(Item::Fn(f));
continue;
}
diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
index 0c36194d9971..2cfd59e0f9e7 100644
--- a/rust/macros/lib.rs
+++ b/rust/macros/lib.rs
@@ -6,6 +6,9 @@
// and thus add a dependency on `include/config/RUSTC_VERSION_TEXT`, which is
// touched by Kconfig when the version string from the compiler changes.
+// Stable since Rust 1.87.0.
+#![feature(extract_if)]
+//
// Stable since Rust 1.88.0 under a different name, `proc_macro_span_file`,
// which was added in Rust 1.88.0. This is why `cfg_attr` is used here, i.e.
// to avoid depending on the full `proc_macro_span` on Rust >= 1.88.0.
--
2.53.0
^ permalink raw reply related
* [PATCH v2 07/33] rust: allow globally `clippy::incompatible_msrv`
From: Miguel Ojeda @ 2026-04-05 23:52 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: <20260405235309.418950-1-ojeda@kernel.org>
`clippy::incompatible_msrv` is not buying us much, and we discussed
allowing it several times in the past.
For instance, there was recently another patch sent to `allow` it where
needed [1]. While that particular case would not be needed after the
minimum version bump to 1.85.0, it is simpler to just allow it to prevent
future instances.
Thus do so, and remove the last instance of locally allowing it we have
in the tree (except the one in the vendored `proc_macro2` crate).
Note that we still keep the `msrv` config option in `clippy.toml` since
that affects other lints as well.
Link: https://lore.kernel.org/rust-for-linux/20260404212831.78971-4-jhubbard@nvidia.com/ [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Makefile | 1 +
rust/macros/helpers.rs | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a63684c36d60..78f5ee173eda 100644
--- a/Makefile
+++ b/Makefile
@@ -486,6 +486,7 @@ export rust_common_flags := --edition=2021 \
-Wclippy::as_underscore \
-Wclippy::cast_lossless \
-Wclippy::ignored_unit_patterns \
+ -Aclippy::incompatible_msrv \
-Wclippy::mut_mut \
-Wclippy::needless_bitwise_bool \
-Aclippy::needless_lifetimes \
diff --git a/rust/macros/helpers.rs b/rust/macros/helpers.rs
index 37ef6a6f2c85..d18fbf4daa0a 100644
--- a/rust/macros/helpers.rs
+++ b/rust/macros/helpers.rs
@@ -49,7 +49,6 @@ pub(crate) fn file() -> String {
}
#[cfg(CONFIG_RUSTC_HAS_SPAN_FILE)]
- #[allow(clippy::incompatible_msrv)]
{
proc_macro::Span::call_site().file()
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 01/33] rust: kbuild: remove `--remap-path-prefix` workarounds
From: Miguel Ojeda @ 2026-04-05 23:52 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: <20260405235309.418950-1-ojeda@kernel.org>
Commit 8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix
to make paths relative"") removed `--remap-path-prefix` from the build
system, so the workarounds are not needed anymore.
Thus remove them.
Note that the flag has landed again in parallel in this cycle in
commit dda135077ecc ("rust: build: remap path to avoid absolute path"),
together with `--remap-path-scope=macro` [1]. However, they are gated on
`rustc-option-yn, --remap-path-scope=macro`, which means they are both
only passed starting with Rust 1.95.0 [2]:
`--remap-path-scope` is only stable in Rust 1.95, so use `rustc-option`
to detect its presence. This feature has been available as
`-Zremap-path-scope` for all versions that we support; however due to
bugs in the Rust compiler, it does not work reliably until 1.94. I opted
to not enable it for 1.94 as it's just a single version that we missed.
In turn, that means the workarounds removed here should not be needed
again (even with the flag added again above), since:
- `rustdoc` now recognizes the `--remap-path-prefix` flag since Rust
1.81.0 [3] (even if it is still an unstable feature [4]).
- The Internal Compiler Error [5] that the comment mentions was fixed in
Rust 1.87.0 [6]. We tested that was the case in a previous version
of this series by making the workaround conditional [7][8].
...which are both older versions than Rust 1.95.0.
We will still need to skip `--remap-path-scope` for `rustdoc` though,
since `rustdoc` does not support that one yet [4].
Link: https://github.com/rust-lang/rust/issues/111540 [1]
Link: https://github.com/rust-lang/rust/pull/147611 [2]
Link: https://github.com/rust-lang/rust/pull/107099 [3]
Link: https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#--remap-path-prefix-remap-source-code-paths-in-output [4]
Link: https://github.com/rust-lang/rust/issues/138520 [5]
Link: https://github.com/rust-lang/rust/pull/138556 [6]
Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-9-ojeda@kernel.org/ [7]
Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-10-ojeda@kernel.org/ [8]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
rust/Makefile | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/rust/Makefile b/rust/Makefile
index 96cd7d8e6ee9..16ea720e0a8e 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -145,14 +145,10 @@ rustdoc_modifiers_workaround := $(if $(call rustc-min-version,108800),-Cunsafe-a
# Similarly, for doctests (https://github.com/rust-lang/rust/issues/146465).
doctests_modifiers_workaround := $(rustdoc_modifiers_workaround)$(if $(call rustc-min-version,109100),$(comma)sanitizer)
-# `rustc` recognizes `--remap-path-prefix` since 1.26.0, but `rustdoc` only
-# since Rust 1.81.0. Moreover, `rustdoc` ICEs on out-of-tree builds since Rust
-# 1.82.0 (https://github.com/rust-lang/rust/issues/138520). Thus workaround both
-# issues skipping the flag. The former also applies to `RUSTDOC TK`.
quiet_cmd_rustdoc = RUSTDOC $(if $(rustdoc_host),H, ) $<
cmd_rustdoc = \
OBJTREE=$(abspath $(objtree)) \
- $(RUSTDOC) $(filter-out $(skip_flags) --remap-path-prefix=%,$(if $(rustdoc_host),$(rust_common_flags),$(rust_flags))) \
+ $(RUSTDOC) $(filter-out $(skip_flags),$(if $(rustdoc_host),$(rust_common_flags),$(rust_flags))) \
$(rustc_target_flags) -L$(objtree)/$(obj) \
-Zunstable-options --generate-link-to-definition \
--output $(rustdoc_output) \
@@ -338,7 +334,7 @@ quiet_cmd_rustdoc_test_kernel = RUSTDOC TK $<
rm -rf $(objtree)/$(obj)/test/doctests/kernel; \
mkdir -p $(objtree)/$(obj)/test/doctests/kernel; \
OBJTREE=$(abspath $(objtree)) \
- $(RUSTDOC) --test $(filter-out --remap-path-prefix=%,$(rust_flags)) \
+ $(RUSTDOC) --test $(rust_flags) \
-L$(objtree)/$(obj) --extern ffi --extern pin_init \
--extern kernel --extern build_error --extern macros \
--extern bindings --extern uapi \
--
2.53.0
^ permalink raw reply related
* [PATCH v2 00/33] rust: bump minimum Rust and `bindgen` versions
From: Miguel Ojeda @ 2026-04-05 23:52 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:
- A few cleanups that can be performed before the bumps.
- The Rust bump (and its cleanups).
- The `bindgen` bump (and its 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]
---
v1: https://lore.kernel.org/rust-for-linux/20260401114540.30108-1-ojeda@kernel.org/
v2:
- Added patch to globally allow `incompatible_msrv` and removed the
last instance.
- Replaced `--remap-path-prefix` patches with one that drops the
workaround entirely (and place it as the first one) and summarizes
the discussion.
I also noticed that `--remap-path-prefix` for `rustdoc` is still
unstable (unlike `rustc`'s one), so I added it to our list as usual
(https://github.com/Rust-for-Linux/linux/issues/2). There does not
seem to be a tracking issue, so I asked upstream about it.
We will need these two lines as the resolution for the conflict:
$(RUSTDOC) $(filter-out $(skip_flags) --remap-path-scope=%,$(if $(rustdoc_host),$(rust_common_flags),$(rust_flags))) \
$(RUSTDOC) --test $(filter-out --remap-path-scope=%,$(rust_flags)) \
- Reworked the `extract_if` patch to use it (unstably). The feature
last major change happened in Rust 1.85.0, so that is fine.
- Moved `$(HOSTRUSTFLAGS)` below so that per-version flags (like
lints) can be overridden too. Please see the details in the commit
and my reply to v1.
- Added `feature(extract_if)` and `feature(non_null_convenience)`
items to https://github.com/Rust-for-Linux/linux/issues/1223.
Then reworded the commits accordingly to include the references
to tracking issues and PRs.
- Other rewords, e.g. the "beyond" typo.
- Rebased on top of `rust-next`.
- Picked up tags.
Alice Ryhl (1):
rust: declare cfi_encoding for lru_status
Miguel Ojeda (32):
rust: kbuild: remove `--remap-path-prefix` workarounds
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`
rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
rust: bump Clippy's MSRV and clean `incompatible_msrv` allows
rust: allow globally `clippy::incompatible_msrv`
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: transmute: simplify code with Rust 1.80.0 `split_at_*checked()`
rust: alloc: simplify with `NonNull::add()` now that it is stable
rust: macros: simplify code using `feature(extract_if)`
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 `bindgen` 0.66.[01]
rust: rust_is_available: remove warning for `bindgen` < 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
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 | 12 +++-
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 | 31 ++--------
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/helpers.rs | 1 -
rust/macros/kunit.rs | 9 +--
rust/macros/lib.rs | 3 +
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 +------------------
39 files changed, 83 insertions(+), 451 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
base-commit: 36f5a2b09e650b82d7b2a106e3b93af48c2010d9
--
2.53.0
^ permalink raw reply
* Re: [PATCH 1/2] pmdomain/rockchip: skip QoS operations for idle-only domains
From: Jonas Karlman @ 2026-04-05 23:29 UTC (permalink / raw)
To: Shawn Lin, Daniel Bozeman, finley.xiao@rock-chips.com
Cc: ulf.hansson@linaro.org, heiko@sntech.de, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <f1b9a97a-f1f9-0757-5dc7-33960318be61@rock-chips.com>
Hi,
On 4/4/2026 1:40 PM, Shawn Lin wrote:
> + Jonas
>
> 在 2026/04/04 星期六 5:27, Daniel Bozeman 写道:
>> I ran both tests you requested:
>>
>> Test 1: Added pr_err to rockchip_pd_power_on/off to identify
>> the crashing domain. With patch 2 only (skip EPROBE_DEFER),
>> the crash occurs on PD_VO:
>
> Thanks for fing the PD_VO, and I'm still requesting more docs internally
> to check what's going on. I see there are several qos nodes under PD_VO,
> but I'm not sure if they all belong to PD_VO and even not sure if their
> registers are define correctly.
>
> Perhaps, could you help dig more by removing the qos one by one from
> PD_VO to narrow down the broken qos?
>
> I also loop in Jonas who submited the code, to have a look.(I'm also
> surprised to see there aren't any Qos nodes under PD_VO in vendor
> kernel for reference, but upstream code has...)
Upstream included all QoS that seemed to be related to each power domains
based on e.g. vendor DTs, clock driver and other hints.
Vendor kernel mostly seemed to take the easy way out and flagged all
rk3528 power domains as always on or similar, if I recall correctly.
For upstream we have instead tried to describe all power domains without
any always on flag and instead ensure all devices belong to a power
domain.
I do not have access to any rk3528 TRM or similar, so I would not be
surprised if there could be some wrong details. However, runtime
testing at time of patches was sent upstream did not show any issues.
I was however able to reproduce a crash using next-20260403 + rk3528 usb
series [1][2]. Such crash was not happening at the original submission
of the pmdomain or usb series.
Looking at pmdomain core and rk pmdomain driver changes since rk3528
merge I see that there are some changes that may have changed behavior
of the driver since initial rk3528 merge. I.e. GENPD_FLAG_NO_STAY_ON.
Following quick diff seem to remove any changed behavior introduced in
commit 2bc12a8199a0 ("pmdomain: rockchip: Fix regulator dependency with
GENPD_FLAG_NO_STAY_ON"), and fixes the crash for me.
diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
index 490bbb1d1d8e..4d69b9f68886 100644
--- a/drivers/pmdomain/rockchip/pm-domains.c
+++ b/drivers/pmdomain/rockchip/pm-domains.c
@@ -892,7 +892,9 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu,
pd->genpd.power_on = rockchip_pd_power_on;
pd->genpd.attach_dev = rockchip_pd_attach_dev;
pd->genpd.detach_dev = rockchip_pd_detach_dev;
- pd->genpd.flags = GENPD_FLAG_PM_CLK | GENPD_FLAG_NO_STAY_ON;
+ pd->genpd.flags = GENPD_FLAG_PM_CLK;
+ if (pd->info->pwr_mask || pd->info->status_mask)
+ pd->genpd.flags |= GENPD_FLAG_NO_STAY_ON;
if (pd_info->active_wakeup)
pd->genpd.flags |= GENPD_FLAG_ACTIVE_WAKEUP;
pm_genpd_init(&pd->genpd, NULL,
Could also be that GENPD_FLAG_NO_STAY_ON only need to be applied to
need_regulator domains?
[1] https://lore.kernel.org/r/20250723122323.2344916-1-jonas@kwiboo.se/
[2] https://github.com/Kwiboo/linux-rockchip/commits/next-20260403-rk3528/
Regards,
Jonas
>
>>
>> rockchip_pd_power_off: vo pwr_mask=0x0
>> Internal error: synchronous external abort: 0000000096000010
>> Workqueue: pm genpd_power_off_work_fn
>> Call trace:
>> regmap_mmio_read32le+0x8/0x20
>> _regmap_bus_reg_read+0x6c/0xac
>> _regmap_read+0x60/0xd8
>> regmap_read+0x4c/0x7c
>> rockchip_pmu_set_idle_request.isra.0+0x98/0x16c
>> rockchip_pd_power+0x130/0x48c
>> rockchip_pd_power_off+0x38/0x48
>> genpd_power_off.isra.0+0x1f0/0x2f0
>> genpd_power_off_work_fn+0x34/0x54
>>
>> Test 2: Same debug build, booted with clk_ignore_unused
>> added to kernel cmdline via U-Boot. Same crash, same domain:
>>
>> rockchip_pd_power_off: vo pwr_mask=0x0
>> Internal error: synchronous external abort: 0000000096000010
>> (identical call trace)
>>
>> The crash occurs even with clk_ignore_unused. The QoS
>> registers for PD_VO are inaccessible when genpd attempts
>> to power off this idle-only domain.
>>
^ permalink raw reply related
* Re: [PATCH 32/33] rust: kbuild: support global per-version flags
From: Miguel Ojeda @ 2026-04-05 23:15 UTC (permalink / raw)
To: Gary Guo, Nathan Chancellor, Nicolas Schier
Cc: Miguel Ojeda, 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, Boqun Feng, 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: <DHHX9O7V06VZ.G0N1CQ7BUKFO@garyguo.net>
On Thu, Apr 2, 2026 at 12:28 AM Gary Guo <gary@garyguo.net> wrote:
>
> I think I would prefer moving these down.
>
> The current approach append the flags to all variables, which will cause the
> following equivalence to stop holding after the flag update.
>
> KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
> -Zallow-features= $(HOSTRUSTFLAGS)
>
> (Per version flags doesn't go before -O anymore, it comes after HOSTRUSTFLAGS).
[ For context for others, Sashiko reported the same and we also talked
about it in a Rust for Linux call. ]
I have been thinking about this, and about potential other ways to
achieve the same thing. I think the best at the moment is to move just
the `$(HOSTRUSTFLAGS)` below, but not the rest.
The reason is that it is closer to what we do with other user (kernel)
flags (e.g. arch flags come after the general ones). But I am
wondering if we should/could set all the user variables later in the
`Makefile` in general `HOST*FLAGS` later in the `Makefile`.
In fact, there is already a limitation with the host flags: `-Werror`,
i.e. that one gets appended later, and so users cannot override it.
This may be considered a bug, because commit 7ded7d37e5f5
("scripts/Makefile.extrawarn: Respect CONFIG_WERROR / W=e for
hostprogs") says:
While it is
possible to avoid this behavior by passing HOSTCFLAGS=-w or
HOSTCFLAGS=-Wno-error, it may not be the most intuitive for regular
users not intimately familiar with Kbuild.
But passing `HOSTCFLAGS=-Wno-error` doesn't work, since it comes
earlier (`-w` does work, but because it turns off everything).
I am also a bit confused with:
While this means there is a small portion of
the build that does not have -Werror enabled (namely scripts/kconfig/*
and scripts/basic/fixdep)
because it gets enabled in the build (I think it is referring to other
targets like the config ones).
Anyway, for now I moved the expansion of `HOSTRUSTFLAGS` in v2. If
Kbuild (Nathan, Nicolas) think it is a good idea to do one of the
bigger changes (e.g. for more `HOST*` flags, appending it even later),
then we can do it afterwards.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: rp1: Add PWM node
From: Uwe Kleine-König @ 2026-04-05 21:48 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <ef79e974c6680202294a4cfde7cc791753bf1b3e.1775223441.git.andrea.porta@suse.com>
[-- Attachment #1: Type: text/plain, Size: 149 bytes --]
Hello,
The "rp1" in the Subject is very irritating. Better make this:
arm64: dts: broadcom: rpi-5: Add rp1 PWM node
or similar.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-05 21:45 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <28e29fbfc20c0b8a115d006233c2759d8f49e639.1775223441.git.andrea.porta@suse.com>
[-- Attachment #1: Type: text/plain, Size: 10393 bytes --]
Hello Andrea,
On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> From: Naushir Patuck <naush@raspberrypi.com>
>
> The Raspberry Pi RP1 southbridge features an embedded PWM
> controller with 4 output channels, alongside an RPM interface
> to read the fan speed on the Raspberry Pi 5.
>
> Add the supporting driver.
>
> Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> ---
> drivers/pwm/Kconfig | 10 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-rp1.c | 244 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 255 insertions(+)
> create mode 100644 drivers/pwm/pwm-rp1.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 6f3147518376a..22e4fc6385da2 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -625,6 +625,16 @@ config PWM_ROCKCHIP
> Generic PWM framework driver for the PWM controller found on
> Rockchip SoCs.
>
> +config PWM_RP1
I prefer PWM_RASPBERRYPI1, or PWM_RASPBERRYPI_RP1 here.
> + tristate "RP1 PWM support"
> + depends on MISC_RP1 || COMPILE_TEST
> + depends on HWMON
> + help
> + PWM framework driver for Raspberry Pi RP1 controller
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-rp1.
> +
> config PWM_SAMSUNG
> tristate "Samsung PWM support"
> depends on PLAT_SAMSUNG || ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 0dc0d2b69025d..895a7c42fe9c0 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -56,6 +56,7 @@ obj-$(CONFIG_PWM_RENESAS_RZG2L_GPT) += pwm-rzg2l-gpt.o
> obj-$(CONFIG_PWM_RENESAS_RZ_MTU3) += pwm-rz-mtu3.o
> obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
> obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
> +obj-$(CONFIG_PWM_RP1) += pwm-rp1.o
> obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
> obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o
> obj-$(CONFIG_PWM_SL28CPLD) += pwm-sl28cpld.o
> diff --git a/drivers/pwm/pwm-rp1.c b/drivers/pwm/pwm-rp1.c
> new file mode 100644
> index 0000000000000..0a1c1c1dd27e9
> --- /dev/null
> +++ b/drivers/pwm/pwm-rp1.c
> @@ -0,0 +1,244 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * pwm-rp1.c
> + *
> + * Raspberry Pi RP1 PWM.
> + *
> + * Copyright © 2026 Raspberry Pi Ltd.
> + *
> + * Author: Naushir Patuck (naush@raspberrypi.com)
> + *
> + * Based on the pwm-bcm2835 driver by:
> + * Bart Tanghe <bart.tanghe@thomasmore.be>
> + */
Please add a paragraph here named "Limitations" in the same format as
several other drivers describing how the driver behaves on disable and
configuration changes (can glitches occur? Is the currently running
period completed or aborted?)
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +
> +#define PWM_GLOBAL_CTRL 0x000
> +#define PWM_CHANNEL_CTRL(x) (0x014 + ((x) * 0x10))
> +#define PWM_RANGE(x) (0x018 + ((x) * 0x10))
> +#define PWM_PHASE(x) (0x01C + ((x) * 0x10))
> +#define PWM_DUTY(x) (0x020 + ((x) * 0x10))
> +
> +/* 8:FIFO_POP_MASK + 0:Trailing edge M/S modulation */
> +#define PWM_CHANNEL_DEFAULT (BIT(8) + BIT(0))
> +#define PWM_CHANNEL_ENABLE(x) BIT(x)
> +#define PWM_POLARITY BIT(3)
> +#define SET_UPDATE BIT(31)
> +#define PWM_MODE_MASK GENMASK(1, 0)
> +
> +#define NUM_PWMS 4
Please prefix all #defines by something driver specific (e.g. RP1_PWM_).
> +
> +struct rp1_pwm {
> + void __iomem *base;
> + struct clk *clk;
> +};
> +
> +static const struct hwmon_channel_info * const rp1_fan_hwmon_info[] = {
> + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT),
> + NULL
> +};
> +
> +static umode_t rp1_fan_hwmon_is_visible(const void *data, enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + umode_t mode = 0;
> +
> + if (type == hwmon_fan && attr == hwmon_fan_input)
> + mode = 0444;
> +
> + return mode;
> +}
> +
> +static int rp1_fan_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val)
> +{
> + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> +
> + if (type != hwmon_fan || attr != hwmon_fan_input)
> + return -EOPNOTSUPP;
> +
> + *val = readl(rp1->base + PWM_PHASE(2));
> +
> + return 0;
> +}
I don't like having hwmon bits in pwm drivers. Is the PWM only usable
for a fan? I guess the hwmon parts should be dropped and a pwm-fan
defined in dt.
> +static const struct hwmon_ops rp1_fan_hwmon_ops = {
> + .is_visible = rp1_fan_hwmon_is_visible,
> + .read = rp1_fan_hwmon_read,
> +};
> +
> +static const struct hwmon_chip_info rp1_fan_hwmon_chip_info = {
> + .ops = &rp1_fan_hwmon_ops,
> + .info = rp1_fan_hwmon_info,
> +};
> +
> +static void rp1_pwm_apply_config(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + u32 value;
> +
> + value = readl(rp1->base + PWM_GLOBAL_CTRL);
> + value |= SET_UPDATE;
> + writel(value, rp1->base + PWM_GLOBAL_CTRL);
> +}
> +
> +static int rp1_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> +
> + writel(PWM_CHANNEL_DEFAULT, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
Please add a comment about what this does.
> + return 0;
> +}
> +
> +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + u32 value;
> +
> + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> + value &= ~PWM_MODE_MASK;
> + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> +
> + rp1_pwm_apply_config(chip, pwm);
What is the purpose of this call?
> +}
> +
> +static int rp1_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + unsigned long clk_rate = clk_get_rate(rp1->clk);
> + unsigned long clk_period;
> + u32 value;
> +
> + if (!clk_rate) {
> + dev_err(&chip->dev, "failed to get clock rate\n");
> + return -EINVAL;
> + }
> +
> + /* set period and duty cycle */
> + clk_period = DIV_ROUND_CLOSEST(NSEC_PER_SEC, clk_rate);
DIV_ROUND_CLOSEST is wrong here. (I don't go into details as .apply()
should be dropped.)
> + writel(DIV_ROUND_CLOSEST(state->duty_cycle, clk_period),
Dividing by the result of a division loses precision.
> + rp1->base + PWM_DUTY(pwm->hwpwm));
> +
> + writel(DIV_ROUND_CLOSEST(state->period, clk_period),
> + rp1->base + PWM_RANGE(pwm->hwpwm));
> +
> + /* set polarity */
> + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> + if (state->polarity == PWM_POLARITY_NORMAL)
> + value &= ~PWM_POLARITY;
> + else
> + value |= PWM_POLARITY;
> + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> +
> + /* enable/disable */
> + value = readl(rp1->base + PWM_GLOBAL_CTRL);
> + if (state->enabled)
> + value |= PWM_CHANNEL_ENABLE(pwm->hwpwm);
> + else
> + value &= ~PWM_CHANNEL_ENABLE(pwm->hwpwm);
> + writel(value, rp1->base + PWM_GLOBAL_CTRL);
> +
> + rp1_pwm_apply_config(chip, pwm);
> +
> + return 0;
> +}
> +
> +static const struct pwm_ops rp1_pwm_ops = {
> + .request = rp1_pwm_request,
> + .free = rp1_pwm_free,
> + .apply = rp1_pwm_apply,
Please implement the waveform callbacks instead of .apply().
> +};
> +
> +static int rp1_pwm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device *hwmon_dev;
> + struct pwm_chip *chip;
> + struct rp1_pwm *rp1;
> + int ret;
> +
> + chip = devm_pwmchip_alloc(dev, NUM_PWMS, sizeof(*rp1));
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> +
> + rp1 = pwmchip_get_drvdata(chip);
> +
> + rp1->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(rp1->base))
> + return PTR_ERR(rp1->base);
> +
> + rp1->clk = devm_clk_get_enabled(dev, NULL);
> + if (IS_ERR(rp1->clk))
> + return dev_err_probe(dev, PTR_ERR(rp1->clk), "clock not found\n");
Please start error messages with a capital letter.
> +
> + ret = devm_clk_rate_exclusive_get(dev, rp1->clk);
After this call you can determine the rate just once and fail if it's ==
0.
> + if (ret)
> + return dev_err_probe(dev, ret, "fail to get exclusive rate\n");
> +
> + chip->ops = &rp1_pwm_ops;
> +
> + platform_set_drvdata(pdev, chip);
> +
> + ret = devm_pwmchip_add(dev, chip);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register PWM chip\n");
> +
> + hwmon_dev = devm_hwmon_device_register_with_info(dev, "rp1_fan_tach", rp1,
> + &rp1_fan_hwmon_chip_info,
> + NULL);
> +
> + if (IS_ERR(hwmon_dev))
> + return dev_err_probe(dev, PTR_ERR(hwmon_dev),
> + "failed to register hwmon fan device\n");
> +
> + return 0;
> +}
> +
> +static int rp1_pwm_suspend(struct device *dev)
> +{
> + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(rp1->clk);
> +
> + return 0;
> +}
> +
> +static int rp1_pwm_resume(struct device *dev)
> +{
> + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> +
> + return clk_prepare_enable(rp1->clk);
Hmm, if this fails and then the driver is unbound, the clk operations
are not balanced.
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(rp1_pwm_pm_ops, rp1_pwm_suspend, rp1_pwm_resume);
> +
> +static const struct of_device_id rp1_pwm_of_match[] = {
> + { .compatible = "raspberrypi,rp1-pwm" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, rp1_pwm_of_match);
> +
> +static struct platform_driver rp1_pwm_driver = {
> + .probe = rp1_pwm_probe,
> + .driver = {
> + .name = "rp1-pwm",
> + .of_match_table = rp1_pwm_of_match,
> + .pm = pm_ptr(&rp1_pwm_pm_ops),
> + },
> +};
> +module_platform_driver(rp1_pwm_driver);
> +
> +MODULE_DESCRIPTION("RP1 PWM driver");
> +MODULE_AUTHOR("Naushir Patuck <naush@raspberrypi.com>");
> +MODULE_LICENSE("GPL");
> --
> 2.35.3
>
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v6 0/5] Add CCI and imx577 sensor support for Talos evk
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Loic Poulain, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Robert Foss, Todor Tomov,
Bryan O'Donoghue, Vladimir Zapolskiy, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Frank Li, Wenmeng Liu
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
imx, linux-arm-kernel, Krzysztof Kozlowski, Konrad Dybcio,
Dmitry Baryshkov
In-Reply-To: <20260305-sm6150_evk-v6-0-38ce4360d5e0@oss.qualcomm.com>
On Thu, 05 Mar 2026 17:48:11 +0800, Wenmeng Liu wrote:
> Talos EVK is based on the Qualcomm SM6150 SoC.
> It lacks a camera sensor in its default configuration.
> This series adds CCI support and enables the IMX577 sensor via CSIPHY1
> through device tree overlay.
>
> We have tested IMX577 Sensor on CCI1 with following commands:
> - media-ctl -d /dev/media0 --reset
> - media-ctl -d /dev/media0 -V '"imx577 1-001a":0[fmt:SRGGB10/4056x3040 field:none]'
> - media-ctl -d /dev/media0 -V '"msm_csiphy1":0[fmt:SRGGB10/4056x3040]'
> - media-ctl -d /dev/media0 -V '"msm_csid0":0[fmt:SRGGB10/4056x3040]'
> - media-ctl -d /dev/media0 -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4056x3040]'
> - media-ctl -d /dev/media0 -l '"msm_csiphy1":1->"msm_csid0":0[1]'
> - media-ctl -d /dev/media0 -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
> - yavta -B capture-mplane -n 5 -f SRGGB10P -s 4056x3040 -F /dev/video0 --capture=5
>
> [...]
Applied, thanks!
[2/5] arm64: dts: qcom: talos: Add camss node
commit: c0b357d5d059812e5b48fab81270d8f4c8f62162
[3/5] arm64: dts: qcom: talos: Add CCI definitions
commit: 17ba0a3c874684c9ca5a41ddf9f167648b10aad2
[4/5] arm64: dts: qcom: talos: Add camera MCLK pinctrl
commit: fd3850cde71f284ca69f70b904df78f561ece103
[5/5] arm64: dts: qcom: talos-evk-camera: Add DT overlay
commit: 594be93cdc9dcfec5d10882ed3fccce1e3af9015
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Maxime Coquelin,
Alexandre Torgue, linux-arm-msm, linux-clk, linux-kernel,
linux-stm32, linux-arm-kernel, Krzysztof Kozlowski
In-Reply-To: <20260331091721.61613-3-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 31 Mar 2026 11:17:22 +0200, Krzysztof Kozlowski wrote:
> The static 'struct qcom_cc_driver_data' contains probe match-like data
> and is not modified: neither by the driver defining it nor by common.c
> code using it.
>
> Make it const for code safety and code readability.
>
>
> [...]
Applied, thanks!
[2/2] clk: qcom: Constify list of critical CBCR registers
commit: 87df31ea43eef5f6b9e7be0fa2555e58a9455e05
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/3] pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
From: Andre Przywara @ 2026-04-05 15:27 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, linux-gpio, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <CAGb2v64A0rgiMkTCdvq-pVfzCTqWKqc=nx69B9tD7A8_E7vHUg@mail.gmail.com>
On Fri, 27 Mar 2026 19:38:57 +0800
Chen-Yu Tsai <wens@kernel.org> wrote:
Hi Linus,
> On Fri, Mar 27, 2026 at 7:30 PM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when
> > that line is muxed for IRQ triggering (muxval 6), but only if it's
> > explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this
> > behaviour, so we added a optional workaround, triggered by a quirk bit,
> > which triggers remuxing the pin when it's configured for IRQ, while we
> > need to read its value.
> >
> > For some reasons this quirk flag was copied over to newer SoCs, even
> > though they don't show this behaviour, and the GPIO data register
> > reflects the true GPIO state even with a pin muxed to IRQ trigger.
> >
> > Remove the unneeded quirk from the A523 family, where it's definitely
> > not needed (confirmed by experiments), and where it actually breaks,
> > because the workaround is not compatible with the newer generation
> > pinctrl IP used in that chip.
> >
> > Together with a DT change this fixes GPIO IRQ operation on the A523
> > family of SoCs, as for instance used for the SD card detection.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports")
>
> Acked-by: Chen-Yu Tsai <wens@kernel.org>
Can you possibly take this patch and maybe the binding (PATCH v2 2/3)?
Ideally still for v7.0? IIUC Chen-Yu would take the DT patch, but
relies on those two here.
Thanks,
Andre
>
> > ---
> > drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 1 -
> > drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c | 1 -
> > 2 files changed, 2 deletions(-)
> >
> > diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> > index 69cd2b4ebd7d..462aa1c4a5fa 100644
> > --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> > +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> > @@ -26,7 +26,6 @@ static const u8 a523_r_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
> > static struct sunxi_pinctrl_desc a523_r_pinctrl_data = {
> > .irq_banks = ARRAY_SIZE(a523_r_irq_bank_map),
> > .irq_bank_map = a523_r_irq_bank_map,
> > - .irq_read_needs_mux = true,
> > .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> > .pin_base = PL_BASE,
> > };
> > diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> > index 7d2308c37d29..b6f78f1f30ac 100644
> > --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> > +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> > @@ -26,7 +26,6 @@ static const u8 a523_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
> > static struct sunxi_pinctrl_desc a523_pinctrl_data = {
> > .irq_banks = ARRAY_SIZE(a523_irq_bank_map),
> > .irq_bank_map = a523_irq_bank_map,
> > - .irq_read_needs_mux = true,
> > .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> > };
> >
> > --
> > 2.43.0
> >
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox