* Re: [PATCH 2/3] [v5 net-next] p54spi: convert to devicetree
From: Arnd Bergmann @ 2026-05-11 19:45 UTC (permalink / raw)
To: Simon Horman, Arnd Bergmann
Cc: Netdev, Aaro Koskinen, Andreas Kemnade, Bartosz Golaszewski,
Benoît Cousson, David S . Miller, Dmitry Torokhov,
Eric Dumazet, Felipe Balbi, Jakub Kicinski, Johannes Berg,
Kevin Hilman, krzk+dt, Linus Walleij, Paolo Abeni, Rob Herring,
Roger Quadros, Tony Lindgren, linux-wireless, devicetree,
linux-kernel, linux-arm-kernel, open list:GPIO SUBSYSTEM,
Linux-OMAP, Krzysztof Kozlowski
In-Reply-To: <20260511161243.49098-3-horms@kernel.org>
On Mon, May 11, 2026, at 18:12, Simon Horman wrote:
>
> Simon says: As a pre-existing issue I don't think we need to be concerned
> about this in the scope of this patch-set. But it may
> be a potential for follow-up.
>
> This problem wasn't introduced by this patch, but I noticed a pre-existing
> issue in the context here. Does the p54spi_spi_read() function perform an SPI
> transfer using a stack-allocated buffer?
>
> Looking at p54spi_spi_read(), the addr variable is allocated on the stack and
> passed as a transfer buffer to spi_sync(). The SPI framework maps transfer
> buffers for DMA. Passing a stack-allocated buffer is illegal, particularly with
> CONFIG_VMAP_STACK enabled, because stack memory resides in vmalloc space and
> cannot be safely DMA-mapped.
>
> Could this cause memory corruption or a kernel panic during the transfer?
I already commented on this earlier: This is indeed a theoretical
bug, but it works in practice because DMA-capable SPI controllers
tend to all use MMIO for short transfers instead of DMA.
SPI is very fragile this way, and I do have some patches to improve
that overall, but it seems out of scope for this one driver.
>> -
>> - gpio_direction_output(p54spi_gpio_power, 0);
>> - gpio_direction_input(p54spi_gpio_irq);
>> -
>> - ret = request_irq(gpio_to_irq(p54spi_gpio_irq),
>> - p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi",
>> - priv->spi);
>> + ret = request_irq(spi->irq, p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi", priv->spi);
>
> Simon says: This one seems more concerning in the context of this patch-set.
>
> Is there missing validation for spi->irq before calling request_irq()?
>
> If the device tree node lacks an interrupts property, the SPI core may set
> spi->irq to 0 or a negative error code.
>
> Passing this directly to request_irq() without validation can successfully
> hijack a core system interrupt like the system timer on some architectures,
> leading to system instability or deadlocks.
>
> Should there be a check like if (spi->irq <= 0) to fail the probe gracefully?
I also commented on this: request_irq() already fails gracefully
with -EINVAL when presented with an invalid IRQ. IRQ 0 is guaranteed
to be invalid on any target that uses devicetree.
Arnd
^ permalink raw reply
* Re: [PATCH v3 0/4] ARM: pxa: attach software nodes to the GPIO controllers
From: Linus Walleij @ 2026-05-11 19:53 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bartosz Golaszewski, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Russell King, Dmitry Torokhov, Arnd Bergmann, linux-arm-kernel,
linux-gpio, linux-kernel
In-Reply-To: <CAMRc=Md7EdfvNV+6NRZK0UkNXcYp3uR4N4buKH6NeKKg_rnt-w@mail.gmail.com>
On Mon, May 11, 2026 at 3:35 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
> On Thu, Apr 30, 2026 at 2:57 PM Bartosz Golaszewski
> <bartosz.golaszewski@oss.qualcomm.com> wrote:
> >
> > Convert GPIO controllers and their consumers on the PXA platform to using
> > "attached" software nodes. Since everything happens in a bord-file, it's
> > quite straightforward. We technically now have a way of passing an
> > unregistered software node to platform_device_register_full() but that
> > requires using struct platform_device_info and since the existing
> > platform devices are either referenced from other places or defined in a
> > different compilation unit, I wanted to reduce the impact of the changes
> > I can't test and went with the older method.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > ---
>
> If there are no other comments, can this be queued for v7.2?
Are you planning to queue it in the GPIO tree? (I would.)
Otherwise just send a pull request to the SoC tree, I would not
expect the PXA maintainers to be very active and stacking patches
and sending pull requests. But they might surprise me!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/1] pinctrl: imx1: Allow parsing DT without function nodes
From: Linus Walleij @ 2026-05-11 19:56 UTC (permalink / raw)
To: Frank Li
Cc: Dong Aisheng, open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
NXP S32 Linux Team, Jacky Bai, Sascha Hauer, open list,
open list:PIN CONTROLLER - FREESCALE, Pengutronix Kernel Team,
Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260505160902.1425532-1-Frank.Li@nxp.com>
On Tue, May 5, 2026 at 6:09 PM Frank Li <Frank.Li@nxp.com> wrote:
> The old format to define pinctrl settings for imx in DT has two hierarchy
> levels. The first level are function device nodes. The second level are
> pingroups which contain a property fsl,pins. The original ntention was to
> define all pin functions in a single dtsi file and just reference the
> correct ones in the board files.
>
> The commit ("5fcdf6a7ed95e pinctrl: imx: Allow parsing DT without function
> nodes") already make moden i.MX chip support flatten layout.
>
> Make legacy chipes (more than 15 years) support this flatten layout also.
>
> Fixes: e948cbdc41d6f ("ARM: dts: imx: remove redundant intermediate node in pinmux hierarchy")
> Tested-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
No reaction from other i.MX maintainers but OK, patch applied for fixes!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] pinctrl: mediatek: common-v1: bypass pinctrl GPIO layer in set GPIO direction
From: Linus Walleij @ 2026-05-11 20:01 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
linux-mediatek, linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260505104056.1812343-1-wenst@chromium.org>
On Tue, May 5, 2026 at 12:41 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
> pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take
> the pinctrl mutex. This causes a gpiochip operations to need to sleep.
> Worse yet, the .can_sleep field in the gpiochip is not set. This causes
> the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check
> whether it can use a spinlock or needs a mutex. In this case, it ends
> up taking a spinlock, then calls pinctrl_gpio_direction_output(), which
> takes a mutex. This causes a huge warning.
>
> Since the Mediatek hardware has separate clear/set registers, there is
> no risk of clobbering other bits like with a read-modify-write pattern.
> Also, once the GPIO function is selected / muxed in, further GPIO
> operations do not involve pinctrl operations or state. The GPIO direction
> and level values do not require toggling the pinmux or any other pin config
> options.
>
> Switch to directly calling mtk_pmx_gpio_set_direction() in the GPIO set
> direction callbacks to avoid taking the pinctrl mutex. Drop the
> .gpio_set_direction field in mtk_pmx_ops to signal we are no longer using
> the pinctrl GPIO layer for setting the direction.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction
From: Linus Walleij @ 2026-05-11 20:00 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
linux-mediatek, linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260505104003.1811841-1-wenst@chromium.org>
On Tue, May 5, 2026 at 12:40 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
> pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take
> the pinctrl mutex. This causes a gpiochip operations to need to sleep.
> Worse yet, the .can_sleep field in the gpiochip is not set. This causes
> the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check
> whether it can use a spinlock or needs a mutex. In this case, it ends
> up taking a spinlock, then calls pinctrl_gpio_direction_output(), which
> takes a mutex. This causes a huge warning.
>
> While this class of Mediatek hardware does not have separate clear/set
> registers, the pinctrl context has a spinlock that is taken whenever
> a register read-modify-write is done. Also, once the GPIO function is
> selected / muxed in, further GPIO operations do not involve pinctrl
> operations or state. The GPIO direction and level values do not require
> toggling the pinmux or any other pin config options.
>
> Switch to directly calling mtk_pinmux_gpio_set_direction() in the GPIO
> set direction callbacks to avoid taking the pinctrl mutex. Drop the
> .gpio_set_direction field in mtk_pmxops to signal we are no longer using
> the pinctrl GPIO layer for setting the direction.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Patch applied, thanks for your perseverance Chen-Yu!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v9 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Linus Walleij @ 2026-05-11 20:03 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Bartosz Golaszewski, Ryan Chen,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, openbmc, linux-gpio, linux-clk
In-Reply-To: <20260506-upstream_pinctrl-v9-1-0636e22343ad@aspeedtech.com>
On Wed, May 6, 2026 at 10:12 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> Add a device tree binding for the pin controller found in the
> ASPEED AST2700 SoC0.
>
> The controller manages various peripheral functions such as eMMC, USB,
> VGA DDC, JTAG, and PCIe root complex signals.
>
> Describe the AST2700 SoC0 pin controller using standard pin multiplexing
> and configuration properties.
>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v9 2/3] dt-bindings: mfd: aspeed,ast2x00-scu: Describe AST2700 SCU0
From: Linus Walleij @ 2026-05-11 20:04 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Bartosz Golaszewski, Ryan Chen,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, openbmc, linux-gpio, linux-clk
In-Reply-To: <20260506-upstream_pinctrl-v9-2-0636e22343ad@aspeedtech.com>
On Wed, May 6, 2026 at 10:07 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> AST2700 consists of two interconnected SoC instances, each with its own
> System Control Unit (SCU). The SCU0 provides pin control, interrupt
> controllers, clocks, resets, and address-space mappings for the
> Secondary and Tertiary Service Processors (SSP and TSP).
>
> Describe the SSP/TSP address mappings using the standard
> memory-region and memory-region-names properties.
>
> Disallow legacy child nodes that are not present on AST2700, including
> p2a-control and smp-memram. The latter is unnecessary as software can
> access the scratch registers via the SCU syscon.
>
> Also allow the AST2700 SoC0 pin controller to be described as a child
> node of the SCU0, and add an example illustrating the SCU0 layout,
> including reserved-memory, interrupt controllers, and pinctrl.
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
This is an MFD patch in the middle of a pinctrl series, I think Lee
should apply this.
FWIW:
Acked-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v9 0/3] pinctrl: aspeed: Add AST2700 SoC0 support
From: Linus Walleij @ 2026-05-11 20:05 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Bartosz Golaszewski, Ryan Chen,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, openbmc, linux-gpio, linux-clk
In-Reply-To: <20260506-upstream_pinctrl-v9-0-0636e22343ad@aspeedtech.com>
On Wed, May 6, 2026 at 10:12 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> AST2700 is composed of two interconnected SoC instances, each providing
> its own pin control hardware. This series introduces bindings describing
> the AST2700 pinctrl architecture and adds pinctrl driver support for the
> SoC0 instance.
>
> The bindings document the AST2700 dual-SoC design and follow common
> pinctrl conventions, while the SoC0 driver implementation builds upon
> the existing ASPEED pinctrl infrastructure.
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: mediatek: mt8188: allow gpio hogs
From: Linus Walleij @ 2026-05-11 20:10 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Hui Liu, linux-gpio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260504072748.2580172-1-zhengxingda@iscas.ac.cn>
On Mon, May 4, 2026 at 9:28 AM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
> Add gpio hogs subnode rules to the MT8188 pinctrl binding.
>
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
This patch 1/2 applied to the pinctrl tree.
Please funnel patch 2/2 through the SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 4/9] dt-bindings: pinctrl: mediatek,mt65xx: Add MT6392 pinctrl
From: Linus Walleij @ 2026-05-11 20:12 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, AngeloGioacchino Del Regno, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Liam Girdwood, Mark Brown, Louis-Alexis Eyraud, Gary Bisson,
Val Packett, Julien Massot, Fabien Parent, Akari Tsuyukusa,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-5-l.scorcia@gmail.com>
On Mon, Apr 20, 2026 at 11:37 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> Add a compatible for the pinctrl device of the MT6392 PMIC, a variant of
> the already supported MT6397.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
This patch 4/9 applied to the pinctrl tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm64: Implement _THIS_IP_ using inline asm
From: Marco Elver @ 2026-05-11 20:16 UTC (permalink / raw)
To: elver, Catalin Marinas, Will Deacon
Cc: Thomas Huth, Nathan Chancellor, Kees Cook, Vlastimil Babka,
Harry Yoo, linux-arm-kernel, linux-kernel, kasan-dev
Both GCC [1] and Clang [2] consider the generic version of _THIS_IP_ to
be broken:
#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
In particular, the address of a label is only expected to be used with a
computed goto.
While the generic version more or less works today, it is known to be
brittle and may break with current and future optimizations. For
example, Clang -O2 always returns 1 when this function is inlined:
static inline unsigned long get_ip(void)
{ return ({ __label__ __here; __here: (unsigned long)&&__here; }); }
Fix it by overriding _THIS_IP_ in <asm/linkage.h> (which is included by
<linux/instruction_pointer.h>) using an architecture-specific inline asm
version. Additionally, avoiding taking the address of a label prevents
compilers from emitting spurious indirect branch targets (e.g. ENDBR or
BTI) under control-flow integrity schemes.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071 [1]
Link: https://github.com/llvm/llvm-project/issues/138272 [2]
Signed-off-by: Marco Elver <elver@google.com>
---
arch/arm64/include/asm/linkage.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h
index 40bd17add539..73eabc82a6bb 100644
--- a/arch/arm64/include/asm/linkage.h
+++ b/arch/arm64/include/asm/linkage.h
@@ -43,4 +43,6 @@
SYM_TYPED_START(name, SYM_L_GLOBAL, SYM_A_ALIGN) \
bti c ;
+#define _THIS_IP_ ({ unsigned long __ip; asm volatile("adr %0, ." : "=r" (__ip)); __ip; })
+
#endif
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [soc:soc/dt] BUILD SUCCESS b133e22edd5c4d43398b0656063457e7ccf32778
From: kernel test robot @ 2026-05-11 20:24 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/dt
branch HEAD: b133e22edd5c4d43398b0656063457e7ccf32778 ARM: dts: ixp4xx: use phandle-based GPIOs in mi424wr
elapsed time: 726m
configs tested: 267
configs skipped: 134
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260511 gcc-10.5.0
arc randconfig-002-20260511 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260511 gcc-10.5.0
arm randconfig-002-20260511 gcc-10.5.0
arm randconfig-003-20260511 gcc-10.5.0
arm randconfig-004-20260511 gcc-10.5.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260511 clang-17
arm64 randconfig-001-20260511 clang-23
arm64 randconfig-001-20260512 gcc-14.3.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260511 clang-17
arm64 randconfig-002-20260511 clang-23
arm64 randconfig-002-20260512 gcc-14.3.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260511 clang-17
arm64 randconfig-003-20260511 clang-23
arm64 randconfig-003-20260512 gcc-14.3.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260511 clang-17
arm64 randconfig-004-20260511 clang-23
arm64 randconfig-004-20260512 gcc-14.3.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 clang-23
csky randconfig-001-20260511 clang-17
csky randconfig-001-20260511 clang-23
csky randconfig-001-20260512 gcc-14.3.0
csky randconfig-002 clang-23
csky randconfig-002-20260511 clang-17
csky randconfig-002-20260511 clang-23
csky randconfig-002-20260512 gcc-14.3.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260511 gcc-8.5.0
hexagon randconfig-001-20260512 gcc-10.5.0
hexagon randconfig-002-20260511 gcc-8.5.0
hexagon randconfig-002-20260512 gcc-10.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260511 gcc-14
i386 buildonly-randconfig-002-20260511 gcc-14
i386 buildonly-randconfig-003-20260511 gcc-14
i386 buildonly-randconfig-004-20260511 gcc-14
i386 buildonly-randconfig-005-20260511 gcc-14
i386 buildonly-randconfig-006-20260511 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260511 gcc-12
i386 randconfig-002-20260511 gcc-12
i386 randconfig-003-20260511 gcc-12
i386 randconfig-004-20260511 gcc-12
i386 randconfig-005-20260511 gcc-12
i386 randconfig-006-20260511 gcc-12
i386 randconfig-007-20260511 gcc-12
i386 randconfig-011 clang-20
i386 randconfig-011-20260511 clang-20
i386 randconfig-011-20260512 clang-20
i386 randconfig-012 clang-20
i386 randconfig-012-20260511 clang-20
i386 randconfig-012-20260512 clang-20
i386 randconfig-013 clang-20
i386 randconfig-013-20260511 clang-20
i386 randconfig-013-20260512 clang-20
i386 randconfig-014 clang-20
i386 randconfig-014-20260511 clang-20
i386 randconfig-014-20260512 clang-20
i386 randconfig-015 clang-20
i386 randconfig-015-20260511 clang-20
i386 randconfig-015-20260512 clang-20
i386 randconfig-016 clang-20
i386 randconfig-016-20260511 clang-20
i386 randconfig-016-20260512 clang-20
i386 randconfig-017 clang-20
i386 randconfig-017-20260511 clang-20
i386 randconfig-017-20260512 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260511 gcc-8.5.0
loongarch randconfig-001-20260512 gcc-10.5.0
loongarch randconfig-002-20260511 gcc-8.5.0
loongarch randconfig-002-20260512 gcc-10.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips jazz_defconfig clang-17
mips maltaup_xpa_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260511 gcc-8.5.0
nios2 randconfig-001-20260512 gcc-10.5.0
nios2 randconfig-002-20260511 gcc-8.5.0
nios2 randconfig-002-20260512 gcc-10.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001 clang-20
parisc randconfig-001-20260511 clang-20
parisc randconfig-002 clang-20
parisc randconfig-002-20260511 clang-20
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc arches_defconfig gcc-15.2.0
powerpc randconfig-001 clang-20
powerpc randconfig-001-20260511 clang-20
powerpc randconfig-002 clang-20
powerpc randconfig-002-20260511 clang-20
powerpc64 randconfig-001 clang-20
powerpc64 randconfig-001-20260511 clang-20
powerpc64 randconfig-002 clang-20
powerpc64 randconfig-002-20260511 clang-20
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-12.5.0
riscv randconfig-001-20260511 gcc-12.5.0
riscv randconfig-001-20260512 gcc-15.2.0
riscv randconfig-002 gcc-12.5.0
riscv randconfig-002-20260511 gcc-12.5.0
riscv randconfig-002-20260512 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-12.5.0
s390 randconfig-001-20260511 gcc-12.5.0
s390 randconfig-001-20260512 gcc-15.2.0
s390 randconfig-002 gcc-12.5.0
s390 randconfig-002-20260511 gcc-12.5.0
s390 randconfig-002-20260512 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001 gcc-12.5.0
sh randconfig-001-20260511 gcc-12.5.0
sh randconfig-001-20260512 gcc-15.2.0
sh randconfig-002 gcc-12.5.0
sh randconfig-002-20260511 gcc-12.5.0
sh randconfig-002-20260512 gcc-15.2.0
sh se7751_defconfig gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001 gcc-8.5.0
sparc randconfig-001-20260511 gcc-8.5.0
sparc randconfig-002 gcc-8.5.0
sparc randconfig-002-20260511 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-8.5.0
sparc64 randconfig-001-20260511 gcc-8.5.0
sparc64 randconfig-002 gcc-8.5.0
sparc64 randconfig-002-20260511 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-8.5.0
um randconfig-001-20260511 gcc-8.5.0
um randconfig-002 gcc-8.5.0
um randconfig-002-20260511 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260511 gcc-14
x86_64 buildonly-randconfig-001-20260512 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260511 gcc-14
x86_64 buildonly-randconfig-002-20260512 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260511 gcc-14
x86_64 buildonly-randconfig-003-20260512 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260511 gcc-14
x86_64 buildonly-randconfig-004-20260512 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260511 gcc-14
x86_64 buildonly-randconfig-005-20260512 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260511 gcc-14
x86_64 buildonly-randconfig-006-20260512 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001 clang-20
x86_64 randconfig-001-20260511 clang-20
x86_64 randconfig-001-20260512 gcc-14
x86_64 randconfig-002 clang-20
x86_64 randconfig-002-20260511 clang-20
x86_64 randconfig-002-20260512 gcc-14
x86_64 randconfig-003 clang-20
x86_64 randconfig-003-20260511 clang-20
x86_64 randconfig-003-20260512 gcc-14
x86_64 randconfig-004 clang-20
x86_64 randconfig-004-20260511 clang-20
x86_64 randconfig-004-20260512 gcc-14
x86_64 randconfig-005 clang-20
x86_64 randconfig-005-20260511 clang-20
x86_64 randconfig-005-20260512 gcc-14
x86_64 randconfig-006 clang-20
x86_64 randconfig-006-20260511 clang-20
x86_64 randconfig-006-20260512 gcc-14
x86_64 randconfig-011 clang-20
x86_64 randconfig-011-20260511 clang-20
x86_64 randconfig-012 clang-20
x86_64 randconfig-012-20260511 clang-20
x86_64 randconfig-013 clang-20
x86_64 randconfig-013-20260511 clang-20
x86_64 randconfig-014 clang-20
x86_64 randconfig-014-20260511 clang-20
x86_64 randconfig-015 clang-20
x86_64 randconfig-015-20260511 clang-20
x86_64 randconfig-016 clang-20
x86_64 randconfig-016-20260511 clang-20
x86_64 randconfig-071-20260511 clang-20
x86_64 randconfig-072-20260511 clang-20
x86_64 randconfig-073-20260511 clang-20
x86_64 randconfig-074-20260511 clang-20
x86_64 randconfig-075-20260511 clang-20
x86_64 randconfig-076-20260511 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa iss_defconfig gcc-15.2.0
xtensa randconfig-001 gcc-8.5.0
xtensa randconfig-001-20260511 gcc-8.5.0
xtensa randconfig-002 gcc-8.5.0
xtensa randconfig-002-20260511 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 0/2] pinctrl: add support amlogic a9
From: Linus Walleij @ 2026-05-11 20:26 UTC (permalink / raw)
To: xianwei.zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, linux-amlogic,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260507-a9-pinctrl-v2-0-49774feff2ef@amlogic.com>
On Thu, May 7, 2026 at 10:21 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
> Add pinctrl bindings and driver about for amlogic a9.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Patches applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Linus Walleij @ 2026-05-11 20:34 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <agIwOYrKXlnKbpII@lizhi-Precision-Tower-5810>
On Mon, May 11, 2026 at 9:38 PM Frank Li <Frank.li@nxp.com> wrote:
> I fixed a build warning by missing doc 'np',
> https://lore.kernel.org/imx/20260507152117.240612-1-Frank.Li@nxp.com/
>
> Anything need me to do futher?
Sorry was busy!
Applied this fixup on top of the branch and merged it into my
devel branch for v7.2!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] clk: rockchip: Use flexible array for clock table
From: Brian Masney @ 2026-05-11 20:41 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Heiko Stuebner,
moderated list:ARM/Rockchip SoC support,
open list:ARM/Rockchip SoC support, open list,
Gustavo A. R. Silva
In-Reply-To: <CAKxU2N-nEx-=KFh9djQRGZVTR_HJTSrJYzAa8NR+4QcNvbkxqw@mail.gmail.com>
+ Gustavo
On Mon, May 11, 2026 at 12:08:56PM -0700, Rosen Penev wrote:
> On Mon, May 11, 2026 at 9:06 AM Brian Masney <bmasney@redhat.com> wrote:
> >
> > Hi Rosen,
> >
> > On Sun, May 10, 2026 at 08:22:52PM -0700, Rosen Penev wrote:
> > > Store the clock lookup table in the Rockchip clock provider
> > > allocation instead of allocating it separately.
> > >
> > > This ties the table lifetime directly to the provider and removes a
> > > separate allocation failure path while preserving the clk_onecell_data
> > > lookup interface.
> > >
> > > Assisted-by: Codex:GPT-5.5
> > > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > > ---
> > > drivers/clk/rockchip/clk.c | 17 ++++-------------
> > > drivers/clk/rockchip/clk.h | 2 ++
> > > 2 files changed, 6 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
> > > index ee8c79b938d3..dbb4b6f33abb 100644
> > > --- a/drivers/clk/rockchip/clk.c
> > > +++ b/drivers/clk/rockchip/clk.c
> > > @@ -359,26 +359,21 @@ static struct rockchip_clk_provider *rockchip_clk_init_base(
> > > unsigned long nr_clks, bool has_late_clocks)
> > > {
> > > struct rockchip_clk_provider *ctx;
> > > - struct clk **clk_table;
> > > struct clk *default_clk_val;
> > > int i;
> > >
> > > default_clk_val = ERR_PTR(has_late_clocks ? -EPROBE_DEFER : -ENOENT);
> > >
> > > - ctx = kzalloc_obj(struct rockchip_clk_provider);
> > > + ctx = kzalloc_flex(*ctx, clk_table, nr_clks);
> > > if (!ctx)
> > > return ERR_PTR(-ENOMEM);
> > >
> > > - clk_table = kzalloc_objs(struct clk *, nr_clks);
> > > - if (!clk_table)
> > > - goto err_free;
> > > -
> > > for (i = 0; i < nr_clks; ++i)
> > > - clk_table[i] = default_clk_val;
> > > + ctx->clk_table[i] = default_clk_val;
> > >
> > > - ctx->reg_base = base;
> > > - ctx->clk_data.clks = clk_table;
> > > ctx->clk_data.clk_num = nr_clks;
> > > + ctx->clk_data.clks = ctx->clk_table;
> >
> > Where's the __counted_by? Also struct clk_onecell_data is embedded
> > inside struct rockchip_clk_provider, and I'm not sure offhand how
> > that'll work.
> Not present. __counted_by does not work with embedded struct members.
> No need to add one IMO.
I'll be honest that I'm not sure what's correct here. I added Gustavo
since I saw comments from him before about these types of changes.
Brian
^ permalink raw reply
* [PATCH 0/4] ARM: dts: DTB_CHECK warning cleanup
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (4):
ARM: dts: imx6qdl-sabrelite: add mdio phy address 0
ARM: dts: imx: add ti,deskew = <0> for ti,tfp410
ARM: dts: imx53-qsb: add dvdd and avdd supply for panel sii,43wvf1g
ARM: dts: imx53-ppd: add '#phy-cells' for usb-nop-xceiv
arch/arm/boot/dts/nxp/imx/imx51-babbage.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx53-ppd.dts | 2 ++
arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi | 10 ++++++++++
arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi | 3 ++-
6 files changed, 17 insertions(+), 1 deletion(-)
---
base-commit: 6920bef1402681e36b9c09e9aff8a860b0b54ccd
change-id: 20260511-b4-imx25_dts_simple_warning-e29b7a077b31
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com>
According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
is connected to the station management entity via the mechanical interface
defined in 22.6 shall always respond to transactions addressed to PHY
Address zero <00000>.
Use address 0 is safe because only one MDIO phy under mdio bus.
Fix below CHECK_DTBS warnings:
arm/boot/dts/nxp/imx/imx6dl-sabrelite.dtb: ethernet@2188000 (fsl,imx6q-fec): mdio: Unevaluated properties are not allowed ('ethernet-phy' was unexpected)
from schema $id: http://devicetree.org/schemas/net/fsl,fec.yaml
/home/lizhi/source/linux-upstream-pci/arch/arm/boot/dts/nxp/imx/imx6dl-sabrelite.dtb: ethernet-phy (ethernet-phy-ieee802.3-c22): 'reg' is a required property
from schema $id: http://devicetree.org/schemas/net/ethernet-phy.yaml
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
index 3b7d01065e87b2587a87f97438eea205be3222f8..d936732db46f07806ca07de4353ff47fe26e23b6 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
@@ -291,8 +291,9 @@ mdio {
#address-cells = <1>;
#size-cells = <0>;
- ethphy: ethernet-phy {
+ ethphy: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: imx: add ti,deskew = <0> for ti,tfp410
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com>
Add required proprety ti,deskew for ti,tfp410, which have not defined
default value in yaml. 0 is default value according to
drivers/gpu/drm/bridge/ti-tfp410.c.
Fix below check_dtbs warning:
dvi-encoder (ti,tfp410): 'ti,deskew' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx51-babbage.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts b/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
index b17264e06e6916057c426179e4207c4a28acf1ab..a02e9cd0b3fa04efc4df49f8ad990515d5e81671 100644
--- a/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
@@ -126,6 +126,7 @@ dvi_connector_in: endpoint {
dvi-encoder {
compatible = "ti,tfp410";
+ ti,deskew = <0>;
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts b/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts
index 0814f5665a59c3a64c6023714a3b58230ac80dda..02be8b6da69619a5d33a7b1e964e951addefa676 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts
@@ -60,6 +60,7 @@ dvi_connector_in: endpoint {
dvi-converter {
compatible = "ti,tfp410";
+ ti,deskew = <0>;
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts b/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
index c78f101c3cc122f418b708b1c274ca11b586b65c..6a6ef4a25d8dca7363a527aeea4ddcd81acd58bc 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
@@ -61,6 +61,7 @@ aliases {
encoder {
compatible = "ti,tfp410";
+ ti,deskew = <0>;
ports {
#address-cells = <1>;
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: imx53-qsb: add dvdd and avdd supply for panel sii,43wvf1g
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com>
Add dvdd and avdd supply and regulators for panel sii,43wvf1g to fix below
check_dtbs warnings:
panel (sii,43wvf1g): 'dvdd-supply' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi b/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
index 1869ad86baf202098c6062c0f511358eeffb5c5a..d3b27dc3c2c7d2ab868a8a070a164af994ed30a9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
@@ -91,6 +91,8 @@ panel_dpi: panel {
pinctrl-0 = <&pinctrl_display_power>;
backlight = <&backlight_parallel>;
enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;
+ dvdd-supply = <®_3p2v>;
+ avdd-supply = <®_5v>;
port {
panel_in: endpoint {
@@ -107,6 +109,14 @@ reg_3p2v: regulator-3p2v {
regulator-always-on;
};
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
reg_usb_vbus: regulator-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: imx53-ppd: add '#phy-cells' for usb-nop-xceiv
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com>
Add '#phy-cells' for usb-nop-xceiv to fix below check_dtbs warnings:
usbphy-2 (usb-nop-xceiv): '#phy-cells' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx53-ppd.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts b/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts
index e45a97d3f449de9a82ecd9171bcedb0f5f41346b..f0fb88c14171919ccdd68a90c453a5d2dbaa126d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts
@@ -258,6 +258,7 @@ usbphy2: usbphy-2 {
clock-names = "main_clk";
clock-frequency = <24000000>;
clocks = <&clks IMX5_CLK_CKO2>;
+ #phy-cells = <0>;
assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks IMX5_CLK_OSC>;
assigned-clock-parents = <&clks IMX5_CLK_OSC>;
};
@@ -270,6 +271,7 @@ usbphy3: usbphy-3 {
clock-frequency = <24000000>;
clocks = <&clks IMX5_CLK_CKO2>;
+ #phy-cells = <0>;
assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks IMX5_CLK_OSC>;
assigned-clock-parents = <&clks IMX5_CLK_OSC>;
};
--
2.43.0
^ permalink raw reply related
* [PATCH 1/3] perf vendor events arm64: fix swapped MetricGroup for Tegra410 L1 prefetcher metrics
From: Saurav Sachidanand @ 2026-05-11 21:08 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Will Deacon, Besar Wicaksono, Ian Rogers, Namhyung Kim, Leo Yan,
linux-perf-users, linux-arm-kernel, linux-kernel, aghayev, juew,
Saurav Sachidanand
The L1D prefetcher metrics (l1d_cache_rw_miss_ratio, l1d_demand_accesses,
etc.) were incorrectly assigned to MetricGroup "L1I_Prefetcher_Effectiveness"
and vice versa. This causes 'perf stat --metric-group L1D_Prefetcher_Effectiveness'
to display L1I metrics, which is misleading.
Swap the MetricGroup assignments so L1D metrics are in the L1D group and
L1I metrics are in the L1I group.
Fixes: 86ff690f45cc ("perf vendor events arm64: Add Tegra410 Olympus PMU events")
Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
---
.../arch/arm64/nvidia/t410/metrics.json | 28 +++++++++----------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json b/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json
index b825ede03f544..59474ccb7417f 100644
--- a/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json
+++ b/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json
@@ -346,42 +346,42 @@
"MetricExpr": "l1d_demand_misses / l1d_demand_accesses",
"BriefDescription": "This metric measures the ratio of L1 D-cache Read accesses missed to the total number of L1 D-cache accesses. This gives an indication of the effectiveness of the L1 D-cache for demand Load or Store traffic.",
"ScaleUnit": "1per cache access",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_demand_accesses",
"MetricExpr": "L1D_CACHE_RW",
"BriefDescription": "This metric measures the count of L1 D-cache accesses incurred on Load or Store by the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_demand_misses",
"MetricExpr": "L1D_CACHE_REFILL_RW",
"BriefDescription": "This metric measures the count of L1 D-cache misses incurred on a Load or Store by the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_prf_accuracy",
"MetricExpr": "100 * (l1d_useful_prf / l1d_refilled_prf)",
"BriefDescription": "This metric measures the fraction of prefetched memory addresses that are used by the instruction stream.",
"ScaleUnit": "1percent of prefetch",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_prf_coverage",
"MetricExpr": "100 * (l1d_useful_prf / (l1d_demand_misses + l1d_refilled_prf))",
"BriefDescription": "This metric measures the baseline demand cache misses which the prefetcher brings into the cache.",
"ScaleUnit": "1percent of cache access",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_refilled_prf",
"MetricExpr": "L1D_CACHE_REFILL_HWPRF + L1D_CACHE_REFILL_PRFM + L1D_LFB_HIT_RW_FHWPRF + L1D_LFB_HIT_RW_FPRFM",
"BriefDescription": "This metric measures the count of cache lines refilled by L1 data prefetcher (hardware prefetches or software preload) into L1 D-cache.",
"ScaleUnit": "1count",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_tlb_miss_ratio",
@@ -402,7 +402,7 @@
"MetricExpr": "L1D_CACHE_HIT_RW_FPRF + L1D_LFB_HIT_RW_FHWPRF + L1D_LFB_HIT_RW_FPRFM",
"BriefDescription": "This metric measures the count of cache lines refilled by L1 data prefetcher (hardware prefetches or software preload) into L1 D-cache which are further used by Load or Store from the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_cache_miss_ratio",
@@ -423,42 +423,42 @@
"MetricExpr": "l1i_demand_misses / l1i_demand_accesses",
"BriefDescription": "This metric measures the ratio of L1 I-cache Read accesses missed to the total number of L1 I-cache accesses. This gives an indication of the effectiveness of the L1 I-cache for demand instruction fetch traffic. Note that cache accesses in this cache are demand instruction fetch.",
"ScaleUnit": "1per cache access",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_demand_accesses",
"MetricExpr": "L1I_CACHE_RD",
"BriefDescription": "This metric measures the count of L1 I-cache accesses caused by an instruction fetch by the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_demand_misses",
"MetricExpr": "L1I_CACHE_REFILL_RD",
"BriefDescription": "This metric measures the count of L1 I-cache misses caused by an instruction fetch by the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_prf_accuracy",
"MetricExpr": "100 * (l1i_useful_prf / l1i_refilled_prf)",
"BriefDescription": "This metric measures the fraction of prefetched memory addresses that are used by the instruction stream.",
"ScaleUnit": "1percent of prefetch",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_prf_coverage",
"MetricExpr": "100 * (l1i_useful_prf / (l1i_demand_misses + l1i_refilled_prf))",
"BriefDescription": "This metric measures the baseline demand cache misses which the prefetcher brings into the cache.",
"ScaleUnit": "1percent of cache access",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_refilled_prf",
"MetricExpr": "L1I_CACHE_REFILL_HWPRF + L1I_CACHE_REFILL_PRFM",
"BriefDescription": "This metric measures the count of cache lines refilled by L1 instruction prefetcher (hardware prefetches or software preload) into L1 I-cache.",
"ScaleUnit": "1count",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_tlb_miss_ratio",
@@ -479,7 +479,7 @@
"MetricExpr": "L1I_CACHE_HIT_RD_FPRF",
"BriefDescription": "This metric measures the count of cache lines refilled by L1 instruction prefetcher (hardware prefetches or software preload) into L1 I-cache which are further used by instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l2_cache_miss_ratio",
--
2.47.3
^ permalink raw reply related
* [PATCH 2/3] perf/arm_cspmu: nvidia: handle empty resource list in PCIE-TGT init
From: Saurav Sachidanand @ 2026-05-11 21:09 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Besar Wicaksono, Ilkka Koskinen, Jonathan Hunter,
linux-arm-kernel, linux-perf-users, linux-kernel, aghayev, juew,
Saurav Sachidanand
When acpi_dev_get_memory_resources() returns success but the resource
list is empty (rentry is NULL), addr_filter_reg remains NULL from
devm_kzalloc. Since IS_ERR(NULL) is false, the function proceeds
without error and later dereferences the NULL pointer in
pcie_tgt_pmu_config_addr_filter().
Set addr_filter_reg to ERR_PTR(-ENODEV) when the resource list is
empty so the existing IS_ERR check catches it.
Fixes: 3dd73022306b ("perf/arm_cspmu: nvidia: Add Tegra410 PCIE-TGT PMU")
Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
---
drivers/perf/arm_cspmu/nvidia_cspmu.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/perf/arm_cspmu/nvidia_cspmu.c b/drivers/perf/arm_cspmu/nvidia_cspmu.c
index bac83e424d6dc..bae722e263e91 100644
--- a/drivers/perf/arm_cspmu/nvidia_cspmu.c
+++ b/drivers/perf/arm_cspmu/nvidia_cspmu.c
@@ -555,14 +555,16 @@ static int pcie_tgt_init_data(struct arm_cspmu *cspmu)
rentry = list_first_entry_or_null(
&resource_list, struct resource_entry, node);
- if (rentry) {
+ if (rentry)
data->addr_filter_reg = devm_ioremap_resource(dev, rentry->res);
- ret = 0;
- }
+ else
+ data->addr_filter_reg = ERR_PTR(-ENODEV);
if (IS_ERR(data->addr_filter_reg)) {
dev_err(dev, "failed to get address filter resource\n");
ret = PTR_ERR(data->addr_filter_reg);
+ } else {
+ ret = 0;
}
acpi_dev_free_resource_list(&resource_list);
--
2.47.3
^ permalink raw reply related
* [PATCH 3/3] perf/arm_cspmu: nvidia: fix BDF calculation examples in PCIE PMU docs
From: Saurav Sachidanand @ 2026-05-11 21:09 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Besar Wicaksono, Ilkka Koskinen, Jonathan Hunter,
linux-arm-kernel, linux-perf-users, linux-kernel, aghayev, juew,
Saurav Sachidanand
In-Reply-To: <20260511210905.91917-1-sauravsc@amazon.com>
The BDF hex values in the documentation examples are inconsistent with
the stated formula (bus << 8) + (device << 3) + (function):
- BDF 27:01.1: documented as 0x2781, correct value is 0x2709
(0x27 << 8) + (0x01 << 3) + 0x1 = 0x2709
- BDF 01:01.0: documented as 0x0180, correct value is 0x0108
(0x01 << 8) + (0x01 << 3) + 0x0 = 0x0108
It appears (device << 7) was used instead of (device << 3) when
computing the example values.
Fixes: bf585ba14726 ("perf/arm_cspmu: nvidia: Add Tegra410 PCIE PMU")
Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
---
Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
index 0656223b61d47..24f0e801d7b80 100644
--- a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
+++ b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
@@ -170,7 +170,7 @@ The list of event filters:
devices in root port 0 to 3.
* src_bdf: the BDF that will be monitored. This is a 16-bit value that
follows formula: (bus << 8) + (device << 3) + (function). For example, the
- value of BDF 27:01.1 is 0x2781.
+ value of BDF 27:01.1 is 0x2709.
* src_bdf_en: enable the BDF filter. If this is set, the BDF filter value in
"src_bdf" is used to filter the traffic.
@@ -215,7 +215,7 @@ Example usage:
* Count event id 0x4 from BDF 01:01.0 of PCIE RC-4 on socket 0 targeting all
destinations::
- perf stat -a -e nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0180,src_bdf_en=0x1/
+ perf stat -a -e nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0108,src_bdf_en=0x1/
.. _NVIDIA_T410_PCIE_PMU_RC_Mapping_Section:
--
2.47.3
^ permalink raw reply related
* [PATCH 0/4] remoteproc: cleanup shared carveout and resource-table helpers
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
This series is a preparatory remoteproc cleanup split out from review of
the AMD BRAM-based remoteproc series.
During review, there was a request to move the duplicated plain
ioremap_wc()/iounmap() carveout callbacks into common code and to
factor the "missing resource table is OK" ELF parsing path into a
common helper as well. There was also a request to send that cleanup as
its own patchset first, with the AMD BRAM series respun afterwards on
top once this cleanup is merged.
This series does that in four patches:
1. add common subsystem-private callbacks for the exact-match
wc-ioremap carveout case
2. switch the in-tree exact-match users over to those callbacks
3. add a common helper for drivers that treat a missing ELF resource
table as optional, returning success on -EINVAL and propagating
other errors unchanged
4. switch the matching in-tree drivers over to that helper
For the carveout map/unmap cleanup, this series covers the exact-match
users called out in review: xlnx_r5_remoteproc, rcar_rproc,
st_remoteproc, stm32_rproc, imx_rproc, and imx_dsp_rproc. The zynqmp R5
TCM mapping path is left alone because it also clears the mapped memory
and is not an exact match.
For the optional resource-table handling, this series converts
xlnx_r5_remoteproc, rcar_rproc, stm32_rproc, imx_rproc, and
imx_dsp_rproc. st_remoteproc is intentionally left unchanged because its
parse_fw() callback also builds carveouts and is therefore not a direct
match for the helper introduced here.
Ben Levinsky (4):
remoteproc: add common wc-ioremap carveout callbacks
remoteproc: switch exact-match drivers to wc-ioremap callbacks
remoteproc: add helper for optional ELF resource tables
remoteproc: switch drivers to optional resource-table helper
drivers/remoteproc/imx_dsp_rproc.c | 46 +++-----------
drivers/remoteproc/imx_rproc.c | 45 +-------------
drivers/remoteproc/rcar_rproc.c | 46 +-------------
drivers/remoteproc/remoteproc_internal.h | 38 +++++++++++-
drivers/remoteproc/st_remoteproc.c | 31 +---------
drivers/remoteproc/stm32_rproc.c | 44 +-------------
drivers/remoteproc/xlnx_r5_remoteproc.c | 76 ++----------------------
7 files changed, 60 insertions(+), 266 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 1/4] remoteproc: add common wc-ioremap carveout callbacks
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-1-ben.levinsky@amd.com>
Several remoteproc drivers open-code the same ioremap_wc() and
iounmap() callbacks for carveout mappings. Add subsystem-private
helpers in remoteproc_internal.h so those drivers can share the same
implementation.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
drivers/remoteproc/remoteproc_internal.h | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
index 0a5e15744b1d..3724a47a9748 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -12,8 +12,9 @@
#ifndef REMOTEPROC_INTERNAL_H
#define REMOTEPROC_INTERNAL_H
-#include <linux/irqreturn.h>
#include <linux/firmware.h>
+#include <linux/io.h>
+#include <linux/irqreturn.h>
struct rproc;
@@ -122,6 +123,29 @@ rproc_find_carveout_by_name(struct rproc *rproc, const char *name, ...);
void rproc_add_rvdev(struct rproc *rproc, struct rproc_vdev *rvdev);
void rproc_remove_rvdev(struct rproc_vdev *rvdev);
+static inline int rproc_mem_entry_ioremap_wc(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ void __iomem *va;
+
+ va = ioremap_wc(mem->dma, mem->len);
+ if (!va)
+ return -ENOMEM;
+
+ mem->va = (__force void *)va;
+ mem->is_iomem = true;
+
+ return 0;
+}
+
+static inline int rproc_mem_entry_iounmap(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ iounmap((__force __iomem void *)mem->va);
+
+ return 0;
+}
+
static inline int rproc_prepare_device(struct rproc *rproc)
{
if (rproc->ops->prepare)
--
2.34.1
^ 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