gpio: gpio-tb10x: remove incorrect __exit markup
PATCH 1/1 gpio: gpio-tb10x: remove incorrect __exit markup
Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes.
--- drivers/gpio/gpio-tb10x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-tb10x.c +1 -1
@@ -283,7 +283,7 @@ fail_ioremap:return ret; } -static int __exit tb10x_gpio_remove(struct platform_device *pdev) +static int tb10x_gpio_remove (struct platform_device *pdev) {struct tb10x_gpio *tb10x_gpio =platform_get_drvdata (pdev);
Signature · 5 lines
2.2.0.rc0.207.ga3a616c -- Dmitry
Quoted 7 lines · Dmitry Torokhov
Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using
__exitannotations onremove()methods. The only exception is drivers registered withplatform_driver_probe()which specifically disables sysfs bind/unbind attributes.Signed-off-by Dmitry Torokhov <[email protected]>
I prefer to have this fixed by setting .suppress_bind_attrs = true
in the struct device_driver .drv portion of the device driver, so the driver cannot be removed from sysfs.
So platform_driver_probe() isn't really the only exception, there is a way to do the same supression on ordinary drivers if we know we won't fiddle with them from sysfs.
Can you make a patch as per above (alternatively tell me how wrong I am...)
Yours,
Linus Walleij
Quoted 11 lines · Linus Walleij
Quoted 7 lines · Dmitry Torokhov
Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using
__exitannotations onremove()methods. The only exception is drivers registered withplatform_driver_probe()which specifically disables sysfs bind/unbind attributes.Signed-off-by Dmitry Torokhov <[email protected]>
Quoted 8 lines
I prefer to have this fixed by setting .suppress_bind_attrs = true
in the structdevice_driver.drv portion of the device driver, so the driver cannot be removed from sysfs.So
platform_driver_probe()isn't really the only exception, there is a way to do the same supression on ordinary drivers if we know we won't fiddle with them from sysfs.
Yes, you are right, setting suppress_bind_attrs will work too.
Quoted 3 lines
Can you make a patch as per above (alternatively tell me how wrong I am...)
Unfortunately I won't be able to do that as I can't provide justification for such change (i.e. I do not know why you want to disable unbinding while still keeping the remove() implementation.
Thanks.
Signature · 1 line
Dmitry
Quoted 24 lines · Dmitry Torokhov
Quoted 11 lines · Linus Walleij
Quoted 7 lines · Dmitry Torokhov
Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using
__exitannotations onremove()methods. The only exception is drivers registered withplatform_driver_probe()which specifically disables sysfs bind/unbind attributes.Signed-off-by Dmitry Torokhov <[email protected]>Quoted 8 lines
I prefer to have this fixed by setting .suppress_bind_attrs = true
in the structdevice_driver.drv portion of the device driver, so the driver cannot be removed from sysfs.So
platform_driver_probe()isn't really the only exception, there is a way to do the same supression on ordinary drivers if we know we won't fiddle with them from sysfs.Yes, you are right, setting
suppress_bind_attrswill work too.Quoted 1 line
Quoted 6 lines
Quoted 2 lines
Can you make a patch as per above (alternatively tell me how wrong I am...)
Unfortunately I won't be able to do that as I can't provide justification for such change (i.e. I do not know why you want to disable unbinding while still keeping the
remove()implementation.
You are right, I want a patch deleting the remove() implementation and setting the .suppress_bind_attrs = true at the same time.
For a bool driver of this type (typically compiled in and probed at boot) that makes most sense to me.
Well I guess there are a ton of drivers that should be done like that ... just wanna start somewhere.
Yours,
Linus Walleij
Quoted 33 lines · Linus Walleij
Quoted 24 lines · Dmitry Torokhov
Quoted 11 lines · Linus Walleij
Quoted 7 lines · Dmitry Torokhov
Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using
__exitannotations onremove()methods. The only exception is drivers registered withplatform_driver_probe()which specifically disables sysfs bind/unbind attributes.Signed-off-by Dmitry Torokhov <[email protected]>Quoted 8 lines
I prefer to have this fixed by setting .suppress_bind_attrs = true
in the structdevice_driver.drv portion of the device driver, so the driver cannot be removed from sysfs.So
platform_driver_probe()isn't really the only exception, there is a way to do the same supression on ordinary drivers if we know we won't fiddle with them from sysfs.Yes, you are right, setting
suppress_bind_attrswill work too.Quoted 1 line
Quoted 6 lines
Quoted 2 lines
Can you make a patch as per above (alternatively tell me how wrong I am...)
Unfortunately I won't be able to do that as I can't provide justification for such change (i.e. I do not know why you want to disable unbinding while still keeping the
remove()implementation.
Quoted 5 lines
You are right, I want a patch deleting the
remove()implementation and setting the .suppress_bind_attrs = true at the same time.For a bool driver of this type (typically compiled in and probed at boot) that makes most sense to me.
Hmm, I do not think this is a good justification for disabling unbinding. However, as far as I can see, removing gpiochip will succeed even though there are users of gpios in the system and that might justify the change. But does this mean that we give up on making gpiochip clean up properly and we should schedule gpiochip_remove() and the rest of gpio cleanup infrastructure for removal and declare that gpio drivers can not ever be made modules?
Seems like wrong direction to move to...
Thanks.
Signature · 1 line
Dmitry
Quoted 5 lines · Dmitry Torokhov
Quoted 2 lines · Linus Walleij
For a bool driver of this type (typically compiled in and probed at boot) that makes most sense to me.
Quoted 7 lines
Hmm, I do not think this is a good justification for disabling unbinding. However, as far as I can see, removing gpiochip will succeed even though there are users of gpios in the system and that might justify the change. But does this mean that we give up on making gpiochip clean up properly and we should schedule
gpiochip_remove()and the rest of gpio cleanup infrastructure for removal and declare that gpio drivers can not ever be made modules?
No. Johan Hovold is looking into use cases for GPIO chips that come and go, think GPIO on USB. These obviously need remove() semantics.
What I'm thinking is that the SoC-embedded GPIO controllers (I don't know how many these are) should probably be bool in Kconfig and also patched not to have remove() functions and drop the sysfs attribs for unbinding.
But now I think I'll just apply the patch anyways because it sure does not make a difference wrt to the bigger problem, so I'm just bitching around about details and thinking aloud, sorry..
Yours,
Linus Walleij
Quoted 7 lines · Dmitry Torokhov
Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using
__exitannotations onremove()methods. The only exception is drivers registered withplatform_driver_probe()which specifically disables sysfs bind/unbind attributes.Signed-off-by Dmitry Torokhov <[email protected]>
Patch applied.
Yours,
Linus Walleij