Re: [PATCH] move cfag12864bfb's probe function to .devinit.text

[Uwe Kleine-König]

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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/