* Re: [PATCH 1/3] arm64: dts: amlogic: t7: Add uart_c pinctrl pins group
From: Ronald Claveau @ 2026-04-15 13:44 UTC (permalink / raw)
To: Xianwei Zhao
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <956625df-0a80-4d0e-9bb7-8071d5797748@amlogic.com>
Hello Xianwei,
On 4/15/26 1:28 PM, Xianwei Zhao wrote:
>
>
> On 2026/4/15 19:16, Ronald Claveau wrote:
>> Add the pin multiplexing configuration for UART C (TX, RX, CTS, RTS)
>> in the T7 SoC pinctrl node, required to route the UART C signals
>> through the correct pads before enabling the controller.
>>
>> Signed-off-by: Ronald Claveau<linux-kernel-dev@aliel.fr>
>> ---
>> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/
>> boot/dts/amlogic/amlogic-t7.dtsi
>> index 7fe72c94ed623..531931cc1437c 100644
>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> @@ -553,6 +553,18 @@ mux {
>> bias-pull-up;
>> };
>> };
>> +
>> + uart_c_pins: uart_c {
> node name uart-c
I will change this, thank you for reminding me.
>> + mux {
>> + groups = "uart_c_tx",
>> + "uart_c_rx",
>> + "uart_c_cts",
>> + "uart_c_rts";
>> + bias-pull-up;
>> + output-high;
>> + function = "uart_c";
>> + };
>> + };
>> };
>>
>> gpio_intc: interrupt-controller@4080 {
--
Best regards,
Ronald
^ permalink raw reply
* Re: [EXTERNAL] Re: [PATCH 1/8] hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS
From: Thomas Zimmermann @ 2026-04-15 13:42 UTC (permalink / raw)
To: Saurabh Singh Sengar, javierm@redhat.com, arnd@arndb.de,
ardb@kernel.org, ilias.apalodimas@linaro.org,
chenhuacai@kernel.org, kernel@xen0n.name,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
airlied@gmail.com, simona@ffwll.ch, KY Srinivasan, Haiyang Zhang,
wei.liu@kernel.org, Dexuan Cui, Long Li, deller@gmx.de
Cc: linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
linux-efi@vger.kernel.org, linux-riscv@lists.infradead.org,
dri-devel@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
linux-fbdev@vger.kernel.org, Michael Kelley, Saurabh Sengar,
stable@vger.kernel.org
In-Reply-To: <KUZP153MB1444885C302B353C02C2FA2FBE242@KUZP153MB1444.APCP153.PROD.OUTLOOK.COM>
Am 13.04.26 um 10:22 schrieb Saurabh Singh Sengar:
[...]
>>
>>> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
>> This fix is independent from the rest of the series. Do you want to merge it or
>> can I take it into DRM trees?
> Please feel free to take it via DRM tree.
Done now. Thanks a lot.
> CC : Wei Liu
>
> - Saurabh
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v12 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: Andrew Lunn @ 2026-04-15 13:24 UTC (permalink / raw)
To: P.K. Lee
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Jason-Hsu, p.k.lee
In-Reply-To: <CAK8yEOAOhY25R5qt82LUkGifg_9HLia24-E=WxoEwCdbft1eMg@mail.gmail.com>
On Wed, Apr 15, 2026 at 06:05:32PM +0800, P.K. Lee wrote:
> > > > > > If there are no devices on the bus, why enable it?
> > > > >
> > > > > We intentionally enable it so user-space tools can access the switch
> > > > > registers. I have added a comment in v13 to clarify this.
> > > >
> > > > Why would user space want to access the switch registers for an
> > > > unmanaged switch? It sounds like you are using Marvells SDK in
> > > > userspace to manage the switch, rather than using DSA.
> > > >
> > >
> > > We do have a custom user-space daemon that configures the switch
> > > registers for our specific use case. Should I remove the &mdio0 node
> > > if it is only enabled and has no other configuration in the upstream
> > > device tree?
> >
> > Please just be truthful that you have a user space driver, so need the
> > bus enabled.
> >
> > I also guess you have some other kernel code that allows you to
> > actually use the bus from user space? The typical ethernet IOCTL
> > handler does not work for you, since you don't have an ethernet device
> > using this bus. Such code is unlikely to be accepted into mainline. We
> > don't like user space drivers when there is a perfectly good kernel
> > driver for this switch.
>
> Since the kernel driver for mv88e6xxx in kernel 6.6 used by this
> project does not support LED control, and this feature is only
> available starting from kernel 6.13, I had to initialize the LEDs of
> the 88E6393X from user space.
>
> In this case, should I remove the &mdio0 node?
I would keep it, and add a comment why it is there. And upgrade the
kernel to 6.18, or backport the LED code.
Andrew
^ permalink raw reply
* Re: [PATCH] KVM: arm64: pkvm: Adopt MARKER() to define host hypercall ranges
From: Marc Zyngier @ 2026-04-15 13:18 UTC (permalink / raw)
To: Fuad Tabba
Cc: kvmarm, linux-arm-kernel, Will Deacon, Vincent Donnefort,
Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu
In-Reply-To: <CA+EHjTxWAFKHqBUOCVkkqtzTKrMSU8HQDwoLMqD2HQPga7y_-w@mail.gmail.com>
On Wed, 15 Apr 2026 10:56:17 +0100,
Fuad Tabba <tabba@google.com> wrote:
>
> Hi Marc,
>
> On Tue, 14 Apr 2026 at 17:05, Marc Zyngier <maz@kernel.org> wrote:
> >
> > The EL2 code defines ranges of host hypercalls that are either
> > enabled at boot-time only, used by [nh]VHE KVM, or reserved to pKVM.
> >
> > The way these ranges are delineated is error prone, as the enum symbols
> > defining the limits are expressed in terms of actual function symbols.
> > This means that should a new function be added, special care must be
> > taken to also update the limit symbol.
> >
> > Improve this by reusing the mechanism introduced for the vcpu_sysreg
> > enum, which uses a MARKER() macro and some extra trickery to make
> > the limit symbol standalone. Crucially, the limit symbol has the
> > same value as the *following* symbol.
> >
> > The handle_host_hcall() function is then updated to make use of
> > the new limit definitions and get rid of the brittle default
> > upper limit. This allows for some more strict checks at build
> > time, and the removal of an comparison at run time.
>
> This is pretty neat. There is still the issue of a hole, i.e., adding
> an enum in the middle but forgetting to add a function, but that is
> caught in handle_host_hcall(). I can't think of an easy way to catch
> that though (xarray that initializes both?)
Yeah, there isn't a simple way to do that at compile-time,
unfortunately.
One thing that could be done is to have a blanket initialisation with
an illegal value, override all the entries you want, and then check at
KVM init time for the presence of the canary value. If you find it,
abort the KVM initialisation.
With that, you can drop the NULL test on the handling path.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
>
> Tested-by: Fuad Tabba <tabba@google.com>
> Reviewed-by: Fuad Tabba <tabba@google.com>
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH v2 1/2] thermal/drivers/imx: Fix thermal zone leak on probe error path
From: Felix Gu @ 2026-04-15 13:10 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Felix Gu
In-Reply-To: <20260415-imx-v2-0-aeacff9e72b2@gmail.com>
If pm_runtime_resume_and_get() fails after the thermal zone has been
registered, the probe error path cleans up runtime PM but skips
thermal_zone_device_unregister(), leaking the thermal zone device.
Switch to use devm_thermal_of_zone_register() to fix the problem.
Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/thermal/imx_thermal.c | 35 +++++++++++++++++++----------------
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 38c993d1bcb3..3729c3eac748 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -216,6 +216,20 @@ struct imx_thermal_data {
const char *temp_grade;
};
+static int imx_thermal_sync_zone_trip(struct thermal_trip *trip, void *arg)
+{
+ struct imx_thermal_data *data = arg;
+ int temp;
+
+ if (trip->type != THERMAL_TRIP_PASSIVE && trip->type != THERMAL_TRIP_CRITICAL)
+ return 0;
+
+ temp = trips[trip->type].temperature;
+ thermal_zone_set_trip_temp(data->tz, trip, temp);
+
+ return 0;
+}
+
static void imx_set_panic_temp(struct imx_thermal_data *data,
int panic_temp)
{
@@ -679,13 +693,8 @@ static int imx_thermal_probe(struct platform_device *pdev)
goto legacy_cleanup;
}
- data->tz = thermal_zone_device_register_with_trips("imx_thermal_zone",
- trips,
- ARRAY_SIZE(trips),
- data,
- &imx_tz_ops, NULL,
- IMX_PASSIVE_DELAY,
- IMX_POLLING_DELAY);
+ data->irq_enabled = true;
+ data->tz = devm_thermal_of_zone_register(dev, 0, data, &imx_tz_ops);
if (IS_ERR(data->tz)) {
ret = PTR_ERR(data->tz);
dev_err(dev, "failed to register thermal zone device %d\n",
@@ -693,6 +702,8 @@ static int imx_thermal_probe(struct platform_device *pdev)
goto clk_disable;
}
+ thermal_zone_for_each_trip(data->tz, imx_thermal_sync_zone_trip, data);
+
dev_info(dev, "%s CPU temperature grade - max:%dC"
" critical:%dC passive:%dC\n", data->temp_grade,
data->temp_max / 1000, trips[IMX_TRIP_CRITICAL].temperature / 1000,
@@ -724,25 +735,18 @@ static int imx_thermal_probe(struct platform_device *pdev)
if (ret < 0)
goto disable_runtime_pm;
- data->irq_enabled = true;
- ret = thermal_zone_device_enable(data->tz);
- if (ret)
- goto thermal_zone_unregister;
-
ret = devm_request_threaded_irq(dev, data->irq,
imx_thermal_alarm_irq, imx_thermal_alarm_irq_thread,
0, "imx_thermal", data);
if (ret < 0) {
dev_err(dev, "failed to request alarm irq: %d\n", ret);
- goto thermal_zone_unregister;
+ goto disable_runtime_pm;
}
pm_runtime_put(data->dev);
return 0;
-thermal_zone_unregister:
- thermal_zone_device_unregister(data->tz);
disable_runtime_pm:
pm_runtime_put_noidle(data->dev);
pm_runtime_disable(data->dev);
@@ -761,7 +765,6 @@ static void imx_thermal_remove(struct platform_device *pdev)
pm_runtime_put_noidle(data->dev);
pm_runtime_disable(data->dev);
- thermal_zone_device_unregister(data->tz);
imx_thermal_unregister_legacy_cooling(data);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] thermal/drivers/imxl:Fix runtime PM handling on early returns
From: Felix Gu @ 2026-04-15 13:10 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Felix Gu
In-Reply-To: <20260415-imx-v2-0-aeacff9e72b2@gmail.com>
Use PM_RUNTIME_ACQUIRE() in imx_get_temp() and imx_set_trip_temp() so
runtime PM references are released correctly even when the functions
return early on errors.
Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/thermal/imx_thermal.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 3729c3eac748..057dbab70266 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -274,8 +274,9 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
u32 val;
int ret;
- ret = pm_runtime_resume_and_get(data->dev);
- if (ret < 0)
+ PM_RUNTIME_ACQUIRE(data->dev, pm);
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
return ret;
regmap_read(map, soc_data->temp_data, &val);
@@ -316,8 +317,6 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
enable_irq(data->irq);
}
- pm_runtime_put(data->dev);
-
return 0;
}
@@ -351,8 +350,9 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
struct imx_thermal_data *data = thermal_zone_device_priv(tz);
int ret;
- ret = pm_runtime_resume_and_get(data->dev);
- if (ret < 0)
+ PM_RUNTIME_ACQUIRE(data->dev, pm);
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
return ret;
/* do not allow passive to be set higher than critical */
@@ -362,8 +362,6 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
imx_set_alarm_temp(data, temp);
trips[IMX_TRIP_PASSIVE].temperature = temp;
- pm_runtime_put(data->dev);
-
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] thermal/drivers/imx: two fixes
From: Felix Gu @ 2026-04-15 13:10 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Felix Gu
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
Changes in v2:
- Switch to use devm_thermal_of_zone_register() to fix Frank and Daniel's comment.
- Collect Frank's Reviewed-by tag for patch 2.
- Link to v1: https://lore.kernel.org/r/20260412-imx-v1-0-cc3b45d63811@gmail.com
---
Felix Gu (2):
thermal/drivers/imx: Fix thermal zone leak on probe error path
thermal/drivers/imxl:Fix runtime PM handling on early returns
drivers/thermal/imx_thermal.c | 49 ++++++++++++++++++++++---------------------
1 file changed, 25 insertions(+), 24 deletions(-)
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260411-imx-b022791ea1b9
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply
* Re: [PATCH v6 01/30] mm: Introduce kpkeys
From: David Hildenbrand (Arm) @ 2026-04-15 13:00 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: linux-kernel, Andrew Morton, Andy Lutomirski, Catalin Marinas,
Dave Hansen, Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Lorenzo Stoakes, Marc Zyngier, Mark Brown,
Matthew Wilcox, Maxwell Bland, Mike Rapoport (IBM),
Peter Zijlstra, Pierre Langlois, Quentin Perret, Rick Edgecombe,
Ryan Roberts, Thomas Gleixner, Vlastimil Babka, Will Deacon,
Yang Shi, Yeoreum Yun, linux-arm-kernel, linux-mm, x86
In-Reply-To: <20260227175518.3728055-2-kevin.brodsky@arm.com>
On 2/27/26 18:54, Kevin Brodsky wrote:
> kpkeys is a simple framework to enable the use of protection keys
> (pkeys) to harden the kernel itself. This patch introduces the basic
> API in <linux/kpkeys.h>: a couple of functions to set and restore
> the pkey register and macros to define guard objects.
>
> kpkeys introduces a new concept on top of pkeys: the kpkeys level.
> Each level is associated to a set of permissions for the pkeys
> managed by the kpkeys framework. kpkeys_set_level(lvl) sets those
> permissions according to lvl, and returns the original pkey
> register, to be later restored by kpkeys_restore_pkey_reg(). To
> start with, only KPKEYS_LVL_DEFAULT is available, which is meant
> to grant RW access to KPKEYS_PKEY_DEFAULT (i.e. all memory since
> this is the only available pkey for now).
>
> Because each architecture implementing pkeys uses a different
> representation for the pkey register, and may reserve certain pkeys
> for specific uses, support for kpkeys must be explicitly indicated
> by selecting ARCH_HAS_KPKEYS and defining the following functions in
> <asm/kpkeys.h>, in addition to the macros provided in
> <asm-generic/kpkeys.h>:
I don't quite understand the reason for using levels. Levels sounds like
it would all be in some ordered fashion, where higher levels have access
to lower levels.
Think of that as a key that can unlock all "lower" locks, not just a
single lock.
Then, the question is about the ordering once we introduce new
keys/locks. With two, it obviously doesn't matter :)
So naturally I wonder whether levels is really the right abstraction
here, and why we are not simply using "distinct" keys, like
KPKEY_DEFAULT
KPKEY_PGTABLE
KPKEY_SUPER_SECRET1
KPKEY_SUPER_SECRET2
Is it because you want KPKEY_PGTABLE also be able to write to KPKEY_DEFAULT?
But how would you handle KPKEY_SUPER_SECRET1 and KPKEY_SUPER_SECRET2 then?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH net-next 5/6] net: stmmac: move PHY handling out of __stmmac_open()/release()
From: Russell King (Oracle) @ 2026-04-15 12:59 UTC (permalink / raw)
To: Alexander Stein
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-stm32, Maxime Coquelin, netdev, Paolo Abeni
In-Reply-To: <8409022.LvFx2qVVIh@steina-w>
On Wed, Apr 15, 2026 at 08:08:40AM +0200, Alexander Stein wrote:
> Hi,
>
> Am Dienstag, 23. September 2025, 13:26:19 CEST schrieb Russell King (Oracle):
> > Move the PHY attachment/detachment from the network driver out of
> > __stmmac_open() and __stmmac_release() into stmmac_open() and
> > stmmac_release() where these actions will only happen when the
> > interface is administratively brought up or down. It does not make
> > sense to detach and re-attach the PHY during a change of MTU.
>
> Sorry for coming up now. But I recently noticed this commit breaks changing
> the MTU on i.MX8MP. Once I simply change the MTU I run into some DMA error:
> $ ip link set dev end1 mtu 1400
> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-0
> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-1
> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-2
> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-3
> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-4
> imx-dwmac 30bf0000.ethernet end1: Link is Down
> imx-dwmac 30bf0000.ethernet end1: Failed to reset the dma
> imx-dwmac 30bf0000.ethernet end1: stmmac_hw_setup: DMA engine initialization failed
This basically means that a clock is missing. Please provide more
information:
- what kernel version are you using?
- has EEE been negotiated?
- does the problem persist when EEE is disabled?
- which PHY is attached to stmmac?
- which PHY interface mode is being used to connect the PHY to stmmac?
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net v5] net: stmmac: Prevent NULL deref when RX memory exhausted
From: Russell King (Oracle) @ 2026-04-15 12:56 UTC (permalink / raw)
To: Sam Edwards
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Maxime Chevallier,
Ovidiu Panait, Vladimir Oltean, Baruch Siach, Serge Semin,
Giuseppe Cavallaro, netdev, linux-stm32, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <20260415023947.7627-1-CFSworks@gmail.com>
On Tue, Apr 14, 2026 at 07:39:47PM -0700, Sam Edwards wrote:
> The CPU receives frames from the MAC through conventional DMA: the CPU
> allocates buffers for the MAC, then the MAC fills them and returns
> ownership to the CPU. For each hardware RX queue, the CPU and MAC
> coordinate through a shared ring array of DMA descriptors: one
> descriptor per DMA buffer. Each descriptor includes the buffer's
> physical address and a status flag ("OWN") indicating which side owns
> the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set
> the flag and the MAC is only allowed to clear it, and both must move
> through the ring in sequence: thus the ring is used for both
> "submissions" and "completions."
>
> In the stmmac driver, stmmac_rx() bookmarks its position in the ring
> with the `cur_rx` index. The main receive loop in that function checks
> for rx_descs[cur_rx].own=0, gives the corresponding buffer to the
> network stack (NULLing the pointer), and increments `cur_rx` modulo the
> ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its
> position with `dirty_rx`, allocates fresh buffers and rearms the
> descriptors (setting OWN=1). If it fails any allocation, it simply stops
> early (leaving OWN=0) and will retry where it left off when next called.
>
> This means descriptors have a three-stage lifecycle (terms my own):
> - `empty` (OWN=1, buffer valid)
> - `full` (OWN=0, buffer valid and populated)
> - `dirty` (OWN=0, buffer NULL)
>
> But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In
> the past (see 'Fixes:'), there was a bug where the loop could cycle
> `cur_rx` all the way back to the first descriptor it dirtied, resulting
> in a NULL dereference when mistaken for `full`. The aforementioned
> commit resolved that *specific* failure by capping the loop's iteration
> limit at `dma_rx_size - 1`, but this is only a partial fix: if the
> previous stmmac_rx_refill() didn't complete, then there are leftover
> `dirty` descriptors that the loop might encounter without needing to
> cycle fully around. The current code therefore panics (see 'Closes:')
> when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to
> catch up to `dirty_rx`.
>
> Fix this by further tightening the clamp from `dma_rx_size - 1` to
> `dma_rx_size - stmmac_rx_dirty() - 1`, subtracting any remnant dirty
> entries and limiting the loop so that `cur_rx` cannot catch back up to
> `dirty_rx`. This carries no risk of arithmetic underflow: since the
> maximum possible return value of stmmac_rx_dirty() is `dma_rx_size - 1`,
> the worst the clamp can do is prevent the loop from running at all.
>
> Fixes: b6cb4541853c7 ("net: stmmac: avoid rx queue overrun")
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221010
> Cc: stable@vger.kernel.org
> Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Locally, while debugging my issues, I used this to prevent cur_rx
catching up with dirty_rx:
status = stmmac_rx_status(priv, &priv->xstats, p);
/* check if managed by the DMA otherwise go ahead */
if (unlikely(status & dma_own))
break;
next_entry = STMMAC_NEXT_ENTRY(rx_q->cur_rx,
priv->dma_conf.dma_rx_size);
if (unlikely(next_entry == rx_q->dirty_rx))
break;
rx_q->cur_rx = next_entry;
If we care about the cost of reloading rx_q->dirty_rx on every
iteration, then I'd suggest that the cost we already incur reading and
writing rx_q->cur_rx is something that should be addressed, and
eliminating that would counter the cost of reading rx_q->dirty_rx. I
suspect, however, that the cost is minimal, as cur_tx and dirty_rx are
likely in the same cache line.
It looks like any fix to stmmac_rx() will also need a corresponding
fix for stmmac_rx_zc().
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v6 00/30] pkeys-based page table hardening
From: David Hildenbrand (Arm) @ 2026-04-15 12:48 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: linux-kernel, Andrew Morton, Andy Lutomirski, Catalin Marinas,
Dave Hansen, Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Lorenzo Stoakes, Marc Zyngier, Mark Brown,
Matthew Wilcox, Maxwell Bland, Mike Rapoport (IBM),
Peter Zijlstra, Pierre Langlois, Quentin Perret, Rick Edgecombe,
Ryan Roberts, Thomas Gleixner, Vlastimil Babka, Will Deacon,
Yang Shi, Yeoreum Yun, linux-arm-kernel, linux-mm, x86
In-Reply-To: <20260227175518.3728055-1-kevin.brodsky@arm.com>
On 2/27/26 18:54, Kevin Brodsky wrote:
> NEW in v6: support for large block mappings through a dedicated page table
> allocator (patch 14-17)
Heh, I had to read till the very end to realize that this is an RFC, and
then saw your other mail.
I can recommend using b4 for patch management, where you can configure a
sticky prefix through
b4 prep --set-prefixes RFC
And using "b4 send" to automate all the rest.
>
> Threat model
> ============
>
> The proposed scheme aims at mitigating data-only attacks (e.g.
> use-after-free/cross-cache attacks). In other words, it is assumed that
> control flow is not corrupted, and that the attacker does not achieve
> arbitrary code execution. Nothing prevents the pkey register from being
> set to its most permissive state - the assumption is that the register
> is only modified on legitimate code paths.
>
> A few related notes:
>
> - Functions that set the pkey register are all implemented inline.
> Besides performance considerations, this is meant to avoid creating
> a function that can be used as a straightforward gadget to set the
> pkey register to an arbitrary value.
>
> - kpkeys_set_level() only accepts a compile-time constant as argument,
> as a variable could be manipulated by an attacker. This could be
> relaxed but it seems unlikely that a variable kpkeys level would be
> needed in practice.
>
I see a lot of value for that also as a debugging mechanism. I hear that
other people had private patches that would attempt to only map leaf
pages in the direct map in pte_offset_map_lock() and friends. I assume
there are some tricky bits to that (concurrent access to page tables).
What's the general take regarding the thread model you describe vs. MTE?
Regarding use-after-free, I'd assume KASAN would achieve something
similar. And with MTE "reasonably" fast. Or what is the biggest
difference you see, there?
I'd assume that one difference would be, that not even match-all
pointers could accidentally modify page tables.
In the future, would you think that both mechanisms (pkey PT table
protection + KASAN) would be active at the same time, or wouldn't there
really be a lot of value in having both enabled?
[...]
>
>
> Open questions
> ==============
>
> A few aspects in this RFC that are debatable and/or worth discussing:
>
> - Can the pkeys block allocator be abstracted into something more
> generic? This seems desirable considering other use-cases for changing
> attributes of regions of the linear map, but the handling of page
> tables while splitting may be difficult to integrate in a generic
> allocator.
>
> - There is currently no restriction on how kpkeys levels map to pkeys
> permissions. A typical approach is to allocate one pkey per level and
> make it writable at that level only. As the number of levels
> increases, we may however run out of pkeys, especially on arm64 (just
> 8 pkeys with POE). Depending on the use-cases, it may be acceptable to
> use the same pkey for the data associated to multiple levels.
>
>
> Any comment or feedback is highly appreciated, be it on the high-level
> approach or implementation choices!
How crucial would the dedicated page table allocator be for a first up
streamed version?
Assuming we introduce this as a debugging feature first, it would be
perfectly reasonable to just disallow large block mappings in the direct
map when enabled.
That means, we could merge basic support first and think about how to
deal with page tables in a different way with most of the pkey details
out of the picture.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
From: Russell King (Oracle) @ 2026-04-15 12:43 UTC (permalink / raw)
To: Sam Edwards
Cc: Jakub Kicinski, Andrew Lunn, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
linux-stm32, Linux Network Development Mailing List, Paolo Abeni
In-Reply-To: <CAH5Ym4jA8w9=UxMT4vKJpnXkuDHtkFtMcg4u2sy_0S+8wgy-9w@mail.gmail.com>
On Tue, Apr 14, 2026 at 07:12:34PM -0700, Sam Edwards wrote:
> On Tue, Apr 14, 2026 at 6:19 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> > Okay, just a quick note to say that nvidia's 5.10.216-tegra kernel
> > survives iperf3 -c -R to the imx6.
>
> Hi Russell,
>
> Aw, you beat me to it! I was about to report that 5.10.104-tegra is
> unaffected. And my iperf3 server is a multi-GbE amd64 machine.
>
> > Dumping the registers and comparing, and then forcing the RQS and TQS
> > values to 0x23 (+1 = 36, *256 = 9216 bytes) and 0x8f (+1 = 144,
> > *256 = 36864 ytes) respectively seems to solve the problem. Under
> > net-next, these both end up being 0xff (+1 = 256, *256 = 65536 bytes.)
> > Suspiciously, 36 * 4 = 144, and I also see that this kernel programs
> > all four of the MTL receive operation mode registers, but only the
> > first MTL transmit operation mode register. However, DMA channels 1-3
> > aren't initialised.
>
> Wow, great! I wonder if the problem is that the MTL FIFOs are smaller
> than that, so when the DMA suffers a momentary hiccup, the FIFOs are
> allowed to overflow, putting the hardware in a bad state.
>
> Though I suspect this is only half of the problem: do you still see
> RBUs? Everything you've shared so far suggests the DMA failures are
> _not_ because the rx ring is drying up.
Yes. Note that RBUs will happen not because of DMA failures, but if
the kernel fails to keep up with the packet rate. RBU means "we read
the next descriptor, and it wasn't owned by hardware".
> > Looking back at 5.10, I don't see any code that would account for these
> > values being programmed for TQS and RQS, it looks like the calculations
> > are basically the same as we have today.
>
> Note that Nvidia have their own "nvethernet" driver for their vendor
> kernel, which appears to pick the FIFO sizes from hardcoded tables in
> its eqos_configure_mtl_queue() [1] function.
That has:
const nveu32_t rx_fifo_sz[2U][OSI_EQOS_MAX_NUM_QUEUES] = {
{ FIFO_SZ(9U), FIFO_SZ(9U), FIFO_SZ(9U), FIFO_SZ(9U),
FIFO_SZ(1U), FIFO_SZ(1U), FIFO_SZ(1U), FIFO_SZ(1U) },
{ FIFO_SZ(36U), FIFO_SZ(2U), FIFO_SZ(2U), FIFO_SZ(2U),
FIFO_SZ(2U), FIFO_SZ(2U), FIFO_SZ(2U), FIFO_SZ(16U) },
};
const nveu32_t tx_fifo_sz[2U][OSI_EQOS_MAX_NUM_QUEUES] = {
{ FIFO_SZ(9U), FIFO_SZ(9U), FIFO_SZ(9U), FIFO_SZ(9U),
FIFO_SZ(1U), FIFO_SZ(1U), FIFO_SZ(1U), FIFO_SZ(1U) },
{ FIFO_SZ(8U), FIFO_SZ(8U), FIFO_SZ(8U), FIFO_SZ(8U),
FIFO_SZ(8U), FIFO_SZ(8U), FIFO_SZ(8U), FIFO_SZ(8U) },
};
where each of those values is the RQS/TQS value to use in KiB:
#define FIFO_SZ(x) ((((x) * 1024U) / 256U) - 1U)
This doesn't correspond with the values I'm seeing programmed into
the hardware under the 5.10.216-tegra kernel. I'm seeing TQS = 143
(36KiB), and RQS = 35 (9KiB). Yes, these values exist in the tables
above from a quick look, but they're not in the right place!
For example, tx_fifo_sz[] doesn't contain an entry for 36KiB.
rx_fifo_sz[0][0..3] looks plausible.
It's certainly not a case of misreading the register values, this is
what devmem2 said:
Value at address 0x02490d00: 0x008f000a
Value at address 0x02490d30: 0x02379eb0
where TQS is bits 24:16 of the register at offset 0xd00 - which is
0x8f, and RQS is bits 29:20 of the register at 0xd30, which is
0x23.
Now, as for FIFO sizes, if we sum up all the entries, then we
get:
SUM(rx_fifo_size[0][]) = 60KiB
SUM(rx_fifo_size[1][]) = 64KiB
SUM(tx_fifo_size[0][]) = 60KiB
SUM(tx_fifo_size[1][]) = 64KiB
From what I gather in core_local.h, l_mac_ver contains one of three
values - 0 = Legacy EQOS, 1 = Orin EQOS, 2 = Orin MGBE, and which
set of values is selected by bit 0 of that. Decoding this further,
Legacy EQOS is IP version v5.0, Orin EQOS is v5.3, and Orin MGBE
is v3.1 and v4.0.
So, I wonder whether there's something in "Legacy EQOS" that consumes
4KiB of FIFO that isn't documented in iMX8M (IP v5.1).
Is anyone aware of public SoC documentation that covers the v5.0 IP
version?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'
From: Ben Horgan @ 2026-04-15 12:42 UTC (permalink / raw)
To: Zeng Heng, James Morse
Cc: Qinxin Xia, amitsinght, baisheng.gao, baolin.wang, carl,
dave.martin, david, dfustini, fenghuay, gshan, jonathan.cameron,
kobak, lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, xhao, Linuxarm
In-Reply-To: <d5918112-0c9f-ecf3-226c-8c3cdd5cd508@huawei.com>
Hi Zeng,
On 4/15/26 02:27, Zeng Heng wrote:
> Hi Ben,
>
> On 2026/4/13 23:02, Ben Horgan wrote:
>> Hi Qinxin,
>>
>> On 4/3/26 03:44, Qinxin Xia wrote:
>>>
>>>
>>> On 2026/3/27 18:47:49, Ben Horgan <ben.horgan@arm.com> wrote:
>>>> Hi Qinxin,
>>>>
>>>> On 3/27/26 10:21, Qinxin Xia wrote:
>>>>>
>>>>> Hello everyone!
>>>>>
>>>>> In earlier versions, mpam supports the configuration of iommu_groups.
>>>>>
>>>>> 823 static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
>>>>> 824 char *buf, size_t nbytes,
>>>>> loff_t off)
>>>>> 825 {
>>>>> 826 struct rdtgroup *rdtgrp;
>>>>> 827 int iommu_group_id;
>>>>> 828 bool is_iommu;
>>>>> 829 char *pid_str;
>>>>> 830 int ret = 0;
>>>>> 831 pid_t pid;
>>>>> 832
>>>>> 833 rdtgrp = rdtgroup_kn_lock_live(of->kn);
>>>>> 834 if (!rdtgrp) {
>>>>> 835 rdtgroup_kn_unlock(of->kn);
>>>>> 836 return -ENOENT;
>>>>> 837 }
>>>>> 838 rdt_last_cmd_clear();
>>>>> 839
>>>>> 840 if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED ||
>>>>> 841 rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
>>>>> 842 ret = -EINVAL;
>>>>> 843 rdt_last_cmd_puts("Pseudo-locking in progress\n");
>>>>> 844 goto unlock;
>>>>> 845 }
>>>>> 846
>>>>> 847 while (buf && buf[0] != '\0' && buf[0] != '\n') {
>>>>> 848 pid_str = strim(strsep(&buf, ","));
>>>>> 849
>>>>> 850 is_iommu = string_is_iommu_group(pid_str, &iommu_group_id);
>>>>>
>>>>> What puzzles me is why we would put it under 'task'—this seems a little
>>>>> strange to users.It seems they are not related.Why don't we add a new
>>>>> interface like 'iommu'?
>>>>
>>>> I think it is likely that this interface would change if upstream support is added.
>>>>
>>>
>>> I have done some work in this direction before, and I will release an
>>> RFC later for further discussion.:-)
>>
>> Looking forward to seeing it.
>>
>> Ben
>>
>
> Following the current SMMU approach, I've submitted several bugfix
> patches for the MPAM driver, but haven't received any review feedback
> yet.
>
> To avoid these being overlooked, I'd like to kindly remind to take a
> look:
> v2: https://lore.kernel.org/all/20260414032610.1523958-1-zengheng4@huawei.com/
> v1: https://lore.kernel.org/all/20251107063300.1580046-1-zengheng4@huawei.com/
>
> Additionally, I'd like to check on the status of this branch — is it
> still actively maintained? It would be helpful to understand the future
> plans for MPAM development.
The MPAM snapshot and extras branches are no longer maintained. Work on these has stopped so that we can focus on
upstream. Apologies for not making this clear earlier.
Thanks,
Ben
>
>
> Thanks for your time,
> Zeng Heng
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/2] bpf, arm64: Remove redundant bpf_flush_icache() after pack allocator finalize
From: Breno Leitao @ 2026-04-15 12:38 UTC (permalink / raw)
To: Puranjay Mohan
Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Xu Kuohai, Catalin Marinas,
Will Deacon, Luke Nelson, Xi Wang, Björn Töpel,
Pu Lehui, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, linux-arm-kernel, linux-riscv, linux-kernel
In-Reply-To: <20260413191111.3426023-2-puranjay@kernel.org>
On Mon, Apr 13, 2026 at 12:11:08PM -0700, Puranjay Mohan wrote:
> bpf_flush_icache() calls flush_icache_range() to clean the data cache
> and invalidate the instruction cache for the JITed code region. However,
> since commit 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory
> management"), this flush is redundant.
>
> bpf_jit_binary_pack_finalize() copies the JITed instructions to the ROX
> region via bpf_arch_text_copy() -> aarch64_insn_copy() -> __text_poke(),
> and __text_poke() already calls flush_icache_range() on the written
> range. The subsequent bpf_flush_icache() repeats the same cache
> maintenance on an overlapping range, including an unnecessary second
> synchronous IPI to all CPUs via kick_all_cpus_sync().
>
> Remove the redundant bpf_flush_icache() call and its now-unused
> definition.
>
> Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management")
> Acked-by: Song Liu <song@kernel.org>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Acked-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Add Broadcom channel priority commands
From: Sasha Finkelstein @ 2026-04-15 12:33 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-kernel, asahi, linux-arm-kernel,
linux-bluetooth, netdev
In-Reply-To: <CABBYNZJAEqwfTuVqbFAnx97HBSjcwn3Hb+y+r4r2C=MMPxFoDg@mail.gmail.com>
On Tue, 14 Apr 2026 at 16:00, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> > + if (sock)
> > + set_bit(SOCK_CUSTOM_SOCKOPT, &sock->flags);
>
> This is more complicated than it needs to be. I'd just add a new
> callback, `hdev->set_priority(handle, skb->priority)`, so the driver
> is called whenever it needs to elevate a connection's priority, that
> said there could be cases where a connection needs its priority set
> momentarily to transmit A2DP, followed by OBEX packets that are best
> effort. Therefore, `hci_conn` will probably need to track the priority
> so it can detect when it needs changing on a per skb basis.
I have tested per-skb priorities, and unfortunately, this does not work.
If something tries to send a low-priority packet (for example - a volume
adjustment), a priority drop causes the same kind of dropout that is
caused by scans. It appears that the only way to make this hardware work
is to set the entire hci connection as high priority for as long as it
is being used to transmit audio.
^ permalink raw reply
* Re: [PATCH v4 7/9] coresight: etm3x: introduce struct etm_caps
From: Jie Gan @ 2026-04-15 12:17 UTC (permalink / raw)
To: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel
Cc: suzuki.poulose, mike.leach, james.clark, alexander.shishkin,
leo.yan
In-Reply-To: <20260413142003.3549310-8-yeoreum.yun@arm.com>
On 4/13/2026 10:20 PM, Yeoreum Yun wrote:
> Introduce struct etm_caps to describe ETMv3 capabilities
> and move capabilities information into it.
>
> Since drvdata->etmccr and drvdata->etmccer are used to check
> whether it supports fifofull logic and timestamping,
> remove etmccr and etmccer field from drvdata and add relevant fields
> in etm_caps structure.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-etm.h | 42 ++++++++++++-------
> .../coresight/coresight-etm3x-core.c | 39 ++++++++++-------
> .../coresight/coresight-etm3x-sysfs.c | 29 ++++++++-----
> 3 files changed, 67 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
> index 40f20daded4f..8d1a1079b008 100644
> --- a/drivers/hwtracing/coresight/coresight-etm.h
> +++ b/drivers/hwtracing/coresight/coresight-etm.h
> @@ -140,6 +140,30 @@
> ETM_ADD_COMP_0 | \
> ETM_EVENT_NOT_A)
>
> +/**
> + * struct etmv_caps - specifics ETM capabilities
s/etmv_caps/etm_caps
Thanks,
Jie
> + * @port_size: port size as reported by ETMCR bit 4-6 and 21.
> + * @nr_addr_cmp:Number of pairs of address comparators as found in ETMCCR.
> + * @nr_cntr: Number of counters as found in ETMCCR bit 13-15.
> + * @nr_ext_inp: Number of external input as found in ETMCCR bit 17-19.
> + * @nr_ext_out: Number of external output as found in ETMCCR bit 20-22.
> + * @nr_ctxid_cmp: Number of contextID comparators as found in ETMCCR bit 24-25.
> + * @fifofull: FIFOFULL logic is present.
> + * @timestamp: Timestamping is implemented.
> + * @retstack: Return stack is implemented.
> + */
> +struct etm_caps {
> + int port_size;
> + u8 nr_addr_cmp;
> + u8 nr_cntr;
> + u8 nr_ext_inp;
> + u8 nr_ext_out;
> + u8 nr_ctxid_cmp;
> + bool fifofull : 1;
> + bool timestamp : 1;
> + bool retstack : 1;
> +};
> +
> /**
> * struct etm_config - configuration information related to an ETM
> * @mode: controls various modes supported by this ETM/PTM.
> @@ -212,19 +236,12 @@ struct etm_config {
> * @csdev: component vitals needed by the framework.
> * @spinlock: only one at a time pls.
> * @cpu: the cpu this component is affined to.
> - * @port_size: port size as reported by ETMCR bit 4-6 and 21.
> * @arch: ETM/PTM version number.
> + * @caps: ETM capabilities.
> * @use_cpu14: true if management registers need to be accessed via CP14.
> * @sticky_enable: true if ETM base configuration has been done.
> * @boot_enable:true if we should start tracing at boot time.
> * @os_unlock: true if access to management registers is allowed.
> - * @nr_addr_cmp:Number of pairs of address comparators as found in ETMCCR.
> - * @nr_cntr: Number of counters as found in ETMCCR bit 13-15.
> - * @nr_ext_inp: Number of external input as found in ETMCCR bit 17-19.
> - * @nr_ext_out: Number of external output as found in ETMCCR bit 20-22.
> - * @nr_ctxid_cmp: Number of contextID comparators as found in ETMCCR bit 24-25.
> - * @etmccr: value of register ETMCCR.
> - * @etmccer: value of register ETMCCER.
> * @traceid: value of the current ID for this component.
> * @config: structure holding configuration parameters.
> */
> @@ -234,19 +251,12 @@ struct etm_drvdata {
> struct coresight_device *csdev;
> raw_spinlock_t spinlock;
> int cpu;
> - int port_size;
> u8 arch;
> + struct etm_caps caps;
> bool use_cp14;
> bool sticky_enable;
> bool boot_enable;
> bool os_unlock;
> - u8 nr_addr_cmp;
> - u8 nr_cntr;
> - u8 nr_ext_inp;
> - u8 nr_ext_out;
> - u8 nr_ctxid_cmp;
> - u32 etmccr;
> - u32 etmccer;
> u32 traceid;
> struct etm_config config;
> };
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
> index 4a702b515733..e42ca346da91 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
> @@ -308,6 +308,7 @@ void etm_config_trace_mode(struct etm_config *config)
> static int etm_parse_event_config(struct etm_drvdata *drvdata,
> struct perf_event *event)
> {
> + const struct etm_caps *caps = &drvdata->caps;
> struct etm_config *config = &drvdata->config;
> struct perf_event_attr *attr = &event->attr;
> u8 ts_level;
> @@ -356,8 +357,7 @@ static int etm_parse_event_config(struct etm_drvdata *drvdata,
> * has ret stack) on the same SoC. So only enable when it can be honored
> * - trace will still continue normally otherwise.
> */
> - if (ATTR_CFG_GET_FLD(attr, retstack) &&
> - (drvdata->etmccer & ETMCCER_RETSTACK))
> + if (ATTR_CFG_GET_FLD(attr, retstack) && (caps->retstack))
> config->ctrl |= ETMCR_RETURN_STACK;
>
> return 0;
> @@ -367,6 +367,7 @@ static int etm_enable_hw(struct etm_drvdata *drvdata)
> {
> int i, rc;
> u32 etmcr;
> + const struct etm_caps *caps = &drvdata->caps;
> struct etm_config *config = &drvdata->config;
> struct coresight_device *csdev = drvdata->csdev;
>
> @@ -388,7 +389,7 @@ static int etm_enable_hw(struct etm_drvdata *drvdata)
> etmcr = etm_readl(drvdata, ETMCR);
> /* Clear setting from a previous run if need be */
> etmcr &= ~ETM3X_SUPPORTED_OPTIONS;
> - etmcr |= drvdata->port_size;
> + etmcr |= caps->port_size;
> etmcr |= ETMCR_ETM_EN;
> etm_writel(drvdata, config->ctrl | etmcr, ETMCR);
> etm_writel(drvdata, config->trigger_event, ETMTRIGGER);
> @@ -396,11 +397,11 @@ static int etm_enable_hw(struct etm_drvdata *drvdata)
> etm_writel(drvdata, config->enable_event, ETMTEEVR);
> etm_writel(drvdata, config->enable_ctrl1, ETMTECR1);
> etm_writel(drvdata, config->fifofull_level, ETMFFLR);
> - for (i = 0; i < drvdata->nr_addr_cmp; i++) {
> + for (i = 0; i < caps->nr_addr_cmp; i++) {
> etm_writel(drvdata, config->addr_val[i], ETMACVRn(i));
> etm_writel(drvdata, config->addr_acctype[i], ETMACTRn(i));
> }
> - for (i = 0; i < drvdata->nr_cntr; i++) {
> + for (i = 0; i < caps->nr_cntr; i++) {
> etm_writel(drvdata, config->cntr_rld_val[i], ETMCNTRLDVRn(i));
> etm_writel(drvdata, config->cntr_event[i], ETMCNTENRn(i));
> etm_writel(drvdata, config->cntr_rld_event[i],
> @@ -414,9 +415,9 @@ static int etm_enable_hw(struct etm_drvdata *drvdata)
> etm_writel(drvdata, config->seq_32_event, ETMSQ32EVR);
> etm_writel(drvdata, config->seq_13_event, ETMSQ13EVR);
> etm_writel(drvdata, config->seq_curr_state, ETMSQR);
> - for (i = 0; i < drvdata->nr_ext_out; i++)
> + for (i = 0; i < caps->nr_ext_out; i++)
> etm_writel(drvdata, ETM_DEFAULT_EVENT_VAL, ETMEXTOUTEVRn(i));
> - for (i = 0; i < drvdata->nr_ctxid_cmp; i++)
> + for (i = 0; i < caps->nr_ctxid_cmp; i++)
> etm_writel(drvdata, config->ctxid_pid[i], ETMCIDCVRn(i));
> etm_writel(drvdata, config->ctxid_mask, ETMCIDCMR);
> etm_writel(drvdata, config->sync_freq, ETMSYNCFR);
> @@ -563,6 +564,7 @@ static int etm_enable(struct coresight_device *csdev, struct perf_event *event,
> static void etm_disable_hw(struct etm_drvdata *drvdata)
> {
> int i;
> + const struct etm_caps *caps = &drvdata->caps;
> struct etm_config *config = &drvdata->config;
> struct coresight_device *csdev = drvdata->csdev;
>
> @@ -572,7 +574,7 @@ static void etm_disable_hw(struct etm_drvdata *drvdata)
> /* Read back sequencer and counters for post trace analysis */
> config->seq_curr_state = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
>
> - for (i = 0; i < drvdata->nr_cntr; i++)
> + for (i = 0; i < caps->nr_cntr; i++)
> config->cntr_val[i] = etm_readl(drvdata, ETMCNTVRn(i));
>
> etm_set_pwrdwn(drvdata);
> @@ -754,7 +756,9 @@ static void etm_init_arch_data(void *info)
> {
> u32 etmidr;
> u32 etmccr;
> + u32 etmccer;
> struct etm_drvdata *drvdata = info;
> + struct etm_caps *caps = &drvdata->caps;
>
> /* Make sure all registers are accessible */
> etm_os_unlock(drvdata);
> @@ -779,16 +783,19 @@ static void etm_init_arch_data(void *info)
> /* Find all capabilities */
> etmidr = etm_readl(drvdata, ETMIDR);
> drvdata->arch = BMVAL(etmidr, 4, 11);
> - drvdata->port_size = etm_readl(drvdata, ETMCR) & PORT_SIZE_MASK;
> + caps->port_size = etm_readl(drvdata, ETMCR) & PORT_SIZE_MASK;
> +
> + etmccer = etm_readl(drvdata, ETMCCER);
> + caps->timestamp = !!(etmccer & ETMCCER_TIMESTAMP);
> + caps->retstack = !!(etmccer & ETMCCER_RETSTACK);
>
> - drvdata->etmccer = etm_readl(drvdata, ETMCCER);
> etmccr = etm_readl(drvdata, ETMCCR);
> - drvdata->etmccr = etmccr;
> - drvdata->nr_addr_cmp = BMVAL(etmccr, 0, 3) * 2;
> - drvdata->nr_cntr = BMVAL(etmccr, 13, 15);
> - drvdata->nr_ext_inp = BMVAL(etmccr, 17, 19);
> - drvdata->nr_ext_out = BMVAL(etmccr, 20, 22);
> - drvdata->nr_ctxid_cmp = BMVAL(etmccr, 24, 25);
> + caps->fifofull = !!(etmccr & ETMCCR_FIFOFULL);
> + caps->nr_addr_cmp = BMVAL(etmccr, 0, 3) * 2;
> + caps->nr_cntr = BMVAL(etmccr, 13, 15);
> + caps->nr_ext_inp = BMVAL(etmccr, 17, 19);
> + caps->nr_ext_out = BMVAL(etmccr, 20, 22);
> + caps->nr_ctxid_cmp = BMVAL(etmccr, 24, 25);
>
> coresight_clear_self_claim_tag_unlocked(&drvdata->csa);
> etm_set_pwrdwn(drvdata);
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> index 42b12c33516b..f7330d830e21 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> @@ -15,8 +15,9 @@ static ssize_t nr_addr_cmp_show(struct device *dev,
> {
> unsigned long val;
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + const struct etm_caps *caps = &drvdata->caps;
>
> - val = drvdata->nr_addr_cmp;
> + val = caps->nr_addr_cmp;
> return sprintf(buf, "%#lx\n", val);
> }
> static DEVICE_ATTR_RO(nr_addr_cmp);
> @@ -25,8 +26,9 @@ static ssize_t nr_cntr_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> { unsigned long val;
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + const struct etm_caps *caps = &drvdata->caps;
>
> - val = drvdata->nr_cntr;
> + val = caps->nr_cntr;
> return sprintf(buf, "%#lx\n", val);
> }
> static DEVICE_ATTR_RO(nr_cntr);
> @@ -37,7 +39,7 @@ static ssize_t nr_ctxid_cmp_show(struct device *dev,
> unsigned long val;
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>
> - val = drvdata->nr_ctxid_cmp;
> + val = drvdata->caps.nr_ctxid_cmp;
> return sprintf(buf, "%#lx\n", val);
> }
> static DEVICE_ATTR_RO(nr_ctxid_cmp);
> @@ -80,7 +82,7 @@ static ssize_t reset_store(struct device *dev,
> memset(config, 0, sizeof(struct etm_config));
> config->mode = ETM_MODE_EXCLUDE;
> config->trigger_event = ETM_DEFAULT_EVENT_VAL;
> - for (i = 0; i < drvdata->nr_addr_cmp; i++) {
> + for (i = 0; i < drvdata->caps.nr_addr_cmp; i++) {
> config->addr_type[i] = ETM_ADDR_TYPE_NONE;
> }
>
> @@ -111,6 +113,7 @@ static ssize_t mode_store(struct device *dev,
> int ret;
> unsigned long val;
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + const struct etm_caps *caps = &drvdata->caps;
> struct etm_config *config = &drvdata->config;
>
> ret = kstrtoul(buf, 16, &val);
> @@ -131,7 +134,7 @@ static ssize_t mode_store(struct device *dev,
> config->ctrl &= ~ETMCR_CYC_ACC;
>
> if (config->mode & ETM_MODE_STALL) {
> - if (!(drvdata->etmccr & ETMCCR_FIFOFULL)) {
> + if (!caps->fifofull) {
> dev_warn(dev, "stall mode not supported\n");
> ret = -EINVAL;
> goto err_unlock;
> @@ -141,7 +144,7 @@ static ssize_t mode_store(struct device *dev,
> config->ctrl &= ~ETMCR_STALL_MODE;
>
> if (config->mode & ETM_MODE_TIMESTAMP) {
> - if (!(drvdata->etmccer & ETMCCER_TIMESTAMP)) {
> + if (!caps->timestamp) {
> dev_warn(dev, "timestamp not supported\n");
> ret = -EINVAL;
> goto err_unlock;
> @@ -286,13 +289,14 @@ static ssize_t addr_idx_store(struct device *dev,
> int ret;
> unsigned long val;
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + const struct etm_caps *caps = &drvdata->caps;
> struct etm_config *config = &drvdata->config;
>
> ret = kstrtoul(buf, 16, &val);
> if (ret)
> return ret;
>
> - if (val >= drvdata->nr_addr_cmp)
> + if (val >= caps->nr_addr_cmp)
> return -EINVAL;
>
> /*
> @@ -589,13 +593,14 @@ static ssize_t cntr_idx_store(struct device *dev,
> int ret;
> unsigned long val;
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + const struct etm_caps *caps = &drvdata->caps;
> struct etm_config *config = &drvdata->config;
>
> ret = kstrtoul(buf, 16, &val);
> if (ret)
> return ret;
>
> - if (val >= drvdata->nr_cntr)
> + if (val >= caps->nr_cntr)
> return -EINVAL;
> /*
> * Use spinlock to ensure index doesn't change while it gets
> @@ -720,18 +725,19 @@ static ssize_t cntr_val_show(struct device *dev,
> int i, ret = 0;
> u32 val;
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + const struct etm_caps *caps = &drvdata->caps;
> struct etm_config *config = &drvdata->config;
>
> if (!coresight_get_mode(drvdata->csdev)) {
> raw_spin_lock(&drvdata->spinlock);
> - for (i = 0; i < drvdata->nr_cntr; i++)
> + for (i = 0; i < caps->nr_cntr; i++)
> ret += sprintf(buf, "counter %d: %x\n",
> i, config->cntr_val[i]);
> raw_spin_unlock(&drvdata->spinlock);
> return ret;
> }
>
> - for (i = 0; i < drvdata->nr_cntr; i++) {
> + for (i = 0; i < caps->nr_cntr; i++) {
> val = etm_readl(drvdata, ETMCNTVRn(i));
> ret += sprintf(buf, "counter %d: %x\n", i, val);
> }
> @@ -999,13 +1005,14 @@ static ssize_t ctxid_idx_store(struct device *dev,
> int ret;
> unsigned long val;
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + const struct etm_caps *caps = &drvdata->caps;
> struct etm_config *config = &drvdata->config;
>
> ret = kstrtoul(buf, 16, &val);
> if (ret)
> return ret;
>
> - if (val >= drvdata->nr_ctxid_cmp)
> + if (val >= caps->nr_ctxid_cmp)
> return -EINVAL;
>
> /*
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: airoha: en7581: Enable spi nand controller for EN7581 EVB
From: Lorenzo Bianconi @ 2026-04-15 12:12 UTC (permalink / raw)
To: Benjamin Larsson
Cc: Christian Marangi (Ansuel), Matthias Brugger,
AngeloGioacchino Del Regno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-kernel, linux-mediatek, devicetree,
Arnd Bergmann
In-Reply-To: <ab5bab39-88be-4f58-aee6-2bb0dc49a732@genexis.eu>
[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]
>
> On 4/15/26 11:47, Christian Marangi (Ansuel) wrote:
> > Il giorno mar 10 mar 2026 alle ore 18:07 Lorenzo Bianconi
> > <lorenzo@kernel.org> ha scritto:
> > > > Enable spi controller used for snand memory device for EN7581 evaluation
> > > > board.
> > > >
> > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > Hi all,
> > >
> > > it seems this patch has been reviewed by AngeloGioacchino, but it has never
> > > been applied to linux-mediatek tree (or at least I can't find it). It is marked
> > > as 'New, archived' in patchwork [0]. Am I missing something?
> > >
> > > Regards,
> > > Lorenzo
> > >
> > > [0] https://patchwork.kernel.org/project/linux-mediatek/patch/20250225-en7581-snfi-probe-fix-v2-1-92e35add701b@kernel.org/
> > >
> > Hi,
> >
> > friendly ping here. There are lots of patch with review tag and ACK
> > also for 7583.
> >
> > Any chance someone can ping maintainers that take care of picking these patch?
> > Or someone that can reply on how to handle this? Maybe we need to sync with
> > them? Lorenzo (and also me) are fully maintaining the Airoha ARM target also on
> > U-Boot. Also on OpenWrt this target is starting to get traction and is
> > getting used
> > there, so Airoha is not considered an abandoned target anymore.
>
> I think the following Airoha patch set has not been picked up either:
>
> [PATCH RESEND v3 0/2] ARM: dts: airoha: en7523: update dts
>
> MvH
>
> Benjamin Larsson
>
ack. Thx Ben for pointing this out.
It is not clear to me if these patches should go via linux-mediatek tree.
@AngeloGioacchino @Matthias: any input about it?
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: airoha: en7581: Enable spi nand controller for EN7581 EVB
From: Benjamin Larsson @ 2026-04-15 12:09 UTC (permalink / raw)
To: Christian Marangi (Ansuel), Lorenzo Bianconi
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
linux-mediatek, devicetree
In-Reply-To: <CA+_ehUyfP7bohsSZEbjp-KLxD084NcR+2SmhDNrpoKQE=BiHcQ@mail.gmail.com>
On 4/15/26 11:47, Christian Marangi (Ansuel) wrote:
> Il giorno mar 10 mar 2026 alle ore 18:07 Lorenzo Bianconi
> <lorenzo@kernel.org> ha scritto:
>>> Enable spi controller used for snand memory device for EN7581 evaluation
>>> board.
>>>
>>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>> Hi all,
>>
>> it seems this patch has been reviewed by AngeloGioacchino, but it has never
>> been applied to linux-mediatek tree (or at least I can't find it). It is marked
>> as 'New, archived' in patchwork [0]. Am I missing something?
>>
>> Regards,
>> Lorenzo
>>
>> [0] https://patchwork.kernel.org/project/linux-mediatek/patch/20250225-en7581-snfi-probe-fix-v2-1-92e35add701b@kernel.org/
>>
> Hi,
>
> friendly ping here. There are lots of patch with review tag and ACK
> also for 7583.
>
> Any chance someone can ping maintainers that take care of picking these patch?
> Or someone that can reply on how to handle this? Maybe we need to sync with
> them? Lorenzo (and also me) are fully maintaining the Airoha ARM target also on
> U-Boot. Also on OpenWrt this target is starting to get traction and is
> getting used
> there, so Airoha is not considered an abandoned target anymore.
I think the following Airoha patch set has not been picked up either:
[PATCH RESEND v3 0/2] ARM: dts: airoha: en7523: update dts
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH v4 6/9] coresight: etm3x: change drvdata->spinlock type to raw_spin_lock_t
From: Jie Gan @ 2026-04-15 12:05 UTC (permalink / raw)
To: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel
Cc: suzuki.poulose, mike.leach, james.clark, alexander.shishkin,
leo.yan
In-Reply-To: <20260413142003.3549310-7-yeoreum.yun@arm.com>
On 4/13/2026 10:19 PM, Yeoreum Yun wrote:
> etm_starting_cpu()/etm_dying_cpu() are called in not sleepable context.
> This poses an issue in PREEMPT_RT kernel where spinlock_t is sleepable.
>
> To address this, change etm3's drvdata->spinlock type to raw_spin_lock_t.
> This will be good to align with etm4x.
>
LGTM
Reviewed-by: Jie Gan <jie.gan@oss.qualcomm.com>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-etm.h | 2 +-
> .../coresight/coresight-etm3x-core.c | 18 +--
> .../coresight/coresight-etm3x-sysfs.c | 130 +++++++++---------
> 3 files changed, 75 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
> index 1d753cca2943..40f20daded4f 100644
> --- a/drivers/hwtracing/coresight/coresight-etm.h
> +++ b/drivers/hwtracing/coresight/coresight-etm.h
> @@ -232,7 +232,7 @@ struct etm_drvdata {
> struct csdev_access csa;
> struct clk *atclk;
> struct coresight_device *csdev;
> - spinlock_t spinlock;
> + raw_spinlock_t spinlock;
> int cpu;
> int port_size;
> u8 arch;
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
> index a547a6d2e0bd..4a702b515733 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
> @@ -511,7 +511,7 @@ static int etm_enable_sysfs(struct coresight_device *csdev, struct coresight_pat
> struct etm_enable_arg arg = { };
> int ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
>
> drvdata->traceid = path->trace_id;
>
> @@ -534,7 +534,7 @@ static int etm_enable_sysfs(struct coresight_device *csdev, struct coresight_pat
> if (ret)
> etm_release_trace_id(drvdata);
>
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> if (!ret)
> dev_dbg(&csdev->dev, "ETM tracing enabled\n");
> @@ -634,7 +634,7 @@ static void etm_disable_sysfs(struct coresight_device *csdev)
> * DYING hotplug callback is serviced by the ETM driver.
> */
> cpus_read_lock();
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
>
> /*
> * Executing etm_disable_hw on the cpu whose ETM is being disabled
> @@ -643,7 +643,7 @@ static void etm_disable_sysfs(struct coresight_device *csdev)
> smp_call_function_single(drvdata->cpu, etm_disable_sysfs_smp_call,
> drvdata, 1);
>
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> cpus_read_unlock();
>
> /*
> @@ -709,7 +709,7 @@ static int etm_starting_cpu(unsigned int cpu)
> if (!etmdrvdata[cpu])
> return 0;
>
> - spin_lock(&etmdrvdata[cpu]->spinlock);
> + raw_spin_lock(&etmdrvdata[cpu]->spinlock);
> if (!etmdrvdata[cpu]->os_unlock) {
> etm_os_unlock(etmdrvdata[cpu]);
> etmdrvdata[cpu]->os_unlock = true;
> @@ -717,7 +717,7 @@ static int etm_starting_cpu(unsigned int cpu)
>
> if (coresight_get_mode(etmdrvdata[cpu]->csdev))
> etm_enable_hw(etmdrvdata[cpu]);
> - spin_unlock(&etmdrvdata[cpu]->spinlock);
> + raw_spin_unlock(&etmdrvdata[cpu]->spinlock);
> return 0;
> }
>
> @@ -726,10 +726,10 @@ static int etm_dying_cpu(unsigned int cpu)
> if (!etmdrvdata[cpu])
> return 0;
>
> - spin_lock(&etmdrvdata[cpu]->spinlock);
> + raw_spin_lock(&etmdrvdata[cpu]->spinlock);
> if (coresight_get_mode(etmdrvdata[cpu]->csdev))
> etm_disable_hw(etmdrvdata[cpu]);
> - spin_unlock(&etmdrvdata[cpu]->spinlock);
> + raw_spin_unlock(&etmdrvdata[cpu]->spinlock);
> return 0;
> }
>
> @@ -856,7 +856,7 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
>
> desc.access = drvdata->csa = CSDEV_ACCESS_IOMEM(base);
>
> - spin_lock_init(&drvdata->spinlock);
> + raw_spin_lock_init(&drvdata->spinlock);
>
> drvdata->atclk = devm_clk_get_optional_enabled(dev, "atclk");
> if (IS_ERR(drvdata->atclk))
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> index 762109307b86..42b12c33516b 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> @@ -49,13 +49,13 @@ static ssize_t etmsr_show(struct device *dev,
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>
> pm_runtime_get_sync(dev->parent);
> - spin_lock_irqsave(&drvdata->spinlock, flags);
> + raw_spin_lock_irqsave(&drvdata->spinlock, flags);
> CS_UNLOCK(drvdata->csa.base);
>
> val = etm_readl(drvdata, ETMSR);
>
> CS_LOCK(drvdata->csa.base);
> - spin_unlock_irqrestore(&drvdata->spinlock, flags);
> + raw_spin_unlock_irqrestore(&drvdata->spinlock, flags);
> pm_runtime_put(dev->parent);
>
> return sprintf(buf, "%#lx\n", val);
> @@ -76,7 +76,7 @@ static ssize_t reset_store(struct device *dev,
> return ret;
>
> if (val) {
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> memset(config, 0, sizeof(struct etm_config));
> config->mode = ETM_MODE_EXCLUDE;
> config->trigger_event = ETM_DEFAULT_EVENT_VAL;
> @@ -86,7 +86,7 @@ static ssize_t reset_store(struct device *dev,
>
> etm_set_default(config);
> etm_release_trace_id(drvdata);
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> }
>
> return size;
> @@ -117,7 +117,7 @@ static ssize_t mode_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->mode = val & ETM_MODE_ALL;
>
> if (config->mode & ETM_MODE_EXCLUDE)
> @@ -168,12 +168,12 @@ static ssize_t mode_store(struct device *dev,
> if (config->mode & (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
> etm_config_trace_mode(config);
>
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
>
> err_unlock:
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return ret;
> }
> static DEVICE_ATTR_RW(mode);
> @@ -299,9 +299,9 @@ static ssize_t addr_idx_store(struct device *dev,
> * Use spinlock to ensure index doesn't change while it gets
> * dereferenced multiple times within a spinlock block elsewhere.
> */
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->addr_idx = val;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -315,16 +315,16 @@ static ssize_t addr_single_show(struct device *dev,
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etm_config *config = &drvdata->config;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> idx = config->addr_idx;
> if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
> config->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EINVAL;
> }
>
> val = config->addr_val[idx];
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return sprintf(buf, "%#lx\n", val);
> }
> @@ -343,17 +343,17 @@ static ssize_t addr_single_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> idx = config->addr_idx;
> if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
> config->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EINVAL;
> }
>
> config->addr_val[idx] = val;
> config->addr_type[idx] = ETM_ADDR_TYPE_SINGLE;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -367,23 +367,23 @@ static ssize_t addr_range_show(struct device *dev,
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etm_config *config = &drvdata->config;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> idx = config->addr_idx;
> if (idx % 2 != 0) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EPERM;
> }
> if (!((config->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
> config->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
> (config->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
> config->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EPERM;
> }
>
> val1 = config->addr_val[idx];
> val2 = config->addr_val[idx + 1];
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return sprintf(buf, "%#lx %#lx\n", val1, val2);
> }
> @@ -403,17 +403,17 @@ static ssize_t addr_range_store(struct device *dev,
> if (val1 > val2)
> return -EINVAL;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> idx = config->addr_idx;
> if (idx % 2 != 0) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EPERM;
> }
> if (!((config->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
> config->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
> (config->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
> config->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EPERM;
> }
>
> @@ -422,7 +422,7 @@ static ssize_t addr_range_store(struct device *dev,
> config->addr_val[idx + 1] = val2;
> config->addr_type[idx + 1] = ETM_ADDR_TYPE_RANGE;
> config->enable_ctrl1 |= (1 << (idx/2));
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -436,16 +436,16 @@ static ssize_t addr_start_show(struct device *dev,
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etm_config *config = &drvdata->config;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> idx = config->addr_idx;
> if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
> config->addr_type[idx] == ETM_ADDR_TYPE_START)) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EPERM;
> }
>
> val = config->addr_val[idx];
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return sprintf(buf, "%#lx\n", val);
> }
> @@ -464,11 +464,11 @@ static ssize_t addr_start_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> idx = config->addr_idx;
> if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
> config->addr_type[idx] == ETM_ADDR_TYPE_START)) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EPERM;
> }
>
> @@ -476,7 +476,7 @@ static ssize_t addr_start_store(struct device *dev,
> config->addr_type[idx] = ETM_ADDR_TYPE_START;
> config->startstop_ctrl |= (1 << idx);
> config->enable_ctrl1 |= ETMTECR1_START_STOP;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -490,16 +490,16 @@ static ssize_t addr_stop_show(struct device *dev,
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etm_config *config = &drvdata->config;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> idx = config->addr_idx;
> if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
> config->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EPERM;
> }
>
> val = config->addr_val[idx];
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return sprintf(buf, "%#lx\n", val);
> }
> @@ -518,11 +518,11 @@ static ssize_t addr_stop_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> idx = config->addr_idx;
> if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
> config->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return -EPERM;
> }
>
> @@ -530,7 +530,7 @@ static ssize_t addr_stop_store(struct device *dev,
> config->addr_type[idx] = ETM_ADDR_TYPE_STOP;
> config->startstop_ctrl |= (1 << (idx + 16));
> config->enable_ctrl1 |= ETMTECR1_START_STOP;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -543,9 +543,9 @@ static ssize_t addr_acctype_show(struct device *dev,
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etm_config *config = &drvdata->config;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> val = config->addr_acctype[config->addr_idx];
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return sprintf(buf, "%#lx\n", val);
> }
> @@ -563,9 +563,9 @@ static ssize_t addr_acctype_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->addr_acctype[config->addr_idx] = val;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -601,9 +601,9 @@ static ssize_t cntr_idx_store(struct device *dev,
> * Use spinlock to ensure index doesn't change while it gets
> * dereferenced multiple times within a spinlock block elsewhere.
> */
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->cntr_idx = val;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -616,9 +616,9 @@ static ssize_t cntr_rld_val_show(struct device *dev,
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etm_config *config = &drvdata->config;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> val = config->cntr_rld_val[config->cntr_idx];
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return sprintf(buf, "%#lx\n", val);
> }
> @@ -636,9 +636,9 @@ static ssize_t cntr_rld_val_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->cntr_rld_val[config->cntr_idx] = val;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -651,9 +651,9 @@ static ssize_t cntr_event_show(struct device *dev,
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etm_config *config = &drvdata->config;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> val = config->cntr_event[config->cntr_idx];
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return sprintf(buf, "%#lx\n", val);
> }
> @@ -671,9 +671,9 @@ static ssize_t cntr_event_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->cntr_event[config->cntr_idx] = val & ETM_EVENT_MASK;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -686,9 +686,9 @@ static ssize_t cntr_rld_event_show(struct device *dev,
> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etm_config *config = &drvdata->config;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> val = config->cntr_rld_event[config->cntr_idx];
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return sprintf(buf, "%#lx\n", val);
> }
> @@ -706,9 +706,9 @@ static ssize_t cntr_rld_event_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->cntr_rld_event[config->cntr_idx] = val & ETM_EVENT_MASK;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -723,11 +723,11 @@ static ssize_t cntr_val_show(struct device *dev,
> struct etm_config *config = &drvdata->config;
>
> if (!coresight_get_mode(drvdata->csdev)) {
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> for (i = 0; i < drvdata->nr_cntr; i++)
> ret += sprintf(buf, "counter %d: %x\n",
> i, config->cntr_val[i]);
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
> return ret;
> }
>
> @@ -752,9 +752,9 @@ static ssize_t cntr_val_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->cntr_val[config->cntr_idx] = val;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -947,13 +947,13 @@ static ssize_t seq_curr_state_show(struct device *dev,
> }
>
> pm_runtime_get_sync(dev->parent);
> - spin_lock_irqsave(&drvdata->spinlock, flags);
> + raw_spin_lock_irqsave(&drvdata->spinlock, flags);
>
> CS_UNLOCK(drvdata->csa.base);
> val = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
> CS_LOCK(drvdata->csa.base);
>
> - spin_unlock_irqrestore(&drvdata->spinlock, flags);
> + raw_spin_unlock_irqrestore(&drvdata->spinlock, flags);
> pm_runtime_put(dev->parent);
> out:
> return sprintf(buf, "%#lx\n", val);
> @@ -1012,9 +1012,9 @@ static ssize_t ctxid_idx_store(struct device *dev,
> * Use spinlock to ensure index doesn't change while it gets
> * dereferenced multiple times within a spinlock block elsewhere.
> */
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->ctxid_idx = val;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
> @@ -1034,9 +1034,9 @@ static ssize_t ctxid_pid_show(struct device *dev,
> if (task_active_pid_ns(current) != &init_pid_ns)
> return -EINVAL;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> val = config->ctxid_pid[config->ctxid_idx];
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return sprintf(buf, "%#lx\n", val);
> }
> @@ -1066,9 +1066,9 @@ static ssize_t ctxid_pid_store(struct device *dev,
> if (ret)
> return ret;
>
> - spin_lock(&drvdata->spinlock);
> + raw_spin_lock(&drvdata->spinlock);
> config->ctxid_pid[config->ctxid_idx] = pid;
> - spin_unlock(&drvdata->spinlock);
> + raw_spin_unlock(&drvdata->spinlock);
>
> return size;
> }
^ permalink raw reply
* Re: [PATCH v4 5/9] coresight: etm4x: remove redundant call etm4_enable_hw() with hotplug
From: Jie Gan @ 2026-04-15 11:59 UTC (permalink / raw)
To: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel
Cc: suzuki.poulose, mike.leach, james.clark, alexander.shishkin,
leo.yan
In-Reply-To: <20260413142003.3549310-6-yeoreum.yun@arm.com>
On 4/13/2026 10:19 PM, Yeoreum Yun wrote:
> The cpu_online_mask is set at the CPUHP_BRINGUP_CPU step.
> In other words, if etm4_enable_sysfs() is called between
> CPUHP_BRINGUP_CPU and CPUHP_AP_ARM_CORESIGHT_STARTING,
> etm4_enable_hw() may be invoked in etm4_enable_sysfs_smp_call()
> and then executed again in etm4_starting_cpu().
>
> To remove this redundant call, take the hotplug lock before executing
> etm4_enable_sysfs_smp_call().
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-etm4x-core.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 01099689525b..facd5a306228 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -959,8 +959,20 @@ static int etm4_enable_sysfs(struct coresight_device *csdev, struct coresight_pa
> arg.config = drvdata->config;
> raw_spin_unlock(&drvdata->spinlock);
>
> + /*
> + * Take the hotplug lock to prevent redundant calls to etm4_enable_hw().
> + *
> + * The cpu_online_mask is set at the CPUHP_BRINGUP_CPU step.
> + * In other words, if etm4_enable_sysfs() is called between
> + * CPUHP_BRINGUP_CPU and CPUHP_AP_ARM_CORESIGHT_STARTING,
> + * etm4_enable_hw() may be invoked in etm4_enable_sysfs_smp_call()
> + * and then executed again in etm4_starting_cpu().
> + */
> + cpus_read_lock();
> ret = smp_call_function_single(drvdata->cpu,
> etm4_enable_sysfs_smp_call, &arg, 1);
> + cpus_read_unlock();
> +
> if (!ret)
> ret = arg.rc;
> if (!ret)
Reviewed-by: Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 15/18] Documentation: KVM: Fix typos in VGICv5 documentation
From: Marc Zyngier @ 2026-04-15 11:55 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff
In-Reply-To: <20260415115559.2227718-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
Fix two typos in the VGICv5 documentation.
Fixes: d51c978b7d3e ("KVM: arm64: gic-v5: Communicate userspace-driveable PPIs via a UAPI")
Fixes: eb3c4d2c9a4d ("Documentation: KVM: Introduce documentation for VGICv5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
Documentation/virt/kvm/devices/arm-vgic-v5.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/virt/kvm/devices/arm-vgic-v5.rst b/Documentation/virt/kvm/devices/arm-vgic-v5.rst
index 29335ea823fc5..1985b2d880322 100644
--- a/Documentation/virt/kvm/devices/arm-vgic-v5.rst
+++ b/Documentation/virt/kvm/devices/arm-vgic-v5.rst
@@ -12,8 +12,8 @@ Only one VGIC instance may be instantiated through this API. The created VGIC
will act as the VM interrupt controller, requiring emulated user-space devices
to inject interrupts to the VGIC instead of directly to CPUs.
-Creating a guest GICv5 device requires a host GICv5 host. The current VGICv5
-device only supports PPI interrupts. These can either be injected from emulated
+Creating a guest GICv5 device requires a GICv5 host. The current VGICv5 device
+only supports PPI interrupts. These can either be injected from emulated
in-kernel devices (such as the Arch Timer, or PMU), or via the KVM_IRQ_LINE
ioctl.
@@ -25,7 +25,7 @@ Groups:
request the initialization of the VGIC, no additional parameter in
kvm_device_attr.addr. Must be called after all VCPUs have been created.
- KVM_DEV_ARM_VGIC_USERPSPACE_PPIs
+ KVM_DEV_ARM_VGIC_USERPSPACE_PPIS
request the mask of userspace-drivable PPIs. Only a subset of the PPIs can
be directly driven from userspace with GICv5, and the returned mask
informs userspace of which it is allowed to drive via KVM_IRQ_LINE.
--
2.47.3
^ permalink raw reply related
* [PATCH 12/18] KVM: arm64: selftests: Add missing GIC CDEN to no-vgic-v5 selftest
From: Marc Zyngier @ 2026-04-15 11:55 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff
In-Reply-To: <20260415115559.2227718-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
The selftest mistakenly omitted the GIC CDEN instruction from the
testing. Add it in.
Fixes: ce29261ec648 ("KVM: arm64: selftests: Add no-vgic-v5 selftest")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
tools/testing/selftests/kvm/arm64/no-vgic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/kvm/arm64/no-vgic.c b/tools/testing/selftests/kvm/arm64/no-vgic.c
index b14686ef17d12..e09e3fac904f4 100644
--- a/tools/testing/selftests/kvm/arm64/no-vgic.c
+++ b/tools/testing/selftests/kvm/arm64/no-vgic.c
@@ -159,6 +159,7 @@ static void guest_code_gicv5(void)
check_gicv5_gic_op(CDAFF);
check_gicv5_gic_op(CDDI);
check_gicv5_gic_op(CDDIS);
+ check_gicv5_gic_op(CDEN);
check_gicv5_gic_op(CDEOI);
check_gicv5_gic_op(CDHM);
check_gicv5_gic_op(CDPEND);
--
2.47.3
^ permalink raw reply related
* [PATCH 17/18] irqchip/gic-v5: Immediately exec priority drop following activate
From: Marc Zyngier @ 2026-04-15 11:55 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff
In-Reply-To: <20260415115559.2227718-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
With GICv5 an interrupt of equal or lower priority cannot be signalled
until there has been a priority drop. This is done via the GIC CDEOI
system instruction. Once this has been executed, the hardware is able
to signal the next interrupt if there is one.
As all interrupts are programmed to have the same priority, no new
interrupts can be signalled until the priority drop has happened. This
can cause issues when, for example, an interrupt remains active while
a long running process takes place, such as when injecting a physical
interrupt into a guest VM in software.
The GICv5 driver has so far done the priority drop as part of
irq_eoi(), i.e., at the same time as deactivating the interrupt. This
means that any long running process (or VM) could block incoming
interrupts, effectively causing a denial of service for all other
interrupts.
Rather than doing the EOI as part of irq_eoi() (which the name would
suggest would be a good place for it), move it to happen immediately
after acknowledging an interrupt in the main GICv5 interrupt
handler. The deactivation of interrupts (GIC CDDI) remains implemented
as part of irq_eoi(), which means that the same interrupt cannot be
signalled a second time until deactivated by software.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v5.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
index 6b0903be8ebfd..58e457d4c1476 100644
--- a/drivers/irqchip/irq-gic-v5.c
+++ b/drivers/irqchip/irq-gic-v5.c
@@ -218,17 +218,13 @@ static void gicv5_hwirq_eoi(u32 hwirq_id, u8 hwirq_type)
FIELD_PREP(GICV5_GIC_CDDI_TYPE_MASK, hwirq_type);
gic_insn(cddi, CDDI);
-
- gic_insn(0, CDEOI);
}
static void gicv5_ppi_irq_eoi(struct irq_data *d)
{
/* Skip deactivate for forwarded PPI interrupts */
- if (irqd_is_forwarded_to_vcpu(d)) {
- gic_insn(0, CDEOI);
+ if (irqd_is_forwarded_to_vcpu(d))
return;
- }
gicv5_hwirq_eoi(d->hwirq, GICV5_HWIRQ_TYPE_PPI);
}
@@ -963,6 +959,13 @@ static void __exception_irq_entry gicv5_handle_irq(struct pt_regs *regs)
*/
isb();
+ /*
+ * Ensure that we can receive the next interrupts in the event that we
+ * have a long running handler or directly enter a guest by doing the
+ * priority drop immediately.
+ */
+ gic_insn(0, CDEOI);
+
hwirq = FIELD_GET(GICV5_HWIRQ_INTID, ia);
handle_irq_per_domain(hwirq);
--
2.47.3
^ permalink raw reply related
* [PATCH 09/18] KVM: arm64: vgic-v5: Limit support to 64 PPIs
From: Marc Zyngier @ 2026-04-15 11:55 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff
In-Reply-To: <20260415115559.2227718-1-maz@kernel.org>
Although we have some code supporting 128 PPIs, the only supported
configuration is 64 PPIs. There is no way to test the 128 PPI code,
so it is bound to bitrot very quickly.
Given that KVM/arm64's goal has always been to stick to non-IMPDEF
behaviours, drop the 128 PPI support. Someone motivated enough and
with very strong arguments can always bring it back -- it's all in
the git history.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/hyp/vgic-v5-sr.c | 82 ++++++---------------------
arch/arm64/kvm/sys_regs.c | 17 +++---
arch/arm64/kvm/vgic/vgic-kvm-device.c | 9 +--
3 files changed, 26 insertions(+), 82 deletions(-)
diff --git a/arch/arm64/kvm/hyp/vgic-v5-sr.c b/arch/arm64/kvm/hyp/vgic-v5-sr.c
index 47e6bcd437029..6d69dfe89a96c 100644
--- a/arch/arm64/kvm/hyp/vgic-v5-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v5-sr.c
@@ -30,10 +30,9 @@ void __vgic_v5_save_ppi_state(struct vgic_v5_cpu_if *cpu_if)
{
/*
* The following code assumes that the bitmap storage that we have for
- * PPIs is either 64 (architected PPIs, only) or 128 bits (architected &
- * impdef PPIs).
+ * PPIs is either 64 (architected PPIs, only).
*/
- BUILD_BUG_ON(VGIC_V5_NR_PRIVATE_IRQS % 64);
+ BUILD_BUG_ON(VGIC_V5_NR_PRIVATE_IRQS != 64);
bitmap_write(host_data_ptr(vgic_v5_ppi_state)->activer_exit,
read_sysreg_s(SYS_ICH_PPI_ACTIVER0_EL2), 0, 64);
@@ -49,22 +48,6 @@ void __vgic_v5_save_ppi_state(struct vgic_v5_cpu_if *cpu_if)
cpu_if->vgic_ppi_priorityr[6] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR6_EL2);
cpu_if->vgic_ppi_priorityr[7] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR7_EL2);
- if (VGIC_V5_NR_PRIVATE_IRQS == 128) {
- bitmap_write(host_data_ptr(vgic_v5_ppi_state)->activer_exit,
- read_sysreg_s(SYS_ICH_PPI_ACTIVER1_EL2), 64, 64);
- bitmap_write(host_data_ptr(vgic_v5_ppi_state)->pendr,
- read_sysreg_s(SYS_ICH_PPI_PENDR1_EL2), 64, 64);
-
- cpu_if->vgic_ppi_priorityr[8] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR8_EL2);
- cpu_if->vgic_ppi_priorityr[9] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR9_EL2);
- cpu_if->vgic_ppi_priorityr[10] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR10_EL2);
- cpu_if->vgic_ppi_priorityr[11] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR11_EL2);
- cpu_if->vgic_ppi_priorityr[12] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR12_EL2);
- cpu_if->vgic_ppi_priorityr[13] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR13_EL2);
- cpu_if->vgic_ppi_priorityr[14] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR14_EL2);
- cpu_if->vgic_ppi_priorityr[15] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR15_EL2);
- }
-
/* Now that we are done, disable DVI */
write_sysreg_s(0, SYS_ICH_PPI_DVIR0_EL2);
write_sysreg_s(0, SYS_ICH_PPI_DVIR1_EL2);
@@ -74,9 +57,6 @@ void __vgic_v5_restore_ppi_state(struct vgic_v5_cpu_if *cpu_if)
{
DECLARE_BITMAP(pendr, VGIC_V5_NR_PRIVATE_IRQS);
- /* We assume 64 or 128 PPIs - see above comment */
- BUILD_BUG_ON(VGIC_V5_NR_PRIVATE_IRQS % 64);
-
/* Enable DVI so that the guest's interrupt config takes over */
write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_dvir, 0, 64),
SYS_ICH_PPI_DVIR0_EL2);
@@ -108,50 +88,20 @@ void __vgic_v5_restore_ppi_state(struct vgic_v5_cpu_if *cpu_if)
write_sysreg_s(cpu_if->vgic_ppi_priorityr[7],
SYS_ICH_PPI_PRIORITYR7_EL2);
- if (VGIC_V5_NR_PRIVATE_IRQS == 128) {
- /* Enable DVI so that the guest's interrupt config takes over */
- write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_dvir, 64, 64),
- SYS_ICH_PPI_DVIR1_EL2);
-
- write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_activer, 64, 64),
- SYS_ICH_PPI_ACTIVER1_EL2);
- write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_enabler, 64, 64),
- SYS_ICH_PPI_ENABLER1_EL2);
- write_sysreg_s(bitmap_read(pendr, 64, 64),
- SYS_ICH_PPI_PENDR1_EL2);
-
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[8],
- SYS_ICH_PPI_PRIORITYR8_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[9],
- SYS_ICH_PPI_PRIORITYR9_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[10],
- SYS_ICH_PPI_PRIORITYR10_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[11],
- SYS_ICH_PPI_PRIORITYR11_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[12],
- SYS_ICH_PPI_PRIORITYR12_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[13],
- SYS_ICH_PPI_PRIORITYR13_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[14],
- SYS_ICH_PPI_PRIORITYR14_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[15],
- SYS_ICH_PPI_PRIORITYR15_EL2);
- } else {
- write_sysreg_s(0, SYS_ICH_PPI_DVIR1_EL2);
-
- write_sysreg_s(0, SYS_ICH_PPI_ACTIVER1_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_ENABLER1_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PENDR1_EL2);
-
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR8_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR9_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR10_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR11_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR12_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR13_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR14_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR15_EL2);
- }
+ write_sysreg_s(0, SYS_ICH_PPI_DVIR1_EL2);
+
+ write_sysreg_s(0, SYS_ICH_PPI_ACTIVER1_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_ENABLER1_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PENDR1_EL2);
+
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR8_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR9_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR10_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR11_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR12_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR13_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR14_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR15_EL2);
}
void __vgic_v5_save_state(struct vgic_v5_cpu_if *cpu_if)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4ef13ac0703df..eba3ef793097d 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -724,6 +724,7 @@ static bool access_gicv5_ppi_enabler(struct kvm_vcpu *vcpu,
{
unsigned long *mask = vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask;
struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
+ unsigned long reg = p->regval;
int i;
/* We never expect to get here with a read! */
@@ -731,21 +732,17 @@ static bool access_gicv5_ppi_enabler(struct kvm_vcpu *vcpu,
return undef_access(vcpu, p, r);
/*
- * If we're only handling architected PPIs and the guest writes to the
- * enable for the non-architected PPIs, we just return as there's
- * nothing to do at all. We don't even allocate the storage for them in
- * this case.
+ * As we're only handling architected PPIs, the guest writes to the
+ * enable for the non-architected PPIs just return as there's
+ * nothing to do at all. We don't even allocate the storage for them.
*/
- if (VGIC_V5_NR_PRIVATE_IRQS == 64 && p->Op2 % 2)
+ if (p->Op2 % 2)
return true;
/*
- * Merge the raw guest write into out bitmap at an offset of either 0 or
- * 64, then and it with our PPI mask.
+ * Merge the raw guest write into out bitmap, anded with our PPI mask.
*/
- bitmap_write(cpu_if->vgic_ppi_enabler, p->regval, 64 * (p->Op2 % 2), 64);
- bitmap_and(cpu_if->vgic_ppi_enabler, cpu_if->vgic_ppi_enabler, mask,
- VGIC_V5_NR_PRIVATE_IRQS);
+ bitmap_and(cpu_if->vgic_ppi_enabler, ®, mask, VGIC_V5_NR_PRIVATE_IRQS);
/*
* Sync the change in enable states to the vgic_irqs. We consider all
diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
index a96c77dccf353..90be99443df3b 100644
--- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
+++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
@@ -730,18 +730,15 @@ static int vgic_v5_get_userspace_ppis(struct kvm_device *dev,
guard(mutex)(&dev->kvm->arch.config_lock);
/*
- * We either support 64 or 128 PPIs. In the former case, we need to
- * return 0s for the second 64 bits as we have no storage backing those.
+ * We only support 64 PPIs, so, we need to return 0s for the
+ * second 64 bits as we have no storage backing those.
*/
ret = put_user(bitmap_read(gicv5_vm->userspace_ppis, 0, 64), uaddr);
if (ret)
return ret;
uaddr++;
- if (VGIC_V5_NR_PRIVATE_IRQS == 128)
- ret = put_user(bitmap_read(gicv5_vm->userspace_ppis, 64, 128), uaddr);
- else
- ret = put_user(0, uaddr);
+ ret = put_user(0, uaddr);
return ret;
}
--
2.47.3
^ permalink raw reply related
* [PATCH 08/18] KVM: arm64: vgic: Rationalise per-CPU irq accessor
From: Marc Zyngier @ 2026-04-15 11:55 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff
In-Reply-To: <20260415115559.2227718-1-maz@kernel.org>
Despite adding the necessary infrastructure to identify irq types,
vgic_get_vcpu_irq() treats GICv5 PPIs in a special way, which
impairs the readability of the code.
Use the existing irq classifiers to handle per-CPU irqs for all
vgic types, and let the normal control flow reach global interrupt
handling without any v5-specific path.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 3ac6d49bc4876..b697678d68b01 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -106,24 +106,23 @@ struct vgic_irq *vgic_get_irq(struct kvm *kvm, u32 intid)
struct vgic_irq *vgic_get_vcpu_irq(struct kvm_vcpu *vcpu, u32 intid)
{
+ enum kvm_device_type type;
+
if (WARN_ON(!vcpu))
return NULL;
- if (vgic_is_v5(vcpu->kvm)) {
- u32 int_num, hwirq_id;
-
- if (!__irq_is_ppi(KVM_DEV_TYPE_ARM_VGIC_V5, intid))
- return NULL;
-
- hwirq_id = FIELD_GET(GICV5_HWIRQ_ID, intid);
- int_num = array_index_nospec(hwirq_id, VGIC_V5_NR_PRIVATE_IRQS);
+ type = vcpu->kvm->arch.vgic.vgic_model;
- return &vcpu->arch.vgic_cpu.private_irqs[int_num];
- }
+ if (__irq_is_sgi(type, intid) || __irq_is_ppi(type, intid)) {
+ switch (type) {
+ case KVM_DEV_TYPE_ARM_VGIC_V5:
+ intid = vgic_v5_get_hwirq_id(intid);
+ intid = array_index_nospec(intid, VGIC_V5_NR_PRIVATE_IRQS);
+ break;
+ default:
+ intid = array_index_nospec(intid, VGIC_NR_PRIVATE_IRQS);
+ }
- /* SGIs and PPIs */
- if (intid < VGIC_NR_PRIVATE_IRQS) {
- intid = array_index_nospec(intid, VGIC_NR_PRIVATE_IRQS);
return &vcpu->arch.vgic_cpu.private_irqs[intid];
}
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox