On Tue, Mar 19, 2013 at 9:55 AM, Fabio Porcedda
[off-list ref] wrote:

On Mon, Mar 18, 2013 at 12:28 PM, Arnd Bergmann [off-list ref] wrote:

quoted

On Monday 18 March 2013, Fabio Porcedda wrote:

quoted

On Mon, Mar 18, 2013 at 11:58 AM, Arnd Bergmann [off-list ref] wrote:

quoted

On Monday 18 March 2013, Fabio Porcedda wrote:

quoted

Since by using platform_driver_probe() the  function
ep93xx_pwm_probe() is freed after initialization,
is better to use module_platform_drive_probe().
IMHO i don't see any good reason to use module_platform_driver() for
this driver.

As I commented earlier, the platform_driver_probe() and
module_platform_drive_probe() interfaces are rather dangerous in combination
with deferred probing, I would much prefer Harley's patch.

Since those drivers don't use -EPROBE_DEFER i was thinking that they don't use
deferred probing.
I'm missing something?

clk_get() may return -EPROBE_DEFER after ep93xx is converted to use the
common clk API. We currently return the value of clk_get from the probe()
function, which will automatically do the right thing as long as the probe
function remains reachable.

Thanks for the explanation.

Hmm, so we may have drivers that (now) work perfectly fine with
module_platform_driver_probe()/platform_driver_probe(), but will start
failing suddenly in the future?

I guess we need a big fat WARN_ON(-EPROBE_DEFER) in
platform_driver_probe() to catch these?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds