linux-kernel - Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes

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, 28 Feb 2019 00:03:56 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Ganapathi Bhat <gbhat@...vell.com>,
        Jeffy Chen <jeffy.chen@...k-chips.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Devicetree List <devicetree@...r.kernel.org>,
        Xinming Hu <huxinming820@...il.com>,
        "<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
        linux-pm <linux-pm@...r.kernel.org>,
        "<linux-wireless@...r.kernel.org>" <linux-wireless@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Amitkumar Karwar <amitkarwar@...il.com>,
        linux-rockchip@...ts.infradead.org,
        Nishant Sarmukadam <nishants@...vell.com>,
        Rob Herring <robh+dt@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Kalle Valo <kvalo@...eaurora.org>,
        Tony Lindgren <tony@...mide.com>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes

On Wed, Feb 27, 2019 at 9:58 PM Brian Norris <briannorris@...omium.org> wrote:
>
> Hi Ard,
>
> On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
> > On Wed, 27 Feb 2019 at 11:02, Marc Zyngier <marc.zyngier@....com> wrote:
> > > On 26/02/2019 23:28, Brian Norris wrote:
> > > > You're not the first person to notice this. All the motivations are not
> > > > necessarily painted clearly in their cover letter, but here are some
> > > > previous attempts at solving this problem:
> > > >
> > > > [RFC PATCH v11 0/5] PCI: rockchip: Move PCIe WAKE# handling into pci core
> > > > https://lkml.kernel.org/lkml/20171225114742.18920-1-jeffy.chen@rock-chips.com/
> > > > http://lkml.kernel.org/lkml/20171226023646.17722-1-jeffy.chen@rock-chips.com/
> > > >
> > > > As you can see by the 12th iteration, it wasn't left unsolved for lack
> > > > of trying...
> > >
> > > I wasn't aware of this. That's definitely a better approach than my
> > > hack, and I would really like this to be revived.
> > >
> >
> > I don't think this approach is entirely sound either.
>
> (I'm sure there may be problems with the above series. We probably
> should give it another shot though someday, as I think it's closer to
> the mark.)
>
> > From the side of the PCI device, WAKE# is just a GPIO line, and how it
> > is wired into the system is an entirely separate matter. So I don't
> > think it is justified to overload the notion of legacy interrupts with
> > some other pin that may behave in a way that is vaguely similar to how
> > a true wake-up capable interrupt works.
>
> I think you've conflated INTx with WAKE# just a bit (and to be fair,
> that's exactly what the bad binding we're trying to replace did,
> accidentally). We're not trying to claim this WAKE# signal replaces the
> typical PCI interrupts, but it *is* an interrupt in some sense --
> "depending on your definition of interrupt", per our IRC conversation ;)
>
> > So I'd argue that we should add an optional 'wake-gpio' DT property
> > instead to the generic PCI device binding, and leave the interrupt
> > binding and discovery alone.
>
> So I think Mark Rutland already shot that one down; it's conceptually an
> interrupt from the device's perspective.

Which device are you talking about?  The one that signals wakeup?  If
so, then I beg to differ.

On ACPI platforms WAKE# is represented as an ACPI GPE that is signaled
through SCI and handled at a different level (on HW-reduced ACPI it
actually can be a GPIO interrupt, but it still is handled with the
help of AML).  The driver of the device signaling wakeup need not even
be aware that WAKE# has been asserted.

> We just need to figure out a good way of representing it that doesn't stomp on the existing INTx
> definitions.

WAKE# is a signal that is converted into an interrupt, but that
interrupt may arrive at some place your driver has nothing to do with.
It generally doesn't make sense to represent it as an interrupt for
the target device.