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] [day] [month] [year] [list]

Date:   Wed, 7 Nov 2018 15:38:07 -0700
From:   Lina Iyer <ilina@...eaurora.org>
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     linux-kernel@...r.kernel.org, evgreen@...omium.org,
        marc.zyngier@....com
Subject: Re: [PATCH RFC 1/1] drivers: pinctrl: qcom: add wakeup capability to
 GPIO

On Mon, Nov 05 2018 at 22:19 -0700, Stephen Boyd wrote:
>Quoting Lina Iyer (2018-11-01 10:16:30)
>> On Wed, Oct 31 2018 at 18:13 -0600, Stephen Boyd wrote:
>> >
[...]

>Ok. I don't see why we need to limit ourselves here. If a GPIO interrupt
>isn't routed through PDC physically why does it matter? It shouldn't be
>why we avoid hierarchical irq domains.
>
Ok, now that we are not limited by this requirement...

>It doesn't seem like they can be exactly the same because of deep idle
>wakeup, so I suggest we go back to the beginning:
>
> * Split PDC into two domains, one for GIC and one for TLMM and
>   associate the TLMM one with an irq_domain_bus_token enum so
>   that TLMM can look it up with irq_find_matching_host()
>
The complexity here is that the GPIO and GIC interrupts are intertwined
at the PDC.
It would be ugly to describe the GIC interrupts with holes for the GPIOs
and the other way around as well. A single PDC instance would be best
way to keep things simple and clean.

Instead, we could have TLMM -> TLMM-PDC -> PDC -> GIC. The TLMM-PDC
being the interrupt controller that sets up the IRQ parent for the GPIO
IRQs.

Thanks,
Lina

> * Set TLMM as the child of the PDC TLMM domain
>
> * Allocate irqs from TLMM and have those allocate in the parent domain
>   if the TLMM is in a hierarchy domain with irq_domain_alloc_irqs()
>
> * When allocating an irq in TLMM's irqdomain::alloc function pass a
>   TLMM specific struct to irq_domain_alloc_irqs_parent() last argument
>
>   struct qcom_tlmm_fwspec {
>      bool mask;
>      struct irq_fwspec spec;
>   };
>
> * Have the PDC driver set the mask bit and the MPM driver not set the
>   mask bit in the qcom_tlmm_fwspec above
>
> * Have the TLMM driver use the mask bit to figure out if it should mask
>   or not mask the interrupt in the TLMM hardware
>
>This way we can use the last argument to irq_domain_alloc_irqs_parent()
>to communicate between the PDC/MPM drivers and the TLMM driver about how
>the irq is being managed by the wakeup domain.
>
>There will be some other functions to call for the hierarchy irq calls
>in the TLMM code, specifically the set_type callback and the set_wake
>callback need to call up to the parent irq domain so the MPM can trap
>the set_wake calls to know what to monitor and the PDC can trigger
>correctly. You can look at what Thierry has done for Tegra[1] and copy a
>lot of that patch series.
>
>The main difference is that on Tegra they have hardware replay the edge
>vs. on qcom platforms we'll rely on the GIC SPI line for each PDC line
>to go high and then have the hierarchy replay the interrupt. Also, on
>Tegra they don't really care to allocate the irq in the GIC, whereas on
>qcom we'll want to allocate the interrupt in the GIC to get the replay
>to work. In the MPM design I think we'll need to use the
>irq_set_irqchip_state() API too so the MPM driver can replay the edge
>interrupts into the TLMM hardware when the MPM summary irq runs.
>
>[1] https://lkml.org/lkml/2018/9/21/471
>