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
