linux-kernel - Re: [PATCH v3 3/3] pinctrl: qcom: Clear possible pending irq when remuxing GPIOs

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:   Fri, 11 Dec 2020 14:14:48 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     Jason Cooper <jason@...edaemon.net>,
        Linus Walleij <linus.walleij@...aro.org>,
        Marc Zyngier <maz@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Srinivas Ramana <sramana@...eaurora.org>,
        Maulik Shah <mkshah@...eaurora.org>,
        Neeraj Upadhyay <neeraju@...eaurora.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Andy Gross <agross@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 3/3] pinctrl: qcom: Clear possible pending irq when
 remuxing GPIOs

Hi,

On Thu, Dec 10, 2020 at 1:56 PM Stephen Boyd <swboyd@...omium.org> wrote:
>
> Quoting Douglas Anderson (2020-12-09 16:41:03)
> > Conceptually, we can envision the input on Qualcomm SoCs to pass
> > through a bunch of blocks between coming into the chip and becoming a
> > GPIO interrupt.  From guessing and running a handful of tests, I
> > believe that we can represent the state of the world with a drawing
> > that looks something like this:
> >
> >  +-----------------+       +-----------------+       +-----------------+
> >  |      INPUT      |  -->  |      PINMUX     |       |    IS_INPUT     |
> >  +-----------------+       |                 |  -->  |                 |
> >                            | output bogus (?)|       | output bogus (?)|
> >                            | if not muxed    |       | if input disab. |
> >                            +-----------------+       +-----------------+
> >                                                               |
> >           +---------------------------------------------------+--> to PDC
> >           |
> >           V
> >  +-----------------+       +-----------------+       +-----------------+
> >  | INTR RAW ENABLE |       | DETECTION LOGIC |       | STATUS REGISTER |
> >  |                 |       |                 |       |                 |
> >  | output bogus (?)|  -->  | maybe handles   |       | latches inputs  |
> >  | if disabled     |       | polarity diffs  |  -->  | that are high   |
> >  +-----------------+       |                 |       |                 |
> >                            | maybe debounces |       | write 1 to clr  |
> >                            | level irqs      |       +-----------------+
> >                            +-----------------+                |
> >                                                               |
> >           +---------------------------------------------------+
> >           |
> >           V
> >  +-----------------+
> >  |      ENABLE     |
> >  |                 |       +-----------------+
> >  | nothing passes  |  -->  |   SUMMARY IRQ   |
> >  | through if      |       +-----------------+
> >  | disabled        |
> >  +-----------------+
>
> This diagram doesn't make sense to me.

I've gutted most of this code for v4 after Maulik pointed out why my
testing was flawed.  Hopefully v4 looks saner...

-Doug