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

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Thu, Nov 5, 2015 at 10:44 AM, Johan Hovold <johan@xxxxxxxxxx> wrote:
> On Wed, Nov 04, 2015 at 11:48:47AM +0100, Linus Walleij wrote:

>> Thinking about it maybe it's simplest to just make ->dev a pointer
>> and kzalloc() it at gpiochip_add().
>>
>> That should solve this.

Turns out that it's a bad idea to have a struct device as pointer because
it makes it impossible to use container_of() in e.g. .remove.

> You'd avoid ever reregistering the same struct device, but that would
> not solve the bigger life-time issue by itself.

Since device_del() unconditionally kills off the devince from the system
this is equivalent to saying device_add() and device_del() should really
not be used by subsystems, am I right?

Right now there is a cryptic comment in device_del() that says it should
"only be used if device_add() was also used manually" I wonder who this
man is that is using things manually inside the kernel, I guess it actually
means they must be paired.

If I don't use device_add()/device_del(), I see this must mean I have to use
device_register()/device_unregister() as the latter only decrease the refcount
and wait for the instance to die off.

So am I reading it correctly if I understand that this is what we should be
doing? I.e device_register()/device_unregister() and then wait for the
.remove() call to do its deed, so the kobj/struct device is kept around if
e.g. sysfs or the chardev has open files.

(It makes sense. Harder to code up, but makes sense.)

Yours,
Linus Walleij
--
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