On Tue, Oct 04, 2011 at 12:18:18PM -0600, Grant Likely wrote:

On Mon, Sep 26, 2011 at 10:38:58AM +0100, Mark Brown wrote:

quoted

No, that's not helpful.  The issue isn't the device probe code itself,
the issue is things like module unload not doing what they're supposed
to do and leaving the device lying around or something - there's rather
more going on than just the plain API call.

Then lets fix the core code.  I see this pattern show up again and
again of extra boilerplate going around
platform_driver_{register,unregister}().  That says to me that there
either needs to be a new helper, or the core code needs to be made
more verbose.

I'd go with the latter, it's pretty much the approach the subsystems I
help maintain have been taking.  In fast paths it's a bit different but
in slow paths it tends to be helpful to know why things just fell over.

In fact, I've been considering adding a macro for
{platform,i2c,spi,...}_drivers that does all the module boilerplate
for the common case of only registering a driver at init time.
Something like:

#define module_platform_driver(__driver) \
int __driver##_init(void) \
{ \
	return platform_driver_register(&(__driver)); \
} \
module_init(__driver##_init); \
void ##__driver##_exit(void) \
{ \
	platform_driver_unregister(&(__driver)); \
} \
module_exit(##__driver##_exit);

It's not a lot of code, but I dislike how much boilerplate every
single driver has to use if it doesn't do anything special.

Yeah, this sort of stuff would be helpful - there's quite a bit of
boilerplate you end up having to write to get drivers going.