* [PATCH 49/78] ASoC: codecs: rt712: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:32 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Cheng-Yi Chiang,
Tzung-Bi Shih, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek, bui duc phuc
In-Reply-To: <20260617103235.449609-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/codecs/rt712-sdca-sdw.c | 34 +++++++++++++++----------------
sound/soc/codecs/rt712-sdca.c | 7 ++-----
2 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/sound/soc/codecs/rt712-sdca-sdw.c b/sound/soc/codecs/rt712-sdca-sdw.c
index 581732180473..066d15399bd9 100644
--- a/sound/soc/codecs/rt712-sdca-sdw.c
+++ b/sound/soc/codecs/rt712-sdca-sdw.c
@@ -277,7 +277,7 @@ static int rt712_sdca_interrupt_callback(struct sdw_slave *slave,
* scheme. We do want however to prevent new workqueues from being scheduled if
* the disable_irq flag was set during system suspend.
*/
- mutex_lock(&rt712->disable_irq_lock);
+ guard(mutex)(&rt712->disable_irq_lock);
ret = sdw_read_no_pm(rt712->slave, SDW_SCP_SDCA_INT1);
if (ret < 0)
@@ -341,12 +341,9 @@ static int rt712_sdca_interrupt_callback(struct sdw_slave *slave,
mod_delayed_work(system_power_efficient_wq,
&rt712->jack_detect_work, msecs_to_jiffies(30));
- mutex_unlock(&rt712->disable_irq_lock);
-
return 0;
io_error:
- mutex_unlock(&rt712->disable_irq_lock);
pr_err_ratelimited("IO error in %s, ret %d\n", __func__, ret);
return ret;
}
@@ -428,13 +425,13 @@ static int rt712_sdca_dev_system_suspend(struct device *dev)
* deferred work completes and before the parent disables
* interrupts on the link
*/
- mutex_lock(&rt712_sdca->disable_irq_lock);
- rt712_sdca->disable_irq = true;
- ret1 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK1,
- SDW_SCP_SDCA_INTMASK_SDCA_0, 0);
- ret2 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK2,
- SDW_SCP_SDCA_INTMASK_SDCA_8, 0);
- mutex_unlock(&rt712_sdca->disable_irq_lock);
+ scoped_guard(mutex, &rt712_sdca->disable_irq_lock) {
+ rt712_sdca->disable_irq = true;
+ ret1 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK1,
+ SDW_SCP_SDCA_INTMASK_SDCA_0, 0);
+ ret2 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK2,
+ SDW_SCP_SDCA_INTMASK_SDCA_8, 0);
+ }
if (ret1 < 0 || ret2 < 0) {
/* log but don't prevent suspend from happening */
@@ -456,14 +453,15 @@ static int rt712_sdca_dev_resume(struct device *dev)
return 0;
if (!slave->unattach_request) {
- mutex_lock(&rt712->disable_irq_lock);
- if (rt712->disable_irq == true) {
-
- sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK1, SDW_SCP_SDCA_INTMASK_SDCA_0);
- sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK2, SDW_SCP_SDCA_INTMASK_SDCA_8);
- rt712->disable_irq = false;
+ scoped_guard(mutex, &rt712->disable_irq_lock) {
+ if (rt712->disable_irq == true) {
+ sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK1,
+ SDW_SCP_SDCA_INTMASK_SDCA_0);
+ sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK2,
+ SDW_SCP_SDCA_INTMASK_SDCA_8);
+ rt712->disable_irq = false;
+ }
}
- mutex_unlock(&rt712->disable_irq_lock);
}
ret = sdw_slave_wait_for_init(slave, RT712_PROBE_TIMEOUT);
diff --git a/sound/soc/codecs/rt712-sdca.c b/sound/soc/codecs/rt712-sdca.c
index 4796fce084ff..5db478633f17 100644
--- a/sound/soc/codecs/rt712-sdca.c
+++ b/sound/soc/codecs/rt712-sdca.c
@@ -79,7 +79,7 @@ static int rt712_sdca_calibration(struct rt712_sdca_priv *rt712)
int chk_cnt = 100;
int ret = 0;
- mutex_lock(&rt712->calibrate_mutex);
+ guard(mutex)(&rt712->calibrate_mutex);
dev = regmap_get_device(regmap);
/* Set HP-JD source from JD1 */
@@ -126,7 +126,6 @@ static int rt712_sdca_calibration(struct rt712_sdca_priv *rt712)
/* Release HP-JD, EN_CBJ_TIE_GL/R open, en_osw gating auto done bit */
rt712_sdca_index_write(rt712, RT712_VENDOR_REG, RT712_DIGITAL_MISC_CTRL4, 0x0010);
- mutex_unlock(&rt712->calibrate_mutex);
dev_dbg(dev, "%s calibration complete, ret=%d\n", __func__, ret);
return ret;
}
@@ -403,7 +402,7 @@ static void rt712_sdca_btn_check_handler(struct work_struct *work)
static void rt712_sdca_jack_init(struct rt712_sdca_priv *rt712)
{
- mutex_lock(&rt712->calibrate_mutex);
+ guard(mutex)(&rt712->calibrate_mutex);
if (rt712->hs_jack) {
/* Enable HID1 event & set button RTC mode */
@@ -450,8 +449,6 @@ static void rt712_sdca_jack_init(struct rt712_sdca_priv *rt712)
dev_dbg(&rt712->slave->dev, "in %s disable\n", __func__);
}
-
- mutex_unlock(&rt712->calibrate_mutex);
}
static int rt712_sdca_set_jack_detect(struct snd_soc_component *component,
--
2.43.0
^ permalink raw reply related
* [PATCH 50/78] ASoC: codecs: rt721: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:32 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Cheng-Yi Chiang,
Tzung-Bi Shih, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek, bui duc phuc
In-Reply-To: <20260617103235.449609-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/codecs/rt721-sdca-sdw.c | 33 +++++++++++++++----------------
sound/soc/codecs/rt721-sdca.c | 3 +--
2 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/sound/soc/codecs/rt721-sdca-sdw.c b/sound/soc/codecs/rt721-sdca-sdw.c
index 58606209316a..0ee78b28a3ce 100644
--- a/sound/soc/codecs/rt721-sdca-sdw.c
+++ b/sound/soc/codecs/rt721-sdca-sdw.c
@@ -315,7 +315,7 @@ static int rt721_sdca_interrupt_callback(struct sdw_slave *slave,
* scheme. We do want however to prevent new workqueues from being scheduled if
* the disable_irq flag was set during system suspend.
*/
- mutex_lock(&rt721->disable_irq_lock);
+ guard(mutex)(&rt721->disable_irq_lock);
ret = sdw_read_no_pm(rt721->slave, SDW_SCP_SDCA_INT1);
if (ret < 0)
@@ -382,12 +382,9 @@ static int rt721_sdca_interrupt_callback(struct sdw_slave *slave,
mod_delayed_work(system_power_efficient_wq,
&rt721->jack_detect_work, msecs_to_jiffies(280));
- mutex_unlock(&rt721->disable_irq_lock);
-
return 0;
io_error:
- mutex_unlock(&rt721->disable_irq_lock);
pr_err_ratelimited("IO error in %s, ret %d\n", __func__, ret);
return ret;
}
@@ -467,13 +464,13 @@ static int rt721_sdca_dev_system_suspend(struct device *dev)
* deferred work completes and before the parent disables
* interrupts on the link
*/
- mutex_lock(&rt721_sdca->disable_irq_lock);
- rt721_sdca->disable_irq = true;
- ret1 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK1,
- SDW_SCP_SDCA_INTMASK_SDCA_0, 0);
- ret2 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK2,
- SDW_SCP_SDCA_INTMASK_SDCA_8, 0);
- mutex_unlock(&rt721_sdca->disable_irq_lock);
+ scoped_guard(mutex, &rt721_sdca->disable_irq_lock) {
+ rt721_sdca->disable_irq = true;
+ ret1 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK1,
+ SDW_SCP_SDCA_INTMASK_SDCA_0, 0);
+ ret2 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK2,
+ SDW_SCP_SDCA_INTMASK_SDCA_8, 0);
+ }
if (ret1 < 0 || ret2 < 0) {
/* log but don't prevent suspend from happening */
@@ -495,13 +492,15 @@ static int rt721_sdca_dev_resume(struct device *dev)
return 0;
if (!slave->unattach_request) {
- mutex_lock(&rt721->disable_irq_lock);
- if (rt721->disable_irq == true) {
- sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK1, SDW_SCP_SDCA_INTMASK_SDCA_0);
- sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK2, SDW_SCP_SDCA_INTMASK_SDCA_8);
- rt721->disable_irq = false;
+ scoped_guard(mutex, &rt721->disable_irq_lock) {
+ if (rt721->disable_irq == true) {
+ sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK1,
+ SDW_SCP_SDCA_INTMASK_SDCA_0);
+ sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK2,
+ SDW_SCP_SDCA_INTMASK_SDCA_8);
+ rt721->disable_irq = false;
+ }
}
- mutex_unlock(&rt721->disable_irq_lock);
}
ret = sdw_slave_wait_for_init(slave, RT721_PROBE_TIMEOUT);
diff --git a/sound/soc/codecs/rt721-sdca.c b/sound/soc/codecs/rt721-sdca.c
index 35960c225224..157269ba2723 100644
--- a/sound/soc/codecs/rt721-sdca.c
+++ b/sound/soc/codecs/rt721-sdca.c
@@ -289,7 +289,7 @@ static void rt721_sdca_jack_preset(struct rt721_sdca_priv *rt721)
static void rt721_sdca_jack_init(struct rt721_sdca_priv *rt721)
{
- mutex_lock(&rt721->calibrate_mutex);
+ guard(mutex)(&rt721->calibrate_mutex);
if (rt721->hs_jack) {
sdw_write_no_pm(rt721->slave, SDW_SCP_SDCA_INTMASK1,
SDW_SCP_SDCA_INTMASK_SDCA_0);
@@ -309,7 +309,6 @@ static void rt721_sdca_jack_init(struct rt721_sdca_priv *rt721)
rt_sdca_index_update_bits(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
RT721_GE_REL_CTRL1, 0x4000, 0x4000);
}
- mutex_unlock(&rt721->calibrate_mutex);
}
static int rt721_sdca_set_jack_detect(struct snd_soc_component *component,
--
2.43.0
^ permalink raw reply related
* [PATCH 51/78] ASoC: codecs: rt722: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:32 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Cheng-Yi Chiang,
Tzung-Bi Shih, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek, bui duc phuc
In-Reply-To: <20260617103235.449609-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/codecs/rt722-sdca-sdw.c | 33 +++++++++++++++----------------
sound/soc/codecs/rt722-sdca.c | 3 +--
2 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/sound/soc/codecs/rt722-sdca-sdw.c b/sound/soc/codecs/rt722-sdca-sdw.c
index 0f76492ff915..ca5a4ee6ce9e 100644
--- a/sound/soc/codecs/rt722-sdca-sdw.c
+++ b/sound/soc/codecs/rt722-sdca-sdw.c
@@ -368,7 +368,7 @@ static int rt722_sdca_interrupt_callback(struct sdw_slave *slave,
* scheme. We do want however to prevent new workqueues from being scheduled if
* the disable_irq flag was set during system suspend.
*/
- mutex_lock(&rt722->disable_irq_lock);
+ guard(mutex)(&rt722->disable_irq_lock);
ret = sdw_read_no_pm(rt722->slave, SDW_SCP_SDCA_INT1);
if (ret < 0)
@@ -432,12 +432,9 @@ static int rt722_sdca_interrupt_callback(struct sdw_slave *slave,
mod_delayed_work(system_power_efficient_wq,
&rt722->jack_detect_work, msecs_to_jiffies(280));
- mutex_unlock(&rt722->disable_irq_lock);
-
return 0;
io_error:
- mutex_unlock(&rt722->disable_irq_lock);
pr_err_ratelimited("IO error in %s, ret %d\n", __func__, ret);
return ret;
}
@@ -514,13 +511,13 @@ static int rt722_sdca_dev_system_suspend(struct device *dev)
* deferred work completes and before the parent disables
* interrupts on the link
*/
- mutex_lock(&rt722_sdca->disable_irq_lock);
- rt722_sdca->disable_irq = true;
- ret1 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK1,
- SDW_SCP_SDCA_INTMASK_SDCA_0, 0);
- ret2 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK2,
- SDW_SCP_SDCA_INTMASK_SDCA_8, 0);
- mutex_unlock(&rt722_sdca->disable_irq_lock);
+ scoped_guard(mutex, &rt722_sdca->disable_irq_lock) {
+ rt722_sdca->disable_irq = true;
+ ret1 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK1,
+ SDW_SCP_SDCA_INTMASK_SDCA_0, 0);
+ ret2 = sdw_update_no_pm(slave, SDW_SCP_SDCA_INTMASK2,
+ SDW_SCP_SDCA_INTMASK_SDCA_8, 0);
+ }
if (ret1 < 0 || ret2 < 0) {
/* log but don't prevent suspend from happening */
@@ -542,13 +539,15 @@ static int rt722_sdca_dev_resume(struct device *dev)
return 0;
if (!slave->unattach_request) {
- mutex_lock(&rt722->disable_irq_lock);
- if (rt722->disable_irq == true) {
- sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK1, SDW_SCP_SDCA_INTMASK_SDCA_0);
- sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK2, SDW_SCP_SDCA_INTMASK_SDCA_8);
- rt722->disable_irq = false;
+ scoped_guard(mutex, &rt722->disable_irq_lock) {
+ if (rt722->disable_irq == true) {
+ sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK1,
+ SDW_SCP_SDCA_INTMASK_SDCA_0);
+ sdw_write_no_pm(slave, SDW_SCP_SDCA_INTMASK2,
+ SDW_SCP_SDCA_INTMASK_SDCA_8);
+ rt722->disable_irq = false;
+ }
}
- mutex_unlock(&rt722->disable_irq_lock);
}
ret = sdw_slave_wait_for_init(slave, RT722_PROBE_TIMEOUT);
diff --git a/sound/soc/codecs/rt722-sdca.c b/sound/soc/codecs/rt722-sdca.c
index 1b6729f363fc..5fb5dc2ee3b4 100644
--- a/sound/soc/codecs/rt722-sdca.c
+++ b/sound/soc/codecs/rt722-sdca.c
@@ -294,7 +294,7 @@ static void rt722_sdca_btn_check_handler(struct work_struct *work)
static void rt722_sdca_jack_init(struct rt722_sdca_priv *rt722)
{
- mutex_lock(&rt722->calibrate_mutex);
+ guard(mutex)(&rt722->calibrate_mutex);
if (rt722->hs_jack) {
/* set SCP_SDCA_IntMask1[0]=1 */
sdw_write_no_pm(rt722->slave, SDW_SCP_SDCA_INTMASK1,
@@ -317,7 +317,6 @@ static void rt722_sdca_jack_init(struct rt722_sdca_priv *rt722)
rt722_sdca_index_update_bits(rt722, RT722_VENDOR_HDA_CTL,
RT722_GE_RELATED_CTL2, 0x4000, 0x4000);
}
- mutex_unlock(&rt722->calibrate_mutex);
}
static int rt722_sdca_set_jack_detect(struct snd_soc_component *component,
--
2.43.0
^ permalink raw reply related
* [PATCH 52/78] ASoC: codecs: sigmadsp: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:32 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Cheng-Yi Chiang,
Tzung-Bi Shih, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek, bui duc phuc
In-Reply-To: <20260617103235.449609-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/codecs/sigmadsp.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/sound/soc/codecs/sigmadsp.c b/sound/soc/codecs/sigmadsp.c
index 2e08fde3989c..592aba25de11 100644
--- a/sound/soc/codecs/sigmadsp.c
+++ b/sound/soc/codecs/sigmadsp.c
@@ -135,7 +135,7 @@ static int sigmadsp_ctrl_put(struct snd_kcontrol *kcontrol,
uint8_t *data;
int ret = 0;
- mutex_lock(&sigmadsp->lock);
+ guard(mutex)(&sigmadsp->lock);
data = ucontrol->value.bytes.data;
@@ -148,8 +148,6 @@ static int sigmadsp_ctrl_put(struct snd_kcontrol *kcontrol,
ctrl->cached = true;
}
- mutex_unlock(&sigmadsp->lock);
-
return ret;
}
@@ -160,7 +158,7 @@ static int sigmadsp_ctrl_get(struct snd_kcontrol *kcontrol,
struct sigmadsp *sigmadsp = snd_kcontrol_chip(kcontrol);
int ret = 0;
- mutex_lock(&sigmadsp->lock);
+ guard(mutex)(&sigmadsp->lock);
if (!ctrl->cached) {
ret = sigmadsp_read(sigmadsp, ctrl->addr, ctrl->cache,
@@ -174,8 +172,6 @@ static int sigmadsp_ctrl_get(struct snd_kcontrol *kcontrol,
ctrl->num_bytes);
}
- mutex_unlock(&sigmadsp->lock);
-
return ret;
}
@@ -677,10 +673,10 @@ static void sigmadsp_activate_ctrl(struct sigmadsp *sigmadsp,
return;
changed = snd_ctl_activate_id(card, &ctrl->kcontrol->id, active);
if (active && changed > 0) {
- mutex_lock(&sigmadsp->lock);
- if (ctrl->cached)
- sigmadsp_ctrl_write(sigmadsp, ctrl, ctrl->cache);
- mutex_unlock(&sigmadsp->lock);
+ scoped_guard(mutex, &sigmadsp->lock) {
+ if (ctrl->cached)
+ sigmadsp_ctrl_write(sigmadsp, ctrl, ctrl->cache);
+ }
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH 53/78] ASoC: codecs: sta350: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:32 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Cheng-Yi Chiang,
Tzung-Bi Shih, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek, bui duc phuc
In-Reply-To: <20260617103235.449609-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/codecs/sta350.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/sound/soc/codecs/sta350.c b/sound/soc/codecs/sta350.c
index 99c7f7ac807b..b1e2f346c647 100644
--- a/sound/soc/codecs/sta350.c
+++ b/sound/soc/codecs/sta350.c
@@ -306,9 +306,9 @@ static int sta350_coefficient_get(struct snd_kcontrol *kcontrol,
int numcoef = kcontrol->private_value >> 16;
int index = kcontrol->private_value & 0xffff;
unsigned int cfud, val;
- int i, ret = 0;
+ int i;
- mutex_lock(&sta350->coeff_lock);
+ guard(mutex)(&sta350->coeff_lock);
/* preserve reserved bits in STA350_CFUD */
regmap_read(sta350->regmap, STA350_CFUD, &cfud);
@@ -325,8 +325,7 @@ static int sta350_coefficient_get(struct snd_kcontrol *kcontrol,
} else if (numcoef == 5) {
regmap_write(sta350->regmap, STA350_CFUD, cfud | 0x08);
} else {
- ret = -EINVAL;
- goto exit_unlock;
+ return -EINVAL;
}
for (i = 0; i < 3 * numcoef; i++) {
@@ -334,10 +333,7 @@ static int sta350_coefficient_get(struct snd_kcontrol *kcontrol,
ucontrol->value.bytes.data[i] = val;
}
-exit_unlock:
- mutex_unlock(&sta350->coeff_lock);
-
- return ret;
+ return 0;
}
static int sta350_coefficient_put(struct snd_kcontrol *kcontrol,
--
2.43.0
^ permalink raw reply related
* [PATCH 54/78] ASoC: codecs: sta32x: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:32 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Cheng-Yi Chiang,
Tzung-Bi Shih, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek, bui duc phuc
In-Reply-To: <20260617103235.449609-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/codecs/sta32x.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/sound/soc/codecs/sta32x.c b/sound/soc/codecs/sta32x.c
index 652c6e3a9e63..61703e6e0586 100644
--- a/sound/soc/codecs/sta32x.c
+++ b/sound/soc/codecs/sta32x.c
@@ -271,7 +271,7 @@ static int sta32x_coefficient_get(struct snd_kcontrol *kcontrol,
unsigned int cfud, val;
int i, ret = 0;
- mutex_lock(&sta32x->coeff_lock);
+ guard(mutex)(&sta32x->coeff_lock);
/* preserve reserved bits in STA32X_CFUD */
regmap_read(sta32x->regmap, STA32X_CFUD, &cfud);
@@ -287,19 +287,15 @@ static int sta32x_coefficient_get(struct snd_kcontrol *kcontrol,
regmap_write(sta32x->regmap, STA32X_CFUD, cfud | 0x04);
} else if (numcoef == 5) {
regmap_write(sta32x->regmap, STA32X_CFUD, cfud | 0x08);
- } else {
- ret = -EINVAL;
- goto exit_unlock;
- }
+ } else
+ return -EINVAL;
+
for (i = 0; i < 3 * numcoef; i++) {
regmap_read(sta32x->regmap, STA32X_B1CF1 + i, &val);
ucontrol->value.bytes.data[i] = val;
}
-exit_unlock:
- mutex_unlock(&sta32x->coeff_lock);
-
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 55/78] ASoC: codecs: tas2781: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:32 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Cheng-Yi Chiang,
Tzung-Bi Shih, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek, bui duc phuc
In-Reply-To: <20260617103235.449609-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/codecs/tas2781-comlib-i2c.c | 4 +---
sound/soc/codecs/tas2781-i2c.c | 20 ++++++++------------
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/sound/soc/codecs/tas2781-comlib-i2c.c b/sound/soc/codecs/tas2781-comlib-i2c.c
index e24d56a14cfd..85fcb33752a1 100644
--- a/sound/soc/codecs/tas2781-comlib-i2c.c
+++ b/sound/soc/codecs/tas2781-comlib-i2c.c
@@ -342,7 +342,7 @@ int tascodec_init(struct tasdevice_priv *tas_priv, void *codec,
/* Codec Lock Hold to ensure that codec_probe and firmware parsing and
* loading do not simultaneously execute.
*/
- mutex_lock(&tas_priv->codec_lock);
+ guard(mutex)(&tas_priv->codec_lock);
if (tas_priv->name_prefix)
scnprintf(tas_priv->rca_binaryname, 64, "%s-%sRCA%d.bin",
@@ -360,8 +360,6 @@ int tascodec_init(struct tasdevice_priv *tas_priv, void *codec,
dev_err(tas_priv->dev, "request_firmware_nowait err:0x%08x\n",
ret);
- /* Codec Lock Release*/
- mutex_unlock(&tas_priv->codec_lock);
return ret;
}
EXPORT_SYMBOL_GPL(tascodec_init);
diff --git a/sound/soc/codecs/tas2781-i2c.c b/sound/soc/codecs/tas2781-i2c.c
index 9e6f0ad5f05d..f2b739780f73 100644
--- a/sound/soc/codecs/tas2781-i2c.c
+++ b/sound/soc/codecs/tas2781-i2c.c
@@ -843,12 +843,12 @@ static int tasdevice_digital_gain_get(
unsigned char data[4];
int ret;
- mutex_lock(&tas_dev->codec_lock);
+ guard(mutex)(&tas_dev->codec_lock);
/* Read the primary device */
ret = tasdevice_dev_bulk_read(tas_dev, 0, reg, data, 4);
if (ret) {
dev_err(tas_dev->dev, "%s, get AMP vol error\n", __func__);
- goto out;
+ return ret;
}
target = get_unaligned_be32(&data[0]);
@@ -868,8 +868,7 @@ static int tasdevice_digital_gain_get(
/* find out the member same as or closer to the current volume */
ucontrol->value.integer.value[0] =
abs(target - ar_l) <= abs(target - ar_r) ? l : r;
-out:
- mutex_unlock(&tas_dev->codec_lock);
+
return 0;
}
@@ -889,13 +888,13 @@ static int tasdevice_digital_gain_put(
unsigned char data[4];
vol = clamp(vol, 0, max);
- mutex_lock(&tas_dev->codec_lock);
+ guard(mutex)(&tas_dev->codec_lock);
/* Read the primary device */
ret = tasdevice_dev_bulk_read(tas_dev, 0, reg, data, 4);
if (ret) {
dev_err(tas_dev->dev, "%s, get AMP vol error\n", __func__);
rc = -1;
- goto out;
+ return rc;
}
volrd = get_unaligned_be32(&data[0]);
@@ -903,7 +902,7 @@ static int tasdevice_digital_gain_put(
if (volrd == volwr) {
rc = 0;
- goto out;
+ return rc;
}
for (i = 0; i < tas_dev->ndev; i++) {
@@ -919,8 +918,7 @@ static int tasdevice_digital_gain_put(
if (status)
rc = -1;
-out:
- mutex_unlock(&tas_dev->codec_lock);
+
return rc;
}
@@ -1766,12 +1764,10 @@ static int tasdevice_dapm_event(struct snd_soc_dapm_widget *w,
int state = 0;
/* Codec Lock Hold */
- mutex_lock(&tas_priv->codec_lock);
+ guard(mutex)(&tas_priv->codec_lock);
if (event == SND_SOC_DAPM_PRE_PMD)
state = 1;
tasdevice_tuning_switch(tas_priv, state);
- /* Codec Lock Release*/
- mutex_unlock(&tas_priv->codec_lock);
return 0;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Krzysztof Kozlowski @ 2026-06-17 10:49 UTC (permalink / raw)
To: Frieder Schrempf
Cc: 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, Frieder Schrempf
In-Reply-To: <20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-1-cb7f3698c3e6@kontron.de>
On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> Some SoCs like the i.MX9 family allow full access to the fuses only
> through the secure enclave firmware API. Add a property to reference
> the secure enclave node and let the driver use the API.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> index a8076d0e2737..14a6429f4a4c 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> @@ -53,6 +53,10 @@ properties:
> reg:
> maxItems: 1
>
> + secure-enclave:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: A phandle to the secure enclave node
Two things here:
1. Here you describe what for is that phandle, how it is used by the
hardware. Currently the description repeats the property name and type,
so not much useful.
2. If you access OTP via firmware, then this is completely different
interface than MMIO, thus:
A. reg is not appropriate
B. Device is very different thus it has different compatible and I even
claim should be in different binding. Devices having completely
different SW interface should not be in the same binding, at least
usually.
If any of above is not accurate, then your commit msg should answer why
and give some background.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] dt-bindings: arm: mediatek: Add MT8127 Amazon ford
From: Krzysztof Kozlowski @ 2026-06-17 10:55 UTC (permalink / raw)
To: Zakariya Hadrami
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, linux-watchdog
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-4-d02ad15ac359@proton.me>
On Wed, Jun 17, 2026 at 11:20:13AM +0900, Zakariya Hadrami wrote:
> Add entry for the MT8127 based Amazon ford tablet.
>
> Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
> ---
> Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 382d0eb4d0af..5ddc79689df9 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -124,6 +124,10 @@ properties:
> - enum:
> - mediatek,mt8127-moose
> - const: mediatek,mt8127
> + - items:
> + - enum:
> + - amazon,ford
And it is not part of existing enum because?
> + - const: mediatek,mt8127
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/5] ARM: dts: mediatek: Add basic support for Amazon ford board
From: Krzysztof Kozlowski @ 2026-06-17 10:55 UTC (permalink / raw)
To: Zakariya Hadrami
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, linux-watchdog
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-3-d02ad15ac359@proton.me>
On Wed, Jun 17, 2026 at 11:20:12AM +0900, Zakariya Hadrami wrote:
> This tablet uses a MediaTek MT8127 system-on-chip with 1GB of RAM.
> It can currently boot into initramfs with a working UART and
> Simple Framebuffer using already initialized panel by the bootloader.
>
> Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
> ---
> arch/arm/boot/dts/mediatek/Makefile | 1 +
> arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 +++++++++++++++++++++++
> 2 files changed, 47 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mediatek/Makefile b/arch/arm/boot/dts/mediatek/Makefile
> index 37c4cded0eae..a610bc75c7d9 100644
> --- a/arch/arm/boot/dts/mediatek/Makefile
> +++ b/arch/arm/boot/dts/mediatek/Makefile
> @@ -14,5 +14,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt7623n-rfb-emmc.dtb \
> mt7623n-bananapi-bpi-r2.dtb \
> mt7629-rfb.dtb \
> + mt8127-amazon-ford.dtb \
> mt8127-moose.dtb \
> mt8135-evbp1.dtb
> diff --git a/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
> new file mode 100644
> index 000000000000..21bdab0e43f8
> --- /dev/null
> +++ b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +#include "mt8127.dtsi"
> +
> +/ {
> + model = "MediaTek MT8127 Amazon Ford";
> + compatible = "amazon,ford", "mediatek,mt8127";
Please organize the patch documenting the compatible (DT bindings)
before the patch using that compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/5] dt-bindings: watchdog: mediatek: Add MT8127
From: Krzysztof Kozlowski @ 2026-06-17 10:56 UTC (permalink / raw)
To: Zakariya Hadrami
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, linux-watchdog
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-5-d02ad15ac359@proton.me>
On Wed, Jun 17, 2026 at 11:20:14AM +0900, Zakariya Hadrami wrote:
> Add entry for MT8127 SoC's watchdog which is compatible with MT6589's
> one.
>
> Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
> ---
> Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
<form letter>
This is an automated instruction, just in case, because many review
tags are being ignored. If you know the process, just skip it entirely
(please do not feel offended by me posting it here - no bad intentions
intended, no patronizing, I just want to avoid wasted efforts). If you
do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here ('b4 trailers -u ...').
However, there's no need to repost patches *only* to add the tags. The
upstream maintainer will do that for tags received on the version they
apply.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/process/submitting-patches.rst#L591
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 15/78] ASoC: codecs: cs42l43: Use guard() for mutex locks
From: Charles Keepax @ 2026-06-17 10:57 UTC (permalink / raw)
To: phucduc.bui
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Cheng-Yi Chiang, Tzung-Bi Shih, Guenter Roeck, Benson Leung,
David Rhodes, Richard Fitzgerald, povik+lin, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260617103235.449609-16-phucduc.bui@gmail.com>
On Wed, Jun 17, 2026 at 05:31:32PM +0700, phucduc.bui@gmail.com wrote:
> 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>
> ---
> @@ -913,17 +908,13 @@ int cs42l43_jack_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *u
> if (override >= e->items)
> return -EINVAL;
>
> - mutex_lock(&priv->jack_lock);
> + guard(mutex)(&priv->jack_lock);
I believe you have to use scoped_guard here, as there is a return
from the function above, if memory serves it attempts to release
the mutex on that path despite it being above the guard.
Be worth having a quick scan through the rest of the series for
this as well.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v3] clk: mvebu: ap-cpu: fix missing clk_put() in ap_cpu_clock_probe()
From: Brian Masney @ 2026-06-17 11:00 UTC (permalink / raw)
To: Wentao Liang
Cc: andrew, gregory.clement, sebastian.hesselbarth, mturquette, sboyd,
linux-arm-kernel, linux-clk, linux-kernel
In-Reply-To: <20260617014126.1716291-1-vulab@iscas.ac.cn>
On Wed, Jun 17, 2026 at 01:41:26AM +0000, Wentao Liang wrote:
> The function ap_cpu_clock_probe() calls of_clk_get() to obtain a
> reference to the parent clock for each CPU cluster, but it never
> releases it with clk_put(). The returned clk is used only to read
> the parent's name via __clk_get_name(), and the reference is leaked
> on every successful cluster initialization as well as on the error
> path when devm_clk_hw_register() fails.
>
> Rather than adding clk_put() calls, replace the of_clk_get() +
> __clk_get_name() pattern with of_clk_get_parent_name(), which is
> the intended API for this use case and handles the reference
> counting internally. This matches the pattern already used by the
> sibling drivers clk-cpu.c and clk-corediv.c.
>
> Fixes: f756e362d9384 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Brian Masney <bmasney@redhat.com>
For the future, if someone leaves a tag like Reviewed-by, or Tested-by,
then include it with your next version, unless something major changes
with the code. Don't post another version since Stephen's automation
will pick up my tag when he merges this.
Brian
^ permalink raw reply
* Re: [PATCH v9 9/9] perf test: Add Arm CoreSight callchain test
From: Leo Yan @ 2026-06-17 11:11 UTC (permalink / raw)
To: James Clark
Cc: linux-arm-kernel, coresight, linux-perf-users,
Arnaldo Carvalho de Melo, John Garry, Will Deacon, Mike Leach,
Suzuki K Poulose, Namhyung Kim, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov
In-Reply-To: <00183ce3-e387-4ca3-9eb8-67aa6a1221e5@linaro.org>
On Wed, Jun 17, 2026 at 09:38:42AM +0100, James Clark wrote:
[...]
> > +noinline void callchain_do_syscall(void)
> > +{
> > + syscall(SYS_getpid);
>
> I get this error when compiling for x86, but it works on Arm:
>
> tests/workloads/callchain.c:17:10: error: use of undeclared identifier
> 'SYS_getpid'; did you mean '__getpgid'?
> syscall(SYS_getpid);
> ^~~~~~~~~~
> __getpgid
> /usr/include/unistd.h:659:16: note: '__getpgid' declared here
> extern __pid_t __getpgid (__pid_t __pid) __THROW;
Thanks for finding this.
This is not the issue for program itself actually, it contains
tools/arch/x86/include/uapi/asm/unistd_64.h rather than uAPI headers
provided in toolchain or kernel.
At current stage, we can simply change to syscall(SYS_gettid) to
workaround the issue.
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Michael Walle @ 2026-06-17 11:19 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], Bartosz Golaszewski,
Andy Shevchenko
Cc: linusw@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <61c053a5a8e6461f9e6fcd40b6b5064d@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]
Hi,
On Wed Jun 17, 2026 at 11:54 AM CEST, Yu-Chun Lin [林祐君] wrote:
> Hi Michael,
>
>> Hi,
>>
>> On Wed Jun 17, 2026 at 10:36 AM CEST, Yu-Chun Lin [林祐君] wrote:
>>>>>>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot
>>>>>>> retrieve the gpio_chip instantiated inside gpio-regmap.c to
>>>>>>> fulfill these requirements in our
>>>>>>> map() function.
>>>>
>>>> Why is gpiochip_irq_reqres() called in the first place? Isn't that
>>>> only called if the irq handling is set up via gc->irq.chip and not
>>>> via
>>>> gpiochip_irqchip_add_domain() like in gpio-regmap?
>>>>
>>>
>>> The panic was caused by my driver including
>>> 'GPIOCHIP_IRQ_RESOURCE_HELPERS', which forced the call to 'gpiochip_irq_reqres()' and crashed.
>>
>> But why did you use it if your irq domain isn't managed by the gpiolib, but rather your own >irq domain? Before going with option #3 I'd double check if that is correct in your driver.
>>
>> -michael
>
> Do you mean that a custom IRQ domain shouldn't be mixed with gpiolib features like
> 'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
Honestly, I'm not sure. I've never done anything with irq domains
except for using the regmap_irq_chip. But from what I can tell is
that GPIOCHIP_IRQ_RESOURCE_HELPERS are tied to the handling with
gc->irq.chip, which isn't used at all if you add the domain via
gpiochip_irqchip_add_domain(). Please correct me if I'm wrong
though.
-michael
> Additional information: our GPIO controller receives 3 separate interrupt lines.
> Because the standard 'regmap_irq_chip' mechanism in 'gpio-regmap' does not support
> this multi-line hardware design, we are forced to create our own IRQ domain and pass
> it via 'config->irq_domain'.
>
> Given this constraint (that we must use our own IRQ domain), are you suggesting
> that we should implement our own 'irq_request_resources' and
> 'irq_release_resources' callbacks instead of relying on
> 'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
>
> But if that is the case, we would much prefer to let the core gpiolib handle
> these resource and state management tasks for us *as proposed in option 3), rather
> than duplicating the effort in our driver.
>
> Best Regards,
> Yu-Chun
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] ASoC: rockchip: Use guard() for spin locks
From: Nicolas Frattaroli @ 2026-06-17 11:24 UTC (permalink / raw)
To: Heiko Stuebner, Liam Girdwood, phucduc.bui, Mark Brown
Cc: Nicolas Frattaroli, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <178120760640.484538.12942087225448845771.b4-ty@b4>
On Thursday, 11 June 2026 21:53:26 Central European Summer Time Mark Brown wrote:
> On Thu, 04 Jun 2026 10:35:50 +0700, phucduc.bui@gmail.com wrote:
> > ASoC: rockchip: Use guard() for spin locks
> >
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > Hi all,
> >
> > This series converts spinlock handling in the Rockchip sound drivers
> > to use guard() helpers.
> > The changes are code cleanup only and should have no functional impact.
> >
> > [...]
>
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
>
> Thanks!
FWIW, the SAI patch wasn't sent to the proper maintainer e-mail
for it which is why I didn't notice this series at all until now,
and the whole thing is pointless churn that wasn't even tested.
From a cursory glance, whatever LLM was pointed at this and decided
to make the output my problem also didn't do a good job, the scoped
indentation of rockchip_sai_runtime_suspend seems pointless because
it could've been replaced by a pm guard followed by a spinlock guard,
without an additional level of indentation, and `if (ret == 0) {` is
not kernel style.
It's not worth the revert but it sucks that I have to now set up a
new lei search for all the drivers I am supposed to receive mail for
because vibecoders can't be bothered to run get_maintainers as they
pad their CV with nonsense like this.
>
> [1/3] ASoC: rockchip: rockchip_i2s: Use guard() for spin locks
> https://git.kernel.org/broonie/sound/c/4bda5af16920
> [2/3] ASoC: rockchip: i2s-tdm: Use guard() for spin locks
> https://git.kernel.org/broonie/sound/c/ec22437fc41a
> [3/3] ASoC: rockchip: rockchip_sai: Use guard() for spin locks
> https://git.kernel.org/broonie/sound/c/f7fe9f707360
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
>
>
^ permalink raw reply
* Re: [PATCH net-next v7 2/2] net: ti: icssg-prueth: Add ethtool ops for Frame Preemption MAC Merge
From: Meghana Malladi @ 2026-06-17 11:25 UTC (permalink / raw)
To: MD Danish Anwar, Jakub Kicinski
Cc: elfring, haokexin, vadim.fedorenko, devnexen, horms,
jacob.e.keller, arnd, basharath, afd, parvathi, vladimir.oltean,
rogerq, pabeni, edumazet, davem, andrew+netdev, linux-arm-kernel,
netdev, linux-kernel, srk, vigneshr
In-Reply-To: <a62d5243-d641-48e7-a1f5-88150513be48@ti.com>
On 6/17/26 10:58, MD Danish Anwar wrote:
> Meghana,
>
> On 16/06/26 6:24 pm, Meghana Malladi wrote:
>> Hi Jakub,
>>
>> On 6/16/26 05:09, Jakub Kicinski wrote:
>>> On Mon, 15 Jun 2026 16:10:41 -0700 Jakub Kicinski wrote:
>>>>> diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/
>>>>> net/ethernet/ti/icssg/icssg_stats.h
>>>>> index 5ec0b38e0c67..8073deac35c3 100644
>>>>> --- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>>>> +++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>>>> @@ -189,6 +187,11 @@ static const struct icssg_pa_stats
>>>>> icssg_all_pa_stats[] = {
>>>>> ICSSG_PA_STATS(FW_INF_DROP_PRIOTAGGED),
>>>>> ICSSG_PA_STATS(FW_INF_DROP_NOTAG),
>>>>> ICSSG_PA_STATS(FW_INF_DROP_NOTMEMBER),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_BAD_FRAG),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_ASSEMBLY_ERR),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_FRAG_CNT_TX),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_ASSEMBLY_OK),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_FRAG_CNT_RX),
>>>>> ICSSG_PA_STATS(FW_RX_EOF_SHORT_FRMERR),
>>>>> ICSSG_PA_STATS(FW_RX_B0_DROP_EARLY_EOF),
>>>>> ICSSG_PA_STATS(FW_TX_JUMBO_FRM_CUTOFF),
>>>>
>>>> [Medium]
>>>> Are these five new entries duplicating values that already have a
>>>> standard uAPI?
>>>>
>>>> The same five firmware counters are exposed through the new
>>>> .get_mm_stats callback as the standardized MAC Merge stats
>>>> (MACMergeFrameAssOkCount, MACMergeFrameAssErrorCount,
>>>> MACMergeFragCountRx,
>>>> MACMergeFragCountTx, MACMergeFrameSmdErrorCount in struct
>>>> ethtool_mm_stats), and adding them to icssg_all_pa_stats[] also
>>>> publishes them via emac_get_strings() / emac_get_ethtool_stats() as
>>>> ethtool -S strings.
>>>>
>>>> Documentation/networking/statistics.rst describes ethtool -S as the
>>>> private-driver-stats interface; counters that have a standard uAPI are
>>>> expected to flow only through that uAPI.
>>>>
>>>> Could the firmware-register lookup table used by emac_get_stat_by_name()
>>>> be separated from the ethtool -S string table, so the new preemption
>>>> counters feed get_mm_stats without also showing up under ethtool -S?
>>>
>>> This -- not sure about the other complaints but this one looks legit.
>>
>> I agree that this is legit, but right now there is no other place holder
>> other than pa stats to put the mac merge firmware counters. I believe
>
> You can put a boolean is_standard_stats. Only those where
> is_standard_stats=false will be populated via ethtool. Others will be
> populated via the standard interface.
>
> Look at icssg_miig_stats for reference.
>
Sure, since you were already doing some refactoring w.r.t HSR standard
stats I thought this could also be covered there.
I will send out another version addressing this then.
>> the effort needs to go in re-structuring the hardware and firmware stats
>> implementation to address this issue.
>>
>
^ permalink raw reply
* Re: [PATCH net 4/4] net: ti: icssg: Fix XSK zero copy TX during application wakeup
From: Meghana Malladi @ 2026-06-17 11:31 UTC (permalink / raw)
To: Jakub Kicinski
Cc: diogo.ivo, haokexin, vadim.fedorenko, devnexen, horms,
jacob.e.keller, sdf, john.fastabend, hawk, daniel, ast, pabeni,
edumazet, davem, andrew+netdev, bpf, linux-kernel, netdev,
linux-arm-kernel, srk, Vignesh Raghavendra, Roger Quadros,
danishanwar
In-Reply-To: <20260616081954.0d12aa13@kernel.org>
On 6/16/26 20:49, Jakub Kicinski wrote:
> On Tue, 16 Jun 2026 16:41:00 +0530 Meghana Malladi wrote:
>> On 6/16/26 04:51, Jakub Kicinski wrote:
>>> On Fri, 12 Jun 2026 00:27:44 +0530 Meghana Malladi wrote:
>>>> @@ -169,9 +169,6 @@ static int emac_xsk_xmit_zc(struct prueth_emac *emac,
>>>>
>>>> num_tx++;
>>>> }
>>>> -
>>>> - xsk_tx_release(tx_chn->xsk_pool);
>>>> - return num_tx;
>>>
>>> Why are you deleting this?
>>>
>>
>> xsk_sendmsg() also calls this without an rcu-lock when transmitting the
>> packets if the xmit was successful, so I was assuming it is not required
>> and I removed this.
>
> I think you still need it. Besides, seems like a separate cleanup.
>
Okay, I will add it back then.
>>>> void prueth_xmit_free(struct prueth_tx_chn *tx_chn,
>>>> @@ -279,9 +276,6 @@ int emac_tx_complete_packets(struct prueth_emac *emac, int chn,
>>>> num_tx++;
>>>> }
>>>>
>>>> - if (!num_tx)
>>>> - return 0;
>>>
>>> Does something prevent us from running all this code if budget is 0?
>>> If budget is 0 we can complete normal Tx with skbs but we must
>>> not touch any AF-XDP related state.
>>
>> Can you elaborate more, I couldn't interpret your comment here
>
> netpoll may call napi from any context, including from IRQ.
> It uses budget of 0 to indicate that it's trying to only reap tx
> completions, without doing any Rx or XDP work. XDPs can't be called
> from IRQ context.
>
Ah I wasn't aware of this, I will add a check to ensure AF_XDP runs only
when budget > 0 then.
>>>> netif_txq = netdev_get_tx_queue(ndev, chn);
>>>> netdev_tx_completed_queue(netif_txq, num_tx, total_bytes);
>>>>
>>>> @@ -306,7 +300,9 @@ int emac_tx_complete_packets(struct prueth_emac *emac, int chn,
>>>>
>>>> netif_txq = netdev_get_tx_queue(ndev, chn);
>>>> txq_trans_cond_update(netif_txq);
>>>
>>> This looks misplaced, now we will hit it even if we didn't complete
>>> or submit any Tx.
>>
>> This code needs to be hit for packet transmission in zero copy mode.
>> emac_xsk_xmit_zc() submits the packets to the DMA in NAPI context,
>> when application wakes up the driver and triggers NAPI. Once DMA
>> transfer is done, irq gets triggered NAPI gets called which will handle
>> the tx packet completion + submit next Tx batch packets to the DMA.
>>
>> if (tx_chn->xsk_pool) -> check ensure this hits and runs for zero copy
>> only. Also above check (!num_tx) returns early during the application
>> wakeup (where budget is zero), hence it is removed.
>
> I'm commenting on txq_trans_cond_update(), you're calling it
> effectively on every NAPI call when XSK is bound, whether
> Tx is making progress or not.
Ok got it, but I wonder if it will hurt in anyway to call this even when
there are no Tx completions.
Nonetheless, I will move this inside xsk_frames_done check.
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Frieder Schrempf @ 2026-06-17 11:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Frieder Schrempf
Cc: 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: <20260617-prodigious-private-inchworm-beae1e@quoll>
On 17.06.26 12:49, Krzysztof Kozlowski wrote:
> On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> Some SoCs like the i.MX9 family allow full access to the fuses only
>> through the secure enclave firmware API. Add a property to reference
>> the secure enclave node and let the driver use the API.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>> ---
>> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>> index a8076d0e2737..14a6429f4a4c 100644
>> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>> @@ -53,6 +53,10 @@ properties:
>> reg:
>> maxItems: 1
>>
>> + secure-enclave:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description: A phandle to the secure enclave node
>
> Two things here:
> 1. Here you describe what for is that phandle, how it is used by the
> hardware. Currently the description repeats the property name and type,
> so not much useful.
Ok, agree.
>
> 2. If you access OTP via firmware, then this is completely different
> interface than MMIO, thus:
> A. reg is not appropriate
> B. Device is very different thus it has different compatible and I even
> claim should be in different binding. Devices having completely
> different SW interface should not be in the same binding, at least
> usually.
>
> If any of above is not accurate, then your commit msg should answer why
> and give some background.
Thanks for the feedback!
The driver currently uses the limited MMIO (FSB) interface to access the
OTPs. The intention is to support the firmware interface alongside the
MMIO interface so the driver can pick the interface that is available
(firmware might not be loaded) and fallback to MMIO.
Following your argument would mean a driver deciding by itself which
interface to use at runtime is not something we want to have in general,
right?
In turn this would mean we need two drivers, or at least two
compatibles/bindings for something that is effectively the same hardware.
Actually, my first RFC approach [1] was to create a separate driver. But
in the end it seemed very weird to have two drivers and two DT nodes for
the same hardware block. Also I have no idea what happens if both
interfaces are used at the same time.
The other idea from back then was to replace the MMIO (FSB) interface
with ELE, but this would mean that we rely on the proprietary ELE
firmware to be available for simple things like reading a MAC address,
which is not desirable either, I guess.
In which direction should I move on with this?
[1]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250416142715.1042363-1-frieder@fris.de/
^ permalink raw reply
* [PATCH] Revert "ASoC: rockchip: rockchip_sai: Use guard() for spin locks"
From: Nicolas Frattaroli @ 2026-06-17 11:46 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Heiko Stuebner
Cc: bui duc phuc, linux-rockchip, linux-sound, linux-arm-kernel,
linux-kernel, kernel, Nicolas Frattaroli
This reverts commit f7fe9f7073602958d6b63cc58a144094533377fa.
This is very noisy pointless churn that was not tested by the submitter,
nor was it addressed to the driver's maintainer. It mixes unrelated
whitespace changes (eliminating the blank line between the includes -
why?) with hard to review diffs that add a whole indentation level to
the function for no benefit, while also not following kernel code style
by doing stuff like "ret == 0".
The driver is better off without these changes, and they're not worth
the time to validate whether they really do make no functional changes.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
sound/soc/rockchip/rockchip_sai.c | 262 +++++++++++++++++++-------------------
1 file changed, 133 insertions(+), 129 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
index a195e96fed0a..ed393e5034a4 100644
--- a/sound/soc/rockchip/rockchip_sai.c
+++ b/sound/soc/rockchip/rockchip_sai.c
@@ -18,6 +18,7 @@
#include <sound/pcm_params.h>
#include <sound/dmaengine_pcm.h>
#include <sound/tlv.h>
+
#include "rockchip_sai.h"
#define DRV_NAME "rockchip-sai"
@@ -215,12 +216,14 @@ static void rockchip_sai_xfer_clk_stop_and_wait(struct rk_sai_dev *sai, unsigned
static int rockchip_sai_runtime_suspend(struct device *dev)
{
struct rk_sai_dev *sai = dev_get_drvdata(dev);
+ unsigned long flags;
rockchip_sai_fsync_lost_detect(sai, 0);
rockchip_sai_fsync_err_detect(sai, 0);
- scoped_guard(spinlock_irqsave, &sai->xfer_lock)
- rockchip_sai_xfer_clk_stop_and_wait(sai, NULL);
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+ rockchip_sai_xfer_clk_stop_and_wait(sai, NULL);
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
regcache_cache_only(sai->regmap, true);
/*
@@ -480,6 +483,7 @@ static int rockchip_sai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
struct rk_sai_dev *sai = snd_soc_dai_get_drvdata(dai);
unsigned int mask = 0, val = 0;
unsigned int clk_gates;
+ unsigned long flags;
int ret = 0;
pm_runtime_get_sync(dai->dev);
@@ -495,56 +499,56 @@ static int rockchip_sai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
sai->is_master_mode = false;
break;
default:
- pm_runtime_put(dai->dev);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_pm_put;
}
- scoped_guard(spinlock_irqsave, &sai->xfer_lock) {
- rockchip_sai_xfer_clk_stop_and_wait(sai, &clk_gates);
- if (sai->initialized) {
- if (sai->has_capture && sai->has_playback)
- rockchip_sai_xfer_stop(sai, -1);
- else if (sai->has_capture)
- rockchip_sai_xfer_stop(sai, SNDRV_PCM_STREAM_CAPTURE);
- else
- rockchip_sai_xfer_stop(sai, SNDRV_PCM_STREAM_PLAYBACK);
- } else {
- rockchip_sai_clear(sai, 0);
- sai->initialized = true;
- }
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+ rockchip_sai_xfer_clk_stop_and_wait(sai, &clk_gates);
+ if (sai->initialized) {
+ if (sai->has_capture && sai->has_playback)
+ rockchip_sai_xfer_stop(sai, -1);
+ else if (sai->has_capture)
+ rockchip_sai_xfer_stop(sai, SNDRV_PCM_STREAM_CAPTURE);
+ else
+ rockchip_sai_xfer_stop(sai, SNDRV_PCM_STREAM_PLAYBACK);
+ } else {
+ rockchip_sai_clear(sai, 0);
+ sai->initialized = true;
+ }
- regmap_update_bits(sai->regmap, SAI_CKR, mask, val);
-
- mask = SAI_CKR_CKP_MASK | SAI_CKR_FSP_MASK;
- switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
- case SND_SOC_DAIFMT_NB_NF:
- val = SAI_CKR_CKP_NORMAL | SAI_CKR_FSP_NORMAL;
- break;
- case SND_SOC_DAIFMT_NB_IF:
- val = SAI_CKR_CKP_NORMAL | SAI_CKR_FSP_INVERTED;
- break;
- case SND_SOC_DAIFMT_IB_NF:
- val = SAI_CKR_CKP_INVERTED | SAI_CKR_FSP_NORMAL;
- break;
- case SND_SOC_DAIFMT_IB_IF:
- val = SAI_CKR_CKP_INVERTED | SAI_CKR_FSP_INVERTED;
- break;
- default:
- ret = -EINVAL;
- break;
- }
+ regmap_update_bits(sai->regmap, SAI_CKR, mask, val);
- if (ret == 0) {
- regmap_update_bits(sai->regmap, SAI_CKR, mask, val);
- rockchip_sai_fmt_create(sai, fmt);
- }
-
- if (clk_gates)
- regmap_update_bits(sai->regmap, SAI_XFER,
- SAI_XFER_CLK_MASK | SAI_XFER_FSS_MASK,
- clk_gates);
+ mask = SAI_CKR_CKP_MASK | SAI_CKR_FSP_MASK;
+ switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+ case SND_SOC_DAIFMT_NB_NF:
+ val = SAI_CKR_CKP_NORMAL | SAI_CKR_FSP_NORMAL;
+ break;
+ case SND_SOC_DAIFMT_NB_IF:
+ val = SAI_CKR_CKP_NORMAL | SAI_CKR_FSP_INVERTED;
+ break;
+ case SND_SOC_DAIFMT_IB_NF:
+ val = SAI_CKR_CKP_INVERTED | SAI_CKR_FSP_NORMAL;
+ break;
+ case SND_SOC_DAIFMT_IB_IF:
+ val = SAI_CKR_CKP_INVERTED | SAI_CKR_FSP_INVERTED;
+ break;
+ default:
+ ret = -EINVAL;
+ goto err_xfer_unlock;
}
+ regmap_update_bits(sai->regmap, SAI_CKR, mask, val);
+
+ rockchip_sai_fmt_create(sai, fmt);
+
+err_xfer_unlock:
+ if (clk_gates)
+ regmap_update_bits(sai->regmap, SAI_XFER,
+ SAI_XFER_CLK_MASK | SAI_XFER_FSS_MASK,
+ clk_gates);
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
+err_pm_put:
pm_runtime_put(dai->dev);
return ret;
@@ -560,6 +564,7 @@ static int rockchip_sai_hw_params(struct snd_pcm_substream *substream,
unsigned int ch_per_lane, slot_width;
unsigned int val, fscr, reg;
unsigned int lanes, req_lanes;
+ unsigned long flags;
int ret = 0;
if (!rockchip_sai_stream_valid(substream, dai))
@@ -586,8 +591,8 @@ static int rockchip_sai_hw_params(struct snd_pcm_substream *substream,
dev_err(sai->dev, "not enough lanes (%d) for requested number of %s channels (%d)\n",
lanes, reg == SAI_TXCR ? "playback" : "capture",
params_channels(params));
- pm_runtime_put(sai->dev);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_pm_put;
} else {
lanes = req_lanes;
}
@@ -613,88 +618,84 @@ static int rockchip_sai_hw_params(struct snd_pcm_substream *substream,
val = SAI_XCR_VDW(32);
break;
default:
- pm_runtime_put(sai->dev);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_pm_put;
}
val |= SAI_XCR_CSR(lanes);
- scoped_guard(spinlock_irqsave, &sai->xfer_lock) {
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+
+ regmap_update_bits(sai->regmap, reg, SAI_XCR_VDW_MASK | SAI_XCR_CSR_MASK, val);
- regmap_update_bits(sai->regmap, reg, SAI_XCR_VDW_MASK | SAI_XCR_CSR_MASK, val);
+ if (!sai->is_tdm)
+ regmap_update_bits(sai->regmap, reg, SAI_XCR_SBW_MASK,
+ SAI_XCR_SBW(params_physical_width(params)));
- if (!sai->is_tdm)
- regmap_update_bits(sai->regmap, reg, SAI_XCR_SBW_MASK,
- SAI_XCR_SBW(params_physical_width(params)));
+ regmap_read(sai->regmap, reg, &val);
- regmap_read(sai->regmap, reg, &val);
+ slot_width = SAI_XCR_SBW_V(val);
+ ch_per_lane = params_channels(params) / lanes;
- slot_width = SAI_XCR_SBW_V(val);
- ch_per_lane = params_channels(params) / lanes;
+ regmap_update_bits(sai->regmap, reg, SAI_XCR_SNB_MASK,
+ SAI_XCR_SNB(ch_per_lane));
- regmap_update_bits(sai->regmap, reg, SAI_XCR_SNB_MASK,
- SAI_XCR_SNB(ch_per_lane));
+ fscr = SAI_FSCR_FW(sai->fw_ratio * slot_width * ch_per_lane);
- fscr = SAI_FSCR_FW(sai->fw_ratio * slot_width * ch_per_lane);
+ switch (sai->fpw) {
+ case FPW_ONE_BCLK_WIDTH:
+ fscr |= SAI_FSCR_FPW(1);
+ break;
+ case FPW_ONE_SLOT_WIDTH:
+ fscr |= SAI_FSCR_FPW(slot_width);
+ break;
+ case FPW_HALF_FRAME_WIDTH:
+ fscr |= SAI_FSCR_FPW(sai->fw_ratio * slot_width * ch_per_lane / 2);
+ break;
+ default:
+ dev_err(sai->dev, "Invalid Frame Pulse Width %d\n", sai->fpw);
+ ret = -EINVAL;
+ goto err_xfer_unlock;
+ }
- switch (sai->fpw) {
- case FPW_ONE_BCLK_WIDTH:
- fscr |= SAI_FSCR_FPW(1);
- break;
- case FPW_ONE_SLOT_WIDTH:
- fscr |= SAI_FSCR_FPW(slot_width);
- break;
- case FPW_HALF_FRAME_WIDTH:
- fscr |= SAI_FSCR_FPW(sai->fw_ratio * slot_width * ch_per_lane / 2);
- break;
- default:
- dev_err(sai->dev, "Invalid Frame Pulse Width %d\n", sai->fpw);
+ regmap_update_bits(sai->regmap, SAI_FSCR,
+ SAI_FSCR_FW_MASK | SAI_FSCR_FPW_MASK, fscr);
+
+ if (sai->is_master_mode) {
+ bclk_rate = sai->fw_ratio * slot_width * ch_per_lane * params_rate(params);
+ ret = clk_set_rate(sai->mclk, sai->mclk_rate);
+ if (ret) {
+ dev_err(sai->dev, "Failed to set mclk to %u: %pe\n",
+ sai->mclk_rate, ERR_PTR(ret));
+ goto err_xfer_unlock;
+ }
+
+ mclk_rate = clk_get_rate(sai->mclk);
+ if (mclk_rate < bclk_rate) {
+ dev_err(sai->dev, "Mismatch mclk: %u, at least %u\n",
+ mclk_rate, bclk_rate);
ret = -EINVAL;
- break;
+ goto err_xfer_unlock;
}
- if (ret == 0) {
- regmap_update_bits(sai->regmap, SAI_FSCR,
- SAI_FSCR_FW_MASK | SAI_FSCR_FPW_MASK, fscr);
-
- if (sai->is_master_mode) {
- bclk_rate = sai->fw_ratio * slot_width *
- ch_per_lane * params_rate(params);
- ret = clk_set_rate(sai->mclk, sai->mclk_rate);
- if (ret)
- dev_err(sai->dev, "Failed to set mclk to %u: %pe\n",
- sai->mclk_rate, ERR_PTR(ret));
- else {
- mclk_rate = clk_get_rate(sai->mclk);
- if (mclk_rate < bclk_rate) {
- dev_err(sai->dev, "Mismatch mclk: %u, at least %u\n",
- mclk_rate, bclk_rate);
- ret = -EINVAL;
- } else {
-
- div_bclk = DIV_ROUND_CLOSEST(mclk_rate, bclk_rate);
- mclk_req_rate = bclk_rate * div_bclk;
-
- if (mclk_rate <
- mclk_req_rate - CLK_SHIFT_RATE_HZ_MAX ||
- mclk_rate >
- mclk_req_rate + CLK_SHIFT_RATE_HZ_MAX) {
- dev_err(sai->dev,
- "Mismatch mclk: %u, expected %u (+/- %dHz)\n",
- mclk_rate, mclk_req_rate,
- CLK_SHIFT_RATE_HZ_MAX);
- ret = -EINVAL;
- } else
- regmap_update_bits(sai->regmap,
- SAI_CKR,
- SAI_CKR_MDIV_MASK,
- SAI_CKR_MDIV(div_bclk));
- }
- }
- }
+ div_bclk = DIV_ROUND_CLOSEST(mclk_rate, bclk_rate);
+ mclk_req_rate = bclk_rate * div_bclk;
+
+ if (mclk_rate < mclk_req_rate - CLK_SHIFT_RATE_HZ_MAX ||
+ mclk_rate > mclk_req_rate + CLK_SHIFT_RATE_HZ_MAX) {
+ dev_err(sai->dev, "Mismatch mclk: %u, expected %u (+/- %dHz)\n",
+ mclk_rate, mclk_req_rate, CLK_SHIFT_RATE_HZ_MAX);
+ ret = -EINVAL;
+ goto err_xfer_unlock;
}
+
+ regmap_update_bits(sai->regmap, SAI_CKR, SAI_CKR_MDIV_MASK,
+ SAI_CKR_MDIV(div_bclk));
}
+err_xfer_unlock:
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
+err_pm_put:
pm_runtime_put(sai->dev);
return ret;
@@ -704,6 +705,7 @@ static int rockchip_sai_prepare(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct rk_sai_dev *sai = snd_soc_dai_get_drvdata(dai);
+ unsigned long flags;
if (!rockchip_sai_stream_valid(substream, dai))
return 0;
@@ -724,12 +726,13 @@ static int rockchip_sai_prepare(struct snd_pcm_substream *substream,
* udelay falls short.
*/
udelay(20);
- scoped_guard(spinlock_irqsave, &sai->xfer_lock)
- regmap_update_bits(sai->regmap, SAI_XFER,
- SAI_XFER_CLK_MASK |
- SAI_XFER_FSS_MASK,
- SAI_XFER_CLK_EN |
- SAI_XFER_FSS_EN);
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+ regmap_update_bits(sai->regmap, SAI_XFER,
+ SAI_XFER_CLK_MASK |
+ SAI_XFER_FSS_MASK,
+ SAI_XFER_CLK_EN |
+ SAI_XFER_FSS_EN);
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
}
rockchip_sai_fsync_lost_detect(sai, 1);
@@ -912,6 +915,7 @@ static int rockchip_sai_set_tdm_slot(struct snd_soc_dai *dai,
int slots, int slot_width)
{
struct rk_sai_dev *sai = snd_soc_dai_get_drvdata(dai);
+ unsigned long flags;
unsigned int clk_gates;
int sw = slot_width;
@@ -927,16 +931,16 @@ static int rockchip_sai_set_tdm_slot(struct snd_soc_dai *dai,
return -EINVAL;
pm_runtime_get_sync(dai->dev);
- scoped_guard(spinlock_irqsave, &sai->xfer_lock) {
- rockchip_sai_xfer_clk_stop_and_wait(sai, &clk_gates);
- regmap_update_bits(sai->regmap, SAI_TXCR, SAI_XCR_SBW_MASK,
- SAI_XCR_SBW(sw));
- regmap_update_bits(sai->regmap, SAI_RXCR, SAI_XCR_SBW_MASK,
- SAI_XCR_SBW(sw));
- regmap_update_bits(sai->regmap, SAI_XFER,
- SAI_XFER_CLK_MASK | SAI_XFER_FSS_MASK,
- clk_gates);
- }
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+ rockchip_sai_xfer_clk_stop_and_wait(sai, &clk_gates);
+ regmap_update_bits(sai->regmap, SAI_TXCR, SAI_XCR_SBW_MASK,
+ SAI_XCR_SBW(sw));
+ regmap_update_bits(sai->regmap, SAI_RXCR, SAI_XCR_SBW_MASK,
+ SAI_XCR_SBW(sw));
+ regmap_update_bits(sai->regmap, SAI_XFER,
+ SAI_XFER_CLK_MASK | SAI_XFER_FSS_MASK,
+ clk_gates);
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
pm_runtime_put(dai->dev);
return 0;
---
base-commit: 5b33fc6492a7b7a62359157db0f92f5b6e9af690
change-id: 20260617-sai-revert-8f7ba19962cb
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
^ permalink raw reply related
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: David Hildenbrand (Arm) @ 2026-06-17 11:50 UTC (permalink / raw)
To: Dave Hansen, Xueyuan Chen, akpm, linux-mm
Cc: linux-kernel, linux-arm-kernel, x86, catalin.marinas, will, tglx,
mingo, bp, dave.hansen, luto, peterz, hpa, ljs, liam, vbabka,
rppt, surenb, mhocko, ziy, baolin.wang, npache, ryan.roberts,
dev.jain, baohua, lance.yang, yang, jannh
In-Reply-To: <930d9121-9176-4a7b-a2d7-8224f94000d3@intel.com>
On 6/9/26 21:33, Dave Hansen wrote:
> On 6/9/26 07:37, Xueyuan Chen wrote:
>> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
>> +{
>> + return false;
>> +}
>
> This is a rather wonky function. It's going to cause all kinds of fun if
> it is used like this:
>
> arch_make_pages_readonly(syscall_table, 1);
>
> It's also kinda weird to have it return a bool, and not check that bool
> at the single call site. Some things come to mind:
>
> 1. This function needs commenting. It needs to say what it does, when
> architectures should override it and what their implementations
> should look like. It needs to be clear that this can't be used for
> anything really important. What should architectures do with alias
> mappings? Are they allowed to touch non-direct map aliases? Are they
> required to?
Yes, kerneldoc please.
> 2. The return type needs to be reconsidered. Is 'bool' even acceptable?
> Should it just be 'void' if callers can't do anything when it fails?
> 3. What should the naming be? "readonly" vs "ro". Should it have a
> "maybe" since it's kinda optional?
We're adjusting the directmap, remapping a r/w page to be r/o. I think we should
be very clear about which transition we expect+support.
Also, I rather hate the "set_memory" naming scheme ... "set_direct_map" is
clearer. Anyhow ...
Now we are throwing a "arch_make_pages_*" into the mix.
Should it really contain the "arch"?
Should it really contain the "make" ?
Why can't we just reuse set_memory_ro and pass address+nr_pages? (highmem check?
Could that be moved in there?)
Or do we want a "change_direct_map_ro()" / "remap_direct_map_ro" interface?
> 4. Should this new API be folio or page-based in the first place?
> 5. Is mm/huge_memory.c the right place to define a generic mm function,
> even a stub?
+1
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()
From: Marc Zyngier @ 2026-06-17 11:50 UTC (permalink / raw)
To: Oliver Upton, Catalin Marinas, Will Deacon, Weiming Shi
Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Jakub Kicinski, Andrew Morton, Hans Verkuil, Mark Rutland,
Kristina Martsenko, linux-arm-kernel, kvmarm, Zhong Wang,
Xuanqing Shi, stable
In-Reply-To: <20260617040820.2194831-2-bestswngs@gmail.com>
On Wed, 17 Jun 2026 12:08:21 +0800, Weiming Shi wrote:
> kvm_hyp_handle_mops() resets the single-step state machine as part of
> rewinding state for a MOPS exception by modifying vcpu_cpsr() and
> writing the result directly into hardware.
>
> In the case of nested virtualization, vcpu_cpsr() is a synthetic value
> such that the rest of KVM can deal with vEL2 cleanly. That means the
> value requires translation before being written into hardware, which is
> unfortunately missing from the MOPS handler.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()
commit: ff1022c3de46753eb7eba2f6efd990569e66ff95
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: vgic: Check the interrupt is still ours before migrating it
From: Marc Zyngier @ 2026-06-17 11:51 UTC (permalink / raw)
To: oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will, Sascha.Bischoff, jic23, timothy.hayes,
eric.auger, christoffer.dall, andre.przywara, Hyunwoo Kim
Cc: linux-arm-kernel, kvmarm
In-Reply-To: <aiHnI1mu6SGQrgnz@v4bel>
On Fri, 05 Jun 2026 05:59:15 +0900, Hyunwoo Kim wrote:
> vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating
> an interrupt to another vCPU. After reacquiring the locks it only checks
> that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq))
> before moving the interrupt, which assumes that an interrupt whose affinity
> is preserved is still queued on this vCPU's ap_list.
>
> That assumption no longer holds if the interrupt is taken off the ap_list
> while the locks are dropped. vgic_flush_pending_lpis() removes the
> interrupt from the list and sets irq->vcpu to NULL, but leaves
> enabled/pending/target_vcpu untouched. As the interrupt is still enabled
> and pending, vgic_target_oracle() returns the same target_vcpu, so the
> affinity check passes and list_del() is run a second time on an entry that
> has already been removed.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: vgic: Check the interrupt is still ours before migrating it
commit: 0074b82cdfcb5fd13710a0ac308ade68ac6f6fbe
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Handle race between interrupt affinity change and LPI disabling
From: Marc Zyngier @ 2026-06-17 11:51 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm, Marc Zyngier
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Hyunwoo Kim
In-Reply-To: <20260615181625.3029352-1-maz@kernel.org>
On Mon, 15 Jun 2026 19:16:25 +0100, Marc Zyngier wrote:
> Hyunwoo Kim reports some really bad races should the following
> situation occur:
>
> - LPI-I is pending in vcpu-B's AP list
> - vcpu-A writes to vcpu-B's RD to disable its LPIs
> - vcpu-C moves I from B to C
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: Handle race between interrupt affinity change and LPI disabling
commit: 7258770e5814f15e8308ebda82ac9acf6964ba8e
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix MODULE_LICENSE to match SPDX GPL-2.0-only identifier
From: Leon Romanovsky @ 2026-06-17 11:58 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Wayen Yan, netdev, lorenzo, horms, pabeni, kuba, edumazet,
andrew+netdev, angelogioacchino.delregno, matthias.bgg,
linux-arm-kernel, linux-mediatek
In-Reply-To: <178156440888.329386.11011872053824456703.git-patchwork-notify@kernel.org>
On Mon, Jun 15, 2026 at 11:00:08PM +0000, patchwork-bot+netdevbpf@kernel.org wrote:
> Hello:
>
> This patch was applied to netdev/net-next.git (main)
> by Jakub Kicinski <kuba@kernel.org>:
>
> On Sun, 14 Jun 2026 07:52:39 +0800 you wrote:
> > Both airoha_eth.c and airoha_npu.c declare SPDX-License-Identifier:
> > GPL-2.0-only but use MODULE_LICENSE("GPL"), which the kernel module
> > loader interprets as GPL-2.0+ (any GPL version). This mismatch causes
> > license compliance tools (FOSSology, ScanCode, etc.) to misidentify
> > the effective license as more permissive than intended.
> >
> > Replace MODULE_LICENSE("GPL") with MODULE_LICENSE("GPL v2") to
> > align with the GPL-2.0-only SPDX identifier. Per include/linux/module.h,
> > "GPL v2" maps to GPL-2.0-only, matching the source files' declared
> > license.
> >
> > [...]
>
> Here is the summary with links:
> - net: airoha: Fix MODULE_LICENSE to match SPDX GPL-2.0-only identifier
> https://git.kernel.org/netdev/net-next/c/b0d62ed16424
Jakub,
This patch doesn't fix anything. License rules are pretty clear.
Documentation/process/license-rules.rst
444 "GPL" Module is licensed under GPL version 2. This
445 does not express any distinction between
446 GPL-2.0-only or GPL-2.0-or-later. The exact
447 license information can only be determined
448 via the license information in the
449 corresponding source files.
450
451 "GPL v2" Same as "GPL". It exists for historic
452 reasons.
>
> You are awesome, thank you!
> --
> Deet-doot-dot, I am a bot.
> https://korg.docs.kernel.org/patchwork/pwbot.html
>
>
>
^ 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