On 08.12.20 15:19, Andy Shevchenko wrote: Hi, > Have you able to test them all? Not yet. It's still an *RFC*, I just like to discuss whether the whole idea makes sense at all. In case we come to the consensus that we should do it, I'm going to split up the patch and rework everything more carefully (for now, it's just a draft for illustrating the general idea) I'd also like to hear your opinion on whether we can consolidate these things even more, eg. using struct gpio_chip's irq data (enabled by CONFIG_GPIOLIB_IRQCHIP) instead of own fields. An interesting question here is how to do that w/o gpiolib assuming they've been managed by it - for example gpiochip_remove (which cleans up the IRQ stuff) is called by gpiochip_remove(), so we have to make sure that the driver clears the corresponding fields before gpiochip_remove() is called. So far so good. BUT: gpiochip_remove() is also called in error paths, when registration fails in the middle, and there the driver cannot act properly. Maybe introduce a flag for telling gpiolib that it should leave these fields alone and let the driver do everything ? > As the PCA953x case showed us this is not so simple, Can you tell me more about it ? (BTW haven't touched it in my patch) > besides the name > which sucks — we don't *raise* and IRQ we *handle* it. right, the naming was bad, forgot to correct that before sending. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287