lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 5 Nov 2020 08:47:57 -0600 From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com> To: Sasha Levin <sashal@...nel.org>, Paul Bolle <pebolle@...cali.nl> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org, stable@...r.kernel.org, Rander Wang <rander.wang@...el.com>, Bard Liao <yung-chuan.liao@...ux.intel.com>, Guennadi Liakhovetski <guennadi.liakhovetski@...ux.intel.com>, Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>, Mark Brown <broonie@...nel.org> Subject: Re: [PATCH 5.9 080/391] ASoC: SOF: fix a runtime pm issue in SOF when HDMI codec doesnt work On 11/5/20 8:35 AM, Sasha Levin wrote: > On Thu, Nov 05, 2020 at 02:23:35PM +0100, Paul Bolle wrote: >> Greg Kroah-Hartman schreef op di 03-11-2020 om 21:32 [+0100]: >>> From: Rander Wang <rander.wang@...el.com> >>> >>> [ Upstream commit 6c63c954e1c52f1262f986f36d95f557c6f8fa94 ] >>> >>> When hda_codec_probe() doesn't initialize audio component, we disable >>> the codec and keep going. However,the resources are not released. The >>> child_count of SOF device is increased in snd_hdac_ext_bus_device_init >>> but is not decrease in error case, so SOF can't get suspended. >>> >>> snd_hdac_ext_bus_device_exit will be invoked in HDA framework if it >>> gets a error. Now copy this behavior to release resources and decrease >>> SOF device child_count to release SOF device. >>> >>> Signed-off-by: Rander Wang <rander.wang@...el.com> >>> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com> >>> Reviewed-by: Bard Liao <yung-chuan.liao@...ux.intel.com> >>> Reviewed-by: Guennadi Liakhovetski >>> <guennadi.liakhovetski@...ux.intel.com> >>> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@...ux.intel.com> >>> Link: >>> https://lore.kernel.org/r/20200825235040.1586478-3-ranjani.sridharan@linux.intel.com >>> >>> Signed-off-by: Mark Brown <broonie@...nel.org> >>> Signed-off-by: Sasha Levin <sashal@...nel.org> >>> --- >>> sound/soc/sof/intel/hda-codec.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/sound/soc/sof/intel/hda-codec.c >>> b/sound/soc/sof/intel/hda-codec.c >>> index 2c5c451fa19d7..c475955c6eeba 100644 >>> --- a/sound/soc/sof/intel/hda-codec.c >>> +++ b/sound/soc/sof/intel/hda-codec.c >>> @@ -151,7 +151,7 @@ static int hda_codec_probe(struct snd_sof_dev >>> *sdev, int address, >>> if (!hdev->bus->audio_component) { >>> dev_dbg(sdev->dev, >>> "iDisp hw present but no driver\n"); >>> - return -ENOENT; >>> + goto error; >>> } >>> hda_priv->need_display_power = true; >>> } >>> @@ -174,7 +174,7 @@ static int hda_codec_probe(struct snd_sof_dev >>> *sdev, int address, >>> * other return codes without modification >>> */ >>> if (ret == 0) >>> - ret = -ENOENT; >>> + goto error; >>> } >>> >>> return ret; >> >> My local build of v5.9.5 broke on this patch. >> >> sound/soc/sof/intel/hda-codec.c: In function 'hda_codec_probe': >> sound/soc/sof/intel/hda-codec.c:177:4: error: label 'error' used but >> not defined >> 177 | goto error; >> | ^~~~ >> make[4]: *** [scripts/Makefile.build:283: >> sound/soc/sof/intel/hda-codec.o] Error 1 >> make[3]: *** [scripts/Makefile.build:500: sound/soc/sof/intel] Error 2 >> make[2]: *** [scripts/Makefile.build:500: sound/soc/sof] Error 2 >> make[1]: *** [scripts/Makefile.build:500: sound/soc] Error 2 >> make: *** [Makefile:1778: sound] Error 2 >> >> There's indeed no error label in v5.9.5. (There is one in v5.10-rc2, I >> just >> checked.) Is no-one else running into this? > > It seems that setting CONFIG_SND_SOC_SOF_HDA_AUDIO_CODEC=y is very > "difficult", it's not being set by allmodconfig nor is it easy to > manually set it up. > > I'll revert the patch, but it would be nice to make sure it's easier to > test this out too. this issue comes from out-of-order patches, give me a couple of hours to look into this before reverting. thanks!
Powered by blists - more mailing lists