| Message ID | E1X1YLq-0004E1-MT@rmk-PC.arm.linux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jun 30, 2014 at 10:58:18AM +0100, Russell King wrote: > You may wish to give some consideration to whether ASoC core code should > be doing this instead, this is probably a very common source of brokenness > where two-stage driver initialisation exists. These kinds of issues are > why I consider (as a general rule) that two-stage driver initialisation > is really bad. What we've been doing here is getting everyone to move their resource allocation to the device level probe where it should be, leaving only things that genuinely need the card to be there (mainly controls and so on) in the ASoC level probe. Is that possible for this device - now that it's been converted to regmap I'd expect so?
On Mon, Jun 30, 2014 at 03:44:17PM +0100, Mark Brown wrote: > On Mon, Jun 30, 2014 at 10:58:18AM +0100, Russell King wrote: > > > You may wish to give some consideration to whether ASoC core code should > > be doing this instead, this is probably a very common source of brokenness > > where two-stage driver initialisation exists. These kinds of issues are > > why I consider (as a general rule) that two-stage driver initialisation > > is really bad. > > What we've been doing here is getting everyone to move their resource > allocation to the device level probe where it should be, leaving only > things that genuinely need the card to be there (mainly controls and so > on) in the ASoC level probe. Is that possible for this device - now > that it's been converted to regmap I'd expect so? I have no idea, and I can't help beyond this patch. Needless to say that the driver as it stands right now oopses the kernel when you try and remove it, so it really needs fixing.
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index 96ce061c1f10..3bbd89065313 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -1305,6 +1305,9 @@ static int sgtl5000_probe(struct snd_soc_codec *codec) int ret; struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec); + if (!devres_open_group(codec->dev, NULL, GFP_KERNEL)) + return -ENOMEM; + ret = sgtl5000_enable_regulators(codec); if (ret) return ret; @@ -1362,6 +1365,9 @@ static int sgtl5000_probe(struct snd_soc_codec *codec) err: regulator_bulk_disable(ARRAY_SIZE(sgtl5000->supplies), sgtl5000->supplies); + + devres_release_group(codec->dev, NULL); + ldo_regulator_remove(codec); return ret; @@ -1375,6 +1381,9 @@ static int sgtl5000_remove(struct snd_soc_codec *codec) regulator_bulk_disable(ARRAY_SIZE(sgtl5000->supplies), sgtl5000->supplies); + + devres_release_group(codec->dev, NULL); + ldo_regulator_remove(codec); return 0;
The sgtl5000 uses a two-stage initialisation process. The first stage is when the platform driver is probed, where some resources are found and initialised. The second stage is via the codec driver's probe function, where regulators are found and initialised using the managed resource support. The problem here is that this works fine until the codec driver is unbound. When this occurs, sgtl5000_remove() is called which is a no-op as far as the managed resource code is concerned. The regulators remain allocated, and their pointers in sgtl5000_priv remain valid. If the codec is now re-probed, it will again try and find the regulators, which will now be busy. This will fail. That's not the only problem - if using the LDO regulator, the regulator is unregistered from the regulator core code, but it still has a user. When the user is cleaned up (eg, by removing the module) it hits the free'd regulator, and this can oops the kernel. This bug was originally introduced by 63e54cd9caa3ce ("ASoC: sgtl5000: Use devm_regulator_bulk_get()"). Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> --- You may wish to give some consideration to whether ASoC core code should be doing this instead, this is probably a very common source of brokenness where two-stage driver initialisation exists. These kinds of issues are why I consider (as a general rule) that two-stage driver initialisation is really bad. sound/soc/codecs/sgtl5000.c | 9 +++++++++ 1 file changed, 9 insertions(+)