Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp3477348imc; Sun, 24 Feb 2019 06:06:13 -0800 (PST) X-Google-Smtp-Source: AHgI3IbACKQMgz8iy7WjdQfHpGAJiuO9KOHK+MLSjFlyisydd4WnnRzKXWqNnldxbf/MBqzYsUZO X-Received: by 2002:a62:70c9:: with SMTP id l192mr14344571pfc.207.1551017173319; Sun, 24 Feb 2019 06:06:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551017173; cv=none; d=google.com; s=arc-20160816; b=fKWMq2xXhi4zh6AHqAorkY4y2hgnCfT7gcTyDL2vGUdVDWIiZpK8t79WNPnhdssFoL QGhnLg+KnOceyW5UbtRp4cnK7a1vo5ynDsxW/HUievFaQ1g5zPH+f2y7MKyATofn3Xku kusviZlXwMi8E+FGQV4lYxGX331dpR6f9agRyPSXI4W9jMlrPux/9q5XTlj1+Svb0b+x pvqmmZER4AIpDGL1w+/C6IQGAy5VKvMGpmq1lE5xoCfQoU9wP2zxk50q8mwHtv6ydomZ RB1eP94t7DgFOLP2jBk5I3piRKKgzJqWGdEv3DDkk6ow6NAP2+cwHNIBgiCsDEH7qDra BRCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=Pd7pTftFKXPqPkk2fNSzpHq3Oe1vedD/ZUv6Hk4pOwE=; b=bxGS8XcUqh70eYJO8//F9tFvXYkNoUkboeKmCp8OhJGWD2gk8A331e318LIHrKzuML C4JLkwY6OFWFflw9eGtD2jLM4il9TdWWHRQnQapJSDbiSWIIAeLdObKzsTaD/dArkXsi sG3CmW7YjsQr2cA2M2kpshAeNx/wjRp+/kA6k/SNgUNqJ3o1LFr939LGXp4LRiUvTbGC E5FnKHnJpgxLHs3wPu8Fz9AZVlmKWtbAsic5EJSk/sTOWBLTgM139vR+B6hzmxmh0qmz oSabeokAWjww8jY1SQWDHr6+0vijHsjO4YhvmsMpvSRneOooSsnJYiFRy3YhDXFyds3j Vj/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1si6471113pld.197.2019.02.24.06.05.41; Sun, 24 Feb 2019 06:06:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728337AbfBXOFK (ORCPT + 99 others); Sun, 24 Feb 2019 09:05:10 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52460 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726835AbfBXOFJ (ORCPT ); Sun, 24 Feb 2019 09:05:09 -0500 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 Cc: "David S. Miller" , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org 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 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(-) -- 2.20.1