On Thu, Nov 5, 2015 at 10:44 AM, Johan Hovold <jo...@kernel.org> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
