[PATCH] ASoC: amd: acp: Fix error handling in .remove()
Even in the presence of problems (here: rn_acp_deinit() might fail), it's important to unregister all resources acquired during .probe() because even if .remove() returns an error code, the device is removed.
As .remove() is only called after .probe() returned success, platdata must be valid, so the first check in .remove() can just be dropped.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König u.kleine-koenig@pengutronix.de --- sound/soc/amd/acp/acp-renoir.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/sound/soc/amd/acp/acp-renoir.c b/sound/soc/amd/acp/acp-renoir.c index 75c9229ece97..8375c00ff4c3 100644 --- a/sound/soc/amd/acp/acp-renoir.c +++ b/sound/soc/amd/acp/acp-renoir.c @@ -307,16 +307,10 @@ static int renoir_audio_remove(struct platform_device *pdev) int ret;
chip = dev_get_platdata(&pdev->dev); - if (!chip || !chip->base) { - dev_err(&pdev->dev, "ACP chip data is NULL\n"); - return -ENODEV; - }
ret = rn_acp_deinit(chip->base); - if (ret) { - dev_err(&pdev->dev, "ACP de-init Failed\n"); - return -EINVAL; - } + if (ret) + dev_err(&pdev->dev, "ACP de-init Failed (%pe)\n", ERR_PTR(ret));
acp_platform_unregister(dev); return 0;
base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56
On Wed, 22 Jun 2022 08:17:39 +0200, Uwe Kleine-König wrote:
Even in the presence of problems (here: rn_acp_deinit() might fail), it's important to unregister all resources acquired during .probe() because even if .remove() returns an error code, the device is removed.
As .remove() is only called after .probe() returned success, platdata must be valid, so the first check in .remove() can just be dropped.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: amd: acp: Fix error handling in .remove() commit: 0deb003933052ac1a44b5f94b927484be6e34f86
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (2)
-
Mark Brown -
Uwe Kleine-König