Re: [alsa-devel] Question about struct snd_soc_dai() :: cpu_dai->codec

[Vinod Koul <vinod.koul@intel.com>]

On Wed, Jul 27, 2016 at 10:22:41PM +0200, Takashi Iwai wrote:
> On Wed, 27 Jul 2016 20:22:33 +0200,
> Mark Brown wrote:
> > 
> > On Wed, Jul 27, 2016 at 08:11:49PM +0200, Takashi Iwai wrote:
> > 
> > > I'm wondering whether it's a better option to block the unbind
> > > behavior, either in driver base (allowing to return an error) or in
> > > the sound side (waiting in remove() until the sane point). 
> > 
> > That's certainly going to be a lot easier and part of the reason it's
> > never been looked at much is that (unlike USB) there's very little
> > reason why an ASoC sound card would ever be hotplugged - even in
> > development these days the normal development flow involves rebooting.

I agree, it makese no sense for devices to be hotplugged. And for
developement flows people can do rmmond and insmod. That works fine!

> Actually there is already the suppress_bind_attr flag in struct
> device_driver.  For a simple platform driver like snd-soc-rcar, it's
> easy like:

I like this idea, should we do this per driver or in core? I think we should
let drivers decide..

> diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
> index 3351a701c60e..d019824927de 100644
> --- a/sound/soc/sh/rcar/core.c
> +++ b/sound/soc/sh/rcar/core.c
> @@ -1251,6 +1251,7 @@ static struct platform_driver rsnd_driver = {
>  	.driver	= {
>  		.name	= "rcar_sound",
>  		.of_match_table = rsnd_of_match,
> +		.suppress_bind_attrs = true,
>  	},
>  	.probe		= rsnd_probe,
>  	.remove		= rsnd_remove,
> 
> Then there will be no sysfs bind/unbind for this driver.
> (Note: totally untested: let me know if it really works.)
> 
> The same technique is likely available for i2c and spi codec drivers.
> But it's another open question whether we should suppress the sysfs
> bind/unbind of these devices at all.  My gut feeling is that sysfs
> bind/unbind are mostly useless for drivers like ASoC codecs.  At
> least, it would be much safer to disable for now.

-- 
~Vinod