[PATCH v2] ASoC: cs42l51: Improve error handling in cs42l51_remove()
When disabling a regulator fails while the device goes away, there is little we can do and the machine is probably in enough trouble that any action we'd want to take fails anyhow.
The return value used to be passed on in cs42l51_i2c_remove() (i.e. the i2c device remove callback). But the i2c core ignores the error code (apart from emitting a generic warning) and removes the device anyhow.
So return 0 unconditionally in cs42l51_i2c_remove(), and instead of returning the error code to the upper layer emit a more helpful warning message. After that nobody is interested any more in the actual error code, so let cs42l51_remove() return void.
Signed-off-by: Uwe Kleine-König u.kleine-koenig@pengutronix.de --- Hello,
compared to v1 (Message-Id: 20211021103627.70975-1-u.kleine-koenig@pengutronix.de) I'm using regulator_bulk_disable() instead of regulator_bulk_force_disable().
Best regards Uwe
sound/soc/codecs/cs42l51-i2c.c | 4 +++- sound/soc/codecs/cs42l51.c | 11 ++++++++--- sound/soc/codecs/cs42l51.h | 2 +- 3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/cs42l51-i2c.c b/sound/soc/codecs/cs42l51-i2c.c index 70260e0a8f09..3cb21a2ba29f 100644 --- a/sound/soc/codecs/cs42l51-i2c.c +++ b/sound/soc/codecs/cs42l51-i2c.c @@ -31,7 +31,9 @@ static int cs42l51_i2c_probe(struct i2c_client *i2c,
static int cs42l51_i2c_remove(struct i2c_client *i2c) { - return cs42l51_remove(&i2c->dev); + cs42l51_remove(&i2c->dev); + + return 0; }
static const struct dev_pm_ops cs42l51_pm_ops = { diff --git a/sound/soc/codecs/cs42l51.c b/sound/soc/codecs/cs42l51.c index c61b17dc2af8..e9c3cb4e2bfc 100644 --- a/sound/soc/codecs/cs42l51.c +++ b/sound/soc/codecs/cs42l51.c @@ -793,14 +793,19 @@ int cs42l51_probe(struct device *dev, struct regmap *regmap) } EXPORT_SYMBOL_GPL(cs42l51_probe);
-int cs42l51_remove(struct device *dev) +void cs42l51_remove(struct device *dev) { struct cs42l51_private *cs42l51 = dev_get_drvdata(dev); + int ret;
gpiod_set_value_cansleep(cs42l51->reset_gpio, 1);
- return regulator_bulk_disable(ARRAY_SIZE(cs42l51->supplies), - cs42l51->supplies); + ret = regulator_bulk_disable(ARRAY_SIZE(cs42l51->supplies), + cs42l51->supplies); + if (ret) + dev_warn(dev, "Failed to disable all regulators (%pe)\n", + ERR_PTR(ret)); + } EXPORT_SYMBOL_GPL(cs42l51_remove);
diff --git a/sound/soc/codecs/cs42l51.h b/sound/soc/codecs/cs42l51.h index 9d06cf7f8876..a79343e8a54e 100644 --- a/sound/soc/codecs/cs42l51.h +++ b/sound/soc/codecs/cs42l51.h @@ -13,7 +13,7 @@ struct device;
extern const struct regmap_config cs42l51_regmap; int cs42l51_probe(struct device *dev, struct regmap *regmap); -int cs42l51_remove(struct device *dev); +void cs42l51_remove(struct device *dev); int __maybe_unused cs42l51_suspend(struct device *dev); int __maybe_unused cs42l51_resume(struct device *dev); extern const struct of_device_id cs42l51_of_match[];
base-commit: df0cc57e057f18e44dac8e6c18aba47ab53202f9
On Mon, 10 Jan 2022 08:18:32 +0100, Uwe Kleine-König wrote:
When disabling a regulator fails while the device goes away, there is little we can do and the machine is probably in enough trouble that any action we'd want to take fails anyhow.
The return value used to be passed on in cs42l51_i2c_remove() (i.e. the i2c device remove callback). But the i2c core ignores the error code (apart from emitting a generic warning) and removes the device anyhow.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: cs42l51: Improve error handling in cs42l51_remove() commit: 73d4c3135b2aa2308fe058f58ddbf658436aa385
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