* [PATCH 04/78] ASoC: codecs: arizona: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:31 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/arizona.c | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 8c683b0bb74c..77bd02def9c7 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -1158,17 +1158,16 @@ int arizona_dvfs_up(struct snd_soc_component *component, unsigned int flags)
struct arizona_priv *priv = snd_soc_component_get_drvdata(component);
int ret = 0;
- mutex_lock(&priv->dvfs_lock);
+ guard(mutex)(&priv->dvfs_lock);
if (!priv->dvfs_cached && !priv->dvfs_reqs) {
ret = arizona_dvfs_enable(component);
if (ret)
- goto err;
+ return ret;
}
priv->dvfs_reqs |= flags;
-err:
- mutex_unlock(&priv->dvfs_lock);
+
return ret;
}
EXPORT_SYMBOL_GPL(arizona_dvfs_up);
@@ -1179,7 +1178,7 @@ int arizona_dvfs_down(struct snd_soc_component *component, unsigned int flags)
unsigned int old_reqs;
int ret = 0;
- mutex_lock(&priv->dvfs_lock);
+ guard(mutex)(&priv->dvfs_lock);
old_reqs = priv->dvfs_reqs;
priv->dvfs_reqs &= ~flags;
@@ -1187,7 +1186,6 @@ int arizona_dvfs_down(struct snd_soc_component *component, unsigned int flags)
if (!priv->dvfs_cached && old_reqs && !priv->dvfs_reqs)
ret = arizona_dvfs_disable(component);
- mutex_unlock(&priv->dvfs_lock);
return ret;
}
EXPORT_SYMBOL_GPL(arizona_dvfs_down);
@@ -1199,7 +1197,7 @@ int arizona_dvfs_sysclk_ev(struct snd_soc_dapm_widget *w,
struct arizona_priv *priv = snd_soc_component_get_drvdata(component);
int ret = 0;
- mutex_lock(&priv->dvfs_lock);
+ guard(mutex)(&priv->dvfs_lock);
switch (event) {
case SND_SOC_DAPM_POST_PMU:
@@ -1222,7 +1220,6 @@ int arizona_dvfs_sysclk_ev(struct snd_soc_dapm_widget *w,
break;
}
- mutex_unlock(&priv->dvfs_lock);
return ret;
}
EXPORT_SYMBOL_GPL(arizona_dvfs_sysclk_ev);
@@ -1657,13 +1654,11 @@ static void arizona_wm5102_set_dac_comp(struct snd_soc_component *component,
{ 0x80, 0x0 },
};
- mutex_lock(&arizona->dac_comp_lock);
-
- dac_comp[1].def = arizona->dac_comp_coeff;
- if (rate >= 176400)
- dac_comp[2].def = arizona->dac_comp_enabled;
-
- mutex_unlock(&arizona->dac_comp_lock);
+ scoped_guard(mutex, &arizona->dac_comp_lock) {
+ dac_comp[1].def = arizona->dac_comp_coeff;
+ if (rate >= 176400)
+ dac_comp[2].def = arizona->dac_comp_enabled;
+ }
regmap_multi_reg_write(arizona->regmap,
dac_comp,
--
2.43.0
^ permalink raw reply related
* [PATCH 03/78] ASoC: codecs: arizona-jack: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:31 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/arizona-jack.c | 194 +++++++++++++++-----------------
1 file changed, 92 insertions(+), 102 deletions(-)
diff --git a/sound/soc/codecs/arizona-jack.c b/sound/soc/codecs/arizona-jack.c
index a9063bac2752..fc09b31943a6 100644
--- a/sound/soc/codecs/arizona-jack.c
+++ b/sound/soc/codecs/arizona-jack.c
@@ -528,12 +528,11 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
int ret, reading, state, report;
bool mic = false;
- mutex_lock(&info->lock);
+ guard(mutex)(&info->lock);
/* If we got a spurious IRQ for some reason then ignore it */
if (!info->hpdet_active) {
dev_warn(arizona->dev, "Spurious HPDET IRQ\n");
- mutex_unlock(&info->lock);
return IRQ_NONE;
}
@@ -546,7 +545,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
ret = arizona_hpdet_read(info);
if (ret == -EAGAIN)
- goto out;
+ return IRQ_HANDLED;
else if (ret < 0)
goto done;
reading = ret;
@@ -559,7 +558,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
ret = arizona_hpdet_do_id(info, &reading, &mic);
if (ret == -EAGAIN)
- goto out;
+ return IRQ_HANDLED;
else if (ret < 0)
goto done;
@@ -596,9 +595,6 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
if (state)
info->hpdet_done = true;
-out:
- mutex_unlock(&info->lock);
-
return IRQ_HANDLED;
}
@@ -707,15 +703,13 @@ static void arizona_micd_timeout_work(struct work_struct *work)
struct arizona_priv,
micd_timeout_work.work);
- mutex_lock(&info->lock);
+ guard(mutex)(&info->lock);
dev_dbg(info->arizona->dev, "MICD timed out, reporting HP\n");
info->detecting = false;
arizona_identify_headphone(info);
-
- mutex_unlock(&info->lock);
}
static int arizona_micd_adc_read(struct arizona_priv *info)
@@ -921,12 +915,11 @@ static void arizona_micd_detect(struct work_struct *work)
cancel_delayed_work_sync(&info->micd_timeout_work);
- mutex_lock(&info->lock);
+ guard(mutex)(&info->lock);
/* If the cable was removed while measuring ignore the result */
if (!(info->jack->status & SND_JACK_MECHANICAL)) {
dev_dbg(arizona->dev, "Ignoring MICDET for removed cable\n");
- mutex_unlock(&info->lock);
return;
}
@@ -936,7 +929,6 @@ static void arizona_micd_detect(struct work_struct *work)
arizona_button_reading(info);
pm_runtime_mark_last_busy(arizona->dev);
- mutex_unlock(&info->lock);
}
static irqreturn_t arizona_micdet(int irq, void *data)
@@ -948,10 +940,10 @@ static irqreturn_t arizona_micdet(int irq, void *data)
cancel_delayed_work_sync(&info->micd_detect_work);
cancel_delayed_work_sync(&info->micd_timeout_work);
- mutex_lock(&info->lock);
- if (!info->detecting)
- debounce = 0;
- mutex_unlock(&info->lock);
+ scoped_guard(mutex, &info->lock) {
+ if (!info->detecting)
+ debounce = 0;
+ }
if (debounce)
queue_delayed_work(system_power_efficient_wq,
@@ -969,9 +961,8 @@ static void arizona_hpdet_work(struct work_struct *work)
struct arizona_priv,
hpdet_work.work);
- mutex_lock(&info->lock);
+ guard(mutex)(&info->lock);
arizona_start_hpdet_acc_id(info);
- mutex_unlock(&info->lock);
}
static int arizona_hpdet_wait(struct arizona_priv *info)
@@ -1013,6 +1004,7 @@ static irqreturn_t arizona_jackdet(int irq, void *data)
struct arizona *arizona = info->arizona;
unsigned int val, present, mask;
bool cancelled_hp, cancelled_mic;
+ irqreturn_t ret_irq = IRQ_HANDLED;
int ret, i;
cancelled_hp = cancel_delayed_work_sync(&info->hpdet_work);
@@ -1020,110 +1012,108 @@ static irqreturn_t arizona_jackdet(int irq, void *data)
pm_runtime_get_sync(arizona->dev);
- mutex_lock(&info->lock);
-
- if (info->micd_clamp) {
- mask = ARIZONA_MICD_CLAMP_STS;
- present = 0;
- } else {
- mask = ARIZONA_JD1_STS;
- if (arizona->pdata.jd_invert)
+ scoped_guard(mutex, &info->lock) {
+ if (info->micd_clamp) {
+ mask = ARIZONA_MICD_CLAMP_STS;
present = 0;
- else
- present = ARIZONA_JD1_STS;
- }
+ } else {
+ mask = ARIZONA_JD1_STS;
+ if (arizona->pdata.jd_invert)
+ present = 0;
+ else
+ present = ARIZONA_JD1_STS;
+ }
- ret = regmap_read(arizona->regmap, ARIZONA_AOD_IRQ_RAW_STATUS, &val);
- if (ret) {
- dev_err(arizona->dev, "Failed to read jackdet status: %d\n", ret);
- mutex_unlock(&info->lock);
- pm_runtime_put_autosuspend(arizona->dev);
- return IRQ_NONE;
- }
+ ret = regmap_read(arizona->regmap, ARIZONA_AOD_IRQ_RAW_STATUS, &val);
+ if (ret) {
+ dev_err(arizona->dev, "Failed to read jackdet status: %d\n", ret);
+ ret_irq = IRQ_NONE;
+ break;
+ }
- val &= mask;
- if (val == info->last_jackdet) {
- dev_dbg(arizona->dev, "Suppressing duplicate JACKDET\n");
- if (cancelled_hp)
- queue_delayed_work(system_power_efficient_wq,
- &info->hpdet_work,
- msecs_to_jiffies(HPDET_DEBOUNCE));
+ val &= mask;
+ if (val == info->last_jackdet) {
+ dev_dbg(arizona->dev, "Suppressing duplicate JACKDET\n");
+ if (cancelled_hp)
+ queue_delayed_work(system_power_efficient_wq,
+ &info->hpdet_work,
+ msecs_to_jiffies(HPDET_DEBOUNCE));
- if (cancelled_mic) {
- int micd_timeout = arizona->pdata.micd_timeout;
+ if (cancelled_mic) {
+ int micd_timeout = arizona->pdata.micd_timeout;
- queue_delayed_work(system_power_efficient_wq,
- &info->micd_timeout_work,
- msecs_to_jiffies(micd_timeout));
+ queue_delayed_work(system_power_efficient_wq,
+ &info->micd_timeout_work,
+ msecs_to_jiffies(micd_timeout));
+ }
+
+ goto out;
}
+ info->last_jackdet = val;
- goto out;
- }
- info->last_jackdet = val;
+ if (info->last_jackdet == present) {
+ dev_dbg(arizona->dev, "Detected jack\n");
+ snd_soc_jack_report(info->jack, SND_JACK_MECHANICAL, SND_JACK_MECHANICAL);
- if (info->last_jackdet == present) {
- dev_dbg(arizona->dev, "Detected jack\n");
- snd_soc_jack_report(info->jack, SND_JACK_MECHANICAL, SND_JACK_MECHANICAL);
+ info->detecting = true;
+ info->mic = false;
+ info->jack_flips = 0;
- info->detecting = true;
- info->mic = false;
- info->jack_flips = 0;
+ if (!arizona->pdata.hpdet_acc_id) {
+ arizona_start_mic(info);
+ } else {
+ queue_delayed_work(system_power_efficient_wq,
+ &info->hpdet_work,
+ msecs_to_jiffies(HPDET_DEBOUNCE));
+ }
- if (!arizona->pdata.hpdet_acc_id) {
- arizona_start_mic(info);
+ if (info->micd_clamp || !arizona->pdata.jd_invert)
+ regmap_update_bits(arizona->regmap,
+ ARIZONA_JACK_DETECT_DEBOUNCE,
+ ARIZONA_MICD_CLAMP_DB |
+ ARIZONA_JD1_DB, 0);
} else {
- queue_delayed_work(system_power_efficient_wq,
- &info->hpdet_work,
- msecs_to_jiffies(HPDET_DEBOUNCE));
- }
+ dev_dbg(arizona->dev, "Detected jack removal\n");
- if (info->micd_clamp || !arizona->pdata.jd_invert)
- regmap_update_bits(arizona->regmap,
- ARIZONA_JACK_DETECT_DEBOUNCE,
- ARIZONA_MICD_CLAMP_DB |
- ARIZONA_JD1_DB, 0);
- } else {
- dev_dbg(arizona->dev, "Detected jack removal\n");
+ arizona_stop_mic(info);
- arizona_stop_mic(info);
+ info->num_hpdet_res = 0;
+ for (i = 0; i < ARRAY_SIZE(info->hpdet_res); i++)
+ info->hpdet_res[i] = 0;
+ info->mic = false;
+ info->hpdet_done = false;
+ info->hpdet_retried = false;
- info->num_hpdet_res = 0;
- for (i = 0; i < ARRAY_SIZE(info->hpdet_res); i++)
- info->hpdet_res[i] = 0;
- info->mic = false;
- info->hpdet_done = false;
- info->hpdet_retried = false;
-
- snd_soc_jack_report(info->jack, 0, ARIZONA_JACK_MASK | info->micd_button_mask);
+ snd_soc_jack_report(info->jack, 0,
+ ARIZONA_JACK_MASK | info->micd_button_mask);
- /*
- * If the jack was removed during a headphone detection we
- * need to wait for the headphone detection to finish, as
- * it can not be aborted. We don't want to be able to start
- * a new headphone detection from a fresh insert until this
- * one is finished.
- */
- arizona_hpdet_wait(info);
+ /*
+ * If the jack was removed during a headphone detection we
+ * need to wait for the headphone detection to finish, as
+ * it can not be aborted. We don't want to be able to start
+ * a new headphone detection from a fresh insert until this
+ * one is finished.
+ */
+ arizona_hpdet_wait(info);
- regmap_update_bits(arizona->regmap,
- ARIZONA_JACK_DETECT_DEBOUNCE,
- ARIZONA_MICD_CLAMP_DB | ARIZONA_JD1_DB,
- ARIZONA_MICD_CLAMP_DB | ARIZONA_JD1_DB);
- }
+ regmap_update_bits(arizona->regmap,
+ ARIZONA_JACK_DETECT_DEBOUNCE,
+ ARIZONA_MICD_CLAMP_DB | ARIZONA_JD1_DB,
+ ARIZONA_MICD_CLAMP_DB | ARIZONA_JD1_DB);
+ }
out:
- /* Clear trig_sts to make sure DCVDD is not forced up */
- regmap_write(arizona->regmap, ARIZONA_AOD_WKUP_AND_TRIG,
- ARIZONA_MICD_CLAMP_FALL_TRIG_STS |
- ARIZONA_MICD_CLAMP_RISE_TRIG_STS |
- ARIZONA_JD1_FALL_TRIG_STS |
- ARIZONA_JD1_RISE_TRIG_STS);
-
- mutex_unlock(&info->lock);
+ /* Clear trig_sts to make sure DCVDD is not forced up */
+ regmap_write(arizona->regmap, ARIZONA_AOD_WKUP_AND_TRIG,
+ ARIZONA_MICD_CLAMP_FALL_TRIG_STS |
+ ARIZONA_MICD_CLAMP_RISE_TRIG_STS |
+ ARIZONA_JD1_FALL_TRIG_STS |
+ ARIZONA_JD1_RISE_TRIG_STS);
+ }
pm_runtime_put_autosuspend(arizona->dev);
- return IRQ_HANDLED;
+ return ret_irq;
}
/* Map a level onto a slot in the register bank */
--
2.43.0
^ permalink raw reply related
* [PATCH 02/78] ASoC: codecs: ak4613: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:31 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/ak4613.c | 72 +++++++++++++++++++--------------------
1 file changed, 35 insertions(+), 37 deletions(-)
diff --git a/sound/soc/codecs/ak4613.c b/sound/soc/codecs/ak4613.c
index 3e0696b5abf5..413ef55b918a 100644
--- a/sound/soc/codecs/ak4613.c
+++ b/sound/soc/codecs/ak4613.c
@@ -384,7 +384,7 @@ static void ak4613_dai_shutdown(struct snd_pcm_substream *substream,
struct ak4613_priv *priv = snd_soc_component_get_drvdata(component);
struct device *dev = component->dev;
- mutex_lock(&priv->lock);
+ guard(mutex)(&priv->lock);
priv->cnt--;
if (priv->cnt < 0) {
dev_err(dev, "unexpected counter error\n");
@@ -392,7 +392,6 @@ static void ak4613_dai_shutdown(struct snd_pcm_substream *substream,
}
if (!priv->cnt)
priv->ctrl1 = 0;
- mutex_unlock(&priv->lock);
}
static void ak4613_hw_constraints(struct ak4613_priv *priv,
@@ -507,10 +506,9 @@ static int ak4613_dai_startup(struct snd_pcm_substream *substream,
struct snd_soc_component *component = dai->component;
struct ak4613_priv *priv = snd_soc_component_get_drvdata(component);
- mutex_lock(&priv->lock);
+ guard(mutex)(&priv->lock);
ak4613_hw_constraints(priv, substream);
priv->cnt++;
- mutex_unlock(&priv->lock);
return 0;
}
@@ -599,42 +597,42 @@ static int ak4613_dai_hw_params(struct snd_pcm_substream *substream,
*/
ret = -EINVAL;
- mutex_lock(&priv->lock);
- if (priv->cnt > 1) {
- /*
- * If it was already working, use current priv->ctrl1
- */
- ret = 0;
- } else {
- /*
- * It is not yet working,
- */
- unsigned int channel = params_channels(params);
- u8 tdm;
-
- /* STEREO or TDM */
- if (channel == 2)
- tdm = AK4613_CONFIG_MODE_STEREO;
- else
- tdm = AK4613_CONFIG_GET(priv, MODE);
-
- for (i = ARRAY_SIZE(ak4613_iface) - 1; i >= 0; i--) {
- const struct ak4613_interface *iface = ak4613_iface + i;
-
- if ((iface->fmt == fmt) && (iface->width == width)) {
- /*
- * Ctrl1
- * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
- * |TDM1|TDM0|DIF2|DIF1|DIF0|ATS1|ATS0|SMUTE|
- * < tdm > < iface->dif >
- */
- priv->ctrl1 = (tdm << 6) | (iface->dif << 3);
- ret = 0;
- break;
+ scoped_guard(mutex, &priv->lock) {
+ if (priv->cnt > 1) {
+ /*
+ * If it was already working, use current priv->ctrl1
+ */
+ ret = 0;
+ } else {
+ /*
+ * It is not yet working,
+ */
+ unsigned int channel = params_channels(params);
+ u8 tdm;
+
+ /* STEREO or TDM */
+ if (channel == 2)
+ tdm = AK4613_CONFIG_MODE_STEREO;
+ else
+ tdm = AK4613_CONFIG_GET(priv, MODE);
+
+ for (i = ARRAY_SIZE(ak4613_iface) - 1; i >= 0; i--) {
+ const struct ak4613_interface *iface = ak4613_iface + i;
+
+ if ((iface->fmt == fmt) && (iface->width == width)) {
+ /*
+ * Ctrl1
+ * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
+ * |TDM1|TDM0|DIF2|DIF1|DIF0|ATS1|ATS0|SMUTE|
+ * < tdm > < iface->dif >
+ */
+ priv->ctrl1 = (tdm << 6) | (iface->dif << 3);
+ ret = 0;
+ break;
+ }
}
}
}
- mutex_unlock(&priv->lock);
if (ret < 0)
goto hw_params_end;
--
2.43.0
^ permalink raw reply related
* [PATCH 01/78] ASoC: codecs: ab8500: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-17 10:31 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/ab8500-codec.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/ab8500-codec.c b/sound/soc/codecs/ab8500-codec.c
index 6e8ef9cd1b31..20beb830fd62 100644
--- a/sound/soc/codecs/ab8500-codec.c
+++ b/sound/soc/codecs/ab8500-codec.c
@@ -989,9 +989,8 @@ static int sid_status_control_get(struct snd_kcontrol *kcontrol,
struct snd_soc_component *component = snd_kcontrol_chip(kcontrol);
struct ab8500_codec_drvdata *drvdata = dev_get_drvdata(component->dev);
- mutex_lock(&drvdata->ctrl_lock);
+ guard(mutex)(&drvdata->ctrl_lock);
ucontrol->value.enumerated.item[0] = drvdata->sid_status;
- mutex_unlock(&drvdata->ctrl_lock);
return 0;
}
@@ -1014,7 +1013,7 @@ static int sid_status_control_put(struct snd_kcontrol *kcontrol,
return -EIO;
}
- mutex_lock(&drvdata->ctrl_lock);
+ guard(mutex)(&drvdata->ctrl_lock);
sidconf = snd_soc_component_read(component, AB8500_SIDFIRCONF);
if (((sidconf & BIT(AB8500_SIDFIRCONF_FIRSIDBUSY)) != 0)) {
@@ -1025,7 +1024,8 @@ static int sid_status_control_put(struct snd_kcontrol *kcontrol,
} else {
status = -EBUSY;
}
- goto out;
+ dev_dbg(component->dev, "%s: Exit\n", __func__);
+ return status;
}
snd_soc_component_write(component, AB8500_SIDFIRADR, 0);
@@ -1043,9 +1043,6 @@ static int sid_status_control_put(struct snd_kcontrol *kcontrol,
drvdata->sid_status = SID_FIR_CONFIGURED;
-out:
- mutex_unlock(&drvdata->ctrl_lock);
-
dev_dbg(component->dev, "%s: Exit\n", __func__);
return status;
--
2.43.0
^ permalink raw reply related
* [PATCH 00/78] ASoC: codecs: Use guard() for mutex & spin locks
From: phucduc.bui @ 2026-06-17 10:31 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
From: bui duc phuc <phucduc.bui@gmail.com>
Hi all,
This series converts mutex and spinlock handling in the ASoC codec
drivers to use guard() and scoped_guard() helpers.
The changes are purely refactoring and should have no functional
impact.
Compile tested only.
Best regards,
Phuc
bui duc phuc (78):
ASoC: codecs: ab8500: Use guard() for mutex locks
ASoC: codecs: ak4613: Use guard() for mutex locks
ASoC: codecs: arizona-jack: Use guard() for mutex locks
ASoC: codecs: arizona: Use guard() for mutex locks
ASoC: codecs: aw87390: Use guard() for mutex locks
ASoC: codecs: aw88081: Use guard() for mutex locks
ASoC: codecs: aw88166: Use guard() for mutex locks
ASoC: codecs: aw88261: Use guard() for mutex locks
ASoC: codecs: aw88395: Use guard() for mutex locks
ASoC: codecs: aw88399: Use guard() for mutex locks
ASoC: codecs: cros_ec_codec: Use guard() for mutex locks
ASoC: codecs: cs-amp-lib: Use guard() for mutex locks
ASoC: codecs: cs35l56: Use guard() for mutex locks
ASoC: codecs: cs42l42: Use guard() for mutex locks
ASoC: codecs: cs42l43: Use guard() for mutex locks
ASoC: codecs: cs42l84: Use guard() for mutex locks
ASoC: codecs: cs43130: Use guard() for mutex locks
ASoC: codecs: cs47l15: Use guard() for mutex locks
ASoC: codecs: cs47l35: Use guard() for mutex locks
ASoC: codecs: cs47l85: Use guard() for mutex locks
ASoC: codecs: cs47l90: Use guard() for mutex locks
ASoC: codecs: cs47l92: Use guard() for mutex locks
ASoC: codecs: cs48l32: Use guard() for mutex locks
ASoC: codecs: cs2072x: Use guard() for mutex locks
ASoC: codecs: da7213: Use guard() for mutex locks
ASoC: codecs: da7219: Use guard() for mutex locks
ASoC: codecs: es8316: Use guard() for mutex locks
ASoC: codecs: es8326: Use guard() for mutex locks
ASoC: codecs: es9356: Use guard() for mutex locks
ASoC: codecs: fs210x: Use guard() for mutex locks
ASoC: codecs: hdac_hdmi: Use guard() for mutex locks
ASoC: codecs: hdmi-codec: Use guard() for mutex locks
ASoC: codecs: idt821034: Use guard() for mutex locks
ASoC: codecs: lpass-macro: Use guard() for mutex locks
ASoC: codecs: madera: Use guard() for mutex locks
ASoC: codecs: max98095: Use guard() for mutex locks
ASoC: codecs: mt6359-accdet: Use guard() for mutex locks
ASoC: codecs: pcm512x: Use guard() for mutex locks
ASoC: codecs: pcm6240: Use guard() for mutex locks
ASoC: codecs: peb2466: Use guard() for mutex locks
ASoC: codecs: rt5514-spi: Use guard() for mutex locks
ASoC: codecs: rt5645: Use guard() for mutex locks
ASoC: codecs: rt5665: Use guard() for mutex locks
ASoC: codecs: rt5668: Use guard() for mutex locks
ASoC: codecs: rt5677: Use guard() for mutex locks
ASoC: codecs: rt5682: Use guard() for mutex locks
ASoC: codecs: rt700: Use guard() for mutex locks
ASoC: codecs: rt711: Use guard() for mutex locks
ASoC: codecs: rt712: Use guard() for mutex locks
ASoC: codecs: rt721: Use guard() for mutex locks
ASoC: codecs: rt722: Use guard() for mutex locks
ASoC: codecs: sigmadsp: Use guard() for mutex locks
ASoC: codecs: sta350: Use guard() for mutex locks
ASoC: codecs: sta32x: Use guard() for mutex locks
ASoC: codecs: tas2781: Use guard() for mutex locks
ASoC: codecs: tas2783: Use guard() for mutex locks
ASoC: codecs: tas5805m: Use guard() for mutex locks
ASoC: codecs: tas675x: Use guard() for mutex locks
ASoC: codecs: tlv320dac33: Use guard() for mutex & spin locks
ASoC: codecs: tscs42xx: Use guard() for mutex locks
ASoC: codecs: tscs454: Use guard() for mutex locks
ASoC: codecs: twl6040: Use guard() for mutex locks
ASoC: codecs: wcd-mbhc: Use guard() for mutex locks
ASoC: codecs: wcd934x: Use guard() for mutex locks
ASoC: codecs: wcd937x: Use guard() for mutex locks
ASoC: codecs: wcd938x: Use guard() for mutex locks
ASoC: codecs: wcd939x: Use guard() for mutex locks
ASoC: codecs: wm0010: Use guard() for mutex & spin locks
ASoC: codecs: wm2000: Use guard() for mutex locks
ASoC: codecs: wm5102: Use guard() for mutex locks
ASoC: codecs: wm8731: Use guard() for mutex locks
ASoC: codecs: wm8903: Use guard() for mutex locks
ASoC: codecs: wm8958: Use guard() for mutex locks
ASoC: codecs: wm8962: Use guard() for mutex locks
ASoC: codecs: wm8994: Use guard() for mutex locks
ASoC: codecs: wm971x: Use guard() for mutex locks
ASoC: codecs: wm_adsp: Use guard() for mutex locks
ASoC: codecs: wsa88xx: Use guard() for mutex locks
sound/soc/codecs/ab8500-codec.c | 11 +-
sound/soc/codecs/ak4613.c | 72 ++++---
sound/soc/codecs/arizona-jack.c | 194 +++++++++----------
sound/soc/codecs/arizona.c | 25 +--
sound/soc/codecs/aw87390.c | 9 +-
sound/soc/codecs/aw88081.c | 17 +-
sound/soc/codecs/aw88166.c | 23 +--
sound/soc/codecs/aw88261.c | 20 +-
sound/soc/codecs/aw88395/aw88395.c | 23 +--
sound/soc/codecs/aw88395/aw88395_device.c | 39 ++--
sound/soc/codecs/aw88399.c | 14 +-
sound/soc/codecs/cros_ec_codec.c | 17 +-
sound/soc/codecs/cs-amp-lib.c | 10 +-
sound/soc/codecs/cs35l56-shared.c | 6 +-
sound/soc/codecs/cs35l56.c | 56 +++---
sound/soc/codecs/cs42l42.c | 222 +++++++++++-----------
sound/soc/codecs/cs42l43-jack.c | 57 +++---
sound/soc/codecs/cs42l43.c | 16 +-
sound/soc/codecs/cs42l84.c | 9 +-
sound/soc/codecs/cs43130.c | 96 +++++-----
sound/soc/codecs/cs47l15.c | 10 +-
sound/soc/codecs/cs47l35.c | 10 +-
sound/soc/codecs/cs47l85.c | 10 +-
sound/soc/codecs/cs47l90.c | 10 +-
sound/soc/codecs/cs47l92.c | 10 +-
sound/soc/codecs/cs48l32.c | 28 ++-
sound/soc/codecs/cx2072x.c | 4 +-
sound/soc/codecs/da7213.c | 36 ++--
sound/soc/codecs/da7219.c | 59 ++----
sound/soc/codecs/es8316.c | 30 ++-
sound/soc/codecs/es8326.c | 29 ++-
sound/soc/codecs/es9356.c | 29 ++-
sound/soc/codecs/fs210x.c | 86 +++------
sound/soc/codecs/hdac_hdmi.c | 116 ++++++-----
sound/soc/codecs/hdmi-codec.c | 16 +-
sound/soc/codecs/idt821034.c | 120 +++++-------
sound/soc/codecs/lpass-macro-common.c | 11 +-
sound/soc/codecs/madera.c | 31 +--
sound/soc/codecs/max98095.c | 34 ++--
sound/soc/codecs/mt6359-accdet.c | 12 +-
sound/soc/codecs/pcm512x.c | 17 +-
sound/soc/codecs/pcm6240.c | 27 ++-
sound/soc/codecs/peb2466.c | 15 +-
sound/soc/codecs/rt5514-spi.c | 20 +-
sound/soc/codecs/rt5645.c | 161 ++++++++--------
sound/soc/codecs/rt5665.c | 7 +-
sound/soc/codecs/rt5668.c | 9 +-
sound/soc/codecs/rt5677-spi.c | 35 ++--
sound/soc/codecs/rt5677.c | 77 ++++----
sound/soc/codecs/rt5682-sdw.c | 23 ++-
sound/soc/codecs/rt5682.c | 4 +-
sound/soc/codecs/rt5682s.c | 16 +-
sound/soc/codecs/rt700-sdw.c | 13 +-
sound/soc/codecs/rt711-sdca-sdw.c | 33 ++--
sound/soc/codecs/rt711-sdca.c | 7 +-
sound/soc/codecs/rt711-sdw.c | 23 ++-
sound/soc/codecs/rt711.c | 19 +-
sound/soc/codecs/rt712-sdca-sdw.c | 34 ++--
sound/soc/codecs/rt712-sdca.c | 7 +-
sound/soc/codecs/rt721-sdca-sdw.c | 33 ++--
sound/soc/codecs/rt721-sdca.c | 3 +-
sound/soc/codecs/rt722-sdca-sdw.c | 33 ++--
sound/soc/codecs/rt722-sdca.c | 3 +-
sound/soc/codecs/sigmadsp.c | 16 +-
sound/soc/codecs/sta32x.c | 12 +-
sound/soc/codecs/sta350.c | 12 +-
sound/soc/codecs/tas2781-comlib-i2c.c | 4 +-
sound/soc/codecs/tas2781-i2c.c | 20 +-
sound/soc/codecs/tas2783-sdw.c | 89 +++++----
sound/soc/codecs/tas5805m.c | 15 +-
sound/soc/codecs/tas675x.c | 6 +-
sound/soc/codecs/tlv320dac33.c | 77 +++-----
sound/soc/codecs/tscs42xx.c | 44 ++---
sound/soc/codecs/tscs454.c | 106 ++++-------
sound/soc/codecs/twl6040.c | 4 +-
sound/soc/codecs/wcd-mbhc-v2.c | 142 +++++++-------
sound/soc/codecs/wcd934x.c | 46 ++---
sound/soc/codecs/wcd937x.c | 24 +--
sound/soc/codecs/wcd938x.c | 21 +-
sound/soc/codecs/wcd939x.c | 19 +-
sound/soc/codecs/wm0010.c | 63 +++---
sound/soc/codecs/wm2000.c | 27 +--
sound/soc/codecs/wm5102.c | 12 +-
sound/soc/codecs/wm8731.c | 3 +-
sound/soc/codecs/wm8903.c | 3 +-
sound/soc/codecs/wm8958-dsp2.c | 9 +-
sound/soc/codecs/wm8962.c | 7 +-
sound/soc/codecs/wm8994.c | 51 ++---
sound/soc/codecs/wm9712.c | 4 +-
sound/soc/codecs/wm9713.c | 4 +-
sound/soc/codecs/wm_adsp.c | 87 +++------
sound/soc/codecs/wsa883x.c | 10 +-
sound/soc/codecs/wsa884x.c | 10 +-
93 files changed, 1330 insertions(+), 1863 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 28/37] drm/mediatek: dpi: Switch to atomic bridge callbacks
From: Maxime Ripard @ 2026-06-17 10:14 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
dri-devel, Maxime Ripard, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, AngeloGioacchino Del Regno, linux-mediatek,
linux-arm-kernel
In-Reply-To: <20260617-drm-all-atomic-bridges-v1-0-b63e6316166b@kernel.org>
The mediatek mtk_dpi bridge still uses the deprecated non-atomic bridge
callbacks.
Switch to their atomic counterparts.
Generated by the following Coccinelle script:
@ is_bridge @
identifier funcs;
@@
struct drm_bridge_funcs funcs = {
...,
};
@ has_create_state depends on is_bridge @
identifier funcs, f;
@@
struct drm_bridge_funcs funcs = {
...,
.atomic_create_state = f,
...,
};
@ update_struct depends on (is_bridge && !has_create_state) @
identifier is_bridge.funcs;
identifier f;
@@
struct drm_bridge_funcs funcs = {
+ .atomic_create_state = drm_atomic_helper_bridge_create_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
...,
};
@ update_pre_enable_struct depends on is_bridge @
identifier is_bridge.funcs;
identifier f;
@@
struct drm_bridge_funcs funcs = {
...,
- .pre_enable = f,
+ .atomic_pre_enable = f,
...,
};
@ update_pre_enable_impl depends on update_pre_enable_struct @
identifier update_pre_enable_struct.f;
identifier b;
@@
-void f(struct drm_bridge *b)
+void f(struct drm_bridge *b, struct drm_atomic_commit *commit)
{
...
}
@ update_enable_struct depends on is_bridge @
identifier is_bridge.funcs;
identifier f;
@@
struct drm_bridge_funcs funcs = {
...,
- .enable = f,
+ .atomic_enable = f,
...,
};
@ update_enable_impl depends on update_enable_struct @
identifier update_enable_struct.f;
identifier b;
@@
-void f(struct drm_bridge *b)
+void f(struct drm_bridge *b, struct drm_atomic_commit *commit)
{
...
}
@ update_disable_struct depends on is_bridge @
identifier is_bridge.funcs;
identifier f;
@@
struct drm_bridge_funcs funcs = {
...,
- .disable = f,
+ .atomic_disable = f,
...,
};
@ update_disable_impl depends on update_disable_struct @
identifier update_disable_struct.f;
identifier b;
@@
-void f(struct drm_bridge *b)
+void f(struct drm_bridge *b, struct drm_atomic_commit *commit)
{
...
}
@ update_post_disable_struct depends on is_bridge @
identifier is_bridge.funcs;
identifier f;
@@
struct drm_bridge_funcs funcs = {
...,
- .post_disable = f,
+ .atomic_post_disable = f,
...,
};
@ update_post_disable_impl depends on update_post_disable_struct @
identifier update_post_disable_struct.f;
identifier b;
@@
-void f(struct drm_bridge *b)
+void f(struct drm_bridge *b, struct drm_atomic_commit *commit)
{
...
}
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
To: Philipp Zabel <p.zabel@pengutronix.de>
To: Matthias Brugger <matthias.bgg@gmail.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: linux-mediatek@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 959c994eef24..0e4f430de983 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -848,21 +848,23 @@ static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
drm_mode_copy(&dpi->mode, adjusted_mode);
}
-static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
+static void mtk_dpi_bridge_disable(struct drm_bridge *bridge,
+ struct drm_atomic_commit *commit)
{
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
mtk_dpi_power_off(dpi);
if (dpi->pinctrl && dpi->pins_gpio)
pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
}
-static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
+static void mtk_dpi_bridge_enable(struct drm_bridge *bridge,
+ struct drm_atomic_commit *commit)
{
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
if (dpi->pinctrl && dpi->pins_dpi)
pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
@@ -980,12 +982,12 @@ static void mtk_dpi_debugfs_init(struct drm_bridge *bridge, struct dentry *root)
static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
.attach = mtk_dpi_bridge_attach,
.mode_set = mtk_dpi_bridge_mode_set,
.mode_valid = mtk_dpi_bridge_mode_valid,
- .disable = mtk_dpi_bridge_disable,
- .enable = mtk_dpi_bridge_enable,
+ .atomic_disable = mtk_dpi_bridge_disable,
+ .atomic_enable = mtk_dpi_bridge_enable,
.atomic_check = mtk_dpi_bridge_atomic_check,
.atomic_get_output_bus_fmts = mtk_dpi_bridge_atomic_get_output_bus_fmts,
.atomic_get_input_bus_fmts = mtk_dpi_bridge_atomic_get_input_bus_fmts,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
--
2.54.0
^ permalink raw reply related
* [PATCH 00/37] drm/bridge: Convert all bridges to atomic
From: Maxime Ripard @ 2026-06-17 10:14 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
dri-devel, Maxime Ripard, Sasha Finkelstein, Janne Grunau, asahi,
Benson Leung, Guenter Roeck, chrome-platform, Francesco Dolcini,
Peter Senna Tschudin, Ian Ray, Martyn Welch,
Manikandan Muralidharan, Dharma Balasubiramani, Russell King,
Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Alim Akhtar, linux-arm-kernel, linux-samsung-soc, Linus Walleij,
Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, linux-mediatek, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, freedreno, Tomi Valkeinen, Alain Volmat,
Raphael Gallais-Pou
Hi,
Over the years, most of the bridges have been converted to atomic
modesetting and hooks, but not all of them. This forces us to maintain
two different code path in quite a few places, which is pretty
bothersome. The switch to atomic modesetting for legacy bridges though
is pretty trivial, and we don't have a lot of drivers still using the
legacy path.
This series converts all bridges to atomic modesetting and drops the
legacy codepaths where relevant.
Let me know what you think,
Maxime
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
Maxime Ripard (37):
drm/adp: mipi: Switch to atomic bridge callbacks
drm/bridge: analogix-anx6345: Switch to atomic bridge callbacks
drm/bridge: analogix-anx78xx: Switch to atomic bridge callbacks
drm/bridge: aux-bridge: Switch to atomic bridge callbacks
drm/bridge: aux-hpd-bridge: Switch to atomic bridge callbacks
drm/bridge: chrontel-ch7033: Switch to atomic bridge callbacks
drm/bridge: cros-ec-anx7688: Switch to atomic bridge callbacks
drm/bridge: lontium-lt8713sx: Switch to atomic bridge callbacks
drm/bridge: lontium-lt8912b: Switch to atomic bridge callbacks
drm/bridge: lontium-lt9611uxc: Switch to atomic bridge callbacks
drm/bridge: lvds-codec: Switch to atomic bridge callbacks
drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: Switch to atomic bridge callbacks
drm/bridge: microchip-lvds: Switch to atomic bridge callbacks
drm/bridge: nxp-ptn3460: Switch to atomic bridge callbacks
drm/bridge: of-display-mode-bridge: Switch to atomic bridge callbacks
drm/bridge: parade-ps8622: Switch to atomic bridge callbacks
drm/bridge: sii9234: Switch to atomic bridge callbacks
drm/bridge: sil-sii8620: Switch to atomic bridge callbacks
drm/bridge: simple-bridge: Switch to atomic bridge callbacks
drm/bridge: tc358764: Switch to atomic bridge callbacks
drm/bridge: tda998x: Switch to atomic bridge callbacks
drm/bridge: ti-tfp410: Switch to atomic bridge callbacks
drm/bridge: ti-tpd12s015: Switch to atomic bridge callbacks
drm/bridge: thc63lvd1024: Switch to atomic bridge callbacks
drm/bridge: waveshare-dsi: Switch to atomic bridge callbacks
drm/exynos: mic: Switch to atomic bridge callbacks
drm/mcde: dsi: Switch to atomic bridge callbacks
drm/mediatek: dpi: Switch to atomic bridge callbacks
drm/msm: dsi: Switch to atomic bridge callbacks
drm/omap: dpi: Switch to atomic bridge callbacks
drm/omap: dsi: Switch to atomic bridge callbacks
drm/omap: sdi: Switch to atomic bridge callbacks
drm/omap: venc: Switch to atomic bridge callbacks
drm/sti: dvo: Switch to atomic bridge callbacks
drm/sti: hda: Switch to atomic bridge callbacks
drm/sti: hdmi: Switch to atomic bridge callbacks
drm/bridge: Remove legacy bridge callback support
drivers/gpu/drm/adp/adp-mipi.c | 4 +
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 13 ++-
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 13 ++-
drivers/gpu/drm/bridge/aux-bridge.c | 4 +
drivers/gpu/drm/bridge/aux-hpd-bridge.c | 4 +
drivers/gpu/drm/bridge/chrontel-ch7033.c | 13 ++-
drivers/gpu/drm/bridge/cros-ec-anx7688.c | 4 +
drivers/gpu/drm/bridge/lontium-lt8713sx.c | 4 +
drivers/gpu/drm/bridge/lontium-lt8912b.c | 8 +-
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 +
drivers/gpu/drm/bridge/lvds-codec.c | 10 +-
.../drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c | 3 +
drivers/gpu/drm/bridge/microchip-lvds.c | 3 +
drivers/gpu/drm/bridge/nxp-ptn3460.c | 17 ++--
drivers/gpu/drm/bridge/of-display-mode-bridge.c | 4 +
drivers/gpu/drm/bridge/parade-ps8622.c | 18 ++--
drivers/gpu/drm/bridge/sii9234.c | 4 +
drivers/gpu/drm/bridge/sil-sii8620.c | 4 +
drivers/gpu/drm/bridge/simple-bridge.c | 13 ++-
drivers/gpu/drm/bridge/tc358764.c | 13 ++-
drivers/gpu/drm/bridge/tda998x_drv.c | 13 ++-
drivers/gpu/drm/bridge/thc63lvd1024.c | 14 ++-
drivers/gpu/drm/bridge/ti-tfp410.c | 10 +-
drivers/gpu/drm/bridge/ti-tpd12s015.c | 4 +
drivers/gpu/drm/bridge/waveshare-dsi.c | 14 ++-
drivers/gpu/drm/drm_bridge.c | 27 +-----
drivers/gpu/drm/exynos/exynos_drm_mic.c | 14 ++-
drivers/gpu/drm/mcde/mcde_dsi.c | 3 +
drivers/gpu/drm/mediatek/mtk_dpi.c | 10 +-
drivers/gpu/drm/msm/dsi/dsi_manager.c | 13 ++-
drivers/gpu/drm/omapdrm/dss/dpi.c | 14 ++-
drivers/gpu/drm/omapdrm/dss/dsi.c | 14 ++-
drivers/gpu/drm/omapdrm/dss/sdi.c | 14 ++-
drivers/gpu/drm/omapdrm/dss/venc.c | 14 ++-
drivers/gpu/drm/sti/sti_dvo.c | 20 ++--
drivers/gpu/drm/sti/sti_hda.c | 20 ++--
drivers/gpu/drm/sti/sti_hdmi.c | 20 ++--
drivers/gpu/drm/tests/drm_bridge_test.c | 104 ---------------------
include/drm/drm_bridge.h | 103 --------------------
39 files changed, 272 insertions(+), 332 deletions(-)
---
base-commit: 60dc0946bbad3eef8bc66a5a8b09b98dbc6e09c0
change-id: 20260615-drm-all-atomic-bridges-4da4fe7df58f
prerequisite-change-id: 20260530-drm-no-more-bridge-reset-ca20d5e22740:v2
prerequisite-patch-id: 8a8fbf1313a047a4a519f531a71c6c6f87b9bc83
prerequisite-patch-id: a4e58ec70eaf69e00dba8b06a9ea276476d99743
prerequisite-patch-id: d352592969ab04b77b981b3f214f2564e03adbb5
prerequisite-patch-id: 12209462a46aa438a0e5c415de008e2328128fe5
prerequisite-patch-id: 6193aa414873bcc7fa5d1062ed34cc124838ea6a
prerequisite-patch-id: 076dae12bdbc2c270f30588a8d6e95563359b309
prerequisite-patch-id: ffc56b19b1cd7ca4e909224903d8d43b39ae7fc6
prerequisite-patch-id: 5dfc850e535eea05740da327f1ec8ab1a57a3218
prerequisite-patch-id: 128438e2c3f56d29d05cf98486786c307441678b
prerequisite-patch-id: 9f030232058e7b6c6eb9978c0e2ea8baebadbfd8
prerequisite-patch-id: 9aa995e299738e71811fce508043e049216dbee8
prerequisite-patch-id: 3c8c77a634ee316df7d077926b84f97f75ce3b9d
prerequisite-patch-id: d60457e4989ffd8315fc5dfa0fe938f20ba5769e
prerequisite-patch-id: d8aca430669a3514e9c7c8071392fd975c729943
prerequisite-patch-id: f13b78cddc8e1d0a24ad2f07822cddcc2f349d56
prerequisite-patch-id: 274645e4a50795892bba19c49b7228223837e4ee
prerequisite-patch-id: b6e9e252c6b97ff453c31e7ce9f0c7e30af226ad
prerequisite-patch-id: eaf8dc37e5fa9671a749287932de5cedeaa19367
prerequisite-patch-id: ed140d0015fe32b1a312902d6a49dfa505d0c062
prerequisite-patch-id: 1798291a06b97eb5e44521dcb1d2db22266b7322
prerequisite-patch-id: 643d01d3dbe83950d3b3f1cec7adddc297163f24
prerequisite-patch-id: 3e63f40fbd7b98e342da46b1aa377e39fb4e20fe
prerequisite-patch-id: 83a906dc9533cfd63233328737c13092b0117164
prerequisite-patch-id: 24f53e9c4f55a4e879fa5a32b30910ed6c1cd269
prerequisite-patch-id: bd7e4106e2f0ef8608121b0408eac85d0f17b4df
prerequisite-patch-id: 2b76a8943c04e7be9da62a78caa5fc86437d87e3
prerequisite-patch-id: 59b0884a01a819a1d67e9135ea8e313a97bbb4fc
prerequisite-patch-id: bb66b9cc8daa47a2ebedbf0b8bfe67b3f5afc193
prerequisite-patch-id: 476834604d587da752945e53b2e4c6e0aba74b38
prerequisite-patch-id: 0d0c0d400e2dda1b2a2143c2bd34d6a361b97f13
prerequisite-patch-id: 27768e65101e85d23f008b22c9e34e8556334e1c
prerequisite-patch-id: 8ee093b3d6884c6c7dcd5072893c58dad092fda6
prerequisite-patch-id: 9ed3a66dc12bd099b09a495bd8148ecc363d3779
prerequisite-patch-id: 288c493e2466e08e8a7b3137fbb443e17a99e510
prerequisite-patch-id: 6f00079c63b96a7de1603f1524f06c0ad27c2cd3
prerequisite-patch-id: f5c58ba609d0b609afd627e0452d6de34bb12f4e
prerequisite-patch-id: 7f22cb2b55bd93af027ca50709fbbda072c15a06
prerequisite-patch-id: 922a3d5ceb0607718a290ffd1f02e3e573a49cf4
prerequisite-patch-id: 1d79eb945c8ca7ecae7b9d94b3ea07883c0337a9
prerequisite-patch-id: 2f97212d2d87fabca5724d003cc6c70ae1e026b0
prerequisite-patch-id: f667fac52310410fc067bebcf2c12e5757edbc51
prerequisite-patch-id: ddc5ac03c75f6c6bd080e379b1c86c0024f09010
prerequisite-patch-id: 1811f9a95469f9ab89faacc8fa23af3a8def0e10
prerequisite-patch-id: 29684ab02ba8bf4ee366a56627c02ff4ef0d5af3
prerequisite-patch-id: 00ebcbd12168a25f625d41dc4e0fc11659e00773
prerequisite-patch-id: 1c570484a5d1a5209db2290b991dd7914e219e1c
prerequisite-patch-id: 740c4469f788188f0e08fcbe9772ab2654892638
prerequisite-patch-id: 2fb23f6f9a41c7ddf94480c904ad7ec22c161f95
prerequisite-patch-id: d7f382a50b8db0525f2341a86705d01cdfbd9b56
prerequisite-patch-id: d7243d13750efb81a0e93d223f1afd7e30bcae24
prerequisite-patch-id: 6fd0d1296c2b01204a703d740cded71e448f7514
prerequisite-patch-id: e093cf415c55b339b04562e3dc970361a971b226
prerequisite-patch-id: 5f2c35278a4eb15ccf7f388b996a2ae2ba9b7396
prerequisite-patch-id: 9c732ea87d43b26c1e16377fe3a4de42f603f153
prerequisite-patch-id: 0d06852811ed3d3b52b701be99df135772b22d86
prerequisite-patch-id: 972a1fe51fc62083eee9af1ba4cccc2350f87820
prerequisite-patch-id: f78004b914048a14f48f9efbcf95586d84b33f23
prerequisite-patch-id: cd38c76c499c1e9722889d97938b0406eff31940
prerequisite-patch-id: 0777475583042460d0ef343533d8e2c37d3d2c4b
prerequisite-patch-id: 2e535f65d1b8e0e768e8f897f779f06c31d128a6
prerequisite-patch-id: ee47825cdbe1d4b937a6775fca324171015282d1
prerequisite-patch-id: 1e4c68816dc7d1672dfd7e7175a1680a40ab18ae
prerequisite-patch-id: 7509918098c4aabff7639a8f3849f4b2c56fca53
prerequisite-patch-id: fd07b55c2a713e73540f3049818d996fcd5ef966
prerequisite-patch-id: 5b269160fdaa636392cb2f1bf362c0cc393f08b8
prerequisite-patch-id: 021c28b68be7ccbab88067648f9730be2c70cdf6
prerequisite-patch-id: 8b208c636fb9439764239b991fd123ffc1addf1f
prerequisite-patch-id: dd6127d8825c9225abe959d6720b58bbac72a978
prerequisite-patch-id: 0001484c6655bfd60677b5af414aac14cbcf7431
prerequisite-patch-id: 592c6729eac409319be242a8358b469236f159b3
prerequisite-patch-id: dfcbcf6d807e482d41bf04ac4e65227e8ab5f39d
prerequisite-patch-id: 9817811602db4b50fed170d50d43c1989dc06202
prerequisite-patch-id: 6f932774c07dbe23e95a0fa35cdb1d3d9122e84b
prerequisite-patch-id: 70d2333469ba724002e019f785ca50b6fe636648
prerequisite-patch-id: f29fad83d6c2e4bf4e9c4606b7bf1e150f2be3c6
prerequisite-patch-id: d4c58215c22b28a9b7488f666004e399b47dac8b
prerequisite-patch-id: 14734115bea19a7d037f8f68899ac8a4016b3b43
prerequisite-patch-id: 8e74affd6c728fd5096ce92e57bbff3126685151
Best regards,
--
Maxime Ripard <mripard@kernel.org>
^ permalink raw reply
* [PATCH v2 3/4] mfd: mt6397-core: add mt6323 EFUSE support
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 PMIC includes an EFUSE. Register the EFUSE in the mt6323
devices array to allow the corresponding driver to probe using compatible
string.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
drivers/mfd/mt6397-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 3e58d0764c7e..362737a1c4a9 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
static const struct mfd_cell mt6323_devs[] = {
{
+ .name = "mt6323-efuse",
+ .of_compatible = "mediatek,mt6323-efuse",
+ }, {
.name = "mt6323-rtc",
.num_resources = ARRAY_SIZE(mt6323_rtc_resources),
.resources = mt6323_rtc_resources,
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale, Conor Dooley
In-Reply-To: <20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The MediaTek mt6323 PMIC includes an EFUSE used for storing calibration
data.
Add the devicetree binding documentation for the MediaTek mt6323 EFUSE.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
.../devicetree/bindings/mfd/mediatek,mt6397.yaml | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 05c121b0cb3d..beaa67bf0df2 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -145,6 +145,23 @@ properties:
required:
- compatible
+ efuse:
+ type: object
+ unevaluatedProperties: false
+ description:
+ The efuse is responsible for storing calibration data, such as thermal
+ sensor calibration.
+
+ properties:
+ compatible:
+ const: mediatek,mt6323-efuse
+
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+
+ required:
+ - compatible
+
leds:
type: object
additionalProperties: false
@@ -243,6 +260,10 @@ examples:
interrupt-controller;
#interrupt-cells = <2>;
+ efuse {
+ compatible = "mediatek,mt6323-efuse";
+ };
+
leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/4] nvmem: add mt6323 PMIC EFUSE driver
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add support for the EFUSE controller found in the Mediatek MT6323 PMIC.
The MT6323 EFUSE stores 24 bytes of hardware-related data, such as
thermal sensor calibration values.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
MAINTAINERS | 5 +++
drivers/nvmem/Kconfig | 11 ++++++
drivers/nvmem/Makefile | 2 ++
drivers/nvmem/mt6323-efuse.c | 85 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 103 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..910360f148c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16256,6 +16256,11 @@ S: Maintained
F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
F: drivers/mmc/host/mtk-sd.c
+MEDIATEK MT6323 PMIC NVMEM DRIVER
+M: Roman Vivchar <rva333@protonmail.com>
+S: Maintained
+F: drivers/nvmem/mt6323-efuse.c
+
MEDIATEK MT6735 CLOCK & RESET DRIVERS
M: Yassine Oudjana <y.oudjana@protonmail.com>
L: linux-clk@vger.kernel.org
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..db248a3c4e87 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -227,6 +227,17 @@ config NVMEM_MTK_EFUSE
This driver can also be built as a module. If so, the module
will be called efuse-mtk.
+config NVMEM_MT6323_EFUSE
+ tristate "Mediatek MT6323 PMIC EFUSE support"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on MFD_MT6397
+ help
+ This is a driver to access hardware related data like sensor
+ calibration, etc.
+
+ This driver can also be built as a module. If so, the module
+ will be called efuse-mt6323.
+
config NVMEM_MXS_OCOTP
tristate "Freescale MXS On-Chip OTP Memory Support"
depends on ARCH_MXS || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d4..0e2b73f42b25 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -48,6 +48,8 @@ obj-$(CONFIG_NVMEM_MICROCHIP_OTPC) += nvmem-microchip-otpc.o
nvmem-microchip-otpc-y := microchip-otpc.o
obj-$(CONFIG_NVMEM_MTK_EFUSE) += nvmem_mtk-efuse.o
nvmem_mtk-efuse-y := mtk-efuse.o
+obj-$(CONFIG_NVMEM_MT6323_EFUSE) += nvmem_mt6323-efuse.o
+nvmem_mt6323-efuse-y := mt6323-efuse.o
obj-$(CONFIG_NVMEM_MXS_OCOTP) += nvmem-mxs-ocotp.o
nvmem-mxs-ocotp-y := mxs-ocotp.o
obj-$(CONFIG_NVMEM_NINTENDO_OTP) += nvmem-nintendo-otp.o
diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
new file mode 100644
index 000000000000..7a0ce4c7f565
--- /dev/null
+++ b/drivers/nvmem/mt6323-efuse.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2026 Roman Vivchar <rva333@protonmail.com>
+ */
+
+#include <linux/err.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+#include <linux/mfd/mt6323/registers.h>
+
+#define MT6323_EFUSE_DOUT_BASE MT6323_EFUSE_DOUT_0_15
+#define MT6323_EFUSE_SIZE 24
+
+static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct regmap *map = context;
+ u16 *buf = val;
+ u32 tmp;
+ int ret;
+
+ /*
+ * A manual loop using regmap_read is required because PWRAP is not
+ * a continuous MMIO space, but rather a FSM that doesn't implement the
+ * necessary read callback for the regmap_read_raw and regmap_read_bulk
+ * functions.
+ */
+ for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
+ ret = regmap_read(map, MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
+ if (ret)
+ return ret;
+
+ *buf++ = tmp;
+ }
+
+ return 0;
+}
+
+static int mt6323_efuse_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct nvmem_config config = {
+ .name = "mt6323-efuse",
+ .stride = 2,
+ .word_size = 2,
+ .size = MT6323_EFUSE_SIZE,
+ .reg_read = mt6323_efuse_read,
+ };
+ struct nvmem_device *nvmem;
+ struct regmap *regmap;
+
+ /* efuse -> mfd -> pwrap */
+ regmap = dev_get_regmap(dev->parent->parent, NULL);
+ if (!regmap)
+ return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
+
+ config.dev = dev;
+ config.priv = regmap;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ return PTR_ERR_OR_ZERO(nvmem);
+}
+
+static const struct of_device_id mt6323_efuse_of_match[] = {
+ { .compatible = "mediatek,mt6323-efuse" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mt6323_efuse_of_match);
+
+static struct platform_driver mt6323_efuse_driver = {
+ .probe = mt6323_efuse_probe,
+ .driver = {
+ .name = "mt6323-efuse",
+ .of_match_table = mt6323_efuse_of_match,
+ },
+};
+module_platform_driver(mt6323_efuse_driver);
+
+MODULE_DESCRIPTION("MediaTek MT6323 PMIC EFUSE driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/4] nvmem: add support for the MediaTek mt6323 PMIC
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale, Conor Dooley
This series adds support for the EFUSE found on the MediaTek mt6323 PMIC.
The previous version of the series for all AUXADC, EFUSE and thermal
drivers was split after Krzysztof's comment [1].
Tested on the MediaTek mt6572 and mt8163 SoCs (Ben), both paired with a
mt6323.
[1]: https://lore.kernel.org/linux-mediatek/20260504-mt6323-v1-0-799b58b355ff@protonmail.com/T/#med30fad67a090be35f549231336b2dec295233f6
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
Changes in v2:
- EFUSE driver: Sort variables in the mt6323_efuse_read (Andy)
- Link to v1: https://patch.msgid.link/20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com
Changes after split:
- EFUSE driver:
- Remove 'linux/errno.h' header (Andy)
- Remove explicit cast to u16 in the 'mt6323_efuse_read' (Andy)
- Reword comment in the 'mt6323_efuse_read'
- Capitalize MediaTek in the module description
- Link to a previous series: https://patch.msgid.link/20260512-mt6323-v2-0-3efcba579e88@protonmail.com
---
Roman Vivchar (4):
dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
nvmem: add mt6323 PMIC EFUSE driver
mfd: mt6397-core: add mt6323 EFUSE support
ARM: dts: mediatek: mt6323: add EFUSE support
.../devicetree/bindings/mfd/mediatek,mt6397.yaml | 21 ++++++
MAINTAINERS | 5 ++
arch/arm/boot/dts/mediatek/mt6323.dtsi | 4 +
drivers/mfd/mt6397-core.c | 3 +
drivers/nvmem/Kconfig | 11 +++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/mt6323-efuse.c | 85 ++++++++++++++++++++++
7 files changed, 131 insertions(+)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260611-mt6323-nvmem-0c54a0f2fa9f
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: mediatek: mt6323: add EFUSE support
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add the devicetree node for the mt6323 efuse.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
arch/arm/boot/dts/mediatek/mt6323.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index c230c865116d..807e000a7ff6 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -14,6 +14,10 @@ pmic: mt6323 {
interrupt-controller;
#interrupt-cells = <2>;
+ efuse {
+ compatible = "mediatek,mt6323-efuse";
+ };
+
mt6323_leds: leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Andy Shevchenko @ 2026-06-17 9:43 UTC (permalink / raw)
To: rva333
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260616-mt6323-adc-v3-2-1c27c588185d@protonmail.com>
On Tue, Jun 16, 2026 at 05:15:40PM +0300, Roman Vivchar via B4 Relay wrote:
> The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
> provides support for reading various channels including battery and
> charger voltages, battery and chip temperature, current sensing and
> accessory detection.
>
> Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
...
> +static int mt6323_auxadc_prepare_channel(struct mt6323_auxadc *auxadc)
> +{
> + struct regmap *map = auxadc->regmap;
> + u32 val;
> + int ret;
> +
> + ret = regmap_read(map, MT6323_AUXADC_CON19, &val);
> + if (ret)
> + return ret;
> +
> + /* The ADC is idle. */
> + if (!(val & AUXADC_CON19_DECI_GDLY_MASK))
> + return 0;
> + ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19, val,
> + !(val & AUXADC_ADC19_BUSY_MASK),
> + 10, 500);
Still can be amended.
ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19,
val, !(val & AUXADC_ADC19_BUSY_MASK),
10, 500);
(no need to resend just for this).
> + if (ret)
> + return ret;
> +
> + return regmap_clear_bits(map, MT6323_AUXADC_CON19,
> + AUXADC_CON19_DECI_GDLY_MASK);
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Lorenzo Bianconi @ 2026-06-17 9:17 UTC (permalink / raw)
To: Wayen Yan; +Cc: netdev, nbd, linux-arm-kernel, linux-mediatek
In-Reply-To: <178168650178.2224380.3950331731013129336@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2931 bytes --]
> On Tue, Jun 17, 2026, Lorenzo Bianconi wrote:
> > Even if the current codebase supports just AIROHA_NUM_QOS_CHANNEL (4), the hw
> > exposes 32 hw QoS channels (AIROHA_NUM_TX_RING). Here we are just clearing the
> > configuration, so I guess the current implementation is correct.
>
> Hi Lorenzo,
>
> You are right that there is no functional impact, and I agree this
> should not go to net. Let me explain the register layout I was worried
> about, and you can decide whether it is worth a net-next cleanup or
> should just be dropped.
>
> The two macros are:
>
> REG_QUEUE_CLOSE_CFG(_n) = 0x00a0 + ((_n) & 0xfc)
> TXQ_DISABLE_CHAN_QUEUE_MASK(_n, _m) = BIT((_m) + (((_n) & 0x3) << 3))
>
> REG_QUEUE_CLOSE_CFG() masks the channel with 0xfc, and the bit macro
> folds the channel with & 0x3 (mod 4) shifted by 3. So one 32-bit
> register holds 4 channels x 8 queues, 8 queue bits per channel:
>
> channel 0 -> reg 0x00a0, bits 0..7
> channel 1 -> reg 0x00a0, bits 8..15
> channel 2 -> reg 0x00a0, bits 16..23
> channel 3 -> reg 0x00a0, bits 24..31
> channel 4 -> reg 0x00a4, bits 0..7
> ...
>
> In airoha_qdma_set_chan_tx_sched() the loop variable 'i' is passed as
> the *queue* argument _m, not as a channel:
>
> for (i = 0; i < AIROHA_NUM_TX_RING; i++) // i = 0..31
> airoha_qdma_clear(qdma, REG_QUEUE_CLOSE_CFG(channel),
> TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
>
> Since each channel only has AIROHA_NUM_QOS_QUEUES (8) queues, the correct
> logic is to clear the 8 queue bits belonging to 'channel'. With i running
> up to 31 the BIT() shift instead walks past those 8 bits and into the bit
> ranges of the other channels folded into the same register. For channel 0
> the accumulated mask becomes 0xffffffff, i.e. it touches channels 1..3 as
> well.
>
> This is harmless today only because REG_QUEUE_CLOSE_CFG is written
> exclusively here, via airoha_qdma_clear() (RMW clear), and the register
> resets to 0 and is never set anywhere -- so clearing extra bits is a
> no-op. Functionally the current code is fine, as you say.
>
> The point is just the loop-bound semantics: 'i' is a per-channel queue
> index, so the bound should be AIROHA_NUM_QOS_QUEUES (8), not
> AIROHA_NUM_TX_RING (32). The two happen to be related (32 == 4 channels *
> 8 queues) but mean different things.
>
> Since there is no functional change, feel free to drop this if you would
> rather not carry a cosmetic patch. If you think the clarity is worth it I
> can resend against net-next without the Fixes tag.
>
> Thanks,
> Wayen
>
Sorry you are right, I misread the code, your patch is correct. Since as you
pointed out REG_QUEUE_CLOSE_CFG() is actually never set at the moment and the
default register value is 0, I would repost this patch for net-next as soon as
it is opened (this will avoid merge conflicts).
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH RESEND v3] wifi: mt76: mt7921: fix resource leak in probe error path
From: Hongling Zeng @ 2026-06-17 8:58 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee, shayne.chen, sean.wang, matthias.bgg,
angelogioacchino.delregno, xiong.huang, madhurkumar004
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
zhongling0719, Hongling Zeng
When pcim_iomap_region() or devm_kmemdup() fail, the code returns
directly without cleaning up previously allocated resources:
- mt76_device allocated by mt76_alloc_device()
- pci irq vectors allocated by pci_alloc_irq_vectors()
Fix this by jumping to the existing error cleanup path instead of
returning directly.
To avoid using an uninitialized variable in the error path, move the
dev initialization before the error checks.
Fixes: ee5bb35d2b83 ("wifi: mt76: mt7921: Replace deprecated PCI function")
Fixes: 222606f43b58 ("wifi: mt76: mt7921: handle MT7902 irq_map quirk with mutable copy")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
Change in v3
- Fix incorrect Fixes: tag as pointed out by Sean
- Correct tag from unrelated phy/ti-pipe3 commit to the actual mt76 commit
that introduced the resource leak
---
drivers/net/wireless/mediatek/mt76/mt7921/pci.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
index 7a790ddf43bb..49a37185f056 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
@@ -343,11 +343,14 @@ static int mt7921_pci_probe(struct pci_dev *pdev,
pci_set_drvdata(pdev, mdev);
+ dev = container_of(mdev, struct mt792x_dev, mt76);
+
regs = pcim_iomap_region(pdev, 0, pci_name(pdev));
- if (IS_ERR(regs))
- return PTR_ERR(regs);
+ if (IS_ERR(regs)) {
+ ret = PTR_ERR(regs);
+ goto err_free_dev;
+ }
- dev = container_of(mdev, struct mt792x_dev, mt76);
dev->fw_features = features;
dev->hif_ops = &mt7921_pcie_ops;
dev->irq_map = &irq_map;
@@ -359,8 +362,10 @@ static int mt7921_pci_probe(struct pci_dev *pdev,
/* MT7902 needs a mutable copy because wm2_complete_mask differs */
map = devm_kmemdup(&pdev->dev, &irq_map,
sizeof(irq_map), GFP_KERNEL);
- if (!map)
- return -ENOMEM;
+ if (!map) {
+ ret = -ENOMEM;
+ goto err_free_dev;
+ }
map->rx.wm2_complete_mask = 0;
dev->irq_map = map;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Wayen Yan @ 2026-06-17 8:55 UTC (permalink / raw)
To: lorenzo; +Cc: netdev, nbd, linux-arm-kernel, linux-mediatek
In-Reply-To: <178166704952.2212140.11002626760717132754@gmail.com>
On Tue, Jun 17, 2026, Lorenzo Bianconi wrote:
> Even if the current codebase supports just AIROHA_NUM_QOS_CHANNEL (4), the hw
> exposes 32 hw QoS channels (AIROHA_NUM_TX_RING). Here we are just clearing the
> configuration, so I guess the current implementation is correct.
Hi Lorenzo,
You are right that there is no functional impact, and I agree this
should not go to net. Let me explain the register layout I was worried
about, and you can decide whether it is worth a net-next cleanup or
should just be dropped.
The two macros are:
REG_QUEUE_CLOSE_CFG(_n) = 0x00a0 + ((_n) & 0xfc)
TXQ_DISABLE_CHAN_QUEUE_MASK(_n, _m) = BIT((_m) + (((_n) & 0x3) << 3))
REG_QUEUE_CLOSE_CFG() masks the channel with 0xfc, and the bit macro
folds the channel with & 0x3 (mod 4) shifted by 3. So one 32-bit
register holds 4 channels x 8 queues, 8 queue bits per channel:
channel 0 -> reg 0x00a0, bits 0..7
channel 1 -> reg 0x00a0, bits 8..15
channel 2 -> reg 0x00a0, bits 16..23
channel 3 -> reg 0x00a0, bits 24..31
channel 4 -> reg 0x00a4, bits 0..7
...
In airoha_qdma_set_chan_tx_sched() the loop variable 'i' is passed as
the *queue* argument _m, not as a channel:
for (i = 0; i < AIROHA_NUM_TX_RING; i++) // i = 0..31
airoha_qdma_clear(qdma, REG_QUEUE_CLOSE_CFG(channel),
TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
Since each channel only has AIROHA_NUM_QOS_QUEUES (8) queues, the correct
logic is to clear the 8 queue bits belonging to 'channel'. With i running
up to 31 the BIT() shift instead walks past those 8 bits and into the bit
ranges of the other channels folded into the same register. For channel 0
the accumulated mask becomes 0xffffffff, i.e. it touches channels 1..3 as
well.
This is harmless today only because REG_QUEUE_CLOSE_CFG is written
exclusively here, via airoha_qdma_clear() (RMW clear), and the register
resets to 0 and is never set anywhere -- so clearing extra bits is a
no-op. Functionally the current code is fine, as you say.
The point is just the loop-bound semantics: 'i' is a per-channel queue
index, so the bound should be AIROHA_NUM_QOS_QUEUES (8), not
AIROHA_NUM_TX_RING (32). The two happen to be related (32 == 4 channels *
8 queues) but mean different things.
Since there is no functional change, feel free to drop this if you would
rather not carry a cosmetic patch. If you think the clarity is worth it I
can resend against net-next without the Fixes tag.
Thanks,
Wayen
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: btmtk: Add MT7928 support
From: Paul Menzel @ 2026-06-17 8:49 UTC (permalink / raw)
To: Chris Lu (陸稚泓)
Cc: Will-CY Lee (李政穎),
Steve Lee (李視誠), luiz.dentz, marcel,
SS Wu (巫憲欣), linux-kernel, johan.hedberg,
Sean Wang, linux-bluetooth, linux-mediatek
In-Reply-To: <c983c544a39606e1468158a7b6fdc77b6ca5c8a2.camel@mediatek.com>
Dear Chris,
Thank you for your reply.
Am 17.06.26 um 10:34 schrieb Chris Lu (陸稚泓):
> On Wed, 2026-06-17 at 08:53 +0200, Paul Menzel wrote:
>>
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>> Am 17.06.26 um 04:16 schrieb Chris Lu (陸稚泓):
>>
>>> On Tue, 2026-06-16 at 12:24 +0200, Paul Menzel wrote:
>>
>>>> Am 16.06.26 um 05:01 schrieb Chris Lu:
>>>>> Add support for MT7928 (device ID 0x7935) which requires
>>>>> additional
>>>>> firmware (CBMCU firmware) loading before Bluetooth firmware.
>>>>
>>>> Please detail what CBMCU firmware is.
>>>
>>> CBMCU is a new component on MT7928 to handle common part shared across
>>> the combo chip (Wi-Fi/Bluetooth's subsystem), providing a better user
>>> experience through improved coordination between subsystems.
>>
>> Thank you, but please add it to the commit message.
>>
>>>>> Implement two-phase CBMCU firmware download: Phase 1 loads
>>>>> section with type 0x5 containing global descriptor,
>>>>> section maps and signature data; Phase 2 loads remaining
>>>>> firmware sections. Add retry mechanism for concurrent download
>>>>> protection.
>>>>
>>>> What is type 0x5? How big is the firmware, and how long does it
>>>> take?
>>>>
>>>>> After CBMCU firmware loads successfully, the driver continues
>>>>> to load corresponding BT firmware based on device ID through
>>>>> fallthrough to case 0x7922/0x7925.
>>>>
>>>> Please add the new log message to the commit message.
>>
>> Thank you for adding those. Please also mention, where to find the
>> new firmware.
>>
>> […]
>
> Since MT7928 hasn't been deployed in any commercially available
> products yet, MediaTek currently plans to send driver patch first and
> upload firmware part after done a series of internal test to make sure
> the quality.
Understood. Also something for the commit message. ;-)
I wonder, if this should only be put into Linus’ master branch, once the
firmware is available.
Kind regards,
Paul
>> PS: Also, Pauli’s question should be answered in the commit message
>> (internal/external name). (If questions show up during review, it’s a
>> good indicator to amend the commit message answering these
>> questions.)
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: btmtk: Add MT7928 support
From: Chris Lu (陸稚泓) @ 2026-06-17 8:34 UTC (permalink / raw)
To: pmenzel@molgen.mpg.de
Cc: Will-CY Lee (李政穎),
Steve Lee (李視誠), luiz.dentz@gmail.com,
marcel@holtmann.org, SS Wu (巫憲欣),
linux-kernel@vger.kernel.org, johan.hedberg@gmail.com, Sean Wang,
linux-bluetooth@vger.kernel.org,
linux-mediatek@lists.infradead.org
In-Reply-To: <4501985d-c8df-4121-89fd-0b4eb09273c6@molgen.mpg.de>
Hi Paul,
On Wed, 2026-06-17 at 08:53 +0200, Paul Menzel wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> Dear Chris,
>
>
> Thank you for your answer, and sending in v2.
>
> Am 17.06.26 um 04:16 schrieb Chris Lu (陸稚泓):
>
> > On Tue, 2026-06-16 at 12:24 +0200, Paul Menzel wrote:
>
> > > Am 16.06.26 um 05:01 schrieb Chris Lu:
> > > > Add support for MT7928 (device ID 0x7935) which requires
> > > > additional
> > > > firmware (CBMCU firmware) loading before Bluetooth firmware.
> > >
> > > Please detail what CBMCU firmware is.
> >
> > CBMCU is a new component on MT7928 to handle common part shared
> > across
> > the combo chip (Wi-Fi/Bluetooth's subsystem), providing a better
> > user
> > experience through improved coordination between subsystems.
>
> Thank you, but please add it to the commit message.
>
> > > > Implement two-phase CBMCU firmware download: Phase 1 loads
> > > > section with type 0x5 containing global descriptor,
> > > > section maps and signature data; Phase 2 loads remaining
> > > > firmware sections. Add retry mechanism for concurrent download
> > > > protection.
> > >
> > > What is type 0x5? How big is the firmware, and how long does it
> > > take?
> > >
> > > > After CBMCU firmware loads successfully, the driver continues
> > > > to load corresponding BT firmware based on device ID through
> > > > fallthrough to case 0x7922/0x7925.
> > >
> > > Please add the new log message to the commit message.
>
> Thank you for adding those. Please also mention, where to find the
> new
> firmware.
>
> […]
Since MT7928 hasn't been deployed in any commercially available
products yet, MediaTek currently plans to send driver patch first and
upload firmware part after done a series of internal test to make sure
the quality.
>
>
> Kind regards,
>
> Paul
>
>
> PS: Also, Pauli’s question should be answered in the commit message
> (internal/external name). (If questions show up during review, it’s a
> good indicator to amend the commit message answering these
> questions.)
Chris Lu
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix off-by-one error in HTB rate-limit channel removal
From: Lorenzo Bianconi @ 2026-06-17 7:13 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166483303.2209640.10761097847073356089@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
> In airoha_tc_remove_htb_queue(), the rate-limit was being cleared
> using (queue + 1) instead of queue, causing:
> - The original channel rate-limit configuration to remain active
> - The next channel to be incorrectly disabled
> - Potential out-of-bounds access when queue == 3 (channel 4)
>
> The alloc path (airoha_tc_htb_alloc_leaf_queue) correctly uses
> channel (0..3), but the remove path incorrectly added 1.
>
> Fix by using queue directly to match the alloc and rollback paths.
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..02807b3967 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2805,7 +2805,7 @@ static void airoha_tc_remove_htb_queue(struct net_device *dev, int queue)
> struct airoha_gdm_port *port = netdev_priv(dev);
>
> netif_set_real_num_tx_queues(dev, dev->real_num_tx_queues - 1);
> - airoha_qdma_set_tx_rate_limit(dev, queue + 1, 0, 0);
> + airoha_qdma_set_tx_rate_limit(dev, queue, 0, 0);
> clear_bit(queue, port->qos_sq_bmap);
> }
Please hold on with this patch, I am aware of the bug and the fix is already in
my queue [0]. I am just waiting the net-next to be merged into net in order to
avoid merge conflicts.
Regards,
Lorenzo
[0] https://github.com/LorenzoBianconi/net-next/commits/airoha-qos-fixes-for-net/
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] wifi: mt76: mt7925: fix msg len mismatch between driver and firmware
From: JB Tsai @ 2026-06-17 7:13 UTC (permalink / raw)
To: nbd, lorenzo
Cc: linux-wireless, linux-mediatek, Deren.Wu, Sean.Wang, Quan.Zhou,
Ryder.Lee, Leon.Yen, litien.chang, jared.huang, jb.tsai
From: "Jared.Huang" <jared.huang@mediatek.com>
The mt7925_tx_power_limit_tlv struct begins with a 4-byte rsv[] field
that acts as a UNI command header prefix. The firmware dispatcher did
not use the 4-byte rsv[] and will only check the payloads after the
4-byte rsv[] As a result, the total message length minus the 4-byte
prefix. Fix this by setting len to msg_len - 4.
Fixes: ccb1863 ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Jared.Huang <jared.huang@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index e94fa544ff20..7d9b8ebf2889 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -3827,7 +3827,7 @@ mt7925_mcu_rate_txpower_band(struct mt76_phy *phy,
memcpy(tx_power_tlv->alpha2, dev->alpha2, sizeof(dev->alpha2));
tx_power_tlv->n_chan = num_ch;
tx_power_tlv->tag = cpu_to_le16(0x1);
- tx_power_tlv->len = cpu_to_le16(msg_len);
+ tx_power_tlv->len = cpu_to_le16(msg_len - 4);
switch (band) {
case NL80211_BAND_2GHZ:
--
2.45.2
^ permalink raw reply related
* [PATCH] wifi: mt76: mt7925: update clc before setting sar power table
From: JB Tsai @ 2026-06-17 7:13 UTC (permalink / raw)
To: nbd, lorenzo
Cc: linux-wireless, linux-mediatek, Deren.Wu, Sean.Wang, Quan.Zhou,
Ryder.Lee, Leon.Yen, litien.chang, jared.huang, jb.tsai
From: "Jared.Huang" <jared.huang@mediatek.com>
Fix the power table update sequence to ensure CLC is loaded before
setting SAR power table.
The firmware requires CLC baseline to be established first
to properly calculate the final power limit as min(clc_limit, rate_limit,sar_limit).
Fixes: 9557b6fe0c8b ("wifi: mt76: mt7925: refine the txpower initialization flow")
Signed-off-by: Jared.Huang <jared.huang@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index a9059866b701..afb2b473bef7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -1824,9 +1824,15 @@ static int mt7925_set_sar_specs(struct ieee80211_hw *hw,
int err;
mt792x_mutex_acquire(dev);
+ err = mt7925_mcu_set_clc(dev, dev->mt76.alpha2,
+ dev->country_ie_env);
+ if (err < 0)
+ goto out;
+
err = mt7925_set_tx_sar_pwr(hw, sar);
- mt792x_mutex_release(dev);
+out:
+ mt792x_mutex_release(dev);
return err;
}
--
2.45.2
^ permalink raw reply related
* Re: [PATCH net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Lorenzo Bianconi @ 2026-06-17 7:10 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166704952.2212140.11002626760717132754@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]
> In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
> using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
>
> Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
> computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
> - channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
> - channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
> - channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
> - channel 3: clears bit 24..31 (channel 3 only) - correct by accident
>
> While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
> mask parameter, the loop still incorrectly clears queues within the
> same channel beyond queue 7.
>
> Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..a1eda13400 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2217,7 +2217,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
> struct airoha_gdm_port *port = netdev_priv(dev);
> int i;
>
> - for (i = 0; i < AIROHA_NUM_TX_RING; i++)
> + for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
> airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
> TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
Even if the current codebase supports just AIROHA_NUM_QOS_CHANNEL (4), the hw
exposes 32 hw QoS channels (AIROHA_NUM_TX_RING). Here we are just clearing the
configuration, so I guess the current implementation is correct.
Regards,
Lorenzo
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4] ASoC: dt-bindings: mtk-btcvsd-snd: Convert to DT Schema
From: Krzysztof Kozlowski @ 2026-06-17 7:00 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-sound, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260615185810.11804-1-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 08:57:50PM +0200, Luca Leonardo Scorcia wrote:
> Convert the mtk-btcvsd-snd.txt DT binding to DT Schema format.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> Changes in v4:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths
From: Lorenzo Bianconi @ 2026-06-17 6:58 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178167550101.2217645.14579307712717502425@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
> In mtk_ppe_init(), when accounting is enabled, the error paths for
> dmam_alloc_coherent(mib) and devm_kzalloc(acct) failures return NULL
> directly, bypassing the err_free_l2_flows label that destroys the
> rhashtable initialized earlier.
>
> While this leak only occurs during probe (not runtime) and the leaked
> memory is minimal (an empty rhash table), fixing it ensures proper
> error path cleanup consistency.
>
> Fix by changing the two return NULL statements to goto err_free_l2_flows.
>
> Fixes: 603ea5e7ffa7 ("net: ethernet: mtk_eth_soc: fix memory leak in error path")
> Signed-off-by: Wayen Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/mediatek/mtk_ppe.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
> index 18279e2a70..8451dc3fd0 100644
> --- a/drivers/net/ethernet/mediatek/mtk_ppe.c
> +++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
> @@ -918,7 +918,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
> mib = dmam_alloc_coherent(ppe->dev, MTK_PPE_ENTRIES * sizeof(*mib),
> &ppe->mib_phys, GFP_KERNEL);
> if (!mib)
> - return NULL;
> + goto err_free_l2_flows;
>
> ppe->mib_table = mib;
>
> @@ -926,7 +926,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
> GFP_KERNEL);
>
> if (!acct)
> - return NULL;
> + goto err_free_l2_flows;
>
> ppe->acct_table = acct;
> }
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [Bug 221660] New: btmtk (MT7921K / RZ608): BR/EDR outgoing connection always fails with Page Timeout (0x04); scan/receive works, same device pairs fine on Windows
From: Paul Menzel @ 2026-06-17 6:57 UTC (permalink / raw)
To: Sean Wang, Sean Wang
Cc: Chris Lu (陸稚泓), linux-mediatek,
linux-bluetooth
In-Reply-To: <bug-221660-62941@https.bugzilla.kernel.org/>
[Cc: +Mediatek]
Am 17.06.26 um 00:39 schrieb bugzilla-daemon@kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=221660
>
> Bug ID: 221660
> Summary: btmtk (MT7921K / RZ608): BR/EDR outgoing connection
> always fails with Page Timeout (0x04); scan/receive
> works, same device pairs fine on Windows
> Product: Drivers
> Version: 2.5
> Kernel Version: 7.0.12-arch1-1
> Hardware: AMD
> OS: Linux
> Status: NEW
> Severity: normal
> Priority: P3
> Component: Bluetooth
> Assignee: linux-bluetooth@vger.kernel.org
> Reporter: bynxmusic@gmail.com
> Regression: No
>
> Created attachment 310333
> --> https://bugzilla.kernel.org/attachment.cgi?id=310333&action=edit
> btmon HCI trace (binary + decoded) of the Page Timeout + system info
>
> btmtk (MT7921K / RZ608): every BR/EDR outgoing connection fails with Page
> Timeout (0x04). Scan/receive works, and the same device pairs fine on Windows.
>
> HARDWARE
> WiFi+BT combo: MediaTek MT7921K (RZ608) Wi-Fi 6E, PCI 14c3:0608, driver mt7921e
> Bluetooth function: USB 0e8d:0608 (MediaTek Inc. Wireless_Device), btusb + btmtk
> Motherboard onboard radio, AMD desktop platform
>
> SOFTWARE
> Kernel: 7.0.12-arch1-1 (x86_64), Arch Linux (rolling)
> linux-firmware: 20260519-1 ; linux-firmware-mediatek: 20260519-1
> BlueZ: 5.86
> BT controller firmware: HW/SW Version 0x008a008a, Build Time 20260224111243
> BT firmware blob loads OK: mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
>
> WHAT WORKS
> Controller initializes cleanly every boot ("hci0: Device setup in ~160000
> usecs", AOSP extensions v1.00). Inquiry/scan works: remote devices (a
> Skullcandy Crusher Evo headset and a Samsung TV) are reliably discovered with
> RSSI, so the RX path is fine.
>
> THE BUG
> Every outgoing connection (page) to any BR/EDR device times out. HCI Create
> Connection is issued and accepted (Command Status: Success), but roughly 7.7
> s
> later the controller returns Connect Complete with Status: Page Timeout (0x04).
> BlueZ reports org.bluez.Error.ConnectionAttemptFailed. The remote device never
> registers a connection. The same headset on the same PC pairs and works
> perfectly under Windows, so this is not dead hardware or a peripheral issue;
> it is the btmtk/MT7921K outgoing-connection path on Linux.
>
> KEY HCI TRACE (btmon), captured with the WiFi driver (mt7921e) UNLOADED, i.e.
> WiFi/BT coexistence ruled out:
>
> < HCI Command: Create Connection (0x01|0x0005) plen 13 #9 [hci0] 14.208614
> Address: 88:08:94:13:8F:94 (Skullcandy)
> Packet type: 0xcc18 (DM1/DH1/DM3/DH3 ...)
> > HCI Event: Command Status (0x0f) plen 4 #10 [hci0] 14.209664
> Create Connection (0x01|0x0005) ncmd 1
> Status: Success (0x00)
> > HCI Event: Connect Complete (0x03) plen 11 #11 [hci0] 21.899975
> Status: Page Timeout (0x04)
> Handle: 0
> Address: 88:08:94:13:8F:94 (Skullcandy)
> Link type: ACL (0x01)
>
> Also seen intermittently in dmesg during attempts:
> Bluetooth: hci0: ACL packet for unknown connection handle 3837
>
> STEPS TO REPRODUCE
> 1. Boot with MT7921K onboard Bluetooth.
> 2. Put any BR/EDR device (e.g. a freshly factory-reset BT headset) in pairing
> mode.
> 3. In bluetoothctl: scan on (device IS discovered), then pair <MAC>.
> 4. Pairing fails with org.bluez.Error.ConnectionAttemptFailed; btmon shows
> Connect Complete: Page Timeout (0x04).
>
> EXPECTED vs ACTUAL
> Expected: Create Connection succeeds and pairing/bonding proceeds (as on
> Windows).
> Actual: every Create Connection ends in Page Timeout; no outgoing connection
> ever completes.
>
> ALREADY RULED OUT
> - USB autosuspend: disabled via options btusb enable_autosuspend=0 (confirmed
> power/control=on). No change.
> - WiFi/BT coexistence: Page Timeout persists even with mt7921e fully unloaded
> (modprobe -r mt7921e); the trace above is from that state. Also tested with
> rfkill block wifi. No change.
> - LE vs BR/EDR bearer: tested with and without Experimental, and with
> ControllerMode = bredr. No change.
> - Stale/half state: reproduced after a fresh cold boot (controller not
> wedged).
> - Remote device: Crusher Evo factory-reset; nothing else paired to it
> (phone/TV BT off); works on Windows.
>
> ATTACHMENTS
> - bt-hci-trace.btsnoop: full binary btmon capture of one failed pairing.
> - bt-bugreport.txt: full system diagnostic bundle (versions, lspci/lsusb, dmesg).
^ 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