From patchwork Sun Feb 24 14:04:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 10827995 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E106213B5 for ; Sun, 24 Feb 2019 14:08:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CC19829B3A for ; Sun, 24 Feb 2019 14:08:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BCC192B471; Sun, 24 Feb 2019 14:08:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 620B729B3A for ; Sun, 24 Feb 2019 14:08:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=5dsTW+4qCHq8YtvjKfVHiYB2vCErCnX+7O54DwtiXlM=; b=ZmcnBjvBLgl6oJ OefZO0pRuQeM2YgXIsTwMU9LLnNZOU0ySzTJvVEyyXQscxJykbwVzIB8RkOgCTncFdf5pn1UvuygU ZsJ2d8fdMaE+uoJO7dtsA8Y/VnK0g/8zH21hWHGfosYdwxGx3sFtZcs9bHSrRFiq1ZEnUjohlXvEv qgOWsyR2KGrzt/tzcB6ge4NO2GJOy2s71obAqyEMmr0bKv1u00N9IYsaDWFvVxSXTiaaKt67y8Dss 8QOGAF4obPkBqndqBYKjNHMJS4UIRcrcXbxfKl1jOi7l1FNX9pz88d/TC+Efwi/ziMe4e4Au3IpGk 0Sl1GVzju68GcRPiq0dA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gxuPg-00089o-PH; Sun, 24 Feb 2019 14:05:52 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gxuP8-0007Ye-CR; Sun, 24 Feb 2019 14:05:22 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D7859A78; Sun, 24 Feb 2019 06:05:08 -0800 (PST) Received: from why.lan (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B762A3F690; Sun, 24 Feb 2019 06:05:05 -0800 (PST) From: Marc Zyngier To: Amitkumar Karwar , Enric Balletbo i Serra , Ganapathi Bhat , Heiko Stuebner , Kalle Valo , Nishant Sarmukadam , Rob Herring , Xinming Hu Subject: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes Date: Sun, 24 Feb 2019 14:04:22 +0000 Message-Id: <20190224140426.3267-1-marc.zyngier@arm.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190224_060518_427791_4C1ABA6F X-CRM114-Status: GOOD ( 13.63 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, "David S. Miller" , linux-arm-kernel@lists.infradead.org Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP For quite some time, I wondered why the PCI mwifiex device built in my Chromebook was unable to use the good old legacy interrupts. But as MSIs were working fine, I never really bothered investigating. I finally had a look, and the result isn't very pretty. On this machine (rk3399-based kevin), the wake-up interrupt is described as such: &pci_rootport { mvl_wifi: wifi@0,0 { compatible = "pci1b4b,2b42"; reg = <0x83010000 0x0 0x00000000 0x0 0x00100000 0x83010000 0x0 0x00100000 0x0 0x00100000>; interrupt-parent = <&gpio0>; interrupts = <8 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; pinctrl-0 = <&wlan_host_wake_l>; wakeup-source; }; }; Note how the interrupt is part of the properties directly attached to the PCI node. And yet, this interrupt has nothing to do with a PCI legacy interrupt, as it is attached to the wake-up widget that bypasses the PCIe RC altogether (Yay for the broken design!). This is in total violation of the IEEE Std 1275-1994 spec[1], which clearly documents that such interrupt specifiers describe the PCI device interrupts, and must obey the INT-{A,B,C,D} mapping. Oops! The net effect of the above is that Linux tries to do something vaguely sensible, and uses the same interrupt for both the wake-up widget and the PCI device. This doesn't work for two reasons: (1) the wake-up widget grabs the interrupt in exclusive mode, and (2) the PCI interrupt is still routed to the RC, leading to a screaming interrupt. This simply cannot work. To sort out this mess, we need to lift the confusion between the two interrupts. This is done by extending the DT binding to allow the wake-up interrupt to be described in a 'wake-up' subnode, sidestepping the issue completely. On my Chromebook, it now looks like this: &pci_rootport { mvl_wifi: wifi@0,0 { compatible = "pci1b4b,2b42"; reg = <0x83010000 0x0 0x00000000 0x0 0x00100000 0x83010000 0x0 0x00100000 0x0 0x00100000>; pinctrl-names = "default"; pinctrl-0 = <&wlan_host_wake_l>; wake-up { interrupt-parent = <&gpio0>; interrupts = <8 IRQ_TYPE_LEVEL_LOW>; wakeup-source; }; }; }; The driver is then updated to look for this subnode first, and fallback to the original, broken behaviour (spitting out a warning in the offending configuration). For good measure, there are two additional patches: - The wake-up interrupt requesting is horribly racy, and could lead to unpredictable behaviours. Let's fix that properly. - A final patch implementing the above transformation for the whole RK3399-based Chromebook range, which all use the same broken configuration. With all that, I finally have PCI legacy interrupts working with the mwifiex driver on my Chromebook. [1] http://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf Marc Zyngier (4): dt-bindings/marvell-8xxx: Allow wake-up interrupt to be placed in a separate node mwifiex: Fetch wake-up interrupt from 'wake-up' subnode when it exists mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late arm64: dts: rockchip: gru: Move wifi wake-up interrupt into its own subnode .../bindings/net/wireless/marvell-8xxx.txt | 23 ++++++++++++++++++- .../dts/rockchip/rk3399-gru-chromebook.dtsi | 8 ++++--- drivers/net/wireless/marvell/mwifiex/main.c | 13 +++++++++-- 3 files changed, 38 insertions(+), 6 deletions(-)