ASoC: fsl: Fix error handling if platform_device_add fails

Call platform_device_put() instead of platform_device_unregister() if platform_device_add() fails.

---
 sound/soc/fsl/mpc8610_hpcd.c |    2 +-
 sound/soc/fsl/p1022_ds.c     |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

index 358f0ba..31af405 100644
@@ -505,7 +505,7 @@ static int mpc8610_hpcd_probe(struct platform_device *pdev)
 	return 0;
 
 error_sound:
-	platform_device_unregister(sound_device);
+	platform_device_put(sound_device);
 error:
 	kfree(machine_data);
 error_alloc:

index e8849ed..2c064a9 100644
@@ -506,7 +506,7 @@ static int p1022_ds_probe(struct platform_device *pdev)
 
 error:
 	if (sound_device)
-		platform_device_unregister(sound_device);
+		platform_device_put(sound_device);
 
 	kfree(mdata);
 error_put:

1.7.4.1

Applied, thanks.

What's wrong with calling platform_device_unregister()?

Timur Tabi
Linux kernel developer at Freescale

hi all,

I have a question for the dummy codec.

As you know, sometimes maybe we only need set the timing from the processor, and codec just only need tx/rx data; So there do not need the codec driver.

After browser the code, there have NO such a dummy codec driver; and for soc-core, there have not such flags to support this situation. Only what i get is sound/soc/codecs/spdif_transciever.c, but it's specific for TI's DaVinci platform.

I want to get the right direction, so here have some works or discussing for that?

Thx,
Leo Yan

Don't start new threads by randomly replying to unrelated mails.

Even a dumb CODEC will have some constraints on things like the sample rates it can support which need to be conveyed to the framework and ideally the audio routing out of the CODEC should be visible for integration with any external output drivers or similar.

Not at all, what makes you believe that it is platform specific?

Sorry for that :-), the alsa-devel is the unrelated mailing list, right? if so, i will note for that later.

Get it.

On our platform, there have some devices (like hdmi/bt) do not need config from the CODEC driver, they have their own s/w stack and interface to configure; for the audio driver, just need to set the I2S/PCM timing for them. So if there have a common dummy codec driver, then it can meet our requirement well. Otherwise, there will have some duplicate codes for these dummy codecs.

The general thought here has been that for dumb CODECs the boilerplate is sufficiently small and simple to mean that the discoverability from writing a skeletal driver outweighs the cost of having it kicking around
- while there is some boilerplate there it's easier for someone to grab and use this code than it is to work out how exactly to translate the datasheets into code each time they encounter the part. However, a sufficiently well written generic driver would maintain that advantage while reducing the duplication.

What's wrong with calling platform_device_unregister()?

Timur Tabi
Linux kernel developer at Freescale

2011/9/27 Tabi Timur-B04825 <[email protected]>:

/**
* platform_device_unregister - unregister a platform-level device
* @pdev: platform device we're unregistering
*
* Unregistration is done in 2 steps. First we release all resources
* and remove it from the subsystem, then we drop reference count by
* calling platform_device_put().
*/

platform_device_unregister() actually calls platform_device_del() and platform_device_put().

If platform_device_add() call fails, we failed to add the platform device to device hierarchy. Thus we can just call platform_device_put() instead.