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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 May 2014 15:37:37 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Grygorii Strashko <grygorii.strashko@...com>
Cc:	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Alexandre Courbot <gnurou@...il.com>,
	"Zhu, Lejun" <lejun.zhu@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	jacob.jun.pan@...ux.intel.com, bin.yang@...el.com
Subject: Re: [PATCH v4] gpio: Add support for Intel SoC PMIC (Crystal Cove)

On Tue, May 27, 2014 at 2:04 PM, Grygorii Strashko
<grygorii.strashko@...com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/