Re: [PATCH v4] gpio: Add support for Intel SoC PMIC (Crystal Cove)

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Tue, May 27, 2014 at 2:04 PM, Grygorii Strashko
<grygorii.strashko@xxxxxx> wrote:
> On 05/27/2014 11:46 AM, Mika Westerberg wrote:

> Regarding remove()/suspend() routines, It's like an axiom for me:
> - always disable irq
> - always stop all works/threads created by driver
> - do everything else
> (It's proved by dozens hours of debugging).
>
> Anyway, above is just my opinion :)

We cannot really let such things be up to someone's
opinion... we need to figure out what is the right way to
do it and do it that way, else we have ambigous semantics
in gpiolib and/or irqchip, which i *hate*.

> So, It's up to you, because it's your code :)

No, let's figure out what is right...

And, FWIW your sequence looks perfectly reasonable.

> Also FYI, I did fast analysis of GPIO drivers - funny statistic below:
> - 16 drivers setup IRQs BEFORE calling gpiochip_add();
> - 22 drivers setup IRQs AFTER calling gpiochip_add();

My idea is that you should call gpiochip_add() *first* and then
add the IRQs to the chip. In succession.

Rationale: with dynamic GPIO numbers, gpio_to_irq()
cannot reasonably be working before the gpiochip is added,
so it should be added first, then the irqchip. Since irq_to_gpio()
is *NOT* to be used (rather obliterated), this is the sequence
we mandate.

This is how the new irqchip helpers work by the way. As I
introduce this to more and more drivers it will look more and
more like this. And attack patches tagged RFT switching the
semantics of drivers are appreciated.

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