Re: More platform driver questions

[Jean Delvare]

Hi Russell,

> On Sun, Dec 11, 2005 at 10:00:23PM +0100, Jean Delvare wrote:
> > The base I/O address seemed to belong to .platform_data, as this is the
> > only way I have to pass the information through the .probe mechanism
> > (or should I use platform_get_resource instead?) All the rest I have
> > put in .driver_data. Actually, I even duplicated the base I/O address
> > there, as it made the rest of the code much more simple.
> 
> You should generally use the resources to pass address information.

OK, I've changed my code that way. Thanks for the hint.

> > It seems that in most .remove functions, we explicitely set the driver
> > data pointer to NULL before freeing the associated memory. I am
> > wondering why. Can someone explain? Given that the device is just being
> > deleted anyway, I don't quite see the benefit in doing so. But I guess
> > I am once again missing something obvious.
> 
> This depends on your point of view - whether you think there's a
> possibility that the driver_data might be accessed somehow after
> you've freed the pointer.  Having a NULL pointer will give you a
> very deterministic failure.
> 
> Of course, it can also be viewed as needless code and therefore not
> required.  Again, it's an opinion thing.

I don't mind the extra expense if it helps spotting race conditions. I
just wanted to make sure we agreed that doing so would simply change
the nature of the error we'll get if such a condition happens, but
won't actually prevent this error from happening. Unless each user of
the driver data has an explicit NULL check, which isn't the case for my
driver (and I *would* mind that extra expense.)

Now the question is, is there actually any race condition there? In my
case, the only users of the driver data are the sysfs callback
functions, so I guess that this is all down to whether the driver core
will unregister them before platform_driver.remove is called, or after
it is called. If .remove is called first, then yes my code is racy and
I'll have to fix it.

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