* Re: [PATCH 0/4] firmware: arm_ffa: Move core init to platform driver probe
From: Sudeep Holla @ 2026-05-17 11:36 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, Sudeep Holla
Cc: Yeoreum Yun
In-Reply-To: <20260508-b4-ffa_plat_dev-v1-0-c5a30f8cf7b8@kernel.org>
On Fri, 08 May 2026 18:54:14 +0100, Sudeep Holla wrote:
> This series moves the Arm FF-A core initialisation into the driver model by
> converting the core bring-up path to a platform driver probe/remove flow.
>
> The first patch reverts the earlier rootfs_initcall change. That initcall
> ordering workaround is not a proper solution and potentially conflicts with
> pKVM FF-A proxy requirement.
>
> [...]
Applied to sudeep.holla/linux (for-next/ffa/updates), thanks!
[1/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"
https://git.kernel.org/sudeep.holla/c/1b4c1c4d75a8
[2/4] firmware: arm_ffa: Register core as a platform driver
https://git.kernel.org/sudeep.holla/c/d10175dd517a
[3/4] firmware: arm_ffa: Set the core device as FF-A device parent
https://git.kernel.org/sudeep.holla/c/8bdff2dda405
[4/4] firmware: arm_ffa: Defer probe until pKVM is initialized
https://git.kernel.org/sudeep.holla/c/216d4772b411
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] media: rockchip: rga: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-17 11:34 UTC (permalink / raw)
To: Jacob Chen, Ezequiel Garcia, Mauro Carvalho Chehab,
Heiko Stuebner, Hans Verkuil, linux-media, linux-rockchip,
linux-arm-kernel, linux-kernel
Cc: Guangshuo Li
rga_probe() allocates a video_device with video_device_alloc() and
releases it from the rel_vdev error path if video_register_device()
fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
rga_probe()
-> rel_vdev
-> video_device_release(vfd)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free vfd through vdev->release().
rga_probe() then releases vfd exactly once from rel_vdev. Restore
video_device_release() after successful registration so the registered
device keeps its normal lifetime handling.
This issue was found by a static analysis tool I am developing.
Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/rockchip/rga/rga.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
index fea63b94c5f3..90ae01de3216 100644
--- a/drivers/media/platform/rockchip/rga/rga.c
+++ b/drivers/media/platform/rockchip/rga/rga.c
@@ -851,6 +851,7 @@ static int rga_probe(struct platform_device *pdev)
goto unreg_v4l2_dev;
}
*vfd = rga_videodev;
+ vfd->release = video_device_release_empty;
vfd->lock = &rga->mutex;
vfd->v4l2_dev = &rga->v4l2_dev;
@@ -895,6 +896,8 @@ static int rga_probe(struct platform_device *pdev)
goto free_dma;
}
+ vfd->release = video_device_release;
+
v4l2_info(&rga->v4l2_dev, "Registered %s as /dev/%s\n",
vfd->name, video_device_node_name(vfd));
--
2.43.0
^ permalink raw reply related
* [PATCH] media: stm32: dma2d: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-17 11:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Maxime Coquelin, Alexandre Torgue,
Hans Verkuil, Laurent Pinchart, Benjamin Gaignard, Kees Cook,
Guangshuo Li, Jacopo Mondi, Dillon Min, linux-media, linux-stm32,
linux-arm-kernel, linux-kernel
dma2d_probe() allocates a video_device with video_device_alloc() and
releases it from the rel_vdev error path if video_register_device()
fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
dma2d_probe()
-> rel_vdev
-> video_device_release(vfd)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free vfd through vdev->release().
dma2d_probe() then releases vfd exactly once from rel_vdev. Restore
video_device_release() after successful registration so the registered
device keeps its normal lifetime handling.
This issue was found by a static analysis tool I am developing.
Fixes: 002e8f0d5927 ("media: stm32-dma2d: STM32 DMA2D driver")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/st/stm32/dma2d/dma2d.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/st/stm32/dma2d/dma2d.c b/drivers/media/platform/st/stm32/dma2d/dma2d.c
index a3ad19256859..0e36ddfa8c7b 100644
--- a/drivers/media/platform/st/stm32/dma2d/dma2d.c
+++ b/drivers/media/platform/st/stm32/dma2d/dma2d.c
@@ -651,6 +651,7 @@ static int dma2d_probe(struct platform_device *pdev)
}
*vfd = dma2d_videodev;
+ vfd->release = video_device_release_empty;
vfd->lock = &dev->mutex;
vfd->v4l2_dev = &dev->v4l2_dev;
vfd->device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING;
@@ -669,6 +670,8 @@ static int dma2d_probe(struct platform_device *pdev)
goto free_m2m;
}
+ vfd->release = video_device_release;
+
video_set_drvdata(vfd, dev);
dev->vfd = vfd;
v4l2_info(&dev->v4l2_dev, "device registered as /dev/video%d\n",
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 03/11] m68k: mcf5441x: setup DAC clock name as per driver name
From: Jonathan Cameron @ 2026-05-17 11:43 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, David Lechner, Nuno Sá,
Andy Shevchenko, Greg Ungerer, linux-m68k, linux-kernel,
linux-stm32, linux-arm-kernel, linux-iio
In-Reply-To: <CALSJ-wAqFni+OwSUcQS+KESfe7SbWMxc0aCURHtTZ93Rx6GZhw@mail.gmail.com>
On Sun, 17 May 2026 02:11:33 -0700
Angelo Dureghello <adureghello@baylibre.com> wrote:
> Hi Greg,
>
> jfyi, for some reason i was not in to/cc, but i could grab the message
> in lore.
>
> On Thu, May 14, 2026 at 10:54:32PM +1000, Greg Ungerer wrote:
> > Hi Angelo,
> >
> > On 14/5/26 17:05, Angelo Dureghello wrote:
> > > Hi Greg,
> > >
> > > On 14.05.2026 11:27, Greg Ungerer wrote:
> > > > Hi Angelo,
> > > >
> > > > On 13/5/26 19:14, Angelo Dureghello wrote:
> > > > > From: Angelo Dureghello <adureghello@baylibre.com>
> > > > >
> > > > > Later in this patchset, the mcf54415 DAC driver is added.
> > > > > Considering some other different ColdFire cpu DACs exists, the DAC driver
> > > > > is named as "mcf54415_dac", related to the mcf5441x family SoCs with
> > > > > DACs (mcf54415/6/7/8).
> > > > >
> > > > > So updating DAC clock names to bind with proper driver name.
> > > >
> > > > I am not sure I like naming the clocks here with a prefix for the
> > > > specific SoC part number this is in. It might be unlikely now, but
> > > > what if another ColdFire family SoC member uses this same hardware block?
> > > > That is very common amongst other hardware blocks within the ColdFire
> > > > family. Can we come up with a name more specific to just this type
> > > > of DAC hardware block?
> > > >
> > >
> > > from a brief study, this 12bit DAC, and DAC module in general, is only on
> > > this mcf45441x family. There are some ColdFire with ADC only, as those
> > > mcf5249/53/82.
> > > The mcf51mm/ag/je are the opnly to have a 5bit dacs, but these are mcus.
> > > So, if i don't miss any existing model, the name may be correct,
> > > unless we want rename it to a more generic mcf_dac.
> >
> > Yes, I would suggest just leaving it as is, "mcfdac".
> > That is not currently used by any other ColdFire variants supported by
> > the kernel.
> >
>
> Ok, will fix this in a v3, just asking confirmation on the name to
> Jonathan and all, since it involves iio too.
>
> Chaches are:
> mcfdac
> mcf-dac or mcf_dac (we have drivers as vf610_dac and cio-dac)
I'm a bit lost. If we are talking about clocks that's fine as confusion is very
unlikely. If we are talking driver naming - pick a part on which it exists and
name it after that.
Historically we made a few mistakes letting in very generic driver names
and it causes confusion when a non compatible part comes along.
If we know these have 'versions' of IP like the QC ones do, then we could name
them after generations but that is often not actually documented anywhere
so would need confirmation from Coldfire folk.
Jonathan
>
> Regards,
> angelo
>
> > Regards
> > Greg
> >
> >
>
>
>
> >
> > > > Regards
> > > > Greg
> > > >
> > > >
> > >
> > > Regards,
> > > angelo
> > > >
> > > >
> > > > > Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
> > > > > ---
> > > > > arch/m68k/coldfire/m5441x.c | 8 ++++----
> > > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
> > > > > index 5b5e09ecf487..b724d7fc1a08 100644
> > > > > --- a/arch/m68k/coldfire/m5441x.c
> > > > > +++ b/arch/m68k/coldfire/m5441x.c
> > > > > @@ -43,8 +43,8 @@ DEFINE_CLK(0, "mcfpit.2", 34, MCF_BUSCLK);
> > > > > DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
> > > > > 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, "mcfdac.1", 39, MCF_CLK);
> > > > > +DEFINE_CLK(0, "mcf54415_dac.0", 38, MCF_CLK);
> > > > > +DEFINE_CLK(0, "mcf54415_dac.1", 39, 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);
> > > > > @@ -106,8 +106,8 @@ static struct clk_lookup m5411x_clk_lookup[] = {
> > > > > CLKDEV_INIT("mcfpit.3", NULL, &__clk_0_35),
> > > > > 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("mcfdac.1", NULL, &__clk_0_39),
> > > > > + CLKDEV_INIT("mcf54415_dac.0", NULL, &__clk_0_38),
> > > > > + CLKDEV_INIT("mcf54415_dac.1", NULL, &__clk_0_39),
> > > > > 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),
> > > > >
> > > >
> >
> >
^ permalink raw reply
* Re: [PATCH 0/4] firmware: arm_ffa: Move core init to platform driver probe
From: Sudeep Holla @ 2026-05-17 11:44 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, Sudeep Holla
Cc: Yeoreum Yun
In-Reply-To: <20260508-b4-ffa_plat_dev-v1-0-c5a30f8cf7b8@kernel.org>
On Fri, 08 May 2026 18:54:14 +0100, Sudeep Holla wrote:
> This series moves the Arm FF-A core initialisation into the driver model by
> converting the core bring-up path to a platform driver probe/remove flow.
>
> The first patch reverts the earlier rootfs_initcall change. That initcall
> ordering workaround is not a proper solution and potentially conflicts with
> pKVM FF-A proxy requirement.
>
> [...]
Applied to sudeep.holla/linux (for-next/ffa/updates), thanks!
[1/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"
https://git.kernel.org/sudeep.holla/c/cc7e8f21b9f0
[2/4] firmware: arm_ffa: Register core as a platform driver
https://git.kernel.org/sudeep.holla/c/e659fc8e537c
[3/4] firmware: arm_ffa: Set the core device as FF-A device parent
https://git.kernel.org/sudeep.holla/c/7fe2ec9fb8e9
[4/4] firmware: arm_ffa: Defer probe until pKVM is initialized
https://git.kernel.org/sudeep.holla/c/3acc80a78e45
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 03/11] m68k: mcf5441x: setup DAC clock name as per driver name
From: Geert Uytterhoeven @ 2026-05-17 11:45 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Steven King, Greg Ungerer, Arnd Bergmann, Maxime Coquelin,
Alexandre Torgue, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Greg Ungerer, linux-m68k, linux-kernel,
linux-stm32, linux-arm-kernel, linux-iio
In-Reply-To: <CALSJ-wAqFni+OwSUcQS+KESfe7SbWMxc0aCURHtTZ93Rx6GZhw@mail.gmail.com>
Hi Angelo,
There's something wrong with "Mail-Followup-To:", which lists everyone,
except for you...
On Sun, 17 May 2026 at 11:11, Angelo Dureghello
<adureghello@baylibre.com> wrote:
> jfyi, for some reason i was not in to/cc, but i could grab the message
> in lore.
Might be related...
> On Thu, May 14, 2026 at 10:54:32PM +1000, Greg Ungerer wrote:
> > On 14/5/26 17:05, Angelo Dureghello wrote:
> > > On 14.05.2026 11:27, Greg Ungerer wrote:
> > > > On 13/5/26 19:14, Angelo Dureghello wrote:
> > > > > From: Angelo Dureghello <adureghello@baylibre.com>
> > > > >
> > > > > Later in this patchset, the mcf54415 DAC driver is added.
> > > > > Considering some other different ColdFire cpu DACs exists, the DAC driver
> > > > > is named as "mcf54415_dac", related to the mcf5441x family SoCs with
> > > > > DACs (mcf54415/6/7/8).
> > > > >
> > > > > So updating DAC clock names to bind with proper driver name.
> > > >
> > > > I am not sure I like naming the clocks here with a prefix for the
> > > > specific SoC part number this is in. It might be unlikely now, but
> > > > what if another ColdFire family SoC member uses this same hardware block?
> > > > That is very common amongst other hardware blocks within the ColdFire
> > > > family. Can we come up with a name more specific to just this type
> > > > of DAC hardware block?
> > > >
> > >
> > > from a brief study, this 12bit DAC, and DAC module in general, is only on
> > > this mcf45441x family. There are some ColdFire with ADC only, as those
> > > mcf5249/53/82.
> > > The mcf51mm/ag/je are the opnly to have a 5bit dacs, but these are mcus.
> > > So, if i don't miss any existing model, the name may be correct,
> > > unless we want rename it to a more generic mcf_dac.
> >
> > Yes, I would suggest just leaving it as is, "mcfdac".
> > That is not currently used by any other ColdFire variants supported by
> > the kernel.
> >
>
> Ok, will fix this in a v3, just asking confirmation on the name to
> Jonathan and all, since it involves iio too.
>
> Chaches are:
> mcfdac
> mcf-dac or mcf_dac (we have drivers as vf610_dac and cio-dac)
The clock names in arch/m68k/coldfire/m5441x.c are the names as
specified by the producer side, not by the consumer side.
> > > > > --- a/arch/m68k/coldfire/m5441x.c
> > > > > +++ b/arch/m68k/coldfire/m5441x.c
> > > > > @@ -43,8 +43,8 @@ DEFINE_CLK(0, "mcfpit.2", 34, MCF_BUSCLK);
> > > > > DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
> > > > > 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, "mcfdac.1", 39, MCF_CLK);
> > > > > +DEFINE_CLK(0, "mcf54415_dac.0", 38, MCF_CLK);
> > > > > +DEFINE_CLK(0, "mcf54415_dac.1", 39, 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);
> > > > > @@ -106,8 +106,8 @@ static struct clk_lookup m5411x_clk_lookup[] = {
> > > > > CLKDEV_INIT("mcfpit.3", NULL, &__clk_0_35),
> > > > > 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("mcfdac.1", NULL, &__clk_0_39),
> > > > > + CLKDEV_INIT("mcf54415_dac.0", NULL, &__clk_0_38),
> > > > > + CLKDEV_INIT("mcf54415_dac.1", NULL, &__clk_0_39),
> > > > > 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),
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] media: s5p-g2d: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-17 11:46 UTC (permalink / raw)
To: Łukasz Stelmach, Mauro Carvalho Chehab, Kamil Debski,
Kyungmin Park, Marek Szyprowski, linux-arm-kernel, linux-media,
linux-kernel
Cc: Guangshuo Li
g2d_probe() allocates a video_device with video_device_alloc() and
releases it from the rel_vdev error path if video_register_device()
fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
g2d_probe()
-> rel_vdev
-> video_device_release(vfd)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free vfd through vdev->release().
g2d_probe() then releases vfd exactly once from rel_vdev. Restore
video_device_release() after successful registration so the registered
device keeps its normal lifetime handling.
This issue was found by a static analysis tool I am developing.
Fixes: 918847341af0 ("[media] v4l: add G2D driver for s5p device family")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/samsung/s5p-g2d/g2d.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/samsung/s5p-g2d/g2d.c b/drivers/media/platform/samsung/s5p-g2d/g2d.c
index a18b13db19d5..f38c28abd6d9 100644
--- a/drivers/media/platform/samsung/s5p-g2d/g2d.c
+++ b/drivers/media/platform/samsung/s5p-g2d/g2d.c
@@ -684,6 +684,7 @@ static int g2d_probe(struct platform_device *pdev)
goto unreg_v4l2_dev;
}
*vfd = g2d_videodev;
+ vfd->release = video_device_release_empty;
set_bit(V4L2_FL_QUIRK_INVERTED_CROP, &vfd->flags);
vfd->lock = &dev->mutex;
vfd->v4l2_dev = &dev->v4l2_dev;
@@ -711,6 +712,8 @@ static int g2d_probe(struct platform_device *pdev)
v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
goto free_m2m;
}
+
+ vfd->release = video_device_release;
video_set_drvdata(vfd, dev);
dev->vfd = vfd;
v4l2_info(&dev->v4l2_dev, "device registered as /dev/video%d\n",
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] clk: scpi: pass child node to of_clk_del_provider() in remove
From: Sudeep Holla @ 2026-05-17 11:47 UTC (permalink / raw)
To: Stepan Ionichev
Cc: Sudeep Holla, cristian.marussi, mturquette, sboyd, arm-scmi,
linux-arm-kernel, linux-clk, linux-kernel
In-Reply-To: <20260513090900.5323-1-sozdayvek@gmail.com>
On Wed, 13 May 2026 14:09:00 +0500, Stepan Ionichev wrote:
> scpi_clocks_remove() iterates over the SCPI clock provider's child
> device nodes, but passes the parent node to of_clk_del_provider()
> on every iteration:
>
> for_each_available_child_of_node(np, child)
> of_clk_del_provider(np);
>
> [...]
Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!
[1/1] clk: scpi: pass child node to of_clk_del_provider() in remove
https://git.kernel.org/sudeep.holla/c/b79d9b5747d9
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] media: meson: ge2d: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-17 11:53 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Hans Verkuil, linux-media,
linux-amlogic, linux-arm-kernel, linux-kernel
Cc: Guangshuo Li
ge2d_probe() allocates a video_device with video_device_alloc() and
releases it from the rel_vdev error path if video_register_device()
fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
ge2d_probe()
-> rel_vdev
-> video_device_release(ge2d->vfd)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free ge2d->vfd through vdev->release().
ge2d_probe() then releases ge2d->vfd exactly once from rel_vdev. Restore
video_device_release() after successful registration so the registered
device keeps its normal lifetime handling.
This issue was found by a static analysis tool I am developing.
Fixes: 59a635327ca7 ("media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/amlogic/meson-ge2d/ge2d.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/amlogic/meson-ge2d/ge2d.c b/drivers/media/platform/amlogic/meson-ge2d/ge2d.c
index c5dc03905ce0..b367169e6ad8 100644
--- a/drivers/media/platform/amlogic/meson-ge2d/ge2d.c
+++ b/drivers/media/platform/amlogic/meson-ge2d/ge2d.c
@@ -983,6 +983,7 @@ static int ge2d_probe(struct platform_device *pdev)
}
*vfd = ge2d_videodev;
+ vfd->release = video_device_release_empty;
vfd->lock = &ge2d->mutex;
vfd->v4l2_dev = &ge2d->v4l2_dev;
@@ -1005,6 +1006,7 @@ static int ge2d_probe(struct platform_device *pdev)
v4l2_info(&ge2d->v4l2_dev, "Registered %s as /dev/%s\n",
vfd->name, video_device_node_name(vfd));
+ vfd->release = video_device_release;
return 0;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/4] firmware: arm_ffa: Move core init to platform driver probe
From: Sudeep Holla @ 2026-05-17 11:54 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: Yeoreum Yun, Sudeep Holla
In-Reply-To: <177901775932.3835515.4484747964630642694.b4-ty@b4>
On Sun, May 17, 2026 at 12:36:45PM +0100, Sudeep Holla wrote:
> On Fri, 08 May 2026 18:54:14 +0100, Sudeep Holla wrote:
> > This series moves the Arm FF-A core initialisation into the driver model by
> > converting the core bring-up path to a platform driver probe/remove flow.
> >
> > The first patch reverts the earlier rootfs_initcall change. That initcall
> > ordering workaround is not a proper solution and potentially conflicts with
> > pKVM FF-A proxy requirement.
> >
> > [...]
>
> Applied to sudeep.holla/linux (for-next/ffa/updates), thanks!
>
> [1/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"
> https://git.kernel.org/sudeep.holla/c/1b4c1c4d75a8
> [2/4] firmware: arm_ffa: Register core as a platform driver
> https://git.kernel.org/sudeep.holla/c/d10175dd517a
> [3/4] firmware: arm_ffa: Set the core device as FF-A device parent
> https://git.kernel.org/sudeep.holla/c/8bdff2dda405
> [4/4] firmware: arm_ffa: Defer probe until pKVM is initialized
> https://git.kernel.org/sudeep.holla/c/216d4772b411
These are incorrect and fixed in later email, this was accidental send.
Please ignore.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] crypto: atmel-sha204a - remove sysfs group before hwrng
From: Thorsten Blum @ 2026-05-17 12:37 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
atmel_sha204a_probe() registers the hwrng before creating the sysfs
group. Mirror this order in atmel_sha204a_remove() by removing the sysfs
group before unregistering the hwrng.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-sha204a.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index 6e6ac4770416..37538b0fd7c2 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -199,11 +199,10 @@ static void atmel_sha204a_remove(struct i2c_client *client)
{
struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
+ sysfs_remove_group(&client->dev.kobj, &atmel_sha204a_groups);
devm_hwrng_unregister(&client->dev, &i2c_priv->hwrng);
atmel_i2c_flush_queue();
- sysfs_remove_group(&client->dev.kobj, &atmel_sha204a_groups);
-
kfree((void *)i2c_priv->hwrng.priv);
}
^ permalink raw reply related
* usb: gadget: aspeed_udc: list iterator used after loop in ast_udc_ep_dequeue
From: Xie Maoyi @ 2026-05-17 14:03 UTC (permalink / raw)
To: neal_liu@aspeedtech.com, gregkh@linuxfoundation.org
Cc: joel@jms.id.au, andrew@codeconstruct.com.au,
linux-aspeed@lists.ozlabs.org, linux-usb@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 3295 bytes --]
Hi all,
I have been running a small static check for list_for_each_entry
past-the-end patterns, similar to Jakob Koschel's 2022 cleanup
(commit 2966a9918df and related). The check flagged
ast_udc_ep_dequeue() in drivers/usb/gadget/udc/aspeed_udc.c, and I
would like to ask whether you consider this a real defect before I
send anything formal. The same code is present in v7.0 and in
v7.1-rc1 (the two files are byte-identical).
The code in question is around line 691:
struct ast_udc_request *req;
...
list_for_each_entry(req, &ep->queue, queue) {
if (&req->req == _req) {
list_del_init(&req->queue);
ast_udc_done(ep, req, -ESHUTDOWN);
_req->status = -ECONNRESET;
break;
}
}
if (&req->req != _req)
rc = -EINVAL;
If nothing matches, the loop exits past-the-end and req becomes the
synthetic container_of(&ep->queue, struct ast_udc_request, queue).
Reading &req->req after the loop is undefined per C11. The post-loop
check works in practice only because real _req values do not collide
with that synthetic address.
What made me suspect this was not intentional is that 14 other UDC
drivers in the same directory (at91_udc, atmel_usba_udc, dummy_hcd,
fsl_qe_udc, fsl_udc_core, goku_udc, gr_udc, lpc32xx_udc, max3420_udc,
net2280, omap_udc, pxa25x_udc, pxa27x_udc, udc-xilinx) use a
different pattern, with a separate iter cursor and a result variable.
For example dummy_hcd.c:
struct dummy_request *req = NULL, *iter;
list_for_each_entry(iter, &ep->queue, queue) {
if (&iter->req != _req) continue;
...
req = iter;
retval = 0;
break;
}
if (retval == 0) { ... }
aspeed_udc seems to be the only outlier in drivers/usb/gadget/udc/,
which is what made me think this was probably an oversight rather
than a deliberate idiom.
I also tried to confirm whether it observably misbehaves. If _req
happens to coincide with the synthetic past-the-end address, the
function returns 0 (success) on an empty queue without removing
anything. I attached a small userspace reproducer (poc_aspeed_udc.c
and its output log) that arranges this collision. In normal use _req
comes from the kernel slab and the collision is unlikely to happen
naturally, so I am not sure whether this rises to the level of a
real bug or just a code-quality issue.
Two questions:
1. Do you consider the past-the-end use here a defect worth fixing,
or is it an accepted idiom in this driver that I am misreading?
2. If it is worth fixing, I already have a small patch that brings
the function in line with the 14 sibling drivers. Would you like
me to send it, or would you rather address it locally?
Thanks for taking a look, and apologies if I am off base on any of
this.
Best,
Maoyi Xie
--
Nanyang Technological University
https://maoyixie.com/
________________________________
CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its contents.
Towards a sustainable earth: Print only when necessary. Thank you.
[-- Attachment #2: poc_aspeed_udc.log --]
[-- Type: application/octet-stream, Size: 402 bytes --]
$ ./poc_aspeed_udc
[setup] ep.queue=0x7ffefe0b1cd0 (head)
[setup] past_end=0x7ffefe0b1cc0
[setup] fake_req=0x7ffefe0b1cc0
[probe] existing rc=0
[result] returned 0 (success) on empty queue without removing anything
$ ./poc_aspeed_udc patched
[setup] ep.queue=0x7ffee648eee0 (head)
[setup] past_end=0x7ffee648eed0
[setup] fake_req=0x7ffee648eed0
[probe] patched rc=-22
[result] returned -22 (rejected)
[-- Attachment #3: poc_aspeed_udc.c --]
[-- Type: text/plain, Size: 4521 bytes --]
/*
* Userspace reproducer for the past-the-end iterator behavior in
* ast_udc_ep_dequeue() (drivers/usb/gadget/udc/aspeed_udc.c).
*
* Aspeed UDC is BMC/ARM hardware. Rather than bringing up a full SoC
* emulation, this program extracts the dequeue function's logic into
* userspace using mock structs whose layout (req at offset 0, queue
* immediately after) matches the kernel definition. It then runs both
* the existing code path and the proposed fix on the same crafted input.
*
* Build: cc -O0 -g poc_aspeed_udc.c -o poc_aspeed_udc
* Run: ./poc_aspeed_udc (existing code, returns 42)
* ./poc_aspeed_udc patched (proposed fix, returns 0)
*/
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stddef.h>
/* Minimal mock of the kernel list_head and container_of. */
struct list_head { struct list_head *next, *prev; };
#define container_of(ptr, type, member) \
((type *)((char *)(ptr) - offsetof(type, member)))
#define list_first_entry(ptr, type, member) \
container_of((ptr)->next, type, member)
#define list_next_entry(pos, member) \
container_of((pos)->member.next, typeof(*(pos)), member)
#define list_entry_is_head(pos, head, member) \
(&(pos)->member == (head))
#define list_for_each_entry(pos, head, member) \
for (pos = list_first_entry(head, typeof(*pos), member); \
!list_entry_is_head(pos, head, member); \
pos = list_next_entry(pos, member))
static void list_init(struct list_head *h) { h->next = h->prev = h; }
/* Mock structs. Only field order matters: req at offset 0, queue
* immediately after. */
struct usb_request {
void *buf;
unsigned length;
int status;
};
struct ast_udc_request {
struct usb_request req;
struct list_head queue;
int pad;
};
struct ast_udc_ep {
struct list_head queue;
};
/* Existing code path from aspeed_udc.c around line 691. Locks and
* the ast_udc_done() callback are elided since the past-the-end
* behavior is independent of them. */
static int ast_udc_ep_dequeue_existing(struct ast_udc_ep *ep,
struct usb_request *_req)
{
struct ast_udc_request *req;
int rc = 0;
list_for_each_entry(req, &ep->queue, queue) {
if (&req->req == _req) {
/* list_del_init + ast_udc_done + set status here */
break;
}
}
/* When the loop finds no match, req is past-the-end. Reading
* &req->req is undefined per C11; the resulting check is a
* property of heap layout rather than the queue contents. */
if (&req->req != _req)
rc = -22; /* -EINVAL */
return rc;
}
/* Proposed fix using the separate iter cursor pattern shared by the
* other UDC drivers in the same directory (e.g. dummy_hcd.c). */
static int ast_udc_ep_dequeue_patched(struct ast_udc_ep *ep,
struct usb_request *_req)
{
struct ast_udc_request *req = NULL, *iter;
list_for_each_entry(iter, &ep->queue, queue) {
if (&iter->req != _req)
continue;
req = iter;
break;
}
if (!req)
return -22; /* -EINVAL */
/* list_del_init + ast_udc_done + set status here */
return 0;
}
int main(int argc, char **argv)
{
int use_patched = (argc > 1 && !strcmp(argv[1], "patched"));
struct ast_udc_ep ep;
list_init(&ep.queue);
/* An empty queue forces the existing code's iterator past the end.
* past_end is the synthetic ast_udc_request pointer the loop will
* leave behind. Because req is the first member, &past_end->req
* has the same numeric value as past_end itself. */
struct ast_udc_request *past_end =
container_of(&ep.queue, struct ast_udc_request, queue);
struct usb_request *fake_req = &past_end->req;
printf("[setup] ep.queue=%p (head)\n", (void *)&ep.queue);
printf("[setup] past_end=%p\n", (void *)past_end);
printf("[setup] fake_req=%p\n", (void *)fake_req);
int rc;
if (use_patched) {
rc = ast_udc_ep_dequeue_patched(&ep, fake_req);
printf("[probe] patched rc=%d\n", rc);
} else {
rc = ast_udc_ep_dequeue_existing(&ep, fake_req);
printf("[probe] existing rc=%d\n", rc);
}
if (rc == 0) {
printf("[result] returned 0 (success) on empty queue without "
"removing anything\n");
return 42;
}
printf("[result] returned %d (rejected)\n", rc);
return 0;
}
^ permalink raw reply
* Re: usb: gadget: aspeed_udc: list iterator used after loop in ast_udc_ep_dequeue
From: gregkh @ 2026-05-17 14:21 UTC (permalink / raw)
To: Xie Maoyi
Cc: neal_liu@aspeedtech.com, joel@jms.id.au,
andrew@codeconstruct.com.au, linux-aspeed@lists.ozlabs.org,
linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <TYZPR01MB67588F1EEB07DBEB681AEE1ADC022@TYZPR01MB6758.apcprd01.prod.exchangelabs.com>
On Sun, May 17, 2026 at 02:03:47PM +0000, Xie Maoyi wrote:
> CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its contents.
Now deleted.
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: mfd: st,stmpe: fix PWM schema and drop legacy binding
From: Uwe Kleine-König @ 2026-05-17 15:05 UTC (permalink / raw)
To: Manish Baing
Cc: lee, linusw, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, linux-pwm
In-Reply-To: <20260509193928.19030-1-manishbaing2789@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]
Hello,
On Sat, May 09, 2026 at 07:39:28PM +0000, Manish Baing wrote:
> The st,stmpe-pwm binding is already covered by the MFD schema in
> Documentation/devicetree/bindings/mfd/st,stmpe.yaml. However, the
> PWM subnode was missing a 'required' properties block. This allowed
> Device Tree nodes to pass validation even if the 'compatible'
> string was omitted. This omission could lead to probe failures
> at runtime.
>
> Fix the schema by adding the missing 'required' block and
> remove the obsolete and redundant text binding file.
>
> Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
> ---
> Changes in v3:
> - Added 'required' properties to the pwm subnode in st,stmpe.yaml
> to close a validation gap identified by the Sashiko.
> - Updated commit message and description to reflect MFD subsystem changes.
>
> Changes in v2:
> - Droppped the TXT file instead of converting to YAML, as the
> functionality is already covered by st,stmpe.yaml.
>
> .../devicetree/bindings/mfd/st,stmpe.yaml | 4 ++++
> .../devicetree/bindings/pwm/st,stmpe-pwm.txt | 18 ------------------
If the patch was split into two, each touching just one of the files,
there would be no need for merge coordination. Also logically it's two
patches. Would you mind splitting?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* usb: gadget: aspeed_udc: list iterator used after loop in ast_udc_ep_dequeue
From: Maoyi Xie @ 2026-05-17 15:46 UTC (permalink / raw)
To: neal_liu, gregkh
Cc: joel, andrew, linux-aspeed, linux-usb, linux-arm-kernel,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]
Hi all,
(Resending from a personal address — my previous attempt from
my NTU corporate account carried an auto-appended confidentiality
disclaimer that you've declined to accept. The content below is
unchanged.)
I have been running a small static check for list_for_each_entry
past-the-end patterns, similar to Jakob Koschel's 2022 cleanup
(commit 2966a9918df and related). The check flagged
ast_udc_ep_dequeue() in drivers/usb/gadget/udc/aspeed_udc.c, and I
would like to ask whether you consider this a real defect before I
send anything formal. The same code is present in v7.0 and in
v7.1-rc1 (the two files are byte-identical).
The code in question is around line 691:
struct ast_udc_request *req;
...
list_for_each_entry(req, &ep->queue, queue) {
if (&req->req == _req) {
list_del_init(&req->queue);
ast_udc_done(ep, req, -ESHUTDOWN);
_req->status = -ECONNRESET;
break;
}
}
if (&req->req != _req)
rc = -EINVAL;
If nothing matches, the loop exits past-the-end and req becomes the
synthetic container_of(&ep->queue, struct ast_udc_request, queue).
Reading &req->req after the loop is undefined per C11. The post-loop
check works in practice only because real _req values do not collide
with that synthetic address.
What made me suspect this was not intentional is that 14 other UDC
drivers in the same directory (at91_udc, atmel_usba_udc, dummy_hcd,
fsl_qe_udc, fsl_udc_core, goku_udc, gr_udc, lpc32xx_udc, max3420_udc,
net2280, omap_udc, pxa25x_udc, pxa27x_udc, udc-xilinx) use a
different pattern, with a separate iter cursor and a result variable.
For example dummy_hcd.c:
struct dummy_request *req = NULL, *iter;
list_for_each_entry(iter, &ep->queue, queue) {
if (&iter->req != _req) continue;
...
req = iter;
retval = 0;
break;
}
if (retval == 0) { ... }
aspeed_udc seems to be the only outlier in drivers/usb/gadget/udc/,
which is what made me think this was probably an oversight rather
than a deliberate idiom.
I also tried to confirm whether it observably misbehaves. If _req
happens to coincide with the synthetic past-the-end address, the
function returns 0 (success) on an empty queue without removing
anything. I attached a small userspace reproducer (poc_aspeed_udc.c
and its output log) that arranges this collision. In normal use _req
comes from the kernel slab and the collision is unlikely to happen
naturally, so I am not sure whether this rises to the level of a
real bug or just a code-quality issue.
Two questions:
1. Do you consider the past-the-end use here a defect worth fixing,
or is it an accepted idiom in this driver that I am misreading?
2. If it is worth fixing, I already have a small patch that brings
the function in line with the 14 sibling drivers. Would you like
me to send it, or would you rather address it locally?
Thanks for taking a look, and apologies if I am off base on any of
this.
Best,
Maoyi Xie
--
Nanyang Technological University
https://maoyixie.com/
[-- Attachment #2: poc_aspeed_udc.c --]
[-- Type: application/octet-stream, Size: 4521 bytes --]
/*
* Userspace reproducer for the past-the-end iterator behavior in
* ast_udc_ep_dequeue() (drivers/usb/gadget/udc/aspeed_udc.c).
*
* Aspeed UDC is BMC/ARM hardware. Rather than bringing up a full SoC
* emulation, this program extracts the dequeue function's logic into
* userspace using mock structs whose layout (req at offset 0, queue
* immediately after) matches the kernel definition. It then runs both
* the existing code path and the proposed fix on the same crafted input.
*
* Build: cc -O0 -g poc_aspeed_udc.c -o poc_aspeed_udc
* Run: ./poc_aspeed_udc (existing code, returns 42)
* ./poc_aspeed_udc patched (proposed fix, returns 0)
*/
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stddef.h>
/* Minimal mock of the kernel list_head and container_of. */
struct list_head { struct list_head *next, *prev; };
#define container_of(ptr, type, member) \
((type *)((char *)(ptr) - offsetof(type, member)))
#define list_first_entry(ptr, type, member) \
container_of((ptr)->next, type, member)
#define list_next_entry(pos, member) \
container_of((pos)->member.next, typeof(*(pos)), member)
#define list_entry_is_head(pos, head, member) \
(&(pos)->member == (head))
#define list_for_each_entry(pos, head, member) \
for (pos = list_first_entry(head, typeof(*pos), member); \
!list_entry_is_head(pos, head, member); \
pos = list_next_entry(pos, member))
static void list_init(struct list_head *h) { h->next = h->prev = h; }
/* Mock structs. Only field order matters: req at offset 0, queue
* immediately after. */
struct usb_request {
void *buf;
unsigned length;
int status;
};
struct ast_udc_request {
struct usb_request req;
struct list_head queue;
int pad;
};
struct ast_udc_ep {
struct list_head queue;
};
/* Existing code path from aspeed_udc.c around line 691. Locks and
* the ast_udc_done() callback are elided since the past-the-end
* behavior is independent of them. */
static int ast_udc_ep_dequeue_existing(struct ast_udc_ep *ep,
struct usb_request *_req)
{
struct ast_udc_request *req;
int rc = 0;
list_for_each_entry(req, &ep->queue, queue) {
if (&req->req == _req) {
/* list_del_init + ast_udc_done + set status here */
break;
}
}
/* When the loop finds no match, req is past-the-end. Reading
* &req->req is undefined per C11; the resulting check is a
* property of heap layout rather than the queue contents. */
if (&req->req != _req)
rc = -22; /* -EINVAL */
return rc;
}
/* Proposed fix using the separate iter cursor pattern shared by the
* other UDC drivers in the same directory (e.g. dummy_hcd.c). */
static int ast_udc_ep_dequeue_patched(struct ast_udc_ep *ep,
struct usb_request *_req)
{
struct ast_udc_request *req = NULL, *iter;
list_for_each_entry(iter, &ep->queue, queue) {
if (&iter->req != _req)
continue;
req = iter;
break;
}
if (!req)
return -22; /* -EINVAL */
/* list_del_init + ast_udc_done + set status here */
return 0;
}
int main(int argc, char **argv)
{
int use_patched = (argc > 1 && !strcmp(argv[1], "patched"));
struct ast_udc_ep ep;
list_init(&ep.queue);
/* An empty queue forces the existing code's iterator past the end.
* past_end is the synthetic ast_udc_request pointer the loop will
* leave behind. Because req is the first member, &past_end->req
* has the same numeric value as past_end itself. */
struct ast_udc_request *past_end =
container_of(&ep.queue, struct ast_udc_request, queue);
struct usb_request *fake_req = &past_end->req;
printf("[setup] ep.queue=%p (head)\n", (void *)&ep.queue);
printf("[setup] past_end=%p\n", (void *)past_end);
printf("[setup] fake_req=%p\n", (void *)fake_req);
int rc;
if (use_patched) {
rc = ast_udc_ep_dequeue_patched(&ep, fake_req);
printf("[probe] patched rc=%d\n", rc);
} else {
rc = ast_udc_ep_dequeue_existing(&ep, fake_req);
printf("[probe] existing rc=%d\n", rc);
}
if (rc == 0) {
printf("[result] returned 0 (success) on empty queue without "
"removing anything\n");
return 42;
}
printf("[result] returned %d (rejected)\n", rc);
return 0;
}
[-- Attachment #3: poc_aspeed_udc.log --]
[-- Type: application/octet-stream, Size: 402 bytes --]
$ ./poc_aspeed_udc
[setup] ep.queue=0x7ffefe0b1cd0 (head)
[setup] past_end=0x7ffefe0b1cc0
[setup] fake_req=0x7ffefe0b1cc0
[probe] existing rc=0
[result] returned 0 (success) on empty queue without removing anything
$ ./poc_aspeed_udc patched
[setup] ep.queue=0x7ffee648eee0 (head)
[setup] past_end=0x7ffee648eed0
[setup] fake_req=0x7ffee648eed0
[probe] patched rc=-22
[result] returned -22 (rejected)
^ permalink raw reply
* [PATCH] crypto: atmel-sha204a - fail on hwrng registration error in probe path
From: Thorsten Blum @ 2026-05-17 16:27 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Lothar Rubusch
Cc: stable, linux-crypto, linux-arm-kernel, linux-kernel
Commit 13909a0c8897 ("crypto: atmel-sha204a - provide the otp content")
overwrote the hwrng registration return value when creating the sysfs
group, which allowed atmel_sha204a_probe() to succeed even if
devm_hwrng_register() failed.
Return immediately when devm_hwrng_register() fails, and report both
hwrng and sysfs registration errors with dev_err(). Adjust the sysfs
error log message for consistency.
Fixes: 13909a0c8897 ("crypto: atmel-sha204a - provide the otp content")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-sha204a.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index 37538b0fd7c2..12eb85b57380 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -183,12 +183,14 @@ static int atmel_sha204a_probe(struct i2c_client *client)
i2c_priv->hwrng.quality = *quality;
ret = devm_hwrng_register(&client->dev, &i2c_priv->hwrng);
- if (ret)
- dev_warn(&client->dev, "failed to register RNG (%d)\n", ret);
+ if (ret) {
+ dev_err(&client->dev, "failed to register RNG (%d)\n", ret);
+ return ret;
+ }
ret = sysfs_create_group(&client->dev.kobj, &atmel_sha204a_groups);
if (ret) {
- dev_err(&client->dev, "failed to register sysfs entry\n");
+ dev_err(&client->dev, "failed to create sysfs group (%d)\n", ret);
return ret;
}
^ permalink raw reply related
* [PATCH] arm64: dts: renesas: r8a78000: Describe all reserved memory
From: Marek Vasut @ 2026-05-17 16:31 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
Fully describe all available DRAM in the DT, and describe regions which
are not accessible because they are used by firmware in reserved-memory
node.
Replace first memory bank memory@60600000 with memory@40000000 and a
518 MiB long reserved-memory no-map subnode. This memory region is used
by other cores in the system.
Reserve 32 kiB of memory at 0x8c100000 for parameters shared by IPL,
SCP, TFA BL31 and TEE.
Reserve 512 kiB of memory at 0x8c200000 for TFA BL31. The upcoming
upstream TFA 2.15 BL31 uses memory from 0x8c200000..0x8c242fff, the
round up to 512 kiB is slight future proofing.
Reserve 32 MiB of memory at 0x8c400000 for OPTEE-OS, which is the
entire OPTEE-OS TZ protected DRAM area.
Neither the TFA BL31 nor OPTEE-OS do modify the DT passed to Linux in
any way with any new reserved-memory {} node to reserve memory areas
used by the TFA BL31 or OPTEE-OS to prevent the next stage from using
those areas, which lets Linux use all of the available DRAM as it is
described in the DT that was passed in by U-Boot, including the areas
that are newly utilized by TFA BL31 or OPTEE-OS.
In case of high DRAM utilization, unless the memory used by TFA BL31
or OPTEE-OS is properly reserved, Linux may use and corrupt the memory
used by TFA BL31 or OPTEE-OS, which would lead to the system becoming
unresponsive.
Fixes: ad142a4ef710 ("arm64: dts: renesas: r8a78000: Add initial Ironhide board support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../boot/dts/renesas/r8a78000-ironhide.dts | 35 +++++++++++++++++--
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
index a721734fbd5d0..99f4cfb53e0f8 100644
--- a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
+++ b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
@@ -20,10 +20,9 @@ chosen {
stdout-path = "serial0:1843200n8";
};
- memory@60600000 {
+ memory@40000000 {
device_type = "memory";
- /* first 518MiB is reserved for other purposes. */
- reg = <0x0 0x60600000 0x0 0x5fa00000>;
+ reg = <0x0 0x40000000 0x0 0x80000000>;
};
memory@1080000000 {
@@ -65,6 +64,36 @@ memory@1e00000000 {
device_type = "memory";
reg = <0x1e 0x00000000 0x1 0x00000000>;
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* First 518 MiB is reserved for other purposes. */
+ firmware@40000000 {
+ reg = <0x0 0x40000000 0x0 0x20600000>;
+ no-map;
+ };
+
+ /* Parameters set by IPL. */
+ parameters@8c100000 {
+ reg = <0x0 0x8c100000 0x0 0x00008000>;
+ no-map;
+ };
+
+ /* TFA BL31. */
+ tfa-bl31@8c200000 {
+ reg = <0x0 0x8c200000 0x0 0x00080000>;
+ no-map;
+ };
+
+ /* TEE TZ DRAM. */
+ tee@8c400000 {
+ reg = <0x0 0x8c400000 0x0 0x02000000>;
+ no-map;
+ };
+ };
};
&extal_clk {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] pwm: atmel-tcb: Remove unneeded semicolon
From: Uwe Kleine-König @ 2026-05-17 16:52 UTC (permalink / raw)
To: Chen Ni
Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea, linux-pwm,
linux-arm-kernel
In-Reply-To: <afC3PwD0LfzYSoMP@monoceros>
[-- Attachment #1: Type: text/plain, Size: 746 bytes --]
Hello Chen,
On Tue, Apr 28, 2026 at 03:36:45PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Apr 28, 2026 at 03:53:29PM +0800, Chen Ni wrote:
> > - goto err_disable_clk;;
> > + goto err_disable_clk;
>
> Oh, that is my fault. If you're ok I'd add
>
> This was introduced in commit 68637b68afcc ("pwm: atmel-tcb:
> Cache clock rates and mark chip as atomic") in Uwe's adaption of
> Sangyun's original patch.
>
> to the commit log. I'll apply it then to my fixes branch but not send it
> to Linus. But if something more urgent pops up I'll send it along.
I'd like to pick up this commit, but don't want to modify the commit log
without your consent. For now this is blocked because of that.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: rockchip: inno-hdmi: Add configure() and validate() ops
From: Vinod Koul @ 2026-05-17 16:54 UTC (permalink / raw)
To: Jonas Karlman
Cc: Neil Armstrong, Heiko Stuebner, linux-phy, linux-rockchip,
linux-arm-kernel, linux-kernel
In-Reply-To: <d69b500b-0473-496d-b17e-c60ce9839e0c@kwiboo.se>
On 15-05-26, 23:04, Jonas Karlman wrote:
> Hi,
>
> On 5/15/2026 9:55 PM, Jonas Karlman wrote:
> > The commit 10ed34d6eaaf ("phy: Add HDMI configuration options")
> > introduced a way for HDMI PHYs to be configured through the generic
> > phy_configure() function.
> >
> > This driver derives the TMDS character rate from the pixel clock and the
> > PHY bus width setting. However, no in-tree consumer of this PHY has ever
> > called phy_set_bus_width() to change the TMDS character rate as only
> > 8-bit RGB output is supported by the HDMI display driver.
> >
> > Add configure() and validate() ops to allow consumers to configure the
> > TMDS character rate using phy_configure(). Fallback to the deprecated
> > way of using the PHY bus width to configure the TMDS character rate.
> >
> > A typical call chain during DRM modeset on a RK3328 device:
> >
> > dw_hdmi_rockchip_encoder_atomic_check():
> > - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000
> >
> > dw_hdmi_rockchip_encoder_atomic_mode_set():
> > - inno_hdmi_phy_configure(): pixclock 148500000
> > - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000
> >
> > vop_crtc_atomic_enable():
> > - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000
> > - inno_hdmi_phy_rk3328_clk_set_rate(): pixclock 594000000 tmdsclock 594000000
> > - inno_hdmi_phy_rk3328_clk_recalc_rate(): pixclock 594000000 vco 594000000
> >
> > dw_hdmi_rockchip_encoder_enable():
> > - inno_hdmi_phy_power_on(): Inno HDMI PHY Power On
> > - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000
> >
> > Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> > ---
> > Changes in v3:
> > - Change validate() ops to only validate tmdsclock
> > - Add comments about expected consumer usage
> > - Update commit message with a typical call chain
> > Changes in v2:
> > - Add validate() ops to validate that the TMDS rate is supported
> > - Split out parts that remove the old workaround into a separate patch
> >
> > Patch "drm/rockchip: dw_hdmi: Configure HDMI PHY in atomic_mode_set()"
> > at [1] adds phy_validate() and phy_configure() calls for this HDMI PHY.
> >
> > [1] https://lore.kernel.org/dri-devel/20260510183114.1248840-10-jonas@kwiboo.se/
> > ---
> > drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 60 ++++++++++++++++++-
> > 1 file changed, 59 insertions(+), 1 deletion(-)
>
> [snip]
>
> > +static int inno_hdmi_phy_validate(struct phy *phy, enum phy_mode mode,
> > + int submode, union phy_configure_opts *opts)
> > +{
> > + const struct pre_pll_config *cfg = pre_pll_cfg_table;
> > + unsigned long tmdsclock;
> > +
> > + if (!(mode == PHY_MODE_HDMI && submode == PHY_HDMI_MODE_TMDS))
> > + return -EINVAL;
> > +
> > + if (!opts->hdmi.tmds_char_rate || opts->hdmi.tmds_char_rate > 594000000)
> > + return -EINVAL;
>
> Sashiko reasoning log pointed out that a consumer of phy_validate() or
> phy_configure() can make a call with opts=NULL, so I may likely send a
> v4 of this series to fix such possible NULL pointer dereference here.
Yes please
>
> Or is that something that possible should be checked before phy core
> calls the .validate()/.configure() ops?
The opts is an optional argument depending upon the mode to be valid. So
we cant do that in the core...
>
> Multiple other phy .configure() ops seem to dereference opts members
> without any type of opts NULL check. (next-20260508)
We should fix these
PS: Any reason why you are sending encypted emails?
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 2/2] pwm: meson: Add support for Amlogic S7
From: Uwe Kleine-König @ 2026-05-17 17:12 UTC (permalink / raw)
To: xianwei.zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiner Kallweit,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pwm, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <20260402-s6-s7-pwm-v2-2-657dce040956@amlogic.com>
[-- Attachment #1: Type: text/plain, Size: 2555 bytes --]
Hello,
On Thu, Apr 02, 2026 at 02:40:16AM +0000, Xianwei Zhao via B4 Relay wrote:
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> Add support for Amlogic S7 PWM. Amlogic S7 different from the
> previous SoCs, a controller includes one pwm, at the same time,
> the controller has only one input clock source.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
> ---
> drivers/pwm/pwm-meson.c | 32 +++++++++++++++++++++++++++++---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
> index 8c6bf3d49753..7a43c42ef3d6 100644
> --- a/drivers/pwm/pwm-meson.c
> +++ b/drivers/pwm/pwm-meson.c
> @@ -113,6 +113,7 @@ struct meson_pwm_data {
> int (*channels_init)(struct pwm_chip *chip);
> bool has_constant;
> bool has_polarity;
> + bool single_pwm;
Conceptually I'd prefer a `npwm` field here. That doesn't take more
space in memory and simplifies the logic a bit. (At the cost of having
to adapt all already existing meson_pwm_data instances, but that's fine
in my book.)
> };
>
> struct meson_pwm {
> @@ -503,6 +504,18 @@ static void meson_pwm_s4_put_clk(void *data)
> clk_put(clk);
> }
>
> +static int meson_pwm_init_channels_s7(struct pwm_chip *chip)
> +{
> + struct device *dev = pwmchip_parent(chip);
> + struct meson_pwm *meson = to_meson_pwm(chip);
> +
> + meson->channels[0].clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(meson->channels[0].clk))
> + return dev_err_probe(dev, PTR_ERR(meson->channels[0].clk),
> + "Failed to get clk\n");
> + return 0;
> +}
> +
> static int meson_pwm_init_channels_s4(struct pwm_chip *chip)
> {
> struct device *dev = pwmchip_parent(chip);
> @@ -592,6 +605,13 @@ static const struct meson_pwm_data pwm_s4_data = {
> .has_polarity = true,
> };
>
> +static const struct meson_pwm_data pwm_s7_data = {
> + .channels_init = meson_pwm_init_channels_s7,
> + .has_constant = true,
> + .has_polarity = true,
> + .single_pwm = true,
> +};
> +
> static const struct of_device_id meson_pwm_matches[] = {
> {
> .compatible = "amlogic,meson8-pwm-v2",
> @@ -642,6 +662,10 @@ static const struct of_device_id meson_pwm_matches[] = {
> .compatible = "amlogic,meson-s4-pwm",
> .data = &pwm_s4_data
> },
> + {
> + .compatible = "amlogic,s7-pwm",
> + .data = &pwm_s7_data
> + },
> {},
If you touch that array in the next revision, please make this line:
{ }
(I.e. add a space and drop the comma.)
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] pinctrl: sunxi: Implement function_is_gpio
From: Paul Kocialkowski @ 2026-05-17 17:14 UTC (permalink / raw)
To: linux-gpio, linux-arm-kernel, linux-sunxi, linux-kernel
Cc: Andre Przywara, Linus Walleij, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Paul Kocialkowski
The function_is_gpio pinmux op allows the core to find out whether a
GPIO can be safely requested from a pinctrl property and requested as a
GPIO at the same time.
This is especially useful to request a GPIO with a particular drive
strength, which would otherwise not be possible.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index d3042e0c9712..6162f2d86723 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -821,6 +821,17 @@ static int sunxi_pmx_get_func_groups(struct pinctrl_dev *pctldev,
return 0;
}
+static bool sunxi_pmx_function_is_gpio(struct pinctrl_dev *pctldev,
+ unsigned function)
+{
+ struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+
+ if (!strncmp(pctl->functions[function].name, "gpio", 4))
+ return true;
+
+ return false;
+}
+
static void sunxi_pmx_set(struct pinctrl_dev *pctldev,
unsigned pin,
u8 config)
@@ -952,6 +963,7 @@ static const struct pinmux_ops sunxi_pmx_ops = {
.get_functions_count = sunxi_pmx_get_funcs_cnt,
.get_function_name = sunxi_pmx_get_func_name,
.get_function_groups = sunxi_pmx_get_func_groups,
+ .function_is_gpio = sunxi_pmx_function_is_gpio,
.set_mux = sunxi_pmx_set_mux,
.gpio_set_direction = sunxi_pmx_gpio_set_direction,
.request = sunxi_pmx_request,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 03/11] m68k: mcf5441x: setup DAC clock name as per driver name
From: Angelo Dureghello @ 2026-05-17 17:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Angelo Dureghello, Steven King, Greg Ungerer, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Greg Ungerer,
linux-m68k, linux-kernel, linux-stm32, linux-arm-kernel,
linux-iio
In-Reply-To: <CAMuHMdUMvoODD4huxqPb+Hj6Rdid1cSgvzuJdqvg_hRzviyFuA@mail.gmail.com>
Hi,
On Sun, May 17, 2026 at 01:45:44PM +0200, Geert Uytterhoeven wrote:
> Hi Angelo,
>
> There's something wrong with "Mail-Followup-To:", which lists everyone,
> except for you...
>
> On Sun, 17 May 2026 at 11:11, Angelo Dureghello
> <adureghello@baylibre.com> wrote:
> > jfyi, for some reason i was not in to/cc, but i could grab the message
> > in lore.
>
> Might be related...
>
yes, imported the raw msg from lore but was not allowed to send from
lieer, so i removed In-Reply-To:, anyway, thread seems back ok now.
> > On Thu, May 14, 2026 at 10:54:32PM +1000, Greg Ungerer wrote:
> > > On 14/5/26 17:05, Angelo Dureghello wrote:
> > > > On 14.05.2026 11:27, Greg Ungerer wrote:
> > > > > On 13/5/26 19:14, Angelo Dureghello wrote:
> > > > > > From: Angelo Dureghello <adureghello@baylibre.com>
> > > > > >
> > > > > > Later in this patchset, the mcf54415 DAC driver is added.
> > > > > > Considering some other different ColdFire cpu DACs exists, the DAC driver
> > > > > > is named as "mcf54415_dac", related to the mcf5441x family SoCs with
> > > > > > DACs (mcf54415/6/7/8).
> > > > > >
> > > > > > So updating DAC clock names to bind with proper driver name.
> > > > >
> > > > > I am not sure I like naming the clocks here with a prefix for the
> > > > > specific SoC part number this is in. It might be unlikely now, but
> > > > > what if another ColdFire family SoC member uses this same hardware block?
> > > > > That is very common amongst other hardware blocks within the ColdFire
> > > > > family. Can we come up with a name more specific to just this type
> > > > > of DAC hardware block?
> > > > >
> > > >
> > > > from a brief study, this 12bit DAC, and DAC module in general, is only on
> > > > this mcf45441x family. There are some ColdFire with ADC only, as those
> > > > mcf5249/53/82.
> > > > The mcf51mm/ag/je are the opnly to have a 5bit dacs, but these are mcus.
> > > > So, if i don't miss any existing model, the name may be correct,
> > > > unless we want rename it to a more generic mcf_dac.
> > >
> > > Yes, I would suggest just leaving it as is, "mcfdac".
> > > That is not currently used by any other ColdFire variants supported by
> > > the kernel.
> > >
> >
> > Ok, will fix this in a v3, just asking confirmation on the name to
> > Jonathan and all, since it involves iio too.
> >
> > Chaches are:
> > mcfdac
> > mcf-dac or mcf_dac (we have drivers as vf610_dac and cio-dac)
>
> The clock names in arch/m68k/coldfire/m5441x.c are the names as
> specified by the producer side, not by the consumer side.
yes sorry, i confused DEFINE_CLK with CLKDEV_INIT where the driver name
must be set.
So sure, thanks, fixing clock names back as mcfdac in v3.
>
> > > > > > --- a/arch/m68k/coldfire/m5441x.c
> > > > > > +++ b/arch/m68k/coldfire/m5441x.c
> > > > > > @@ -43,8 +43,8 @@ DEFINE_CLK(0, "mcfpit.2", 34, MCF_BUSCLK);
> > > > > > DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
> > > > > > 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, "mcfdac.1", 39, MCF_CLK);
> > > > > > +DEFINE_CLK(0, "mcf54415_dac.0", 38, MCF_CLK);
> > > > > > +DEFINE_CLK(0, "mcf54415_dac.1", 39, 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);
> > > > > > @@ -106,8 +106,8 @@ static struct clk_lookup m5411x_clk_lookup[] = {
> > > > > > CLKDEV_INIT("mcfpit.3", NULL, &__clk_0_35),
> > > > > > 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("mcfdac.1", NULL, &__clk_0_39),
> > > > > > + CLKDEV_INIT("mcf54415_dac.0", NULL, &__clk_0_38),
> > > > > > + CLKDEV_INIT("mcf54415_dac.1", NULL, &__clk_0_39),
> > > > > > 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),
>
> Gr{oetje,eeting}s,
>
> Geert
>
Regards,
angelo
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 4/7] perf unwind-libunwind: Make libunwind register reading cross platform
From: Ian Rogers @ 2026-05-17 17:23 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: adrian.hunter, dapeng1.mi, james.clark, namhyung,
Florian Fainelli, Li Guan, 9erthalion6, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, howardchu95, john.g.garry, jolsa,
leo.yan, libunwind-devel, linux-arm-kernel, linux-kernel,
linux-perf-users, linux-riscv, mingo, palmer, peterz, pjw,
shimin.guo, tglozar, tmricht, will
In-Reply-To: <ageGsOVhDDKnvQhQ@x1>
On Fri, May 15, 2026 at 1:48 PM Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
>
> On Fri, May 15, 2026 at 12:38:48PM -0700, Ian Rogers wrote:
> > On Fri, May 15, 2026 at 12:23 PM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> > > +++ b/tools/perf/util/libunwind-arch/libunwind-ppc32.c
> > > @@ -23,6 +23,8 @@ int __get_perf_regnum_for_unw_regnum_ppc32(int unw_regnum __maybe_unused)
> > > return PERF_REG_POWERPC_CTR;
> > > case UNW_PPC32_XER:
> > > return PERF_REG_POWERPC_XER;
> > > + case UNW_PPC32_NIP:
> > > + return PERF_REG_POWERPC_NIP;
> > > default:
> > > pr_err("unwind: invalid reg id %d\n", unw_regnum);
> > > return -EINVAL;
> > > ⬢ [acme@toolbx perf-tools-next]$
>
> > > Ok? It was the only issue found in this patch.
>
> > Looks good, the NIP is in the original code that I copied, so I don't
> > understand how I lost this, but good catch!
>
> What I have is in tmp.perf-tools-next, doing a container build now,
> still need to look at the other findings, but they seems either trivial
> or complaints about making the build time more inneficient by not
> caching some feature tests, so I think I'll fix the trivial like I did
> in the above case (posting diffs to the list) and leave the build time
> for later so that we make progress.
>
> Will try to do this later today so that I publish it to perf-tools-next
> for it to soak a bit in linux-next.
This is great! Thank you Arnaldo!
Ian
> - Arnaldo
^ permalink raw reply
* Re: [PATCH v2] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Sudeep Holla @ 2026-05-17 17:28 UTC (permalink / raw)
To: Jamie Nguyen; +Cc: linux-arm-kernel, linux-kernel, Sudeep Holla
In-Reply-To: <20260515174432.13419-1-jamien@nvidia.com>
On Fri, May 15, 2026 at 10:44:32AM -0700, Jamie Nguyen wrote:
> __ffa_partition_info_get_regs() walks the response with a hardcoded
> 24-byte stride (regs += 3) even though the SPMC tells us the actual
> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
> read into buf_sz and then thrown away.
>
> That works while every SPMC returns the FF-A v1.1 layout, but it falls
> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
> strides over half a descriptor at a time and ends up parsing every
> other entry from a slice of two adjacent ones.
>
> The FF-A spec (v1.2, section 18.5) says that the producer should
> report the descriptor size, and the consumer is supposed to stride by
> that size and ignore any trailing fields it doesn't understand. The
> non-REGS path (__ffa_partition_info_get) does this already, and the
> REGS path should match.
>
> Use buf_sz for the stride, and bail out with -EINVAL if the SPMC
> reports something we can't safely walk.
>
> Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS")
> Signed-off-by: Jamie Nguyen <jamien@nvidia.com>
> ---
> Changes in v2:
> - Rebase onto linux-next; reuse the
> FFA_PART_INFO_GET_REGS_{REGS_PER_DESC,MAX_DESC} macros it added instead of
> introducing new ones.
> - Return -EINVAL instead of -EPROTO to match surrounding checks.
> - Update Fixes: tag to the commit that introduced the hardcoded stride.
> ---
> drivers/firmware/arm_ffa/driver.c | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> index b9f17fda7243..38ae4476e864 100644
> --- a/drivers/firmware/arm_ffa/driver.c
> +++ b/drivers/firmware/arm_ffa/driver.c
> @@ -374,9 +374,23 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
> return -EINVAL;
>
> tag = UUID_INFO_TAG(partition_info.a2);
> +
> + /*
> + * Per FF-A v1.2 section 18.5 the SPMC reports the per-
> + * descriptor size and consumers must stride by that size,
> + * reading only the fields they understand and ignoring any
> + * trailing ones. Reject sizes that cannot hold the v1.1
> + * fields parsed below, are not u64-aligned, or whose total
> + * payload would walk past the x3..x17 window (e.g. a v1.3
> + * 48-byte descriptor with nr_desc > 2).
> + */
I am not sure if this above note is necessary.
> buf_sz = PARTITION_INFO_SZ(partition_info.a2);
> - if (buf_sz > sizeof(*buffer))
> - buf_sz = sizeof(*buffer);
> + if (buf_sz < FFA_PART_INFO_GET_REGS_REGS_PER_DESC * sizeof(u64) ||
> + buf_sz % sizeof(u64) ||
> + nr_desc * (buf_sz / sizeof(u64)) >
> + FFA_PART_INFO_GET_REGS_MAX_DESC *
> + FFA_PART_INFO_GET_REGS_REGS_PER_DESC)
> + return -EINVAL;
>
The logic above is correct but bit hard to read, I am thinking of splitting
this
> regs = (void *)&partition_info.a3;
> for (idx = 0; idx < nr_desc; idx++, buf++) {
> @@ -395,7 +409,7 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
> buf->exec_ctxt = PART_INFO_EXEC_CXT(val);
> buf->properties = PART_INFO_PROPERTIES(val);
> uuid_copy(&buf->uuid, &uuid_regs.uuid);
> - regs += 3;
> + regs += buf_sz / sizeof(u64);
> }
> start_idx = cur_idx + 1;
Is it OK if I adjust something like below patch ?
Regards,
Sudeep
-->8
diff --git c/drivers/firmware/arm_ffa/driver.c w/drivers/firmware/arm_ffa/driver.c
index fb97b01c282a..54984e1b9741 100644
--- c/drivers/firmware/arm_ffa/driver.c
+++ w/drivers/firmware/arm_ffa/driver.c
@@ -329,11 +329,9 @@ __ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
#define PART_INFO_EXEC_CXT_MASK GENMASK(31, 16)
#define PART_INFO_PROPS_MASK GENMASK(63, 32)
#define FFA_PART_INFO_GET_REGS_FIRST_REG 3
-#define FFA_PART_INFO_GET_REGS_REGS_PER_DESC 3
-#define FFA_PART_INFO_GET_REGS_MAX_DESC \
- (((sizeof(ffa_value_t) / sizeof_field(ffa_value_t, a0)) - \
- FFA_PART_INFO_GET_REGS_FIRST_REG) / \
- FFA_PART_INFO_GET_REGS_REGS_PER_DESC)
+#define FFA_PART_INFO_GET_REGS_MIN_REGS_PER_DESC 3
+#define FFA_PART_INFO_GET_REGS_NUM_REGS \
+ (sizeof(ffa_value_t) / sizeof_field(ffa_value_t, a0))
#define PART_INFO_ID(x) ((u16)(FIELD_GET(PART_INFO_ID_MASK, (x))))
#define PART_INFO_EXEC_CXT(x) ((u16)(FIELD_GET(PART_INFO_EXEC_CXT_MASK, (x))))
#define PART_INFO_PROPERTIES(x) ((u32)(FIELD_GET(PART_INFO_PROPS_MASK, (x))))
@@ -347,7 +345,7 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
do {
__le64 *regs;
- int idx, nr_desc, buf_idx;
+ int idx, nr_desc, buf_idx, regs_per_desc, max_desc;
invoke_ffa_fn((ffa_value_t){
.a0 = FFA_PARTITION_INFO_GET_REGS,
@@ -370,8 +368,18 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
if (cur_idx < start_idx || cur_idx >= count)
return -EINVAL;
+ buf_sz = PARTITION_INFO_SZ(partition_info.a2);
+ if (buf_sz % sizeof(*regs))
+ return -EINVAL;
+
+ regs_per_desc = buf_sz / sizeof(*regs);
+ if (regs_per_desc < FFA_PART_INFO_GET_REGS_MIN_REGS_PER_DESC)
+ return -EINVAL;
+
nr_desc = cur_idx - start_idx + 1;
- if (nr_desc > FFA_PART_INFO_GET_REGS_MAX_DESC)
+ max_desc = (FFA_PART_INFO_GET_REGS_NUM_REGS -
+ FFA_PART_INFO_GET_REGS_FIRST_REG) / regs_per_desc;
+ if (nr_desc > max_desc)
return -EINVAL;
buf_idx = buf - buffer;
@@ -379,9 +387,6 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
return -EINVAL;
tag = UUID_INFO_TAG(partition_info.a2);
- buf_sz = PARTITION_INFO_SZ(partition_info.a2);
- if (buf_sz > sizeof(*buffer))
- buf_sz = sizeof(*buffer);
regs = (void *)&partition_info.a3;
for (idx = 0; idx < nr_desc; idx++, buf++) {
@@ -400,7 +405,7 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
buf->exec_ctxt = PART_INFO_EXEC_CXT(val);
buf->properties = PART_INFO_PROPERTIES(val);
uuid_copy(&buf->uuid, &uuid_regs.uuid);
- regs += 3;
+ regs += regs_per_desc;
}
start_idx = cur_idx + 1;
^ permalink raw reply related
* [PATCH] KVM: arm64: vgic-its: reject restored DTE with out-of-range num_eventid_bits
From: Michael Bommarito @ 2026-05-17 17:49 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon, linux-arm-kernel, kvmarm, linux-kernel
Userspace can trigger a host-side denial of service via
KVM_DEV_ARM_ITS_RESTORE_TABLES. A Device Table Entry whose Size
field encodes num_eventid_bits > VITS_TYPER_IDBITS reaches
scan_its_table() with a sign-extended ~18 EiB length, where the
loop holds the per-ITS mutex and never calls cond_resched(),
pinning a host CPU for a time linear in registered guest memslot
size. The accessor is any process that can open /dev/kvm and
create a VM. The same out-of-range value also disables a
subsequent live bounds check on EventID, as described below.
The MAPD command handler already rejects this case in the live
path:
if (valid && num_eventid_bits > VITS_TYPER_IDBITS)
return E_ITS_MAPD_ITTSIZE_OOR;
vgic_its_restore_dte() reconstructs num_eventid_bits from the DTE
Size field but does not apply the same cap, so userspace can
install device state that the live MAPD path is documented to
reject. The restored value is stored in dev->num_eventid_bits and
is then used by vgic_its_restore_itt():
size_t max_size = BIT_ULL(dev->num_eventid_bits) * ite_esz;
ret = scan_its_table(its, base, max_size, ite_esz, ...);
scan_its_table() takes the size as int and assigns it to
unsigned long in the callee:
static int scan_its_table(struct vgic_its *its, gpa_t base,
int size, u32 esz, ...)
{
unsigned long len = size;
For num_eventid_bits = 28 the size_t value 0x80000000 truncates to
INT_MIN as int and sign-extends to ~18 EiB as unsigned long. The
scan loop then walks the registered guest memslot one ite_esz at
a time with the per-ITS mutex held and no cond_resched(). In a
QEMU TCG arm64 guest at EL2 on v7.1-rc1, with an empty ITT, the
ioctl returned -EFAULT after about 14 seconds with a 256 MiB
memslot and about 56 seconds with a 1 GiB memslot (linear in
memslot size). The per-iteration cost on native arm64 KVM
hardware will differ; the loop shape, and so the linear scaling,
will not.
The same out-of-range num_eventid_bits also disables the live
vgic_its_check_event_id() bounds check, because event_id is u32
and BIT_ULL(32) is unreachable in that comparison, leaving
subsequent MAPI/MAPTI handling without an effective EventID cap.
Mirror the MAPD cap in vgic_its_restore_dte() before allocating
the device, so out-of-range restored DTEs are rejected with
-EINVAL up front rather than triggering the int-truncated scan or
installing a device whose num_eventid_bits silently disables the
live bounds check. Sizes within [1, VITS_TYPER_IDBITS] are
unaffected.
Fixes: 57a9a117154c ("KVM: arm64: vgic-its: Device table save/restore")
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
arch/arm64/kvm/vgic/vgic-its.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 2ea9f1c7ebcd0..a5dcf9a6a2854 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -2307,6 +2307,15 @@ static int vgic_its_restore_dte(struct vgic_its *its, u32 id,
/* dte entry is valid */
offset = (entry & KVM_ITS_DTE_NEXT_MASK) >> KVM_ITS_DTE_NEXT_SHIFT;
+ /*
+ * The MAPD command rejects this case; mirror the cap here so a
+ * restored DTE cannot install an out-of-range num_eventid_bits
+ * that vgic_its_restore_itt() would then convert into a
+ * sign-extended scan_its_table() length.
+ */
+ if (num_eventid_bits > VITS_TYPER_IDBITS)
+ return -EINVAL;
+
if (!vgic_its_check_id(its, baser, id, NULL))
return -EINVAL;
--
2.53.0
^ 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