* Re: [PATCH v6 1/2] dma: arm-dma350: enable ANYCH interrupt for shared IRQ wiring
From: Jun Guo @ 2026-04-22 10:33 UTC (permalink / raw)
To: Frank Li
Cc: peter.chen, fugang.duan, robh, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li, dmaengine, devicetree,
linux-kernel, cix-kernel-upstream, linux-arm-kernel
In-Reply-To: <aeia3uoz4g8tlBaV@lizhi-Precision-Tower-5810>
On 4/22/2026 5:54 PM, Frank Li wrote:
> [Some people who received this message don't often get email from frank.li@nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL
>
> On Tue, Apr 21, 2026 at 03:24:11PM +0800, Jun Guo wrote:
>> Hi Robin,
>>
>> Just pinging. I’d like to ask if you have any comments on the latest patch?
>>
>> On 3/25/2026 7:21 PM, Jun Guo wrote:
>>> Enable DMANSECCTRL.INTREN_ANYCHINTR during probe so channel
>>> interrupts are propagated when integrators wire DMA-350 channels
>>> onto a shared IRQ line.
>
> Your tag is wrong
>
> dmaegine: arm-dma350: enable ANYCH ...
Okay, I'll fix this in the next version.
>
>>>
>>> Signed-off-by: Jun Guo <jun.guo@cixtech.com>
>>> ---
>>> drivers/dma/arm-dma350.c | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/dma/arm-dma350.c b/drivers/dma/arm-dma350.c
>>> index 84220fa83029..09403aca8bb0 100644
>>> --- a/drivers/dma/arm-dma350.c
>>> +++ b/drivers/dma/arm-dma350.c
>>> @@ -13,6 +13,11 @@
>>> #include "dmaengine.h"
>>> #include "virt-dma.h"
>
> extra empty line between header file and macro
The space actually exists in the code, but it is hidden in the review
records.
>
>
>>> +#define DMANSECCTRL 0x200
>>> +
>>> +#define NSEC_CTRL 0x0c
>
> why need two layer regiser define, your use DMANSECCTRL + NSEC_CTRL，
>
> why not use one macro for 0x20c
>
DMANSECCTRL is the base address for a set of control registers.
Currently, only the NSEC_CTRL register within that set is being used.
All other registers in the same group share this same base address, and
a similar arrangement applies to DMAINFO.
>
>>> +#define INTREN_ANYCHINTR_EN BIT(0)
>>> +
>>> #define DMAINFO 0x0f00
>>> #define DMA_BUILDCFG0 0xb0
>>> @@ -582,6 +587,10 @@ static int d350_probe(struct platform_device *pdev)
>>> dmac->dma.device_issue_pending = d350_issue_pending;
>>> INIT_LIST_HEAD(&dmac->dma.channels);
>>> + reg = readl_relaxed(base + DMANSECCTRL + NSEC_CTRL);
>>> + writel_relaxed(reg | INTREN_ANYCHINTR_EN,
>>> + base + DMANSECCTRL + NSEC_CTRL);
>>> +
>>> /* Would be nice to have per-channel caps for this... */
>>> memset = true;
>>> for (int i = 0; i < nchan; i++) {
>>
^ permalink raw reply
* Re: [PATCH v2 1/9] driver core: Enable suppliers to implement fine grained sync_state support
From: Danilo Krummrich @ 2026-04-22 10:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel, Geert Uytterhoeven, driver-core
In-Reply-To: <CAPDyKFqMDPiqvqJrq5Qs6Tw4Sc7szG4G-=y0NFkNSPoNd9kdVA@mail.gmail.com>
On Wed Apr 22, 2026 at 12:07 PM CEST, Ulf Hansson wrote:
> On Sat, 18 Apr 2026 at 13:23, Danilo Krummrich <dakr@kernel.org> wrote:
>> On Fri Apr 10, 2026 at 12:40 PM CEST, Ulf Hansson wrote:
>> > @@ -1126,6 +1128,9 @@ static void __device_links_queue_sync_state(struct device *dev,
>> > if (dev->state_synced)
>> > return;
>> >
>> > + if (dev->driver && dev->driver->queue_sync_state)
>> > + dev->driver->queue_sync_state(dev);
>>
>> This seems to be called without the device lock being held, which seems to allow
>> the queue_sync_state() callback to execute concurrently with remove(). This
>> opens the door for all kinds of UAF conditions in drivers.
>
> If that were the case, this whole function would be unsafe even before
> this change. I assume this isn't because of how the function is being
> called, but I may be wrong.
This function does not issue any driver callbacks intentionally; the existing
sync_state() callback is deferred to device_links_flush_sync_list(), which is
called without the device_links_write_lock() held, but takes the device_lock()
to protect against other concurrent driver callbacks, such as remove().
I.e. we can't take the device_lock() when the device_links_write_lock() is held,
as it would be prone to lock inversion.
The documentation of __device_links_queue_sync_state() actually slightly hints
at this, but focuses more on the other reason for the deferred semantics -- the
sync_state() callback may want to call device link APIs.
> Anyway, let me add a get/put_device() here somewhere, to ensure we
> prevent this from happening. I assume that is what you are proposing?
No, an additional device reference count won't protect against other concurrent
driver callbacks, such as remove().
^ permalink raw reply
* Re: [PATCH 0/5] firmware/irqchip: Add FF-A DT interrupt support for donated NS SGIs
From: Marc Zyngier @ 2026-04-22 11:01 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260412-b4-ffa_ns_sgi_gicv3-v1-0-af61243eb405@kernel.org>
On Sun, 12 Apr 2026 18:04:36 +0100,
Sudeep Holla <sudeep.holla@kernel.org> wrote:
>
> Hi all,
>
> This series wires FF-A notification interrupts up through DT using the
> standard interrupts property on the arm,ffa node and adds the
> required GICv3 and binding support for secure-donated non-secure SGIs.
>
> This has been long pending after the discussions here[1][2]. I have been
> waiting for some ACPI story to shape up for almost an year now, but no
> progress there. So posting this for now to start discussion on the approach
> taken here instead of waiting for another year to sort out ACPI 😉.
>
> It:
>
> - documents secure-donated NS SGIs in the GIC DT binding
> - teaches the GICv3 driver to accept and map those SGIs
> - adds a DT binding for the arm,ffa firmware node
> - updates the FF-A driver to use the arm,ffa node interrupt instead of
> synthesizing its own GIC mapping
> - adds an FVP DT node using SGI 8 as the FF-A notification interrupt
>
> The FF-A DT lookup expects a single interrupt entry, verifies that it is
> a per-CPU interrupt via the reported affinity mask, and cross-checks the
> resolved Linux IRQ hwirq against the interrupt ID returned by
> FFA_FEATURES.
I haven't looked at this in any detail, but these are the additional
issues someone needs to address:
- The GIC(v3) is dead, long live the GIC(v5)! SGIs don't exist in the
brave new world, so FFA needs to find new ways to signal interrupts.
- FFA doesn't necessarily live in secure world, and could be
implemented by a hypervisor. In the context of a single security
domain machine (that's what a VM is), the guest *owns* all SGIs. So
there is absolutely nothing to donate, and this doesn't work. FFA
also needs fixing here.
- All of the above should work with the other firmware description
(Avoid Critical Periodic Interrupts). But maybe FFA is not a thing
on these machines? If not, it should be made explicit.
Overall, it only indicates that FFA should behave as a device, and
use interrupts that are valid for a device.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3 4/4] docs: driver-api: add mod_name argument to __platform_register_drivers()
From: Greg Kroah-Hartman @ 2026-04-22 11:27 UTC (permalink / raw)
To: Shashank Balaji
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Rafael J. Wysocki,
Danilo Krummrich, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Richard Cochran, Jonathan Corbet, Shuah Khan,
Rahul Bukte, linux-kernel, coresight, linux-arm-kernel,
driver-core, rust-for-linux, linux-doc, Daniel Palmer, Tim Bird
In-Reply-To: <20260422-acpi_mod_name-v3-4-a184eff9ff6f@sony.com>
On Wed, Apr 22, 2026 at 06:49:06PM +0900, Shashank Balaji wrote:
> Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> ---
> Documentation/driver-api/driver-model/platform.rst | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
For obvious reasons we can't take patches without any changelog text at
all (and neither should you want us to...)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/9] driver core: Add dev_set_drv_queue_sync_state()
From: Danilo Krummrich @ 2026-04-22 11:30 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel, Geert Uytterhoeven, driver-core
In-Reply-To: <CAPDyKFpeSv+fg=YKJE_qc=Q5BfiJFn0tR7Ar8SncqrD0UW1P1g@mail.gmail.com>
On Wed Apr 22, 2026 at 12:25 PM CEST, Ulf Hansson wrote:
> Most of the static inline functions in device.h lacks documentation.
> Are you suggesting that we should move towards documenting all of
> them?
I'd prefer that, yes. After all, if they are defined in device.h, they are
public APIs, so they should ideally have documentation.
(If a function is only used throughout the driver core, it should be in
drivers/base/base.h instead.)
^ permalink raw reply
* Re: [PATCH v5 0/6] Add Rockchip RK3576 PWM Support Through MFPWM
From: Nicolas Frattaroli @ 2026-04-22 11:31 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Lee Jones, William Breathitt Gray,
Damon Ding, kernel, Jonas Karlman, Alexey Charkov, linux-rockchip,
linux-pwm, devicetree, linux-arm-kernel, linux-kernel, linux-iio,
Conor Dooley
In-Reply-To: <20260421165656.168fe262@jic23-huawei>
On Tuesday, 21 April 2026 17:56:56 Central European Summer Time Jonathan Cameron wrote:
> On Mon, 20 Apr 2026 15:52:37 +0200
> Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
>
> > This series introduces support for some of the functions of the new PWM
> > silicon found on Rockchip's RK3576 SoC. Due to the wide range of
> > functionalities offered by it, including many parts which this series'
> > first iteration does not attempt to implement for now. The drivers are
> > modelled as an MFD, with no leakage of the MFD-ness into the binding, as
> > it's a Linux implementation detail.
>
> Just thought I'd point out that as this includes the linux-iio
> list sashiko took a look at it. Quite a few things and at least
> the first one I looked at was valid (a dereference before a validity
> check)
>
> https://sashiko.dev/#/patchset/20260420-rk3576-pwm-v5-0-ae7cfbbe5427%40collabora.com
>
> Whilst this tool does generate some false positives, it also finds
> quite a few things it seems us humans fail to spot.
>
> Jonathan
>
While I'm not entirely opposed to this, I do think reviews should happen
on-list when possible. Sashiko is a Google service, so it has about a 50%
chance of still being around in 2 years time. One of the benefits of the
kernel development workflow is that discussion going back decades is still
accessible.
The reason why these aren't posted to list goes into the other thing
that I currently am not stoked about, which is that I'd have to act as
a filter for a Bring-Your-Own-Brain noise generator to pick out the
parts that aren't convincing lies.
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: add tqma9596la-mba95xxca
From: Francesco Dolcini @ 2026-04-22 11:42 UTC (permalink / raw)
To: Alexander Stein, Daniel Baluta
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo, linux-arm-kernel,
Markus Niebel, devicetree, linux-kernel, imx, linux,
linux-renesas-soc
In-Reply-To: <5988897.DvuYhMxLoT@steina-w>
On Wed, Apr 22, 2026 at 07:58:11AM +0200, Alexander Stein wrote:
> Am Dienstag, 21. April 2026, 16:48:25 CEST schrieb Daniel Baluta:
> > [..]
> >
> > > +
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + linux_cma: linux,cma {
> > > + compatible = "shared-dma-pool";
> > > + reusable;
> > > + size = <0 0x28000000>;
> > > + alloc-ranges = <0 0x80000000 0 0x80000000>;
> > > + linux,cma-default;
> > > + };
> > > +
> > > + vpu_boot: vpu_boot@a0000000 {
> >
> > Should this be memory@a0000000 ?
>
> According to schema in dt-schema repository [1] the node name should
> describe the purpose, so I would keep that.
See this question on the topic, and the related answer from Rob,
https://lore.kernel.org/all/88456d17c91737cfc09af46673b49bb9a9d36dc0.camel@gmail.com/
Francesco
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: dts: amlogic: add support for Amediatech X98Q
From: Christian Hewitt @ 2026-04-22 11:43 UTC (permalink / raw)
To: christian.koever-draxl
Cc: robh, krzk+dt, conor+dt, neil.armstrong, khilman, jbrunet,
martin.blumenstingl, devicetree, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260422095840.26139-3-christian.koever-draxl@student.uibk.ac.at>
> On 22 Apr 2026, at 1:58 pm, christian.koever-draxl@student.uibk.ac.at wrote:
>
> From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
> Add dts enabling core hardware for the Amediatech X98Q TV box.
>
> The board features:
> - Amlogic S905W2 (Meson S4) SoC
> - 1 GiB RAM (2 GiB variants exist)
> - eMMC and microSD card slot
> - SDIO-based WiFi module (unsupported)
> - RMII Ethernet with internal PHY
> - IR receiver and UART console
> - Status LED
>
> Enabled peripherals:
> - eMMC (HS200)
> - SD card interface
> - SDIO bus (WiFi, no driver yet)
> - Ethernet (RMII)
> - UART_B
> - IR receiver
> - PWM-controlled CPU regulator
> - PWM and Fixed regulators for core and IO rails
>
> Known limitations:
> - No support for the onboard WiFi module
> - Missing multimedia (HDMI/audio)
>
> Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
> ---
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
> 2 files changed, 250 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>
> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
> index 15f9c817e502..c7752684dea6 100644
> --- a/arch/arm64/boot/dts/amlogic/Makefile
> +++ b/arch/arm64/boot/dts/amlogic/Makefile
> @@ -85,6 +85,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-ugoos-am3.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
> +dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
> index 000000000000..3eecbc858522
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
> @@ -0,0 +1,249 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2026 Christian Stefan Köver-Draxl
> + * Based on meson-s4-s905y4-khadas-vim1s.dts:
> + * - Copyright (c) 2026 Khadas Technology Co., Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "meson-s4.dtsi"
> +
> +/ {
> + model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
> + compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + mmc0 = &emmc; /* eMMC */
> + mmc1 = &sd; /* SD card */
> + mmc2 = &sdio; /* SDIO */
> + serial0 = &uart_b;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x40000000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 52 MiB reserved for ARM Trusted Firmware */
> + secmon_reserved: secmon@5000000 {
> + reg = <0x0 0x05000000 0x0 0x3400000>;
> + no-map;
> + };
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
> + };
> +
> + sdio_32k: sdio-32k {
> + compatible = "pwm-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
> + clocks = <&sdio_32k>;
> + clock-names = "ext_clock";
> + };
> +
> + main_5v: regulator-main-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +
> + sd_3v3: regulator-sd-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "SD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
> + regulator-always-on;
> + };
> +
> + vddio_sd: regulator-vddio-sd {
> + compatible = "regulator-gpio";
> + regulator-name = "VDDIO_SD";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
> + gpios-states = <1>;
> + states = <1800000 1 3300000 0>;
> + };
> +
> + vddao_3v3: regulator-vddao-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&main_5v>;
> + regulator-always-on;
> + };
> +
> + vddio_ao1v8: regulator-vddio-ao1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_AO1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + /* SY8120B1ABC DC/DC Regulator. */
> + vddcpu: regulator-vddcpu {
> + compatible = "pwm-regulator";
> +
> + regulator-name = "VDDCPU";
> + regulator-min-microvolt = <689000>;
> + regulator-max-microvolt = <1049000>;
> +
> + vin-supply = <&main_5v>;
> +
> + pwms = <&pwm_ij 1 1500 0>;
> + pwm-dutycycle-range = <100 0>;
> +
> + regulator-boot-on;
> + regulator-always-on;
> + /* Voltage Duty-Cycle */
> + voltage-table = <1049000 0>,
> + <1039000 3>,
> + <1029000 6>,
> + <1019000 9>,
> + <1009000 12>,
> + <999000 14>,
> + <989000 17>,
> + <979000 20>,
> + <969000 23>,
> + <959000 26>,
> + <949000 29>,
> + <939000 31>,
> + <929000 34>,
> + <919000 37>,
> + <909000 40>,
> + <899000 43>,
> + <889000 45>,
> + <879000 48>,
> + <869000 51>,
> + <859000 54>,
> + <849000 56>,
> + <839000 59>,
> + <829000 62>,
> + <819000 65>,
> + <809000 68>,
> + <799000 70>,
> + <789000 73>,
> + <779000 76>,
> + <769000 79>,
> + <759000 81>,
> + <749000 84>,
> + <739000 87>,
> + <729000 89>,
> + <719000 92>,
> + <709000 95>,
> + <699000 98>,
> + <689000 100>;
> + };
> +};
> +
> +&emmc {
> + status = "okay";
> + pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
> + pinctrl-1 = <&emmc_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> +
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> +
> + mmc-pwrseq = <&emmc_pwrseq>;
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddio_ao1v8>;
> +};
> +
> +ðmac {
> + status = "okay";
> + phy-handle = <&internal_ephy>;
> + phy-mode = "rmii";
> +};
> +
> +&ir {
> + status = "okay";
> + pinctrl-0 = <&remote_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&pwm_ef {
> + status = "okay";
> + pinctrl-0 = <&pwm_e_pins1>;
> + pinctrl-names = "default";
> +};
> +
> +&pwm_ij {
> + status = "okay";
> +};
> +
> +&sd {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-1 = <&sdcard_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> + bus-width = <4>;
> + cap-sd-highspeed;
> + max-frequency = <50000000>;
> + disable-wp;
> +
> + cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
> +
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddao_3v3>;
> +};
> +
> + /*
> + * Wireless SDIO Module (Amlogic W150S1)
> + * Note: There is no driver for this at the moment.
> + */
^ drop this comment
> +
> +&sdio {
> + status = "okay";
> + pinctrl-0 = <&sdio_pins>;
> + pinctrl-1 = <&sdio_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + bus-width = <4>;
> + cap-sd-highspeed;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> +
> + no-sd;
> + no-mmc;
> + mmc-pwrseq = <&sdio_pwrseq>;
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddio_ao1v8>;
sdio: wifi@1 {
/* Amlogic W150S1 */
reg = <1>;
};
^ add this to generically describe the hardware without
the need for a specific compatible (as done in several of
the Amlogic reference designs where we cannot guarantee
which chipset is used). The reg value should be enough to
result in the downstream driver probing should a distro
choose to package it; thus avoiding the need for distros
to forever carry a device-tree patch to add support (as
Amlogic have no plans to upstream the driver). Should that
ever change the comment can be replaced with a compatible.
Christian
> +};
> +
> +&uart_b {
> + status = "okay";
> +};
> --
> 2.53.0
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* [PATCH] pinctrl: meson: amlogic-a4: fix deadlock issue
From: Xianwei Zhao via B4 Relay @ 2026-04-22 11:44 UTC (permalink / raw)
To: Linus Walleij, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: linux-amlogic, linux-gpio, linux-arm-kernel, linux-kernel,
Xianwei Zhao
From: Xianwei Zhao <xianwei.zhao@amlogic.com>
Accessing the pinconf-pins sysfs node may deadlock.
pinconf_pins_show() holds pctldev->mutex, and the platform driver
calls pinctrl_find_gpio_range_from_pin(), which tries to acquire
the same mutex again, leading to a deadlock.
Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue.
Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs")
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
Fix deadlock issue.
---
drivers/pinctrl/meson/pinctrl-amlogic-a4.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
index e2293a872dcb..35d27626a336 100644
--- a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
+++ b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
@@ -292,7 +292,7 @@ static int aml_calc_reg_and_bit(struct pinctrl_gpio_range *range,
static int aml_pinconf_get_pull(struct aml_pinctrl *info, unsigned int pin)
{
struct pinctrl_gpio_range *range =
- pinctrl_find_gpio_range_from_pin(info->pctl, pin);
+ pinctrl_find_gpio_range_from_pin_nolock(info->pctl, pin);
struct aml_gpio_bank *bank = gpio_chip_to_bank(range->gc);
unsigned int reg, bit, val;
int ret, conf;
@@ -326,7 +326,7 @@ static int aml_pinconf_get_drive_strength(struct aml_pinctrl *info,
u16 *drive_strength_ua)
{
struct pinctrl_gpio_range *range =
- pinctrl_find_gpio_range_from_pin(info->pctl, pin);
+ pinctrl_find_gpio_range_from_pin_nolock(info->pctl, pin);
struct aml_gpio_bank *bank = gpio_chip_to_bank(range->gc);
unsigned int reg, bit;
unsigned int val;
@@ -365,7 +365,7 @@ static int aml_pinconf_get_gpio_bit(struct aml_pinctrl *info,
unsigned int reg_type)
{
struct pinctrl_gpio_range *range =
- pinctrl_find_gpio_range_from_pin(info->pctl, pin);
+ pinctrl_find_gpio_range_from_pin_nolock(info->pctl, pin);
struct aml_gpio_bank *bank = gpio_chip_to_bank(range->gc);
unsigned int reg, bit, val;
int ret;
---
base-commit: bd7fd288490c64835a74c05e631c102ce056d5e1
change-id: 20260422-fix-pinconf-42be1cc2f5af
Best regards,
--
Xianwei Zhao <xianwei.zhao@amlogic.com>
^ permalink raw reply related
* Re: [PATCH 1/4] arm64: signal: Preserve POR_EL0 if poe_context is missing
From: Will Deacon @ 2026-04-22 12:19 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, Catalin Marinas, Joey Gouly,
Mark Brown, Shuah Khan, linux-kselftest
In-Reply-To: <20260421144252.1440365-2-kevin.brodsky@arm.com>
Hey Kevin,
On Tue, Apr 21, 2026 at 03:42:49PM +0100, Kevin Brodsky wrote:
> Commit 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to
> avoid uaccess failures") delayed the write to POR_EL0 in
> rt_sigreturn to avoid spurious uaccess failures. This change however
> relies on the poe_context frame record being present: on a system
> supporting POE, calling sigreturn without a poe_context record now
> results in writing arbitrary data from the kernel stack into POR_EL0.
>
> Fix this by adding a valid_fields member to struct
> user_access_state, and zeroing the struct on allocation.
> restore_poe_context() then indicates that the por_el0 field is valid
> by setting the corresponding bit in valid_fields, and
> restore_user_access_state() only touches POR_EL0 if there is a valid
> value to set it to. This is in line with how POR_EL0 was originally
> handled; all frame records are currently optional, except
> fpsimd_context.
>
> restore_user_access_state() is also called if setting up the signal
> frame fails, so we also initialise valid_fields in that case. For
> consistency, setup_sigframe() now also checks valid_fields to decide
> whether to write a poe_context record, avoiding another call to
> system_supports_poe().
>
> Fixes: 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to avoid uaccess failures")
> Reported-by: Will Deacon <will@kernel.org>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Thanks for fixing this. I think your patch is correct, but I have a
couple of comments inline. Please let me know what you think.
> ---
> arch/arm64/kernel/signal.c | 19 ++++++++++++++-----
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 08ffc5a5aea4..3f17aed5b4f0 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -67,6 +67,8 @@ struct rt_sigframe_user_layout {
> unsigned long end_offset;
> };
>
> +#define UA_STATE_HAS_POR_EL0 BIT(0)
> +
> /*
> * Holds any EL0-controlled state that influences unprivileged memory accesses.
> * This includes both accesses done in userspace and uaccess done in the kernel.
> @@ -74,8 +76,12 @@ struct rt_sigframe_user_layout {
> * This state needs to be carefully managed to ensure that it doesn't cause
> * uaccess to fail when setting up the signal frame, and the signal handler
> * itself also expects a well-defined state when entered.
> + *
> + * The valid_fields member is a bitfield (see UA_STATE_HAS_*), specifying which
> + * of the remaining fields is valid (has been set to a value).
> */
> struct user_access_state {
> + unsigned int valid_fields;
> u64 por_el0;
> };
Do you think it would be worth adding some accessors to make it easier
to keep the flags in sync? For example:
/* Stores por_el0 into uas->por_el0 and sets UA_STATE_HAS_POR_EL0 */
void set_ua_state_por_el0(struct user_access_state *uas, u64 por_el0);
/*
* If UA_STATE_HAS_POR_EL0, *por_el0 = uas->por_el0 and return 0.
* Otherwise, return -ENOENT.
*/
int get_ua_state_por_el0(struct user_access_state *uas, u64 *por_el0);
WDYT?
> @@ -1095,7 +1104,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
> {
> struct pt_regs *regs = current_pt_regs();
> struct rt_sigframe __user *frame;
> - struct user_access_state ua_state;
> + struct user_access_state ua_state = {0};
nit: {} should do (no need for the '0'). Same in setup_rt_frame().
Will
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
From: Marc Zyngier @ 2026-04-22 12:24 UTC (permalink / raw)
To: Sebastian Ene
Cc: oupton, will, ayrton, catalin.marinas, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, yuzenghui, stable
In-Reply-To: <20260422102540.1433704-1-sebastianene@google.com>
On Wed, 22 Apr 2026 11:25:40 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
>
> Prevent the pKVM hypervisor from making assumptions that the
> endpoint memory access descriptor (EMAD) comes right after the
> FF-A memory region header and enforce a strict placement for it
> when validating an FF-A memory lend/share transaction.
As I read this, you want to remove a bad assumption...
>
> Prior to FF-A version 1.1 the header of the memory region
> didn't contain an offset to the endpoint memory access descriptor.
> The layout of a memory transaction looks like this:
>
> Field name | Offset
> -- 0
> [ Header (ffa_mem_region) |__ ep_mem_offset
> EMAD 1 (ffa_mem_region_attributes) |
> ]
>
> Reject the host from specifying a memory access descriptor offset
> that is different than the size of the memory region header.
And yet you decide that you want to enforce this assumption. I don't
understand how you arrive to this conclusion.
Looking at the spec, it appears that the offset is *designed* to allow
a gap between the header and the EMAD. Refusing to handle a it seems to be a
violation of the spec.
What am I missing?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support
From: Jason Gunthorpe @ 2026-04-22 12:40 UTC (permalink / raw)
To: Sami Mujawar
Cc: Suzuki Poulose, Dan Williams,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Catalin Marinas, will@kernel.org,
thuth@redhat.com, Steven Price, gshan@redhat.com, Yeoreum Yun,
cedric.xing@intel.com, Dan Williams, Dionna Glaze,
Aneesh Kumar K . V, Alexey Kardashevskiy,
linux-coco@lists.linux.dev
In-Reply-To: <AS8PR08MB680669CBFA9654BC12179D5E842F2@AS8PR08MB6806.eurprd08.prod.outlook.com>
On Wed, Apr 22, 2026 at 08:57:00AM +0000, Sami Mujawar wrote:
> > So this is tying it to the same FW event log that TPM uses.
> >
> > I think that strengthens my point this should all be uninform. TPM
> > drivers are directly exposing the event log today, but I guess that
> > needs generalization if non-TPM drivers are going to present it as
> > well.
> >
> > How do you imagine getting and manipulating the EFI event log to use
> > with this?
>
> The event logs from UEFI will be handed off to the OS using CCEL
> ACPI table. The CCEL table spec update can be seen at
> https://github.com/tianocore/edk2/issues/11384
I ment from linux userspace. event log is well establihsed in the aCPI
side for TPM and in Linux today it is only exposed to userspace
through TPM.
This is not TPM, so how do you intend to give the event log to
userspace?
Jason
^ permalink raw reply
* Re: [PATCH RFC 1/2] arm64: vdso: Prepare for robust futex unlock support
From: André Almeida @ 2026-04-22 12:46 UTC (permalink / raw)
To: Florian Weimer
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Rich Felker, Torvald Riegel, Darren Hart,
Ingo Molnar, Davidlohr Bueso, Arnd Bergmann, Liam R . Howlett,
Uros Bizjak, Thomas Weißschuh, linux-arm-kernel,
linux-kernel, linux-arch, kernel-dev
In-Reply-To: <lhu1pgd8w0f.fsf@oldenburg.str.redhat.com>
Hi Florian,
Em 17/04/2026 12:08, Florian Weimer escreveu:
> * André Almeida:
>
>> There will be a VDSO function to unlock non-contended robust futexes in
>> user space. The unlock sequence is racy vs. clearing the list_pending_op
>> pointer in the task's robust list head. To plug this race the kernel needs
>> to know the critical section window so it can clear the pointer when the
>> task is interrupted within that race window. The window is determined by
>> labels in the inline assembly.
>>
>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>> ---
>> RFC: Those symbols can't be found by the linker after patch 2/2, it fails with:
>>
>> ld: arch/arm64/kernel/vdso.o: in function `vdso_futex_robust_unlock_update_ips':
>> arch/arm64/kernel/vdso.c:72:(.text+0x200): undefined reference to `__futex_list64_try_unlock_cs_success'
>> ld: arch/arm64/kernel/vdso.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__futex_list64_try_unlock_cs_success' which may bind externally can not be used when making a shared object; recompile with -fPIC
>> arch/arm64/kernel/vdso.c:72:(.text+0x200): dangerous relocation: unsupported relocation
>
> I think your GLOBLS definition adds a 64 suffix. That shouldn't be
> necessary on AArch64. It's not reflected in the references, so you end
> up with an undefined symbol error.
>
Why aarch64 doesn't need the 64 suffix? objdump shows that the final
label name is __futex_list64_try_unlock_cs_success, which should match
what the linker is trying to find, AFAIC.
André
^ permalink raw reply
* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Andrew Lunn @ 2026-04-22 12:47 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <aeiJ3zr4WJAm1UCk@AMDC4622.eu.corp.samsungelectronics.net>
> I don't see anything wrong with it?
> - naming is correct, same as stmmac_extra_stats from common.h, as it
> wouldn't compile otherwise
> - string length is ok, as max name length is ETH_GSTRING_LEN=32 and it is
> not close
> - ethtool just polls data from driver and in my tests it is ok
> - all instances of 'undeflow' are changed
> - 'underflow' semantic is ok, 'undeflow' is just not correct
>
> Please correct me if I am wrong, but imo no issues with this patch.
ABI
This name is published as part of the kAPI. You are changing its
name. User space could be looking for this name, even thought it has a
typo in it.
Andrew
^ permalink raw reply
* [PATCH] crypto: testmgr - disallow RSA PKCS#1 SHA-1 sig algs in FIPS mode
From: jeffbarnes @ 2026-04-22 12:49 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Maxime Coquelin, Alexandre Torgue
Cc: linux-crypto, linux-stm32, linux-arm-kernel, linux-kernel,
Jeff Barnes, Jeff Barnes
From: Jeff Barnes <jeffbarnes@microsoft.com>
When booted with fips=1, RSA signature generation using SHA-1 must not be
available. However, pkcs1pad(rsa,sha1) can currently be instantiated
because it is not present in alg_test_descs; alg_test() falls through the
no_test path and succeeds, after which the algorithm appears in /proc/crypto
as fips-capable. 【1-ebd9df】
Add explicit alg_test_descs entries for pkcs1pad(rsa,sha1) and pkcs1(rsa,sha1)
without marking them fips_allowed, so they are treated as not FIPS-allowed
when fips=1 is enabled.
Include both names to cover kernels where RSA sign/verify is provided via
the pkcs1(...) signature template, while pkcs1pad(...) remains for the
traditional wrapper naming and/or RSAES operations. 【2-17cc14】
Signed-off-by: Jeff Barnes <jeffbarnes@linux.microsoft.com>
---
This series fixes an issue where SHA-1 RSA signature generation remains
available when booted with fips=1.
On a FIPS-enabled system, pkcs1pad(rsa,sha1) can be instantiated even
though SHA-1 must not be available for signature generation. The reason
is that the algorithm is not listed in crypto/testmgr.c's alg_test_descs,
so alg_test() falls through the no_test path and succeeds. Once
instantiated, /proc/crypto reports the algorithm as "fips: yes".
This patch adds explicit alg_test_descs entries for:
- pkcs1pad(rsa,sha1)
- pkcs1(rsa,sha1)
without setting fips=1, so they are treated as not FIPS-allowed in
FIPS mode.
Both names are covered to handle kernels where RSA signature operations
are provided via the pkcs1(...) signature template, while pkcs1pad(...)
remains for the historical wrapper naming and/or RSAES operations.
Reproducer / evidence (current behavior):
1) Boot with fips=1 (confirm /proc/sys/crypto/fips_enabled == 1)
2) Allocate the transform:
crypto_alloc_akcipher("pkcs1pad(rsa,sha1)", 0, 0)
3) Observe that /proc/crypto now contains:
name : pkcs1pad(rsa,sha1)
fips : yes
selftest: passed
4) A simple in-kernel demo module can instantiate the transform and reach
the signing path in FIPS mode.
With this change, attempts to instantiate these SHA-1 RSA signing
templates in FIPS mode are rejected, preventing SHA-1 signature
generation in approved mode.
Thanks for taking a look.
Signed-off-by: Jeff Barnes <jeffbarnes@microsoft.com>
---
crypto/testmgr.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 30671e7bc349..e54d298a26c1 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -5306,6 +5306,9 @@ static const struct alg_test_desc alg_test_descs[] = {
.suite = {
.sig = __VECS(pkcs1_rsa_none_tv_template)
}
+ }, {
+ .alg = "pkcs1(rsa,sha1)",
+ .test = alg_test_null,
}, {
.alg = "pkcs1(rsa,sha224)",
.test = alg_test_null,
@@ -5341,6 +5344,9 @@ static const struct alg_test_desc alg_test_descs[] = {
.alg = "pkcs1pad(rsa)",
.test = alg_test_null,
.fips_allowed = 1,
+ }, {
+ .alg = "pkcs1pad(rsa,sha1)",
+ .test = alg_test_null,
}, {
.alg = "rfc3686(ctr(aes))",
.generic_driver = "rfc3686(ctr(aes-lib))",
---
base-commit: 8879a3c110cb8ca5a69c937643f226697aa551d9
change-id: 20260422-disallow_rsa_sha1_signing_in_fips_mode-8fbb6229ad54
Best regards,
--
Jeff Barnes <jeffbarnes@microsoft.com>
^ permalink raw reply related
* Re: [PATCH RFC 1/2] arm64: vdso: Prepare for robust futex unlock support
From: Florian Weimer @ 2026-04-22 12:56 UTC (permalink / raw)
To: André Almeida
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Rich Felker, Torvald Riegel, Darren Hart,
Ingo Molnar, Davidlohr Bueso, Arnd Bergmann, Liam R . Howlett,
Uros Bizjak, Thomas Weißschuh, linux-arm-kernel,
linux-kernel, linux-arch, kernel-dev
In-Reply-To: <32642d18-8c83-47ad-8456-1813084c4622@igalia.com>
* André Almeida:
> Hi Florian,
>
> Em 17/04/2026 12:08, Florian Weimer escreveu:
>> * André Almeida:
>>
>>> There will be a VDSO function to unlock non-contended robust futexes in
>>> user space. The unlock sequence is racy vs. clearing the list_pending_op
>>> pointer in the task's robust list head. To plug this race the kernel needs
>>> to know the critical section window so it can clear the pointer when the
>>> task is interrupted within that race window. The window is determined by
>>> labels in the inline assembly.
>>>
>>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>>> ---
>>> RFC: Those symbols can't be found by the linker after patch 2/2, it fails with:
>>>
>>> ld: arch/arm64/kernel/vdso.o: in function `vdso_futex_robust_unlock_update_ips':
>>> arch/arm64/kernel/vdso.c:72:(.text+0x200): undefined reference to `__futex_list64_try_unlock_cs_success'
>>> ld: arch/arm64/kernel/vdso.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__futex_list64_try_unlock_cs_success' which may bind externally can not be used when making a shared object; recompile with -fPIC
>>> arch/arm64/kernel/vdso.c:72:(.text+0x200): dangerous relocation: unsupported relocation
>> I think your GLOBLS definition adds a 64 suffix. That shouldn't be
>> necessary on AArch64. It's not reflected in the references, so you end
>> up with an undefined symbol error.
>>
>
> Why aarch64 doesn't need the 64 suffix? objdump shows that the final
> label name is __futex_list64_try_unlock_cs_success, which should match
> what the linker is trying to find, AFAIC.
Sorry, I was confused about how this is expected to work.
Florian
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Peter Zijlstra @ 2026-04-22 12:56 UTC (permalink / raw)
To: Mathias Stearn
Cc: Thomas Gleixner, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Ingo Molnar,
Mark Rutland, Jinjie Ruan, Blake Oler
In-Reply-To: <CAHnCjA25b+nO2n5CeifknSKHssJpPrjnf+dtr7UgzRw4Zgu=oA@mail.gmail.com>
On Wed, Apr 22, 2026 at 11:50:26AM +0200, Mathias Stearn wrote:
> Additionally, it breaks tcmalloc specifically by failing to overwrite
> the cpu_id_start field at points where it was relied on for
> correctness.
This specific behaviour was documented as being wrong and running with
DEBUG_RSEQ would have flagged it.
The tcmalloc issue has been contentious for a long time. The tcmalloc
folks relied on something that was documented to be wrong. It has been
reported to the tcmalloc people many years ago and if you were to run
tcmalloc on most any kernel (very much including 6.19) with
DEBUG_RSEQ=y, it would have yelled.
The tcmalloc people didn't care. There was a proposal for an RSEQ
extension for what they need, and they didn't care. All this should be
in their bugzilla or whatever.
The RSEQ rework improved performance significantly for everyone, and
kept all the documented behaviour (+- arm64 bug). Tcmalloc got screwed
over because they relied on implementation behaviour that was
specifically documented to be broken. And they didn't care. Google was
very much aware of this. And hasn't lifted a finger to remedy it.
^ permalink raw reply
* Re: [PATCH RFC 1/2] arm64: vdso: Prepare for robust futex unlock support
From: Thomas Weißschuh @ 2026-04-22 13:02 UTC (permalink / raw)
To: André Almeida
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, linux-arm-kernel, linux-kernel,
linux-arch, kernel-dev
In-Reply-To: <20260417-tonyk-robust_arm-v1-1-03aa64e2ff1a@igalia.com>
On 2026-04-17 11:56:10-0300, André Almeida wrote:
> There will be a VDSO function to unlock non-contended robust futexes in
> user space. The unlock sequence is racy vs. clearing the list_pending_op
> pointer in the task's robust list head. To plug this race the kernel needs
> to know the critical section window so it can clear the pointer when the
> task is interrupted within that race window. The window is determined by
> labels in the inline assembly.
>
> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
> RFC: Those symbols can't be found by the linker after patch 2/2, it fails with:
>
> ld: arch/arm64/kernel/vdso.o: in function `vdso_futex_robust_unlock_update_ips':
> arch/arm64/kernel/vdso.c:72:(.text+0x200): undefined reference to `__futex_list64_try_unlock_cs_success'
> ld: arch/arm64/kernel/vdso.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__futex_list64_try_unlock_cs_success' which may bind externally can not be used when making a shared object; recompile with -fPIC
> arch/arm64/kernel/vdso.c:72:(.text+0x200): dangerous relocation: unsupported relocation
arch/arm64/kernel/vdso.o is a kernel object.
__futex_list64_try_unlock_cs_success is a vDSO symbol.
They live in wholly different objects, which are never linked together.
Look at VDSO_SYMBOL() to get the offset of the vDSO symbol in kernel code.
(...)
Thomas
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mark Rutland @ 2026-04-22 13:09 UTC (permalink / raw)
To: Mathias Stearn
Cc: Thomas Gleixner, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Peter Zijlstra,
Ingo Molnar, Jinjie Ruan, Blake Oler
In-Reply-To: <CAHnCjA25b+nO2n5CeifknSKHssJpPrjnf+dtr7UgzRw4Zgu=oA@mail.gmail.com>
Hi Mathias,
On Wed, Apr 22, 2026 at 11:50:26AM +0200, Mathias Stearn wrote:
> TL;DR: As of 6.19, rseq no longer provides the documented atomicity
> guarantees on arm64 by failing to abort the critical section on same-core
> preemption/resumption. Additionally, it breaks tcmalloc specifically by
> failing to overwrite the cpu_id_start field at points where it was relied
> on for correctness.
Thanks for the report, and the test case.
As a holding reply, I'm looking into this now from the arm64 side.
I'll leave it to Thomas/Peter/Mathieu to comment w.r.t. the issue you
raise with cpu_id_start.
For some reason, this mail didn't make it to my inbox, and I had to grab
it from lore using b4. That might be a problem with my local mail
server; I'm just noting that in case others also didn't receive this.
Mark.
> This is a SEVERE breakage for MongoDB. We received several user reports of
> crashes on 6.19. I made a stress test that showed that 6.19 can cause
> malloc to return the same pointer twice without it being freed. Because
> that can cause arbitrary corruption, our latest releases have all been
> patched to refuse to start at all on 6.19+.
>
> TCMalloc uses rseq in a "creative" way described at
> https://github.com/google/tcmalloc/blob/master/docs/rseq.md. In particular,
> the "Current CPU Slabs Pointer Caching" section describes an optimization
> that relies on an undocumented fact that the kernel was always overwriting
> cpu_id_start (even when it wouldn't change) to invalidate a user-space
> cache. Since the change to stop writing cpu_id_start seemed to be
> intentional as part of a refactoring merged in 2b09f480f0a1, I started
> working on a userspace patch to stop relying on that. Unfortunately when
> that was complete I ran into a wall that is impossible to work around from
> userspace.
>
> On arm64, the kernel no longer meets the documented guarantee that rseq
> critical sections are atomic with respect to preemption. It seems to only
> abort the critical section when the thread is migrated to a different core.
> The attached test proves it and passes on x86 both before and after 6.19,
> and on arm before 6.19, but fails on arm with 6.19. It pins the process to
> a single core and then has an rseq critical section that observes a change
> made by another thread which is supposed to be impossible. I think this
> will break basically any real usage of rseq, other than just reading the
> current cpu_id.
>
> An LLM pointed to these two specific commits in the refactor as causing
> this (oldest first):
> - 39a167560a61 rseq: Optimize event setting
> This assumed that user_irq would be set on preemption but it wasn't on
> arm64, so TIF_NOTIFY_RESUME isn't raised on same cpu preemption.
> - 566d8015f7ee rseq: Avoid CPU/MM CID updates when no event pending
> This broke TCMalloc slab caching trick by not overwriting cpu_id_start on
> every return to userspace
>
> (I have a lot more analysis and suggested fixes from LLMs since I used them
> heavily in this testing and analysis, but I won't spam you with the slop
> unless requested)
>
> The arm64 change is a clear breakage and I'm sure it will be
> uncontroversial to fix. I can imagine more resistance to reverting to the
> old behavior of always overwriting the cpu_id_start field since that seems
> to have been an intentional optimization choice. I have reached out to the
> TCMalloc maintainers (CC'd) and believe there is a solution that gets the
> vast majority of the optimization while still preserving the behavior that
> TCMalloc currently relies on[1].
>
> Any time a critical section might be aborted (migration, preemption, signal
> delivery, and membarrier IPI), the kernel already must (but doesn't on
> arm64 at the moment) check the rseq_cs field to see if the thread is in a
> critical section, and is documented as nulling the pointer after (I assume
> to make later checks cheaper). It would be sufficient for tcmalloc's
> internal usage if every time the kernel nulled out rseq_cs, it also wrote
> the cpu id to cpu_id_start. That should be essentially free since you are
> already writing to the same cache line. It was pointed out that that could
> be an issue if another rseq user in the same thread nulled rseq_cs after
> its critical section, which would require the kernel to update cpu_id_start
> each time it checks rseq_cs, regardless of whether it nulls it. We aren't
> aware of any processes that mix tcmalloc with other rseq usages that null
> out the field from userspace, but we can't rule them out since it is open
> source. Either way, this preserves the property of not updating
> cpu_id_start on every syscall return and non-membarrier interrupts, which I
> assume is where the majority of the optimization win was from.
>
> All testing of problematic versions was performed on x86_64 and
> aarch64 Ubuntu 24.04.4 with the kernel manually upgraded to
> 6.19.8-061908-generic. Source analysis was performed on the v6.19 tag. I
> had a few AI agents confirm that nothing in the relevant changes to master
> should have solved this, but I have not yet tested there.
>
> $ cat /proc/version
> Linux version 6.19.8-061908-generic (kernel@balboa)
> (aarch64-linux-gnu-gcc-15 (Ubuntu 15.2.0-15ubuntu1) 15.2.0, GNU ld (GNU
> Binutils for Ubuntu) 2.46) #202603131837 SMP PREEMPT_DYNAMIC Sat Mar 14
> 00:00:07 UTC 2026
>
> [1] There is also an exploration of some options to make tcmalloc not rely
> on the cpu_id_start overwriting. However we would strongly prefer that
> existing binaries continue to work on 6.19 kernels, even if newer binaries
> don't need that. At least for a good while.
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Peter Zijlstra @ 2026-04-22 13:13 UTC (permalink / raw)
To: Mathias Stearn
Cc: Thomas Gleixner, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Ingo Molnar,
Mark Rutland, Jinjie Ruan, Blake Oler
In-Reply-To: <20260422125647.GP3126523@noisy.programming.kicks-ass.net>
On Wed, Apr 22, 2026 at 02:56:47PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 22, 2026 at 11:50:26AM +0200, Mathias Stearn wrote:
>
> > Additionally, it breaks tcmalloc specifically by failing to overwrite
> > the cpu_id_start field at points where it was relied on for
> > correctness.
>
> This specific behaviour was documented as being wrong and running with
> DEBUG_RSEQ would have flagged it.
>
> The tcmalloc issue has been contentious for a long time. The tcmalloc
> folks relied on something that was documented to be wrong. It has been
> reported to the tcmalloc people many years ago and if you were to run
> tcmalloc on most any kernel (very much including 6.19) with
> DEBUG_RSEQ=y, it would have yelled.
>
> The tcmalloc people didn't care. There was a proposal for an RSEQ
> extension for what they need, and they didn't care. All this should be
> in their bugzilla or whatever.
>
> The RSEQ rework improved performance significantly for everyone, and
> kept all the documented behaviour (+- arm64 bug). Tcmalloc got screwed
> over because they relied on implementation behaviour that was
> specifically documented to be broken. And they didn't care. Google was
> very much aware of this. And hasn't lifted a finger to remedy it.
Also: https://lore.kernel.org/all/874io5andc.ffs@tglx/
^ permalink raw reply
* Re: [PATCH RFC 2/2] clk: scmi: Add support for two #clock-cells to pass rate rounding mode
From: Sudeep Holla @ 2026-04-22 13:14 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Sudeep Holla,
Krzysztof Kozlowski, Conor Dooley, Cristian Marussi, linux-kernel,
linux-clk, devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <20260306-scmi-clk-round-v1-2-61e2a5df9051@nxp.com>
On Fri, Mar 06, 2026 at 02:20:13PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> SCMI CLOCK_RATE_SET allows the caller to specify the rounding behaviour
> when setting a clock rate. The previously added dt-bindings header
> defines three modes:
>
> ROUND_DOWN / ROUND_UP / ROUND_AUTO
>
> To enable device tree clients to select a rounding mode, extend the
> SCMI clock provider to support "#clock-cells = <2>", where the second
> cell encodes the desired rounding mode. The default remains
> ROUND_DOWN for backwards compatibility with existing device trees.
>
Where is the binding update documented ? It's not in 1/2.
Also if it can be static in the device tree, why can't it be
autonomously handled in the platform firmware ? I think I know the
answer for this but I want to make sure it is a valid use-case and
gets documented here as part of binding updates.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH RFC 1/2] arm64: vdso: Prepare for robust futex unlock support
From: Thomas Weißschuh @ 2026-04-22 13:17 UTC (permalink / raw)
To: André Almeida
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, linux-arm-kernel, linux-kernel,
linux-arch, kernel-dev
In-Reply-To: <e0ee43e3-725c-4b99-80b3-956d24beb1c7@t-8ch.de>
On 2026-04-22 15:02:45+0200, Thomas Weißschuh wrote:
> On 2026-04-17 11:56:10-0300, André Almeida wrote:
> > There will be a VDSO function to unlock non-contended robust futexes in
> > user space. The unlock sequence is racy vs. clearing the list_pending_op
> > pointer in the task's robust list head. To plug this race the kernel needs
> > to know the critical section window so it can clear the pointer when the
> > task is interrupted within that race window. The window is determined by
> > labels in the inline assembly.
> >
> > Signed-off-by: André Almeida <andrealmeid@igalia.com>
> > ---
> > RFC: Those symbols can't be found by the linker after patch 2/2, it fails with:
> >
> > ld: arch/arm64/kernel/vdso.o: in function `vdso_futex_robust_unlock_update_ips':
> > arch/arm64/kernel/vdso.c:72:(.text+0x200): undefined reference to `__futex_list64_try_unlock_cs_success'
> > ld: arch/arm64/kernel/vdso.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__futex_list64_try_unlock_cs_success' which may bind externally can not be used when making a shared object; recompile with -fPIC
> > arch/arm64/kernel/vdso.c:72:(.text+0x200): dangerous relocation: unsupported relocation
>
> arch/arm64/kernel/vdso.o is a kernel object.
> __futex_list64_try_unlock_cs_success is a vDSO symbol.
> They live in wholly different objects, which are never linked together.
> Look at VDSO_SYMBOL() to get the offset of the vDSO symbol in kernel code.
>
> (...)
The diff below shows the idea. Compat code is not fixed, and I didn't
even try to run it. Also please use CONFIG_COMPAT_VDSO over plain
CONFIG_COMPAT.
diff --git a/arch/arm64/include/asm/vdso.h b/arch/arm64/include/asm/vdso.h
index 182fde1df3dd..232b46969088 100644
--- a/arch/arm64/include/asm/vdso.h
+++ b/arch/arm64/include/asm/vdso.h
@@ -18,10 +18,6 @@
extern char vdso_start[], vdso_end[];
extern char vdso32_start[], vdso32_end[];
-extern char __futex_list64_try_unlock_cs_success[], __futex_list64_try_unlock_cs_end[];
-#ifdef CONFIG_COMPAT
-extern char __futex_list32_try_unlock_cs_success[], __futex_list32_try_unlock_cs_end[];
-#endif
#endif /* !__ASSEMBLER__ */
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 42a82e73a774..45eb1aa627a2 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -64,21 +64,17 @@ static void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_str
unsigned long vdso = (unsigned long) mm->context.vdso;
struct futex_mm_data *fd = &mm->futex;
- /*
- * RFC: won't compile due to undefined reference to `__futex_list64_try_unlock_cs_...`
-
if (abi == VDSO_ABI_AA64) {
- futex_set_vdso_cs_range(fd, 0, vdso, (uintptr_t) __futex_list64_try_unlock_cs_success,
- (uintptr_t) __futex_list64_try_unlock_cs_end, false);
+ futex_set_vdso_cs_range(fd, 0, vdso, (uintptr_t)VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_success),
+ (uintptr_t)VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_end), false);
}
-#ifdef CONFIG_COMPAT
+#ifdef CONFIG_COMPAT_VDSO
if (abi == VDSO_ABI_AA32) {
futex_set_vdso_cs_range(fd, 1, vdso, (uintptr_t) __futex_list32_try_unlock_cs_success,
(uintptr_t) __futex_list32_try_unlock_cs_end, true);
}
#endif
- */
}
#else
static inline void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm) { }
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
index 33ce58516580..a17e6eab9d3f 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -116,3 +116,5 @@ VERSION
* Make the sigreturn code visible to the kernel.
*/
VDSO_sigtramp = __kernel_rt_sigreturn;
+VDSO_futex_list64_try_unlock_cs_success = __futex_list64_try_unlock_cs_success;
+VDSO_futex_list64_try_unlock_cs_end = __futex_list64_try_unlock_cs_end;
^ permalink raw reply related
* [PATCH v6 00/13] fix several inconsistencies with sysfs configuration in etmX
From: Yeoreum Yun @ 2026-04-22 13:21 UTC (permalink / raw)
To: coresight, linux-arm-kernel, linux-kernel
Cc: suzuki.poulose, mike.leach, james.clark, alexander.shishkin,
leo.yan, jie.gan, Yeoreum Yun
The current ETMx configuration via sysfs can lead to the following
inconsistencies:
- If a configuration is modified via sysfs while a perf session is
active, the running configuration may differ between before
a sched-out and after a subsequent sched-in.
- If a perf session and sysfs session tries to enable concurrently,
configuration from configfs could be corrupted (etm4).
- There is chance to corrupt drvdata->config if perf session tries
to enabled among handling cscfg_csdev_disable_active_config()
in etm4_disable_sysfs() (etm4).
To resolve these inconsistencies, the configuration should be separated into:
- active_config, which is applied configuration for the current session
- config, which stores the settings configured via sysfs.
and apply configuration from configfs after taking a mode.
Also, This patch set includes some small fixes:
- missing trace id release in etm4x.
- underflow issue for nrseqstate.
- wrong check in etm4x_sspcicrn_present().
- missing call of cscfg_csdev_disable_active_config()
This patch based on v7.0
Patch History
=============
from v5 to v6:
- fix missing of calling cscfg_csdev_disable_active_config()
- add rb & fixes tags.
- add ss_status field in etm4x_drvdata to expose STATUS and PENDING bits.
- https://lore.kernel.org/all/20260415165528.3369607-1-yeoreum.yun@arm.com/
from v4 to v5:
- add rb-tag.
- fix underflow issue for nrseqstate.
- fix wrong check in etm4_sspcicrn_present().
- remove redundant fields on etmv4_save_state.
- rename caps->ss_status to ss_cmp.
- fix wrong location of etm4_release_trace_id.
- https://lore.kernel.org/all/20260413142003.3549310-1-yeoreum.yun@arm.com/
from v3 to v4:
- change etm_drvdata->spinlock type to raw_spin_lock_t
- remove redundant call etmX_enable_hw() with starting_cpu() callsback.
- fix missing trace id release.
- add missing docs.
- https://lore.kernel.org/all/20260412175506.412301-1-yeoreum.yun@arm.com/
from v2 to v3:
- fix build error for etm3x.
- fix checkpatch warning.
- https://lore.kernel.org/all/20260410074310.2693385-1-yeoreum.yun@arm.com/
from v1 to v2
- rebased to v7.0-rc7.
- introduce etmX_caps structure to save etmX's capabilities.
- remove ss_status from etmv4_config.
- modify active_config after taking a mode (perf/sysfs).
- https://lore.kernel.org/all/20260317181705.2456271-1-yeoreum.yun@arm.com/
Yeoreum Yun (13):
coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()
coresight: etm4x: fix underflow for nrseqstate
coresight: etm4x: introduce struct etm4_caps
coresight: etm4x: exclude ss_status from drvdata->config
coresight: etm4x: remove redundant fields in etmv4_save_state
coresight: etm4x: fix leaked trace id
coresight: etm4x: fix inconsistencies with sysfs configuration
coresight: etm4x: remove redundant call etm4_enable_hw() with hotplug
coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf
enable
coresight: etm3x: change drvdata->spinlock type to raw_spin_lock_t
coresight: etm3x: introduce struct etm_caps
coresight: etm3x: fix inconsistencies with sysfs configuration
coresight: etm3x: remove redundant call etm_enable_hw() with hotplug
drivers/hwtracing/coresight/coresight-etm.h | 46 ++-
.../coresight/coresight-etm3x-core.c | 101 ++---
.../coresight/coresight-etm3x-sysfs.c | 159 +++----
.../hwtracing/coresight/coresight-etm4x-cfg.c | 3 +-
.../coresight/coresight-etm4x-core.c | 388 ++++++++++--------
.../coresight/coresight-etm4x-sysfs.c | 202 +++++----
drivers/hwtracing/coresight/coresight-etm4x.h | 190 +++++----
7 files changed, 606 insertions(+), 483 deletions(-)
base-commit: 028ef9c96e96197026887c0f092424679298aae8
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply
* [PATCH v6 01/13] coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()
From: Yeoreum Yun @ 2026-04-22 13:21 UTC (permalink / raw)
To: coresight, linux-arm-kernel, linux-kernel
Cc: suzuki.poulose, mike.leach, james.clark, alexander.shishkin,
leo.yan, jie.gan, Yeoreum Yun
In-Reply-To: <20260422132203.977549-1-yeoreum.yun@arm.com>
According to Embedded Trace Macrocell Architecture Specification
ETMv4.0 to ETM4.6 [0], TRCSSPCICR<n> is present only if all of
the following are true:
- TRCIDR4.NUMSSCC > n.
- TRCIDR4.NUMPC > 0b0000.
- TRCSSCSR<n>.PC == 0b1.
Comment for etm4x_sspcicrn_present() is align with the specification.
However, the check should use drvdata->nr_pe_cmp to check TRCIDR4.NUMPC
not nr_pe.
Link: https://developer.arm.com/documentation/ihi0064/latest/ [0]
Fixes: f6a18f354c58 ("coresight: etm4x: Handle access to TRCSSPCICRn")
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index d565a73f0042..74b7063d130e 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -89,7 +89,7 @@ static int etm4_probe_cpu(unsigned int cpu);
static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n)
{
return (n < drvdata->nr_ss_cmp) &&
- drvdata->nr_pe &&
+ drvdata->nr_pe_cmp &&
(drvdata->config.ss_status[n] & TRCSSCSRn_PC);
}
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply related
* [PATCH v6 02/13] coresight: etm4x: fix underflow for nrseqstate
From: Yeoreum Yun @ 2026-04-22 13:21 UTC (permalink / raw)
To: coresight, linux-arm-kernel, linux-kernel
Cc: suzuki.poulose, mike.leach, james.clark, alexander.shishkin,
leo.yan, jie.gan, Yeoreum Yun
In-Reply-To: <20260422132203.977549-1-yeoreum.yun@arm.com>
TCRSEQEVR<n> is implemented only when TCRIDR5.NUMSEQSTATE is 0b100,
in which case n ranges from 0 to 2; otherwise, TCRIDR5.NUMSEQSTATE is 0b000.
Therefore, drvdata->nrseqstate should be checked before entering the loop.
Link: https://developer.arm.com/documentation/ihi0064/latest/ [0]
Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver")
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
.../hwtracing/coresight/coresight-etm4x-core.c | 18 ++++++++++--------
.../coresight/coresight-etm4x-sysfs.c | 2 ++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 74b7063d130e..ba5b8b423bd4 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -544,9 +544,11 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
etm4x_relaxed_write32(csa, config->vissctlr, TRCVISSCTLR);
if (drvdata->nr_pe_cmp)
etm4x_relaxed_write32(csa, config->vipcssctlr, TRCVIPCSSCTLR);
- for (i = 0; i < drvdata->nrseqstate - 1; i++)
- etm4x_relaxed_write32(csa, config->seq_ctrl[i], TRCSEQEVRn(i));
+
if (drvdata->nrseqstate) {
+ for (i = 0; i < drvdata->nrseqstate - 1; i++)
+ etm4x_relaxed_write32(csa, config->seq_ctrl[i], TRCSEQEVRn(i));
+
etm4x_relaxed_write32(csa, config->seq_rst, TRCSEQRSTEVR);
etm4x_relaxed_write32(csa, config->seq_state, TRCSEQSTR);
}
@@ -1927,10 +1929,10 @@ static int __etm4_cpu_save(struct etmv4_drvdata *drvdata)
if (drvdata->nr_pe_cmp)
state->trcvipcssctlr = etm4x_read32(csa, TRCVIPCSSCTLR);
- for (i = 0; i < drvdata->nrseqstate - 1; i++)
- state->trcseqevr[i] = etm4x_read32(csa, TRCSEQEVRn(i));
-
if (drvdata->nrseqstate) {
+ for (i = 0; i < drvdata->nrseqstate - 1; i++)
+ state->trcseqevr[i] = etm4x_read32(csa, TRCSEQEVRn(i));
+
state->trcseqrstevr = etm4x_read32(csa, TRCSEQRSTEVR);
state->trcseqstr = etm4x_read32(csa, TRCSEQSTR);
}
@@ -2058,10 +2060,10 @@ static void __etm4_cpu_restore(struct etmv4_drvdata *drvdata)
if (drvdata->nr_pe_cmp)
etm4x_relaxed_write32(csa, state->trcvipcssctlr, TRCVIPCSSCTLR);
- for (i = 0; i < drvdata->nrseqstate - 1; i++)
- etm4x_relaxed_write32(csa, state->trcseqevr[i], TRCSEQEVRn(i));
-
if (drvdata->nrseqstate) {
+ for (i = 0; i < drvdata->nrseqstate - 1; i++)
+ etm4x_relaxed_write32(csa, state->trcseqevr[i], TRCSEQEVRn(i));
+
etm4x_relaxed_write32(csa, state->trcseqrstevr, TRCSEQRSTEVR);
etm4x_relaxed_write32(csa, state->trcseqstr, TRCSEQSTR);
}
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
index e9eeea6240d5..0e1ad175aa1e 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
@@ -1395,6 +1395,8 @@ static ssize_t seq_idx_store(struct device *dev,
struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
struct etmv4_config *config = &drvdata->config;
+ if (!drvdata->nrseqstate)
+ return -ENOTSUPP;
if (kstrtoul(buf, 16, &val))
return -EINVAL;
if (val >= drvdata->nrseqstate - 1)
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ 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