On Tue, Dec 15, 2015 at 8:25 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Mon, Dec 14, 2015 at 1:18 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> At this point we have to cross-reference the pointer to my chip to >> find the chip to remove. This goes for anything that takes the struct >> gpio_chip * >> as parameter, like gpiochip_add_pin_range(), gpiochip_request_own_desc() >> etc etc. So something inside gpiolib must take a gpio_chip * pointer and >> turn that into the actual state container, e.g, a struct gpio_device. >> Since struct gpio_chip needs to be static and stateless, it cannot contain >> a pointer back to its struct gpio_device. > > Why does gpio_chip have to be stateless? I am not saying that it > should or should not, I just want to better understand what you are > trying to achieve. Because the allocation of gpio_chip is currently inside each driver (often as part of their own state struct) and will go away with the driver. I want to make that const parameter that the drivers supply to the core gpiolib, and the gpiolib handled all states using something like that struct gpio_device you suggested or a more elaborate solution. >> If I compare to how struct input_dev is done, you appear to also use the >> pattern Russell suggested with input_dev_allocate() akin to >> netdev_alloc(), and the allocated struct holds all the vtable and states etc, >> and I think it is a good pattern, and that GPIO should conform. > > The main difference between gpio_chip (at least as it stands > currently) and input devices and corresponding private driver data is > that input device and driver data has different lifetimes; input > devices may stick around even though driver is unbound from > corresponding device and driver's private data freed. I would like to achieve something similar for GPIO devices. Yours, Linus Walleij
