* [PATCH v2 0/2] arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable i2c3 on 40-pin header
From: Ricardo Pardini via B4 Relay @ 2026-06-24 15:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Ricardo Pardini
The Radxa NIO 12L exposes i2c3 (SDA3/SCL3, GPIO14/GPIO15) on its 40-pin
GPIO header, on the blue-colored pins 27 (SCL3) and 28 (SDA3).
Enable the i2c3 controller, add the matching pinctrl configuration and run
the bus at 400 kHz, matching the other I2C buses already enabled on this
board.
While at it, drop a pre-existing redundant drive-strength from i2c2_pins
that was also about to be copied into i2c3: specifying both drive-strength
(mA) and drive-strength-microamp (uA) makes the generic pinconf parser log
"cannot have multiple drive strength properties" at boot, and the advanced
(uA) setting wins in hardware, leaving the mA value dead.
Tested using a SD1306 I2C OLED display.
---
Changes in v2:
- Add a drive-by patch dropping the redundant drive-strength in i2c2_pins
(via Claude, reported by Sashiko).
- i2c3: use only drive-strength-microamp, as per Sashiko's review.
- Link to v1: https://patch.msgid.link/20260624-nio-12l-add-i2c-40-pin-v1-1-f6c11ed2184c@pardini.net
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Matthias Brugger <matthias.bgg@gmail.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
Ricardo Pardini (2):
arm64: dts: mediatek: mt8395-radxa-nio-12l: Drop redundant i2c2 drive-strength
arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable i2c3 on 40-pin header
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260624-nio-12l-add-i2c-40-pin-19e0482fd835
Best regards,
--
Ricardo Pardini <ricardo@pardini.net>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable i2c3 on 40-pin header
From: Ricardo Pardini via B4 Relay @ 2026-06-24 15:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Ricardo Pardini
In-Reply-To: <20260624-nio-12l-add-i2c-40-pin-v2-0-cf3707a6aaf1@pardini.net>
From: Ricardo Pardini <ricardo@pardini.net>
i2c3 (SDA3/SCL3 on GPIO14/GPIO15) is routed to the 40-pin GPIO header,
exposed on the blue-colored pins 27 (SCL3) and 28 (SDA3). Enable the
controller and add the corresponding pin configuration in the pinctrl
node so users can use external I2C devices.
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index 589a5f07d5dde..9b0966c271cb5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -371,6 +371,14 @@ it5205_sbu_mux: endpoint {
};
};
+/* Exposed on 40-pin header (blue-colored pins 27:SCL3 28:SDA3) */
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c3_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&i2c4 {
clock-frequency = <400000>;
pinctrl-0 = <&i2c4_pins>;
@@ -788,6 +796,15 @@ pins-bus {
};
};
+ i2c3_pins: i2c3-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO14__FUNC_SDA3>,
+ <PINMUX_GPIO15__FUNC_SCL3>;
+ bias-pull-up = <1000>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+
i2c4_pins: i2c4-pins {
pins-bus {
pinmux = <PINMUX_GPIO16__FUNC_SDA4>,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 7/7] ARM: dts: rockchip: Add Alientek DLRV1126
From: Andrew Lunn @ 2026-06-24 15:44 UTC (permalink / raw)
To: Yanan He
Cc: robh, krzk+dt, conor+dt, heiko, andrew+netdev, davem, edumazet,
kuba, pabeni, david.wu, mcoquelin.stm32, alexandre.torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-7-dc42d99f75a7@gmail.com>
> The board consists of a CLRV1126F core module and a DLRV1126 carrier
> board. The core module contains the RV1126 SoC, eMMC and RK809 PMIC,
> while the carrier board provides Ethernet, SD card, AP6212 WiFi and
> Bluetooth, PCF8563 RTC, ADC keys, GPIO LEDs and audio connectors.
>
> The board has been tested with Ethernet/NFS boot, eMMC, SD card, SDIO
> WiFi enumeration, Bluetooth LE scanning, RTC, ADC keys, GPIO LEDs and
> RK809 audio card registration.
Ah, here is the networking nodes. But why was it not threaded to the
rest of the series?
> +&gmac {
> + phy-mode = "rgmii";
> + clock_in_out = "input";
> + assigned-clocks = <&cru CLK_GMAC_SRC>, <&cru CLK_GMAC_TX_RX>,
> + <&cru CLK_GMAC_ETHERNET_OUT>;
> + assigned-clock-parents = <&cru CLK_GMAC_SRC_M1>,
> + <&cru RGMII_MODE_CLK>;
> + assigned-clock-rates = <125000000>, <0>, <25000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmiim1_miim &rgmiim1_bus2 &rgmiim1_bus4
> + &clk_out_ethernetm1_pins>;
> + tx_delay = <0x2a>;
> + rx_delay = <0x1a>;
As i predicted, this is wrong.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
Please try removing rx_delay, rx_delay and setting phy-mode to
rgmii-id.
Andrew
^ permalink raw reply
* Re: [PATCH v15 00/11] arm64: entry: Convert to Generic Entry
From: Ada Couprie Diaz @ 2026-06-24 15:44 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <ec181396-e398-4ce2-8cb8-10d7bdfeed61@arm.com>
Hi Jinjie,
On 17/06/2026 17:27, Ada Couprie Diaz wrote:
> Hi Jinjie,
>
> On 11/05/2026 10:20, Jinjie Ruan wrote:
>> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
>> maintainers' work easier and codes more elegant. arm64 has already
>> successfully switched to the Generic IRQ Entry in commit
>> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
>> time to completely convert arm64 to Generic Entry.
>>
>> [...]
> [...], when combining pseudo-NMIs with PREEMPT_RT under heavy pNMI load,
> I was able to trigger a new warning compared to upstream :
>
> BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
>
> Specifically, this was when running `stress-ng --all 100 --class vm -t
> 300` with
> `perf top -a -e 'cycles'` in another shell.
>
> This does not feel like a major issue : from my understanding it only
> happens
> when running the full suite for some time and with many stressors (I
> was not
> able to reproduce it by running individual tests), and flooding the
> system with
> pseudo-NMIs.
>
> Given that this only happen with PREEMPT_RT, my guess is that it
> interacts
> with generic entry in a way that can lead to more nesting than before,
> leading to an easier exhaustion of the limit on lockdep.
> As the system was still able to recover and did not lock up, I think
> it can be OK
> as-is, or simply bumped a bit ? Happy for more opinions on that.
>
>
> Otherwise, this is
> Tested-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
>
> As this is an important change, any other testing, especially on real
> workloads
> as well as on very large systems (which we haven't covered), would be
> very welcome !
>
>
> I will take some time soon to review this latest version, now that I
> am able to.
I went through the series and only had some minor nitpicks, and some small
worries about the intentionality of the behaviour changes in patch 7.
It also feels like the above bug is more of a stress limit being easier
to reach
than a core issue with the series, but I'd be happy to get more thoughts
on it.
This looks great, and I am looking forward to seeing it merged ! :)
Thanks again for carrying this change through.
Kind regards,
Ada
^ permalink raw reply
* Re: [PATCH 6/7] ARM: dts: rockchip: Add RV1126 I2C5
From: Andrew Lunn @ 2026-06-24 15:42 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-6-5aef608a3f64@gmail.com>
On Wed, Jun 24, 2026 at 04:44:43PM +0800, Yanan He wrote:
> The controller is present in the SoC and can be used by boards for
> external peripherals, such as an RTC on the Alientek DLRV1126 carrier
> board.
This has nothing to do with networking, so please post it separately.
What i would actually like to see is the patch adding networking
nodes, because my guess is, you have the RGMII delays wrong.
Andrew
^ permalink raw reply
* Re: [PATCH 4/7] net: stmmac: dwmac-rk: Enable refout clock for RGMII
From: Andrew Lunn @ 2026-06-24 15:39 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-4-5aef608a3f64@gmail.com>
On Wed, Jun 24, 2026 at 04:44:41PM +0800, Yanan He wrote:
> Some Rockchip GMAC integrations use clk_mac_refout as an external PHY
> reference clock even when the MAC is configured for RGMII.
>
> RV1126 boards can route CLK_GMAC_ETHERNET_OUT to the external PHY as a
> 25 MHz reference clock. If the driver does not acquire and enable this
> clock in RGMII mode, the common clock framework may disable it as unused
> and the PHY can lose its reference clock.
>
> Enable the refout clock handling for RGMII in addition to RMII.
>
> Signed-off-by: Yanan He <grumpycat921013@gmail.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> index 8d7042e68926..f6fdc0c5b475 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -1112,7 +1112,8 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
> bsp_priv->clk_enabled = false;
>
> bsp_priv->num_clks = ARRAY_SIZE(rk_clocks);
> - if (phy_iface == PHY_INTERFACE_MODE_RMII)
> + if (phy_iface == PHY_INTERFACE_MODE_RMII ||
> + phy_iface == PHY_INTERFACE_MODE_RGMII)
Apart from Heiko commenting that this patch is completely wrong, there
are 4 RGMII modes, not one. You should of used
phy_interface_mode_is_rgmii().
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 06/37] drm/display: bridge-connector: use a drm_bridge_connector internally, not a drm_connector
From: Luca Ceresoli @ 2026-06-24 15:39 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260624-chicken-of-infinite-enthusiasm-8b0e3f@houat>
On Wed Jun 24, 2026 at 1:47 PM CEST, Maxime Ripard wrote:
> On Fri, Jun 12, 2026 at 02:57:39PM +0200, Luca Ceresoli wrote:
>> On Mon Jun 8, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
>> > On Tue, May 19, 2026 at 12:37:23PM +0200, Luca Ceresoli wrote:
>> >> Currently drm_bridge_connector_init() always returns the added connector or
>> >> errors out. When adding bridge hotplug the bridge-connector can be
>> >> successfully initialized without creating a connector, which can be added
>> >> later when the pipeline will be complete.
>> >>
>> >> For this the internal function drm_bridge_connector_add_connector() must be
>> >> able to return a valid drm_bridge_connector even without any drm_connector.
>> >>
>> >> In preparation to support bridge hotplug, change its return value to be the
>> >> same drm_bridge_connector pointer it gets as input, or a PTR_ERR.
>> >>
>> >> No functional changes, just changing an internal API.
>> >>
>> >> Note the return value could now become an int (0 or negative error) because
>> >> returning the same value received as input does not carry any added
>> >> value. However this would be change a lot of lines, so leave such change as
>> >> a future cleanup.
>> >
>> > You just created that function and changed "a lot of lines" already, so
>> > I'm not sure that argument holds.
>>
>> Do you refer to the previous patch?
>>
>> My comment is more about the following patches. It means I separated
>> changes moving code to a subfunction from changes to the the return value
>> in separate patches, so that each patch is trivial to review for
>> correctness.
>>
>> Makes sense?
>
> What confused me is that I took it as "I'm not going to do that work
> (yet?)". If you do it later on, I'd drop the "future cleanup" part, or
> rephrase it.
Ah, I see the issue. I really meant "this change [returning int] is done in
a following commit".
I guess I'll just drop the whole paragraph.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v15 11/11] arm64: Inline el0_svc_common()
From: Ada Couprie Diaz @ 2026-06-24 15:36 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-12-ruanjinjie@huawei.com>
On 11/05/2026 10:21, Jinjie Ruan wrote:
> After converting arm64 to Generic Entry framework, the compiler no longer
> inlines el0_svc_common() into its caller do_el0_svc(). This introduces
> a small but measurable overhead in the critical system call path.
>
> Manually forcing el0_svc_common() to be inlined restores the
> performance. Benchmarking with perf bench syscall basic on a
> Kunpeng 920 platform (based on v6.19-rc1) shows a ~1% performance
> uplift.
>
> Inlining this function reduces function prologue/epilogue overhead
> and allows for better compiler optimization in the hot system call
> dispatch path.
>
> | Metric | W/O this patch | With this patch | Change |
> | ---------- | -------------- | --------------- | --------- |
> | Total time | 2.195 [sec] | 2.171 [sec] | ↓1.1% |
> | usecs/op | 0.219575 | 0.217192 | ↓1.1% |
> | ops/sec | 4,554,260 | 4,604,225 | ↑1.1% |
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v2] arm64: mm: Defer read-only remap of data/bss linear alias
From: Will Deacon @ 2026-06-24 15:35 UTC (permalink / raw)
To: linux-arm-kernel, Ard Biesheuvel
Cc: catalin.marinas, kernel-team, Will Deacon, linux-kernel,
Kevin Brodsky, Ard Biesheuvel, Fuad Tabba
In-Reply-To: <20260623202817.2225495-2-ardb+git@google.com>
On Tue, 23 Jun 2026 22:28:18 +0200, Ard Biesheuvel wrote:
> Since commit
>
> f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only in the linear map")
>
> the linear alias of the .data and .bss regions is remapped read-only
> early during the boot. (Note that a subsequent patch to unmap this
> region entirely was reverted just before the v7.2 merge window, and will
> be brought back in an improved form for the v7.3 cycle)
>
> [...]
Applied to arm64 (for-next/core), thanks!
[1/1] arm64: mm: Defer read-only remap of data/bss linear alias
https://git.kernel.org/arm64/c/36fa5ffa6034
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH 15/37] drm/display: bridge-connector: allocate the connector dynamically
From: Luca Ceresoli @ 2026-06-24 15:34 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260624-judicious-enigmatic-hippo-b13ffe@houat>
Hi Maxime,
thanks for the feedback.
On Wed Jun 24, 2026 at 1:48 PM CEST, Maxime Ripard wrote:
> On Fri, Jun 12, 2026 at 02:44:43PM +0200, Luca Ceresoli wrote:
>> On Mon Jun 8, 2026 at 1:46 PM CEST, Maxime Ripard wrote:
>> > On Tue, May 19, 2026 at 12:37:32PM +0200, Luca Ceresoli wrote:
>> >> Currently the drm_bridge_connector has an embedded drm_connector, so their
>> >> allocation lifetimes are tied to each other. This is insufficient to
>> >> support DRM bridge hotplugging, which requires the connector to be added
>> >> and removed dynamically at runtime multiple times based on hotplug/unplug
>> >> events while the drm_bridge_connector is persistent.
>> >>
>> >> Moreover the drm_connector is exposed to user space and thus an ongoing
>> >> operation (e.g. an ioctl) might last for an arbitrarily long time even
>> >> after the hardware gets removed. This means a new connector might have to
>> >> be added when the previous one is still referenced by user space.
>> >>
>> >> In preparation to handle hotplug, allocate the drm-connector dynamically,
>> >> to allow:
>> >>
>> >> * creating and destroying a connector multiple times during a single
>> >> drm_bridge_connector lifetime
>> >> * creating a new connector even though the previous one is still in use
>> >> and thus still refcounted and not yet freed
>> >>
>> >> This commit does not introduce the actions in the two bullets (it will
>> >> happen in a later commit), it only moves to dynamic APIs for connector
>> >> allocation and init.
>> >>
>> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> >
>> > I think this patch should be split in half, with the switch to using
>> > destroy first, and then the actual move to the dynamically allocated
>> > connector API.
>>
>> Is it doable? drm_connector_dynamic_init() mandates a .destroy callback,
>> drm_connector_init() forbids it.
>
> drmm_connector_init forbids it. drm_connector_init mandates it.
Something bogus in my reply, sorry. :)
So you mean splitting in:
* first patch: move from drmm_connector[_hdmi]_init() to
drm_connector[_hdmi]_init() and add a .destroy
* second patch: move from drm_connector[_hdmi]_init() to
drm_connector[_hdmi]_dynamic_init() +
drm_connector_dynamic_register/unregister()
?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v1] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Mark Brown @ 2026-06-24 12:01 UTC (permalink / raw)
To: Nicolas Frattaroli, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Uwe Kleine-König (The Capable Hub)
Cc: Heiko Stuebner, linux-rockchip, linux-sound, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624083708.254517-2-u.kleine-koenig@baylibre.com>
On Wed, 24 Jun 2026 10:37:07 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
https://git.kernel.org/broonie/sound/c/83d53eca7e55
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v15 10/11] arm64: entry: Convert to generic entry
From: Ada Couprie Diaz @ 2026-06-24 15:32 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-11-ruanjinjie@huawei.com>
On 11/05/2026 10:21, Jinjie Ruan wrote:
> Implement the generic entry framework for arm64 to handle system call
> entry and exit. This follows the migration of x86, RISC-V, and LoongArch,
> consolidating architecture-specific syscall tracing and auditing into
> the common kernel entry infrastructure.
If I understand correctly, as Syscall User Dispatch is gated being
`CONFIG_GENERIC_ENTRY` only and handled via ptrace, this patch
effectively enables Syscall User Dispatch for arm64.
I think it would be great to mention it here explicitly !
>
> [Background]
> Arm64 has already adopted generic IRQ entry. Completing the conversion
> to the generic syscall entry framework reduces architectural divergence,
> simplifies maintenance, and allows arm64 to automatically benefit from
> improvements in the common entry code.
>
> [Changes]
>
> 1. Kconfig and Infrastructure:
> - Select GENERIC_ENTRY and remove GENERIC_IRQ_ENTRY (now implied).
>
> - Migrate struct thread_info to use the syscall_work field instead
> of TIF flags for syscall-related tasks.
>
> 2. Thread Info and Flags:
> - Remove definitions for TIF_SYSCALL_TRACE, TIF_SYSCALL_AUDIT,
> TIF_SYSCALL_TRACEPOINT, TIF_SECCOMP, and TIF_SYSCALL_EMU.
>
> - Replace _TIF_SYSCALL_WORK and _TIF_SYSCALL_EXIT_WORK with the
> generic SYSCALL_WORK bitmask.
>
> - Map single-step state to SYSCALL_EXIT_TRAP in debug-monitors.c.
>
> 3. Architecture-Specific Hooks (asm/entry-common.h):
> - Implement arch_ptrace_report_syscall_entry() and _exit() by
> porting the existing arm64 logic to the generic interface.
>
> - Add arch_syscall_is_vdso_sigreturn() to asm/syscall.h to
> support Syscall User Dispatch (SUD).
Related to the above : I feel this is missing an important information.
Given that SUD is only controlled by `CONFIG_GENERIC_ENTRY`,
converting to generic entry _requires_ supporting SUD, so we do it here.
I think this would be important to mention, as I otherwise felt like this
change did not belong in this patch.
General question that follows : does it make sense to require an arch
to support Syscall User Dispatch to be able to convert to generic entry ?
(I assume not really, given that only `arch_syscall_is_vdso_sigreturn()` is
required on the arch side, but I am curious)
>
> 4. Cleanup and Refactoring:
> - Remove redundant arm64-specific syscall tracing functions from
> ptrace.c, including syscall_trace_enter(), syscall_exit_work(),
> and related audit/step helpers.
>
> - Update el0_svc_common() in syscall.c to use the generic
> syscall_work checks and entry/exit call sites.
>
> [Why this matters]
> - Unified Interface: Aligns arm64 with the modern kernel entry standard.
>
> - Improved Maintainability: Bug fixes in kernel/entry/common.c now
> apply to arm64 automatically.
>
> - Feature Readiness: Simplifies the implementation of future
> cross-architecture syscall features.
>
> [Compatibility]
> This conversion maintains full ABI compatibility with existing
> userspace. The ptrace register-saving behavior, seccomp filtering, and
> syscall tracing semantics remain identical to the previous implementation.
I agree, would it make sense to mention that there is no change related
to RSEQ as arm64 does not have `HAVE_GENERIC_TIF_BITS` ? As that is
part of generic entry, but is indeed a no-op for us.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Suggested-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> [...]
> diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
> index 29307642f4c9..e67643a70405 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -385,11 +385,18 @@ void user_enable_single_step(struct task_struct *task)
>
> if (!test_and_set_ti_thread_flag(ti, TIF_SINGLESTEP))
> set_regs_spsr_ss(task_pt_regs(task));
> +
> + /*
> + * Ensure that a trap is triggered once stepping out of a system
> + * call prior to executing any user instruction.
> + */
I was a bit confused by the comment in isolation at first : we already
have a signal that we are stepping and would need a trap, `TIF_SINGLESTEP`.
Would it make sense to mention here that this is for/handled by the generic
entry code ?
Something along the lines of "[...], as the generic entry code does not
check for `TIF_SINGLESTEP`.", or "Ensure that the generic entry code
triggers a trap [...]", if you think its useful ?
> + set_task_syscall_work(task, SYSCALL_EXIT_TRAP);
> }
> NOKPROBE_SYMBOL(user_enable_single_step);
>
> void user_disable_single_step(struct task_struct *task)
> {
> clear_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
> + clear_task_syscall_work(task, SYSCALL_EXIT_TRAP);
> }
> NOKPROBE_SYMBOL(user_disable_single_step);
Apart from my minor nitpicks :
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Thanks,
Ada
^ permalink raw reply
* Re: [PATCH] mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout
From: Vladimir Zapolskiy @ 2026-06-24 15:29 UTC (permalink / raw)
To: Pengpeng Hou, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Piotr Wojtaszczyk
Cc: linux-mtd, linux-arm-kernel, linux-kernel
In-Reply-To: <20260624144127.69075-1-pengpeng@iscas.ac.cn>
On 6/24/26 17:41, Pengpeng Hou wrote:
> lpc32xx_xmit_dma() waits for the DMA completion callback but ignores
> wait_for_completion_timeout(). A timed out DMA transfer is therefore
> unmapped and reported as successful to the NAND read/write path.
>
> Return -ETIMEDOUT when the completion wait expires. Terminate the DMA
> channel before unmapping the scatterlist so the timed out transfer cannot
> continue to access the buffer after the error is returned.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/mtd/nand/raw/lpc32xx_slc.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/lpc32xx_slc.c b/drivers/mtd/nand/raw/lpc32xx_slc.c
> index 3ca30e7dc..10c808020 100644
> --- a/drivers/mtd/nand/raw/lpc32xx_slc.c
> +++ b/drivers/mtd/nand/raw/lpc32xx_slc.c
> @@ -430,6 +430,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
> struct dma_async_tx_descriptor *desc;
> int flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
> int res;
> + unsigned long time_left;
>
> host->dma_slave_config.direction = dir;
> host->dma_slave_config.src_addr = dma;
> @@ -467,12 +468,19 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
> dmaengine_submit(desc);
> dma_async_issue_pending(host->dma_chan);
>
> - wait_for_completion_timeout(&host->comp, msecs_to_jiffies(1000));
> + time_left = wait_for_completion_timeout(&host->comp,
> + msecs_to_jiffies(1000));
> + if (!time_left) {
> + dmaengine_terminate_sync(host->dma_chan);
> + res = -ETIMEDOUT;
> + } else {
> + res = 0;
> + }
>
> dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
> DMA_BIDIRECTIONAL);
>
> - return 0;
> + return res;
> out1:
> dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
> DMA_BIDIRECTIONAL);
Thank you for the change.
Reviewed-by: Vladimir Zapolskiy <vz@kernel.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 19/37] drm/bridge: samsung-dsim: move drm_bridge_add() call to probe
From: Maxime Ripard @ 2026-06-24 15:28 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJ63DNXUOW46.1DI6982PGPFRR@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 4791 bytes --]
On Thu, Jun 11, 2026 at 10:54:14AM +0200, Luca Ceresoli wrote:
> On Mon Jun 8, 2026 at 1:58 PM CEST, Maxime Ripard wrote:
> > On Tue, May 19, 2026 at 12:37:36PM +0200, Luca Ceresoli wrote:
> >> This bridge driver calls drm_bridge_add() in the DSI host .attach callback
> >> instead of in the probe function.
> >>
> >> This works for current use cases but is problematic for supporting hotplug
> >> of DRM bridges. The problematic case is when this DSI host is always
> >> present while its DSI device is hot-pluggable. In such case with the
> >> current code the DRM card will not be populated until after the DSI device
> >> attaches to the host, which could happen a very long time after booting, or
> >> even not happen at all.
> >>
> >> The reason is that the previous pipeline component (the encoder in this
> >> case) when probing cannot find the samsung-dsim bridge. What happens is:
> >>
> >> [1 and 2 can happen in any order, same result]
> >> 1) samsung-dsim probes (does not drm_bridge_add() itself)
> >> 2) The lcdif starts probing multiple times, but
> >> lcdif_probe
> >> -> lcdif_load
> >> -> lcdif_attach_bridge
> >> -> devm_drm_of_get_bridge() returns -EPROBE_DEFER because
> >> the samsung-dsim is not in the global bridge_list
> >> (deferred probe pending: imx-lcdif: Cannot connect bridge)
> >>
> >> The samsung-dsim will not drm_bridge_add() itself until a DSI device will
> >> try to mipi_dsi_attach() to the DSI Host, which can happen arbitratily late
> >> on hot-pluggable hardware.
> >>
> >> As a preliminary step to supporting hotplug move drm_bridge_add() at probe
> >> time, so that the samsung-dsim DSI host bridge is available during boot,
> >> even without a connected DSI device. This results in:
> >>
> >> 1) samsung-dsim probes (and adds to drm_bridge_add() itself)
> >> 2) The lcdif starts probing multiple times, but
> >> lcdif_probe
> >> -> lcdif_load
> >> -> lcdif_attach_bridge
> >> -> devm_drm_of_get_bridge() --> OK, returns samsung-dsim ptr
> >>
> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> >
> > We should probably amend
> > https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
> >
> > To mention this use case here
>
> Right. I haven't updated the docs for this v1 because I was not sure the
> overall approach would be acked. Now Dmitry acked it overall, and I kind of
> infer you are not against, so I'll look into updating the docs in v2.
>
> However I find that section of the docs a bit hard to read especially from
> a newcomer perspective.
It's a complex problem, so I don't think we should expect the target
audience to be newcomers. But maybe we can indeed improve it.
> A better understanding on my side would help in doing the right change as
> far as this patch is concerned, and as a bonus in improving the section
> overall (that would probably be a separate series).
>
> So I have a couple questions to start from:
>
> * Do I understand correctly that using the component framework is legacy,
> not recommended for new DRM development, and that converting existing
> code to stop using it is welcome?
No. It's not legacy or deprecated. And about the conversion, I guess
it's on a case-by-case basis? It's not encouraged or discouraged anyway.
> * The first bullet quotes "The upstream driver [...] isn’t a MIPI-DSI
> host". If the upstream driver of a MIPI DSI link isn't a MIPI DSI host,
> what else could it be? What are the use cases here?
Nowhere is it said that we're considering a MIPI-DSI link here, so the
use case is any bridge that isn't using MIPI-DSI at all.
> * If read literally, none of the 4 bullets after "Indeed, there’s multiple
> cases that needs to be considered" covers this driver (it does not use
> the component framework, it does not use DCS, and the upstream device is
> a DSI host). However the 3 bullets after "The ideal pattern to cover the
> last item" appear to cover what this driver does. Do we need a fifth
> bullet for drivers like this one? Or...?
You tell me :)
How does hotplugging, say, a MIPI-DSI device bridge controlled over I2C,
or a MIPI-DSI host bridge, affect the probing sequence, and can we end
up in endless probe deferrals?
> * To me it looks like the "bridge" word in this section is always used to
> refer to the DSI device. Would it make sense to replace "bridge" ->
> "[DSI ]device" in this section?
Not necessarily, and from a KMS point of view, MIPI-DSI doesn't exist,
only bridge do.
> (especially as the DSI host is also a DRM bridge)
It doesn't have to be.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* RE: [PATCH v2] spi: imx: reconfigure for PIO when DMA cannot be started
From: Carlos Song @ 2026-06-24 15:27 UTC (permalink / raw)
To: Javier Fernandez Pastrana, Mark Brown, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-spi@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
In-Reply-To: <20260624151958.18626-1-javier.pastrana@linutronix.de>
> -----Original Message-----
> From: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
> Sent: Wednesday, June 24, 2026 11:20 PM
> To: Mark Brown <broonie@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha
> Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Carlos Song
> <carlos.song@nxp.com>; linux-spi@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: javier.pastrana@linutronix.de; stable@vger.kernel.org
> Subject: [EXT] [PATCH v2] spi: imx: reconfigure for PIO when DMA cannot be
> started
>
> [Some people who received this message don't often get email from
> javier.pastrana@linutronix.de. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Caution: This is an external email. Please take care when clicking links or opening
> attachments. When in doubt, report the message using the 'Report this email'
> button
>
>
> When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA:
> spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and
> spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the
> SDMA watermarks.
>
> If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single()
> returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START and falls
> back to PIO. The dynamic-burst DMA path uses its own bounce buffers instead of
> the SPI core's mapping, so xfer->{tx,rx}_sg_mapped are not set and the core's
> DMA->PIO retry is skipped; the driver falls back to PIO internally. But none of the
> DMA-mode configuration is undone, so the PIO transfer runs with CTRL.SMC set,
> the wrong burst length and dynamic_burst cleared, and the transferred data is
> corrupted.
>
> This is easily hit on i.MX8MP boards that describe ECSPI DMA in the device tree
> but run SDMA on ROM firmware (no external sdma-imx7d.bin):
> every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then returns
> shifted TPM2_GetCapability data, is flagged "field failure mode", /dev/tpmrm0 is
> never created.
>
> Set controller->fallback before re-running spi_imx_setupxfer() so the ECSPI is
> reconfigured exactly like a normal PIO transfer. With
> controller->fallback set, spi_imx_setupxfer() sees spi_imx_can_dma()
> return false, so it clears spi_imx->usedma and reprograms the controller (clears
> CTRL.SMC, restores dynamic_burst and the PIO burst length). No explicit
> spi_imx->usedma = false is needed: setupxfer() already updates it from the
> can_dma() result.
>
> Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA
> mode")
> Cc: stable@vger.kernel.org
> Signed-off-by: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
Hi,
LGTM. Thank you!
Acked-by: Carlos Song <carlos.song@nxp.com>
> ---
> v2: drop redundant spi_imx->usedma = false; spi_imx_setupxfer() already
> clears it via spi_imx_can_dma() (Carlos Song)
>
> drivers/spi/spi-imx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index
> 480d1e8b281f..1837cc7b0b96 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -2152,7 +2152,8 @@ static int spi_imx_transfer_one(struct spi_controller
> *controller,
> if (spi_imx->usedma) {
> ret = spi_imx_dma_transfer(spi_imx, transfer);
> if (transfer->error & SPI_TRANS_FAIL_NO_START) {
> - spi_imx->usedma = false;
> + controller->fallback = true;
> + spi_imx_setupxfer(spi, transfer);
> if (spi_imx->target_mode)
> return spi_imx_pio_transfer_target(spi,
> transfer);
> else
> --
> 2.47.3
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Xueyuan Chen @ 2026-06-24 14:49 UTC (permalink / raw)
To: david
Cc: xueyuan.chen21, dave.hansen, akpm, linux-mm, linux-kernel,
linux-arm-kernel, x86, catalin.marinas, will, tglx, mingo, bp,
dave.hansen, luto, peterz, hpa, ljs, liam, vbabka, rppt, surenb,
mhocko, ziy, baolin.wang, npache, ryan.roberts, dev.jain, baohua,
lance.yang, yang, jannh
In-Reply-To: <f679fc68-5ff6-4715-9a07-9eb3074b2d1e@kernel.org>
On Fri, Jun 19, 2026 at 01:09:09PM +0200, David Hildenbrand (Arm) wrote:
Hi, David
[...]
>Having a new direct-map specific function with clear semantics might indeed
>avoid even messing with that.
>
>So, yeah, given that we have
>
> set_direct_map_invalid_noflush
> set_direct_map_default_noflush
> set_direct_map_valid_noflush
>
>Let's add a
>
> set_direct_map_ro()
>
>Or (my preference)
>
> change_direct_map_ro()
>
>But given the existing naming scheme ... maybe just set_direct_map_ro() and
>we'll clean this up another day.
>
>
>Now, should there also be a "_noflush" in there, or who is supposed to flush the
>TLB (or don't we flush at all, because it's used early during boot so far)?
>
>In any case, for this function we should add excessive documentation and define
>clear semantics.
>
After talking with Lance, we're leaning toward a direct-map helper:
set_direct_map_ro_noflush(const void *addr, unsigned long nr_pages)
Contract should be pretty explicit: direct/linear map only, no alias
handling, no TLB flush. If a caller needs stale entries gone, it has
to flush itself.
Huge zero folio only uses this early during boot so far, so noflush
should be OK. Will document that.
Thanks,
Xueyuan
^ permalink raw reply
* [PATCH v2] spi: imx: reconfigure for PIO when DMA cannot be started
From: Javier Fernandez Pastrana @ 2026-06-24 15:19 UTC (permalink / raw)
To: Mark Brown, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Carlos Song, linux-spi, imx, linux-arm-kernel,
linux-kernel
Cc: javier.pastrana, stable
When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA:
spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and
spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the
SDMA watermarks.
If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single()
returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START and
falls back to PIO. The dynamic-burst DMA path uses its own bounce
buffers instead of the SPI core's mapping, so xfer->{tx,rx}_sg_mapped
are not set and the core's DMA->PIO retry is skipped; the driver falls
back to PIO internally. But none of the DMA-mode configuration is
undone, so the PIO transfer runs with CTRL.SMC set, the wrong burst
length and dynamic_burst cleared, and the transferred data is corrupted.
This is easily hit on i.MX8MP boards that describe ECSPI DMA in the
device tree but run SDMA on ROM firmware (no external sdma-imx7d.bin):
every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then
returns shifted TPM2_GetCapability data, is flagged "field failure
mode", /dev/tpmrm0 is never created.
Set controller->fallback before re-running spi_imx_setupxfer() so the
ECSPI is reconfigured exactly like a normal PIO transfer. With
controller->fallback set, spi_imx_setupxfer() sees spi_imx_can_dma()
return false, so it clears spi_imx->usedma and reprograms the controller
(clears CTRL.SMC, restores dynamic_burst and the PIO burst length). No
explicit spi_imx->usedma = false is needed: setupxfer() already updates
it from the can_dma() result.
Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode")
Cc: stable@vger.kernel.org
Signed-off-by: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
---
v2: drop redundant spi_imx->usedma = false; spi_imx_setupxfer() already
clears it via spi_imx_can_dma() (Carlos Song)
drivers/spi/spi-imx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 480d1e8b281f..1837cc7b0b96 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -2152,7 +2152,8 @@ static int spi_imx_transfer_one(struct spi_controller *controller,
if (spi_imx->usedma) {
ret = spi_imx_dma_transfer(spi_imx, transfer);
if (transfer->error & SPI_TRANS_FAIL_NO_START) {
- spi_imx->usedma = false;
+ controller->fallback = true;
+ spi_imx_setupxfer(spi, transfer);
if (spi_imx->target_mode)
return spi_imx_pio_transfer_target(spi, transfer);
else
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-24 15:16 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <25d7d3a1-58e0-4f25-a73a-59a978130c47@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 11:08:32PM +0800, Jie Gan wrote:
[...]
> > Why does it fail ? power management ? hw broken ? Is it really AMBA or
> > do you pretend that to be an AMBA device by faking the CID/PID?
>
> The CID reads as 0 from the register, which I suspect is a hardware design
> issue. I have not yet confirmed this with the hardware team. As a
> workaround, I provided a fake periphid via a DT property to bypass
> amba_read_periphid.
>
>
> Leo commented in other thread:
> >>tnoc.c registers both an AMBA driver and a platform driver. Shouldn't >>it
> >>be registered as a platform device instead?
>
> The platform driver is intended for the interconnect TraceNoC device and is
> not designed to allocate an ATID. The issue is that the TPDM device borrows
> the ATID from the TraceNoC device, resulting in the ATID always being 0 when
> associated with an interconnect NoC device.
>
> However, I believe it is acceptable to allocate an ATID for the itNoC device
> and the issue can be fixed with this way.
I think so.
^ permalink raw reply
* Re: [PATCH 26/37] drm: event-notifier: add mechanism to notify about hotplug events
From: Maxime Ripard @ 2026-06-24 15:09 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJ4EWMIX84PN.3VTENLJT2FWDH@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
On Tue, Jun 09, 2026 at 11:30:52AM +0200, Luca Ceresoli wrote:
> On Mon Jun 8, 2026 at 2:13 PM CEST, Maxime Ripard wrote:
> > On Tue, May 19, 2026 at 12:37:43PM +0200, Luca Ceresoli wrote:
> >> In preparation for supporting DRM bridge hotplug, add an event notifier to
> >> allow interested parties to be notified about events they need to react to.
> >>
> >> For the initial implementation of bridge hotplug, two events are needed:
> >> bridge detach (happening in drm_bridge.c) and MIPI device attach to MIPI
> >> host (happening in drm_mipi_dsi.c).
> >>
> >> For this reason implement the event notifier in a new common file that
> >> event producers can easily use to send events.
> >>
> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> >
> > So, you claim in the commit message that it's about a hotplug event, but
> > the only events are the bridge being attached and detached, so not a
> > hotplug event?
> >
> > And why a bridge would want to be notified that itself (or another?)
> > bridge is being attached or detached?
> >
> > You need documentation, and a more descriptive commit message.
>
> Yes.
>
> But before that I need a decision about the scope we want to give to this
> notifier. It is a very generic module, with basically no dependencies, so
> people will try to add more unrelated events and we'd need to set a
> boundary.
>
> Options:
>
> * Should it be for hotplug-related events only?
> * Should it be for any DRM event that needs notifications?
> * Something else?
>
> I'm happy to write that in the docs and commit message once it's agreed, so
> any comments would be welcome right now.
At the end of the day, you'd be the first user of it, so you get to make
the rules, but they should be written down :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 15:08 UTC (permalink / raw)
To: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <471d7a92-3629-4274-a303-8906d3626037@arm.com>
On 6/24/2026 9:51 PM, Suzuki K Poulose wrote:
> On 24/06/2026 14:48, Jie Gan wrote:
>>
>>
>> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>>> its probe function if the arm,primecell-periphid property is absent.
>>>> This causes a deferred probe issue for the TraceNoC device, as the
>>>> CID/PID cannot be read from the periphid register.
>>>
>>> Why does it probe defer?
>>>
>>
>> For an AMBA device, the periphid is mandatory for probing. In the
>> amba_match function, AMBA attempts to read the periphid from the CID/
>> PID registers if the arm,primecell-periphid property is absent in the
>> device tree. If this read fails, it returns -EPROBE_DEFER, and the
>> probe ultimately fails.
>
> Why does it fail ? power management ? hw broken ? Is it really AMBA or
> do you pretend that to be an AMBA device by faking the CID/PID?
The CID reads as 0 from the register, which I suspect is a hardware
design issue. I have not yet confirmed this with the hardware team. As a
workaround, I provided a fake periphid via a DT property to bypass
amba_read_periphid.
Leo commented in other thread:
>>tnoc.c registers both an AMBA driver and a platform driver. Shouldn't
>>it
>>be registered as a platform device instead?
The platform driver is intended for the interconnect TraceNoC device and
is not designed to allocate an ATID. The issue is that the TPDM device
borrows the ATID from the TraceNoC device, resulting in the ATID always
being 0 when associated with an interconnect NoC device.
However, I believe it is acceptable to allocate an ATID for the itNoC
device and the issue can be fixed with this way.
Thanks,
Jie
>
> Suzuki
>
>
>> Most AMBA devices expose valid CID/PID registers, so specifying
>> arm,primecell-periphid in the device tree is usually unnecessary.
>> However, for the TraceNoC device in this case, AMBA cannot reliably
>> read the periphid from the corresponding registers.
>>
>>> And is this required for all TNOC devices?
>>
>> So far, the TNOC device has been added to sm8750, Glymur, and
>> Kaanapali platforms, and all exhibit probe failures due to the same
>> root cause.
>>
>> I prefer to fix it on Kaanapali first.
>>
>> Thanks,
>> Jie
>>
>>>
>>> Konrad
>>
>
^ permalink raw reply
* Re: [PATCH 6.1 337/522] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
From: Ryan Roberts @ 2026-06-24 15:05 UTC (permalink / raw)
To: Will Deacon, Ben Hutchings
Cc: Anshuman Khandual, Catalin Marinas, David Hildenbrand (Arm),
patches, linux-arm-kernel, linux-kernel, Sasha Levin,
Greg Kroah-Hartman, stable, mark.rutland
In-Reply-To: <ajqXWqiAol6Shdd6@willie-the-truck>
On 23/06/2026 15:25, Will Deacon wrote:
> On Sun, Jun 21, 2026 at 05:02:27PM +0200, Ben Hutchings wrote:
>> On Tue, 2026-06-16 at 20:28 +0530, Greg Kroah-Hartman wrote:
>>> 6.1-stable review patch. If anyone has any objections, please let me know.
>>>
>>> ------------------
>>>
>>> From: Anshuman Khandual <anshuman.khandual@arm.com>
>>>
>>> [ Upstream commit 48478b9f791376b4b89018d7afdfd06865498f65 ]
>> [...]
>>> @@ -949,15 +953,14 @@ static void unmap_hotplug_pmd_range(pud_
>>> WARN_ON(!pmd_present(pmd));
>>> if (pmd_sect(pmd)) {
>>> pmd_clear(pmdp);
>>> -
>>> - /*
>>> - * One TLBI should be sufficient here as the PMD_SIZE
>>> - * range is mapped with a single block entry.
>>> - */
>>> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>>> - if (free_mapped)
>>> + if (free_mapped) {
>>> + /* CONT blocks are not supported in the vmemmap */
>>> + WARN_ON(pmd_cont(pmd));
>>> + flush_tlb_kernel_range(addr, addr + PMD_SIZE);
>>
>> It wasn't clear to me from the commit message why this now adds PMD_SIZE
>> rather than PAGE_SIZE. It seems like this change is fine for Linux
>> 6.13+ with a CPU that supports TLB range flushing, but otherwise results
>> in unnecessarily executing multiple TLB invalidations at intervals of
>> the base page size.
>
> Hmm, the commit message also makes very little sense to me and so I don't
> understand why this patch has us doing multiple TLB invalidations when
> we run into a !cont, block mapping at the PMD level. The old comment
> (which this patch removes) should still apply afaict.
>
> Anshuman, Ryan, any ideas what's going on here?
I think this change was probably my fault; Given the API is called
flush_tlb_kernel_range() it seemed like an abuse/hack to pretend we are only
flushing the first PAGE_SIZE of the range. But as I understand it, even if the
HW shatters a block mapping into multiple TLB entries, all of the entries
relating to the block mapping will be invalidated if just one of them intersects
the TLBI range/address. So it should be safe to reapply this hack.
Although ideally I think it would be better if this API took a stride argument;
then intent is clear.
What's the best way to handle this? Submit a patch for mainline that reverts
this part, then get it backported to stable (implying this current patch will
have been applied to stable)?
Thanks,
Ryan
>
> Will
^ permalink raw reply
* Re: [PATCH v3 00/12] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Borislav Petkov @ 2026-06-24 14:59 UTC (permalink / raw)
To: Will Deacon
Cc: Jinjie Ruan, catalin.marinas, tsbogend, tglx, mingo, dave.hansen,
hpa, peterz, kees, nathan, linusw, ojeda, david.kaplan,
lukas.bulwahn, ryan.roberts, maz, timothy.hayes, lpieralisi,
thuth, menglong8.dong, oupton, yeoreum.yun, miko.lenczewski,
broonie, kevin.brodsky, james.clark, yangyicong, tabba, osandov,
arnd, anshuman.khandual, david, akpm, ljs, dev.jain, yang,
chaitanyas.prakash, kprateek.nayak, chenl311, sshegde,
thorsten.blum, chang.seok.bae, tim.c.chen, x86, linux-kernel,
linux-arm-kernel, linux-mips
In-Reply-To: <ajvKkLw5bL-FT5JC@willie-the-truck>
On Wed, Jun 24, 2026 at 01:16:16PM +0100, Will Deacon wrote:
> If you want to help out in the meantime, there are plenty of patches that
> need reviewing...
I would loooove it if git send-email speed and rate of sending mail is
proportional to how many other patches the sender has really reviewed...
:-P :-P :-P
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v15 09/11] arm64/ptrace: Skip syscall exit reporting for PTRACE_SYSEMU_SINGLESTEP
From: Ada Couprie Diaz @ 2026-06-24 14:55 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-10-ruanjinjie@huawei.com>
On 11/05/2026 10:21, Jinjie Ruan wrote:
> Align the syscall exit reporting logic with the generic entry
> framework by skipping the exit stop when PTRACE_SYSEMU_SINGLESTEP is
> in effect.
>
> [Rationale]
> When a tracer uses PTRACE_SYSEMU_SINGLESTEP, both _TIF_SYSCALL_EMU
> and _TIF_SINGLESTEP flags are set. Currently, arm64 reports a syscall
> exit stop whenever _TIF_SINGLESTEP is set, regardless of the
> emulation state.
>
> However, as per the generic entry implementation (see
> include/linux/entry-common.h):
> "If SYSCALL_EMU is set, then the only reason to report is when SINGLESTEP
> is set (i.e. PTRACE_SYSEMU_SINGLESTEP). This syscall instruction has been
> already reported in syscall_trace_enter()."
>
> Since PTRACE_SYSEMU intercepts and skips the actual syscall
> execution, reporting a subsequent exit stop is redundant and
> inconsistent with the expected behavior of emulated system calls.
>
> [Changes]
> - Introduce report_single_step(): Add a helper to encapsulate the
> logic for deciding whether to report a single-step stop at syscall
> exit. It returns false if _TIF_SYSCALL_EMU is set, ensuring the
> emulated syscall does not trigger a duplicate report.
>
> - Update syscall_exit_work(): Use the new helper to determine
> the stepping state instead of directly checking _TIF_SINGLESTEP.
>
> [Impact]
> - PTRACE_SINGLESTEP: Continues to report exit stops for actual
> instructions.
>
> - PTRACE_SYSEMU: Continues to skip exit stops.
>
> - PTRACE_SYSEMU_SINGLESTEP: Now correctly skips the redundant exit
> stop, aligning arm64 with the generic entry infrastructure.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v15 08/11] arm64/ptrace: Define and use _TIF_SYSCALL_EXIT_WORK
From: Ada Couprie Diaz @ 2026-06-24 14:53 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-9-ruanjinjie@huawei.com>
On 11/05/2026 10:21, Jinjie Ruan wrote:
> Introduce _TIF_SYSCALL_EXIT_WORK to filter out entry-only flags
> during the syscall exit path. This aligns arm64 with the generic
> entry framework's SYSCALL_WORK_EXIT semantics.
>
> [Rationale]
> The current syscall exit path uses _TIF_SYSCALL_WORK to decide whether
> to invoke syscall_exit_work(). However, _TIF_SYSCALL_WORK includes
> flags that are only relevant during syscall entry:
>
> 1. _TIF_SECCOMP: Seccomp filtering (__secure_computing) only runs
> on entry. There is no seccomp callback for syscall exit.
>
> 2. _TIF_SYSCALL_EMU: In PTRACE_SYSEMU mode, the syscall is
> intercepted and skipped on entry. Since the syscall is never
> executed, reporting a syscall exit stop is unnecessary.
>
> [Changes]
> - Define _TIF_SYSCALL_EXIT_WORK: A new mask containing only flags
> requiring exit processing: _TIF_SYSCALL_TRACE, _TIF_SYSCALL_AUDIT,
> and _TIF_SYSCALL_TRACEPOINT.
>
> - Update exit path: Use _TIF_SYSCALL_EXIT_WORK in
> syscall_exit_to_user_mode_work() to avoid redundant calls to
> audit and ptrace reporting when only entry-flags are set.
>
> - Cleanup: Remove the has_syscall_work() helper as it is no longer
> needed. Direct flag comparison is now used to distinguish between
> entry and exit work requirements.
>
> [Impact]
> audit_syscall_exit() and report_syscall_exit() will no longer be
> triggered for seccomp-only or emu-only syscalls. This matches the
> generic entry behavior and improves efficiency by skipping unnecessary
> exit processing.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Definitely not related to this series, but it feels like this brings us
quite close to being able to switch to generic TIF flags as well :
only TIF_FOREIGN_PSTATE and TIF_MTE_ASYNC_FAULT
would need to be moved to the upper 16 bits,
with TIF_RESTORE_SIGMASK and TIF_MEMDIE freeing two slots there.
Not sure how important the bit number changes would be and if any
of the extra generic bits require any arch support (TIF_POLLING_NRFLAG,
TIF_USER_RETURN_NOTIFY, TIF_RSEQ, TIF_HRTIMER_REARM)...
But again, just thinking out loud !
Thanks,
Ada
^ permalink raw reply
* [PATCH] mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout
From: Pengpeng Hou @ 2026-06-24 14:41 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Vladimir Zapolskiy, Piotr Wojtaszczyk
Cc: Pengpeng Hou, linux-mtd, linux-arm-kernel, linux-kernel
lpc32xx_xmit_dma() waits for the DMA completion callback but ignores
wait_for_completion_timeout(). A timed out DMA transfer is therefore
unmapped and reported as successful to the NAND read/write path.
Return -ETIMEDOUT when the completion wait expires. Terminate the DMA
channel before unmapping the scatterlist so the timed out transfer cannot
continue to access the buffer after the error is returned.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mtd/nand/raw/lpc32xx_slc.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/lpc32xx_slc.c b/drivers/mtd/nand/raw/lpc32xx_slc.c
index 3ca30e7dc..10c808020 100644
--- a/drivers/mtd/nand/raw/lpc32xx_slc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_slc.c
@@ -430,6 +430,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
struct dma_async_tx_descriptor *desc;
int flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
int res;
+ unsigned long time_left;
host->dma_slave_config.direction = dir;
host->dma_slave_config.src_addr = dma;
@@ -467,12 +468,19 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
dmaengine_submit(desc);
dma_async_issue_pending(host->dma_chan);
- wait_for_completion_timeout(&host->comp, msecs_to_jiffies(1000));
+ time_left = wait_for_completion_timeout(&host->comp,
+ msecs_to_jiffies(1000));
+ if (!time_left) {
+ dmaengine_terminate_sync(host->dma_chan);
+ res = -ETIMEDOUT;
+ } else {
+ res = 0;
+ }
dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
DMA_BIDIRECTIONAL);
- return 0;
+ return res;
out1:
dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
DMA_BIDIRECTIONAL);
--
2.50.1 (Apple Git-155)
^ 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