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]

Message-ID: <CA+ASDXNT9Taqfoz7R1Z926Vi1fMNNLYg5vqcZTw2m6JvXk+75w@mail.gmail.com>
Date:   Wed, 27 Feb 2019 18:29:21 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     "Rafael J. Wysocki" <rafael@...nel.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>,
        "open list:ARM/Rockchip SoC..." <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

Hi Rafael,

On Wed, Feb 27, 2019 at 3:04 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Wed, Feb 27, 2019 at 9:58 PM Brian Norris <briannorris@...omium.org> wrote:
> > On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
> > > 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.

Perhaps I shouldn't speak for Mark, but I am basically quoting him off IRC.

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

Yes, the endpoint device.

> 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.

Frankly, ACPI is not relevant to how we represent WAKE# in DT, IMO.
Also, we're talking about the *device*, not the driver. When talking
about Device Tree, that distinction is relevant.

So while the driver need not be aware (and I agree! it only needs to
care about enabling/disabling wake), *something* should be aware, and
the signal that "something" should be receiving is simply "did WAKE
happen"? That sounds basically like the device is signalling an
interrupt to me.

Maybe this goes back to some confusion we had elsewhere: what is the
meaning of "interrupt" in device tree?

> > 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.

I could agree with that, perhaps. But that's also what Device Tree is
all about, really. We describe the relation between devices. So some
other <foo> handles events that are triggered by <bar>, so we use a
phandle to relate <bar> to <foo>.

> It generally doesn't make sense to represent it as an interrupt for
> the target device.

What would you suggest then? I'm not clearly understanding how you
think we should (a) describe (in DT) and (b) implement this WAKE#
handling.

Brian