linux-kernel - Re: [PATCH RFC 1/1] drivers: pinctrl: qcom: add wakeup capability to GPIO

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]

Message-ID: <20181019194712.GB17444@codeaurora.org>
Date:   Fri, 19 Oct 2018 13:47:12 -0600
From:   Lina Iyer <ilina@...eaurora.org>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     sboyd@...nel.org, evgreen@...omium.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/1] drivers: pinctrl: qcom: add wakeup capability to
 GPIO

On Fri, Oct 19 2018 at 09:53 -0600, Marc Zyngier wrote:
>Hi Lina,
>
>On 19/10/18 16:32, Lina Iyer wrote:
>> Hi folks,
>>
>> On Wed, Oct 10 2018 at 18:30 -0600, Lina Iyer wrote:

[...]

>>> +static irqreturn_t wake_irq_gpio_handler(int irq, void *data)
>>> +{
>>> +	struct irq_data *irqd = data;
>>> +	struct irq_desc *desc = irq_to_desc(irqd->irq);
>>> +
>>> +	desc->handle_irq(desc);
>> Do we see any problem calling handle_irq()?
>
>Good timing, I was just looking at this.
>
:) Thanks for your time.

>One thing I can see is that you will end-up calling the EOI callback on
>the root interrupt controller (the GIC), thus writing to ICC_EOIR1_EL1.
>
>But you've never acked this interrupt the first place by reading
>ICC_IAR1_EL1, and that puts you violently out of spec, according to the
>GICv3 spec (8.2.10), which reads:
>
>"A write to this register must correspond to the most recent valid read
>by this PE from an Interrupt Acknowledge Register, and must correspond
>to the INTID that was read from ICC_IAR1_EL1, otherwise the system
>behavior is UNPREDICTABLE."
>
>Here, you definitely risk the sanity of the CPU interface state machine.
>
Oh, thanks Marc. Will look into it. The problem is because I call
handle_irq() directly for the GPIO IRQ which is not triggered but we end
up mask, eoi etc.

How about calling handle_simple_irq(), which doesn't seem to the IRQ
registers?

>So stepping back a bit: At some point, you had a version that just
>relied on regenerating edge interrupts by writing to some register
>(knowing that level interrupts are safe by definition). Why isn't that
>the right solution? It'd avoid the above minefield by just letting the
>HW do its thing...
>
There are some unnecessary complexity with the approach that we are
trying to avoid.

The TLMM may or not may not be powered off (depending on the SoC state)
and Linux has no control on it. The PDC will remain powered on but we
don't want the PDC interrupt enabled always, since we will receive to
interrupts (one from TLMM and one from PDC) for every event. So we have
to keep the PDC interrupt configured as wakeup interrupt but operate on
the fact that when we go into suspend or cpuidle we will have to switch
to enabling the PDC interrupt and disabling the GPIO IRQ and swap back
when we resume. This dance is harder with cpuidle (notifying the TLMM
driver, when all the CPUs are in idle) than suspend/resume which has
nice callbacks and is what we are trying to avoid but using the PDC
interrupt always.

Thanks,
Lina