* [PATCH v3 01/11] m68k: mcf5441x: fix clocks numbering
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Fix clocks numbering, set correct values for eport and DAC,
as per RM Rev 5, 05/2018, table 9.5.
Fixes: bea8bcb12da09 ("m68knommu: Add support for the Coldfire m5441x.")
Fixes: 007f84ede6e3e ("m68k: coldfire: remove private clk_get/clk_put")
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/coldfire/m5441x.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index 6ce730098ff6..613b0275d9d8 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -41,9 +41,9 @@ DEFINE_CLK(0, "mcfpit.0", 32, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.1", 33, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.2", 34, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
-DEFINE_CLK(0, "mcfeport.0", 37, MCF_CLK);
-DEFINE_CLK(0, "mcfadc.0", 38, MCF_CLK);
-DEFINE_CLK(0, "mcfdac.0", 39, MCF_CLK);
+DEFINE_CLK(0, "mcfeport.0", 36, MCF_CLK);
+DEFINE_CLK(0, "mcfadc.0", 37, MCF_CLK);
+DEFINE_CLK(0, "mcfdac.0", 38, MCF_CLK);
DEFINE_CLK(0, "mcfrtc.0", 42, MCF_CLK);
DEFINE_CLK(0, "mcfsim.0", 43, MCF_CLK);
DEFINE_CLK(0, "mcfusb-otg.0", 44, MCF_CLK);
@@ -103,9 +103,9 @@ static struct clk_lookup m5411x_clk_lookup[] = {
CLKDEV_INIT("mcfpit.1", NULL, &__clk_0_33),
CLKDEV_INIT("mcfpit.2", NULL, &__clk_0_34),
CLKDEV_INIT("mcfpit.3", NULL, &__clk_0_35),
- CLKDEV_INIT("mcfeport.0", NULL, &__clk_0_37),
- CLKDEV_INIT("mcfadc.0", NULL, &__clk_0_38),
- CLKDEV_INIT("mcfdac.0", NULL, &__clk_0_39),
+ CLKDEV_INIT("mcfeport.0", NULL, &__clk_0_36),
+ CLKDEV_INIT("mcfadc.0", NULL, &__clk_0_37),
+ CLKDEV_INIT("mcfdac.0", NULL, &__clk_0_38),
CLKDEV_INIT("mcfrtc.0", NULL, &__clk_0_42),
CLKDEV_INIT("mcfsim.0", NULL, &__clk_0_43),
CLKDEV_INIT("mcfusb-otg.0", NULL, &__clk_0_44),
@@ -156,7 +156,7 @@ static struct clk * const enable_clks[] __initconst = {
&__clk_0_27, /* uart3 */
&__clk_0_33, /* pit.1 */
- &__clk_0_37, /* eport */
+ &__clk_0_36, /* eport */
&__clk_0_48, /* pll */
&__clk_0_51, /* esdhc */
@@ -174,8 +174,8 @@ static struct clk * const disable_clks[] __initconst = {
&__clk_0_32, /* pit.0 */
&__clk_0_34, /* pit.2 */
&__clk_0_35, /* pit.3 */
- &__clk_0_38, /* adc */
- &__clk_0_39, /* dac */
+ &__clk_0_37, /* adc */
+ &__clk_0_38, /* dac.0 */
&__clk_0_44, /* usb otg */
&__clk_0_45, /* usb host */
&__clk_0_47, /* ssi.0 */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Randy Dunlap @ 2026-05-22 21:20 UTC (permalink / raw)
To: Stefan Dösinger, linux-kernel
Cc: Linus Walleij, Krzysztof Kozlowski, linux-arm-kernel,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <6270885.lOV4Wx5bFT@strix>
On 5/22/26 12:31 PM, Stefan Dösinger wrote:
> Hi Randy,
>
> Am Freitag, 22. Mai 2026, 20:44:24 Ostafrikanische Zeit schrieben Sie:
>> Does this mean that you will be merging this patch since you merged the
>> original patch?
>
> I am new to the kernel development process, so I don't know what's the
> preferred way. I guess for me it is easier if your patch gets merged as-is.
>
> I can certainly submit a pull request myself though since I made myself the
> maintainer for this thing. Does that go to linux-doc@vger.kernel.org or the
> soc list?
The same way that this commit was merged:
commit 220ae5d36dba
Author: Stefan Dösinger <stefandoesinger@gmail.com>
Date: Tue Jan 27 20:52:08 2026 +0300
ARM: zte: Add zx297520v3 platform support
I guess to the soc list.
--
~Randy
^ permalink raw reply
* [PATCH] ARM: io: avoid KASAN instrumentation of raw halfword I/O
From: Karl Mehltretter @ 2026-05-22 21:20 UTC (permalink / raw)
To: Russell King
Cc: Abbott Liu, Linus Walleij, Ard Biesheuvel, Florian Fainelli,
linux-arm-kernel, linux-kernel, stable, Karl Mehltretter
Commit 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") made KASAN
instrument ARM C memory accesses. For CPUs before ARMv6, __raw_readw()
and __raw_writew() are C volatile halfword accesses, so KASAN instruments
them as normal memory accesses.
That is not valid for MMIO. On the QEMU versatilepb machine with an
ARM926EJ-S CPU and CONFIG_KASAN=y, PL011 probing traps while registering
the UART:
Unable to handle kernel paging request at virtual address bd23e207
PC is at __asan_store2+0x2c/0x9c
LR is at pl011_register_port+0x4c/0x19c
Keep the existing volatile halfword access, but move the pre-ARMv6
definitions into __no_kasan_or_inline functions so raw MMIO halfword
accesses are not instrumented by KASAN. The ARMv6-and-newer inline
assembly path is unchanged.
Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM")
Cc: stable@vger.kernel.org # v5.11+
Assisted-by: Codex:gpt-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
arch/arm/include/asm/io.h | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index bae5edf348ef..e6bd9e79737c 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -56,8 +56,19 @@ void __raw_readsl(const volatile void __iomem *addr, void *data, int longlen);
* the bus. Rather than special-case the machine, just let the compiler
* generate the access for CPUs prior to ARMv6.
*/
-#define __raw_readw(a) (__chk_io_ptr(a), *(volatile unsigned short __force *)(a))
-#define __raw_writew(v,a) ((void)(__chk_io_ptr(a), *(volatile unsigned short __force *)(a) = (v)))
+#define __raw_writew __raw_writew
+static __no_kasan_or_inline void __raw_writew(u16 val, volatile void __iomem *addr)
+{
+ __chk_io_ptr(addr);
+ *(volatile unsigned short __force *)addr = val;
+}
+
+#define __raw_readw __raw_readw
+static __no_kasan_or_inline u16 __raw_readw(const volatile void __iomem *addr)
+{
+ __chk_io_ptr(addr);
+ return *(const volatile unsigned short __force *)addr;
+}
#else
/*
* When running under a hypervisor, we want to avoid I/O accesses with
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* [PATCH] ARM: entry: use byte load for KASAN VMAP stack shadow
From: Karl Mehltretter @ 2026-05-22 21:15 UTC (permalink / raw)
To: Russell King
Cc: Linus Walleij, Russell King (Oracle), linux-arm-kernel,
linux-kernel, stable, Karl Mehltretter
Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from
VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in
__switch_to(). The read uses ldr, but KASAN shadow memory is
byte-granular and the computed shadow address is not guaranteed to be
word aligned.
Booting the QEMU versatilepb machine with an ARM926EJ-S CPU and
CONFIG_KASAN=y, CONFIG_KASAN_VMALLOC=y and CONFIG_VMAP_STACK=y faults
before init:
Unhandled fault: alignment exception (0x001) at 0xb91037f6
PC is at __switch_to+0x64/0x88
Use ldrb for the dummy shadow access. The code only needs to fault if
the shadow mapping is missing, so a byte load is sufficient and matches
the granularity of KASAN shadow memory.
Fixes: 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow")
Cc: stable@vger.kernel.org # v6.13+
Assisted-by: Codex:gpt-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
arch/arm/kernel/entry-armv.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index ef6a657c8d13..a3d050ce9b79 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -567,7 +567,7 @@ ENTRY(__switch_to)
@ are using KASAN
mov_l r2, KASAN_SHADOW_OFFSET
add r2, r2, ip, lsr #KASAN_SHADOW_SCALE_SHIFT
- ldr r2, [r2]
+ ldrb r2, [r2]
#endif
#endif
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* [PATCH v02] mailbox/pcc.c shmem map/unmap in callbacks
From: Adam Young @ 2026-05-22 20:52 UTC (permalink / raw)
To: Sudeep Holla, Jassi Brar, Huisong Li
Cc: linux-kernel, linux-hwmon, Rafael J . Wysocki, Len Brown,
linux-acpi, Andi Shyti, Guenter Roeck, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, linux-arm-kernel
The mailbox IRQ and shmems are not cleaned up atomically, so there is a
race condition. If the shmem is torn down while the IRQ is active, a late
interrupt can trigger a write to un-mapped memory.
If the shmem is torn down while the IRQ is active, and another thread
requests the channel again, we can end up with a channel that has had
its shmem unmapped.
By moving the map to start up and the unmap to teardown, we can let
the mailbox mechanism prevent re-entrance into the startup/teardown
functions.
Avoid doubly unmapping the region by removing the unmap in the
direct error handler for the request.
Assisted-by: Codex:gpt-5.4
Fixes: fa362ffafa51 ("mailbox: pcc: Always map the shared memory communication address")
Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
---
Previous Version: https://lore.kernel.org/linux-hwmon/20260515161001.699470-1-admiyo@os.amperecomputing.com/
Changes in this Version:
- Move the initial mapping into the startup callback
- No Double unmap on error during setup
---
drivers/mailbox/pcc.c | 42 ++++++++++++++++++------------------------
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 636879ae1db7..c5873f9f2b91 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -360,7 +360,6 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
struct pcc_mbox_chan *
pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id)
{
- struct pcc_mbox_chan *pcc_mchan;
struct pcc_chan_info *pchan;
struct mbox_chan *chan;
int rc;
@@ -375,20 +374,10 @@ pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id)
return ERR_PTR(-EBUSY);
}
- pcc_mchan = &pchan->chan;
- pcc_mchan->shmem = acpi_os_ioremap(pcc_mchan->shmem_base_addr,
- pcc_mchan->shmem_size);
- if (!pcc_mchan->shmem)
- return ERR_PTR(-ENXIO);
-
rc = mbox_bind_client(chan, cl);
- if (rc) {
- iounmap(pcc_mchan->shmem);
- pcc_mchan->shmem = NULL;
+ if (rc)
return ERR_PTR(rc);
- }
-
- return pcc_mchan;
+ return &pchan->chan;
}
EXPORT_SYMBOL_GPL(pcc_mbox_request_channel);
@@ -401,18 +390,8 @@ EXPORT_SYMBOL_GPL(pcc_mbox_request_channel);
void pcc_mbox_free_channel(struct pcc_mbox_chan *pchan)
{
struct mbox_chan *chan = pchan->mchan;
- struct pcc_chan_info *pchan_info;
- struct pcc_mbox_chan *pcc_mbox_chan;
-
if (!chan || !chan->cl)
return;
- pchan_info = chan->con_priv;
- pcc_mbox_chan = &pchan_info->chan;
- if (pcc_mbox_chan->shmem) {
- iounmap(pcc_mbox_chan->shmem);
- pcc_mbox_chan->shmem = NULL;
- }
-
mbox_free_channel(chan);
}
EXPORT_SYMBOL_GPL(pcc_mbox_free_channel);
@@ -462,9 +441,15 @@ static bool pcc_last_tx_done(struct mbox_chan *chan)
static int pcc_startup(struct mbox_chan *chan)
{
struct pcc_chan_info *pchan = chan->con_priv;
+ struct pcc_mbox_chan *pcc_mchan;
unsigned long irqflags;
int rc;
+ pcc_mchan = &pchan->chan;
+ pcc_mchan->shmem = acpi_os_ioremap(pcc_mchan->shmem_base_addr,
+ pcc_mchan->shmem_size);
+ if (pcc_mchan->shmem == NULL)
+ return -ENOMEM;
/*
* Clear and acknowledge any pending interrupts on responder channel
* before enabling the interrupt
@@ -479,6 +464,8 @@ static int pcc_startup(struct mbox_chan *chan)
if (unlikely(rc)) {
dev_err(chan->mbox->dev, "failed to register PCC interrupt %d\n",
pchan->plat_irq);
+ iounmap(pcc_mchan->shmem);
+ pcc_mchan->shmem = NULL;
return rc;
}
}
@@ -488,15 +475,22 @@ static int pcc_startup(struct mbox_chan *chan)
/**
* pcc_shutdown - Called from Mailbox Controller code. Used here
- * to free the interrupt.
+ * to free the interrupt and unmap the shared memory.
* @chan: Pointer to Mailbox channel to shutdown.
*/
static void pcc_shutdown(struct mbox_chan *chan)
{
struct pcc_chan_info *pchan = chan->con_priv;
+ struct pcc_mbox_chan *pcc_mbox_chan;
if (pchan->plat_irq > 0)
devm_free_irq(chan->mbox->dev, pchan->plat_irq, chan);
+
+ pcc_mbox_chan = &pchan->chan;
+ if (pcc_mbox_chan->shmem) {
+ iounmap(pcc_mbox_chan->shmem);
+ pcc_mbox_chan->shmem = NULL;
+ }
}
static const struct mbox_chan_ops pcc_chan_ops = {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] pwm: imx27: Fix variable truncation in .apply()
From: Frank Li @ 2026-05-22 20:44 UTC (permalink / raw)
To: Ronaldo Nunez
Cc: linux-pwm, Uwe Kleine-König, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260522191348.6227-1-rnunez@baylibre.com>
On Fri, May 22, 2026 at 04:13:48PM -0300, Ronaldo Nunez wrote:
> Fix a variable truncation when calculating period in microseconds as
> part of the solution for the ERR051198 in .apply() callback.
>
> Example scenario:
> - Period of 3us (PWMPR = 196 and prescaler = 1)
> - Expected value in tmp: 198000000000 (NSEC_PER_SEC * (196 + 2) * 1)
> - Actual value is 431504384 (truncation to u32)
>
> Signed-off-by: Ronaldo Nunez <rnunez@baylibre.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Changes in v2:
> - Added example with actual PWMPR/prescaler values per Frank Li's feedback
> - Dropped testing section
> ---
> drivers/pwm/pwm-imx27.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> index 3d34cdc4a3a5..c8b801fcb525 100644
> --- a/drivers/pwm/pwm-imx27.c
> +++ b/drivers/pwm/pwm-imx27.c
> @@ -200,7 +200,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
> static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> const struct pwm_state *state)
> {
> - unsigned long period_cycles, duty_cycles, prescale, period_us, tmp;
> + unsigned long period_cycles, duty_cycles, prescale, period_us;
> struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
> unsigned long long c;
> unsigned long long clkrate;
> @@ -208,6 +208,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> int val;
> int ret;
> u32 cr;
> + u64 tmp;
>
> clkrate = clk_get_rate(imx->clks[PWM_IMX27_PER].clk);
> c = clkrate * state->period;
> @@ -249,6 +250,11 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> val = readl(imx->mmio_base + MX3_PWMPR);
> val = val >= MX3_PWMPR_MAX ? MX3_PWMPR_MAX : val;
> cr = readl(imx->mmio_base + MX3_PWMCR);
> +
> + /*
> + * tmp stores period in nanoseconds. Result fits in u64 since
> + * val <= 0xfffe and prescaler in [1, 0x1000].
> + */
> tmp = NSEC_PER_SEC * (u64)(val + 2) * MX3_PWMCR_PRESCALER_GET(cr);
> tmp = DIV_ROUND_UP_ULL(tmp, clkrate);
> period_us = DIV_ROUND_UP_ULL(tmp, 1000);
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH v2 1/2] dmaengine: Add helper dmaengine_prep_submit_slave_single()
From: Frank.Li @ 2026-05-22 20:13 UTC (permalink / raw)
To: Vinod Koul, Dong Aisheng, Andi Shyti, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dmaengine, linux-kernel, linux-i2c, imx, linux-arm-kernel,
carlos.song, Frank Li
In-Reply-To: <20260522-dma_prep_submit-v2-0-7a87a5a29525@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Previously, DMA users had to call dmaengine_prep_slave_single() followed by
dmaengine_submit(). Many DMA consumers missed call dmaengine_desc_free()
when dmaengine_submit() returned an error.
Introduce dmaengine_prep_submit_slave_single() to combine preparation and
submission into a single step and ensure the descriptor is freed on
submission failure.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- use api function dmaengine_prep_submit_slave_single()
---
drivers/dma/dmaengine.c | 28 ++++++++++++++++++++++++++++
include/linux/dmaengine.h | 17 +++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ca13cd39330ba..1e25be78a22a5 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1619,6 +1619,34 @@ void dma_run_dependencies(struct dma_async_tx_descriptor *tx)
}
EXPORT_SYMBOL_GPL(dma_run_dependencies);
+#define dmaengine_prep_submit(chan, cb, cb_param, func, ...) \
+({ struct dma_async_tx_descriptor *tx = \
+ dmaengine_prep_##func(chan, __VA_ARGS__); \
+ dma_cookie_t cookie = -ENOMEM; \
+ \
+ if (tx) { \
+ tx->callback = cb; \
+ tx->callback_param = cb_param; \
+ cookie = dmaengine_submit(tx); \
+ \
+ if (dma_submit_error(cookie)) \
+ dmaengine_desc_free(tx); \
+ } \
+ cookie; \
+})
+
+dma_cookie_t
+dmaengine_prep_submit_slave_single(struct dma_chan *chan,
+ dma_async_tx_callback cb, void *cb_param,
+ dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags)
+{
+ return dmaengine_prep_submit(chan, cb, cb_param, slave_single,
+ buf, len, dir, flags);
+}
+EXPORT_SYMBOL_GPL(dmaengine_prep_submit_slave_single);
+
static int __init dma_bus_init(void)
{
int err = dmaengine_init_unmap_pool();
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 99efe2b9b4ea9..0f789fac7e91a 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -990,6 +990,13 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
dir, flags, NULL);
}
+dma_cookie_t
+dmaengine_prep_submit_slave_single(struct dma_chan *chan,
+ dma_async_tx_callback cb, void *cb_param,
+ dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags);
+
/**
* dmaengine_prep_peripheral_dma_vec() - Prepare a DMA scatter-gather descriptor
* @chan: The channel to be used for this descriptor
@@ -1575,6 +1582,16 @@ static inline int dma_get_slave_caps(struct dma_chan *chan,
{
return -ENXIO;
}
+
+static inline dma_cookie_t
+dmaengine_prep_submit_slave_single(struct dma_chan *chan,
+ dma_async_tx_callback cb, void *cb_param;
+ dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags);
+{
+ return -ENODEV;
+}
#endif
static inline int dmaengine_desc_set_reuse(struct dma_async_tx_descriptor *tx)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] i2c: imx-lpi2c: use dmaengine_prep_submit() to simple code
From: Frank.Li @ 2026-05-22 20:13 UTC (permalink / raw)
To: Vinod Koul, Dong Aisheng, Andi Shyti, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dmaengine, linux-kernel, linux-i2c, imx, linux-arm-kernel,
carlos.song, Frank Li
In-Reply-To: <20260522-dma_prep_submit-v2-0-7a87a5a29525@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use dmaengine_prep_submit() to simple code. No functional change.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 21 +++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 2a0962a0b4417..c90f72eec8498 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -720,7 +720,6 @@ static void lpi2c_dma_callback(void *data)
static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
{
- struct dma_async_tx_descriptor *rx_cmd_desc;
struct lpi2c_imx_dma *dma = lpi2c_imx->dma;
struct dma_chan *txchan = dma->chan_tx;
dma_cookie_t cookie;
@@ -733,15 +732,11 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return -EINVAL;
}
- rx_cmd_desc = dmaengine_prep_slave_single(txchan, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_MEM_TO_DEV,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (!rx_cmd_desc) {
- dev_err(&lpi2c_imx->adapter.dev, "DMA prep slave sg failed, use pio\n");
- goto desc_prepare_err_exit;
- }
-
- cookie = dmaengine_submit(rx_cmd_desc);
+ cookie = dmaengine_prep_submit_slave_single(txchan, NULL, NULL,
+ dma->dma_tx_addr,
+ dma->rx_cmd_buf_len,
+ DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (dma_submit_error(cookie)) {
dev_err(&lpi2c_imx->adapter.dev, "submitting DMA failed, use pio\n");
goto submit_err_exit;
@@ -751,15 +746,9 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return 0;
-desc_prepare_err_exit:
- dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- return -EINVAL;
-
submit_err_exit:
dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- dmaengine_desc_free(rx_cmd_desc);
return -EINVAL;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] dmaengine: add helper macro dmaengine_prep_submit()
From: Frank.Li @ 2026-05-22 20:13 UTC (permalink / raw)
To: Vinod Koul, Dong Aisheng, Andi Shyti, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dmaengine, linux-kernel, linux-i2c, imx, linux-arm-kernel,
carlos.song, Frank Li
Add helper macro dmaengine_prep_submit() to combine prep and submit to
one call.
Pervious try to use cleanup
https://lore.kernel.org/dmaengine/20251002-dma_chan_free-v1-0-4dbf116c2b19@nxp.com/
It is not simple enough and easy missing retain_and_null_ptr() at success
path.
struct dma_async_tx_descriptor *rx_cmd_desc __free(dma_async_tx_descriptor) = NULL;
...
cookie = dmaengine_submit(rx_cmd_desc);
if (dma_submit_error(cookie))
return dma_submit_error(cookie);
...
retain_and_null_ptr(rx_cmd_desc);
}
So create help macro to combine prep and submit by one call.
patch 2.
static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
{
- struct dma_async_tx_descriptor *rx_cmd_desc;
struct lpi2c_imx_dma *dma = lpi2c_imx->dma;
struct dma_chan *txchan = dma->chan_tx;
dma_cookie_t cookie;
@@ -761,15 +760,10 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return -EINVAL;
}
- rx_cmd_desc = dmaengine_prep_slave_single(txchan, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_MEM_TO_DEV,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (!rx_cmd_desc) {
- dev_err(&lpi2c_imx->adapter.dev, "DMA prep slave sg failed, use pio\n");
- goto desc_prepare_err_exit;
- }
-
- cookie = dmaengine_submit(rx_cmd_desc);
+ cookie = dmaengine_prep_submit(txchan, NULL, NULL, slave_single,
+ dma->dma_tx_addr,
+ dma->rx_cmd_buf_len, DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (dma_submit_error(cookie)) {
dev_err(&lpi2c_imx->adapter.dev, "submitting DMA failed, use pio\n");
goto submit_err_exit;
@@ -779,15 +773,9 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return 0;
-desc_prepare_err_exit:
- dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- return -EINVAL;
-
submit_err_exit:
dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- dmaengine_desc_free(rx_cmd_desc);
return -EINVAL;
}
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v2:
- use API dmaengine_prep_submit_slave_single()
- Link to v1: https://lore.kernel.org/r/20260130-dma_prep_submit-v1-0-2198f9e848fa@nxp.com
---
Frank Li (2):
dmaengine: Add helper dmaengine_prep_submit_slave_single()
i2c: imx-lpi2c: use dmaengine_prep_submit() to simple code
drivers/dma/dmaengine.c | 28 ++++++++++++++++++++++++++++
drivers/i2c/busses/i2c-imx-lpi2c.c | 21 +++++----------------
include/linux/dmaengine.h | 17 +++++++++++++++++
3 files changed, 50 insertions(+), 16 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20260130-dma_prep_submit-cbeac742de48
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Stefan Dösinger @ 2026-05-22 19:31 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap
Cc: Linus Walleij, Krzysztof Kozlowski, linux-arm-kernel,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <503916c8-da3b-42dd-812e-356f519be47f@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
Hi Randy,
Am Freitag, 22. Mai 2026, 20:44:24 Ostafrikanische Zeit schrieben Sie:
> Does this mean that you will be merging this patch since you merged the
> original patch?
I am new to the kernel development process, so I don't know what's the
preferred way. I guess for me it is easier if your patch gets merged as-is.
I can certainly submit a pull request myself though since I made myself the
maintainer for this thing. Does that go to linux-doc@vger.kernel.org or the
soc list?
Cheers,
Stefan
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v8 01/10] dt-bindings: net: airoha: Add GDM port ethernet child node
From: Lorenzo Bianconi @ 2026-05-22 19:27 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260519-airoha-eth-multi-serdes-v8-1-6bd70e329df6@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]
> EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
> or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner.
> As a result multiple net_devices can connect to the same GDM{3,4} port
> and there is a theoretical "1:n" relation between GDM ports and
> net_devices.
> Introduce the ethernet node child of a specific GDM port in order to model
> a given net_device that is connected via the external arbiter to the
> GDM{3,4} port. This new ethernet node is defined by the "airoha,eth-port"
> compatible string. Please note GDM1 and GDM2 does not support the
> connection with the external arbiter and they are represented by an
> ethernet node defined by the "airoha,eth-mac" compatible string.
Hi Rob, Krzysztof and Conor,
do you have any comment about this patch? Thanks in advance.
Regards,
Lorenzo
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../devicetree/bindings/net/airoha,en7581-eth.yaml | 56 +++++++++++++++++++++-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> index fbe2ddcdd909..17fe2edf4886 100644
> --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> @@ -130,6 +130,42 @@ patternProperties:
> maximum: 4
> description: GMAC port identifier
>
> + allOf:
> + - if:
> + properties:
> + reg:
> + contains:
> + items:
> + - enum:
> + - 3
> + - 4
> + then:
> + properties:
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^ethernet@[0-5]$":
> + type: object
> + unevaluatedProperties: false
> + $ref: ethernet-controller.yaml#
> + description: External ethernet port ID available on the GDM port
> +
> + properties:
> + compatible:
> + const: airoha,eth-port
> +
> + reg:
> + maximum: 5
> + description: External ethernet port identifier
> +
> + required:
> + - reg
> + - compatible
> +
> required:
> - reg
> - compatible
> @@ -191,9 +227,27 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> - mac: ethernet@1 {
> + ethernet@1 {
> compatible = "airoha,eth-mac";
> reg = <1>;
> };
> +
> + ethernet@4 {
> + compatible = "airoha,eth-mac";
> + reg = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet@0 {
> + compatible = "airoha,eth-port";
> + reg = <0>;
> + };
> +
> + ethernet@1 {
> + compatible = "airoha,eth-port";
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: clocksource/drivers/owl: fix refcount leak
From: Markus Elfring @ 2026-05-22 19:25 UTC (permalink / raw)
To: Alexander A. Klimov, linux-actions, linux-arm-kernel,
Andreas Färber, Daniel Lezcano, Manivannan Sadhasivam,
Thomas Gleixner
Cc: LKML, kernel-janitors
In-Reply-To: <fe494c36-04e9-4714-ab49-5f05bed66c9e@al2klimov.de>
>> How will chances evolve to adjust variable scopes accordingly?
>
> Is this even a thing in Linux?
> I mean specifying C variables anywhere ex. at function begin.
Development views are evolving also together with the application of scope-based
resource management, aren't they?
https://elixir.bootlin.com/linux/v7.1-rc4/source/include/linux/cleanup.h#L136-L153
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 3/3] ASoC: sunxi: sun4i-spdif: Reorder clock enable sequence
From: Chen-Yu Tsai @ 2026-05-22 19:20 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai
In-Reply-To: <20260522095401.72915-4-phucduc.bui@gmail.com>
On Fri, May 22, 2026 at 12:54 PM <phucduc.bui@gmail.com> wrote:
>
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Enable the APB bus clock before the SPDIF module clock
> during runtime resume, as register accesses depend on the
> bus clock being enabled first.
That does not even matter here. Access will only happen once the runtime
PM callbacks return.
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> sound/soc/sunxi/sun4i-spdif.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> index f54eb14c9ed8..102db1a2afbb 100644
> --- a/sound/soc/sunxi/sun4i-spdif.c
> +++ b/sound/soc/sunxi/sun4i-spdif.c
> @@ -643,15 +643,15 @@ static int sun4i_spdif_runtime_suspend(struct device *dev)
>
> static int sun4i_spdif_runtime_resume(struct device *dev)
> {
> - struct sun4i_spdif_dev *host = dev_get_drvdata(dev);
> + struct sun4i_spdif_dev *host = dev_get_drvdata(dev);
> int ret;
>
> - ret = clk_prepare_enable(host->spdif_clk);
> + ret = clk_prepare_enable(host->apb_clk);
> if (ret)
> return ret;
> - ret = clk_prepare_enable(host->apb_clk);
> + ret = clk_prepare_enable(host->spdif_clk);
> if (ret)
> - clk_disable_unprepare(host->spdif_clk);
> + clk_disable_unprepare(host->apb_clk);
>
> return ret;
> }
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v5 0/2] mm: improve large folio readahead for exec memory
From: Andrew Morton @ 2026-05-22 19:20 UTC (permalink / raw)
To: Usama Arif
Cc: david, willy, ryan.roberts, linux-mm, r, jack, Andrew Donnellan,
apopple, baohua, baolin.wang, brauner, catalin.marinas, dev.jain,
kees, kevin.brodsky, lance.yang, Liam R.Howlett, linux-arm-kernel,
linux-fsdevel, linux-kernel, ljs, mhocko, npache, pasha.tatashin,
rmclure, rppt, surenb, vbabka, Al Viro, wilts.infradead.org,
"linux-fsdevel, ziy, hannes, kas, shakeel.butt, kernel-team
In-Reply-To: <20260522162422.3856502-1-usama.arif@linux.dev>
On Fri, 22 May 2026 09:23:46 -0700 Usama Arif <usama.arif@linux.dev> wrote:
> Two checks in do_sync_mmap_readahead() limit large-folio readahead:
>
> 1. The mmap_miss heuristic is meant to throttle wasteful speculative
> readahead. It is currently also applied to the VM_EXEC readahead
> path, which is targeted rather than speculative. Once mmap_miss exceeds
> MMAP_LOTSAMISS, exec readahead - including the large-folio
> order requested by exec_folio_order() - is disabled. On
> configurations where the mmap_miss decrement paths are not
> active (see patch 1) the counter only grows, so exec readahead
> is permanently disabled after the first 100 faults.
>
> 2. The force_thp_readahead path is gated only on
> HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER and always drives the
> readahead at HPAGE_PMD_ORDER. Configurations where
> HPAGE_PMD_ORDER exceeds MAX_PAGECACHE_ORDER never reach this
> path, even when the mapping itself supports usefully large
> folios well below the cap.
>
> Both issues are most visible on arm64 with a 64K base page size,
> where HPAGE_PMD_ORDER is 13 (512MB) -- above MAX_PAGECACHE_ORDER
> (11) -- and where fault_around_pages collapses to 1 disabling
> should_fault_around() (one of the two mmap_miss decrement sites).
> However the fixes are architecture-agnostic: patch 1 reflects the
> nature of VM_EXEC readahead regardless of base page size, and
> patch 2 generalises the gate so any mapping advertising a usefully
> large maximum folio order can benefit.
>
> I created a benchmark that mmaps a large executable file and calls
> RET-stub functions at PAGE_SIZE offsets across it. "Cold" measures
> fault + readahead cost. "Random" first faults in all pages with a
> sequential sweep (not measured), then measures time for calling random
> offsets, isolating iTLB miss cost for scattered execution.
>
> The benchmark results on Neoverse V2 (Grace), arm64 with 64K base pages,
> 512MB executable file on ext4, averaged over 3 runs:
>
> Phase | Baseline | Patched | Improvement
> -----------|--------------|--------------|------------------
> Cold fault | 83.4 ms | 41.3 ms | 50% faster
> Random | 76.0 ms | 58.3 ms | 23% faster
Well that's nice.
AI review might have found a few things:
https://sashiko.dev/#/patchset/20260522162422.3856502-1-usama.arif@linux.dev
^ permalink raw reply
* Re: [PATCH v2 2/3] ASoC: sunxi: sun4i-spdif: Resume device before kcontrol register access
From: Chen-Yu Tsai @ 2026-05-22 19:19 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai
In-Reply-To: <20260522095401.72915-3-phucduc.bui@gmail.com>
On Fri, May 22, 2026 at 12:54 PM <phucduc.bui@gmail.com> wrote:
>
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Accessing registers while the device is runtime-suspended
> may lead to invalid hardware accesses on systems where the
> APB bus clock is gated during runtime suspend.
Did you actually reproduce the issue, or did you add the patch simply
because Sashiko mentioned it?
On sunxi, either it will hang the system because the bus transaction
got ignored, or it won't as something else enabled the clock.
And when you do add patches due to Sashiko raising an issue, please
do mention it in the commit message.
> Ensure the device is resumed before accessing registers.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> sound/soc/sunxi/sun4i-spdif.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> index 89eccc83a130..f54eb14c9ed8 100644
> --- a/sound/soc/sunxi/sun4i-spdif.c
> +++ b/sound/soc/sunxi/sun4i-spdif.c
> @@ -428,6 +428,11 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
> struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
> u8 *status = ucontrol->value.iec958.status;
> unsigned int reg;
> + int ret;
> +
> + ret = pm_runtime_resume_and_get(cpu_dai->dev);
> + if (ret)
> + return ret;
>
> scoped_guard(spinlock_irqsave, &host->lock) {
> regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA0, ®);
> @@ -443,6 +448,8 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
> status[5] = (reg >> 8) & 0x3;
> }
>
> + pm_runtime_put(cpu_dai->dev);
> +
> return 0;
> }
>
> @@ -453,8 +460,13 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
> struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
> u8 *status = ucontrol->value.iec958.status;
> unsigned int reg;
> + int ret;
> bool chg0, chg1;
>
> + ret = pm_runtime_resume_and_get(cpu_dai->dev);
> + if (ret)
> + return ret;
> +
> scoped_guard(spinlock_irqsave, &host->lock) {
> reg = (u32)status[3] << 24;
> reg |= (u32)status[2] << 16;
> @@ -479,6 +491,8 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
> SUN4I_SPDIF_TXCFG_NONAUDIO, reg);
> }
>
> + pm_runtime_put(cpu_dai->dev);
> +
> return chg0 || chg1;
> }
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v15 12/28] drm/i915/dp: Add YCBCR444 handling for sink formats
From: Ville Syrjälä @ 2026-05-22 19:19 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone, kernel, amd-gfx,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
intel-gfx, intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260522-color-format-v15-12-21fb136c9df2@collabora.com>
On Fri, May 22, 2026 at 02:32:03PM +0200, Nicolas Frattaroli wrote:
> In anticipation of userspace being able to explicitly select supported
> sink formats, add handling of the YCBCR444 sink format. The AUTO path
> does not choose this format, but with explicit format selection added to
> the driver, it becomes a possibility.
>
> Check for both source and sink support of YCBCR444 in
> intel_dp_sink_format_valid.
>
> Acked-by: Daniel Stone <daniel@fooishbar.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1920d2f02666..143ed85224be 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1344,6 +1344,20 @@ intel_dp_mode_valid_downstream(struct intel_connector *connector,
> 8, sink_format, true);
> }
>
> +static bool
> +intel_dp_can_ycbcr444(struct intel_dp *intel_dp)
> +{
> + if (source_can_output(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR444) &&
> + !drm_dp_is_branch(intel_dp->dpcd))
> + return true;
> +
> + if (source_can_output(intel_dp, INTEL_OUTPUT_FORMAT_RGB) &&
> + dfp_can_convert_from_rgb(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR444))
IIRC my previous conclusion was that we don't want the dfp convert
stuff here, at least initially. So this should just are about
source_can_output().
> + return true;
> +
> + return false;
> +}
> +
> static enum drm_mode_status
> intel_dp_sink_format_valid(struct intel_connector *connector,
> const struct drm_display_mode *mode,
> @@ -1364,6 +1378,13 @@ intel_dp_sink_format_valid(struct intel_connector *connector,
>
> return MODE_OK;
Again, would prefer a cleanr 420->444->rgb order.
> case INTEL_OUTPUT_FORMAT_RGB:
> + return MODE_OK;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
> + return MODE_BAD;
> + if (!intel_dp_can_ycbcr444(intel_dp))
> + return MODE_BAD;
These two ifs are swapped when compared to the HDMI version for no
good reason that I can see.
And missing the has_hdmi_sink check here as well.
> +
> return MODE_OK;
> default:
> MISSING_CASE(sink_format);
>
> --
> 2.54.0
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH v15 11/28] drm/i915/hdmi: Add YCBCR444 handling for sink formats
From: Ville Syrjälä @ 2026-05-22 19:12 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone, kernel, amd-gfx,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
intel-gfx, intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260522-color-format-v15-11-21fb136c9df2@collabora.com>
On Fri, May 22, 2026 at 02:32:02PM +0200, Nicolas Frattaroli wrote:
> In anticipation of userspace being able to explicitly select supported
> sink formats, add handling of the YCBCR444 sink format. The AUTO path
> does not choose this format, but with explicit format selection added to
> the driver, it becomes a possibility.
>
> Check for YCBCR444 support on the sink in sink_bpc_possible, and on the
> source and sink in sink_format_valid.
>
> Acked-by: Daniel Stone <daniel@fooishbar.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 32 +++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 9076c2b176ec..97cb321e6568 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1966,6 +1966,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
>
> if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36;
> + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_36;
> else
> return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_36;
> case 10:
> @@ -1974,6 +1976,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
>
> if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_30;
> + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_30;
> else
> return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_30;
> case 8:
> @@ -2021,6 +2025,27 @@ intel_hdmi_mode_clock_valid(struct drm_connector *_connector, int clock,
> return status;
> }
>
> +/**
> + * intel_hdmi_can_ycbcr444 - Check whether connector can output YCbCr444
> + * @connector: pointer to &struct intel_connector to check
> + *
> + * Checks whether the hardware that backs @connector is capable of outputting
> + * YCbCr444 video over HDMI. Does not check whether currently connected sink is
> + * capable of receiving it.
> + *
> + * Returns: %true if source supports outputting YCbCr444, %false otherwise.
> + */
We don't need kernel docs for internal stuff.
> +static bool
> +intel_hdmi_can_ycbcr444(struct intel_connector *connector)
> +{
> + const struct intel_display *display = to_intel_display(connector);
> +
> + if (HAS_GMCH(display))
> + return true;
Exactly the wrong way around.
> +
> + return false;
> +}
> +
> static enum drm_mode_status
> intel_hdmi_sink_format_valid(struct intel_connector *connector,
> const struct drm_display_mode *mode,
> @@ -2038,6 +2063,13 @@ intel_hdmi_sink_format_valid(struct intel_connector *connector,
>
> return MODE_OK;
I would put the 444 stuff here between 420 and RGB. Then we logically go
from YCbCr420 -> YCbCr444 -> RGB when reading the code.
> case INTEL_OUTPUT_FORMAT_RGB:
> + return MODE_OK;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + if (!intel_hdmi_can_ycbcr444(connector))
> + return MODE_BAD;
We're missing the has_hdmi_sink check as well.
> + if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
> + return MODE_BAD;
> +
> return MODE_OK;
> default:
> MISSING_CASE(sink_format);
>
> --
> 2.54.0
--
Ville Syrjälä
Intel
^ permalink raw reply
* [PATCH v2] pwm: imx27: Fix variable truncation in .apply()
From: Ronaldo Nunez @ 2026-05-22 19:13 UTC (permalink / raw)
To: linux-pwm
Cc: Uwe Kleine-König, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, imx, linux-arm-kernel,
linux-kernel, Ronaldo Nunez
Fix a variable truncation when calculating period in microseconds as
part of the solution for the ERR051198 in .apply() callback.
Example scenario:
- Period of 3us (PWMPR = 196 and prescaler = 1)
- Expected value in tmp: 198000000000 (NSEC_PER_SEC * (196 + 2) * 1)
- Actual value is 431504384 (truncation to u32)
Signed-off-by: Ronaldo Nunez <rnunez@baylibre.com>
---
Changes in v2:
- Added example with actual PWMPR/prescaler values per Frank Li's feedback
- Dropped testing section
---
drivers/pwm/pwm-imx27.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 3d34cdc4a3a5..c8b801fcb525 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -200,7 +200,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)
{
- unsigned long period_cycles, duty_cycles, prescale, period_us, tmp;
+ unsigned long period_cycles, duty_cycles, prescale, period_us;
struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
unsigned long long c;
unsigned long long clkrate;
@@ -208,6 +208,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
int val;
int ret;
u32 cr;
+ u64 tmp;
clkrate = clk_get_rate(imx->clks[PWM_IMX27_PER].clk);
c = clkrate * state->period;
@@ -249,6 +250,11 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
val = readl(imx->mmio_base + MX3_PWMPR);
val = val >= MX3_PWMPR_MAX ? MX3_PWMPR_MAX : val;
cr = readl(imx->mmio_base + MX3_PWMCR);
+
+ /*
+ * tmp stores period in nanoseconds. Result fits in u64 since
+ * val <= 0xfffe and prescaler in [1, 0x1000].
+ */
tmp = NSEC_PER_SEC * (u64)(val + 2) * MX3_PWMCR_PRESCALER_GET(cr);
tmp = DIV_ROUND_UP_ULL(tmp, clkrate);
period_us = DIV_ROUND_UP_ULL(tmp, 1000);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 1/2] gpio: mxc: fix irq_high handling
From: Frank Li @ 2026-05-22 18:21 UTC (permalink / raw)
To: Alexander Stein
Cc: Linus Walleij, Bartosz Golaszewski, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-gpio, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522070118.800671-1-alexander.stein@ew.tq-group.com>
On Fri, May 22, 2026 at 09:01:15AM +0200, Alexander Stein wrote:
> If port->irq_high is -1 (fsl,imx21-gpio compatible) and gpio_idx is >= 16
> enable_irq_wake() is called with -1 which is wrong.
>
> Fixes: 5f6d1998adeb ("gpio: mxc: release the parent IRQ in runtime suspend")
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> I don't have hardware to test. I just noticed this by code review.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> drivers/gpio/gpio-mxc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> index 647b6f4861b74..12f11a6c96653 100644
> --- a/drivers/gpio/gpio-mxc.c
> +++ b/drivers/gpio/gpio-mxc.c
> @@ -469,7 +469,7 @@ static int mxc_gpio_probe(struct platform_device *pdev)
> * the handler is needed only once, but doing it for every port
> * is more robust and easier.
> */
> - port->irq_high = -1;
> + port->irq_high = 0;
> port->mx_irq_handler = mx2_gpio_irq_handler;
> } else
> port->mx_irq_handler = mx3_gpio_irq_handler;
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH] mmc: dw_mmc-rockchip: Add missing private data for very old controllers
From: Heiko Stuebner @ 2026-05-22 18:43 UTC (permalink / raw)
To: ulfh, shawn.lin, jh80.chung
Cc: heiko, linux-mmc, linux-arm-kernel, linux-rockchip, linux-kernel,
stable
The really old controllers (rk2928, rk3066, rk3188) do not support UHS
speeds at all, and thus never handled phase data.
For that reason it never had a parse_dt callback and no driver private
data at all.
Commit ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating
support") makes the private data sort of mandatory, because the init
function checks whether phases are configured internally or through the
clock controller.
This results in the old SoCs then experiencing NULL-pointer dereferences
when they try to access that private-data struct.
While we could have if (priv) conditionals in all places, it's way less
cluttery to just give the old types their private-data struct.
Fixes: ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support")
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/mmc/host/dw_mmc-rockchip.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index c6eece4ec3fd..75c82ff20f17 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -441,6 +441,22 @@ static int dw_mci_common_parse_dt(struct dw_mci *host)
return 0;
}
+static int dw_mci_rk2928_parse_dt(struct dw_mci *host)
+{
+ struct dw_mci_rockchip_priv_data *priv;
+ int err;
+
+ err = dw_mci_common_parse_dt(host);
+ if (err)
+ return err;
+
+ priv = host->priv;
+
+ priv->internal_phase = false;
+
+ return 0;
+}
+
static int dw_mci_rk3288_parse_dt(struct dw_mci *host)
{
struct dw_mci_rockchip_priv_data *priv;
@@ -514,6 +530,7 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
static const struct dw_mci_drv_data rk2928_drv_data = {
.init = dw_mci_rockchip_init,
+ .parse_dt = dw_mci_rk2928_parse_dt,
};
static const struct dw_mci_drv_data rk3288_drv_data = {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v1 3/4] arm64/vdso: Enable SFrame generation in vDSO
From: Dylan Hatch @ 2026-05-22 18:24 UTC (permalink / raw)
To: Jens Remus
Cc: Catalin Marinas, Will Deacon, Steven Rostedt, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Weinan Liu, linux-arm-kernel,
linux-kernel, Heiko Carstens, Ilya Leoshkevich
In-Reply-To: <48871045-9ec8-4e62-a2c5-809e3070d671@linux.ibm.com>
On Fri, May 22, 2026 at 1:51 AM Jens Remus <jremus@linux.ibm.com> wrote:
>
> Hello Dylan,
>
> thank you for the feedback!
>
> On 5/22/2026 3:31 AM, Dylan Hatch wrote:
> > On Fri, Apr 17, 2026 at 8:08 AM Jens Remus <jremus@linux.ibm.com> wrote:
> >>
> >> This replicates Josh's x86 patch "x86/vdso: Enable sframe generation
> >> in VDSO" [1] for arm64.
> >>
> >> Enable .sframe generation in the vDSO library so kernel and user space
> >> can unwind through it. Keep all function symbols in the vDSO .symtab
> >> for stack trace purposes. This enables perf to lookup these function
> >> symbols in addition to those already exported in vDSO .dynsym.
> >>
> >> Starting with binutils 2.46 both GNU assembler and GNU linker
> >> exclusively support generating and merging .sframe in SFrame V3 format.
> >> For vDSO, only if supported by the assembler, generate .sframe, collect
> >> it, mark it as KEEP, and generate a GNU_SFRAME program table entry.
> >> Otherwise explicitly discard any .sframe.
> >>
> >> [1]: x86/vdso: Enable sframe generation in VDSO,
> >> https://lore.kernel.org/all/20260211141357.271402-7-jremus@linux.ibm.com/
> >>
> >> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> >> ---
> >>
> >> Notes (jremus):
> >> @Dylan: Adding -Wa,--gsframe-3 to the VDSO CC_FLAGS_ADD_VDSO (and
> >> AS_FLAGS_ADD_VDSO) may clash with your patch [1] that adds likewise
> >> to the CC_FLAGS_REMOVE_VDSO. Any idea how to resolve?
> >>
> >> [1]: [PATCH v3 2/8] arm64, unwind: build kernel with sframe V3 info,
> >> https://lore.kernel.org/all/20260406185000.1378082-3-dylanbhatch@google.com/
> >
> > In a kernel tree with both your patch and my [1] patch merged, I
> > believe we'd want to hold two invariants true:
> >
> > 1. If HAVE_UNWIND_KERNEL_SFRAME=n, we must not build the kernel with .sframe.
> > 2. If AS_SFRAME3=y, we must build vDSO with .sframe.
> >
> > Since HAVE_UNWIND_KERNEL_SFRAME=y implies AS_SFRAME3=y, I wonder if we
> > should be able to drop CC_FLAGS_SFRAME from CC_FLAGS_REMOVE_VDSO and
> > move some definitions:
> >
> > diff --git a/Makefile b/Makefile
> > index 227fda16deb1..ef059bccb8c1 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1147,12 +1147,15 @@ endif
> > # Ensure compilers do not transform certain loops into calls to wcslen()
> > KBUILD_CFLAGS += -fno-builtin-wcslen
> >
> > +ifeq ($(CONFIG_AS_SFRAME3),y)
> > +CC_FLAGS_SFRAME := -Wa,--gsframe-3
> > +export CC_FLAGS_SFRAME
> > +endif
> > +
> > # build with sframe table
> > ifdef CONFIG_HAVE_UNWIND_KERNEL_SFRAME
> > -CC_FLAGS_SFRAME := -Wa,--gsframe-3
> > KBUILD_CFLAGS += $(CC_FLAGS_SFRAME)
> > KBUILD_AFLAGS += $(CC_FLAGS_SFRAME)
> > -export CC_FLAGS_SFRAME
> > endif
> >
> > # change __FILE__ to the relative path to the source directory
> > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > index e90427a8d0f6..f03cac27857c 100644
> > --- a/arch/arm64/kernel/vdso/Makefile
> > +++ b/arch/arm64/kernel/vdso/Makefile
> > @@ -15,10 +15,6 @@ obj-vdso := vgettimeofday.o note.o sigreturn.o
> > vgetrandom.o vgetrandom-chacha.o
> > targets := $(obj-vdso) vdso.so vdso.so.dbg
> > obj-vdso := $(addprefix $(obj)/, $(obj-vdso))
> >
> > -ifeq ($(CONFIG_AS_SFRAME3),y)
> > - SFRAME_CFLAGS := -Wa,--gsframe-3
> > -endif
> > -
> > btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti
> >
> > # -Bsymbolic has been added for consistency with arm, the compat vDSO and
> > @@ -42,12 +38,12 @@ ccflags-y += -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
> > CC_FLAGS_REMOVE_VDSO := $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) \
> > $(RANDSTRUCT_CFLAGS) $(KSTACK_ERASE_CFLAGS) \
> > $(GCC_PLUGINS_CFLAGS) \
> > - $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) $(CC_FLAGS_SFRAME) \
> > + $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) \
> > -Wmissing-prototypes -Wmissing-declarations
> >
> > -CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> > $(SFRAME_CFLAGS)
> > +CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> > $(CC_FLAGS_SFRAME)
> >
> > -AS_FLAGS_ADD_VDSO := $(SFRAME_CFLAGS)
> > +AS_FLAGS_ADD_VDSO := $(CC_FLAGS_SFRAME)
> >
> > CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_REMOVE_VDSO)
> > CFLAGS_REMOVE_vgetrandom.o = $(CC_FLAGS_REMOVE_VDSO)
> >
> >
> > If done this way I think we will add the -Wa,--gsframe-3 twice when
> > HAVE_UNWIND_KERNEL_SFRAME=y, but maybe that's not a problem? This
> > could probably be folded into either this patch or mine [1], depending
> > which is applied first. I'm happy to rebase my unwind-for-kernel
> > patches onto this series, or we can do the other way around if that
> > works better.
> >
> > What do you think?
>
> I like that approach. Go ahead.
Do you have an updated version you can send? I noticed some of these
patches don't apply cleanly on Steven's current sframe branch. If you
can't get to it before you leave then no worries, have a good vacation
:)
^ permalink raw reply
* Re: [PATCH] clocksource/drivers/owl: fix refcount leak
From: Alexander A. Klimov @ 2026-05-22 18:20 UTC (permalink / raw)
To: Markus Elfring, linux-actions, linux-arm-kernel,
Andreas Färber, Daniel Lezcano, Manivannan Sadhasivam,
Thomas Gleixner
Cc: LKML
In-Reply-To: <c1aba09f-0a74-485c-b787-59b215a3bd88@web.de>
On 5/21/26 14:10, Markus Elfring wrote:
>> Every value returned from of_clk_get() is supposed to be cleaned up
>> via clk_put() once not needed anymore.
>
> How do you think about to add a wording like “Thus add a missing function call.”?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.1-rc4#n94
>
> Would the application of another guard become helpful?
TIL (from you) there's DEFINE_FREE.
This seems pretty cool on its own.
I think I can apply it here, but I'd have to recompile.
This takes long.
Or we just fix this leak with the oneliner
I already compiled, booted and submitted.
I'll wait what maintainers decide...
>
> How will chances evolve to adjust variable scopes accordingly?
Is this even a thing in Linux?
I mean specifying C variables anywhere ex. at function begin.
^ permalink raw reply
* Re: [PATCH 2/2] gpio: mxc: use BIT() macro
From: Frank Li @ 2026-05-22 18:09 UTC (permalink / raw)
To: Alexander Stein
Cc: Linus Walleij, Bartosz Golaszewski, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-gpio, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522070118.800671-2-alexander.stein@ew.tq-group.com>
On Fri, May 22, 2026 at 09:01:16AM +0200, Alexander Stein wrote:
> Do not open-code the BIT() macro.
Nit: Replace the open-code with the BIT() macro.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> drivers/gpio/gpio-mxc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> index 12f11a6c96653..7e2690d92df6f 100644
> --- a/drivers/gpio/gpio-mxc.c
> +++ b/drivers/gpio/gpio-mxc.c
> @@ -330,13 +330,13 @@ static int gpio_set_wake_irq(struct irq_data *d, u32 enable)
> ret = enable_irq_wake(port->irq_high);
> else
> ret = enable_irq_wake(port->irq);
> - port->wakeup_pads |= (1 << gpio_idx);
> + port->wakeup_pads |= BIT(gpio_idx);
> } else {
> if (port->irq_high && (gpio_idx >= 16))
> ret = disable_irq_wake(port->irq_high);
> else
> ret = disable_irq_wake(port->irq);
> - port->wakeup_pads &= ~(1 << gpio_idx);
> + port->wakeup_pads &= ~BIT(gpio_idx);
> }
>
> return ret;
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v3 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Andrew Morton @ 2026-05-22 18:07 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6
In-Reply-To: <20260522053146.83209-1-jiangwenxiaomi@gmail.com>
On Fri, 22 May 2026 13:31:40 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
> This patchset accelerates ioremap, vmalloc, and vmap when the memory
> is physically fully or partially contiguous.
Thanks. AI review asked a few things and might have found an existing
32-bit bug in vmap():
https://sashiko.dev/#/patchset/20260522053146.83209-1-jiangwenxiaomi@gmail.com
^ permalink raw reply
* [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
From: Mark Brown @ 2026-05-22 18:00 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Catalin Marinas, Will Deacon
Cc: Mark Rutland, linux-arm-kernel, kvmarm, linux-kernel, Mark Brown
Since b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps") when guests
write to ZCR_EL2 we have clamped the value of ZCR_EL2.LEN to be at most
that configuring the maximum guest VL. This is not the behaviour the
architecture documents for ZCR_EL2.LEN, the expectation is that all bits
will be read as written. Further, writing values larger than the largest
available vector length is part of the documented procedure for enumerating
the supported vector lengths so we expect to see this happen in practice.
The reasoning for the current behaviour is not specifically articulated, my
best guess is that it is intended to ensure that the guest can not see an
effective VL greater than the maximum that has been configured. This can
instead be achieved by configuring ZCR_EL2 when loading guest state:
- When running at EL0 or EL1 configure ZCR_EL2.LEN to the minimum of the
guest ZCR_EL2.LEN and vcpu_sve_max_vq(vcpu)-1.
- When running at EL2 configure the maximum VL for the guest in
ZCR_EL2.LEN like we do for non-nested guests and load the guest
ZCR_EL2 into ZCR_EL1.
This will ensure that the guest sees both the ZCR_EL2.LEN value which it
wrote and the effective VL that resulting from the values it has configured
in ZCR_ELx.LEN.
Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
written are sanitised based on this.
Fixes: b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps")
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/kvm/hyp/include/hyp/switch.h | 8 ++++----
arch/arm64/kvm/sys_regs.c | 6 +-----
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index bf0eb5e43427..fd277cb70967 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -501,11 +501,11 @@ static inline void fpsimd_lazy_switch_to_guest(struct kvm_vcpu *vcpu)
return;
if (vcpu_has_sve(vcpu)) {
+ zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
+
/* A guest hypervisor may restrict the effective max VL. */
- if (is_nested_ctxt(vcpu))
- zcr_el2 = __vcpu_sys_reg(vcpu, ZCR_EL2);
- else
- zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
+ if (is_nested_ctxt(vcpu) && !is_hyp_ctxt(vcpu))
+ zcr_el2 = min(zcr_el2, __vcpu_sys_reg(vcpu, ZCR_EL2));
write_sysreg_el2(zcr_el2, SYS_ZCR);
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 148fc3400ea8..c4d3bbae2d14 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2862,8 +2862,6 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
- unsigned int vq;
-
if (guest_hyp_sve_traps_enabled(vcpu)) {
kvm_inject_nested_sve_trap(vcpu);
return false;
@@ -2874,9 +2872,7 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
return true;
}
- vq = SYS_FIELD_GET(ZCR_ELx, LEN, p->regval) + 1;
- vq = min(vq, vcpu_sve_max_vq(vcpu));
- __vcpu_assign_sys_reg(vcpu, ZCR_EL2, vq - 1);
+ __vcpu_assign_sys_reg(vcpu, ZCR_EL2, p->regval & ZCR_ELx_LEN);
return true;
}
---
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
change-id: 20260519-kvm-arm64-fix-zcr-len-nv-9e9e7bae012a
Best regards,
--
Mark Brown <broonie@kernel.org>
^ 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