On Thu, 04 May 2023 09:58:44 +0200,
Takashi Iwai wrote:
>
> On Thu, 04 May 2023 09:35:38 +0200,
> Takashi Iwai wrote:
> >
> > On Thu, 04 May 2023 03:09:45 +0200,
> > Mark Brown wrote:
> > >
> > > Hi,
> > >
> > > Here's another mail (one of several in this series) that got completely
> > > mangled by the alsa-project.org mailman to the point of unusability. I
> > > didn't see any response to my last mail about this, is there any news on
> > > fixing mailman to not do this? It's extremely disruptive to working
> > > with lore.
> >
> > It seems that alsa-project.org mailman re-sends the post with
> > xxx@xxxxxxxxxxxxxxxx address sometimes, indeed. I don't know the
> > condition, but now I noticed it while checking the pending approvals.
>
> And, I guess it happens when a post comes from a non-subscriber.
> (But not sure whether this happens always...)
> It waits for approval, but also mangles the sender address and co.
> This behavior is new after the mail server update.
Jaroslav, could you investigate it? I checked again, and it seems
that all "approved" posts from non-subscribers are modified to the
sender addresses with alsa-project.org. I guess there must be some
option to prevent it.
Takashi
> > Those that appeared in the list wrongly were likely the posts I
> > approved without knowing them being superfluously resent ones.
> >
> > Jaroslav, could you check your mailman configuration?
>
> So, please check the configuration. As of now, the post from
> non-subscriber becomes confusing and unusable for b4.
>
>
> thanks,
>
> Takashi
>
> >
> >
> > thanks,
> >
> > Takashi
> >
> > > Thanks,
> > > Mark
> > > Subject: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe
> > > From: AngeloGioacchino Del Regno via Alsa-devel <alsa-devel@xxxxxxxxxxxxxxxx>
> > > Date: Wed, 03 May 2023 13:34:11 +0200
> > > Message-Id: <168311377075.26.14919941665402646886@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> > > MIME-Version: 1.0
> > > Content-Transfer-Encoding: 7bit
> > >
> > > Use devm_pm_runtime_enable() and pm_runtime_resume_and_get() to
> > > to simplify the probe function.
> > >
> > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx>
> > > ---
> > > sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 22 ++++++++++++----------
> > > 1 file changed, 12 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> > > index 9e45efeada55..a54c16e0aa05 100644
> > > --- a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> > > +++ b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> > > @@ -3179,16 +3179,16 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
> > >
> > > mt8195_afe_parse_of(afe, pdev->dev.of_node);
> > >
> > > - pm_runtime_enable(dev);
> > > - if (!pm_runtime_enabled(dev)) {
> > > - ret = mt8195_afe_runtime_resume(dev);
> > > - if (ret)
> > > - return ret;
> > > - }
> > > -
> > > /* enable clock for regcache get default value from hw */
> > > afe_priv->pm_runtime_bypass_reg_ctl = true;
> > > - pm_runtime_get_sync(dev);
> > > +
> > > + ret = devm_pm_runtime_enable(dev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = pm_runtime_resume_and_get(dev);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Failed to resume device\n");
> > >
> > > afe->regmap = devm_regmap_init_mmio(&pdev->dev, afe->base_addr,
> > > &mt8195_afe_regmap_config);
> > > @@ -3238,7 +3238,10 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
> > >
> > > mt8195_afe_init_registers(afe);
> > >
> > > - pm_runtime_put_sync(dev);
> > > + ret = pm_runtime_put_sync(dev);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Failed to suspend device\n");
> > > +
> > > afe_priv->pm_runtime_bypass_reg_ctl = false;
> > >
> > > regcache_cache_only(afe->regmap, true);
> > > @@ -3248,7 +3251,6 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
> > >
> > > err_pm_put:
> > > pm_runtime_put_sync(dev);
> > > - pm_runtime_disable(dev);
> > >
> > > return ret;
> > > }
> > > --
> > > 2.40.1
