Messages in this thread | | | Date | Tue, 20 Jan 2009 10:29:44 +0100 | From | Uwe Kleine-König <> | Subject | Re: [PATCH] move cfag12864bfb's probe function to .devinit.text |
| |
Hello Miguel,
On Tue, Jan 20, 2009 at 09:13:25AM +0100, Miguel Ojeda wrote: > On Mon, Jan 12, 2009 at 11:24 PM, Uwe Kleine-König > <u.kleine-koenig@pengutronix.de> wrote: > > An alternative to this patch is using platform_driver_probe instead of > > platform_driver_register plus removing the pointer to the probe function > > from the struct platform_driver. > > Is that solution better? What are the pros/cons? When using platform_driver_probe only devices that are already available are probed. There is no way you can bind a device that was registered after the call to platform_driver_probe or that was once unbound via sysfs. In return your .probe function can live in .init.text and so you can save some RAM. (Note, that for modular drivers the situation is a bit different because you can reload your modules (assuming it supports unloading) and then you get a new platform_driver_probe call. This doesn't matter though, because either the devices are available before you can load your module or your module creates the devices itself.)
I think for many drivers using platform_driver_probe is the more sensible way, but it needs a deeper look and/or more testing. With the unfixed code a device that is created after platform_driver_register but before the init sections are discarded is correctly bound. After changing to platform_driver_probe this is not the case anymore. That's why I choosed to stay with platform_driver_register for my patches.
Best regards Uwe
-- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |