* [PATCH v3 08/10] mailbox: imx: Move the RXDB part of the mailbox into the threaded handler
From: Sebastian Andrzej Siewior @ 2026-06-17 6:55 UTC (permalink / raw)
To: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel
Cc: Sebastian Andrzej Siewior, Bjorn Andersson, Clark Williams,
Fabio Estevam, Frank Li, Jassi Brar, Mathieu Poirier,
Pengutronix Kernel Team, Sascha Hauer, Steven Rostedt, Peng Fan
In-Reply-To: <20260617-imx_mbox_rproc-v3-0-77948112defc@linutronix.de>
Move RXDB callback handling into the threaded handler. This similar to
the RX side and since the imx_mu_dcfg::rxdb callback can return an error, the
interrupt is only enabled on success.
Move RXDB callback handling into the threaded handler.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/mailbox/imx-mailbox.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 1219c35b116e4..1bd434bdff87a 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -554,6 +554,11 @@ static irqreturn_t imx_mu_isr_th(int irq, void *p)
imx_mu_xcr_set_act(priv, cp, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
break;
+ case IMX_MU_TYPE_RXDB:
+ if (!priv->dcfg->rxdb(priv, cp))
+ imx_mu_xcr_set_act(priv, cp, IMX_MU_GIER, IMX_MU_xCR_GIEn(priv->dcfg->type, cp->idx));
+ break;
+
default:
dev_warn_ratelimited(priv->dev, "Unhandled channel type %d\n",
cp->type);
@@ -610,7 +615,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
ret = IRQ_WAKE_THREAD;
} else if ((val == IMX_MU_xSR_GIPn(priv->dcfg->type, cp->idx)) &&
(cp->type == IMX_MU_TYPE_RXDB)) {
- priv->dcfg->rxdb(priv, cp);
+ imx_mu_xcr_rmw(priv, IMX_MU_GIER, 0, IMX_MU_xCR_GIEn(priv->dcfg->type, cp->idx));
+ ret = IRQ_WAKE_THREAD;
} else {
dev_warn_ratelimited(priv->dev, "Not handled interrupt\n");
return IRQ_NONE;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 07/10] mailbox: imx: Move the RX part of the mailbox into the threaded handler
From: Sebastian Andrzej Siewior @ 2026-06-17 6:55 UTC (permalink / raw)
To: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel
Cc: Sebastian Andrzej Siewior, Bjorn Andersson, Clark Williams,
Fabio Estevam, Frank Li, Jassi Brar, Mathieu Poirier,
Pengutronix Kernel Team, Sascha Hauer, Steven Rostedt, Peng Fan
In-Reply-To: <20260617-imx_mbox_rproc-v3-0-77948112defc@linutronix.de>
Move RX callback handling into the threaded handler. This is similar to
the TX side except that we explicitly mask the source interrupt in the
primary handler and unmask it in the threaded handler again after
success. This was done automatically in the TX part.
The masking/ unmasking can be removed from imx_mu_specific_rx() since it
already happens in the primary/ threaded handler before invoking the
channel specific callback.
Move RX channel handling into threaded handler.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/mailbox/imx-mailbox.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 87acc43cb99c4..1219c35b116e4 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -381,7 +381,6 @@ static int imx_mu_specific_rx(struct imx_mu_priv *priv, struct imx_mu_con_priv *
data = (u32 *)priv->msg;
- imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
*data++ = imx_mu_read(priv, priv->dcfg->xRR);
if (priv->dcfg->type & IMX_MU_V2_S4) {
@@ -408,7 +407,6 @@ static int imx_mu_specific_rx(struct imx_mu_priv *priv, struct imx_mu_con_priv *
*data++ = imx_mu_read(priv, priv->dcfg->xRR + (i % num_rr) * 4);
}
- imx_mu_xcr_set_act(priv, cp, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
mbox_chan_received_data(cp->chan, (void *)priv->msg);
return 0;
@@ -551,6 +549,11 @@ static irqreturn_t imx_mu_isr_th(int irq, void *p)
mbox_chan_txdone(chan, 0);
break;
+ case IMX_MU_TYPE_RX:
+ if (!priv->dcfg->rx(priv, cp))
+ imx_mu_xcr_set_act(priv, cp, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
+ break;
+
default:
dev_warn_ratelimited(priv->dev, "Unhandled channel type %d\n",
cp->type);
@@ -603,7 +606,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
ret = IRQ_WAKE_THREAD;
} else if ((val == IMX_MU_xSR_RFn(priv->dcfg->type, cp->idx)) &&
(cp->type == IMX_MU_TYPE_RX)) {
- priv->dcfg->rx(priv, cp);
+ imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
+ ret = IRQ_WAKE_THREAD;
} else if ((val == IMX_MU_xSR_GIPn(priv->dcfg->type, cp->idx)) &&
(cp->type == IMX_MU_TYPE_RXDB)) {
priv->dcfg->rxdb(priv, cp);
--
2.53.0
^ permalink raw reply related
* [PATCH v3 05/10] mailbox: imx: Use channel index instead of zero in imx_mu_specific_rx()
From: Sebastian Andrzej Siewior @ 2026-06-17 6:55 UTC (permalink / raw)
To: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel
Cc: Sebastian Andrzej Siewior, Bjorn Andersson, Clark Williams,
Fabio Estevam, Frank Li, Jassi Brar, Mathieu Poirier,
Pengutronix Kernel Team, Sascha Hauer, Steven Rostedt, Peng Fan
In-Reply-To: <20260617-imx_mbox_rproc-v3-0-77948112defc@linutronix.de>
imx_mu_specific_rx() masks channel 0 and unmasks it again at the end of
the function. Given that at startup the channel index got unmasked it
should do the right job.
This here either unmasks the actual channel or another one but should
have no impact given that it reverses its doing at the end.
Peng Fan commented here:
| For specific rx channel, whether it is i.MX8 SCU or i.MX ELE, actually there is
| only 1 channel as of now, but it seems better to use cp->idx in case more
| channels in future.
Use the channel index instead of zero.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/mailbox/imx-mailbox.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index a8d4e970fb786..408cd083c64ee 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -381,7 +381,7 @@ static int imx_mu_specific_rx(struct imx_mu_priv *priv, struct imx_mu_con_priv *
data = (u32 *)priv->msg;
- imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, 0));
+ imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
*data++ = imx_mu_read(priv, priv->dcfg->xRR);
if (priv->dcfg->type & IMX_MU_V2_S4) {
@@ -408,7 +408,7 @@ static int imx_mu_specific_rx(struct imx_mu_priv *priv, struct imx_mu_con_priv *
*data++ = imx_mu_read(priv, priv->dcfg->xRR + (i % num_rr) * 4);
}
- imx_mu_xcr_set_act(priv, cp, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, 0));
+ imx_mu_xcr_set_act(priv, cp, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
mbox_chan_received_data(cp->chan, (void *)priv->msg);
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 03/10] mailbox: imx: Use devm_pm_runtime_enable()
From: Sebastian Andrzej Siewior @ 2026-06-17 6:55 UTC (permalink / raw)
To: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel
Cc: Sebastian Andrzej Siewior, Bjorn Andersson, Clark Williams,
Fabio Estevam, Frank Li, Jassi Brar, Mathieu Poirier,
Pengutronix Kernel Team, Sascha Hauer, Steven Rostedt, Peng Fan
In-Reply-To: <20260617-imx_mbox_rproc-v3-0-77948112defc@linutronix.de>
sashiko complained about early usage of the device while probe isn't
completed. This can be mitigated by delaying the pm_runtime_enable()
into the removal path instead doing it early. This ensures that in an
error case the device is removed (and imx_mu_shutdown()) before
pm_runtime_disable() so we don't have to do this manually.
For the order to work, lets move devm_mbox_controller_register() until
after the pm-runtime part. So the reverse order will be mbox-controller
removal followed by disabling pm runtime.
Use devm_pm_runtime_enable(), remove manual pm_runtime_disable()
invocations and move the pm_runtime handling in probe before
devm_mbox_controller_register().
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/mailbox/imx-mailbox.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index e261b382d5c90..516a05b64daa1 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -966,38 +966,36 @@ static int imx_mu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, priv);
- ret = devm_mbox_controller_register(dev, &priv->mbox);
- if (ret)
+ ret = devm_pm_runtime_enable(dev);
+ if (ret < 0)
goto disable_clk;
- of_platform_populate(dev->of_node, NULL, NULL, dev);
-
- pm_runtime_enable(dev);
-
ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
- goto disable_runtime_pm;
+ goto disable_clk;
ret = pm_runtime_put_sync(dev);
if (ret < 0)
- goto disable_runtime_pm;
+ goto disable_clk;
clk_disable_unprepare(priv->clk);
+ ret = devm_mbox_controller_register(dev, &priv->mbox);
+ if (ret)
+ goto err_out;
+
+ of_platform_populate(dev->of_node, NULL, NULL, dev);
+
return 0;
-disable_runtime_pm:
- pm_runtime_disable(dev);
disable_clk:
clk_disable_unprepare(priv->clk);
+err_out:
return ret;
}
static void imx_mu_remove(struct platform_device *pdev)
{
- struct imx_mu_priv *priv = platform_get_drvdata(pdev);
-
- pm_runtime_disable(priv->dev);
}
static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
--
2.53.0
^ permalink raw reply related
* [PATCH v3 10/10] remoteproc: imx_rproc: Invoke the callback directly
From: Sebastian Andrzej Siewior @ 2026-06-17 6:55 UTC (permalink / raw)
To: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel
Cc: Sebastian Andrzej Siewior, Bjorn Andersson, Clark Williams,
Fabio Estevam, Frank Li, Jassi Brar, Mathieu Poirier,
Pengutronix Kernel Team, Sascha Hauer, Steven Rostedt, Peng Fan
In-Reply-To: <20260617-imx_mbox_rproc-v3-0-77948112defc@linutronix.de>
The imx-mailbox driver moved the callback invocation into the threaded
IRQ handler. This means the callback is invoked in preemptible context
and there is no need to schedule the kworker for the
imx_rproc_notified_idr_cb() invocation.
This was tested with the rpmsg-tty driver on imx93.
Remove the workqueue handling and invoke the imx_rproc_notified_idr_cb()
callback directly.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/remoteproc/imx_rproc.c | 33 +--------------------------------
1 file changed, 1 insertion(+), 32 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 0dd80e688b0ea..c97bc1c401655 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -24,7 +24,6 @@
#include <linux/regmap.h>
#include <linux/remoteproc.h>
#include <linux/scmi_imx_protocol.h>
-#include <linux/workqueue.h>
#include "imx_rproc.h"
#include "remoteproc_internal.h"
@@ -115,8 +114,6 @@ struct imx_rproc {
struct mbox_client cl;
struct mbox_chan *tx_ch;
struct mbox_chan *rx_ch;
- struct work_struct rproc_work;
- struct workqueue_struct *workqueue;
void __iomem *rsc_table;
struct imx_sc_ipc *ipc_handle;
struct notifier_block rproc_nb;
@@ -835,21 +832,11 @@ static int imx_rproc_notified_idr_cb(int id, void *ptr, void *data)
return 0;
}
-static void imx_rproc_vq_work(struct work_struct *work)
-{
- struct imx_rproc *priv = container_of(work, struct imx_rproc,
- rproc_work);
- struct rproc *rproc = priv->rproc;
-
- idr_for_each(&rproc->notifyids, imx_rproc_notified_idr_cb, rproc);
-}
-
static void imx_rproc_rx_callback(struct mbox_client *cl, void *msg)
{
struct rproc *rproc = dev_get_drvdata(cl->dev);
- struct imx_rproc *priv = rproc->priv;
- queue_work(priv->workqueue, &priv->rproc_work);
+ idr_for_each(&rproc->notifyids, imx_rproc_notified_idr_cb, rproc);
}
static int imx_rproc_xtr_mbox_init(struct rproc *rproc, bool tx_block)
@@ -1214,13 +1201,6 @@ static int imx_rproc_sys_off_handler(struct sys_off_data *data)
return NOTIFY_DONE;
}
-static void imx_rproc_destroy_workqueue(void *data)
-{
- struct workqueue_struct *workqueue = data;
-
- destroy_workqueue(workqueue);
-}
-
static int imx_rproc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1249,17 +1229,6 @@ static int imx_rproc_probe(struct platform_device *pdev)
priv->ops = dcfg->ops;
dev_set_drvdata(dev, rproc);
- priv->workqueue = create_workqueue(dev_name(dev));
- if (!priv->workqueue) {
- dev_err(dev, "cannot create workqueue\n");
- return -ENOMEM;
- }
-
- ret = devm_add_action_or_reset(dev, imx_rproc_destroy_workqueue, priv->workqueue);
- if (ret)
- return dev_err_probe(dev, ret, "Failed to add devm destroy workqueue action\n");
-
- INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
ret = imx_rproc_xtr_mbox_init(rproc, true);
if (ret)
--
2.53.0
^ permalink raw reply related
* [PATCH v3 06/10] mailbox: imx: Start splitting the IRQ handler in primary and threaded handler
From: Sebastian Andrzej Siewior @ 2026-06-17 6:55 UTC (permalink / raw)
To: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel
Cc: Sebastian Andrzej Siewior, Bjorn Andersson, Clark Williams,
Fabio Estevam, Frank Li, Jassi Brar, Mathieu Poirier,
Pengutronix Kernel Team, Sascha Hauer, Steven Rostedt, Peng Fan
In-Reply-To: <20260617-imx_mbox_rproc-v3-0-77948112defc@linutronix.de>
Split the mailbox irq handling into a primary handler (imx_mu_isr()) and
a threaded handler (imx_mu_isr_th()). The primary handler masks the
interrupt event so the threaded handler can run without raising the
interrupt again.
The goal here is to invoke the mailbox core functions (such as
mbox_chan_received_data(), mbox_chan_txdone()) in preemptible context which is
made possible by using an threaded interrupt handler. This in turn means that
mailbox's client callbacks are invoked in preemptible context, too. This then
allows the mailbox client callback to skip an indirection via a workqueue if
it requries preemptible callback.
As a first step, prepare the logic and move TX handling part.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/mailbox/imx-mailbox.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 408cd083c64ee..87acc43cb99c4 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -540,11 +540,31 @@ static void imx_mu_txdb_work(struct work_struct *t)
mbox_chan_txdone(cp->chan, 0);
}
+static irqreturn_t imx_mu_isr_th(int irq, void *p)
+{
+ struct mbox_chan *chan = p;
+ struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
+ struct imx_mu_con_priv *cp = chan->con_priv;
+
+ switch (cp->type) {
+ case IMX_MU_TYPE_TX:
+ mbox_chan_txdone(chan, 0);
+ break;
+
+ default:
+ dev_warn_ratelimited(priv->dev, "Unhandled channel type %d\n",
+ cp->type);
+ return IRQ_NONE;
+ }
+ return IRQ_HANDLED;
+}
+
static irqreturn_t imx_mu_isr(int irq, void *p)
{
struct mbox_chan *chan = p;
struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
struct imx_mu_con_priv *cp = chan->con_priv;
+ irqreturn_t ret = IRQ_HANDLED;
u32 val, ctrl;
switch (cp->type) {
@@ -580,7 +600,7 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
if ((val == IMX_MU_xSR_TEn(priv->dcfg->type, cp->idx)) &&
(cp->type == IMX_MU_TYPE_TX)) {
imx_mu_xcr_rmw(priv, IMX_MU_TCR, 0, IMX_MU_xCR_TIEn(priv->dcfg->type, cp->idx));
- mbox_chan_txdone(chan, 0);
+ ret = IRQ_WAKE_THREAD;
} else if ((val == IMX_MU_xSR_RFn(priv->dcfg->type, cp->idx)) &&
(cp->type == IMX_MU_TYPE_RX)) {
priv->dcfg->rx(priv, cp);
@@ -595,7 +615,7 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
if (priv->suspend)
pm_system_wakeup();
- return IRQ_HANDLED;
+ return ret;
}
static int imx_mu_send_data(struct mbox_chan *chan, void *data)
@@ -630,7 +650,8 @@ static int imx_mu_startup(struct mbox_chan *chan)
if (!(priv->dcfg->type & IMX_MU_V2_IRQ))
irq_flag |= IRQF_SHARED;
- ret = request_irq(priv->irq[cp->type], imx_mu_isr, irq_flag, cp->irq_desc, chan);
+ ret = request_threaded_irq(priv->irq[cp->type], imx_mu_isr, imx_mu_isr_th,
+ irq_flag, cp->irq_desc, chan);
if (ret) {
dev_err(priv->dev, "Unable to acquire IRQ %d\n", priv->irq[cp->type]);
return ret;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 09/10] mailbox: imx: Don't force-thread the primary handler
From: Sebastian Andrzej Siewior @ 2026-06-17 6:55 UTC (permalink / raw)
To: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel
Cc: Sebastian Andrzej Siewior, Bjorn Andersson, Clark Williams,
Fabio Estevam, Frank Li, Jassi Brar, Mathieu Poirier,
Pengutronix Kernel Team, Sascha Hauer, Steven Rostedt, Peng Fan
In-Reply-To: <20260617-imx_mbox_rproc-v3-0-77948112defc@linutronix.de>
The primary interrupt handler (imx_mu_isr()) no longer invokes any
callbacks it only masks the interrupt source and returns. In a
forced-threaded environment the IRQ-core will force-thread the primary
handler which can be avoided.
The primary handler uses a spinlock_t to protect the RMW operation in
imx_mu_xcr_rmw() - nothing that may introduce long latencies.
The lock can be turned into a raw_spinlock_t and then the primary
handler can run in hardirq context even on PREEMPT_RT skipping one
thread.
Make struct imx_mu_priv::xcr_lock a raw_spinlock_t and skip
force-threading the primrary handler by marking it IRQF_NO_THREAD.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/mailbox/imx-mailbox.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 1bd434bdff87a..40bad2b3e4d19 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -87,7 +87,7 @@ struct imx_mu_priv {
struct device *dev;
void __iomem *base;
void *msg;
- spinlock_t xcr_lock; /* control register lock */
+ raw_spinlock_t xcr_lock; /* control register lock */
struct mbox_controller mbox;
struct mbox_chan mbox_chans[IMX_MU_CHANS];
@@ -207,15 +207,14 @@ static int imx_mu_rx_waiting_read(struct imx_mu_priv *priv, u32 *val, u32 idx)
static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, enum imx_mu_xcr type, u32 set, u32 clr)
{
- unsigned long flags;
u32 val;
- spin_lock_irqsave(&priv->xcr_lock, flags);
+ guard(raw_spinlock_irqsave)(&priv->xcr_lock);
+
val = imx_mu_read(priv, priv->dcfg->xCR[type]);
val &= ~clr;
val |= set;
imx_mu_write(priv, val, priv->dcfg->xCR[type]);
- spin_unlock_irqrestore(&priv->xcr_lock, flags);
return val;
}
@@ -223,31 +222,27 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, enum imx_mu_xcr type, u32 se
static void imx_mu_xcr_clr_shut(struct imx_mu_priv *priv, struct imx_mu_con_priv *cp,
enum imx_mu_xcr type, u32 clr)
{
- unsigned long flags;
u32 val;
- spin_lock_irqsave(&priv->xcr_lock, flags);
+ guard(raw_spinlock_irqsave)(&priv->xcr_lock);
cp->shutdown = true;
val = imx_mu_read(priv, priv->dcfg->xCR[type]);
val &= ~clr;
imx_mu_write(priv, val, priv->dcfg->xCR[type]);
- spin_unlock_irqrestore(&priv->xcr_lock, flags);
}
static void imx_mu_xcr_set_act(struct imx_mu_priv *priv, struct imx_mu_con_priv *cp,
enum imx_mu_xcr type, u32 set)
{
- unsigned long flags;
u32 val;
- spin_lock_irqsave(&priv->xcr_lock, flags);
+ guard(raw_spinlock_irqsave)(&priv->xcr_lock);
if (!cp->shutdown) {
val = imx_mu_read(priv, priv->dcfg->xCR[type]);
val |= set;
imx_mu_write(priv, val, priv->dcfg->xCR[type]);
}
- spin_unlock_irqrestore(&priv->xcr_lock, flags);
}
static int imx_mu_generic_tx(struct imx_mu_priv *priv,
@@ -640,7 +635,7 @@ static int imx_mu_startup(struct mbox_chan *chan)
{
struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
struct imx_mu_con_priv *cp = chan->con_priv;
- unsigned long irq_flag = 0;
+ unsigned long irq_flag = IRQF_NO_THREAD;
int ret;
pm_runtime_get_sync(priv->dev);
@@ -988,7 +983,7 @@ static int imx_mu_probe(struct platform_device *pdev)
goto disable_clk;
}
- spin_lock_init(&priv->xcr_lock);
+ raw_spin_lock_init(&priv->xcr_lock);
priv->mbox.dev = dev;
priv->mbox.ops = &imx_mu_ops;
--
2.53.0
^ permalink raw reply related
* [PATCH net] net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths
From: Wayen Yan @ 2026-06-17 5:48 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In mtk_ppe_init(), when accounting is enabled, the error paths for
dmam_alloc_coherent(mib) and devm_kzalloc(acct) failures return NULL
directly, bypassing the err_free_l2_flows label that destroys the
rhashtable initialized earlier.
While this leak only occurs during probe (not runtime) and the leaked
memory is minimal (an empty rhash table), fixing it ensures proper
error path cleanup consistency.
Fix by changing the two return NULL statements to goto err_free_l2_flows.
Fixes: 603ea5e7ffa7 ("net: ethernet: mtk_eth_soc: fix memory leak in error path")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/mediatek/mtk_ppe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
index 18279e2a70..8451dc3fd0 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
@@ -918,7 +918,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
mib = dmam_alloc_coherent(ppe->dev, MTK_PPE_ENTRIES * sizeof(*mib),
&ppe->mib_phys, GFP_KERNEL);
if (!mib)
- return NULL;
+ goto err_free_l2_flows;
ppe->mib_table = mib;
@@ -926,7 +926,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
GFP_KERNEL);
if (!acct)
- return NULL;
+ goto err_free_l2_flows;
ppe->acct_table = acct;
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net] net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths
From: Lorenzo Bianconi @ 2026-06-17 6:58 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178167550101.2217645.14579307712717502425@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
> In mtk_ppe_init(), when accounting is enabled, the error paths for
> dmam_alloc_coherent(mib) and devm_kzalloc(acct) failures return NULL
> directly, bypassing the err_free_l2_flows label that destroys the
> rhashtable initialized earlier.
>
> While this leak only occurs during probe (not runtime) and the leaked
> memory is minimal (an empty rhash table), fixing it ensures proper
> error path cleanup consistency.
>
> Fix by changing the two return NULL statements to goto err_free_l2_flows.
>
> Fixes: 603ea5e7ffa7 ("net: ethernet: mtk_eth_soc: fix memory leak in error path")
> Signed-off-by: Wayen Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/mediatek/mtk_ppe.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
> index 18279e2a70..8451dc3fd0 100644
> --- a/drivers/net/ethernet/mediatek/mtk_ppe.c
> +++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
> @@ -918,7 +918,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
> mib = dmam_alloc_coherent(ppe->dev, MTK_PPE_ENTRIES * sizeof(*mib),
> &ppe->mib_phys, GFP_KERNEL);
> if (!mib)
> - return NULL;
> + goto err_free_l2_flows;
>
> ppe->mib_table = mib;
>
> @@ -926,7 +926,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
> GFP_KERNEL);
>
> if (!acct)
> - return NULL;
> + goto err_free_l2_flows;
>
> ppe->acct_table = acct;
> }
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4] ASoC: dt-bindings: mtk-btcvsd-snd: Convert to DT Schema
From: Krzysztof Kozlowski @ 2026-06-17 7:00 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-sound, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260615185810.11804-1-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 08:57:50PM +0200, Luca Leonardo Scorcia wrote:
> Convert the mtk-btcvsd-snd.txt DT binding to DT Schema format.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> Changes in v4:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/2] clk: amlogic: Add A9 peripherals clock controller driver
From: Jian Hu @ 2026-06-17 7:02 UTC (permalink / raw)
To: Jerome Brunet
Cc: Jian Hu via B4 Relay, Neil Armstrong, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Xianwei Zhao, Kevin Hilman, Martin Blumenstingl, linux-amlogic,
linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1jpl1qdisp.fsf@starbuckisacylon.baylibre.com>
On 6/16/2026 3:51 PM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On mar. 16 juin 2026 at 14:12, Jian Hu <jian.hu@amlogic.com> wrote:
>
>
>>>> If you think splitting it further into separate helper macros would improve
>>>> readability.
>>> One clock per macro please. Hidding 2 declaration is recipe for
>>> disaster. For ex, here the first one is static, the 2nd is not
>>
>> I'll split it into separate helper macros so that each macro expands to a
>> single clock definition.
>>
>> They are defined as follows: (Excluding struct clk_regmap)
>>
>> #define A9_VCLK_GATE(_name, _reg, _bit, _parent) \
>> .data = &(struct clk_regmap_gate_data){ \
>> .offset = _reg, \
>> .bit_idx = _bit, \
>> }, \
>> .hw.init = &(struct clk_init_data) { \
>> .name = #_name "_en", \
>> .ops = &clk_regmap_gate_ops, \
>> .parent_hws = (const struct clk_hw *[]) { _parent }, \
>> .num_parents = 1, \
>> .flags = CLK_SET_RATE_PARENT, \
>> },
>>
>> #define A9_VCLK_DIV(_name, _reg, _div) \
>>
>> ....
>>
>> static struct clk_regmap a9_vclk_div2_en = {
>> A9_VCLK_GATE(vclk_div2, VID_CLK_CTRL, 1, &a9_vclk.hw),
>> };
>>
>>
>> static struct clk_regmap a9_vclk_div2 = {
>> A9_VCLK_DIV(vclk_div2, VID_CLK_CTRL, 2),
>> };
>>
>> My understanding is that you would prefer helper macros to cover only the
>> repeated initializer fields,
>> while keeping the actual clock declarations explicit.
> I do not have a definitive preference over this but I do want things to be
> consistent, at least within the driver, globaly whenever possible.
>
> Look at the other macros you have already defined in your driver and do
> the same thing, including the way you declare the variable. Apart from
> this, it seems fine.
Understood.
I'll align the new helper macros with the style already used in this driver.
>> If that's not what you had in mind, please let me know.
>>>> I can do that as well.
>>>>
> --
> Jerome
--
Jian
^ permalink raw reply
* Re: [PATCH 3/9] firmware: imx: ele: Add API functions for OCOTP fuse access
From: Frieder Schrempf @ 2026-06-17 6:54 UTC (permalink / raw)
To: Frank Li, Pankaj Gupta, Peng Fan (OSS)
Cc: Frieder Schrempf, Srinivas Kandagatla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <ajGsiglUUbDTIxTh@SMW015318>
On 16.06.26 22:05, Frank Li wrote:
> On Tue, Jun 16, 2026 at 07:59:54PM +0200, Frieder Schrempf wrote:
>> On 16.06.26 17:36, Frank Li wrote:
>>> On Tue, Jun 16, 2026 at 01:52:18PM +0200, Frieder Schrempf wrote:
>>>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>>
>>>> The ELE S400 API provides read and write access to the OCOTP fuse
>>>> registers. This adds the necessary API functions imx_se_read_fuse()
>>>> and imx_se_write_fuse() to be used by other drivers such as the
>>>> OCOTP S400 NVMEM driver.
>>>>
>>>> This is ported from the downstream vendor kernel.
>>>>
>>>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>> ---
>>>> drivers/firmware/imx/ele_base_msg.c | 122 ++++++++++++++++++++++++++++++++++++
>>>> drivers/firmware/imx/ele_base_msg.h | 6 ++
>>>> include/linux/firmware/imx/se_api.h | 3 +
>>>> 3 files changed, 131 insertions(+)
>>>>
>>> ...
>>>> +++ b/include/linux/firmware/imx/se_api.h
>>>> @@ -11,4 +11,7 @@
>>>> #define SOC_ID_OF_IMX8ULP 0x084d
>>>> #define SOC_ID_OF_IMX93 0x9300
>>>>
>>>> +int imx_se_read_fuse(void *se_if_data, uint16_t fuse_id, u32 *value);
>>>> +int imx_se_write_fuse(void *se_if_data, uint16_t fuse_id, u32 value);
>>>> +
>>>
>>> This API should implement in fuse drivers. Other consume should use standard
>>> fuse API to get value. If put here, it may bypass fuse driver.
>>
>> The reason this is here, is the downstream implementation in linux-imx
>> and the current code organization.
>
> Downstream may not good enough, sometime, it is quick solution.
Ok, but the code structure and API design has been upstreamed like this
and the refactoring could have been done before, if downstream is known
to not be well organized.
>
>> I thought there is some good reason
>> to have shared functions and it looks like Pankaj structured it like
>> this so all API functions live in ele_base_msg.c and the internal
>> structs and defines in ele_base_msg.h and se_ctrl.h are not exposed to
>> other drivers.
>>
>> If I would move this into imx-ocotp-ele.c, then I would also need to
>> change how the code is organized and make the internal se_api functions
>> exposed to other drivers. I don't know if that is really a good idea.
>>
>> I get your point but it looks like this contradicts the intention of
>> having a clean API in the firmware driver.
>
> You can refer imx-ocotp-scu.c, structure should be similar, only difference
> is that lower transfer APIs.
Ok, this would mean that I expose the generic SE functions and structs
required for fuse handling. In practice, I would remove
imx_se_read_fuse() and imx_se_write_fuse() from se_api.h and instead add
the following:
struct se_msg_hdr { ... };
struct se_api_msg { ... };
struct se_if_priv;
se_fill_cmd_msg_hdr( ... );
se_msg_send_rcv( ... );
se_val_rsp_hdr_n_status( ... );
Then I would export the functions in ele_common.c and put the fuse
read/write functions in the NVMEM driver.
Is that what you want me to do?
Pankaj (and maybe Peng), do you have any comments on this?
Thanks!
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Lorenzo Bianconi @ 2026-06-17 7:10 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166704952.2212140.11002626760717132754@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]
> In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
> using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
>
> Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
> computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
> - channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
> - channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
> - channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
> - channel 3: clears bit 24..31 (channel 3 only) - correct by accident
>
> While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
> mask parameter, the loop still incorrectly clears queues within the
> same channel beyond queue 7.
>
> Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..a1eda13400 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2217,7 +2217,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
> struct airoha_gdm_port *port = netdev_priv(dev);
> int i;
>
> - for (i = 0; i < AIROHA_NUM_TX_RING; i++)
> + for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
> airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
> TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
Even if the current codebase supports just AIROHA_NUM_QOS_CHANNEL (4), the hw
exposes 32 hw QoS channels (AIROHA_NUM_TX_RING). Here we are just clearing the
configuration, so I guess the current implementation is correct.
Regards,
Lorenzo
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix off-by-one error in HTB rate-limit channel removal
From: Lorenzo Bianconi @ 2026-06-17 7:13 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166483303.2209640.10761097847073356089@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
> In airoha_tc_remove_htb_queue(), the rate-limit was being cleared
> using (queue + 1) instead of queue, causing:
> - The original channel rate-limit configuration to remain active
> - The next channel to be incorrectly disabled
> - Potential out-of-bounds access when queue == 3 (channel 4)
>
> The alloc path (airoha_tc_htb_alloc_leaf_queue) correctly uses
> channel (0..3), but the remove path incorrectly added 1.
>
> Fix by using queue directly to match the alloc and rollback paths.
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..02807b3967 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2805,7 +2805,7 @@ static void airoha_tc_remove_htb_queue(struct net_device *dev, int queue)
> struct airoha_gdm_port *port = netdev_priv(dev);
>
> netif_set_real_num_tx_queues(dev, dev->real_num_tx_queues - 1);
> - airoha_qdma_set_tx_rate_limit(dev, queue + 1, 0, 0);
> + airoha_qdma_set_tx_rate_limit(dev, queue, 0, 0);
> clear_bit(queue, port->qos_sq_bmap);
> }
Please hold on with this patch, I am aware of the bug and the fix is already in
my queue [0]. I am just waiting the net-next to be merged into net in order to
avoid merge conflicts.
Regards,
Lorenzo
[0] https://github.com/LorenzoBianconi/net-next/commits/airoha-qos-fixes-for-net/
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 0/4] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Jun Yan @ 2026-06-17 7:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
- Disable nfc node by default ahead of nand_rb0 pin addition.
- Add missing nand_rb0 pin to fix incomplete NAND pinctrl.
- Disable pcie_phy by default to suppress probe warning.
- Re-enable pcie_phy on S400 board to preserve PCIe functionality.
Changes in v2:
- Add patch to disable nfc node by default.
- Link to v1:
https://lore.kernel.org/all/20260529140605.1070764-1-jerrysteve1101@gmail.com/
Jun Yan (4):
arm64: dts: amlogic: meson-axg: Disable nfc node by default
arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to
nand_all_pins
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
arm64: dts: amlogic: meson-axg-s400: Enable pcie_phy
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 ++++-
2 files changed, 8 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/4] arm64: dts: amlogic: meson-axg: Disable nfc node by default
From: Jun Yan @ 2026-06-17 7:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617071604.635627-1-jerrysteve1101@gmail.com>
nand_rb0 and emmc_ds share one pad. Before enabling nand_rb0 for nfc,
disable nfc nodes by default to resolve pinctrl resource contention.
No mainline AXG boards enable nfc currently thus no extra DTS adjustments
are needed.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index f1f53fd98ae2..6457667d974e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1999,6 +1999,7 @@ nfc: nand-controller@7800 {
clocks = <&clkc CLKID_SD_EMMC_C>,
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "device";
+ status = "disabled";
};
usb2_phy1: phy@9020 {
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/4] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
From: Jun Yan @ 2026-06-17 7:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617071604.635627-1-jerrysteve1101@gmail.com>
The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy)
pin description, which is required for NAND controller operation.
Add it to the pinmux list.
Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 6457667d974e..8ca3ac09b306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -481,7 +481,8 @@ mux {
"nand_ale",
"nand_cle",
"nand_wen_clk",
- "nand_ren_wr";
+ "nand_ren_wr",
+ "nand_rb0";
function = "nand";
input-enable;
bias-pull-up;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: Jun Yan @ 2026-06-17 7:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617071604.635627-1-jerrysteve1101@gmail.com>
Set the pcie_phy node to "disabled" as it is not used on some boards
and should be enabled per-board when necessary.
This change suppresses the deferred probe warning:
platform ff644000.phy: deferred probe pending: (reason unknown)
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 8ca3ac09b306..5b8ef98f6d03 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -328,6 +328,7 @@ pcie_phy: phy@ff644000 {
phys = <&mipi_pcie_analog_dphy>;
phy-names = "analog";
#phy-cells = <0>;
+ status = "disabled";
};
pdm: audio-controller@ff632000 {
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: amlogic: meson-axg-s400: Enable pcie_phy
From: Jun Yan @ 2026-06-17 7:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617071604.635627-1-jerrysteve1101@gmail.com>
The meson-axg dtsi now disables pcie_phy by default, so enable it
for the s400 board to support PCIe functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 285c6ac1dd61..7ba249cc3d56 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -448,6 +448,10 @@ &pcieB {
status = "okay";
};
+&pcie_phy {
+ status = "okay";
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_x20_pins>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Geert Uytterhoeven @ 2026-06-17 7:09 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260617030008.154449-2-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Wed, 17 Jun 2026 at 05:00, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> or APB interface configured to 32 bit, it can therefore access only
> the first 4 GiB of physical address space. This information comes from
> R-Car V4H Interface Specification sheet, there is currently no technical
> update number assigned to this limitation. Further input from hardware
> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> limitation.
>
> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
> common for many ARM GICv3 implementations. Therefore, add an extra
> of_machine_is_compatible() check.
>
> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4901,6 +4901,18 @@ static bool __maybe_unused its_enable_rk3568002(void *data)
> return true;
> }
>
> +static bool __maybe_unused its_enable_renesas_gen4(void *data)
> +{
> + if (!of_machine_is_compatible("renesas,r8a779f0") &&
> + !of_machine_is_compatible("renesas,r8a779g0") &&
> + !of_machine_is_compatible("renesas,r8a779h0"))
of_machine_compatible_match() with an array of strings might generate
smaller code (I didn't check if 3 entries is enough to trip the balance).
> + return false;
> +
> + gfp_flags_quirk |= GFP_DMA32;
> +
> + return true;
> +}
> +
> static const struct gic_quirk its_quirks[] = {
> #ifdef CONFIG_CAVIUM_ERRATUM_22375
> {
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 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marc Zyngier @ 2026-06-17 7:24 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260617030008.154449-2-marek.vasut+renesas@mailbox.org>
On Wed, 17 Jun 2026 03:59:45 +0100,
Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>
> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> or APB interface configured to 32 bit, it can therefore access only
> the first 4 GiB of physical address space. This information comes from
> R-Car V4H Interface Specification sheet, there is currently no technical
> update number assigned to this limitation. Further input from hardware
> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> limitation.
>
> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
> common for many ARM GICv3 implementations. Therefore, add an extra
Not quite. It designates GIC600 unambiguously. It is just that GIC600
is integrated in zillions of SoCs, most of which don't have this
problem (the machine I'm typing this from has a GIC600 *and* 96GB of
RAM).
> of_machine_is_compatible() check.
>
> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
Is this relevant?
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> NOTE: This would not be possible without prior work from Shimoda-san
> https://lore.kernel.org/all/20240214052050.1966439-1-yoshihiro.shimoda.uh@renesas.com/
> ---
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> Documentation/arch/arm64/silicon-errata.rst | 1 +
> arch/arm64/Kconfig | 9 +++++++++
> drivers/irqchip/irq-gic-v3-its.c | 20 ++++++++++++++++++++
> 3 files changed, 30 insertions(+)
>
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 014aa1c215a16..b0c68b64f5ac2 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -352,6 +352,7 @@ stable kernels.
> +----------------+-----------------+-----------------+-----------------------------+
> | Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
> +----------------+-----------------+-----------------+-----------------------------+
> +| Renesas | S4/V4H/V4M | N/A | RENESAS_ERRATUM_GEN4GICITS1 |
> +----------------+-----------------+-----------------+-----------------------------+
> | Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 |
> +----------------+-----------------+-----------------+-----------------------------+
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b3afe0688919b..b9e17ce475e61 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1382,6 +1382,15 @@ config NVIDIA_CARMEL_CNP_ERRATUM
>
> If unsure, say Y.
>
> +config RENESAS_ERRATUM_GEN4GICITS1
> + bool "Renesas R-Car Gen4: GIC600 can not access physical addresses above 4 GiB"
> + default y
> + help
> + The Renesas R-Car Gen4 S4/V4H/V4M GIC600 SoC integrations have AXI
> + addressing limited to the first 32-bit of physical address space.
> +
> + If unsure, say Y.
> +
> config ROCKCHIP_ERRATUM_3568002
> bool "Rockchip 3568002: GIC600 can not access physical addresses higher than 4GB"
> default y
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index b57d81ad33a0a..ec3756f29cf1a 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4901,6 +4901,18 @@ static bool __maybe_unused its_enable_rk3568002(void *data)
> return true;
> }
>
> +static bool __maybe_unused its_enable_renesas_gen4(void *data)
> +{
> + if (!of_machine_is_compatible("renesas,r8a779f0") &&
> + !of_machine_is_compatible("renesas,r8a779g0") &&
> + !of_machine_is_compatible("renesas,r8a779h0"))
> + return false;
> +
> + gfp_flags_quirk |= GFP_DMA32;
> +
> + return true;
> +}
> +
> static const struct gic_quirk its_quirks[] = {
> #ifdef CONFIG_CAVIUM_ERRATUM_22375
> {
> @@ -4975,6 +4987,14 @@ static const struct gic_quirk its_quirks[] = {
> .mask = 0xffffffff,
> .init = its_enable_rk3568002,
> },
> +#endif
> +#ifdef CONFIG_RENESAS_ERRATUM_GEN4GICITS1
> + {
> + .desc = "ITS: Renesas R-Car Gen4 GIC600 32-bit limit",
> + .iidr = 0x0201743b,
> + .mask = 0xffffffff,
> + .init = its_enable_renesas_gen4,
> + },
> #endif
> {
> }
Honestly, that's a bit too much copy-paste for my taste. Just refactor
the erratum handling to be more generic, something like this:
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 291d7668cc8da..380c4758647d2 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -4894,10 +4894,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
return true;
}
-static bool __maybe_unused its_enable_rk3568002(void *data)
+static const char * const dma_impaired_platforms[] = {
+#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
+ "rockchip,rk3566",
+ "rockchip,rk3568",
+#endif
+ NULL,
+};
+
+static bool __maybe_unused its_enable_dma32(void *data)
{
- if (!of_machine_is_compatible("rockchip,rk3566") &&
- !of_machine_is_compatible("rockchip,rk3568"))
+ if (!of_machine_compatible_match(dma_impaired_platforms))
return false;
gfp_flags_quirk |= GFP_DMA32;
@@ -4972,14 +4979,12 @@ static const struct gic_quirk its_quirks[] = {
.property = "dma-noncoherent",
.init = its_set_non_coherent,
},
-#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
{
- .desc = "ITS: Rockchip erratum RK3568002",
+ .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
.iidr = 0x0201743b,
.mask = 0xffffffff,
- .init = its_enable_rk3568002,
+ .init = its_enable_dma32,
},
-#endif
{
}
};
Then add the two lines you need in a separate patch.
In the future, please provide a cover letter when you have more than a
single patch (git will happily generate one for you).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marc Zyngier @ 2026-06-17 7:28 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260617030008.154449-1-marek.vasut+renesas@mailbox.org>
On Wed, 17 Jun 2026 03:59:44 +0100,
Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>
> In case MSI are enabled, but DWC built-in iMSI-RX is not in use, the
> MSI are handled via GIC ITS. Configure all controller MSI registers
> fully.
>
> Set or clear MSI capability register MSICAP0 MSI enable MSIE bit and
> PCIe Interrupt Status 0 Enable register PCIEINTSTS0EN MSI interrupt
> enable MSI_CTRL_INT bit according to MSI enable state, set both bits
> if MSI are enabled, clear both bits if MSI are disabled.
>
> If MSI are disabled, or MSI are enabled and iMSI-RX is used, then
> deconfigure AXIINTCADDR and AXIINTCCONT to 0, which disables any
> pass through of MSI TLPs onto the AXI bus and then further into
> GIC ITS translation registers.
>
> If MSI are enabled and iMSI-RX is not used, the configure AXIINTCADDR
> with target address of GIC ITS translation registers, and configure
> AXIINTCCONT to enable MSI TLP pass through onto AXI bus and into the
> GIC ITS. This specific configuration allows handling of MSI via the
> GIC ITS instead of integrated iMSI-RX.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> NOTE: This would not be possible without prior work from Shimoda-san
> ---
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 53 +++++++++++++++++++--
> 1 file changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index 485cfa8bd9692..ba6e3bedd6d0a 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> @@ -31,6 +31,10 @@
> #define DEVICE_TYPE_RC BIT(4)
> #define BIFUR_MOD_SET_ON BIT(0)
>
> +/* MSI Capability */
> +#define MSICAP0 0x0050
> +#define MSICAP0_MSIE BIT(16)
> +
> /* PCIe Interrupt Status 0 */
> #define PCIEINTSTS0 0x0084
>
> @@ -55,6 +59,16 @@
> #define APP_HOLD_PHY_RST BIT(16)
> #define APP_LTSSM_ENABLE BIT(0)
>
> +/* INTC address */
> +#define AXIINTCADDR 0x0a00
> +/* GITS GIC ITS translation register */
> +#define AXIINTCADDR_VAL 0xf1050000
Wouldn't it be preferable to source the address from the device tree,
rather than hardcoding this?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: amlogic: meson-axg-s400: Enable pcie_phy
From: Neil Armstrong @ 2026-06-17 7:30 UTC (permalink / raw)
To: Jun Yan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260617071604.635627-5-jerrysteve1101@gmail.com>
On 6/17/26 09:15, Jun Yan wrote:
> The meson-axg dtsi now disables pcie_phy by default, so enable it
> for the s400 board to support PCIe functionality.
>
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 285c6ac1dd61..7ba249cc3d56 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -448,6 +448,10 @@ &pcieB {
> status = "okay";
> };
>
> +&pcie_phy {
> + status = "okay";
> +};
> +
> &pwm_ab {
> status = "okay";
> pinctrl-0 = <&pwm_a_x20_pins>;
Please squash this one with the previous patch
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v2] media: meson: vdec: fix use-after-free of decode work in stop/close path
From: Doruk Tan Ozturk @ 2026-06-17 7:41 UTC (permalink / raw)
To: neil.armstrong
Cc: mchehab, gregkh, hverkuil, jbrunet, martin.blumenstingl,
linux-media, linux-amlogic, linux-staging, linux-arm-kernel,
linux-kernel, Doruk Tan Ozturk
In-Reply-To: <20260616074952.93076-1-doruk@0sec.ai>
Please drop v1 and v2 -- both are wrong, and the sashiko review was right
about the deadlock.
The underlying bug is real: vdec_close() does kfree(sess) (and
v4l2_m2m_ctx_release() frees sess->m2m_ctx) without cancelling
sess->esparser_queue_work, whose worker dereferences sess->lock and
sess->m2m_ctx -> UAF if it is pending/running at teardown.
But cancelling on the streamoff/poweroff path can't work:
1) Deadlock. The worker takes sess->lock. For an m2m fh the ioctl core
takes m2m_ctx->q_lock (== sess->lock) for VIDIOC_STREAMOFF and holds it
across the handler, so vdec_stop_streaming() -> vdec_poweroff() already
runs under sess->lock; cancel_work_sync() there waits on a worker blocked
on that same lock.
2) Use-after-power-down. v2 also cancelled after vdec_ops->stop(), which
power-gates VDEC1 (__vdec_1_stop()), while the worker still reads a VDEC1
register (vdec_1_vififo_level() -> VLD_MEM_VIFIFO_LEVEL).
The only deadlock-free point I see is vdec_close() (the ->release fop, not
under sess->lock), cancelling before v4l2_m2m_ctx_release() -- but that
still leaves the threaded VDEC ISR (amvdec_dst_buf_done() ->
schedule_work()) able to re-arm the worker, and there are adjacent teardown
issues (esparser_isr() vs the dos_parser_clk disable;
vdec_decoder_cmd()/esparser_queue_eos() without sess->lock).
I don't have Meson hardware to validate a corrected fix. Is a
vdec_close()-only cancel (plus quiescing the VDEC IRQ outside sess->lock)
the direction you'd want, or would you rather take it given the HW testing
and the surrounding teardown concerns?
Doruk
^ permalink raw reply
* Re: [PATCH] i2c: stm32f7: truncate clock period instead of rounding it
From: Alain Volmat @ 2026-06-17 8:06 UTC (permalink / raw)
To: Guillermo Rodríguez
Cc: Pierre-Yves MORDRET, Andi Shyti, Maxime Coquelin,
Alexandre Torgue, M'boumba Cedric Madianga, Wolfram Sang,
Pierre-Yves MORDRET, linux-i2c, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260611104857.242153-1-guille.rodriguez@gmail.com>
Hi Guillermo,
make sense indeed. Thanks a lot for this patch.
On Thu, Jun 11, 2026 at 12:48:56PM +0200, Guillermo Rodríguez wrote:
> stm32f7_i2c_compute_timing() derives the I2C clock source period
> (i2cclk) with DIV_ROUND_CLOSEST, which may round it up. When the
> period is overestimated, all timings computed from it (SCLDEL,
> SDADEL, SCLL, SCLH) come out shorter on the wire than calculated,
> and the resulting bus rate can exceed the requested speed, violating
> the I2C specification minimums for tLOW and tHIGH.
>
> For example, with a 104.45 MHz clock source (e.g. PCLK1, the
> reset-default I2C clock source on STM32MP1), i2cclk is rounded from
> 9.574 ns up to 10 ns. Requesting a 400 kHz fast mode bus with
> 72/27 ns rise/fall times and no analog/digital filters then produces
> an actual bus rate of 415.6 kHz with tLOW = 1254 ns, violating both
> the 400 kHz maximum rate and the 1300 ns tLOW minimum of the
> specification.
>
> Truncate the period instead, so that it can only be underestimated.
> The error then falls on the safe side: the programmed timings come
> out slightly longer than computed and the bus runs marginally below
> the target rate (375.3 kHz in the example above) while meeting the
> specification.
>
> i2cbus is left rounded-to-closest: it is only used as the target of
> the clk_error comparison and is never multiplied into the programmed
> timings, so nearest rounding remains accurate there.
>
> Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guillermo Rodríguez <guille.rodriguez@gmail.com>
> ---
> drivers/i2c/busses/i2c-stm32f7.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
> index 53d9df70ebe4..6439620d6bed 100644
> --- a/drivers/i2c/busses/i2c-stm32f7.c
> +++ b/drivers/i2c/busses/i2c-stm32f7.c
> @@ -464,8 +464,13 @@ static int stm32f7_i2c_compute_timing(struct stm32f7_i2c_dev *i2c_dev,
> {
> struct stm32f7_i2c_spec *specs;
> u32 p_prev = STM32F7_PRESC_MAX;
> - u32 i2cclk = DIV_ROUND_CLOSEST(NSEC_PER_SEC,
> - setup->clock_src);
> + /*
> + * Truncate instead of rounding to closest: if the clock period is
> + * overestimated, the computed SCL timings will come out shorter on
> + * the wire, which can push the bus above the target rate and below
> + * the spec's tLOW/tHIGH minimums.
> + */
> + u32 i2cclk = NSEC_PER_SEC / setup->clock_src;
> u32 i2cbus = DIV_ROUND_CLOSEST(NSEC_PER_SEC,
> setup->speed_freq);
> u32 clk_error_prev = i2cbus;
> --
> 2.25.1
>
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
Regards,
Alain
^ 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