Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]
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@alsa-project.org address sometimes, indeed. I don't know the condition, but now I noticed it while checking the pending approvals. 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?
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@alsa-project.org Date: Wed, 03 May 2023 13:34:11 +0200 Message-Id: 168311377075.26.14919941665402646886@mailman-core.alsa-project.org 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@collabora.com
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
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@alsa-project.org 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.
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@alsa-project.org Date: Wed, 03 May 2023 13:34:11 +0200 Message-Id: 168311377075.26.14919941665402646886@mailman-core.alsa-project.org 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@collabora.com
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
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@alsa-project.org 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@alsa-project.org Date: Wed, 03 May 2023 13:34:11 +0200 Message-Id: 168311377075.26.14919941665402646886@mailman-core.alsa-project.org 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@collabora.com
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
On 08. 05. 23 9:52, Takashi Iwai wrote:
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@alsa-project.org 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.
The answer is DMARC. And the "mangling" applies only to senders which domains have restricted DMARC settings (reject or quarantine) - collabora.com has quarantine. More information:
https://lore.kernel.org/alsa-devel/6f003598-4cae-a521-233f-2c19eb439359@pere...
I am open to any suggestions, but the default mailman settings (do not do anything) causes that some (mostly gmail) users do not receive their e-mails because the ALSA's mail server has a bad reputation. Many companies are using the google mail service for their domains nowadays.
The information is not lost - the original e-mail is just encapsulated (as an attachmnent) to new with the "allowed from" header for DMARC. But yes, it requires some more work (reply to the attachment, update scripts).
Jaroslav
On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote:
I am open to any suggestions, but the default mailman settings (do not do anything) causes that some (mostly gmail) users do not receive their e-mails because the ALSA's mail server has a bad reputation. Many companies are using the google mail service for their domains nowadays.
As a GMail user, I can confirm that I'm not seeing any more bounces after mangling started. Usually it'd bounce and I'd have to login to the web interface to turn back on my subscription, a real pain.
Jaroslav
-- Jaroslav Kysela perex@perex.cz Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
On Wed, May 10, 2023 at 1:52 AM Geraldo Nascimento geraldogabriel@gmail.com wrote:
On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote:
I am open to any suggestions, but the default mailman settings (do not do anything) causes that some (mostly gmail) users do not receive their e-mails because the ALSA's mail server has a bad reputation. Many companies are using the google mail service for their domains nowadays.
As a GMail user, I can confirm that I'm not seeing any more bounces after mangling started. Usually it'd bounce and I'd have to login to the web interface to turn back on my subscription, a real pain.
FWIW the dri-devel mailing list seems to implement an alternative strategy for dealing with Gmail and co. bouncing messages. If it gets bounces it will send a separate "bounce probe" email including details about what bounced. It will not just deactivate a subscription due to bounces.
Also, ALSA's mailing list now requires a subscriber to register a user account to resume delivery is a bit annoying.
ChenYu
On 10. 05. 23 5:01, Chen-Yu Tsai wrote:
On Wed, May 10, 2023 at 1:52 AM Geraldo Nascimento geraldogabriel@gmail.com wrote:
On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote:
I am open to any suggestions, but the default mailman settings (do not do anything) causes that some (mostly gmail) users do not receive their e-mails because the ALSA's mail server has a bad reputation. Many companies are using the google mail service for their domains nowadays.
As a GMail user, I can confirm that I'm not seeing any more bounces after mangling started. Usually it'd bounce and I'd have to login to the web interface to turn back on my subscription, a real pain.
FWIW the dri-devel mailing list seems to implement an alternative strategy for dealing with Gmail and co. bouncing messages. If it gets bounces it will send a separate "bounce probe" email including details about what bounced. It will not just deactivate a subscription due to bounces.
The probes are enabled for the ALSA's mailing lists, but when the incoming servers decide to not accept any e-mails (as gmail does), they will be lost.
Also, ALSA's mailing list now requires a subscriber to register a user account to resume delivery is a bit annoying.
I tried to set higher thresholds for bounces.
Jaroslav
participants (4)
-
Chen-Yu Tsai
-
Geraldo Nascimento
-
Jaroslav Kysela
-
Takashi Iwai