From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brian Norris Subject: Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes Date: Tue, 26 Feb 2019 15:44:23 -0800 Message-ID: <20190226234422.GD174696@google.com> References: <20190224140426.3267-1-marc.zyngier@arm.com> <5310b73b-4821-6dff-b9c0-34c59fb7fd72@arm.com> <0c433a70-27f6-76ad-c46c-6015de1ffaa4@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <0c433a70-27f6-76ad-c46c-6015de1ffaa4@arm.com> Sender: linux-kernel-owner@vger.kernel.org To: Marc Zyngier Cc: Ard Biesheuvel , Amitkumar Karwar , Enric Balletbo i Serra , Ganapathi Bhat , Heiko Stuebner , Kalle Valo , Nishant Sarmukadam , Rob Herring , Xinming Hu , Devicetree List , "" , "" , Linux Kernel Mailing List , linux-rockchip@lists.infradead.org, "David S. Miller" , linux-arm-kernel , linux-pci@vger.kernel.org, linux-pm@vger.kernel.o List-Id: devicetree@vger.kernel.org Hi, On Tue, Feb 26, 2019 at 05:14:00PM +0000, Marc Zyngier wrote: > On 26/02/2019 16:21, Ard Biesheuvel wrote: > > On Mon, 25 Feb 2019 at 15:53, Marc Zyngier wrote: > >> It outlines one thing: If you have to interpret per-device PCI > >> properties from DT, you're in for serious trouble. I should get some > >> better HW. > >> > > > > Yeah, it obviously makes no sense at all for the interrupt parent of a > > PCI device to deviate from the host bridge's interrupt parent, and > > it's quite unfortunate that we can't simply ban it now that the cat is > > out of the bag already. > > > > Arguably, the wake up widget is not part of the PCI device, but I have > > no opinion as to whether it is better modeling it as a sub device as > > you are proposing or as an entirely separate device referenced via a > > phandle. > > It is not that clear. The widget seems to be an integral part of the > device, as it is the same basic IP that is used for SDIO and USB. It's not really a widget specific to this IP. It's just a GPIO. It so happens that both SDIO and PCIe designs have wanted to use a GPIO for wakeup, as many other devices do. (Note: it's not just cheap ARM devices; pulling up some Intel Chromebook designs, I see the exact same WAKE# GPIO on their PCIe WiFi as well.) > It looks like the good old pre-PCI-2.2 days, where you had to have a > separate cable between your network card and the base-board for the > wake-up interrupt to be delivered. Starting with PCI-2.2, the bus can > carry the signal just fine. With PCIe, it should just be an interrupt > TLP sent to the RC, but that's obviously not within the capabilities of > the HW. You should search the PCI Express specification for WAKE#. There is a clearly-documented "side-band wake" feature that is part of the standard, as an alternative to in-band TLP wakeup. While you claim this is an ancient thing, it in fact still in use on many systems -- it's just usually abstracted better by ACPI firmware, whereas the dirty laundry is aired a bit more on a Device Tree system. And we got it wrong. > Anyway, it'd be good if the Marvell people could chime in and let us > know how they'd prefer to handle this. I'm not sure this is really a Marvell-specific problem. (Well, except for the marvell,wakeup-pin silliness, which is somewhat orthogonal.) In fact, if we cared a little more about Wake-on-WiFi, we'd be trying to support the same (out-of-band WAKE#) with other WiFi drivers. Brian