* Re: [GIT PULL] Allwinner DT Changes for 7.2
From: Krzysztof Kozlowski @ 2026-06-09 11:43 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: soc, Jernej Skrabec, Samuel Holland, linux-sunxi,
linux-arm-kernel, Stephen Boyd
In-Reply-To: <ah3ZAPLzh8ORGmpH@home.wens.tw>
On Tue, Jun 02, 2026 at 03:09:52AM +0800, Chen-Yu Tsai wrote:
> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>
> Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-for-7.2
>
> for you to fetch changes up to 44cf19e41c769720750dbb8752aca75c247e565f:
>
> arm64: dts: allwinner: a523: add gpadc node (2026-05-25 05:02:58 +0800)
>
>
> As mentioned in the tag, this pull request contains a change that should
> be shared between the soc and clk trees. However since I don't have any
> clk changes to send this cycle, I think it can just go through the soc
> tree without any issues.
But the clock driver change cannot be in the DTS branch. This should go
via clock tree even if it is one change. And definitely not via DTS
branch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] remoteproc: abort subdev stop sequence on first failure
From: Stephan Gerhold @ 2026-06-09 11:43 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno, linux-arm-msm, linux-remoteproc,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260609102254.2671238-3-mukesh.ojha@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 03:52:52PM +0530, Mukesh Ojha wrote:
> If a subdevice fails to stop, it indicates broken communication with the
> DSP. Continuing to stop further subdevices against an unresponsive
> remote processor could close rpmsg devices that could remove the memory
> mapping from HLOS and in case if remote processor touches those memory
> can result in SMMU fault.
>
> Change rproc_stop_subdevices() to return int and abort on the first
> failing subdev. Propagate the error through rproc_stop() and
> __rproc_detach() so callers are aware the teardown did not complete
> cleanly.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
But what would callers do about this? If you abort the teardown sequence
half-way through you now have an inconsistent half-stopped state that
neither a new call to stop() nor a new call to start() could recover
from. That doesn't sound much better than the SMMU fault. Or am I
missing something here?
I would expect that we should either be able to tolerate the SMMU faults
with the resets involved in the remoteproc stop/start sequence, or that
DMA gets cancelled by the remoteproc stop sequence, before the buffers
are unmapped. Perhaps the order of our stop sequence is just wrong? Can
we unmap the buffers in the subdev unprepare() callback?
Thanks,
Stephan
^ permalink raw reply
* Re: [GIT PULL] Allwinner Driver Changes for 7.2
From: Krzysztof Kozlowski @ 2026-06-09 11:38 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: soc, Jernej Skrabec, Samuel Holland, linux-sunxi,
linux-arm-kernel
In-Reply-To: <ah3YkTZAR2GXlC3x@home.wens.tw>
On Tue, Jun 02, 2026 at 03:08:01AM +0800, Chen-Yu Tsai wrote:
> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>
> Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-drivers-for-7.2
>
> for you to fetch changes up to 61192938a5870ac36edae81e4775b680dcf02c61:
>
> bus: sunxi-rsb: Always check register address validity (2026-05-25 06:37:11 +0800)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH 0/3] gpio: rockchip: Fix generic IRQ chip leak and modernize resource mapping
From: Bartosz Golaszewski @ 2026-06-09 11:24 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Marco Scardovi
Cc: Bartosz Golaszewski, Heiko Stuebner, Jianqun Xu, linux-gpio,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260607230504.35392-1-scardracs@disroot.org>
On Mon, 08 Jun 2026 01:05:01 +0200, Marco Scardovi wrote:
> This series fixes a generic IRQ chip leak in the gpio-rockchip driver
> and performs two small cleanups to use standard platform device helper APIs.
>
> Patch 1 fixes a leak caused by generic IRQ chips not being removed before
> IRQ domain teardown.
>
> Patch 2 converts register mapping to use devm_platform_ioremap_resource().
>
> [...]
Applied, thanks!
[1/3] gpio: rockchip: fix generic IRQ chip leak on remove
https://git.kernel.org/brgl/c/1c1e0fc88d6ef65bf15d517853251f75ab9d18c3
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH RESEND v4 3/8] can: flexcan: split rx/tx masks per mailbox IRQ line
From: Ciprian Marian Costea @ 2026-06-09 11:20 UTC (permalink / raw)
To: Vincent Mailhol, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet
In-Reply-To: <c50194dd-3a3c-4193-9296-1e35c6732351@kernel.org>
On 6/9/2026 12:24 PM, Vincent Mailhol wrote:
> On 03/06/2026 at 09:13, Ciprian Costea wrote:
>> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>>
>> On S32G2, which has two mailbox IRQ lines (mb-0 for MBs 0-7, mb-1
>> for MBs 8-127), both handlers currently process the full rx_mask/tx_mask
>> range,
>>
>> Introduce struct flexcan_mb_irq to hold per-IRQ-line rx and tx masks.
>>
>> In flexcan_irq_mb(), the irq argument selects the correct mask set: the
>> primary MB IRQ uses mb_irq[0] and the secondary uses mb_irq[1].
>>
>> For single-IRQ platforms, mb_irq[0] holds the full combined masks with no
>> functional change.
>>
>> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>> ---
>> drivers/net/can/flexcan/flexcan-core.c | 61 +++++++++++++++++++-------
>> drivers/net/can/flexcan/flexcan.h | 10 ++++-
>> 2 files changed, 52 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
>> index 7dde2e623def..32e4d4da00a1 100644
>> --- a/drivers/net/can/flexcan/flexcan-core.c
>> +++ b/drivers/net/can/flexcan/flexcan-core.c
>> @@ -957,14 +957,16 @@ static inline void flexcan_write64(struct flexcan_priv *priv, u64 val, void __io
>> priv->write(lower_32_bits(val), addr);
>> }
>>
>> -static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv)
>> +static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv,
>> + u64 rx_mask)
>> {
>> - return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->rx_mask);
>> + return flexcan_read64_mask(priv, &priv->regs->iflag1, rx_mask);
>> }
>>
>> -static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv)
>> +static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv,
>> + u64 tx_mask)
>> {
>> - return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->tx_mask);
>> + return flexcan_read64_mask(priv, &priv->regs->iflag1, tx_mask);
>> }
>>
>> static inline struct flexcan_priv *rx_offload_to_priv(struct can_rx_offload *offload)
>> @@ -1071,7 +1073,8 @@ static struct sk_buff *flexcan_mailbox_read(struct can_rx_offload *offload,
>> }
>>
>> /* Process mailbox (RX + TX) events */
>> -static irqreturn_t flexcan_do_mb(struct net_device *dev)
>> +static irqreturn_t flexcan_do_mb(struct net_device *dev,
>> + const struct flexcan_mb_irq *mb_irq)
>> {
>> struct net_device_stats *stats = &dev->stats;
>> struct flexcan_priv *priv = netdev_priv(dev);
>> @@ -1084,7 +1087,8 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
>> u64 reg_iflag_rx;
>> int ret;
>>
>> - while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv))) {
>> + while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv,
>> + mb_irq->rx_mask))) {
>> handled = IRQ_HANDLED;
>> ret = can_rx_offload_irq_offload_timestamp(&priv->offload,
>> reg_iflag_rx);
>> @@ -1110,10 +1114,10 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
>> }
>> }
>>
>> - reg_iflag_tx = flexcan_read_reg_iflag_tx(priv);
>> + reg_iflag_tx = flexcan_read_reg_iflag_tx(priv, mb_irq->tx_mask);
>>
>> /* transmission complete interrupt */
>> - if (reg_iflag_tx & priv->tx_mask) {
>> + if (reg_iflag_tx & mb_irq->tx_mask) {
>> u32 reg_ctrl = priv->read(&priv->tx_mb->can_ctrl);
>>
>> handled = IRQ_HANDLED;
>> @@ -1125,7 +1129,7 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
>> /* after sending a RTR frame MB is in RX mode */
>> priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
>> &priv->tx_mb->can_ctrl);
>> - flexcan_write64(priv, priv->tx_mask, ®s->iflag1);
>> + flexcan_write64(priv, mb_irq->tx_mask, ®s->iflag1);
>> netif_wake_queue(dev);
>> }
>>
>> @@ -1228,7 +1232,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
>> struct flexcan_priv *priv = netdev_priv(dev);
>> irqreturn_t handled;
>>
>> - handled = flexcan_do_mb(dev);
>> + handled = flexcan_do_mb(dev, &priv->mb_irq[0]);
>> handled |= flexcan_do_state(dev);
>> handled |= flexcan_do_berr(dev);
>>
>> @@ -1243,9 +1247,15 @@ static irqreturn_t flexcan_irq_mb(int irq, void *dev_id)
>> {
>> struct net_device *dev = dev_id;
>> struct flexcan_priv *priv = netdev_priv(dev);
>> + const struct flexcan_mb_irq *mb_irq;
>> irqreturn_t handled;
>> + int idx;
>>
>> - handled = flexcan_do_mb(dev);
>> + idx = (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ &&
>> + irq == priv->irq_secondary_mb) ? 1 : 0;
>> + mb_irq = &priv->mb_irq[idx];
>> +
>> + handled = flexcan_do_mb(dev, mb_irq);
>>
>> if (handled)
>> can_rx_offload_irq_finish(&priv->offload);
>> @@ -1473,6 +1483,7 @@ static void flexcan_ram_init(struct net_device *dev)
>> static int flexcan_rx_offload_setup(struct net_device *dev)
>> {
>> struct flexcan_priv *priv = netdev_priv(dev);
>> + u64 rx_mask, tx_mask;
>> int err;
>>
>> if (priv->can.ctrlmode & CAN_CTRLMODE_FD)
>> @@ -1494,20 +1505,35 @@ static int flexcan_rx_offload_setup(struct net_device *dev)
>> flexcan_get_mb(priv, FLEXCAN_TX_MB_RESERVED_RX_FIFO);
>> priv->tx_mb_idx = priv->mb_count - 1;
>> priv->tx_mb = flexcan_get_mb(priv, priv->tx_mb_idx);
>> - priv->tx_mask = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
>> -
>> priv->offload.mailbox_read = flexcan_mailbox_read;
>>
>> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_USE_RX_MAILBOX) {
>> priv->offload.mb_first = FLEXCAN_RX_MB_RX_MAILBOX_FIRST;
>> priv->offload.mb_last = priv->mb_count - 2;
>>
>> - priv->rx_mask = GENMASK_ULL(priv->offload.mb_last,
>> - priv->offload.mb_first);
>> + rx_mask = GENMASK_ULL(priv->offload.mb_last,
>> + priv->offload.mb_first);
>> + tx_mask = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
>> +
>> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
>> + /* S32G2 has two MB IRQ lines with the split at MB 8:
>> + * mb-0 IRQ handles MBs 0-7,
>> + * mb-1 IRQ handles MBs 8-127.
> ^^^
> Your comment says 8-127 but the code uses GENMASK_ULL(63, 8). Is this
> intentional?
Hello Vincent,
Thank you for taking time in reviewing this series.
This is not intentional. The driver currently supports up to 64 MBs
(bounded by the iflag1 + iflag2 register layout and the u64 mask).
I will update the comment accordingly in V5.
>
>> + */
>> + priv->mb_irq[0].rx_mask = rx_mask & GENMASK_ULL(7, 0);
>> + priv->mb_irq[0].tx_mask = tx_mask & GENMASK_ULL(7, 0);
>> + priv->mb_irq[1].rx_mask = rx_mask & GENMASK_ULL(63, 8);
>> + priv->mb_irq[1].tx_mask = tx_mask & GENMASK_ULL(63, 8);
>> + } else {
>> + priv->mb_irq[0].rx_mask = rx_mask;
>> + priv->mb_irq[0].tx_mask = tx_mask;
>> + }
>> +
>
> The introduction of the struct flexcan_mb_irq seems a bit overkill.
> Can't you just define two new masks and keep the existing struct
> flexcan_stop_mode untouched:
>
> #define FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK GENMASK_U64(7, 0)
> #define FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK GENMASK_U64(63, 8)
>
> and when you need to access the MB, just select the correct mask. For
> example, flexcan_irq_mb() becomes something like this:
>
> u64 mb_mask;
>
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ
> && irq == priv->irq_secondary_mb)
> mb_mask = FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK;
> else
> mb_mask = FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK;
>
> handled = flexcan_do_mb(dev, mb_mask);
>
Sounds like a good simplification indeed. I will update it in V5.
Regards,
Ciprian
>> err = can_rx_offload_add_timestamp(dev, &priv->offload);
>> } else {
>> - priv->rx_mask = FLEXCAN_IFLAG_RX_FIFO_OVERFLOW |
>> + priv->mb_irq[0].rx_mask = FLEXCAN_IFLAG_RX_FIFO_OVERFLOW |
>> FLEXCAN_IFLAG_RX_FIFO_AVAILABLE;
>> + priv->mb_irq[0].tx_mask = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
>> err = can_rx_offload_add_fifo(dev, &priv->offload,
>> FLEXCAN_NAPI_WEIGHT);
>> }
>> @@ -1531,7 +1557,8 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
>> disable_irq(priv->irq_secondary_mb);
>>
>> priv->write(priv->reg_ctrl_default, ®s->ctrl);
>> - reg_imask = priv->rx_mask | priv->tx_mask;
>> + reg_imask = priv->mb_irq[0].rx_mask | priv->mb_irq[0].tx_mask |
>> + priv->mb_irq[1].rx_mask | priv->mb_irq[1].tx_mask;
>> priv->write(upper_32_bits(reg_imask), ®s->imask2);
>> priv->write(lower_32_bits(reg_imask), ®s->imask1);
>> enable_irq(dev->irq);
>> diff --git a/drivers/net/can/flexcan/flexcan.h b/drivers/net/can/flexcan/flexcan.h
>> index 16692a2502eb..22aa097ec3c0 100644
>> --- a/drivers/net/can/flexcan/flexcan.h
>> +++ b/drivers/net/can/flexcan/flexcan.h
>> @@ -75,10 +75,17 @@
>> */
>> #define FLEXCAN_QUIRK_SECONDARY_MB_IRQ BIT(18)
>>
>> +#define FLEXCAN_NR_MB_IRQS 2
>> +
>> struct flexcan_devtype_data {
>> u32 quirks; /* quirks needed for different IP cores */
>> };
>>
>> +struct flexcan_mb_irq {
>> + u64 rx_mask;
>> + u64 tx_mask;
>> +};
>> +
>> struct flexcan_stop_mode {
>> struct regmap *gpr;
>> u8 req_gpr;
>> @@ -99,8 +106,7 @@ struct flexcan_priv {
>> u8 clk_src; /* clock source of CAN Protocol Engine */
>> u8 scu_idx;
>>
>> - u64 rx_mask;
>> - u64 tx_mask;
>> + struct flexcan_mb_irq mb_irq[FLEXCAN_NR_MB_IRQS];
>> u32 reg_ctrl_default;
>>
>> struct clk *clk_ipg;
>
>
> Yours sincerely,
> Vincent Mailhol
>
^ permalink raw reply
* Re: [PATCH] gpio: zynq: fix runtime PM leak on remove
From: Bartosz Golaszewski @ 2026-06-09 11:19 UTC (permalink / raw)
To: Shubhrajyoti Datta, Srinivas Neeli, Michal Simek, Linus Walleij,
Bartosz Golaszewski, Ruoyu Wang
Cc: Bartosz Golaszewski, Harini Katakam, Soren Brinkmann, linux-gpio,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260609073313.5-1-ruoyuw560@gmail.com>
On Tue, 09 Jun 2026 15:33:13 +0800, Ruoyu Wang wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even when it
> returns an error. zynq_gpio_remove() uses it to keep the controller active
> while removing the GPIO chip, but never drops the usage counter again.
>
> Balance the get with pm_runtime_put_noidle() after disabling runtime PM.
>
>
> [...]
Applied, thanks!
[1/1] gpio: zynq: fix runtime PM leak on remove
https://git.kernel.org/brgl/c/6edb934de9bda3b7abcec856eaee6fc8b4278dd1
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [GIT PULL 2/2] Renesas DTS updates for v7.2 (take two)
From: Krzysztof Kozlowski @ 2026-06-09 10:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: soc, soc, Magnus Damm, linux-arm-kernel, linux-renesas-soc
In-Reply-To: <cover.1780319122.git.geert+renesas@glider.be>
On Mon, Jun 01, 2026 at 03:18:19PM +0200, Geert Uytterhoeven wrote:
> The following changes since commit 44f1ef06ceec55b7704c7d773d6136ca8b90f8b7:
>
> ARM: dts: renesas: r8a73a4: Describe coresight on R-Mobile APE6 (2026-05-15 11:35:25 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dts-for-v7.2-tag2
>
> for you to fetch changes up to 0d4ed954061efc3e47fa889d3de0675f933f438f:
>
> arm64: dts: renesas: r9a08g046l48-smarc: Enable audio (2026-05-31 10:52:23 +0200)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 1/2] Renesas driver updates for v7.2 (take two)
From: Krzysztof Kozlowski @ 2026-06-09 10:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: soc, soc, Magnus Damm, linux-arm-kernel, linux-renesas-soc
In-Reply-To: <cover.1780319120.git.geert+renesas@glider.be>
On Mon, Jun 01, 2026 at 03:18:18PM +0200, Geert Uytterhoeven wrote:
> The following changes since commit 17e48e7e5f18b45fd4a9411090148aae3b74f7f3:
>
> soc: renesas: Convert to of_machine_get_match() (2026-05-11 09:56:17 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-drivers-for-v7.2-tag2
>
> for you to fetch changes up to b4d41ffa750fc3403a4076d17090589d000f13ff:
>
> soc: renesas: rcar-mfis: Add R-Car V4H/V4M support (2026-05-29 14:42:29 +0200)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT,PULL,1/3] MediaTek ARM64 Device Tree updates for v7.2
From: Krzysztof Kozlowski @ 2026-06-09 10:47 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: arm-soc, soc, linux-arm-kernel, linux-mediatek, matthias.bgg
In-Reply-To: <20260601091225.5223-1-angelogioacchino.delregno@collabora.com>
On Mon, Jun 01, 2026 at 11:12:20AM +0200, AngeloGioacchino Del Regno wrote:
> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>
> Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git/ tags/mtk-dts64-for-v7.2
>
> for you to fetch changes up to 9897c586b09f79ebcf2e67a888743c046b20d254:
>
> arm64: dts: mediatek: add LED and key support on Xiaomi AX3000T (2026-05-25 10:43:10 +0200)
>
> ----------------------------------------------------------------
> MediaTek ARM64 DeviceTree updates
>
> This adds improvements for already supported SoCs and devices.
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 03/17] clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE
From: Marc Zyngier @ 2026-06-09 10:46 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber,
"Yu-Chun Lin [林祐君]", Heiko Stuebner,
Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek,
Florian Fainelli
In-Reply-To: <193cc406-0834-4dee-9b4a-02cdfd85e05c@samsung.com>
On Tue, 09 Jun 2026 11:35:24 +0100,
Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> On 09.06.2026 12:21, Marc Zyngier wrote:
> > On Tue, 09 Jun 2026 11:03:21 +0100,
> > Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> >> On 23.05.2026 16:02, Marc Zyngier wrote:
> >>> When running with at EL2 with VHE enabled, the architecture provides
> >>> two EL2 timer/counters, dubbed physical and virtual. Apart from their
> >>> names, they are strictly identical.
> >>>
> >>> However, they don't get virtualised the same way, specially when
> >>> it comes to adding arbitrary offsets to the timers. When running as
> >>> a guest, the host CNTVOFF_EL2 does apply to the guest's view of
> >>> CNTHV*_El2. This is not true for CNTPOFF_EL2 and CNTHP*_EL2, as
> >>> the architecture is broken past the first level of virtualisation
> >>> (it lacks some essential mechanisms to be usable, despite what
> >>> the ARM ARM pretends).
> >>>
> >>> This means that when running as a L2 guest hypervisor, using the
> >>> physical timer results in traps to L0, which are then forwarded to
> >>> L1 in order to emulate the offset, leading to even worse performance
> >>> due to massive trap amplification (the combination of register and
> >>> ERET trapping is absolutely lethal).
> >>>
> >>> Switch the arch timer code to using the virtual timer when running
> >>> in VHE by default, only using the physical timer if the interrupt
> >>> is not correctly described in the firmware tables (which seems
> >>> to be an unfortunately common case). This comes as no impact on
> >>> bare-metal, and slightly improves the situation in the virtualised
> >>> case.
> >>>
> >>> Signed-off-by: Marc Zyngier <maz@kernel.org>
> >> This patch landed recently in linux-next as commit d87773de9efe
> >> ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when
> >> running VHE"). In my tests I found that it breaks booting of RaspberryPi5
> >> board. Reverting it on top of linux-next fixes the issue. Here is a boot
> >> log:
> > Huh.
> >
> > [...]
> >
> >> arch_timer: cp15 timer running at 54.00MHz (hyp-virt).
> >> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
> >> sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
> > The interrupt appears to be advertised in the DT, but doesn't seem to
> > fire. That's obviously not going to end well. My suspicion is that
> > either the interrupt isn't wired (that'd be hilariously abd), or is
> > left as Group-0 by the firmware (copy-paste from RPi4).
> >
> > Can you try the following hack and let me know if the kernel shouts at
> > you?
> >
> > Thanks,
> >
> > M.
> >
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index ec70c84e9f91d..d05791e6cc0db 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -213,6 +213,7 @@ static void gic_eoimode1_mask_irq(struct irq_data *d)
> > static void gic_unmask_irq(struct irq_data *d)
> > {
> > gic_poke_irq(d, GIC_DIST_ENABLE_SET);
> > + WARN_ON(!gic_peek_irq(d, GIC_DIST_ENABLE_SET));
> > }
> >
> > static void gic_eoi_irq(struct irq_data *d)
>
> I've applied this change, but it doesn't trigger any warning in the boot log.
[+ Florian]
Huh. So that really points at the timer not being wired into the GIC,
Samsung style... Can you confirm that removing the EL2 virtual timer
from the DT results in a booting machine?
Florian, can you please check whether PPI12 is actually the EL2
virtual timer on the RPI5 SoC?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [GIT,PULL,2/3] MediaTek ARM32 Device Tree updates for v7.2
From: Krzysztof Kozlowski @ 2026-06-09 10:44 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: arm-soc, soc, linux-arm-kernel, linux-mediatek, matthias.bgg
In-Reply-To: <20260601091225.5223-2-angelogioacchino.delregno@collabora.com>
On Mon, Jun 01, 2026 at 11:12:21AM +0200, AngeloGioacchino Del Regno wrote:
> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>
> Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git/ tags/mtk-dts32-for-v7.2
>
> for you to fetch changes up to ba6afff1d9b70028a5fc3df2d3acbee501c20a53:
>
> arm: dts: mediatek: mt8135: fix pinctrl node name (2026-05-11 11:39:02 +0200)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT,PULL,2/3] MediaTek SoC driver updates for v7.2
From: Krzysztof Kozlowski @ 2026-06-09 10:42 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: arm-soc, soc, linux-arm-kernel, linux-mediatek, matthias.bgg,
matthias.bgg
In-Reply-To: <20260601091225.5223-3-angelogioacchino.delregno@collabora.com>
On Mon, Jun 01, 2026 at 11:12:22AM +0200, AngeloGioacchino Del Regno wrote:
> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>
> Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git/ tags/mtk-soc-for-v7.2
>
> for you to fetch changes up to 7d462de9f65b002b439b1b168bf3b5579b0de48b:
>
> soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge (2026-05-11 11:20:48 +0200)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] ufs: mediatek: Implement get_hba_nortt callback for RTT capability
From: ed.tsai @ 2026-06-09 10:38 UTC (permalink / raw)
To: alim.akhtar, avri.altman, bvanassche, James.Bottomley,
martin.petersen, linux-scsi
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
peter.wang, alice.chao, naomi.chu, chun-hung.wu, Ed Tsai
In-Reply-To: <20260609103856.676222-1-ed.tsai@mediatek.com>
From: Ed Tsai <ed.tsai@mediatek.com>
Implement the get_hba_nortt callback to handle platform-specific RTT
capability differences:
- For legacy platforms and IP versions before MT6995 B0, the RTT
capability from host controller register is problematic, so limit
it to 2 (MTK_MAX_NUM_RTT_LEGACY).
- For MT6995 B0 and later platforms, the issue is fixed and the
value from host controller capability register can be used directly.
This replaces the previous max_num_rtt field in ufs_hba_variant_ops
with dynamic platform-specific logic.
Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
---
drivers/ufs/host/ufs-mediatek.c | 12 +++++++++++-
drivers/ufs/host/ufs-mediatek.h | 4 ++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index 3991a51263a6..58701ca95edd 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -2183,6 +2183,16 @@ static int ufs_mtk_clk_scale_notify(struct ufs_hba *hba, bool scale_up,
return 0;
}
+static int ufs_mtk_get_hba_nortt(struct ufs_hba *hba)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ if (host->legacy_ip_ver || host->ip_ver < IP_VER_MT6995_B0)
+ return MTK_MAX_NUM_RTT_LEGACY;
+
+ return FIELD_GET(MASK_NUMBER_OUTSTANDING_RTT, hba->capabilities) + 1;
+}
+
static int ufs_mtk_get_hba_mac(struct ufs_hba *hba)
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
@@ -2322,7 +2332,6 @@ static void ufs_mtk_config_scsi_dev(struct scsi_device *sdev)
*/
static const struct ufs_hba_variant_ops ufs_hba_mtk_vops = {
.name = "mediatek.ufshci",
- .max_num_rtt = MTK_MAX_NUM_RTT,
.init = ufs_mtk_init,
.get_ufs_hci_version = ufs_mtk_get_ufs_hci_version,
.setup_clocks = ufs_mtk_setup_clocks,
@@ -2339,6 +2348,7 @@ static const struct ufs_hba_variant_ops ufs_hba_mtk_vops = {
.event_notify = ufs_mtk_event_notify,
.config_scaling_param = ufs_mtk_config_scaling_param,
.clk_scale_notify = ufs_mtk_clk_scale_notify,
+ .get_hba_nortt = ufs_mtk_get_hba_nortt,
/* mcq vops */
.get_hba_mac = ufs_mtk_get_hba_mac,
.op_runtime_config = ufs_mtk_op_runtime_config,
diff --git a/drivers/ufs/host/ufs-mediatek.h b/drivers/ufs/host/ufs-mediatek.h
index 8547a6f04990..73cdc726f290 100644
--- a/drivers/ufs/host/ufs-mediatek.h
+++ b/drivers/ufs/host/ufs-mediatek.h
@@ -203,8 +203,8 @@ struct ufs_mtk_host {
/* MTK delay of autosuspend: 500 ms */
#define MTK_RPM_AUTOSUSPEND_DELAY_MS 500
-/* MTK RTT support number */
-#define MTK_MAX_NUM_RTT 2
+/* MTK RTT support number for platforms before MT6995 B0 */
+#define MTK_MAX_NUM_RTT_LEGACY 2
/* UFSHCI MTK ip version value */
enum {
--
2.45.2
^ permalink raw reply related
* [PATCH 0/2] ufs: Add callback for vendor-specific RTT capability
From: ed.tsai @ 2026-06-09 10:38 UTC (permalink / raw)
To: alim.akhtar, avri.altman, bvanassche, James.Bottomley,
martin.petersen, linux-scsi
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
peter.wang, alice.chao, naomi.chu, chun-hung.wu, Ed Tsai
From: Ed Tsai <ed.tsai@mediatek.com>
The first patch adds the get_hba_nortt() callback to the UFS core layer
and removes the static max_num_rtt field from ufs_hba_variant_ops. This
allows platform vendors to provide dynamic, platform-specific RTT capability
handling.
The second patch implements this callback in the MediaTek UFS driver,
distinguishing between legacy and newer platforms.
Ed Tsai (2):
ufs: core: Add get_hba_nortt callback for vendor-specific RTT
capability
ufs: mediatek: Implement get_hba_nortt callback for RTT capability
drivers/ufs/core/ufshcd.c | 9 +++++----
drivers/ufs/host/ufs-mediatek.c | 12 +++++++++++-
drivers/ufs/host/ufs-mediatek.h | 4 ++--
include/ufs/ufshcd.h | 5 +++--
4 files changed, 21 insertions(+), 9 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH 1/2] ufs: core: Add get_hba_nortt callback for vendor-specific RTT capability
From: ed.tsai @ 2026-06-09 10:38 UTC (permalink / raw)
To: alim.akhtar, avri.altman, bvanassche, James.Bottomley,
martin.petersen, linux-scsi
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
peter.wang, alice.chao, naomi.chu, chun-hung.wu, Ed Tsai
In-Reply-To: <20260609103856.676222-1-ed.tsai@mediatek.com>
From: Ed Tsai <ed.tsai@mediatek.com>
The number of outstanding RTTs read from host controller capability
register is problematic on some platforms. Add a new vendor callback
get_hba_nortt() to allow platform vendors to override the default RTT
capability value with platform-specific handling.
For platforms without the callback, continue to use the value from the
host controller capability register.
Also remove the max_num_rtt field from ufs_hba_variant_ops as it is
replaced by the new get_hba_nortt callback.
Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
---
drivers/ufs/core/ufshcd.c | 9 +++++----
include/ufs/ufshcd.h | 5 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index c3f08957d179..00072bff9dcd 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -2529,7 +2529,10 @@ static inline int ufshcd_hba_capabilities(struct ufs_hba *hba)
hba->nutmrs =
((hba->capabilities & MASK_TASK_MANAGEMENT_REQUEST_SLOTS) >> 16) + 1;
- hba->nortt = FIELD_GET(MASK_NUMBER_OUTSTANDING_RTT, hba->capabilities) + 1;
+ if (hba->vops && hba->vops->get_hba_nortt)
+ hba->nortt = hba->vops->get_hba_nortt(hba);
+ else
+ hba->nortt = FIELD_GET(MASK_NUMBER_OUTSTANDING_RTT, hba->capabilities) + 1;
/* Read crypto capabilities */
err = ufshcd_hba_init_crypto_capabilities(hba);
@@ -8554,8 +8557,6 @@ static void ufshcd_set_rtt(struct ufs_hba *hba)
struct ufs_dev_info *dev_info = &hba->dev_info;
u32 rtt = 0;
u32 dev_rtt = 0;
- int host_rtt_cap = hba->vops && hba->vops->max_num_rtt ?
- hba->vops->max_num_rtt : hba->nortt;
/* RTT override makes sense only for UFS-4.0 and above */
if (dev_info->wspecversion < 0x400)
@@ -8571,7 +8572,7 @@ static void ufshcd_set_rtt(struct ufs_hba *hba)
if (dev_rtt != DEFAULT_MAX_NUM_RTT)
return;
- rtt = min_t(int, dev_info->rtt_cap, host_rtt_cap);
+ rtt = min_t(int, dev_info->rtt_cap, hba->nortt);
if (rtt == dev_rtt)
return;
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index cfbc75d8df83..13d0d7798294 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -370,7 +370,6 @@ struct ufshcd_tx_eq_params {
/**
* struct ufs_hba_variant_ops - variant specific callbacks
* @name: variant name
- * @max_num_rtt: maximum RTT supported by the host
* @init: called when the driver is initialized
* @exit: called to cleanup everything done in init
* @set_dma_mask: For setting another DMA mask than indicated by the 64AS
@@ -415,10 +414,11 @@ struct ufshcd_tx_eq_params {
* @get_rx_fom: called to get Figure of Merit (FOM) value.
* @tx_eqtr_notify: called before and after TX Equalization Training procedure
* to allow platform vendor specific configs to take place.
+ * @get_hba_nortt: called to get maximum number of outstanding RTTs supported by
+ * the controller.
*/
struct ufs_hba_variant_ops {
const char *name;
- int max_num_rtt;
int (*init)(struct ufs_hba *);
void (*exit)(struct ufs_hba *);
u32 (*get_ufs_hci_version)(struct ufs_hba *);
@@ -477,6 +477,7 @@ struct ufs_hba_variant_ops {
int (*tx_eqtr_notify)(struct ufs_hba *hba,
enum ufs_notify_change_status status,
struct ufs_pa_layer_attr *pwr_mode);
+ int (*get_hba_nortt)(struct ufs_hba *hba);
};
/* clock gating state */
--
2.45.2
^ permalink raw reply related
* Re: [PATCH v3 03/17] clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE
From: Marek Szyprowski @ 2026-06-09 10:35 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <86ik7st3nh.wl-maz@kernel.org>
On 09.06.2026 12:21, Marc Zyngier wrote:
> On Tue, 09 Jun 2026 11:03:21 +0100,
> Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>> On 23.05.2026 16:02, Marc Zyngier wrote:
>>> When running with at EL2 with VHE enabled, the architecture provides
>>> two EL2 timer/counters, dubbed physical and virtual. Apart from their
>>> names, they are strictly identical.
>>>
>>> However, they don't get virtualised the same way, specially when
>>> it comes to adding arbitrary offsets to the timers. When running as
>>> a guest, the host CNTVOFF_EL2 does apply to the guest's view of
>>> CNTHV*_El2. This is not true for CNTPOFF_EL2 and CNTHP*_EL2, as
>>> the architecture is broken past the first level of virtualisation
>>> (it lacks some essential mechanisms to be usable, despite what
>>> the ARM ARM pretends).
>>>
>>> This means that when running as a L2 guest hypervisor, using the
>>> physical timer results in traps to L0, which are then forwarded to
>>> L1 in order to emulate the offset, leading to even worse performance
>>> due to massive trap amplification (the combination of register and
>>> ERET trapping is absolutely lethal).
>>>
>>> Switch the arch timer code to using the virtual timer when running
>>> in VHE by default, only using the physical timer if the interrupt
>>> is not correctly described in the firmware tables (which seems
>>> to be an unfortunately common case). This comes as no impact on
>>> bare-metal, and slightly improves the situation in the virtualised
>>> case.
>>>
>>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> This patch landed recently in linux-next as commit d87773de9efe
>> ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when
>> running VHE"). In my tests I found that it breaks booting of RaspberryPi5
>> board. Reverting it on top of linux-next fixes the issue. Here is a boot
>> log:
> Huh.
>
> [...]
>
>> arch_timer: cp15 timer running at 54.00MHz (hyp-virt).
>> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
>> sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
> The interrupt appears to be advertised in the DT, but doesn't seem to
> fire. That's obviously not going to end well. My suspicion is that
> either the interrupt isn't wired (that'd be hilariously abd), or is
> left as Group-0 by the firmware (copy-paste from RPi4).
>
> Can you try the following hack and let me know if the kernel shouts at
> you?
>
> Thanks,
>
> M.
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index ec70c84e9f91d..d05791e6cc0db 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -213,6 +213,7 @@ static void gic_eoimode1_mask_irq(struct irq_data *d)
> static void gic_unmask_irq(struct irq_data *d)
> {
> gic_poke_irq(d, GIC_DIST_ENABLE_SET);
> + WARN_ON(!gic_peek_irq(d, GIC_DIST_ENABLE_SET));
> }
>
> static void gic_eoi_irq(struct irq_data *d)
I've applied this change, but it doesn't trigger any warning in the boot log.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v8 11/12] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Pranjal Shrivastava @ 2026-06-09 10:34 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rAWZ4Ac23D8eyAHfmaVVkHv8pz45+_dpMO1M4D7+RVCoA@mail.gmail.com>
On Sun, Jun 07, 2026 at 03:22:19PM -0700, Daniel Mentz wrote:
> On Wed, Jun 3, 2026 at 11:27 PM Pranjal Shrivastava <praan@google.com> wrote:
> >
> > On Wed, Jun 03, 2026 at 01:28:19PM -0700, Daniel Mentz wrote:
> > > On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan@google.com> wrote:
> > > > @@ -2361,8 +2394,33 @@ static irqreturn_t arm_smmu_handle_gerror(struct arm_smmu_device *smmu)
> > > > static irqreturn_t arm_smmu_gerror_handler(int irq, void *dev)
> > > > {
> > > > struct arm_smmu_device *smmu = dev;
> > > > + irqreturn_t ret;
> > > > +
> > > > + /*
> > > > + * Global Errors are only processed if the SMMU is active.
> > > > + *
> > > > + * If the STOP_FLAG is set (can_elide == true), the hardware is
> > > > + * either already disabled or in the process of being disabled.
> > > > + * Any errors captured during the quiesce/drain phase will be
> > > > + * handled by the explicit arm_smmu_handle_gerror() call at the
> > > > + * end of arm_smmu_runtime_suspend() callback. On resume, the
> > > > + * STOP_FLAG is cleared before interrupts are re-enabled, ensuring
> > > > + * no valid errors are missed.
> > > > + *
> > > > + * A lockless check is favoured here over a dynamic PM core check
> > > > + * since the runtime_pm_get_if_active would return false during
> > > > + * transient states like RPM_RESUMING & ignore level-triggered
> > > > + * interrupts.
> > > > + */
> > > > + if (arm_smmu_cmdq_can_elide(smmu)) {
> > > > + dev_err(smmu->dev,
> > > > + "Ignoring gerror interrupt because the SMMU is suspended\n");
> > > > + return IRQ_NONE;
> > > > + }
> > >
> > > Have you considered using arm_smmu_rpm_get() here instead?
> > > I can see two issues with the currenlty proposal:
> > > * Returning IRQ_NONE when an interrupt is indeed active and needs to
> > > be handled. This might be interpreted as a spurious interrupt
> > > * Nothing is preventing the suspend handler from running while
> > > arm_smmu_gerror_handler is in the middle of handling an interrupt
> > >
> > > I understand that using arm_smmu_rpm_get() also has downsides,
> > > including an unnecessary resume operation when the SMMU is already in
> > > RPM_SUSPENDING state. However, using arm_smmu_rpm_get() would make it
> > > easier to ensure correctness.
> > >
> >
> > I don't think using arm_smmu_rpm_get() here is possible..
> >
> > GERROR is registered as a hard IRQ handler, so calling rpm_get (which
> > can sleep) would be wrong.
>
> You're right. Sorry, I missed that arm_smmu_gerror_handler is
> registered as a hard irq handler.
>
> > Regarding the race, the STOP_FLAG is set at the very beginning of the
> > suspend sequence. If an IRQ fires after that, we return IRQ_NONE and
> > let the explicit arm_smmu_handle_gerror() call at the end of
> > runtime_suspend catch and clear it. After CMDQEN, PRIQEN, EVTQEN &
> > SMMUEN are all cleared, getting a Gerror should be treated as spurious
> >
> > That said, I understand your concerns about a real IRQ being interpreted
> > as a spurious one, and creating an IRQ storm since the gerror register
> > isn't really written. I have 2 ideas here:
> >
> > 1. We could have a "suspended" flag and check it with can_elide here:
> > arm_smmu_cmdq_can_elide() && is_suspended() to correctly return IRQ_NONE
> >
> > 2. We could explicitly disable Gerror in IRQ_CTRL write after setting
> > the CMDQ_STOP_FLAG. Even if there are Gerrors during the CMDQ drain,
> > we'll catcup to those at the end of our suspend callback.
> >
> > I'm more inclined towards 2 as it prevents potential races (execution of
> > an IRQ handler with handle_gerror calls at the end of the suspend).
> >
> > WDYT?
>
> I'm not sure if I have a good suggestion here. Have you considered the
> following: Do not call arm_smmu_handle_gerror() from
> arm_smmu_runtime_suspend(). Instead, call disable_irq() at the end of
> the suspend handler (and enable_irq() at the beginning of the resume
> handler)?
I thought about using disable_irq(), but I think doing it at the
hardware level (IRQ_CTRL) is better.
By disabling in IRQ_CTRL and keeping the manual arm_smmu_handle_gerror()
call at the end of suspend, we ensure that we don't lose any gerror info
We catch and handle any errors that occurred during the drain/quiesce
phase right before the power-down.
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v5 0/4] Enable sysfs module symlink for more built-in drivers
From: Danilo Krummrich @ 2026-06-09 10:29 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Shashank Balaji, James Clark, Alexander Shishkin,
Greg Kroah-Hartman, Rafael J . Wysocki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Jonathan Corbet, Shuah Khan,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Mike Leach, Leo Yan, Thierry Reding,
Jonathan Hunter, Rahul Bukte, linux-kernel, coresight,
linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
Daniel Palmer, Tim Bird, linux-modules, linux-tegra, Sumit Gupta
In-Reply-To: <1c8e441a-6b33-465a-88f9-9552f346ae18@arm.com>
On Tue Jun 9, 2026 at 11:08 AM CEST, Suzuki K Poulose wrote:
> On 08/06/2026 23:24, Danilo Krummrich wrote:
>> On Mon, 18 May 2026 19:19:56 +0900, Shashank Balaji wrote:
>>> [PATCH v5 0/4] Enable sysfs module symlink for more built-in drivers
>>
>> Applied, thanks!
>>
>> Branch: driver-core-testing
>> Tree: git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
>>
>> [1/4] soc/tegra: cbb: Move driver registration from pure_initcall to core_initcall
>> commit: cd6e95e7ab29
>> [2/4] kernel: param: initialize module_kset in a pure_initcall
>> commit: c82dfce47833
>> [3/4] coresight: pass THIS_MODULE implicitly through a macro
>> commit: efc22b3f89a3
>> [4/4] driver core: platform: set mod_name in driver registration
>> commit: a7a7dc5c46a0
>>
>> The patches will appear in the next linux-next integration (typically within 24
>> hours on weekdays).
>>
>> The patches are in the driver-core-testing branch and will be promoted to
>> driver-core-next after validation.
>
> Apologies, I missed your emails. I am fine with those, happy to fixup
> anything if the linux-next screams.
Thanks for confirming! I did a test merge with linux-next and an allmodconfig
arm64 build before picking it up, so it should be fine.
Thanks,
Danilo
^ permalink raw reply
* [PATCH 3/3] remoteproc: qcom_sysmon: abort stop on unacknowledged shutdown
From: Mukesh Ojha @ 2026-06-09 10:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-arm-msm, linux-remoteproc, linux-kernel, linux-arm-kernel,
linux-mediatek, Mukesh Ojha
In-Reply-To: <20260609102254.2671238-1-mukesh.ojha@oss.qualcomm.com>
When a DSP hangs, if a graceful shutdown is attempted during sysmon stop,
it times out but sysmon_stop() still returns 0. The stop subdevice loop
then continues and tears down the glink and ssr subdevices, which
unregisters and unmaps the memory regions attached to rpmsg device. If the
remote still has DMA in flight against those regions, the result is an
SMMU fault.
Fix sysmon_stop() to return -ETIMEDOUT when a shutdown mechanism was
tried but the remote did not acknowledge it. With the abort-on-first-
failure behaviour already in rproc_stop_subdevices(), this prevents
glink and ssr from running their stop callbacks against an unresponsive
remote.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/remoteproc/qcom_sysmon.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
index 44b905a7e129..a29084cf7145 100644
--- a/drivers/remoteproc/qcom_sysmon.c
+++ b/drivers/remoteproc/qcom_sysmon.c
@@ -559,6 +559,11 @@ static int sysmon_stop(struct rproc_subdev *subdev, bool crashed)
sysmon->shutdown_acked = ssctl_request_shutdown(sysmon);
else if (sysmon->ept)
sysmon->shutdown_acked = sysmon_request_shutdown(sysmon);
+ else
+ return 0;
+
+ if (!sysmon->shutdown_acked)
+ return -ETIMEDOUT;
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] remoteproc: abort subdev stop sequence on first failure
From: Mukesh Ojha @ 2026-06-09 10:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-arm-msm, linux-remoteproc, linux-kernel, linux-arm-kernel,
linux-mediatek, Mukesh Ojha
In-Reply-To: <20260609102254.2671238-1-mukesh.ojha@oss.qualcomm.com>
If a subdevice fails to stop, it indicates broken communication with the
DSP. Continuing to stop further subdevices against an unresponsive
remote processor could close rpmsg devices that could remove the memory
mapping from HLOS and in case if remote processor touches those memory
can result in SMMU fault.
Change rproc_stop_subdevices() to return int and abort on the first
failing subdev. Propagate the error through rproc_stop() and
__rproc_detach() so callers are aware the teardown did not complete
cleanly.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/remoteproc/remoteproc_core.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 21127d972bff..77c4f09c7604 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1110,7 +1110,7 @@ static int rproc_start_subdevices(struct rproc *rproc)
return ret;
}
-static void rproc_stop_subdevices(struct rproc *rproc, bool crashed)
+static int rproc_stop_subdevices(struct rproc *rproc, bool crashed)
{
struct rproc_subdev *subdev;
int ret;
@@ -1118,10 +1118,14 @@ static void rproc_stop_subdevices(struct rproc *rproc, bool crashed)
list_for_each_entry_reverse(subdev, &rproc->subdevs, node) {
if (subdev->stop) {
ret = subdev->stop(subdev, crashed);
- if (ret)
- dev_warn(&rproc->dev, "subdev stop failed: %d\n", ret);
+ if (ret) {
+ dev_err(&rproc->dev, "subdev stop failed: %d\n", ret);
+ return ret;
+ }
}
}
+
+ return 0;
}
static void rproc_unprepare_subdevices(struct rproc *rproc)
@@ -1712,7 +1716,12 @@ static int rproc_stop(struct rproc *rproc, bool crashed)
return -EINVAL;
/* Stop any subdevices for the remote processor */
- rproc_stop_subdevices(rproc, crashed);
+ ret = rproc_stop_subdevices(rproc, crashed);
+ if (ret) {
+ dev_err(dev, "failed to stop subdevices for %s: %d\n",
+ rproc->name, ret);
+ return ret;
+ }
/* the installed resource table is no longer accessible */
ret = rproc_reset_rsc_table_on_stop(rproc);
@@ -1751,7 +1760,12 @@ static int __rproc_detach(struct rproc *rproc)
return -EINVAL;
/* Stop any subdevices for the remote processor */
- rproc_stop_subdevices(rproc, false);
+ ret = rproc_stop_subdevices(rproc, false);
+ if (ret) {
+ dev_err(dev, "failed to stop subdevices for %s: %d\n",
+ rproc->name, ret);
+ return ret;
+ }
/* the installed resource table is no longer accessible */
ret = rproc_reset_rsc_table_on_detach(rproc);
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] remoteproc: check return value of subdev stop and unprepare callbacks
From: Mukesh Ojha @ 2026-06-09 10:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-arm-msm, linux-remoteproc, linux-kernel, linux-arm-kernel,
linux-mediatek, Mukesh Ojha
In-Reply-To: <20260609102254.2671238-1-mukesh.ojha@oss.qualcomm.com>
The stop() and unprepare() callbacks in struct rproc_subdev were void,
making it impossible for implementations to report failures. Unlike
prepare() and start() which already return int and have their errors
checked, errors during teardown were silently discarded.
Change the callback signatures to return int. Update
rproc_stop_subdevices() and rproc_unprepare_subdevices() to check each
return value and emit a warning on failure while continuing to visit all
remaining subdevices (best-effort teardown).
rproc_vdev_do_stop() propagates the error from device_for_each_child()
which it was already computing but had no way to surface. All other
implementations (glink, smd, ssr, pdm, sysmon) gain a return 0 as they
have no failure paths.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/remoteproc/qcom_common.c | 26 +++++++++++++++++++-------
drivers/remoteproc/qcom_sysmon.c | 10 +++++++---
drivers/remoteproc/remoteproc_core.c | 16 ++++++++++++----
drivers/remoteproc/remoteproc_virtio.c | 4 +++-
drivers/rpmsg/mtk_rpmsg.c | 8 ++++++--
include/linux/remoteproc.h | 4 ++--
6 files changed, 49 insertions(+), 19 deletions(-)
diff --git a/drivers/remoteproc/qcom_common.c b/drivers/remoteproc/qcom_common.c
index fd2b6824ad26..05a599318763 100644
--- a/drivers/remoteproc/qcom_common.c
+++ b/drivers/remoteproc/qcom_common.c
@@ -216,19 +216,23 @@ static int glink_subdev_start(struct rproc_subdev *subdev)
return PTR_ERR_OR_ZERO(glink->edge);
}
-static void glink_subdev_stop(struct rproc_subdev *subdev, bool crashed)
+static int glink_subdev_stop(struct rproc_subdev *subdev, bool crashed)
{
struct qcom_rproc_glink *glink = to_glink_subdev(subdev);
qcom_glink_smem_unregister(glink->edge);
glink->edge = NULL;
+
+ return 0;
}
-static void glink_subdev_unprepare(struct rproc_subdev *subdev)
+static int glink_subdev_unprepare(struct rproc_subdev *subdev)
{
struct qcom_rproc_glink *glink = to_glink_subdev(subdev);
qcom_glink_ssr_notify(glink->ssr_name);
+
+ return 0;
}
/**
@@ -327,12 +331,14 @@ static int smd_subdev_start(struct rproc_subdev *subdev)
return PTR_ERR_OR_ZERO(smd->edge);
}
-static void smd_subdev_stop(struct rproc_subdev *subdev, bool crashed)
+static int smd_subdev_stop(struct rproc_subdev *subdev, bool crashed)
{
struct qcom_rproc_subdev *smd = to_smd_subdev(subdev);
qcom_smd_unregister_edge(smd->edge);
smd->edge = NULL;
+
+ return 0;
}
/**
@@ -465,7 +471,7 @@ static int ssr_notify_start(struct rproc_subdev *subdev)
return 0;
}
-static void ssr_notify_stop(struct rproc_subdev *subdev, bool crashed)
+static int ssr_notify_stop(struct rproc_subdev *subdev, bool crashed)
{
struct qcom_rproc_ssr *ssr = to_ssr_subdev(subdev);
struct qcom_ssr_notify_data data = {
@@ -475,9 +481,11 @@ static void ssr_notify_stop(struct rproc_subdev *subdev, bool crashed)
srcu_notifier_call_chain(&ssr->info->notifier_list,
QCOM_SSR_BEFORE_SHUTDOWN, &data);
+
+ return 0;
}
-static void ssr_notify_unprepare(struct rproc_subdev *subdev)
+static int ssr_notify_unprepare(struct rproc_subdev *subdev)
{
struct qcom_rproc_ssr *ssr = to_ssr_subdev(subdev);
struct qcom_ssr_notify_data data = {
@@ -487,6 +495,8 @@ static void ssr_notify_unprepare(struct rproc_subdev *subdev)
srcu_notifier_call_chain(&ssr->info->notifier_list,
QCOM_SSR_AFTER_SHUTDOWN, &data);
+
+ return 0;
}
/**
@@ -572,16 +582,18 @@ static int pdm_notify_prepare(struct rproc_subdev *subdev)
}
-static void pdm_notify_unprepare(struct rproc_subdev *subdev)
+static int pdm_notify_unprepare(struct rproc_subdev *subdev)
{
struct qcom_rproc_pdm *pdm = to_pdm_subdev(subdev);
if (!pdm->adev)
- return;
+ return 0;
auxiliary_device_delete(pdm->adev);
auxiliary_device_uninit(pdm->adev);
pdm->adev = NULL;
+
+ return 0;
}
/**
diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
index 913e3b750a86..44b905a7e129 100644
--- a/drivers/remoteproc/qcom_sysmon.c
+++ b/drivers/remoteproc/qcom_sysmon.c
@@ -531,7 +531,7 @@ static int sysmon_start(struct rproc_subdev *subdev)
return 0;
}
-static void sysmon_stop(struct rproc_subdev *subdev, bool crashed)
+static int sysmon_stop(struct rproc_subdev *subdev, bool crashed)
{
struct qcom_sysmon *sysmon = container_of(subdev, struct qcom_sysmon, subdev);
struct sysmon_event event = {
@@ -548,7 +548,7 @@ static void sysmon_stop(struct rproc_subdev *subdev, bool crashed)
/* Don't request graceful shutdown if we've crashed */
if (crashed)
- return;
+ return 0;
if (sysmon->ssctl_instance) {
if (!wait_for_completion_timeout(&sysmon->ssctl_comp, HZ / 2))
@@ -559,9 +559,11 @@ static void sysmon_stop(struct rproc_subdev *subdev, bool crashed)
sysmon->shutdown_acked = ssctl_request_shutdown(sysmon);
else if (sysmon->ept)
sysmon->shutdown_acked = sysmon_request_shutdown(sysmon);
+
+ return 0;
}
-static void sysmon_unprepare(struct rproc_subdev *subdev)
+static int sysmon_unprepare(struct rproc_subdev *subdev)
{
struct qcom_sysmon *sysmon = container_of(subdev, struct qcom_sysmon,
subdev);
@@ -574,6 +576,8 @@ static void sysmon_unprepare(struct rproc_subdev *subdev)
sysmon->state = SSCTL_SSR_EVENT_AFTER_SHUTDOWN;
blocking_notifier_call_chain(&sysmon_notifiers, 0, (void *)&event);
mutex_unlock(&sysmon->state_lock);
+
+ return 0;
}
/**
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index f003be006b1b..21127d972bff 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1113,20 +1113,28 @@ static int rproc_start_subdevices(struct rproc *rproc)
static void rproc_stop_subdevices(struct rproc *rproc, bool crashed)
{
struct rproc_subdev *subdev;
+ int ret;
list_for_each_entry_reverse(subdev, &rproc->subdevs, node) {
- if (subdev->stop)
- subdev->stop(subdev, crashed);
+ if (subdev->stop) {
+ ret = subdev->stop(subdev, crashed);
+ if (ret)
+ dev_warn(&rproc->dev, "subdev stop failed: %d\n", ret);
+ }
}
}
static void rproc_unprepare_subdevices(struct rproc *rproc)
{
struct rproc_subdev *subdev;
+ int ret;
list_for_each_entry_reverse(subdev, &rproc->subdevs, node) {
- if (subdev->unprepare)
- subdev->unprepare(subdev);
+ if (subdev->unprepare) {
+ ret = subdev->unprepare(subdev);
+ if (ret)
+ dev_warn(&rproc->dev, "subdev unprepare failed: %d\n", ret);
+ }
}
}
diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
index d5e9ff045a28..128d3088a959 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -480,7 +480,7 @@ static int rproc_vdev_do_start(struct rproc_subdev *subdev)
return rproc_add_virtio_dev(rvdev, rvdev->id);
}
-static void rproc_vdev_do_stop(struct rproc_subdev *subdev, bool crashed)
+static int rproc_vdev_do_stop(struct rproc_subdev *subdev, bool crashed)
{
struct rproc_vdev *rvdev = container_of(subdev, struct rproc_vdev, subdev);
struct device *dev = &rvdev->pdev->dev;
@@ -489,6 +489,8 @@ static void rproc_vdev_do_stop(struct rproc_subdev *subdev, bool crashed)
ret = device_for_each_child(dev, NULL, rproc_remove_virtio_dev);
if (ret)
dev_warn(dev, "can't remove vdev child device: %d\n", ret);
+
+ return ret;
}
static int rproc_virtio_probe(struct platform_device *pdev)
diff --git a/drivers/rpmsg/mtk_rpmsg.c b/drivers/rpmsg/mtk_rpmsg.c
index 1b670ed54cfa..d8ea77055f31 100644
--- a/drivers/rpmsg/mtk_rpmsg.c
+++ b/drivers/rpmsg/mtk_rpmsg.c
@@ -326,7 +326,7 @@ static int mtk_rpmsg_prepare(struct rproc_subdev *subdev)
return 0;
}
-static void mtk_rpmsg_unprepare(struct rproc_subdev *subdev)
+static int mtk_rpmsg_unprepare(struct rproc_subdev *subdev)
{
struct mtk_rpmsg_rproc_subdev *mtk_subdev = to_mtk_subdev(subdev);
@@ -334,9 +334,11 @@ static void mtk_rpmsg_unprepare(struct rproc_subdev *subdev)
mtk_rpmsg_destroy_ept(mtk_subdev->ns_ept);
mtk_subdev->ns_ept = NULL;
}
+
+ return 0;
}
-static void mtk_rpmsg_stop(struct rproc_subdev *subdev, bool crashed)
+static int mtk_rpmsg_stop(struct rproc_subdev *subdev, bool crashed)
{
struct mtk_rpmsg_channel_info *info, *next;
struct mtk_rpmsg_rproc_subdev *mtk_subdev = to_mtk_subdev(subdev);
@@ -372,6 +374,8 @@ static void mtk_rpmsg_stop(struct rproc_subdev *subdev, bool crashed)
kfree(info);
}
mutex_unlock(&mtk_subdev->channels_lock);
+
+ return 0;
}
struct rproc_subdev *
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 7c1546d48008..315c479d163a 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -335,8 +335,8 @@ struct rproc_subdev {
int (*prepare)(struct rproc_subdev *subdev);
int (*start)(struct rproc_subdev *subdev);
- void (*stop)(struct rproc_subdev *subdev, bool crashed);
- void (*unprepare)(struct rproc_subdev *subdev);
+ int (*stop)(struct rproc_subdev *subdev, bool crashed);
+ int (*unprepare)(struct rproc_subdev *subdev);
};
/* we currently support only two vrings per rvdev */
--
2.53.0
^ permalink raw reply related
* [PATCH 0/3] remoteproc: fix silent teardown failures and prevent SMMU faults on hung DSP
From: Mukesh Ojha @ 2026-06-09 10:22 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-arm-msm, linux-remoteproc, linux-kernel, linux-arm-kernel,
linux-mediatek, Mukesh Ojha
When a DSP hangs without triggering its own crash handler, a graceful
shutdown via sysmon times out. Before this series, two things went
wrong:
1. The stop() and unprepare() callbacks in struct rproc_subdev were
void. Implementations had no way to surface failures, and callers
discarded any internal error state silently.
2. Even if an error had been detectable, rproc_stop_subdevices() kept
iterating after a failed stop. This meant glink and ssr subdevices
were torn down regardless, causing HLOS to unregister and unmap the
shared memory regions. If the remote still had DMA in flight
against those regions — as is often the case with a hung DSP — the
result was an SMMU fault.
This series fixes both problems in three steps.
Patch 1 changes stop() and unprepare() from void to int, matching
prepare() and start(). Most implementations gain a trivial return 0;
rproc_vdev_do_stop() now surfaces the error it was already computing.
Callers warn on failure but continue iterating (best-effort).
Patch 2 changes rproc_stop_subdevices() to abort and return error on the
first failing subdev, propagating through rproc_stop() and
__rproc_detach().
Patch 3 makes sysmon_stop() return -ETIMEDOUT when the remote does not
acknowledge a graceful shutdown request. Combined with patch 2, this
prevents glink and ssr from unmapping shared memory against a hung DSP.
Mukesh Ojha (3):
remoteproc: check return value of subdev stop and unprepare callbacks
remoteproc: abort subdev stop sequence on first failure
remoteproc: qcom_sysmon: abort stop on unacknowledged shutdown
drivers/remoteproc/qcom_common.c | 26 ++++++++++++++-----
drivers/remoteproc/qcom_sysmon.c | 15 ++++++++---
drivers/remoteproc/remoteproc_core.c | 36 +++++++++++++++++++++-----
drivers/remoteproc/remoteproc_virtio.c | 4 ++-
drivers/rpmsg/mtk_rpmsg.c | 8 ++++--
include/linux/remoteproc.h | 4 +--
6 files changed, 71 insertions(+), 22 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH 4/4] arm64: route crash_smp_send_stop() last resort through SDEI
From: Kiryl Shutsemau @ 2026-06-09 10:21 UTC (permalink / raw)
To: Doug Anderson
Cc: Catalin Marinas, Will Deacon, James Morse, Mark Rutland,
Marc Zyngier, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <aiNCk2M0OlD7VaEs@thinkstation>
On Fri, Jun 05, 2026 at 10:46:11PM +0100, Kiryl Shutsemau wrote:
> On Fri, Jun 05, 2026 at 01:42:57PM -0700, Doug Anderson wrote:
> > > + sdei_nmi_crash_smp_send_stop();
> >
> > It feels weird to me that you're adding SDEI for "crash stop" but not
> > for regular "stop". It feels like you should modify smp_send_stop() to
> > fall back to SDEI if sending the NMI failed, instead of adding this
> > separate path.
>
> Fair. A wedged CPU ignores the reboot-path stop just the same, and the
> escalation logic already lives in smp.c, so I'll restructure in v2.
>
> One thing to sort out there: this patch parks the stopped CPU inside
> its SDEI handler without completing the event, which is fine for the
> crash case (nothing expects the CPU back before reset), but a generic
> stop path probably wants SDEI_EVENT_COMPLETE_AND_RESUME into a parking
> stub instead, so that e.g. a regular kexec can bring all CPUs back up
> in the new kernel. I'll look into that as part of the rework.
Regular kexec takes different path and offlines CPU normally. So the
next kernel can start them. But crash kernel cannot re-use wedged CPU.
C&R alone doesn't buy us anything. We need to get the CPU to CPU_OFF.
I am trying to do this, but so far no luck. Crash kernel fails to start
at all if try to do C&R and then CPU_OFF. C&R alone works, but CPU is
still unreachable by the next kernel, as expected.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v3 03/17] clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE
From: Marc Zyngier @ 2026-06-09 10:21 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber,
"Yu-Chun Lin [林祐君]", Heiko Stuebner,
Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <ea15cce1-b393-43f6-8d58-3d6f90f0c0cd@samsung.com>
On Tue, 09 Jun 2026 11:03:21 +0100,
Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> Dear All,
>
> On 23.05.2026 16:02, Marc Zyngier wrote:
> > When running with at EL2 with VHE enabled, the architecture provides
> > two EL2 timer/counters, dubbed physical and virtual. Apart from their
> > names, they are strictly identical.
> >
> > However, they don't get virtualised the same way, specially when
> > it comes to adding arbitrary offsets to the timers. When running as
> > a guest, the host CNTVOFF_EL2 does apply to the guest's view of
> > CNTHV*_El2. This is not true for CNTPOFF_EL2 and CNTHP*_EL2, as
> > the architecture is broken past the first level of virtualisation
> > (it lacks some essential mechanisms to be usable, despite what
> > the ARM ARM pretends).
> >
> > This means that when running as a L2 guest hypervisor, using the
> > physical timer results in traps to L0, which are then forwarded to
> > L1 in order to emulate the offset, leading to even worse performance
> > due to massive trap amplification (the combination of register and
> > ERET trapping is absolutely lethal).
> >
> > Switch the arch timer code to using the virtual timer when running
> > in VHE by default, only using the physical timer if the interrupt
> > is not correctly described in the firmware tables (which seems
> > to be an unfortunately common case). This comes as no impact on
> > bare-metal, and slightly improves the situation in the virtualised
> > case.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> This patch landed recently in linux-next as commit d87773de9efe
> ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when
> running VHE"). In my tests I found that it breaks booting of RaspberryPi5
> board. Reverting it on top of linux-next fixes the issue. Here is a boot
> log:
Huh.
[...]
> arch_timer: cp15 timer running at 54.00MHz (hyp-virt).
> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
> sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
The interrupt appears to be advertised in the DT, but doesn't seem to
fire. That's obviously not going to end well. My suspicion is that
either the interrupt isn't wired (that'd be hilariously abd), or is
left as Group-0 by the firmware (copy-paste from RPi4).
Can you try the following hack and let me know if the kernel shouts at
you?
Thanks,
M.
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index ec70c84e9f91d..d05791e6cc0db 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -213,6 +213,7 @@ static void gic_eoimode1_mask_irq(struct irq_data *d)
static void gic_unmask_irq(struct irq_data *d)
{
gic_poke_irq(d, GIC_DIST_ENABLE_SET);
+ WARN_ON(!gic_peek_irq(d, GIC_DIST_ENABLE_SET));
}
static void gic_eoi_irq(struct irq_data *d)
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH v8 09/12] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops
From: Pranjal Shrivastava @ 2026-06-09 10:13 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rCTHZOiSx5tTVmLmubJ4SUDtXvCX6oLqsdEsPAFTKJZ4A@mail.gmail.com>
On Tue, Jun 02, 2026 at 08:27:22AM -0700, Daniel Mentz wrote:
> On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan@google.com> wrote:
> > +static inline u32 arm_smmu_cmdq_owner_prod_idx(struct arm_smmu_cmdq *cmdq)
> > +{
> > + return atomic_read(&cmdq->owner_prod) & CMDQ_PROD_IDX_MASK;
>
> Is this masking necessary? Can't we just use
> atomic_read(&cmdq->owner_prod) as is? The only place in
> arm_smmu_cmdq_issue_cmdlist() that writes to cmdq->owner_prod already
> applied CMDQ_PROD_IDX_MASK.
Ack. I'll drop the masking.
>
> > +}
> > +
>
> > @@ -4839,6 +4876,10 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
> > return ret;
> > }
> >
> > + /* Clear any flags from the previous life */
> > + atomic_andnot(CMDQ_PROD_STOP_FLAG, &smmu->cmdq.owner_prod);
>
> Same. I believe CMDQ_PROD_STOP_FLAG will never be set in
> smmu->cmdq.owner_prod. Hence, clearing it shouldn't be necessary.
Ack. I'll drop this.
>
> > + atomic_andnot(CMDQ_PROD_STOP_FLAG, &smmu->cmdq.q.llq.atomic.prod);
> > +
> > /* Invalidate any cached configuration */
> > arm_smmu_cmdq_issue_cmd_with_sync(smmu, arm_smmu_make_cmd_cfgi_all());
> >
> > @@ -4898,6 +4939,21 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
Thanks,
Praan
^ 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