- Sound-open-firmware - mailman.alsa-project.org

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])
by Jaroslav Kysela 09 May '23

09 May '23

On 09. 05. 23 16:35, Mark Brown wrote: > On Tue, May 09, 2023 at 11:54:18AM +0200, Jaroslav Kysela wrote: > >> The signature is correct in the encapsulated original e-mail. The b4 should >> be improved in my opinion. > > It's not b4 that's the issue here except in that it causes me to fetch > copies of the message that went to the list instead of my inbox which > didn't get mangled by the list. git am just does not understand what's b4 can detect, if the e-mail is wrapped and use only the wrapped message. The wrapping is the correct semantics per mailman 3 not mangling (see [1]). https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/d… > happening with attachments. For example for: > > 168198605952.26.13645408104113633580(a)mailman-core.alsa-project.org > > if I try to apply it the top of the commit message looks like: > > | commit 8f0e0ee514b189cf7b4e7fa09581e3f1d246fa09 (HEAD -> tmp) > | Author: Richard Fitzgerald via Alsa-devel <alsa-devel(a)alsa-project.org> > | Date: Thu Apr 20 11:20:43 2023 +0100 > | > | ASoC: cs35l56: Remove duplicate mbox log messages > | > | Received: by alsa1.perex.cz (Postfix, from userid 50401) > | id 7A47CF80155; Thu, 20 Apr 2023 12:20:56 +0200 (CEST) > | X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on alsa1.perex.cz > > with all the headers dumped in there which is just completely mangled. > Note the rewritten author. You should apply the wrapped message not the capsule. > mutt also represents this incredibly badly, it just shows the > "attachment" as the body of the message with all the headers dumped in > like they're just plain text in the body of the mail - I wouldn't have > thought this was an attachment if it hadn't been mentioned in this > thread, none of the atacment UI shows. To reverse the mangling you have > to view attachments then save the root of the message to a folder. AIUI > mutt assumes that whatever the root of the message is is intended to be > the message body and does the best it can to display it as such. I think that you can configure the tool to process this attachment in mutt. > Lore *does* show the body of the message as an attachment. Yes, the original message is in the attachment - no information is lost. >> As you see, the header and all signatures are correct in the attachment: > > None of our tooling or processes understand this, they're working with > the top level message. > >>> Is it possible to take steps to improve the reptuation of the ALSA >>> servers so this isn't needed, or could we migrate the lists elsewhere (I > >> It is not possible to talk with gmail administrators. I tried that several >> times. The outgoing ALSA server is not on any spam list. > > I know there is a lot of discussion going round about which hoops to > jump through to play nice with gmail, I don't know if there's any new > stuff that's come up there recently. > >>> know we set up linux-sound@vger at one point with the idea of >>> migrating). > >> I guess that the vger servers have similar issues, because servers with >> DMARC enabled on the ingress side can reject e-mails. It's related to e-mail >> standards. > > The issue I'm seeing here is the rewriting which I'm not aware of any > other lists having turned on, even infradead ones which are also mailman > based. Either they're just tolerating people having issues with gmail > (which seems reasonable TBH) or they're jumping through some additional > hoops to avoid issues. I checked infradead and they're using mailman 2. Mailman 2 does not support DMARC mitigation. > I believe vger does sometimes manage some backchannel which probably > helps it somewhat. Using a non-standard mechanism is not a big win. DMARC is a internet standard - see RFC7489, RFC8616. It means that the mailing lists cannot send e-mails with From from other domains which have restricted policies set by *their* administrators. So basically, all mail servers violates this if they keep the From header. Mailman 3 implemented several types of mitigations and the message wrap is the best one in my eyes. The mangling of the From header or reject e-mails from those senders is even worse (see [1]). When I turn off the mitigation in mailman, my ALSA server will have bad reputation for gmail users soon in an unpredictable manner. I also saw that ATT incoming mail servers had similar issues. We can expect that the list of the ingress SMTP servers not accepting e-mails based on the DMARC policy will grow. It's something that we don't have under control. If we don't find that it's time to move forward and accept this policy, I can turn off the mitigation, but in a cost that gmail (and soon maybe other) users will bomb me (they already did last years) that the ALSA mail server does not deliver e-mails for them. Are we a community on internet or not? Ideally, we should start upgrade and fix our tools... Let me just know, if you (and Takashi) insist to turn the mitigation off after this discussion. I'll do so... Jaroslav [1] https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/d… -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

2 1

[PATCH] ASoC: SOF: amd: Fix NULL pointer crash in acp_sof_ipc_msg_data function
by V sujith kumar Reddy 09 May '23

09 May '23

Check substream and runtime variables before assigning. Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy(a)amd.com> --- sound/soc/sof/amd/acp-ipc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/amd/acp-ipc.c b/sound/soc/sof/amd/acp-ipc.c index 4e0c48a36159..749e856dc601 100644 --- a/sound/soc/sof/amd/acp-ipc.c +++ b/sound/soc/sof/amd/acp-ipc.c @@ -209,7 +209,12 @@ int acp_sof_ipc_msg_data(struct snd_sof_dev *sdev, struct snd_sof_pcm_stream *sp acp_mailbox_read(sdev, offset, p, sz); } else { struct snd_pcm_substream *substream = sps->substream; - struct acp_dsp_stream *stream = substream->runtime->private_data; + struct acp_dsp_stream *stream; + + if (!substream || !substream->runtime) + return -ESTRPIPE; + + stream = substream->runtime->private_data; if (!stream) return -ESTRPIPE; -- 2.25.1

2 1

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]
by Geraldo Nascimento 08 May '23

08 May '23

On Mon, May 08, 2023 at 08:33:59AM +0900, Mark Brown wrote: > On Fri, May 05, 2023 at 11:17:19PM -0300, Geraldo Nascimento wrote: > > On Sat, May 06, 2023 at 09:13:06AM +0900, Mark Brown wrote: > > > > Not just the headers in the message, the author information for the mail > > > also got rewritten. Try applying the patches with git am... > > > Mark, I think Jaroslav can change the behaviour in the the added Headers in the > > body of the message (the added Headers in the body have e.g. the correct From: > > email information). > > > If the message body *starts* with the "From:", "Subject:" and "Date:" fields > > I think git-am will pickup the correct information from the body instead of from > > the mangled headers. > > > Hopefully... > > No, it absolutely doesn't work properly - I only noticed this was > happening because b4/lore keep picking the copy from alsa-devel which is > mangled to the point of not being usable. Hi Mark, sorry to hear that. The fact mailman is disrupting your workflow as ASoC maintainer is alarming, and I hope you and Jaroslav can work out a solution. But besides my suggestion that the added headers in the body of the message *start* with at least the correct "From:" field, I can't be of much help. Thanks for the hard work, Geraldo Nascimento

1 0

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]
by Geraldo Nascimento 06 May '23

06 May '23

On Sat, May 06, 2023 at 09:13:06AM +0900, Mark Brown wrote: > On Fri, May 05, 2023 at 05:38:28PM -0300, Geraldo Nascimento wrote: > > On Thu, May 04, 2023 at 10:09:45AM +0900, Mark Brown wrote: > > > > 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. > > > Are you complaining about the added headers in the message? Because the > > patch itself didn't look mangled from my side. From my understanding, > > Jaroslav had to start mangling mail addresses due to strict DMARC rules > > which make some servers reject the message from alsa-devel. > > Not just the headers in the message, the author information for the mail > also got rewritten. Try applying the patches with git am... Mark, I think Jaroslav can change the behaviour in the the added Headers in the body of the message (the added Headers in the body have e.g. the correct From: email information). If the message body *starts* with the "From:", "Subject:" and "Date:" fields I think git-am will pickup the correct information from the body instead of from the mangled headers. Hopefully... Good luck, Geraldo Nascimento

1 0

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]
by Geraldo Nascimento 05 May '23

05 May '23

On Thu, May 04, 2023 at 10:09:45AM +0900, 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. Hi Mark, Are you complaining about the added headers in the message? Because the patch itself didn't look mangled from my side. From my understanding, Jaroslav had to start mangling mail addresses due to strict DMARC rules which make some servers reject the message from alsa-devel. Thanks, Geraldo Nascimento > > Thanks, > Mark

1 0

Bad magic error when loading SOF firmware
by David Sayada 04 May '23

04 May '23

Hello SOF team, We are trying to evaluate the SOF project on our 8MPLUSSLPD4-EVK based product, and we are getting some issues when trying to run one of the "yocto compiled" SOF Firmware. Below is the procedure we are trying to perform: *echo /lib/firmware/imx/sof/sof-imx8m.ri > /sys/class/remoteproc/remoteproc0/firmware* *echo start > /sys/class/remoteproc/remoteproc0/state* We are getting, at the end, a "Image is corrupted (bad magic)" -22 return code. We have also created a VM (based on SOF 2.4.1) where we can compile (and sign, with default keys) the different toolchains and firmwares. Will that help in having a firmware run correctly? Maybe, we are doing incorrect things, if this is the case, please advise. Best regards, David Sayada.

2 13

[PATCH 0/5] ASoC: MediaTek MT8195/86 Cleanups
by AngeloGioacchino Del Regno 03 May '23

03 May '23

This series performs some cleanups for mainly MT8195 and switches both MT8195 and MT8186's SOF driver to the snd_sof_ipc_process_reply() helper. AngeloGioacchino Del Regno (5): ASoC: SOF: mediatek: mt8195: Use snd_sof_ipc_process_reply() helper ASoC: SOF: mediatek: mt8186: Use snd_sof_ipc_process_reply() helper ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe ASoC: mediatek: mt8195-afe-pcm: Simplify with dev_err_probe() ASoC: mediatek: mt8195-afe-pcm: Clean up unnecessary functions sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 99 ++++++++-------------- sound/soc/sof/mediatek/mt8186/mt8186.c | 36 +------- sound/soc/sof/mediatek/mt8195/mt8195.c | 36 +------- 3 files changed, 36 insertions(+), 135 deletions(-) -- 2.40.1

3 9

[PATCH] ASoC: SOF: Intel: hda-stream: Move three variable assignments behind condition checks in hda_dsp_iccmax_stream_hw_params()
by Markus Elfring 24 Apr '23

24 Apr '23

Date: Wed, 19 Apr 2023 20:42:19 +0200 The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “hda_dsp_iccmax_stream_hw_params”. Thus avoid the risk for undefined behaviour by moving the assignment for three local variables behind some condition checks. This issue was detected by using the Coccinelle software. Fixes: 7d88b9608142f95ccdd3dfb190da4a5faddb1cc7 ("ASoC: SOF: Intel: hdac_ext_stream: consistent prefixes for variables/members") Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> --- sound/soc/sof/intel/hda-stream.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/sound/soc/sof/intel/hda-stream.c b/sound/soc/sof/intel/hda-stream.c index 79d818e6a0fa..9c44127014fc 100644 --- a/sound/soc/sof/intel/hda-stream.c +++ b/sound/soc/sof/intel/hda-stream.c @@ -407,10 +407,10 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st struct snd_dma_buffer *dmab, struct snd_pcm_hw_params *params) { - struct hdac_stream *hstream = &hext_stream->hstream; - int sd_offset = SOF_STREAM_SD_OFFSET(hstream); + struct hdac_stream *hstream; + int sd_offset; int ret; - u32 mask = 0x1 << hstream->index; + u32 mask; if (!hext_stream) { dev_err(sdev->dev, "error: no stream available\n"); @@ -422,9 +422,12 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st return -ENODEV; } + hstream = &hext_stream->hstream; if (hstream->posbuf) *hstream->posbuf = 0; + sd_offset = SOF_STREAM_SD_OFFSET(hstream); + /* reset BDL address */ snd_sof_dsp_write(sdev, HDA_DSP_HDA_BAR, sd_offset + SOF_HDA_ADSP_REG_SD_BDLPL, @@ -459,6 +462,8 @@ int hda_dsp_iccmax_stream_hw_params(struct snd_sof_dev *sdev, struct hdac_ext_st sd_offset + SOF_HDA_ADSP_REG_SD_LVI, 0xffff, (hstream->frags - 1)); + mask = 0x1 << hstream->index; + /* decouple host and link DMA, enable DSP features */ snd_sof_dsp_update_bits(sdev, HDA_DSP_PP_BAR, SOF_HDA_REG_PP_PPCTL, mask, mask); -- 2.40.0

2 2

[PATCH v2 00/13] ASoC: add and use asoc_dummy_dlc
by Kuninori Morimoto 24 Apr '23

24 Apr '23

Hi Mark These are v2 patch-set of asoc_dummy_dlc. Many ASoC drivers are using dummy DAI. I have 2 concern about it. 1st one is there is no guarantee that local strings ("snd-soc-dummy-dai", "snd-soc-dummy") are kept until the card was binded if it was added at subfunction. 2nd one is we can use common snd_soc_dai_link_component for it. This patch-set adds common asoc_dummy_dlc, and use it. v1 -> v2 - Separate intel patch into 3 - Topology codec doesn't use asoc_dummy_dlc Link: https://lore.kernel.org/r/874jpe3uqh.wl-kuninori.morimoto.gx@renesas.com Kuninori Morimoto (13): ASoC: soc-utils.c: add asoc_dummy_dlc ASoC: ti: use asoc_dummy_dlc ASoC: sof: use asoc_dummy_dlc ASoC: amd: use asoc_dummy_dlc ASoC: fsl: use asoc_dummy_dlc ASoC: qcom: use asoc_dummy_dlc ASoC: atmel: use asoc_dummy_dlc ASoC: meson: use asoc_dummy_dlc ASoC: intel: avs: use asoc_dummy_dlc ASoC: intel: sof: use asoc_dummy_dlc ASoC: intel: skylake: use asoc_dummy_dlc ASoC: simple_card_utils.c: use asoc_dummy_dlc ASoC: soc-topology.c: add comment for Platform/Codec include/sound/simple_card_utils.h | 1 - include/sound/soc.h | 1 + sound/soc/amd/acp/acp-mach-common.c | 43 ++++++++------------ sound/soc/atmel/atmel-classd.c | 8 ++-- sound/soc/atmel/atmel-pdmic.c | 8 ++-- sound/soc/fsl/imx-audmix.c | 14 +++---- sound/soc/fsl/imx-card.c | 11 +---- sound/soc/fsl/imx-rpmsg.c | 3 +- sound/soc/fsl/imx-spdif.c | 8 ++-- sound/soc/generic/simple-card-utils.c | 9 +--- sound/soc/intel/avs/boards/i2s_test.c | 6 +-- sound/soc/intel/boards/ehl_rt5660.c | 8 +--- sound/soc/intel/boards/skl_hda_dsp_generic.c | 8 +--- sound/soc/intel/boards/sof_cs42l42.c | 11 +---- sound/soc/intel/boards/sof_es8336.c | 11 +---- sound/soc/intel/boards/sof_nau8825.c | 11 +---- sound/soc/intel/boards/sof_pcm512x.c | 3 +- sound/soc/intel/boards/sof_rt5682.c | 14 ++----- sound/soc/intel/boards/sof_sdw.c | 13 +----- sound/soc/intel/boards/sof_ssp_amp.c | 18 +++----- sound/soc/meson/axg-card.c | 8 ++-- sound/soc/meson/meson-card-utils.c | 10 +---- sound/soc/qcom/common.c | 11 +---- sound/soc/soc-topology.c | 22 +++++----- sound/soc/soc-utils.c | 7 ++++ sound/soc/sof/nocodec.c | 8 ++-- sound/soc/ti/omap-hdmi.c | 8 ++-- 27 files changed, 89 insertions(+), 194 deletions(-) -- 2.25.1

1 1

[PATCH 04/11] ASoC: sof: use asoc_dummy_dlc
by Kuninori Morimoto 18 Apr '23

18 Apr '23

Now we can share asoc_dummy_dlc. This patch use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/sof/nocodec.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/sound/soc/sof/nocodec.c b/sound/soc/sof/nocodec.c index b13bfdeb2b70..7c5bb9badb6c 100644 --- a/sound/soc/sof/nocodec.c +++ b/sound/soc/sof/nocodec.c @@ -32,7 +32,7 @@ static int sof_nocodec_bes_setup(struct device *dev, /* set up BE dai_links */ for (i = 0; i < link_num; i++) { - dlc = devm_kcalloc(dev, 3, sizeof(*dlc), GFP_KERNEL); + dlc = devm_kcalloc(dev, 2, sizeof(*dlc), GFP_KERNEL); if (!dlc) return -ENOMEM; @@ -44,8 +44,8 @@ static int sof_nocodec_bes_setup(struct device *dev, links[i].stream_name = links[i].name; links[i].cpus = &dlc[0]; - links[i].codecs = &dlc[1]; - links[i].platforms = &dlc[2]; + links[i].codecs = &asoc_dummy_dlc; + links[i].platforms = &dlc[1]; links[i].num_cpus = 1; links[i].num_codecs = 1; @@ -55,8 +55,6 @@ static int sof_nocodec_bes_setup(struct device *dev, links[i].no_pcm = 1; links[i].cpus->dai_name = drv[i].name; links[i].platforms->name = dev_name(dev->parent); - links[i].codecs->dai_name = "snd-soc-dummy-dai"; - links[i].codecs->name = "snd-soc-dummy"; if (drv[i].playback.channels_min) links[i].dpcm_playback = 1; if (drv[i].capture.channels_min) -- 2.25.1

1 0