* [PATCH v2 07/11] ASoC: fsl_xcvr: Use guard() for spin locks
From: phucduc.bui @ 2026-06-15 9:38 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Shengjiu Wang,
Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen, Sascha Hauer,
Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev, bui duc phuc
In-Reply-To: <20260615093824.115751-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/fsl/fsl_xcvr.c | 29 ++++++++++++-----------------
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c
index 6677d3bf36ec..41d100500534 100644
--- a/sound/soc/fsl/fsl_xcvr.c
+++ b/sound/soc/fsl/fsl_xcvr.c
@@ -797,10 +797,9 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
{
struct fsl_xcvr *xcvr = snd_soc_dai_get_drvdata(dai);
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
- unsigned long lock_flags;
int ret = 0;
- spin_lock_irqsave(&xcvr->lock, lock_flags);
+ guard(spinlock_irqsave)(&xcvr->lock);
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -812,7 +811,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
FSL_XCVR_EXT_CTRL_DPTH_RESET(tx));
if (ret < 0) {
dev_err(dai->dev, "Failed to set DPATH RESET: %d\n", ret);
- goto release_lock;
+ return ret;
}
if (tx) {
@@ -824,7 +823,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
FSL_XCVR_ISR_CMDC_TX_EN);
if (ret < 0) {
dev_err(dai->dev, "err updating isr %d\n", ret);
- goto release_lock;
+ return ret;
}
fallthrough;
case FSL_XCVR_MODE_SPDIF:
@@ -833,7 +832,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
FSL_XCVR_TX_DPTH_CTRL_STRT_DATA_TX);
if (ret < 0) {
dev_err(dai->dev, "Failed to start DATA_TX: %d\n", ret);
- goto release_lock;
+ return ret;
}
break;
}
@@ -844,14 +843,14 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
FSL_XCVR_EXT_CTRL_DMA_DIS(tx), 0);
if (ret < 0) {
dev_err(dai->dev, "Failed to enable DMA: %d\n", ret);
- goto release_lock;
+ return ret;
}
ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_IER0,
FSL_XCVR_IRQ_EARC_ALL, FSL_XCVR_IRQ_EARC_ALL);
if (ret < 0) {
dev_err(dai->dev, "Error while setting IER0: %d\n", ret);
- goto release_lock;
+ return ret;
}
/* clear DPATH RESET */
@@ -860,7 +859,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
0);
if (ret < 0) {
dev_err(dai->dev, "Failed to clear DPATH RESET: %d\n", ret);
- goto release_lock;
+ return ret;
}
break;
@@ -873,14 +872,14 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
FSL_XCVR_EXT_CTRL_DMA_DIS(tx));
if (ret < 0) {
dev_err(dai->dev, "Failed to disable DMA: %d\n", ret);
- goto release_lock;
+ return ret;
}
ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_IER0,
FSL_XCVR_IRQ_EARC_ALL, 0);
if (ret < 0) {
dev_err(dai->dev, "Failed to clear IER0: %d\n", ret);
- goto release_lock;
+ return ret;
}
if (tx) {
@@ -891,7 +890,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
FSL_XCVR_TX_DPTH_CTRL_STRT_DATA_TX);
if (ret < 0) {
dev_err(dai->dev, "Failed to stop DATA_TX: %d\n", ret);
- goto release_lock;
+ return ret;
}
if (xcvr->soc_data->spdif_only)
break;
@@ -905,7 +904,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
if (ret < 0) {
dev_err(dai->dev,
"Err updating ISR %d\n", ret);
- goto release_lock;
+ return ret;
}
break;
}
@@ -916,8 +915,6 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
break;
}
-release_lock:
- spin_unlock_irqrestore(&xcvr->lock, lock_flags);
return ret;
}
@@ -1448,11 +1445,10 @@ static void reset_rx_work(struct work_struct *work)
{
struct fsl_xcvr *xcvr = container_of(work, struct fsl_xcvr, work_rst);
struct device *dev = &xcvr->pdev->dev;
- unsigned long lock_flags;
u32 ext_ctrl;
dev_dbg(dev, "reset rx path\n");
- spin_lock_irqsave(&xcvr->lock, lock_flags);
+ guard(spinlock_irqsave)(&xcvr->lock);
regmap_read(xcvr->regmap, FSL_XCVR_EXT_CTRL, &ext_ctrl);
if (!(ext_ctrl & FSL_XCVR_EXT_CTRL_DMA_RD_DIS)) {
@@ -1469,7 +1465,6 @@ static void reset_rx_work(struct work_struct *work)
FSL_XCVR_EXT_CTRL_RX_DPTH_RESET,
0);
}
- spin_unlock_irqrestore(&xcvr->lock, lock_flags);
}
static irqreturn_t irq0_isr(int irq, void *devid)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 06/11] ASoC: fsl_ssi: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-15 9:38 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Shengjiu Wang,
Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen, Sascha Hauer,
Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev, bui duc phuc
In-Reply-To: <20260615093824.115751-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/fsl/fsl_ssi.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index b2e1da1781ae..dc022976c982 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1218,13 +1218,13 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg,
if (reg > 0x7f)
return;
- mutex_lock(&fsl_ac97_data->ac97_reg_lock);
+ guard(mutex)(&fsl_ac97_data->ac97_reg_lock);
ret = clk_prepare_enable(fsl_ac97_data->clk);
if (ret) {
pr_err("ac97 write clk_prepare_enable failed: %d\n",
ret);
- goto ret_unlock;
+ return;
}
lreg = reg << 12;
@@ -1238,9 +1238,6 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg,
udelay(100);
clk_disable_unprepare(fsl_ac97_data->clk);
-
-ret_unlock:
- mutex_unlock(&fsl_ac97_data->ac97_reg_lock);
}
static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
@@ -1252,12 +1249,12 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
unsigned int lreg;
int ret;
- mutex_lock(&fsl_ac97_data->ac97_reg_lock);
+ guard(mutex)(&fsl_ac97_data->ac97_reg_lock);
ret = clk_prepare_enable(fsl_ac97_data->clk);
if (ret) {
pr_err("ac97 read clk_prepare_enable failed: %d\n", ret);
- goto ret_unlock;
+ return val;
}
lreg = (reg & 0x7f) << 12;
@@ -1272,8 +1269,6 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
clk_disable_unprepare(fsl_ac97_data->clk);
-ret_unlock:
- mutex_unlock(&fsl_ac97_data->ac97_reg_lock);
return val;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 05/11] ASoC: fsl_spdif: Use guard() for spin locks
From: phucduc.bui @ 2026-06-15 9:38 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Shengjiu Wang,
Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen, Sascha Hauer,
Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev, bui duc phuc
In-Reply-To: <20260615093824.115751-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/fsl/fsl_spdif.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 1b9be85b34c2..ad1206ed9882 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -853,17 +853,15 @@ static int fsl_spdif_subcode_get(struct snd_kcontrol *kcontrol,
struct snd_soc_dai *cpu_dai = snd_kcontrol_chip(kcontrol);
struct fsl_spdif_priv *spdif_priv = snd_soc_dai_get_drvdata(cpu_dai);
struct spdif_mixer_control *ctrl = &spdif_priv->fsl_spdif_control;
- unsigned long flags;
int ret = -EAGAIN;
- spin_lock_irqsave(&ctrl->ctl_lock, flags);
+ guard(spinlock_irqsave)(&ctrl->ctl_lock);
if (ctrl->ready_buf) {
int idx = (ctrl->ready_buf - 1) * SPDIF_UBITS_SIZE;
memcpy(&ucontrol->value.iec958.subcode[0],
&ctrl->subcode[idx], SPDIF_UBITS_SIZE);
ret = 0;
}
- spin_unlock_irqrestore(&ctrl->ctl_lock, flags);
return ret;
}
@@ -885,17 +883,15 @@ static int fsl_spdif_qget(struct snd_kcontrol *kcontrol,
struct snd_soc_dai *cpu_dai = snd_kcontrol_chip(kcontrol);
struct fsl_spdif_priv *spdif_priv = snd_soc_dai_get_drvdata(cpu_dai);
struct spdif_mixer_control *ctrl = &spdif_priv->fsl_spdif_control;
- unsigned long flags;
int ret = -EAGAIN;
- spin_lock_irqsave(&ctrl->ctl_lock, flags);
+ guard(spinlock_irqsave)(&ctrl->ctl_lock);
if (ctrl->ready_buf) {
int idx = (ctrl->ready_buf - 1) * SPDIF_QSUB_SIZE;
memcpy(&ucontrol->value.bytes.data[0],
&ctrl->qsub[idx], SPDIF_QSUB_SIZE);
ret = 0;
}
- spin_unlock_irqrestore(&ctrl->ctl_lock, flags);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 04/11] ASoC: fsl_esai: Use guard() for spin locks
From: phucduc.bui @ 2026-06-15 9:38 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Shengjiu Wang,
Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen, Sascha Hauer,
Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev, bui duc phuc
In-Reply-To: <20260615093824.115751-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/fsl/fsl_esai.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index cde0b0c6c1ef..4a530a6c33f0 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -709,10 +709,9 @@ static void fsl_esai_hw_reset(struct work_struct *work)
{
struct fsl_esai *esai_priv = container_of(work, struct fsl_esai, work);
bool tx = true, rx = false, enabled[2];
- unsigned long lock_flags;
u32 tfcr, rfcr;
- spin_lock_irqsave(&esai_priv->lock, lock_flags);
+ guard(spinlock_irqsave)(&esai_priv->lock);
/* Save the registers */
regmap_read(esai_priv->regmap, REG_ESAI_TFCR, &tfcr);
regmap_read(esai_priv->regmap, REG_ESAI_RFCR, &rfcr);
@@ -750,8 +749,6 @@ static void fsl_esai_hw_reset(struct work_struct *work)
fsl_esai_trigger_start(esai_priv, tx);
if (enabled[rx])
fsl_esai_trigger_start(esai_priv, rx);
-
- spin_unlock_irqrestore(&esai_priv->lock, lock_flags);
}
static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
@@ -759,7 +756,6 @@ static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
{
struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
- unsigned long lock_flags;
esai_priv->channels[tx] = substream->runtime->channels;
@@ -767,16 +763,14 @@ static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
- spin_lock_irqsave(&esai_priv->lock, lock_flags);
- fsl_esai_trigger_start(esai_priv, tx);
- spin_unlock_irqrestore(&esai_priv->lock, lock_flags);
+ scoped_guard(spinlock_irqsave, &esai_priv->lock)
+ fsl_esai_trigger_start(esai_priv, tx);
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
- spin_lock_irqsave(&esai_priv->lock, lock_flags);
- fsl_esai_trigger_stop(esai_priv, tx);
- spin_unlock_irqrestore(&esai_priv->lock, lock_flags);
+ scoped_guard(spinlock_irqsave, &esai_priv->lock)
+ fsl_esai_trigger_stop(esai_priv, tx);
break;
default:
return -EINVAL;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 03/11] ASoC: fsl_easrc: Use guard() for spin locks
From: phucduc.bui @ 2026-06-15 9:38 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Shengjiu Wang,
Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen, Sascha Hauer,
Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev, bui duc phuc
In-Reply-To: <20260615093824.115751-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/fsl/fsl_easrc.c | 36 ++++++++++--------------------------
1 file changed, 10 insertions(+), 26 deletions(-)
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index 114a6c0b6b73..edfd943197a0 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -1025,7 +1025,6 @@ static int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id)
struct fsl_easrc_ctx_priv *ctx_priv;
struct fsl_asrc_pair *ctx;
struct device *dev;
- unsigned long lock_flags;
int ret;
if (!easrc)
@@ -1053,9 +1052,8 @@ static int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id)
if (ret)
return ret;
- spin_lock_irqsave(&easrc->lock, lock_flags);
- ret = fsl_easrc_config_slot(easrc, ctx->index);
- spin_unlock_irqrestore(&easrc->lock, lock_flags);
+ scoped_guard(spinlock_irqsave, &easrc->lock)
+ ret = fsl_easrc_config_slot(easrc, ctx->index);
if (ret)
return ret;
@@ -1301,13 +1299,12 @@ static int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx)
enum asrc_pair_index index = ASRC_INVALID_PAIR;
struct fsl_asrc *easrc = ctx->asrc;
struct device *dev;
- unsigned long lock_flags;
int ret = 0;
int i;
dev = &easrc->pdev->dev;
- spin_lock_irqsave(&easrc->lock, lock_flags);
+ guard(spinlock_irqsave)(&easrc->lock);
for (i = ASRC_PAIR_A; i < EASRC_CTX_MAX_NUM; i++) {
if (easrc->pair[i])
@@ -1331,8 +1328,6 @@ static int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx)
easrc->channel_avail -= channels;
}
- spin_unlock_irqrestore(&easrc->lock, lock_flags);
-
return ret;
}
@@ -1343,7 +1338,6 @@ static int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx)
*/
static void fsl_easrc_release_context(struct fsl_asrc_pair *ctx)
{
- unsigned long lock_flags;
struct fsl_asrc *easrc;
if (!ctx)
@@ -1351,14 +1345,12 @@ static void fsl_easrc_release_context(struct fsl_asrc_pair *ctx)
easrc = ctx->asrc;
- spin_lock_irqsave(&easrc->lock, lock_flags);
+ guard(spinlock_irqsave)(&easrc->lock);
fsl_easrc_release_slot(easrc, ctx->index);
easrc->channel_avail += ctx->channels;
easrc->pair[ctx->index] = NULL;
-
- spin_unlock_irqrestore(&easrc->lock, lock_flags);
}
/*
@@ -2292,15 +2284,13 @@ static int fsl_easrc_runtime_suspend(struct device *dev)
{
struct fsl_asrc *easrc = dev_get_drvdata(dev);
struct fsl_easrc_priv *easrc_priv = easrc->private;
- unsigned long lock_flags;
regcache_cache_only(easrc->regmap, true);
clk_disable_unprepare(easrc->mem_clk);
- spin_lock_irqsave(&easrc->lock, lock_flags);
- easrc_priv->firmware_loaded = 0;
- spin_unlock_irqrestore(&easrc->lock, lock_flags);
+ scoped_guard(spinlock_irqsave, &easrc->lock)
+ easrc_priv->firmware_loaded = 0;
return 0;
}
@@ -2311,7 +2301,6 @@ static int fsl_easrc_runtime_resume(struct device *dev)
struct fsl_easrc_priv *easrc_priv = easrc->private;
struct fsl_easrc_ctx_priv *ctx_priv;
struct fsl_asrc_pair *ctx;
- unsigned long lock_flags;
int ret;
int i;
@@ -2323,13 +2312,11 @@ static int fsl_easrc_runtime_resume(struct device *dev)
regcache_mark_dirty(easrc->regmap);
regcache_sync(easrc->regmap);
- spin_lock_irqsave(&easrc->lock, lock_flags);
- if (easrc_priv->firmware_loaded) {
- spin_unlock_irqrestore(&easrc->lock, lock_flags);
- goto skip_load;
+ scoped_guard(spinlock_irqsave, &easrc->lock) {
+ if (easrc_priv->firmware_loaded)
+ return 0;
+ easrc_priv->firmware_loaded = 1;
}
- easrc_priv->firmware_loaded = 1;
- spin_unlock_irqrestore(&easrc->lock, lock_flags);
ret = fsl_easrc_get_firmware(easrc);
if (ret) {
@@ -2377,9 +2364,6 @@ static int fsl_easrc_runtime_resume(struct device *dev)
goto disable_mem_clk;
}
-skip_load:
- return 0;
-
disable_mem_clk:
clk_disable_unprepare(easrc->mem_clk);
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 02/11] ASoC: fsl_audmix: Use guard() for spin locks
From: phucduc.bui @ 2026-06-15 9:38 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Shengjiu Wang,
Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen, Sascha Hauer,
Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev, bui duc phuc
In-Reply-To: <20260615093824.115751-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/fsl/fsl_audmix.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c
index 40a3b7432174..066239c64037 100644
--- a/sound/soc/fsl/fsl_audmix.c
+++ b/sound/soc/fsl/fsl_audmix.c
@@ -280,7 +280,6 @@ static int fsl_audmix_dai_trigger(struct snd_pcm_substream *substream, int cmd,
struct snd_soc_dai *dai)
{
struct fsl_audmix *priv = snd_soc_dai_get_drvdata(dai);
- unsigned long lock_flags;
/* Capture stream shall not be handled */
if (substream->stream == SNDRV_PCM_STREAM_CAPTURE)
@@ -290,16 +289,14 @@ static int fsl_audmix_dai_trigger(struct snd_pcm_substream *substream, int cmd,
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
- spin_lock_irqsave(&priv->lock, lock_flags);
- priv->tdms |= BIT(dai->driver->id);
- spin_unlock_irqrestore(&priv->lock, lock_flags);
+ scoped_guard(spinlock_irqsave, &priv->lock)
+ priv->tdms |= BIT(dai->driver->id);
break;
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
- spin_lock_irqsave(&priv->lock, lock_flags);
- priv->tdms &= ~BIT(dai->driver->id);
- spin_unlock_irqrestore(&priv->lock, lock_flags);
+ scoped_guard(spinlock_irqsave, &priv->lock)
+ priv->tdms &= ~BIT(dai->driver->id);
break;
default:
return -EINVAL;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 01/11] ASoC: fsl_asrc: Use guard() for spin locks
From: phucduc.bui @ 2026-06-15 9:38 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Shengjiu Wang,
Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen, Sascha Hauer,
Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev, bui duc phuc
In-Reply-To: <20260615093824.115751-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/fsl/fsl_asrc.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 5fda9b647c70..0b28bcfa47fe 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -222,10 +222,9 @@ static int fsl_asrc_request_pair(int channels, struct fsl_asrc_pair *pair)
enum asrc_pair_index index = ASRC_INVALID_PAIR;
struct fsl_asrc *asrc = pair->asrc;
struct device *dev = &asrc->pdev->dev;
- unsigned long lock_flags;
int i, ret = 0;
- spin_lock_irqsave(&asrc->lock, lock_flags);
+ guard(spinlock_irqsave)(&asrc->lock);
for (i = ASRC_PAIR_A; i < ASRC_PAIR_MAX_NUM; i++) {
if (asrc->pair[i] != NULL)
@@ -250,8 +249,6 @@ static int fsl_asrc_request_pair(int channels, struct fsl_asrc_pair *pair)
pair->index = index;
}
- spin_unlock_irqrestore(&asrc->lock, lock_flags);
-
return ret;
}
@@ -265,19 +262,16 @@ static void fsl_asrc_release_pair(struct fsl_asrc_pair *pair)
{
struct fsl_asrc *asrc = pair->asrc;
enum asrc_pair_index index = pair->index;
- unsigned long lock_flags;
/* Make sure the pair is disabled */
regmap_update_bits(asrc->regmap, REG_ASRCTR,
ASRCTR_ASRCEi_MASK(index), 0);
- spin_lock_irqsave(&asrc->lock, lock_flags);
+ guard(spinlock_irqsave)(&asrc->lock);
asrc->channel_avail += pair->channels;
asrc->pair[index] = NULL;
pair->error = 0;
-
- spin_unlock_irqrestore(&asrc->lock, lock_flags);
}
/**
--
2.43.0
^ permalink raw reply related
* [PATCH v2 00/11] ASoC: fsl: Use guard() for mutex & spin locks
From: phucduc.bui @ 2026-06-15 9:38 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Shengjiu Wang,
Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen, Sascha Hauer,
Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Hi all,
This series converts mutex and spinlock handling in the FSL sound drivers
to use guard() helpers.
The changes are code cleanup only and should have no functional impact.
Compile tested only.
Changes in v2:
- mpc5200_psc_ac97: Fix scoped_guard() usage by replacing
scoped_guard(mutex_lock, ...) with scoped_guard(mutex, ...).
- Added compile testing for mpc5200_dma and mpc5200_psc_ac97,
which were not compile-tested in v1.
Best regards,
Phuc
bui duc phuc (11):
ASoC: fsl_asrc: Use guard() for spin locks
ASoC: fsl_audmix: Use guard() for spin locks
ASoC: fsl_easrc: Use guard() for spin locks
ASoC: fsl_esai: Use guard() for spin locks
ASoC: fsl_spdif: Use guard() for spin locks
ASoC: fsl_ssi: Use guard() for mutex locks
ASoC: fsl_xcvr: Use guard() for spin locks
ASoC: imx-audio-rpmsg: Use guard() for spin locks
ASoC: fsl_rpmsg: Use guard() for mutex & spin locks
ASoC: fsl: mpc5200_dma: Use guard() for spin locks
ASoC: fsl: mpc5200_psc_ac97: Use guard() for mutex locks
sound/soc/fsl/fsl_asrc.c | 10 +----
sound/soc/fsl/fsl_audmix.c | 11 ++---
sound/soc/fsl/fsl_easrc.c | 36 +++++------------
sound/soc/fsl/fsl_esai.c | 16 +++-----
sound/soc/fsl/fsl_spdif.c | 8 +---
sound/soc/fsl/fsl_ssi.c | 13 ++----
sound/soc/fsl/fsl_xcvr.c | 29 ++++++--------
sound/soc/fsl/imx-audio-rpmsg.c | 25 ++++++------
sound/soc/fsl/imx-pcm-rpmsg.c | 69 ++++++++++++++------------------
sound/soc/fsl/mpc5200_dma.c | 56 +++++++++++++-------------
sound/soc/fsl/mpc5200_psc_ac97.c | 34 ++++++----------
11 files changed, 121 insertions(+), 186 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH] soc: amlogic: meson-clk-measure: remove debugfs tree
From: Pengpeng Hou @ 2026-06-15 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Pengpeng Hou
meson_msr_probe() creates a debugfs tree with entries that reference
devm-managed measurement table entries and the driver's private regmap
state. The driver has no remove callback, so unbinding the device can
leave those debugfs entries behind after the private data is released.
Store the debugfs root and remove the subtree from a new remove callback.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/soc/amlogic/meson-clk-measure.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
index d862e30a244e..7ca43bcb622a 100644
--- a/drivers/soc/amlogic/meson-clk-measure.c
+++ b/drivers/soc/amlogic/meson-clk-measure.c
@@ -7,6 +7,7 @@
#include <linux/of_address.h>
#include <linux/platform_device.h>
#include <linux/bitfield.h>
+#include <linux/err.h>
#include <linux/seq_file.h>
#include <linux/debugfs.h>
#include <linux/regmap.h>
@@ -50,6 +51,7 @@ struct meson_msr_data {
struct meson_msr {
struct regmap *regmap;
struct meson_msr_data data;
+ struct dentry *debugfs_root;
};
#define CLK_MSR_ID(__id, __name) \
@@ -952,6 +954,7 @@ static int meson_msr_probe(struct platform_device *pdev)
sizeof(struct msr_reg_offset));
root = debugfs_create_dir("meson-clk-msr", NULL);
+ priv->debugfs_root = root;
clks = debugfs_create_dir("clks", root);
debugfs_create_file("measure_summary", 0444, root,
@@ -967,9 +970,19 @@ static int meson_msr_probe(struct platform_device *pdev)
&priv->data.msr_table[i], &clk_msr_fops);
}
+ platform_set_drvdata(pdev, priv);
+
return 0;
}
+static void meson_msr_remove(struct platform_device *pdev)
+{
+ struct meson_msr *priv = platform_get_drvdata(pdev);
+
+ if (!IS_ERR_OR_NULL(priv->debugfs_root))
+ debugfs_remove_recursive(priv->debugfs_root);
+}
+
static const struct msr_reg_offset msr_reg_offset = {
.duty_val = 0x0,
.freq_ctrl = 0x4,
@@ -1065,6 +1078,7 @@ MODULE_DEVICE_TABLE(of, meson_msr_match_table);
static struct platform_driver meson_msr_driver = {
.probe = meson_msr_probe,
+ .remove = meson_msr_remove,
.driver = {
.name = "meson_msr",
.of_match_table = meson_msr_match_table,
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] soc: ti: knav_qmss: remove debugfs file on teardown
From: Pengpeng Hou @ 2026-06-15 9:12 UTC (permalink / raw)
To: Nishanth Menon, Santosh Shilimkar, linux-kernel, linux-arm-kernel
Cc: Pengpeng Hou
knav_queue_probe() creates the global qmss debugfs file whose show
callback reads the global kdev state. knav_queue_remove() disables
runtime PM but leaves the debugfs file and ready state published.
Save the debugfs dentry, remove it during teardown, and clear the global
ready pointer state.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/soc/ti/knav_qmss_queue.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 86d7a9c9ae01..1cc2e4a90c0d 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -26,6 +26,7 @@
#include "knav_qmss.h"
static struct knav_device *kdev;
+static struct dentry *knav_queue_debugfs;
static DEFINE_MUTEX(knav_dev_lock);
#define knav_dev_lock_held() \
lockdep_is_held(&knav_dev_lock)
@@ -1857,8 +1858,9 @@ static int knav_queue_probe(struct platform_device *pdev)
goto err;
}
- debugfs_create_file("qmss", S_IFREG | S_IRUGO, NULL, NULL,
- &knav_queue_debug_fops);
+ knav_queue_debugfs = debugfs_create_file("qmss", 0444,
+ NULL, NULL,
+ &knav_queue_debug_fops);
device_ready = true;
return 0;
@@ -1873,9 +1875,14 @@ static int knav_queue_probe(struct platform_device *pdev)
static void knav_queue_remove(struct platform_device *pdev)
{
+ device_ready = false;
+ debugfs_remove(knav_queue_debugfs);
+ knav_queue_debugfs = NULL;
+
/* TODO: Free resources */
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ kdev = NULL;
}
static struct platform_driver keystone_qmss_driver = {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] soc: ti: knav_dma: remove debugfs file on teardown
From: Pengpeng Hou @ 2026-06-15 9:12 UTC (permalink / raw)
To: Nishanth Menon, Santosh Shilimkar, linux-kernel, linux-arm-kernel
Cc: Pengpeng Hou
knav_dma_probe() creates the global knav_dma debugfs file whose show
callback walks the global kdev list. knav_dma_remove() tears down the DMA
instances and runtime PM but leaves that debugfs file and global ready
state behind.
Save the debugfs dentry, remove it before destroying the DMA state, and
clear the global ready pointer state during remove.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/soc/ti/knav_dma.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index e5f5e3142fc4..9277c525ac21 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -125,6 +125,7 @@ struct knav_dma_chan {
ch->channel : ch->flow)
static struct knav_dma_pool_device *kdev;
+static struct dentry *knav_dma_debugfs;
static bool device_ready;
bool knav_dma_device_ready(void)
@@ -740,8 +741,9 @@ static int knav_dma_probe(struct platform_device *pdev)
goto err_put_sync;
}
- debugfs_create_file("knav_dma", S_IFREG | S_IRUGO, NULL, NULL,
- &knav_dma_debug_fops);
+ knav_dma_debugfs = debugfs_create_file("knav_dma", 0444,
+ NULL, NULL,
+ &knav_dma_debug_fops);
device_ready = true;
return ret;
@@ -758,6 +760,10 @@ static void knav_dma_remove(struct platform_device *pdev)
{
struct knav_dma_device *dma;
+ device_ready = false;
+ debugfs_remove(knav_dma_debugfs);
+ knav_dma_debugfs = NULL;
+
list_for_each_entry(dma, &kdev->list, list) {
if (atomic_dec_return(&dma->ref_count) == 0)
knav_dma_hw_destroy(dma);
@@ -765,6 +771,7 @@ static void knav_dma_remove(struct platform_device *pdev)
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ kdev = NULL;
}
static struct of_device_id of_match[] = {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] crypto: sun4i-ss: remove debugfs directory on teardown
From: Pengpeng Hou @ 2026-06-15 9:11 UTC (permalink / raw)
To: Corentin Labbe, Herbert Xu, David S. Miller, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, linux-crypto, linux-arm-kernel,
linux-sunxi, linux-kernel
Cc: Pengpeng Hou
sun4i_ss_probe() creates a debugfs directory and a stats file with struct
sun4i_ss_ctx as private data. The remove path unregisters the crypto
algorithms and tears down runtime PM but leaves the debugfs entries
published.
Remove the debugfs subtree before tearing down the driver state used by
the stats show callback.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
index 58a76e2ba64e..bcaddf1b83ca 100644
--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
@@ -512,6 +512,8 @@ static void sun4i_ss_remove(struct platform_device *pdev)
int i;
struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
+ debugfs_remove_recursive(ss->dbgfs_dir);
+
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
switch (ss_algs[i].type) {
case CRYPTO_ALG_TYPE_SKCIPHER:
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH 6/6] irqchip/gic-v3-its: some minor cleanups
From: Marc Zyngier @ 2026-06-15 9:14 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615032910.54735-7-shikemeng@huaweicloud.com>
On Mon, 15 Jun 2026 04:29:10 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> 1. Remove unneeded NULL check in itt_alloc_pool() as addr will always be
> NULL when we reach here.
> 2. Correct indentation in cpumask_pick_least_loaded()
> 3. Remove unneeded updation of range node when it is to be deleted in
> alloc_lpi_range().
> 4. Remove unneeded assignment to baser->psz which is already used
> as input inits_setup_baser()
Honestly, these changes, aside from (maybe) the last one, are pretty
pointless. I'm sure there are better things to waste your time on.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: stm32: lxa: change stdout-path baud rate from 9600 to 115200
From: David Laight @ 2026-06-15 9:00 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: Alexandre Torgue, Maxime Coquelin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Leonard Göhrs,
Marc Kleine-Budde, Alexandre Torgue, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel, kernel
In-Reply-To: <f0b7d0a0-9b75-4d63-bc1a-f0891c86b2b9@pengutronix.de>
On Mon, 15 Jun 2026 09:53:49 +0200
Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> Hello David,
>
> On 6/12/26 8:53 AM, David Laight wrote:
> > On Thu, 11 Jun 2026 22:33:18 +0200
> > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> >> Hi David,
> >>
> >> On 6/11/26 21:43, David Laight wrote:
> >>> On Thu, 11 Jun 2026 20:12:32 +0200
> >>> Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>>
> >>>> The LXA boards are the only STM32 boards that set stdout-path = &uart*
> >>>> instead of explicitly specifying a baud rate.
> >>>>
> >>>> This would mean the default of 9600 is used, but it goes unnoticed when
> >>>> booting normally as barebox fixes up a console= line that includes a
> >>>> baud rate.
> >>>>
> >>>> When EFI booting GRUB however, GRUB will not pass along the console=
> >>>> line and thus the board ends up with a 9600 baud Linux console,
> >>>> confusing users.
> >>>
> >>> Is it possible to determine the current baud rate (by reading the hardware
> >>> register) and default to that value.
> >>> Then if grub has initialised the uart the kernel will use the same
> >>> baud rate.
> >>
> >> I think so, yes. In addition to the register divider configuration, one
> >> would need the input clock rate as well, but that's not a problem.
> >>
> >> Do you know if any drivers already do this?
> >
> > I've seen it done somewhere, certainly x86, but possibly NetBSD.
> > That would have been preserving the baud rate set by the bios.
> > You don't want the baud rate changing half way through the boot sequence.
>
> I agree in general, but in this case here, the BIOS defaults to 115200:
That would certainly make 115200 a better default than 9600.
David
>
> https://github.com/linux-automation/meta-lxatac/blob/wrynose/meta-lxatac-bsp/recipes-bsp/barebox/files/lxatac/defconfig#L171
> https://elixir.bootlin.com/barebox/v2026.06.0/source/common/console.c#L349
>
> Cheers,
> Ahmad
>
> >
> > David
> >
> >>
> >> Nevertheless, I would like the LXA device trees changed, even if only
> >> to align them with all other existing STM32 device trees.
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>
> >>>
> >>> David
> >>>
> >>>>
> >>>> This series fixes this. As the device trees were added at different
> >>>> times, they are fixed each in a separate commit with its own Fixes: tag.
> >>>>
> >>>> ---
> >>>> Ahmad Fatoum (3):
> >>>> ARM: dts: stm32: lxa-mc1: change stdout-path baud rate from 9600 to 115200
> >>>> ARM: dts: stm32: lxa-tac: change stdout-path baud rate from 9600 to 115200
> >>>> ARM: dts: stm32: fairytux2: change stdout-path baud rate from 9600 to 115200
> >>>>
> >>>> arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi | 2 +-
> >>>> arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts | 2 +-
> >>>> arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi | 2 +-
> >>>> 3 files changed, 3 insertions(+), 3 deletions(-)
> >>>> ---
> >>>> base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> >>>> change-id: 20260611-lxa-stdout-path-baudrate-7cf454cdae07
> >>>>
> >>>> Best regards,
> >>>> --
> >>>> Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
^ permalink raw reply
* Re: [PATCH 5/6] irqchip/gic-v3-its: fix typo in comments
From: Marc Zyngier @ 2026-06-15 9:03 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615032910.54735-6-shikemeng@huaweicloud.com>
On Mon, 15 Jun 2026 04:29:09 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> 1. "If it some" -> "If some"
> 2. "by table by reading" -> by reading"
>
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index becd8dd51720..fc32a1709f76 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -163,7 +163,7 @@ struct event_lpi_map {
>
> /*
> * The ITS view of a device - belongs to an ITS, owns an interrupt
> - * translation table, and a list of interrupts. If it some of its
> + * translation table, and a list of interrupts. If some of its
> * LPIs are injected into a guest (GICv4), the event_map.vm field
> * indicates which one.
> */
> @@ -2501,7 +2501,7 @@ static bool its_parse_indirect_baser(struct its_node *its,
> if ((esz << ids) > (psz * 2)) {
> /*
> * Find out whether hw supports a single or two-level table by
> - * table by reading bit at offset '62' after writing '1' to it.
> + * reading bit at offset '62' after writing '1' to it.
> */
If you are going to fix that comment, fix it for good by replacing the
reference to a bit number with its actual name, making it valuable for
everyone.
M.
> its_write_baser(its, baser, val | GITS_BASER_INDIRECT);
> indirect = !!(baser->val & GITS_BASER_INDIRECT);
> --
> 2.36.1
>
>
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Bartosz Golaszewski @ 2026-06-15 9:00 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Heikki Krogerus, Bartosz Golaszewski, Greg Kroah-Hartman,
Daniel Scally, Sakari Ailus, Rafael J. Wysocki, Danilo Krummrich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Alan Stern, linux-acpi, driver-core,
linux-pm, linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam, Andy Shevchenko
In-Reply-To: <CAGXv+5Hf_V4=mkAc3pN8_K9i+FfH2Wv7HVJBq71-f8sMFYL3fA@mail.gmail.com>
On Fri, 12 Jun 2026 07:46:26 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
> On Fri, Jun 12, 2026 at 3:54 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>>
>> On Thu, Jun 11, 2026 at 06:48:56PM +0300, Heikki Krogerus wrote:
>> > On Thu, Jun 11, 2026 at 11:35:13AM +0200, Bartosz Golaszewski wrote:
>> > > On Thu, Jun 11, 2026 at 10:37 AM Andy Shevchenko
>> > > <andriy.shevchenko@linux.intel.com> wrote:
>> > > > On Thu, Jun 11, 2026 at 04:20:58AM -0400, Bartosz Golaszewski wrote:
>> > > > > On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
>> > > > > <andriy.shevchenko@linux.intel.com> said:
>> > > > > > On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
>> > > > > >> When a USB hub port is connected to a connector in a firmware node
>> > > > > >> graph, the port itself has a node in the graph.
>> > > > > >>
>> > > > > >> Associate the port's firmware node with the USB port's device,
>> > > > > >> usb_port::dev. This is used in later changes for the M.2 slot power
>> > > > > >> sequencing provider to match against the requesting port.
>> > > > > >
>> > > > > > Okay, would this affect ACPI-based systems? if so, how?
>> > > > > > Can you elaborate on that, please?
>> > > > >
>> > > > > Is it possible that there's an ACPI device node associated with the port like
>> > > > > on some DT systems? I don't think so and there should be no impact IMO but I
>> > > > > also don't know enough about ACPI.
>> >
>> > There are device nodes for the USB ports in ACPI, and I think they get
>> > always assigned in drivers/usb/core/usb-acpi.c.
>> >
>> > > > The API is agnostic. There is a possibility to have software nodes associated
>> > > > with the port. I think the best is to be sure that ACPI-aware people who are
>> > > > experts in USB will check this (Heikki?).
>> >
>> > I can't say what's the impact from this patch - I'm not an expert with
>> > this side of USB. Is there a danger that we end up overwriting the
>> > ACPI node for the port, or something else?
>>
>> Exactly this one is my worrying, but I haven't checked the actual flow.
>
> Looking through ACPI code, ACPI_COMPANION_SET() is used, which boils
> down to
>
> set_primary_fwnode(dev, acpi_fwnode_handle(acpi_dev))
>
> This is called through
>
> usb_hub_create_port_device()
> device_register()
> device_add()
> device_platform_notify()
> acpi_device_notify()
> usb_acpi_find_companion()
> usb_acpi_find_companion_for_port()
> acpi_bind_one()
> ACPI_COMPANION_SET()
> set_primary_fwnode()
>
> Looking at device_add_software_node(), all swnodes are secondary.
>
> set_primary_fwnode() seems to be able to make the ACPI handle / fwnode
> the primary, keeping any existing fwnode as the secondary. However
> if we do end up assigning a primary fwnode to the device using
> device_set_node() as in this patch, set_primary_fwnode() is going
> to complain loudly.
>
> On another front, the ACPI representation of the USB ports looks nothing
> like the OF graphs, at least on my X1 Carbon:
>
> For a usb port device on the root hub such as
>
> /sys/bus/usb/devices/4-0:1.0/usb4-port1/firmware_node/path
>
> looks like
>
> \_SB_.PC00.XHCI.RHUB.SS01
>
> while a usb port's firmware node link
>
> /sys/bus/usb/devices/4-0:1.0/usb4-port1//firmware_node
>
> resolves to
>
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/device:1a/device:29
>
> Neither looks anything like the graph "port" / "endpoint" node names.
> So maybe we're in the clear here.
>
> Besides the loud warning from set_primary_fwnode(), the major issue stemming
> from a wrong node is that power management (through ACPI) is likely to fail.
>
> If we're still concerned, I think we can skip the assignment if the fwnode
> is an ACPI node, i.e. check it with is_acpi_node().
>
Agreed, I think this is a good compromise.
Bart
>
> I've never worked on ACPI systems, so this is just me checking the code.
>
>
> Thanks
> ChenYu
>
^ permalink raw reply
* Re: [PATCH v4 6/6] drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms
From: Icenowy Zheng @ 2026-06-15 8:58 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260615065003.76661-7-a0987203069@gmail.com>
在 2026-06-15一的 14:50 +0800，Joey Lu写道：
> The DCUltraLite hardware ops and HWDB entry added in the preceding
> commits
> enable the driver to work on Nuvoton MA35D1 hardware. Allow the
> driver
> to be built when ARCH_MA35 is selected; this dependency is meaningful
> only
> now that all supporting code is in place.
The explaination of patch sequence is not needed, but anyway,
`Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>`
Thanks,
Icenowy
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/verisilicon/Kconfig
> b/drivers/gpu/drm/verisilicon/Kconfig
> index 7cce86ec8603..295d246eb4b4 100644
> --- a/drivers/gpu/drm/verisilicon/Kconfig
> +++ b/drivers/gpu/drm/verisilicon/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_VERISILICON_DC
> tristate "DRM Support for Verisilicon DC-series display
> controllers"
> depends on DRM && COMMON_CLK
> - depends on RISCV || COMPILE_TEST
> + depends on RISCV || ARCH_MA35 || COMPILE_TEST
> select DRM_BRIDGE_CONNECTOR
> select DRM_CLIENT_SELECTION
> select DRM_DISPLAY_HELPER
^ permalink raw reply
* Re: [PATCH 4/6] irqchip/gic-v3-its: Add ITS address info in more error logs
From: Marc Zyngier @ 2026-06-15 9:01 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615032910.54735-5-shikemeng@huaweicloud.com>
On Mon, 15 Jun 2026 04:29:08 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> We have a lot of logs containing ITS address info which is helpful to
> distiguish which ITS occurs error. Just add ITS address info into more
> exsiting error logs.
That's only useful on buggy HW, for people debugging it. I don't think
that's useful outside of these scenarios, and this hack can live out
of tree.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v1 0/4] trace_hyp_printk() for pKVM/nVHE hypervisor
From: Fuad Tabba @ 2026-06-15 8:57 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team, qerret
In-Reply-To: <CA+EHjTxG8dK8o7GmoH9hg1p0h5W7H8EnNt1ZwRRXQcNad7R1pw@mail.gmail.com>
On Mon, 15 Jun 2026 at 09:30, Fuad Tabba <tabba@google.com> wrote:
>
> On Mon, 15 Jun 2026 at 09:28, Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > On Sun, Jun 14, 2026 at 01:57:56PM +0100, Fuad Tabba wrote:
> > > Hi Vincent,
> > >
> > > On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > This series adds a hypervisor event "hyp_printk" which enables
> > > > developers to log pretty much anything into the hypervisor tracing
> > > > buffer, just like the kernel function trace_printk().
> > > >
> > > > This enables rich logging from the hypervisor, while leaving all the
> > > > string parsing burden to the kernel. This has been the main way of
> > > > debugging pKVM in Android.
> > >
> > > I tested the series on v7.1-rc7 under QEMU (cortex-a53 CPU, pKVM nVHE):
> > > - Booted a host under pKVM with a non-protected kvmtool guest (npVM)
> > > and a protected kvmtool guest (pVM).
> > > - Functional test: added a temporary trace_hyp_printk() call site in
> > > handle___kvm_vcpu_run() with 0-arg, 1-arg, and 2-arg calls. Mounted
> > > tracefs, enabled the hyp_printk event, ran a kvmtool guest to trigger
> > > vcpu_run, read the trace buffer. All expected entries appeared with
> > > correctly formatted output.
> >
> > Thanks for the testing!
> >
> > >
> > > One question: kvm_hyp_trace_init() returns early when
> > > is_kernel_in_hyp_mode() is true. On VHE-capable hardware, pKVM uses
> > > hVHE. So it seams that the entire hyp tracing subsystem (not just
> > > hyp_printk) is non-functional in hVHE mode. Is hVHE support
> > > intentionally deferred?
> >
> > You got me scared for a moment but I did try hVHE and it seems alright:
> >
> > [ 5.369985] kvm [1]: Protected hVHE mode initialized successfully
> >
> > $ ls /sys/kernel/tracing/remotes/hypervisor/
> >
> > is_kernel_in_hyp_mode() just checks if the kernel is running at EL2 which it
> > shouldn't in the hVHE case?
>
> I'll try again and report back, must be user error.
Confirmed, user error. I must have messed something up with the hVHE test.
My Tested-by for the series covers that now too.
Sorry for the noise.
/fuad
>
> /fuad
>
> >
> > >
> > > Cheers,
> > > /fuad
> > >
> > > >
> > > > Even though not strictly related to trace_hyp_printk, I have added the
> > > > following two patches:
> > > >
> > > > * KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
> > > >
> > > > This one mainly intends to support one of the new features I have
> > > > posted here [1], which allows to enable tracing as early as
> > > > possible. I have added it here to limit cross-posting.
> > > >
> > > > * KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
> > > >
> > > > This one is just a cleanup.
> > > >
> > > > [1] https://lore.kernel.org/all/20260605163825.1762953-1-vdonnefort@google.com/
> > > >
> > > > Vincent Donnefort (4):
> > > > KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
> > > > KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
> > > > tracing/remotes: Add REMOTE_EVENT_CUSTOM_PRINTK() helper
> > > > KVM: arm64: Add hyp_printk event to nVHE/pKVM hyp
> > > >
> > > > arch/arm64/include/asm/kvm_asm.h | 4 +-
> > > > arch/arm64/include/asm/kvm_hypevents.h | 14 ++++
> > > > arch/arm64/include/asm/kvm_hyptrace.h | 8 +++
> > > > arch/arm64/kernel/image-vars.h | 1 +
> > > > arch/arm64/kernel/vmlinux.lds.S | 4 ++
> > > > .../define_hypevents.h} | 0
> > > > .../kvm/hyp/include/nvhe/define_events.h | 2 -
> > > > arch/arm64/kvm/hyp/include/nvhe/trace.h | 65 +++++++++++++++++++
> > > > arch/arm64/kvm/hyp/nvhe/events.c | 6 ++
> > > > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 2 +-
> > > > arch/arm64/kvm/hyp_trace.c | 60 ++++++++++++++++-
> > > > include/trace/define_remote_events.h | 19 +++++-
> > > > 12 files changed, 176 insertions(+), 9 deletions(-)
> > > > rename arch/arm64/{include/asm/kvm_define_hypevents.h => kvm/define_hypevents.h} (100%)
> > > >
> > > >
> > > > base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> > > > --
> > > > 2.54.0.1136.gdb2ca164c4-goog
> > > >
^ permalink raw reply
* Re: [PATCH v4 5/6] drm/verisilicon: add DCUltraLite chip identity to HWDB
From: Icenowy Zheng @ 2026-06-15 8:57 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260615065003.76661-6-a0987203069@gmail.com>
在 2026-06-15一的 14:50 +0800，Joey Lu写道：
> Register the Nuvoton MA35D1 DCUltraLite chip identity in
> vs_chip_identities[]:
> model = 0x0 (DCUltraLite; Verisilicon uses 0 for this IP)
> revision = 0x5560
> customer_id = 0x305
> generation = VSDC_GEN_DC8000
> display_count = 1
> max_cursor_size = 32
I suggest make this more human-readable instead of replicating the
machine-readable data of HWDB.
My proposal here:
```
The Nuvoton MA35D1 chip contains a DCUltraLite display controller with
model number 0x0 (sic, the model name contains no number either),
revision 0x5560 and customer ID 0x305. It has a similar register map
with DC8000, only one display output and only 32x32 cursor supported.
```
>
> Placing this entry last makes it the gate that enables MA35D1
> hardware
> recognition only after all the supporting ops and DT binding changes
> are
> in place.
It's a little ambiguous that "last" here means whether the last in the
patchset or the last in the HWDB array, although I think it's not so
needed to explain the reason of the place in the patchset.
I propose just say `Adding it to the HWDB to enable it to be usable
with the verisilicon driver.` .
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/vs_hwdb.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> index 91524d16f778..7d630a667a3f 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> @@ -129,6 +129,16 @@ static struct vs_chip_identity
> vs_chip_identities[] = {
> .max_cursor_size = 64,
> .formats = &vs_formats_no_yuv444,
> },
> + {
> + .model = 0x0, /* DCUltraLite */
> + .revision = 0x5560,
> + .customer_id = 0x305,
> +
> + .generation = VSDC_GEN_DC8000,
> + .display_count = 1,
> + .max_cursor_size = 32,
> + .formats = &vs_formats_no_yuv444,
> + },
> };
>
> int vs_fill_chip_identity(struct regmap *regs,
^ permalink raw reply
* Re: [PATCH] ARM: disable broken eBPF JIT on the Risc PC
From: David Laight @ 2026-06-15 8:56 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-kernel, stable, Russell King,
Russell King (Oracle), Arnd Bergmann, Linus Walleij, Kees Cook,
Nathan Chancellor, Thomas Weissschuh, Peter Zijlstra,
Shubham Bansal, David S. Miller
In-Reply-To: <CADkSEUizT2dxUni185QDEkmVA+_r9bEQgbuEbZ8b-Sg3JZWrFA@mail.gmail.com>
On Sun, 14 Jun 2026 14:44:38 -0700
Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:
> Hi, David,
>
> On Sun, Jun 14, 2026 at 4:58 AM David Laight
> <david.laight.linux@gmail.com> wrote:
> > Isn't it more the case that the ldrh/strh instructions were added for armv4.
> > Whether the bus supports 16bit accesses is entirely different.
>
> No, it is in fact the bus. While the Risc PC initially shipped with
> ARMv3 CPUs, which the kernel no longer supports, it was later upgraded
> to an ARMv4 StrongARM CPU. However, its bus was designed for ARMv3
> CPUs and has no way to represent a half-word access to memory. This
> means that ldrh/strh will execute (because the CPU supports them) but
> do not function as intended.
Ok, so they work fine for cached accesses.
The only issue will be with uncached ones?
(Or do I remember the strongarm having a write-through cache?)
It just seems odd because byte writes are usually handled with four
byte-enable lines; so the targets support all 16 combinations even
though a cpu will (normally) only be able to generate 8 of them.
David
>
> Ethan
^ permalink raw reply
* Re: [PATCH 2/6] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Marc Zyngier @ 2026-06-15 8:59 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615032910.54735-3-shikemeng@huaweicloud.com>
On Mon, 15 Jun 2026 04:29:06 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> Fix collection leak when its_init_domain() failed in its_probe_one().
>
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 2b7b546c43c8..df26ddc97ae2 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3032,6 +3032,12 @@ static int its_alloc_collections(struct its_node *its)
> return 0;
> }
>
> +static void its_free_collections(struct its_node *its)
> +{
> + kfree(its->collections);
> + its->collections = NULL;
> +}
Why do we need an extra helper for something that has a single calling
spot? Why is it important to set collections to NULL, given that we're
about to free the structure without even looking further?
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH RFC 3/3] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Jinjie Ruan @ 2026-06-15 8:51 UTC (permalink / raw)
To: Michael Kelley, catalin.marinas@arm.com, will@kernel.org,
tsbogend@alpha.franken.de, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, peterz@infradead.org, kees@kernel.org,
nathan@kernel.org, linusw@kernel.org, ojeda@kernel.org,
david.kaplan@amd.com, lukas.bulwahn@redhat.com,
ryan.roberts@arm.com, maz@kernel.org, timothy.hayes@arm.com,
lpieralisi@kernel.org, thuth@redhat.com, oupton@kernel.org,
yeoreum.yun@arm.com, miko.lenczewski@arm.com, broonie@kernel.org,
kevin.brodsky@arm.com, james.clark@linaro.org, tabba@google.com,
mrigendra.chaubey@gmail.com, arnd@arndb.de,
anshuman.khandual@arm.com, x86@kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <SN6PR02MB41575306521E6223561F476FD4182@SN6PR02MB4157.namprd02.prod.outlook.com>
On 6/12/2026 11:45 PM, Michael Kelley wrote:
> From: Jinjie Ruan <ruanjinjie@huawei.com> Sent: Thursday, June 11, 2026 6:38 AM
>>
>> Support for parallel secondary CPU bringup is already utilized by x86,
>> MIPS, and RISC-V. This patch brings this capability to the arm64
>> architecture.
>>
>> Rework the global `secondary_data` accessed during early boot into
>> a per-CPU array. This array maps logical CPU IDs to MPIDR_EL1 values,
>> enabling the early boot code in head.S to resolve each secondary CPU's
>> logical ID concurrently.
>>
>> To fully enable HOTPLUG_PARALLEL, this patch implements:
>> 1) An arm64-specific arch_cpuhp_kick_ap_alive() handler.
>> 2) Callbacks to cpuhp_ap_sync_alive() inside secondary_start_kernel().
>>
>> Successfully tested on QEMU ARM64 virt machine (KVM on, 128 vCPUs).
>>
>> | test kernel | secondary CPUs boot time |
>> | --------------------- | -------------------- |
>> | Without this patch | 155.672 |
>> | cpuhp.parallel=0 | 62.897 |
>> | cpuhp.parallel=1 | 166.703 |
>
> The last two rows seem mixed up. I would expect parallel=0 to
> result in a longer boot time.
Hi, Michael,
The results are correct and not mixed up.
Compared to the original non‑HOTPLUG_PARALLEL approach, the advantage of
cpuhp.parallel=0 lies in its use of cpu_relax(`yield` on arm64) instead
of the wait_for_completion_timeout() mechanism (which may cause sleep
and context switching). This significantly reduces the overhead of VM
exits and context switches in a KVM guest, thereby cutting the secondary
CPU boot time by more than half.
Regarding cpuhp.parallel=1, I believe the reason it fails to optimize
boot time is that when a large number of CPUs issue the KICK_AP call
simultaneously, it results in severe lock contention within KVM, which
paradoxically slows down secondary CPU bringup. However, this needs
further investigation into the PSCI_CPU_ON code in KVM.
I'm testing these performance aspects on physical hardware, so the
results might be somewhat different because secondary CPU bringup
requires trapping into the ATF firmware.
Best regards,
Jinjie
>
> Michael
>
>>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/smp.h | 8 ++++++++
>> arch/arm64/kernel/head.S | 23 +++++++++++++++++++++++
>> arch/arm64/kernel/smp.c | 27 +++++++++++++++++++++++++++
>> 4 files changed, 59 insertions(+)
>>
>
>
^ permalink raw reply
* Re: [PATCH v4 4/6] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: Icenowy Zheng @ 2026-06-15 8:51 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260615065003.76661-5-a0987203069@gmail.com>
在 2026-06-15一的 14:50 +0800，Joey Lu写道：
> The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
> controller whose register layout differs from the DC8200 in several
> important ways:
>
> 1. No CONFIG_EX commit path: framebuffer updates use the enable (bit
> 0)
> and reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
> registers (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT,
> FB_BLEND_CONFIG, PANEL_CONFIG_EX).
>
> 2. No PANEL_START register: panel output starts when
> PANEL_CONFIG.RUNNING is set; there is no multi-display sync start
> register.
>
> 3. Different IRQ registers: DCUltraLite uses DISP_IRQ_STA (0x147C) /
> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
> TOP_IRQ_EN (0x0014).
>
> 4. Per-frame commit cycle: DCUltraLite requires the VALID bit in
> FB_CONFIG to be set at the start of each atomic commit
> (crtc_begin)
> and cleared after (crtc_flush).
>
> 5. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
> divider) clocks; no axi or ahb clocks required. Make axi_clk and
> ahb_clk optional (devm_clk_get_optional_enabled) so DC8000 nodes
> without those clocks are handled gracefully.
>
> Add vs_dc8000.c implementing the vs_dc_funcs vtable for the above
> differences. The probe now selects vs_dc8000_funcs when the
> identified
> generation is VSDC_GEN_DC8000 (DCUltraLite reads model 0x0,
> revision 0x5560, customer_id 0x305).
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/Makefile | 2 +-
> drivers/gpu/drm/verisilicon/vs_dc.c | 9 ++-
> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
> drivers/gpu/drm/verisilicon/vs_dc8000.c | 78
> +++++++++++++++++++++++++
> 4 files changed, 86 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
>
> diff --git a/drivers/gpu/drm/verisilicon/Makefile
> b/drivers/gpu/drm/verisilicon/Makefile
> index 9d4cd16452fa..d2fd8e4dff24 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
> vs_drm.o vs_hwdb.o \
> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
> vs_dc8000.o vs_drm.o vs_hwdb.o \
> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>
> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
> b/drivers/gpu/drm/verisilicon/vs_dc.c
> index 9729b693d360..9499fffbca58 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> return PTR_ERR(dc->core_clk);
> }
>
> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
> if (IS_ERR(dc->axi_clk)) {
> dev_err(dev, "can't get axi clock\n");
> return PTR_ERR(dc->axi_clk);
> }
>
> - dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
> + dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
Please make the clock change a separated patch for atomicity.
BTW the MA35D1 manual's clock tree shows that DCUltra appears on AXI2
ACLK, AHB_HCLK2, behind a mux of SYS-PLL/EPLL-DIV2 (which seems to be
the core clock), and behind a divider (which seems to be the pixel
clock).
However it's weird that only one DCUltra Clock Enable Bit exists
despite both bus clocks have "ICG" (I think it means "Integrated Clock
Gating"). In addition the linux clk-ma35d1 driver assigns "dcu_gate" as
a downstream of "dcu_mux", although the Figure 6.5-2 in the TRM shows
no ICG after the "Display core CLK" mux.
Is the two bus clocks controlled by a single gate bit, and is the bit
also gating DC core clock?
Thanks,
Icenowy
> if (IS_ERR(dc->ahb_clk)) {
> dev_err(dev, "can't get ahb clock\n");
> return PTR_ERR(dc->ahb_clk);
> @@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
> >identity.model,
> dc->identity.revision, dc->identity.customer_id);
>
> - dc->funcs = &vs_dc8200_funcs;
> + if (dc->identity.generation == VSDC_GEN_DC8200)
> + dc->funcs = &vs_dc8200_funcs;
> + else
> + dc->funcs = &vs_dc8000_funcs;
>
> if (port_count > dc->identity.display_count) {
> dev_err(dev, "too many downstream ports than HW
> capability\n");
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
> b/drivers/gpu/drm/verisilicon/vs_dc.h
> index 544e1a37065b..5218e8cf63e2 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
> @@ -66,5 +66,6 @@ struct vs_dc {
> };
>
> extern const struct vs_dc_funcs vs_dc8200_funcs;
> +extern const struct vs_dc_funcs vs_dc8000_funcs;
>
> #endif /* _VS_DC_H_ */
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8000.c
> b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> new file mode 100644
> index 000000000000..be0c0d7baf52
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> @@ -0,0 +1,78 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 Joey Lu <yclu4@nuvoton.com>
> + */
> +
> +#include <linux/regmap.h>
> +
> +#include "vs_crtc_regs.h"
> +#include "vs_dc.h"
> +#include "vs_primary_plane_regs.h"
> +
> +static void vs_dc8000_panel_enable_ex(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_RESET);
> +}
> +
> +static void vs_dc8000_panel_disable_ex(struct vs_dc *dc, unsigned
> int output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_RESET);
> +}
> +
> +static void vs_dc8000_crtc_begin(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_VALID);
> +}
> +
> +static void vs_dc8000_crtc_flush(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_VALID);
> +}
> +
> +static void vs_dc8000_crtc_enable(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE);
> +}
> +
> +static void vs_dc8000_crtc_disable(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE);
> +}
> +
> +static void vs_dc8000_enable_vblank(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_DISP_IRQ_EN,
> + VSDC_DISP_IRQ_VSYNC(output));
> +}
> +
> +static void vs_dc8000_disable_vblank(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_DISP_IRQ_EN,
> + VSDC_DISP_IRQ_VSYNC(output));
> +}
> +
> +static u32 vs_dc8000_irq_ack(struct vs_dc *dc)
> +{
> + u32 irqs;
> +
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &irqs);
> + return irqs;
> +}
> +
> +const struct vs_dc_funcs vs_dc8000_funcs = {
> + .panel_enable_ex = vs_dc8000_panel_enable_ex,
> + .panel_disable_ex = vs_dc8000_panel_disable_ex,
> + .crtc_begin = vs_dc8000_crtc_begin,
> + .crtc_flush = vs_dc8000_crtc_flush,
> + .crtc_enable = vs_dc8000_crtc_enable,
> + .crtc_disable = vs_dc8000_crtc_disable,
> + .enable_vblank = vs_dc8000_enable_vblank,
> + .disable_vblank = vs_dc8000_disable_vblank,
> + .irq_ack = vs_dc8000_irq_ack,
> +};
^ permalink raw reply
* Re: [PATCH 1/6] irqchip/gic-v3-its: Fix LPI range leak and refactor error handler in its_lpi_alloc()
From: Marc Zyngier @ 2026-06-15 8:52 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615032910.54735-2-shikemeng@huaweicloud.com>
On Mon, 15 Jun 2026 04:29:05 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> Fix the LIP range leak when bitmap_zalloc() failed. Besides refactor
Typo.
> error handling code to make it a little simpler.
No. Please don't mix fixes and (totally pointless) refactoring.
>
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8d..2b7b546c43c8 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -2217,10 +2217,9 @@ static int __init its_lpi_init(u32 id_bits)
> static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
> {
> unsigned long *bitmap = NULL;
> - int err = 0;
>
> do {
> - err = alloc_lpi_range(nr_irqs, base);
> + int err = alloc_lpi_range(nr_irqs, base);
> if (!err)
> break;
>
> @@ -2228,22 +2227,20 @@ static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
> } while (nr_irqs > 0);
>
> if (!nr_irqs)
> - err = -ENOSPC;
> -
> - if (err)
> - goto out;
> + goto err_out;
>
> bitmap = bitmap_zalloc(nr_irqs, GFP_ATOMIC);
> if (!bitmap)
> - goto out;
> + goto err_free_lpi;
>
> *nr_ids = nr_irqs;
> -
> -out:
> - if (!bitmap)
> - *base = *nr_ids = 0;
> -
> return bitmap;
> +
> +err_free_lpi:
> + free_lpi_range(*base, nr_irqs);
> +err_out:
> + *base = *nr_ids = 0;
> + return NULL;
> }
>
> static void its_lpi_free(unsigned long *bitmap, u32 base, u32 nr_ids)
Honestly, I question the validity of handling errors this way. You are
already unable to allocate a per-device bitmap. And yet you are
calling free_lpi_range(), which has the interesting property of
*allocating* memory. Which you don't have. Oh wait...
M.
--
Jazz isn't dead. It just smells funny.
^ 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