Re: [PATCH 1/6] gpio: make the gpiochip a real device

[Johan Hovold <johan@xxxxxxxxxx>]

On Mon, Nov 02, 2015 at 01:06:33PM +0000, Mark Brown wrote:
> On Mon, Nov 02, 2015 at 01:53:47PM +0100, Johan Hovold wrote:
> > On Mon, Nov 02, 2015 at 12:47:37PM +0000, Mark Brown wrote:
> 
> > > A memset() should be enough, if not then we have problems with any
> > > dynamically allocated struct device.
> 
> > And how would you know that it is safe to memset that struct device?
> > There can still be references to it. And driver core explicitly forbids
> > this (see device_add() for example).
> 
> My point here is that the memset() of something that was passed in
> externally isn't really a problem, it's the suspicious lack of
> integration with a release function (hence my question about why the
> driver core isn't complaining when the device gets registered).  The
> comment is more of a concern than the memset() itself.

Precisely, the memset itself is not the problem, but rather why was done
in the first place:

	*  We memset the struct to zero to avoid reentrance issues.
	*/

And to that point, I mentioned that it is illegal to register the same
struct device twice (and that this was indicative of a larger problem).

> > Dynamically allocated struct device are not the problem as then you're
> > not *reusing* the same device structure.
> 
> You may end up doing exactly that depending on what you get back from
> the allocator of course.

But then the memory has already been released. You're not deregistering
and reregistering the same device as in your example.

> The point is to make sure that that the driver
> model called release(), dynamically allocating and freeing in the
> release function is the easiest way to do this but it's not magic.

Agreed.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html