* Re: [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails
2011-09-20 7:09 [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Axel Lin
@ 2011-09-20 11:21 ` Liam Girdwood
2011-09-20 12:04 ` Mark Brown
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Liam Girdwood @ 2011-09-20 11:21 UTC (permalink / raw)
To: Axel Lin; +Cc: alsa-devel, Mark, Brown, linux-kernel, Timur Tabi
On Tue, 2011-09-20 at 15:09 +0800, Axel Lin wrote:
> Call platform_device_put() instead of platform_device_unregister() if
> platform_device_add() fails.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> sound/soc/fsl/mpc8610_hpcd.c | 2 +-
> sound/soc/fsl/p1022_ds.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c
> index 358f0ba..31af405 100644
> --- a/sound/soc/fsl/mpc8610_hpcd.c
> +++ b/sound/soc/fsl/mpc8610_hpcd.c
> @@ -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:
> diff --git a/sound/soc/fsl/p1022_ds.c b/sound/soc/fsl/p1022_ds.c
> index e8849ed..2c064a9 100644
> --- a/sound/soc/fsl/p1022_ds.c
> +++ b/sound/soc/fsl/p1022_ds.c
> @@ -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:
Acked-by: Liam Girdwood <lrg@ti.com>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails
2011-09-20 7:09 [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Axel Lin
2011-09-20 11:21 ` Liam Girdwood
@ 2011-09-20 12:04 ` Mark Brown
2011-09-20 16:00 ` Timur Tabi
` (2 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2011-09-20 12:04 UTC (permalink / raw)
To: Axel Lin; +Cc: alsa-devel, Liam Girdwood, linux-kernel, Timur Tabi
On Tue, Sep 20, 2011 at 03:09:00PM +0800, Axel Lin wrote:
> Call platform_device_put() instead of platform_device_unregister() if
> platform_device_add() fails.
Applied, thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails
2011-09-20 7:09 [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Axel Lin
2011-09-20 11:21 ` Liam Girdwood
2011-09-20 12:04 ` Mark Brown
@ 2011-09-20 16:00 ` Timur Tabi
2011-09-21 2:23 ` Questions for dummy codec driver Leo Yan
2011-09-27 2:08 ` [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Tabi Timur-B04825
4 siblings, 0 replies; 10+ messages in thread
From: Timur Tabi @ 2011-09-20 16:00 UTC (permalink / raw)
To: Axel Lin; +Cc: alsa-devel, Mark Brown, linux-kernel, Liam Girdwood
Axel Lin wrote:
> Call platform_device_put() instead of platform_device_unregister() if
> platform_device_add() fails.
What's wrong with calling platform_device_unregister()?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 10+ messages in thread
* Questions for dummy codec driver
2011-09-20 7:09 [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Axel Lin
` (2 preceding siblings ...)
2011-09-20 16:00 ` Timur Tabi
@ 2011-09-21 2:23 ` Leo Yan
2011-09-21 12:56 ` Mark Brown
2011-09-27 2:08 ` [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Tabi Timur-B04825
4 siblings, 1 reply; 10+ messages in thread
From: Leo Yan @ 2011-09-21 2:23 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: Mark Brown, alsa-devel@alsa-project.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Questions for dummy codec driver
2011-09-21 2:23 ` Questions for dummy codec driver Leo Yan
@ 2011-09-21 12:56 ` Mark Brown
2011-09-22 1:42 ` Leo Yan
0 siblings, 1 reply; 10+ messages in thread
From: Mark Brown @ 2011-09-21 12:56 UTC (permalink / raw)
To: Leo Yan; +Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
On Wed, Sep 21, 2011 at 10:23:18AM +0800, Leo Yan wrote:
> I have a question for the dummy codec.
Don't start new threads by randomly replying to unrelated mails.
> 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.
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.
> 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.
Not at all, what makes you believe that it is platform specific?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Questions for dummy codec driver
2011-09-21 12:56 ` Mark Brown
@ 2011-09-22 1:42 ` Leo Yan
2011-09-26 21:47 ` Mark Brown
0 siblings, 1 reply; 10+ messages in thread
From: Leo Yan @ 2011-09-22 1:42 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
On 09/21/2011 08:56 PM, Mark Brown wrote:
> On Wed, Sep 21, 2011 at 10:23:18AM +0800, Leo Yan wrote:
>
>> I have a question for the dummy codec.
>
> Don't start new threads by randomly replying to unrelated mails.
>
Sorry for that :-), the alsa-devel is the unrelated mailing list, right?
if so, i will note for that later.
>> 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.
>
> 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.
>
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.
>> 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.
>
> Not at all, what makes you believe that it is platform specific?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Questions for dummy codec driver
2011-09-22 1:42 ` Leo Yan
@ 2011-09-26 21:47 ` Mark Brown
0 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2011-09-26 21:47 UTC (permalink / raw)
To: Leo Yan; +Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
On Thu, Sep 22, 2011 at 09:42:14AM +0800, Leo Yan wrote:
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails
2011-09-20 7:09 [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Axel Lin
` (3 preceding siblings ...)
2011-09-21 2:23 ` Questions for dummy codec driver Leo Yan
@ 2011-09-27 2:08 ` Tabi Timur-B04825
2011-09-27 2:21 ` Axel Lin
4 siblings, 1 reply; 10+ messages in thread
From: Tabi Timur-B04825 @ 2011-09-27 2:08 UTC (permalink / raw)
To: Axel Lin
Cc: linux-kernel@vger.kernel.org, Liam Girdwood, Mark Brown,
alsa-devel@alsa-project.org
Axel Lin wrote:
> Call platform_device_put() instead of platform_device_unregister() if
> platform_device_add() fails.
What's wrong with calling platform_device_unregister()?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails
2011-09-27 2:08 ` [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Tabi Timur-B04825
@ 2011-09-27 2:21 ` Axel Lin
0 siblings, 0 replies; 10+ messages in thread
From: Axel Lin @ 2011-09-27 2:21 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linux-kernel@vger.kernel.org, Liam Girdwood, Mark Brown,
alsa-devel@alsa-project.org
2011/9/27 Tabi Timur-B04825 <B04825@freescale.com>:
> Axel Lin wrote:
>> Call platform_device_put() instead of platform_device_unregister() if
>> platform_device_add() fails.
>
> What's wrong with calling platform_device_unregister()?
/**
* 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.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
^ permalink raw reply [flat|nested] 10+ messages in thread