Re: [PATCH] Minor change to platform_device_register_simple prototype

[Jean Delvare <khali@linux-fr.org>]

Hi Dmirty, Russell, Greg,

Quoting myself:
> I second Dmitry's request here. I can't seem to possibly build a valid
> error path during device registration with the current API. Having
> platform_device_del() would make it possible.

I since modified the platform driver I am working on, thanks to the
guidance of Alessandro Zummo, and found that the new implementation no
longer needs platform_device_del().

My original code was registering a platform_driver, but wasn't actually
using it. In particular, the driver had no probe and remove functions.
Everything was done directly through the init and exit functions of the
module.

The new code makes proper use of platform_driver's probe and remove
function pointers. This means that the initial platform_device
registration ends with a call to platform_device_add(), and as a
consequence, the error path doesn't need platform_device_del().

So, provided that my case can be extended to others, I'd guess that
platform drivers using platform_driver.probe are likely not to need
platform_device_del(), while drivers not using platform_driver.probe
may need it. This may explain why platform_device_del wasn't needed so
far.

This raises a question. For a module which registers both the
platform_device and the matching platform_driver (as is the case for
mine), is it considered better to rely on platform_driver.probe
and .remove (as my new code does)? Or is it OK to omit these and handle
initialization and cleanup phases more direclty (as my old code did),
as this is technically possible? Using .probe and .remove looks cleaner
with regards to the driver model, but it also makes things a little
more complex.

If the goal is to always use .probe and .remove, then
platform_device_del() might become unneeded again in the long run.

Thanks,
-- 
Jean Delvare
-
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/