* Re: [PATCH v3 11/12] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
From: Krzysztof Kozlowski @ 2026-05-21 10:17 UTC (permalink / raw)
To: Lothar Rubusch, thorsten.blum, herbert, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, tudor.ambarus, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520155703.23018-12-l.rubusch@gmail.com>
On 20/05/2026 17:57, Lothar Rubusch wrote:
> When a non-blocking read operation is requested, the driver dynamically
> allocates memory to track asynchronous transfer status. If the underlying
> I2C transmission fails, atmel_sha204a_rng_done() logs a rate-limited
> warning but incorrectly proceeds to cache the pointer to this uninitialized
> buffer inside the rng->priv data field anyway.
>
> On subsequent execution passes, atmel_sha204a_rng_read_nonblocking()
> detects the stale rng->priv value, skips executing a hardware data read,
> and copies up to 32 bytes of uninitialized kernel heap data from this
> garbage memory pool straight back into the system's hwrng data stream.
>
> Fix this information disclosure vector by immediately releasing the
> allocated asynchronous work data buffer and explicitly clearing the
> tracking pointer context whenever an I2C transaction returns a non-zero
> error status.
>
> Additionally, duplicate the tfm counter decrement within the new error
> path to ensure the reference counter is properly released before executing
> the early return, maintaining the driver's availability for subsequent
> requests.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
This and other fixes should be first in the patchset. Or even separate
patchset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Mukesh Savaliya @ 2026-05-21 10:16 UTC (permalink / raw)
To: Carlos Song (OSS), Mukesh Savaliya, o.rempel@pengutronix.de,
kernel@pengutronix.de, andi.shyti@kernel.org, Frank Li,
s.hauer@pengutronix.de, festevam@gmail.com, Carlos Song,
Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <AM0PR04MB68027798D1B07FD63AEC5F23E80E2@AM0PR04MB6802.eurprd04.prod.outlook.com>
Thanks Carlos !
On 5/21/2026 1:57 PM, Carlos Song (OSS) wrote:
>
>
>> -----Original Message-----
>> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
>> Sent: Thursday, May 21, 2026 3:40 PM
>> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>; o.rempel@pengutronix.de;
>> kernel@pengutronix.de; andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
>> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
>> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
>> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>> stable@vger.kernel.org
>> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered
>> down
>>
>> [You don't often get email from mukesh.savaliya@oss.qualcomm.com. Learn
>> why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Hi Carlos,
>>
>> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
>>> From: Carlos Song <carlos.song@nxp.com>
>>>
>>> Mark the I2C adapter as suspended during system suspend to block
>>> further transfers, and resume it on system resume. This prevents
>>> potential hangs when the hardware is powered down but clients still attempt
>> I2C transfers.
>>>
what was the reason of this hang ? I was thinking you don't have
interrupts working when client requested transfer but adapter was
suspended. Please correct me if wrong.
And it would be good to mention the actual problem and why/how it occurred.
>> Code changes looks fine to me but have comment on commit log.
>>
>> It seems, you are adding support of _noirq() callbacks to allow transfers during
>> suspend/resume noirq phase of PM.
>>
>> Would it make sense if you can write "Replace system PM callbacks with noirq
>> PM callbacks" OR "Allow transfers during _noirq phase of the PM ops" instead of
>> "mark I2C adapter when hardware is powered down" ?
>>
>
> Hi,
>
> Thank you for your comments!
>
> But this patch is added is not for support noirq PM callback or transfer in noirq phase.
>
Okay, may be actual problem description can help me.
> In fact, this fix is to mark the I2C adapter as suspended during system noirq suspend to block further
> transfers, and resume it on system noirq resume. This is to prohibit I2C device calling the I2C controller
> after the system noirq suspend and before noirq resume, because at this time the I2C instance is powered
> off or the clock is disabled ... So I want to keep current commit. How do you think?
completely Makes sense. Please help add how this problem occurred and
why ? So the change/fix will be good to understand against it.
>
> Carlos Song
^ permalink raw reply
* Re: [PATCH v3 02/12] crypto: atmel-ecc - fix use after free situation
From: Krzysztof Kozlowski @ 2026-05-21 10:16 UTC (permalink / raw)
To: Lothar Rubusch, thorsten.blum, herbert, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, tudor.ambarus, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520155703.23018-3-l.rubusch@gmail.com>
On 20/05/2026 17:56, Lothar Rubusch wrote:
> Fixes the very likely race condition, having multiple of such devices
> attached (identified by sashiko feedback).
>
> The Scenario:
> Thread A (Device 1 Probe): Successfully adds i2c_priv to the global
> list (Line 324). The lock is released.
> Thread B (An active crypto request): Concurrently calls
> atmel_ecc_i2c_client_alloc(). It scans the global list, sees
> Device 1, and assigns a crypto job to it.
> Thread A: Moves to line 332. crypto_register_kpp() fails (e.g., out of
> memory or name clash).
> Thread A: Enters the error path. It removes Device 1 from the list and
> frees the i2c_priv memory.
> Thread B: Is still actively trying to talk to the I2C hardware using
> the i2c_priv pointer it grabbed in Step 2. The memory is now
> gone. Result: Kernel crash (Use-After-Free).
>
> Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")
Please add Cc-stable
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
And fixes must be before any code refactorings, so your rename patch
should be after.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v4 1/6] dt-bindings: net: Add support for Airoha AN8801R GbE PHY
From: Rob Herring (Arm) @ 2026-05-21 10:15 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: linux-arm-kernel, Andrew Lunn, linux-mediatek, Russell King,
kevin-kw.huang, matthias.bgg, Andrew Lunn, Jakub Kicinski,
David S. Miller, devicetree, Krzysztof Kozlowski, Heiner Kallweit,
netdev, linux-kernel, AngeloGioacchino Del Regno, Paolo Abeni,
Conor Dooley, kernel, Eric Dumazet, macpaul.lin
In-Reply-To: <20260521-add-airoha-an8801-support-v4-1-1e4837d30ef4@collabora.com>
On Thu, 21 May 2026 10:21:54 +0200, Louis-Alexis Eyraud wrote:
> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> Add a new binding to support the Airoha AN8801R Series Gigabit
> Ethernet PHY.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> .../devicetree/bindings/net/airoha,an8801.yaml | 116 +++++++++++++++++++++
> 1 file changed, 116 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/airoha,an8801.yaml: ^led@[0-2]$: Missing additionalProperties/unevaluatedProperties constraint
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260521-add-airoha-an8801-support-v4-1-1e4837d30ef4@collabora.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v8 4/5] phy: move and rename Airoha PCIe PHY driver to dedicated directory
From: Lorenzo Bianconi @ 2026-05-21 10:13 UTC (permalink / raw)
To: Christian Marangi
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Felix Fietkau, linux-clk, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
In-Reply-To: <20260520150912.11614-5-ansuelsmth@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6921 bytes --]
> To keep the generic PHY directory tidy, move the PCIe PHY driver for
> Airoha AN7581 SoC to a dedicated directory.
>
> Also rename the driver and add the relevant SoC name to the .c and .h
> file in preparation for support of PCIe and USB PHY driver for Airoha
> AN7583 SoC that use a completely different implementation and
> calibration for PHYs and will have their own dedicated drivers.
>
> The rename permits to better identify the specific usage of the driver
> in the future once the airoha PHY directory will have multiple driver
> for multiple SoC.
>
> The config is changed from PHY_AIROHA_PCIE to PHY_AIROHA_AN7581_PCIE.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> MAINTAINERS | 4 ++--
> drivers/phy/Kconfig | 11 +----------
> drivers/phy/Makefile | 4 ++--
> drivers/phy/airoha/Kconfig | 13 +++++++++++++
> drivers/phy/airoha/Makefile | 3 +++
> .../phy-an7581-pcie-regs.h} | 2 +-
> .../{phy-airoha-pcie.c => airoha/phy-an7581-pcie.c} | 6 +++---
> 7 files changed, 25 insertions(+), 18 deletions(-)
> create mode 100644 drivers/phy/airoha/Kconfig
> create mode 100644 drivers/phy/airoha/Makefile
> rename drivers/phy/{phy-airoha-pcie-regs.h => airoha/phy-an7581-pcie-regs.h} (99%)
> rename drivers/phy/{phy-airoha-pcie.c => airoha/phy-an7581-pcie.c} (99%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 932044785a39..7bea8c620da8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -759,8 +759,8 @@ M: Lorenzo Bianconi <lorenzo@kernel.org>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: Documentation/devicetree/bindings/phy/airoha,en7581-pcie-phy.yaml
> -F: drivers/phy/phy-airoha-pcie-regs.h
> -F: drivers/phy/phy-airoha-pcie.c
> +F: drivers/phy/airoha/phy-an7581-pcie-regs.h
> +F: drivers/phy/airoha/phy-an7581-pcie.c
>
> AIROHA SPI SNFI DRIVER
> M: Lorenzo Bianconi <lorenzo@kernel.org>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 227b9a4c612e..f9cd765a3ccc 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -46,16 +46,6 @@ config GENERIC_PHY_MIPI_DPHY
> Provides a number of helpers a core functions for MIPI D-PHY
> drivers to us.
>
> -config PHY_AIROHA_PCIE
> - tristate "Airoha PCIe-PHY Driver"
> - depends on ARCH_AIROHA || COMPILE_TEST
> - depends on OF
> - select GENERIC_PHY
> - help
> - Say Y here to add support for Airoha PCIe PHY driver.
> - This driver create the basic PHY instance and provides initialize
> - callback for PCIe GEN3 port.
> -
> config PHY_CAN_TRANSCEIVER
> tristate "CAN transceiver PHY"
> select GENERIC_PHY
> @@ -133,6 +123,7 @@ config PHY_XGENE
> help
> This option enables support for APM X-Gene SoC multi-purpose PHY.
>
> +source "drivers/phy/airoha/Kconfig"
> source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/apple/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f49d83f00a3d..84062279fa63 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -7,7 +7,6 @@ obj-$(CONFIG_PHY_COMMON_PROPS) += phy-common-props.o
> obj-$(CONFIG_PHY_COMMON_PROPS_TEST) += phy-common-props-test.o
> obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY) += phy-core-mipi-dphy.o
> -obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
> obj-$(CONFIG_PHY_CAN_TRANSCEIVER) += phy-can-transceiver.o
> obj-$(CONFIG_PHY_GOOGLE_USB) += phy-google-usb.o
> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
> @@ -17,7 +16,8 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
> obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
>
> -obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
> +obj-$(CONFIG_GENERIC_PHY) += airoha/ \
> + allwinner/ \
> amlogic/ \
> apple/ \
> broadcom/ \
> diff --git a/drivers/phy/airoha/Kconfig b/drivers/phy/airoha/Kconfig
> new file mode 100644
> index 000000000000..9a1b625a7701
> --- /dev/null
> +++ b/drivers/phy/airoha/Kconfig
> @@ -0,0 +1,13 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Phy drivers for Airoha devices
> +#
> +config PHY_AIROHA_AN7581_PCIE
> + tristate "Airoha AN7581 PCIe-PHY Driver"
> + depends on ARCH_AIROHA || COMPILE_TEST
> + depends on OF
> + select GENERIC_PHY
> + help
> + Say Y here to add support for Airoha AN7581 PCIe PHY driver.
> + This driver create the basic PHY instance and provides initialize
> + callback for PCIe GEN3 port.
> diff --git a/drivers/phy/airoha/Makefile b/drivers/phy/airoha/Makefile
> new file mode 100644
> index 000000000000..912f3e11a061
> --- /dev/null
> +++ b/drivers/phy/airoha/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_PHY_AIROHA_AN7581_PCIE) += phy-an7581-pcie.o
> diff --git a/drivers/phy/phy-airoha-pcie-regs.h b/drivers/phy/airoha/phy-an7581-pcie-regs.h
> similarity index 99%
> rename from drivers/phy/phy-airoha-pcie-regs.h
> rename to drivers/phy/airoha/phy-an7581-pcie-regs.h
> index 58572c793722..b938a7b468fe 100644
> --- a/drivers/phy/phy-airoha-pcie-regs.h
> +++ b/drivers/phy/airoha/phy-an7581-pcie-regs.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> +// SPDX-License-Identifier: GPL-2.0-only
> /*
> * Copyright (c) 2024 AIROHA Inc
> * Author: Lorenzo Bianconi <lorenzo@kernel.org>
> diff --git a/drivers/phy/phy-airoha-pcie.c b/drivers/phy/airoha/phy-an7581-pcie.c
> similarity index 99%
> rename from drivers/phy/phy-airoha-pcie.c
> rename to drivers/phy/airoha/phy-an7581-pcie.c
> index 56e9ade8a9fd..81ddf0e7638b 100644
> --- a/drivers/phy/phy-airoha-pcie.c
> +++ b/drivers/phy/airoha/phy-an7581-pcie.c
> @@ -13,7 +13,7 @@
> #include <linux/platform_device.h>
> #include <linux/slab.h>
>
> -#include "phy-airoha-pcie-regs.h"
> +#include "phy-an7581-pcie-regs.h"
>
> #define LEQ_LEN_CTRL_MAX_VAL 7
> #define FREQ_LOCK_MAX_ATTEMPT 10
> @@ -1279,12 +1279,12 @@ MODULE_DEVICE_TABLE(of, airoha_pcie_phy_of_match);
> static struct platform_driver airoha_pcie_phy_driver = {
> .probe = airoha_pcie_phy_probe,
> .driver = {
> - .name = "airoha-pcie-phy",
> + .name = "airoha-an7581-pcie-phy",
> .of_match_table = airoha_pcie_phy_of_match,
> },
> };
> module_platform_driver(airoha_pcie_phy_driver);
>
> -MODULE_DESCRIPTION("Airoha PCIe PHY driver");
> +MODULE_DESCRIPTION("Airoha AN7581 PCIe PHY driver");
> MODULE_AUTHOR("Lorenzo Bianconi <lorenzo@kernel.org>");
> MODULE_LICENSE("GPL");
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v2 0/5] net: stmmac: eic7700: fix delay calculation and initialization ordering
From: patchwork-bot+netdevbpf @ 2026-05-21 10:10 UTC (permalink / raw)
To: =?utf-8?b?5p2O5b+XIDxsaXpoaTJAZXN3aW5jb21wdXRpbmcuY29tPg==?=
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, netdev, devicetree, linux-kernel, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, linux-stm32,
linux-arm-kernel, ningyu, linmin, pinkesh.vaghela, pritesh.patel,
weishangjuan
In-Reply-To: <20260518021919.404-1-lizhi2@eswincomputing.com>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 18 May 2026 10:19:19 +0800 you wrote:
> From: Zhi Li <lizhi2@eswincomputing.com>
>
> v1 -> v2:
> - Update eswin,eic7700-eth.yaml:
> - Limit the binding changes to adding optional TXD and RXD delay register
> offsets in eswin,hsp-sp-csr.
> - Restore the original enum-based definitions for rx-internal-delay-ps
> and tx-internal-delay-ps.
> - Keep rx-internal-delay-ps and tx-internal-delay-ps as required
> properties.
> - Restore the original example content, with only the additional optional
> TXD and RXD delay register offsets.
> - Restore Acked-by from Conor Dooley for the binding change, which was
> temporarily omitted in v1 during series restructuring and has been
> reinstated now that the change is stable and properly isolated.
>
> [...]
Here is the summary with links:
- [net,v2,1/5] dt-bindings: ethernet: eswin: add optional TXD and RXD delay register offsets
https://git.kernel.org/netdev/net/c/c36069c6f46c
- [net,v2,2/5] net: stmmac: eswin: fix HSP CSR init ordering after clock enable
https://git.kernel.org/netdev/net/c/23386defe949
- [net,v2,3/5] net: stmmac: eswin: clear TXD and RXD delay registers during initialization
https://git.kernel.org/netdev/net/c/6872fb088edc
- [net,v2,4/5] net: stmmac: eswin: correct RGMII delay granularity to 20 ps
https://git.kernel.org/netdev/net/c/6ffcef9bc1fc
- [net,v2,5/5] net: stmmac: eswin: validate RGMII delay values
https://git.kernel.org/netdev/net/c/c2e152f7ce32
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 0/8] hdmi: Add common TMDS character rate constants
From: Javier Martinez Canillas @ 2026-05-21 9:59 UTC (permalink / raw)
To: linux-kernel
Cc: Abhinav Kumar, Alain Volmat, Andrzej Hajda, Andy Yan,
Brian Masney, Chen-Yu Tsai, Chris Morgan, Cristian Ciocaltea,
Daniel Stone, David Airlie, Dmitry Baryshkov, Dmitry Baryshkov,
Heiko Stuebner, Jani Nikula, Jernej Skrabec, Jessica Zhang,
Jonas Karlman, Konrad Dybcio, Laurent Pinchart, Liu Ying,
Luca Ceresoli, Maarten Lankhorst, Marijn Suijten, Maxime Ripard,
Neil Armstrong, Raphael Gallais-Pou, Rob Clark, Robert Foss,
Samuel Holland, Sean Paul, Shengjiu Wang, Simona Vetter,
Thomas Zimmermann, dri-devel, freedreno, linux-arm-kernel,
linux-arm-msm, linux-sunxi
In-Reply-To: <20260520144424.1633354-1-javierm@redhat.com>
Javier Martinez Canillas <javierm@redhat.com> writes:
> Several DRM drivers define their own local macros or use magic numbers for
> the standard HDMI TMDS character rate limits. Maxime Ripard suggested that
> instead these common rate constants could be included to a shared header.
>
> This series introduces these constants to the <linux/hdmi.h> header and
> replaces the local defined constants or magic numbers in drivers.
>
> I split the changes as one patch per driver, so that these can be reviewed
> individually and merged at their own pace.
>
> This is a version 2 that addresses issues pointed out by Maxime Ripard and
> Dmitry Baryshkov.
>
> Changes in v2:
> - Change naming convention to HDMI_$SPEC_TMDS_CHAR_RATE_MAX_HZ (Maxime).
> - Define the constants in <linux/hdmi.h> (Dmitry).
>
> Javier Martinez Canillas (8):
> video/hdmi: Add common TMDS character rate constants
> drm/bridge: dw-hdmi: Use the common TMDS char rate constant
> drm/bridge: dw-hdmi-qp: Use the common TMDS char rate constant
> drm/bridge: inno-hdmi: Use the common TMDS char rate constant
> drm/sti: hdmi: Use the common TMDS char rate constants
> drm/sun4i: hdmi: Use the common TMDS char rate constant
> drm/msm/hdmi: Use the common TMDS char rate constants in 8996 PHY
> drm/msm/hdmi: Use the common TMDS char rate constants in 8998 PHY
>
Pushed to drm-misc (drm-misc-next). Thanks everyone for the feedback and review!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* [soc:soc/arm] BUILD SUCCESS b4e49a4a38fd737f927defb2e9a6562f9ee62f0a
From: kernel test robot @ 2026-05-21 9:55 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/arm
branch HEAD: b4e49a4a38fd737f927defb2e9a6562f9ee62f0a Merge tag 'zx29-plat-for-7.2' of https://gitlab.com/stefandoesinger/zx297520-kernel into soc/arm
elapsed time: 782m
configs tested: 197
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260521 gcc-8.5.0
arc randconfig-002-20260521 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm footbridge_defconfig clang-17
arm randconfig-001-20260521 gcc-8.5.0
arm randconfig-002-20260521 gcc-8.5.0
arm randconfig-003-20260521 gcc-8.5.0
arm randconfig-004-20260521 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260521 gcc-8.5.0
arm64 randconfig-002-20260521 gcc-8.5.0
arm64 randconfig-003-20260521 gcc-8.5.0
arm64 randconfig-004-20260521 gcc-8.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260521 gcc-8.5.0
csky randconfig-002-20260521 gcc-8.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260521 gcc-11.5.0
hexagon randconfig-002-20260521 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260521 clang-20
i386 buildonly-randconfig-002-20260521 clang-20
i386 buildonly-randconfig-003-20260521 clang-20
i386 buildonly-randconfig-004-20260521 clang-20
i386 buildonly-randconfig-005-20260521 clang-20
i386 buildonly-randconfig-006-20260521 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260521 clang-20
i386 randconfig-002-20260521 clang-20
i386 randconfig-003-20260521 clang-20
i386 randconfig-004-20260521 clang-20
i386 randconfig-005-20260521 clang-20
i386 randconfig-006-20260521 clang-20
i386 randconfig-007-20260521 clang-20
i386 randconfig-011-20260521 gcc-14
i386 randconfig-012-20260521 gcc-14
i386 randconfig-013-20260521 gcc-14
i386 randconfig-014-20260521 gcc-14
i386 randconfig-015-20260521 gcc-14
i386 randconfig-016-20260521 gcc-14
i386 randconfig-017-20260521 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260521 gcc-11.5.0
loongarch randconfig-002-20260521 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips rt305x_defconfig clang-23
nios2 10m50_defconfig gcc-11.5.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260521 gcc-11.5.0
nios2 randconfig-002-20260521 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260521 gcc-12.5.0
parisc randconfig-002-20260521 gcc-12.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mgcoge_defconfig clang-23
powerpc mpc837x_rdb_defconfig gcc-15.2.0
powerpc randconfig-001-20260521 gcc-12.5.0
powerpc randconfig-002-20260521 gcc-12.5.0
powerpc sam440ep_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260521 gcc-12.5.0
powerpc64 randconfig-002-20260521 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-15.2.0
riscv randconfig-001-20260521 gcc-15.2.0
riscv randconfig-002 gcc-15.2.0
riscv randconfig-002-20260521 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-15.2.0
s390 randconfig-001-20260521 gcc-15.2.0
s390 randconfig-002 gcc-15.2.0
s390 randconfig-002-20260521 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001 gcc-15.2.0
sh randconfig-001-20260521 gcc-15.2.0
sh randconfig-002 gcc-15.2.0
sh randconfig-002-20260521 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260521 gcc-8.5.0
sparc randconfig-002-20260521 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260521 gcc-8.5.0
sparc64 randconfig-002-20260521 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260521 gcc-8.5.0
um randconfig-002-20260521 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260521 clang-20
x86_64 buildonly-randconfig-002-20260521 clang-20
x86_64 buildonly-randconfig-003-20260521 clang-20
x86_64 buildonly-randconfig-004-20260521 clang-20
x86_64 buildonly-randconfig-005-20260521 clang-20
x86_64 buildonly-randconfig-006-20260521 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260521 clang-20
x86_64 randconfig-002-20260521 clang-20
x86_64 randconfig-003-20260521 clang-20
x86_64 randconfig-004-20260521 clang-20
x86_64 randconfig-005-20260521 clang-20
x86_64 randconfig-006-20260521 clang-20
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260521 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260521 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260521 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260521 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260521 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260521 gcc-14
x86_64 randconfig-071 clang-20
x86_64 randconfig-071-20260521 clang-20
x86_64 randconfig-072 clang-20
x86_64 randconfig-072-20260521 clang-20
x86_64 randconfig-073 clang-20
x86_64 randconfig-073-20260521 clang-20
x86_64 randconfig-074 clang-20
x86_64 randconfig-074-20260521 clang-20
x86_64 randconfig-075 clang-20
x86_64 randconfig-075-20260521 clang-20
x86_64 randconfig-076 clang-20
x86_64 randconfig-076-20260521 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260521 gcc-8.5.0
xtensa randconfig-002-20260521 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 3/4] mfd: max77620: override PSCI poweroff handler on Pixel C
From: Diogo Ivo @ 2026-05-21 9:49 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, Lorenzo Pieralisi, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, linux-arm-kernel, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <ag7TenB3GrdLABuk@orome>
On 5/21/26 11:43, Thierry Reding wrote:
> On Thu, May 21, 2026 at 11:23:11AM +0200, Diogo Ivo wrote:
>>
>>
>> On 5/21/26 09:52, Thierry Reding wrote:
>>> On Thu, May 14, 2026 at 04:47:21PM +0200, Diogo Ivo wrote:
>>>> On Pixel C, shutdown must be handled by the MAX77620 PMIC rather
>>>> than the PSCI SYSTEM_OFF call, whose firmware implementation is:
>>>>
>>>> __dead2 void tegra_system_off(void)
>>>> {
>>>> ERROR("Tegra System Off: operation not handled.\n");
>>>> panic();
>>>> }
>>>
>>> Ugh... sounds very familiar. We have similar stub implementations on
>>> Jetson TX1 and/or Nano, if I remember correctly. Luckily newer platforms
>>> seem to have proper implementations for these.
>>
>> Yes, on my TX1 I was encountering the same problem. However in that case
>> is it possible to update the firmware with a proper implementation?
>
> I tried, but there were complications, both technical and logistical
> because of the point in the product lifecycle. At this point I don't
> think it will happen, unfortunately.
Ah, I see. Then in that case this approach seems like a viable option
for those platforms :)
Best regards,
Diogo
> Thierry
^ permalink raw reply
* Re: [PATCH 1/2] arm64: mm: Add note about overlays in PIE_EL1
From: Kevin Brodsky @ 2026-05-21 9:48 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Catalin Marinas, Joey Gouly, Mark Brown, Shuah Khan, Will Deacon,
linux-kernel, linux-kselftest
In-Reply-To: <20260521-poe_futex-v1-1-1da286b8f9b2@arm.com>
On 21/05/2026 11:42, Kevin Brodsky wrote:
> It isn't completely obvious why user page types do not have overlays
> applied in PIE_EL1. Add a comment to that effect, to avoid
> unpleasant surprises in the future.
Should probably s/PIE_EL1/PIR_EL1/ in this whole patch.
I'm also tempted to rename PIE_E* to PIR_E* to avoid anyone else's brain
being confused like mine... The extension is called PIE, but this is
really about the register configuration, i.e. PIR.
- Kevin
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> ---
> arch/arm64/include/asm/pgtable-prot.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index 212ce1b02e15..6e2f99820909 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -175,6 +175,13 @@ static inline bool __pure lpa2_is_enabled(void)
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_READONLY), PIE_R_O) | \
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_SHARED), PIE_RW_O))
>
> +/*
> + * Regular user page types such as _PAGE_SHARED must not have overlays applied
> + * in PIE_EL1. If POE is enabled at EL1, and in the absence of FEAT_LSUI, this
> + * would break futex atomic operations on user memory with a non-default
> + * POIndex; the privileged atomic load/store instructions would be mistakenly
> + * checked against POR_EL1.
> + */
> #define PIE_E1 ( \
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_GCS), PIE_NONE_O) | \
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_GCS_RO), PIE_NONE_O) | \
>
^ permalink raw reply
* Re: (subset) [PATCH 0/4] power: sys-off: fix Pixel C shutdown via MAX77620
From: Diogo Ivo @ 2026-05-21 9:47 UTC (permalink / raw)
To: Lee Jones, Mark Rutland, Lorenzo Pieralisi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-tegra
In-Reply-To: <177929432727.2891971.15568098895295536822.b4-ty@b4>
Hi Lee,
On 5/20/26 18:25, Lee Jones wrote:
> On Thu, 14 May 2026 16:47:18 +0200, Diogo Ivo wrote:
>> This series migrates PSCI and MAX77620 poweroff handling to the
>> sys-off framework and fixes shutdown on the Pixel C (Smaug).
>>
>> The first two patches replace legacy pm_power_off usage in the PSCI
>> and MAX77620 drivers with sys-off handlers. Besides aligning both
>> drivers with the modern poweroff infrastructure, this removes the
>> global callback dependency and allows multiple handlers to coexist
>> with explicit priorities.
>>
>> [...]
>
> Applied, thanks!
Thanks for applying the patches! Just a question and an observation:
- I'm assuming you were ok with merging [2/4] despite the possible
deadlock since this risk is already present in mainline in the same
form so we're not actually making things worse, is that so?
- The observation is that the comment about overriding PSCI is only
true after (and if) a reworked [1/4] is actually merged.
If it isn't then patch [3/4] is actually working around another handler
in soc/tegra/pmc.c where a handler that only does work for the Nexus
7 is actually registered at FIRMWARE level for all platforms that
probe that driver (I will send out a patch shortly to only register
the handler on the Nexus 7).
Best regards,
Diogo
> [2/4] mfd: max77620: convert poweroff support to sys-off API
> commit: 1ada6d7f88063dd6fd92d74d0b803875b695fe01
> [3/4] mfd: max77620: override PSCI poweroff handler on Pixel C
> commit: ea3f90bcc8524c6d514f6b8183cc202b79b082be
>
> --
> Lee Jones [李琼斯]
>
^ permalink raw reply
* Re: [PATCH 3/4] mfd: max77620: override PSCI poweroff handler on Pixel C
From: Thierry Reding @ 2026-05-21 9:43 UTC (permalink / raw)
To: Diogo Ivo
Cc: Mark Rutland, Lorenzo Pieralisi, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, linux-arm-kernel, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <367bb557-81a0-4286-8788-0e7272cc4d02@tecnico.ulisboa.pt>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
On Thu, May 21, 2026 at 11:23:11AM +0200, Diogo Ivo wrote:
>
>
> On 5/21/26 09:52, Thierry Reding wrote:
> > On Thu, May 14, 2026 at 04:47:21PM +0200, Diogo Ivo wrote:
> > > On Pixel C, shutdown must be handled by the MAX77620 PMIC rather
> > > than the PSCI SYSTEM_OFF call, whose firmware implementation is:
> > >
> > > __dead2 void tegra_system_off(void)
> > > {
> > > ERROR("Tegra System Off: operation not handled.\n");
> > > panic();
> > > }
> >
> > Ugh... sounds very familiar. We have similar stub implementations on
> > Jetson TX1 and/or Nano, if I remember correctly. Luckily newer platforms
> > seem to have proper implementations for these.
>
> Yes, on my TX1 I was encountering the same problem. However in that case
> is it possible to update the firmware with a proper implementation?
I tried, but there were complications, both technical and logistical
because of the point in the product lifecycle. At this point I don't
think it will happen, unfortunately.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] interconnect: qcom: Make important drivers default
From: Konrad Dybcio @ 2026-05-21 9:43 UTC (permalink / raw)
To: Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel
In-Reply-To: <20260515-interconnect-qcom-clean-arm64-v2-3-adeebc73596d@oss.qualcomm.com>
On 5/15/26 2:11 PM, Krzysztof Kozlowski wrote:
> The interconnect drivers for Qualcomm SoC Network-on-Chip are covering a
> basic or fundamental SoC feature: bandwidth management between internal
> SoC blocks. SoC can boot without these, but power management or
> performance will be affected. These drivers do not represent any sort
> of buses visible to the board designers/configurators, thus they should
> be always enabled, regardless how SoC is used in the final board.
>
> Kernel configuration should not ask users choice of drivers when that
> choice is obvious and known to the developers that answer should be
> 'yes' or 'module'.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH 2/2] kselftest/arm64: Add test for atomic futex uaccess with POE
From: Kevin Brodsky @ 2026-05-21 9:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Kevin Brodsky, Catalin Marinas, Joey Gouly, Mark Brown,
Shuah Khan, Will Deacon, linux-kernel, linux-kselftest
In-Reply-To: <20260521-poe_futex-v1-0-1da286b8f9b2@arm.com>
Add a new test to ensure that atomic futex uaccess succeeds on
memory mapped with a non-default POIndex/pkey.
In the absence of FEAT_LSUI, atomic futex uaccess operations such as
those triggered by FUTEX_WAKE_OP use privileged atomic load/store
instructions and thus cannot have user permission overlays applied
(as per POR_EL0). In case the kernel enabled POE at EL1, it is worth
checking that PIR_EL1 isn't mistakenly configured to have kernel
overlays (POR_EL1) applied instead, as that would fail for non-zero
pkeys.
Note that if such misconfiguration occurs, futex_wake_op() may get
stuck in an infinite loop because futex_atomic_op_inuser() will fail
but fault_in_user_writeable() will still report success.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
tools/testing/selftests/arm64/Makefile | 2 +-
tools/testing/selftests/arm64/poe/.gitignore | 2 +
tools/testing/selftests/arm64/poe/Makefile | 6 +++
tools/testing/selftests/arm64/poe/poe_futex.c | 62 +++++++++++++++++++++++++++
4 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
index e456f3b62fa1..bad5c3b33dce 100644
--- a/tools/testing/selftests/arm64/Makefile
+++ b/tools/testing/selftests/arm64/Makefile
@@ -4,7 +4,7 @@
ARCH ?= $(shell uname -m 2>/dev/null || echo not)
ifneq (,$(filter $(ARCH),aarch64 arm64))
-ARM64_SUBTARGETS ?= tags signal pauth fp mte bti abi gcs
+ARM64_SUBTARGETS ?= tags signal pauth fp mte bti abi gcs poe
else
ARM64_SUBTARGETS :=
endif
diff --git a/tools/testing/selftests/arm64/poe/.gitignore b/tools/testing/selftests/arm64/poe/.gitignore
new file mode 100644
index 000000000000..0dce4a3aa38b
--- /dev/null
+++ b/tools/testing/selftests/arm64/poe/.gitignore
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+poe_futex
diff --git a/tools/testing/selftests/arm64/poe/Makefile b/tools/testing/selftests/arm64/poe/Makefile
new file mode 100644
index 000000000000..2af2bbf3f6d3
--- /dev/null
+++ b/tools/testing/selftests/arm64/poe/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+
+CFLAGS += $(KHDR_INCLUDES)
+TEST_GEN_PROGS := poe_futex
+
+include ../../lib.mk
diff --git a/tools/testing/selftests/arm64/poe/poe_futex.c b/tools/testing/selftests/arm64/poe/poe_futex.c
new file mode 100644
index 000000000000..21a2e109ee43
--- /dev/null
+++ b/tools/testing/selftests/arm64/poe/poe_futex.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <stdint.h>
+#include <stdlib.h>
+#include <unistd.h>
+
+#include <linux/futex.h>
+#include <sys/syscall.h>
+
+#include "kselftest_harness.h"
+
+static int sys_pkey_alloc(unsigned long flags, unsigned long init_val)
+{
+ return syscall(__NR_pkey_alloc, flags, init_val);
+}
+
+static int sys_pkey_mprotect(void *ptr, size_t size, int prot, int pkey)
+{
+ return syscall(__NR_pkey_mprotect, ptr, size, prot, pkey);
+}
+
+static int futex_wake_op(uint32_t *uaddr, uint32_t val, uint32_t val2,
+ uint32_t *uaddr2, uint32_t val3)
+{
+ return syscall(SYS_futex, uaddr, FUTEX_WAKE_OP, val, val2,
+ uaddr2, val3);
+}
+
+/*
+ * Trigger some atomic uaccess on a page mapped with a non-default pkey.
+ *
+ * This ensures that such access is not mistakenly checked against the
+ * kernel's POR_EL1 register.
+ */
+TEST(poe_futex)
+{
+ int ret, pkey;
+ void *ptr;
+ size_t size = getpagesize();
+
+ pkey = sys_pkey_alloc(0, 0);
+
+ if (pkey == -1 && errno == ENOSPC)
+ SKIP(return, "pkeys are not supported");
+
+ ASSERT_GT(pkey, 0);
+
+ ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ ASSERT_NE(ptr, MAP_FAILED);
+
+ ret = sys_pkey_mprotect(ptr, size, PROT_READ | PROT_WRITE, pkey);
+ ASSERT_EQ(ret, 0);
+
+ /*
+ * There is no one to wake up so this syscall boils down to *(ptr+4) = 0
+ * (arch_futex_atomic_op_inuser() called with FUTEX_OP_SET and op_arg=0).
+ */
+ ret = futex_wake_op(ptr, 1, 1, ptr + sizeof(uint32_t), 0);
+ ASSERT_EQ(ret, 0);
+}
+
+TEST_HARNESS_MAIN
--
2.51.2
^ permalink raw reply related
* Re: [PATCH v2 1/3] interconnect: qcom: Fix indentation
From: Konrad Dybcio @ 2026-05-21 9:42 UTC (permalink / raw)
To: Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel
In-Reply-To: <20260515-interconnect-qcom-clean-arm64-v2-1-adeebc73596d@oss.qualcomm.com>
On 5/15/26 2:11 PM, Krzysztof Kozlowski wrote:
> KConfig entries should be indented starting with one tab, so replace
> spaces with it.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH 1/2] arm64: mm: Add note about overlays in PIE_EL1
From: Kevin Brodsky @ 2026-05-21 9:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Kevin Brodsky, Catalin Marinas, Joey Gouly, Mark Brown,
Shuah Khan, Will Deacon, linux-kernel, linux-kselftest
In-Reply-To: <20260521-poe_futex-v1-0-1da286b8f9b2@arm.com>
It isn't completely obvious why user page types do not have overlays
applied in PIE_EL1. Add a comment to that effect, to avoid
unpleasant surprises in the future.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
arch/arm64/include/asm/pgtable-prot.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index 212ce1b02e15..6e2f99820909 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -175,6 +175,13 @@ static inline bool __pure lpa2_is_enabled(void)
PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_READONLY), PIE_R_O) | \
PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_SHARED), PIE_RW_O))
+/*
+ * Regular user page types such as _PAGE_SHARED must not have overlays applied
+ * in PIE_EL1. If POE is enabled at EL1, and in the absence of FEAT_LSUI, this
+ * would break futex atomic operations on user memory with a non-default
+ * POIndex; the privileged atomic load/store instructions would be mistakenly
+ * checked against POR_EL1.
+ */
#define PIE_E1 ( \
PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_GCS), PIE_NONE_O) | \
PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_GCS_RO), PIE_NONE_O) | \
--
2.51.2
^ permalink raw reply related
* [PATCH 0/2] Add test for atomic uaccess with permission overlay
From: Kevin Brodsky @ 2026-05-21 9:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Kevin Brodsky, Catalin Marinas, Joey Gouly, Mark Brown,
Shuah Khan, Will Deacon, linux-kernel, linux-kselftest
Permission overlays are not currently applied for memory types
configured in PIR_EL1, meaning that even if POE were enabled at EL1,
memory accesses would not be subject to POE restrictions.
A patch [1] in my series adding page table protection using
pkeys/POE [2] enabled overlays for all memory types in PIR_EL1. It
turns out this is wrong, as reported by Sashiko [3]. User memory
types must not have overlays applied in PIR_EL1, otherwise direct
accesses to user memory with privileged loads/stores (and PAN
disabled) will mistakenly be checked against POR_EL1, instead of the
intended POR_EL0.
To avoid any accident in the future, this series adds a comment
above the PIR_EL1 configuration block, and a kselftest to ensure
that atomic futex uaccess (which uses privileged loads/stores unless
FEAT_LSUI is available) does work on memory mapped with a
non-default pkey.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
[1] https://lore.kernel.org/all/20260505-kpkeys-v7-3-20c0bdd97197@arm.com/
[2] https://lore.kernel.org/all/20260505-kpkeys-v7-0-20c0bdd97197@arm.com/
[3] https://sashiko.dev/#/patchset/20260505-kpkeys-v7-0-20c0bdd97197%40arm.com?part=3
---
To: linux-arm-kernel@lists.infradead.org
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Joey Gouly <joey.gouly@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org
---
Kevin Brodsky (2):
arm64: mm: Add note about overlays in PIE_EL1
kselftest/arm64: Add test for atomic futex uaccess with POE
arch/arm64/include/asm/pgtable-prot.h | 7 +++
tools/testing/selftests/arm64/Makefile | 2 +-
tools/testing/selftests/arm64/poe/.gitignore | 2 +
tools/testing/selftests/arm64/poe/Makefile | 6 +++
tools/testing/selftests/arm64/poe/poe_futex.c | 62 +++++++++++++++++++++++++++
5 files changed, 78 insertions(+), 1 deletion(-)
---
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
change-id: 20260520-poe_futex-ecb8c2276894
^ permalink raw reply
* Re: [PATCH 2/8] bpf: Recover arena kernel faults with scratch page
From: Alexei Starovoitov @ 2026-05-21 9:42 UTC (permalink / raw)
To: Tejun Heo, David Vernet, Andrea Righi, Changwoo Min,
Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Kumar Kartikeya Dwivedi
Cc: Peter Zijlstra, Catalin Marinas, Will Deacon, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, Andrew Morton,
David Hildenbrand, Mike Rapoport, Emil Tsalapatis, sched-ext, bpf,
x86, linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <20260520235052.4180316-3-tj@kernel.org>
On Wed May 20, 2026 at 4:50 PM PDT, Tejun Heo wrote:
>
> v2: Use ptep_get_and_clear() in apply_range_clear_cb(). (David)
>
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: David Hildenbrand <david@kernel.org>
> ---
> Documentation/bpf/kfuncs.rst | 14 +++
> arch/arm64/mm/fault.c | 10 +-
> arch/x86/mm/fault.c | 12 ++-
> include/linux/bpf.h | 1 +
> include/linux/bpf_defs.h | 11 +++
> kernel/bpf/arena.c | 177 +++++++++++++++++++++++++++--------
> kernel/bpf/core.c | 5 +
> 7 files changed, 183 insertions(+), 47 deletions(-)
> create mode 100644 include/linux/bpf_defs.h
First 5 patches lgtm. Should we create a stable branch out of them
and pull into bpf-next and sched-ext trees?
I'm preparing a followup for slab-over-arena on top of these changes.
^ permalink raw reply
* Re: [RFC V2 01/14] mm: Abstract printing of pxd_val()
From: David Laight @ 2026-05-21 9:42 UTC (permalink / raw)
To: Dave Hansen
Cc: Anshuman Khandual, linux-arm-kernel, Catalin Marinas, Will Deacon,
Ryan Roberts, Mark Rutland, Lorenzo Stoakes, Andrew Morton,
David Hildenbrand, Mike Rapoport, Linu Cherian, Usama Arif,
linux-kernel, linux-mm
In-Reply-To: <74f66e30-ab3d-4352-89ef-1bccc7e9daeb@intel.com>
On Tue, 19 May 2026 07:28:17 -0700
Dave Hansen <dave.hansen@intel.com> wrote:
> On 5/12/26 21:45, Anshuman Khandual wrote:
> > if (!p4d_present(p4d) || p4d_leaf(p4d)) {
> > - pr_alert("pgd:%08llx p4d:%08llx\n", pgdv, p4dv);
> > + pr_alert("pgd:%" __PRIpxx " p4d:%" __PRIpxx "\n",
> > + __PRIpxx_args(pgdv), __PRIpxx_args(p4dv));
> > return;
> > }
>
> That's not the most readable result. Could a printk() format specifier
> make this nicer? Maybe use "%pT"?
>
> pr_alert("pgd:%pT p4d:%pT\n", &pgd, &p4d);
>
> I _think_ it could even get rid of the p??v variables.
>
Adding another %p variant that is only used in a few places just makes
it all harder to read.
Perhaps a local helper that lets you do:
char pdgv_buf[??]:
pr_alert("... %s ...", ... fmt_pdgv(pdgv_buf, pdgv) ...)
might be a reasonable compromise.
-- David
^ permalink raw reply
* Re: [PATCH v2 00/11] drm/rockchip: dw_hdmi: Misc cleanup and propagate bus format
From: Heiko Stuebner @ 2026-05-21 9:40 UTC (permalink / raw)
To: Sandy Huang, Andy Yan, Jonas Karlman, Vladimir Oltean
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, dri-devel, linux-rockchip, linux-arm-kernel,
linux-kernel, Jonas Karlman
In-Reply-To: <20260518193748.2482823-1-jonas@kwiboo.se>
Am Montag, 18. Mai 2026, 21:37:34 Mitteleuropäische Sommerzeit schrieb Jonas Karlman:
> This series include misc cleanup of the dwhdmi-rockchip driver and
> prepares for future support of YCbCr output and Deep Color modes.
>
> Patch 1-7 cleanup and changes to use drmres helpers for the encoder.
> Patch 8 prepare for use of a display-connector bridge for RK3568/RK3566.
> Patch 9-10 prepares for future support of YCbCr and Deep Color modes.
> Patch 11 changes to use resume_early pm ops for system suspend.
>
> This series depends on the patch "drm/rockchip: dw_hdmi: avoid direct
> dereference of phy->dev.of_node" [1] from the series "Split Generic PHY
> consumer and provider API" [2].
>
> [1] https://lore.kernel.org/linux-phy/20260505100523.1922388-16-vladimir.oltean@nxp.com/
> [2] https://lore.kernel.org/linux-phy/20260505100523.1922388-1-vladimir.oltean@nxp.com/
With Vladimir's agreement, I've pulled that patch out of the phy-series
and applied it to drm-misc-next - as it's a change that can stand on
its own.
Series:
Tested-by: Heiko Stuebner <heiko@sntech.de> #rk3328
^ permalink raw reply
* [PATCH v5 3/3] PCI: imx6: Add root port reset to support link recovery
From: Richard Zhu @ 2026-05-21 9:32 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel,
Richard Zhu
In-Reply-To: <20260521093255.61585-1-hongxing.zhu@nxp.com>
The PCIe link can go down due to various unexpected circumstances. Add
root port reset support to enable link recovery for the i.MX PCIe
controller when the optional "intr" interrupt is present.
Reset root port to uninitialize, initialize the PCIe controller, and
restart the PCIe link at end when a link down event happens.
On i.MX95 platforms, link events and PME share the same interrupt line.
The link event interrupt cannot use a threaded-only IRQ handler because
the PME driver uses request_irq() with only the IRQF_SHARED flag set,
which requires a primary handler.
To handle this shared interrupt scenario, register a primary interrupt
handler with IRQF_SHARED for link events and manipulate the link event
enable bits to ensure the shared interrupt source triggers only one
handler at a time.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 124 ++++++++++++++++++++++++++
1 file changed, 124 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 1034ac5c5f5c..c286581bede8 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -34,6 +34,7 @@
#include <linux/pm_runtime.h>
#include "../../pci.h"
+#include "../pci-host-common.h"
#include "pcie-designware.h"
#define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
@@ -78,6 +79,10 @@
#define IMX95_SID_MASK GENMASK(5, 0)
#define IMX95_MAX_LUT 32
+#define IMX95_LINK_INT_CTRL_STS 0x1040
+#define IMX95_LINK_DOWN_INT_STS BIT(11)
+#define IMX95_LINK_DOWN_INT_EN BIT(10)
+
#define IMX95_PCIE_RST_CTRL 0x3010
#define IMX95_PCIE_COLD_RST BIT(0)
@@ -125,6 +130,8 @@ enum imx_pcie_variants {
#define IMX_PCIE_MAX_INSTANCES 2
struct imx_pcie;
+static int imx_pcie_reset_root_port(struct pci_host_bridge *bridge,
+ struct pci_dev *pdev);
struct imx_pcie_drvdata {
enum imx_pcie_variants variant;
@@ -158,6 +165,7 @@ struct imx_pcie {
bool supports_clkreq;
bool enable_ext_refclk;
struct regmap *iomuxc_gpr;
+ u32 lnk_intr;
u16 msi_ctrl;
u32 controller_id;
struct reset_control *pciephy_reset;
@@ -1301,6 +1309,13 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
imx_setup_phy_mpll(imx_pcie);
+ /*
+ * Callback invoked by PCI core when link down is detected and
+ * recovery is needed.
+ */
+ if (pp->bridge)
+ pp->bridge->reset_root_port = imx_pcie_reset_root_port;
+
return 0;
err_phy_off:
@@ -1568,6 +1583,9 @@ static int imx_pcie_suspend_noirq(struct device *dev)
if (!(imx_pcie->drvdata->flags & IMX_PCIE_FLAG_SUPPORTS_SUSPEND))
return 0;
+ if (imx_pcie->lnk_intr)
+ regmap_clear_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
imx_pcie_msi_save_restore(imx_pcie, true);
if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT))
imx_pcie_lut_save(imx_pcie);
@@ -1618,6 +1636,9 @@ static int imx_pcie_resume_noirq(struct device *dev)
if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT))
imx_pcie_lut_restore(imx_pcie);
imx_pcie_msi_save_restore(imx_pcie, false);
+ if (imx_pcie->lnk_intr)
+ regmap_set_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
return 0;
}
@@ -1627,6 +1648,85 @@ static const struct dev_pm_ops imx_pcie_pm_ops = {
imx_pcie_resume_noirq)
};
+static irqreturn_t imx_pcie_lnk_irq_isr(int irq, void *priv)
+{
+ struct imx_pcie *imx_pcie = priv;
+ struct dw_pcie *pci = imx_pcie->pci;
+ struct device *dev = pci->dev;
+ u32 val;
+
+ regmap_read(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS, &val);
+ if (val & IMX95_LINK_DOWN_INT_STS) {
+ dev_dbg(dev, "PCIe link down detected, initiating recovery\n");
+ regmap_clear_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
+ /* Clear link down interrupt status by writing 1b'1 to it */
+ regmap_set_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_STS);
+
+ return IRQ_WAKE_THREAD;
+ } else {
+ return IRQ_NONE;
+ }
+}
+
+static irqreturn_t imx_pcie_lnk_irq_thread(int irq, void *priv)
+{
+ struct imx_pcie *imx_pcie = priv;
+ struct dw_pcie *pci = imx_pcie->pci;
+ struct dw_pcie_rp *pp = &pci->pp;
+ struct pci_dev *port;
+
+ for_each_pci_bridge(port, pp->bridge->bus)
+ if (pci_pcie_type(port) == PCI_EXP_TYPE_ROOT_PORT)
+ pci_host_handle_link_down(port);
+
+ regmap_set_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
+
+ return IRQ_HANDLED;
+}
+
+static int imx_pcie_reset_root_port(struct pci_host_bridge *bridge,
+ struct pci_dev *pdev)
+{
+ struct pci_bus *bus = bridge->bus;
+ struct dw_pcie_rp *pp = bus->sysdata;
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct imx_pcie *imx_pcie = to_imx_pcie(pci);
+ int ret;
+
+ imx_pcie_msi_save_restore(imx_pcie, true);
+ if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT))
+ imx_pcie_lut_save(imx_pcie);
+ imx_pcie_stop_link(pci);
+ imx_pcie_host_exit(pp);
+
+ ret = imx_pcie_host_init(pp);
+ if (ret) {
+ dev_err(pci->dev, "Failed to re-init PCIe\n");
+ return ret;
+ }
+ ret = dw_pcie_setup_rc(pp);
+ if (ret)
+ goto err_host_deinit;
+
+ imx_pcie_start_link(pci);
+ dw_pcie_wait_for_link(pci);
+
+ if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT))
+ imx_pcie_lut_restore(imx_pcie);
+ imx_pcie_msi_save_restore(imx_pcie, false);
+
+ dev_dbg(pci->dev, "Root port reset completed\n");
+ return 0;
+
+err_host_deinit:
+ imx_pcie_host_exit(pp);
+
+ return ret;
+}
+
static int imx_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1829,9 +1929,33 @@ static int imx_pcie_probe(struct platform_device *pdev)
val |= PCI_MSI_FLAGS_ENABLE;
dw_pcie_writew_dbi(pci, offset + PCI_MSI_FLAGS, val);
}
+
+ /* Get link event irq if it is present */
+ imx_pcie->lnk_intr = platform_get_irq_byname(pdev, "intr");
+ if (imx_pcie->lnk_intr > 0) {
+ ret = devm_request_threaded_irq(dev, imx_pcie->lnk_intr,
+ imx_pcie_lnk_irq_isr,
+ imx_pcie_lnk_irq_thread,
+ IRQF_SHARED,
+ "lnk", imx_pcie);
+ if (ret) {
+ dev_err_probe(dev, ret,
+ "unable to request LNK IRQ\n");
+ goto err_host_deinit;
+ }
+
+ regmap_set_bits(imx_pcie->iomuxc_gpr,
+ IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
+ }
}
return 0;
+
+err_host_deinit:
+ dw_pcie_host_deinit(&pci->pp);
+
+ return ret;
}
static void imx_pcie_shutdown(struct platform_device *pdev)
--
2.37.1
^ permalink raw reply related
* [PATCH v5 2/3] arm64: dts: imx95: Add dma, intr, aer and pme interrupts for PCIe
From: Richard Zhu @ 2026-05-21 9:32 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel,
Richard Zhu
In-Reply-To: <20260521093255.61585-1-hongxing.zhu@nxp.com>
The current PCIe device tree configuration only defines the MSI
interrupt, which is sufficient for basic PCIe operation but limits
advanced functionality.
Add the following interrupt lines to pcie0 and pcie1 nodes:
- dma: DMA interrupt for PCIe DMA operations
- intr: General controller events and link state changes
- aer: Advanced Error Reporting interrupt
- pme: Power Management Event interrupt
This enables enhanced PCIe features and capabilities that were
previously unavailable due to missing interrupt definitions.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95.dtsi | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index adcc0e1d3696..f40388958717 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1948,8 +1948,12 @@ pcie0: pcie@4c300000 {
bus-range = <0x00 0xff>;
num-lanes = <1>;
num-viewport = <8>;
- interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "msi";
+ interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi", "dma", "intr", "aer", "pme";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
@@ -2023,8 +2027,12 @@ pcie1: pcie@4c380000 {
bus-range = <0x00 0xff>;
num-lanes = <1>;
num-viewport = <8>;
- interrupts = <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "msi";
+ interrupts = <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi", "dma", "intr", "aer", "pme";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>,
--
2.37.1
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: imx6q-pcie: Add optional interrupt entries for intr, aer and pme
From: Richard Zhu @ 2026-05-21 9:32 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel,
Richard Zhu, Frank Li
In-Reply-To: <20260521093255.61585-1-hongxing.zhu@nxp.com>
The i.MX95 PCIe controller introduces three dedicated hardware interrupt
lines:
- intr: general controller events
- aer: Advanced Error Reporting
- pme: Power Management Events
Earlier i.MX PCIe variants (imx6q, imx6sx, imx6qp, imx7d, imx8mm, imx8mp,
imx8mq, imx8q) do not have these dedicated interrupt lines.
PCIe basic functionality (enumeration, configuration, and data transfer)
works correctly regardless of whether these interrupts are present. Mark
these interrupts as optional to maintain backward compatibility with SoCs
that lack these hardware interrupt lines.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 9d1349855b42..cf709132ff1e 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -58,12 +58,18 @@ properties:
items:
- description: builtin MSI controller.
- description: builtin DMA controller.
+ - description: PCIe event interrupt.
+ - description: builtin AER SPI standalone interrupt line.
+ - description: builtin PME SPI standalone interrupt line.
interrupt-names:
minItems: 1
items:
- const: msi
- const: dma
+ - const: intr
+ - const: aer
+ - const: pme
reset-gpio:
description: Should specify the GPIO for controlling the PCI bus device
--
2.37.1
^ permalink raw reply related
* [PATCH v5 0/3] Add root port reset to support link recovery
From: Richard Zhu @ 2026-05-21 9:32 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel
Based on the following patch-set[1] issued by Mani.
Add support for resetting the Root Port for i.MX PCIe to enable link recovery.
[1] [PATCH v8 0/5] PCI: Add support for resetting the Root Ports in a platform specific way
PCIe links can go down due to various unexpected circumstances. This patch series
adds root port reset support for link recovery on i.MX PCIe controllers when the
optional "intr" interrupt is present.
When a link down event is detected, the root port reset uninitializes and
reinitializes the PCIe controller, then restarts the PCIe link.
On i.MX95 platforms, link events and PME share the same interrupt line.
Link event interrupts cannot use only an IRQ thread handler because the PME
driver uses request_irq() to bind the PME interrupt directly with only the
IRQF_SHARED flag set.
To address this, we register one handler with IRQF_SHARED for link event
interrupts and manipulate the enable bits of link events to ensure the same
interrupt source is triggered only once at a time.
Additionally, this series adds 'intr', 'aer', and 'pme' interrupt entries to
the i.MX6Q PCIe binding to support PCIe event-based interrupts for general
controller events, Advanced Error Reporting, and Power Management Events
respectively.
Changes in v5:
- Update the commit message of the first dt-binding patch for clarity.
- Add explicit comment explaining that writing 1 to IMX95_LINK_DOWN_INT_STS
clears the bit
Changes in v4:
- Set these new added three interrupts as optional interrupt.
Changes in v3:
- Don't add a new if:block; Drop the maxItems constraint of the interrupts
property for i.MX95 PCIe.
- Add constraints for the interrupts property for other variants.
- Regarding the ABI break: add descriptions explaining why these new
interrupts are mandatory and required by i.MX95 PCIe.
Changes in v2:
- Constrain the new added three interrupt entries to be valid only for the
i.MX95 variant using conditional schemas
[PATCH v5 1/3] dt-bindings: imx6q-pcie: Add optional interrupt
[PATCH v5 2/3] arm64: dts: imx95: Add dma, intr, aer and pme
[PATCH v5 3/3] PCI: imx6: Add root port reset to support link
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 +++++
arch/arm64/boot/dts/freescale/imx95.dtsi | 16 +++++++++---
drivers/pci/controller/dwc/pci-imx6.c | 124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 142 insertions(+), 4 deletions(-)
^ permalink raw reply
* RE: [PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for i.MX93
From: G.N. Zhou (OSS) @ 2026-05-21 9:29 UTC (permalink / raw)
To: Alexander Stein, Michael Riesch, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil, G.N. Zhou (OSS)
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, G.N. Zhou (OSS)
In-Reply-To: <10853728.nUPlyArG6x@steina-w>
Hi Alexander,
> -----Original Message-----
> From: Alexander Stein <alexander.stein@ew.tq-group.com>
> Sent: Wednesday, May 20, 2026 7:12 PM
> To: Michael Riesch <michael.riesch@collabora.com>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Heiko Stuebner
> <heiko@sntech.de>; Laurent Pinchart <laurent.pinchart@ideasonboard.com>;
> Frank Li <frank.li@nxp.com>; Sakari Ailus <sakari.ailus@linux.intel.com>; Bryan
> O'Donoghue <bryan.odonoghue@linaro.org>; Mehdi Djait
> <mehdi.djait@linux.intel.com>; Hans Verkuil <hverkuil+cisco@kernel.org>;
> G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> Cc: linux-media@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; linux-rockchip@lists.infradead.org; G.N. Zhou (OSS)
> <guoniu.zhou@oss.nxp.com>
> Subject: Re: [PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for
> i.MX93
>
> Hi,
>
> Am Dienstag, 19. Mai 2026, 04:07:41 CEST schrieb Guoniu Zhou:
> > Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
> > ensures proper PHY initialization by verifying that the clock lane and
> > all active data lanes have entered the stop state before proceeding
> > with further operations.
> >
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> > ---
> > Changes in v2:
> > - Removes redundant register availability check
> > - Uses read_poll_timeout() with dw_mipi_csi2rx_read() instead of
> > readl_poll_timeout() with direct register address
> > - Fixes stopstate condition logic
> > - Check PHY stopstate after sensor enable instead of before to ensure
> > correct timing.
> > - Optimize PHY stopstate polling parameters (1000us->10us, 2s->1ms) to
> > balance performance and responsiveness.
> > ---
> > drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 36
> > ++++++++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> > b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> > index 92178a3dec5d..8a34aec550ad 100644
> > --- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> > +++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> > @@ -11,6 +11,7 @@
> > #include <linux/clk.h>
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > +#include <linux/iopoll.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/phy/phy.h>
> > @@ -35,6 +36,8 @@
> > #define DW_REG_EXIST BIT(31)
> > #define DW_REG(x) (DW_REG_EXIST | (x))
> >
> > +#define DPHY_STOPSTATE_CLK_LANE BIT(16)
> > +
> > #define DPHY_TEST_CTRL0_TEST_CLR BIT(0)
> >
> > #define IPI_VCID_VC(x) FIELD_PREP(GENMASK(1, 0),
> (x))
> > @@ -65,6 +68,7 @@ enum dw_mipi_csi2rx_regs_index {
> > DW_MIPI_CSI2RX_PHY_TST_CTRL0,
> > DW_MIPI_CSI2RX_PHY_TST_CTRL1,
> > DW_MIPI_CSI2RX_PHY_SHUTDOWNZ,
> > + DW_MIPI_CSI2RX_PHY_STOPSTATE,
> > DW_MIPI_CSI2RX_IPI_DATATYPE,
> > DW_MIPI_CSI2RX_IPI_MEM_FLUSH,
> > DW_MIPI_CSI2RX_IPI_MODE,
> > @@ -87,6 +91,7 @@ struct dw_mipi_csi2rx_drvdata {
> > void (*dphy_assert_reset)(struct dw_mipi_csi2rx_device *csi2);
> > void (*dphy_deassert_reset)(struct dw_mipi_csi2rx_device *csi2);
> > void (*ipi_enable)(struct dw_mipi_csi2rx_device *csi2);
> > + int (*wait_for_phy_stopstate)(struct dw_mipi_csi2rx_device *csi2);
> > };
> >
> > struct dw_mipi_csi2rx_format {
> > @@ -139,6 +144,7 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX]
> = {
> > [DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
> > [DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
> > [DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
> > + [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
> > [DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
> > [DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
> > [DW_MIPI_CSI2RX_IPI_MODE] = DW_REG(0x80), @@ -556,10 +562,19
> @@
> > static int dw_mipi_csi2rx_enable_streams(struct v4l2_subdev *sd,
> > if (ret)
> > goto err_csi_stop;
> >
> > + if (!csi2->enabled_streams &&
> > + csi2->drvdata->wait_for_phy_stopstate) {
> > + ret = csi2->drvdata->wait_for_phy_stopstate(csi2);
> > + if (ret)
> > + goto err_disable_streams;
> > + }
> > +
> > csi2->enabled_streams |= streams_mask;
> >
> > return 0;
> >
> > +err_disable_streams:
> > + v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
> > err_csi_stop:
> > /* Stop CSI hardware if no streams are enabled */
> > if (!csi2->enabled_streams)
> > @@ -871,11 +886,32 @@ static void imx93_csi2rx_dphy_ipi_enable(struct
> dw_mipi_csi2rx_device *csi2)
> > dw_mipi_csi2rx_write(csi2, DW_MIPI_CSI2RX_IPI_MODE, val); }
> >
> > +static int imx93_csi2rx_wait_for_phy_stopstate(struct
> > +dw_mipi_csi2rx_device *csi2) {
> > + struct device *dev = csi2->dev;
> > + u32 stopstate_mask;
> > + u32 val;
> > + int ret;
> > +
> > + stopstate_mask = DPHY_STOPSTATE_CLK_LANE | GENMASK(csi2-
> >lanes_num -
> > +1, 0);
> > +
> > + ret = read_poll_timeout(dw_mipi_csi2rx_read, val,
> > + (val & stopstate_mask) == stopstate_mask,
> > + 10, 1000, true,
> > + csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE);
> > + if (ret)
> > + dev_err(dev, "lanes are not in stop state: %#x,
> expected %#x\n",
> > + val, stopstate_mask);
>
> Did you actually test this on imx93? I'm trying to get my imx327 sensor to run,
> but only run into this error message:
> dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected
> 0x10003
Thanks for testing. Regarding the lane stop state error on i.MX93 with imx327:
This error indicates the CSI-2 lanes are not in LP-11 (stop) state when
expected. Please check:
1) Verify the sensor PHY is in LP-11 state before returning from the sensor's
s_stream(1) call. The CSI-2 receiver expects lanes to be in stop state
initially.
2) Check if the imx327 driver has a delay between starting the stream and
returning from s_stream(). If the sensor transitions PHY out of LP-11
state during this delay, the CSI driver's lane state check will fail
when it runs later. The sensor should remain in LP-11 until the CSI
controller completes its initialization.
You may need to remove any delays in the imx327 s_stream implementation, or
ensure the sensor stays in LP-11 state until the CSI receiver is ready.
If possible, could you share the imx327 driver code or check its s_stream implementation?
Best Regards
G.N Zhou
>
> Currently I'm using this DT node:
> --8<--
> mipi_csi: mipi-csi@4ae00000 {
> compatible = "fsl,imx93-mipi-csi2";
> reg = <0x4ae00000 0x10000>;
> interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clk IMX93_CLK_MIPI_CSI_GATE>,
> <&clk IMX93_CLK_CAM_PIX>;
> clock-names = "per", "pixel";
> assigned-clocks = <&clk IMX93_CLK_CAM_PIX>;
> assigned-clock-parents = <&clk IMX93_CLK_VIDEO_PLL>;
> assigned-clock-rates = <140000000>;
> power-domains = <&media_blk_ctrl IMX93_MEDIABLK_PD_MIPI_CSI>;
> phys = <&dphy_rx>;
> phy-names = "dphy-rx";
> status = "disabled";
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
>
> mipi_from_sensor: endpoint {
> data-lanes = <1 2>;
> bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
> };
> };
>
> port@1 {
> reg = <1>;
>
> mipi_to_isi: endpoint {
> remote-endpoint = <&isi_in>;
> };
> };
> };
> };
> --8<--
>
> Am I'm missing something?
>
> best regards,
> Alexander
>
> > +
> > + return ret;
> > +}
> > +
> > static const struct dw_mipi_csi2rx_drvdata imx93_drvdata = {
> > .regs = imx93_regs,
> > .dphy_assert_reset = imx93_csi2rx_dphy_assert_reset,
> > .dphy_deassert_reset = imx93_csi2rx_dphy_deassert_reset,
> > .ipi_enable = imx93_csi2rx_dphy_ipi_enable,
> > + .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
> > };
> >
> > static const struct of_device_id dw_mipi_csi2rx_of_match[] = {
> >
> >
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
^ 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