* [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 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
* 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] 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
* [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
* [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
* 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
* 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
* 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
* 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
* [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
* 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] 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] 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: 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 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
* 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: 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
* [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
* [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
* 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
* Re: [PATCH v4 00/15] SCMI Clock rates discovery rework
From: Sudeep Holla @ 2026-05-17 11:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, arm-scmi, linux-clk,
linux-renesas-soc, Cristian Marussi
Cc: Sudeep Holla, philip.radford, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
geert+renesas, kuninori.morimoto.gx, marek.vasut+renesas
In-Reply-To: <20260508153300.2224715-1-cristian.marussi@arm.com>
On Fri, 08 May 2026 16:32:45 +0100, Cristian Marussi wrote:
> it was a known limitation, in the SCMI Clock protocol support, the lack of
> dynamic allocation around per-clock rates discovery: fixed size statically
> per-clock rates arrays did not scale and was increasingly a waste of memory
> (see [1]).
>
> This series aim at solving this in successive steps:
>
> [...]
Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!
[01/15] clk: scmi: Fix clock rate rounding
https://git.kernel.org/sudeep.holla/c/d0c81a38d06d
[02/15] firmware: arm_scmi: Add clock determine_rate operation
https://git.kernel.org/sudeep.holla/c/ecde921eb460
[03/15] clk: scmi: Use new determine_rate clock operation
https://git.kernel.org/sudeep.holla/c/af86c99170b7
[04/15] firmware: arm_scmi: Simplify clock rates exposed interface
https://git.kernel.org/sudeep.holla/c/0d76f62613ca
[05/15] clk: scmi: Use new simplified per-clock rate properties
https://git.kernel.org/sudeep.holla/c/cdcd2fc94936
[06/15] firmware: arm_scmi: Drop unused clock rate interfaces
https://git.kernel.org/sudeep.holla/c/2e757f71a5ab
[07/15] firmware: arm_scmi: Make clock rates allocation dynamic
https://git.kernel.org/sudeep.holla/c/62ba967595e0
[08/15] firmware: arm_scmi: Harden clock parents discovery
https://git.kernel.org/sudeep.holla/c/bda40491e0ce
[09/15] firmware: arm_scmi: Refactor iterators internal allocation
https://git.kernel.org/sudeep.holla/c/e99ed7267263
[10/15] firmware: arm_scmi: Add bound iterators support
https://git.kernel.org/sudeep.holla/c/4848d07ea9fc
[11/15] firmware: arm_scmi: Fix bound iterators returning too many items
https://git.kernel.org/sudeep.holla/c/ae4a088f13de
[12/15] firmware: arm_scmi: Use proper iter_response_bound_cleanup() name
https://git.kernel.org/sudeep.holla/c/3065e26dac52
[13/15] firmware: arm_scmi: Use bound iterators to minimize discovered rates
https://git.kernel.org/sudeep.holla/c/26d04d592a47
[14/15] firmware: arm_scmi: Fix OOB in scmi_clock_describe_rates_get_lazy()
https://git.kernel.org/sudeep.holla/c/4a07036d6159
[15/15] firmware: arm_scmi: Introduce all_rates_get clock operation
https://git.kernel.org/sudeep.holla/c/d2488ff1a257
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2] spi: atmel: fix DMA channel and bounce buffer leaks
From: Felix Gu @ 2026-05-17 10:39 UTC (permalink / raw)
To: Ryan Wanner, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Radu Pirea, Richard Genoud, Wenyou Yang
Cc: linux-spi, linux-arm-kernel, linux-kernel, Mark Brown, Felix Gu
The original code set use_dma to false when dma_alloc_coherent() for
bounce buffers failed, but DMA channels acquired earlier via
atmel_spi_configure_dma() were never freed.
When devm_request_irq() or clk_prepare_enable() failed later in probe,
the driver also did not release DMA channels or bounce buffers already
allocated.
And in the following error path, the driver released DMA channels but
did not free the bounce buffers.
Fix by moving bounce buffer allocation into atmel_spi_configure_dma()
and switching both DMA channels and bounce buffers to their devm-
managed variants. Any allocation failure in the DMA configuration path
now correctly rolls back through devres cleanup, and thenow-unnecessary
atmel_spi_release_dma() function is removed.
Fixes: a9889ed62d06 ("spi: atmel: Implements transfers with bounce buffer")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
Changes in v2:
- Switch to devm-managed variants to fix Claudiu Beznea's comment.
- Link to v1: https://patch.msgid.link/20260516-atmel-v1-0-674fb4707af6@gmail.com
To: Ryan Wanner <ryan.wanner@microchip.com>
To: Mark Brown <broonie@kernel.org>
To: Nicolas Ferre <nicolas.ferre@microchip.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Claudiu Beznea <claudiu.beznea@tuxon.dev>
To: Radu Pirea <radu.pirea@microchip.com>
Cc: linux-spi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/spi/spi-atmel.c | 94 ++++++++++++++-----------------------------------
1 file changed, 27 insertions(+), 67 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 25aa294631c8..23022665c3a4 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -565,14 +565,15 @@ static int atmel_spi_configure_dma(struct spi_controller *host,
struct device *dev = &as->pdev->dev;
int err;
- host->dma_tx = dma_request_chan(dev, "tx");
+ host->dma_tx = devm_dma_request_chan(dev, "tx");
if (IS_ERR(host->dma_tx)) {
err = PTR_ERR(host->dma_tx);
dev_dbg(dev, "No TX DMA channel, DMA is disabled\n");
- goto error_clear;
+ host->dma_tx = NULL;
+ return err;
}
- host->dma_rx = dma_request_chan(dev, "rx");
+ host->dma_rx = devm_dma_request_chan(dev, "rx");
if (IS_ERR(host->dma_rx)) {
err = PTR_ERR(host->dma_rx);
/*
@@ -580,12 +581,27 @@ static int atmel_spi_configure_dma(struct spi_controller *host,
* requested tx channel.
*/
dev_dbg(dev, "No RX DMA channel, DMA is disabled\n");
- goto error;
+ host->dma_rx = NULL;
+ return err;
}
err = atmel_spi_dma_slave_config(as, 8);
if (err)
- goto error;
+ return err;
+
+ if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ as->addr_tx_bbuf = dmam_alloc_coherent(dev, SPI_MAX_DMA_XFER,
+ &as->dma_addr_tx_bbuf,
+ GFP_KERNEL | GFP_DMA);
+ if (!as->addr_tx_bbuf)
+ return -ENOMEM;
+
+ as->addr_rx_bbuf = dmam_alloc_coherent(dev, SPI_MAX_DMA_XFER,
+ &as->dma_addr_rx_bbuf,
+ GFP_KERNEL | GFP_DMA);
+ if (!as->addr_rx_bbuf)
+ return -ENOMEM;
+ }
dev_info(&as->pdev->dev,
"Using %s (tx) and %s (rx) for DMA transfers\n",
@@ -593,14 +609,7 @@ static int atmel_spi_configure_dma(struct spi_controller *host,
dma_chan_name(host->dma_rx));
return 0;
-error:
- if (!IS_ERR(host->dma_rx))
- dma_release_channel(host->dma_rx);
- if (!IS_ERR(host->dma_tx))
- dma_release_channel(host->dma_tx);
-error_clear:
- host->dma_tx = host->dma_rx = NULL;
- return err;
+
}
static void atmel_spi_stop_dma(struct spi_controller *host)
@@ -611,18 +620,6 @@ static void atmel_spi_stop_dma(struct spi_controller *host)
dmaengine_terminate_all(host->dma_tx);
}
-static void atmel_spi_release_dma(struct spi_controller *host)
-{
- if (host->dma_rx) {
- dma_release_channel(host->dma_rx);
- host->dma_rx = NULL;
- }
- if (host->dma_tx) {
- dma_release_channel(host->dma_tx);
- host->dma_tx = NULL;
- }
-}
-
/* This function is called by the DMA driver from tasklet context */
static void dma_callback(void *data)
{
@@ -1581,30 +1578,6 @@ static int atmel_spi_probe(struct platform_device *pdev)
as->use_pdc = true;
}
- if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
- as->addr_rx_bbuf = dma_alloc_coherent(&pdev->dev,
- SPI_MAX_DMA_XFER,
- &as->dma_addr_rx_bbuf,
- GFP_KERNEL | GFP_DMA);
- if (!as->addr_rx_bbuf) {
- as->use_dma = false;
- } else {
- as->addr_tx_bbuf = dma_alloc_coherent(&pdev->dev,
- SPI_MAX_DMA_XFER,
- &as->dma_addr_tx_bbuf,
- GFP_KERNEL | GFP_DMA);
- if (!as->addr_tx_bbuf) {
- as->use_dma = false;
- dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
- as->addr_rx_bbuf,
- as->dma_addr_rx_bbuf);
- }
- }
- if (!as->use_dma)
- dev_info(host->dev.parent,
- " can not allocate dma coherent memory\n");
- }
-
if (as->caps.has_dma_support && !as->use_dma)
dev_info(&pdev->dev, "Atmel SPI Controller using PIO only\n");
@@ -1652,7 +1625,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
ret = spi_register_controller(host);
if (ret)
- goto out_free_dma;
+ goto out_disable_rpm;
/* go! */
dev_info(&pdev->dev, "Atmel SPI Controller version 0x%x at 0x%08lx (irq %d)\n",
@@ -1661,16 +1634,13 @@ static int atmel_spi_probe(struct platform_device *pdev)
return 0;
-out_free_dma:
+out_disable_rpm:
pm_runtime_disable(&pdev->dev);
pm_runtime_set_suspended(&pdev->dev);
-
- if (as->use_dma)
- atmel_spi_release_dma(host);
-
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
- clk_disable_unprepare(as->gclk);
+ if (as->gclk)
+ clk_disable_unprepare(as->gclk);
out_disable_clk:
clk_disable_unprepare(clk);
@@ -1687,18 +1657,8 @@ static void atmel_spi_remove(struct platform_device *pdev)
spi_unregister_controller(host);
/* reset the hardware and block queue progress */
- if (as->use_dma) {
+ if (as->use_dma)
atmel_spi_stop_dma(host);
- atmel_spi_release_dma(host);
- if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
- dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
- as->addr_tx_bbuf,
- as->dma_addr_tx_bbuf);
- dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
- as->addr_rx_bbuf,
- as->dma_addr_rx_bbuf);
- }
- }
spin_lock_irq(&as->lock);
spi_writel(as, CR, SPI_BIT(SWRST));
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260516-atmel-6d6b0150eb7e
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-17 8:45 UTC (permalink / raw)
To: Matthew Wilcox, surenb
Cc: akpm, linux-mm, david, ljs, liam, vbabka, rppt, mhocko, jack,
pfalcato, wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1,
chrisl, kasong, shikemeng, nphamcs, bhe, youngjun.park,
linux-arm-kernel, linux-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <afTpoL3FklpQZNMM@casper.infradead.org>
On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:
> > > > 1. There is no deterministic latency for I/O completion. It depends on
> > > > both the hardware and the software stack (bio/request queues and the
> > > > block scheduler). Sometimes the latency is short; at other times it can
> > > > be quite long. In such cases, a high-priority thread performing operations
> > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait
> > > > for an unpredictable amount of time.
> > >
> > > But does that actually happen? I find it hard to believe that thread A
> > > unmaps a VMA while thread B is in the middle of taking a page fault in
> > > that same VMA. mprotect() and madvise() are more likely to happen, but
> > > it still seems really unlikely to me.
> >
> > It doesn’t have to involve unmapping or applying mprotect to
> > the entire VMA—just a portion of it is sufficient.
>
> Yes, but that still fails to answer "does this actually happen". How much
> performance is all this complexity in the page fault handler buying us?
> If you don't answer this question, I'm just going to go in and rip it
> all out.
>
Hi Matthew (and Lorenzo, Jan, and anyone else who may be
waiting for answers),
As promised during LSF/MM/BPF, we conducted thorough
testing on Android phones to determine whether performing
I/O in `filemap_fault()` can block `vma_start_write()`.
I wanted to give a quick update on this question.
Nanzhe at Xiaomi created tracing scripts and ran various
applications on Android devices with I/O performed under
the VMA lock in `filemap_fault()`. We found that:
1. There are very few cases where unmap() is blocked by
page faults. I assume this is due to buggy user code
or poor synchronization between reads and unmap().
So I assume it is not a problem.
2. We observed many cases where `vma_start_write()`
is blocked by page-fault I/O in some applications.
The blocking occurs in the `dup_mmap()` path during
fork().
With Suren's commit fb49c455323ff ("fork: lock VMAs of
the parent process when forking"), we now always hold
`vma_write_lock()` for each VMA. Note that the
`mmap_lock` write lock is also held, which could lead to
chained waiting if page-fault I/O is performed without
releasing the VMA lock.
My gut feeling is that Suren's commit may be overshooting,
so my rough idea is that we might want to do something like
the following (we haven't tested it yet and it might be
wrong):
diff --git a/mm/mmap.c b/mm/mmap.c
index 2311ae7c2ff4..5ddaf297f31a 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
*mm, struct mm_struct *oldmm)
for_each_vma(vmi, mpnt) {
struct file *file;
- retval = vma_start_write_killable(mpnt);
+ /*
+ * For anonymous or writable private VMAs, prevent
+ * concurrent CoW faults.
+ */
+ if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
+ (mpnt->vm_flags & VM_WRITE)))
+ retval = vma_start_write_killable(mpnt);
if (retval < 0)
goto loop_out;
if (mpnt->vm_flags & VM_DONTCOPY) {
Based on the above, we may want to re-check whether fork()
can be blocked by page faults. At the same time, if Suren,
you, or anyone else has any comments, please feel free to
share them.
Best Regards
Barry
^ permalink raw reply related
* Re: [DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte
From: Karel Balej @ 2026-05-17 8:14 UTC (permalink / raw)
To: Johannes Berg
Cc: Brian Norris, Francesco Dolcini, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Duje Mihanović, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Ulf Hansson, Frank Li, linux-wireless,
devicetree, linux-kernel, linux-arm-kernel, linux-mmc,
~postmarketos/upstreaming, phone-devel, Jeff Chen, Peng Fan,
david
In-Reply-To: <DI5L100Q1RKO.1A68EJIPWYSRC@matfyz.cz>
Johannes,
Karel Balej, 2026-04-29T12:55:23+02:00:
> Brian, what are the options here now? Would it be possible to make an
> exception and accept the patches without the firmware being in
> linux-firmware? This is an old device with no mainstream audience so I
> expect everyone who will want to use it will be able to supply the
> firmware themselves and it would be great to not have to keep the
> patches in a fork, especially when trying to build on top of them
> further (such as to fix the driver-firmware incompatibilities discussed
> in one of the patches of this series).
would you please let us know whether there is any chance an exception
could be made for this chip regarding the firmware or whether there is
any other way to upstream the support?
Thank you and best regards,
Karel
^ permalink raw reply
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