I find a lot of mistakes using struct platform_driver without owner.
So I pick up some of them including usb and net modules
Instead of doing it this way, which is obviously error prone and
easy to forget, make platform_driver_register() be a macro which
sets the module owner field then calls the real __platform_driver_register().
I find a lot of mistakes using struct platform_driver without owner.
So I pick up some of them including usb and net modules
Instead of doing it this way, which is obviously error prone and
easy to forget, make platform_driver_register() be a macro which
sets the module owner field then calls the real
__platform_driver_register().
Or, maybe make the existing module_platform_driver() macro do this?
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
I find a lot of mistakes using struct platform_driver without owner.
So I pick up some of them including usb and net modules
Instead of doing it this way, which is obviously error prone and
easy to forget, make platform_driver_register() be a macro which
sets the module owner field then calls the real
__platform_driver_register().
Or, maybe make the existing module_platform_driver() macro do this?
I find a lot of mistakes using struct platform_driver without owner.
So I pick up some of them including usb and net modules
Instead of doing it this way, which is obviously error prone and
easy to forget, make platform_driver_register() be a macro which
sets the module owner field then calls the real
__platform_driver_register().
Or, maybe make the existing module_platform_driver() macro do this?
But not all the modules use module_platform_driver() macro to replace the module init/exit.
Thanks,
Gu
I find a lot of mistakes using struct platform_driver without owner.
So I pick up some of them including usb and net modules
Instead of doing it this way, which is obviously error prone and
easy to forget, make platform_driver_register() be a macro which
sets the module owner field then calls the real
__platform_driver_register().
Or, maybe make the existing module_platform_driver() macro do this?
But not all the modules use module_platform_driver() macro to replace the module init/exit.
Thanks,
Gu
yes, there are many drivers register platform_driver by platform_driver_register manually.
make both platform_driver_register() and module_platform_driver() to check and set the module owner field?
I find a lot of mistakes using struct platform_driver without owner.
So I pick up some of them including usb and net modules
Instead of doing it this way, which is obviously error prone and
easy to forget, make platform_driver_register() be a macro which
sets the module owner field then calls the real
__platform_driver_register().
Or, maybe make the existing module_platform_driver() macro do this?
But not all the modules use module_platform_driver() macro to replace the module init/exit.
Thanks,
Gu
yes, there are many drivers register platform_driver by platform_driver_register manually.
make both platform_driver_register() and module_platform_driver() to check and set the module owner field?
No, module_platform_driver() will call platform_driver_register() to register platform_driver, just do it in
platform_driver_register() is enough.
As David mentioned, making platform_driver_register() be a macro and sets the module owner field in it, seems
a good way.
Thanks,
Gu
From: Thomas Petazzoni <hidden> Date: 2013-05-21 09:06:25
Dear Gu Zheng,
On Tue, 21 May 2013 16:00:19 +0800, Gu Zheng wrote:
quoted
Or, maybe make the existing module_platform_driver() macro do this?
But not all the modules use module_platform_driver() macro to replace the module init/exit.
Then maybe it's a good opportunity to convert those ones to use
module_platform_driver() ?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Dear Gu Zheng,
On Tue, 21 May 2013 16:00:19 +0800, Gu Zheng wrote:
quoted
quoted
Or, maybe make the existing module_platform_driver() macro do this?
But not all the modules use module_platform_driver() macro to replace the module init/exit.
Then maybe it's a good opportunity to convert those ones to use
module_platform_driver() ?
Thomas
In my opinion, not all modules can use module_platform_driver() macro to replace the module init/exit easily, like us3mc_init.
Furthermore this work will touch various platforms and architectures, I am worried it is hard to *test* (compile and boot).
What do you think?
On Tue, May 21, 2013 at 10:42:00AM +0800, Libo Chen wrote:
I find a lot of mistakes using struct platform_driver without owner.
So I pick up some of them including usb and net modules
Like others said, make the function call a macro that sets the module
owner in it, like all of the other major subsystem registration calls do
(usb_drivers, pci_drivers, etc.)
thanks,
greg k-h
Dear Gu Zheng,
On Tue, 21 May 2013 16:00:19 +0800, Gu Zheng wrote:
quoted
quoted
Or, maybe make the existing module_platform_driver() macro do this?
But not all the modules use module_platform_driver() macro to replace the module init/exit.
Then maybe it's a good opportunity to convert those ones to use
module_platform_driver() ?
Thomas
In my opinion, not all modules can use module_platform_driver() macro to replace the module init/exit easily, like us3mc_init.
Furthermore this work will touch various platforms and architectures, I am worried it is hard to *test* (compile and boot).
Agree. I stick to the way that David mentioned.
Thanks,
Gu