On Tue, Jan 20, 2026 at 5:30 AM Tzung-Bi Shih <[email protected]> wrote: > > Generally, I think we can try to move device_initialize() earlier in the > function. On error handling paths, just put_device() for it. In the > .release() callback, free the resource iff it has initialized. > > > In theory yes but you wouldn't be the first one to attempt to improve > > it. This code is very brittle when it comes to GPIO chips that need to > > be initialized very early into the boot process. I'm talking old > > drivers in arch which call this function without even an associated > > parent struct device. When I'm looking at it now, it does seem > > possible to call device_initialize() early but whether that will work > > correctly for all existing users is a bigger question. > > FWIW: found a very early stage calling path when I was investigating > `gpiolib_initialized`: start_kernel() -> init_IRQ() -> dove_init_irq() -> > orion_gpio_init() -> gpiochip_add_data() -> gpiochip_add_data_with_key(). > > Prior to aab5c6f20023 ("gpio: set device type for GPIO chips"), > device_initialize() is also called in gpiochip_add_data_with_key(). It > seems to me it's possible to move it back to gpiochip_add_data_with_key() > as 03/23 does, and move it earlier in the function.
Sounds good, let's try it next cycle! Tzung-Bi: please make it a change separate from the wider Revocable series for GPIO. Bart
