[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <73a59667-ee41-4f62-8341-fc83a12516f9@amd.com>
Date: Wed, 27 Mar 2024 23:08:54 +0530
From: "Mukunda,Vijendar" <vijendar.mukunda@....com>
To: Mark Brown <broonie@...nel.org>
Cc: alsa-devel@...a-project.org, venkataprasad.potturu@....com,
Basavaraj.Hiregoudar@....com, Sunil-kumar.Dommati@....com,
Liam Girdwood <lgirdwood@...il.com>, Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>, Syed Saba Kareem <Syed.SabaKareem@....com>,
Jarkko Nikula <jarkko.nikula@...mer.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
"open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..."
<linux-sound@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] ASoC: amd: acp: fix for acp_init function error
handling
On 27/03/24 20:28, Mark Brown wrote:
> On Wed, Mar 27, 2024 at 04:16:52PM +0530, Vijendar Mukunda wrote:
>
>> @@ -115,7 +115,10 @@ static int acp_pci_probe(struct pci_dev *pci, const struct pci_device_id *pci_id
>> goto unregister_dmic_dev;
>> }
>>
>> - acp_init(chip);
>> + ret = acp_init(chip);
>> + if (ret)
>> + return ret;
>> +
> The return check is good but shouldn't this be a 'goto
> unregister_dmic_dev' like the above case so we do cleanup?
I do agree. Will modify the code and respin the patch series.
Powered by blists - more mailing lists