From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA9EDC33CAF for ; Thu, 16 Jan 2020 17:16:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BCAA220728 for ; Thu, 16 Jan 2020 17:16:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579194968; bh=Pt1wIy+Ga/MODLru/Fw2LqJ2BaxDv6nVC/Ngcmk9cFE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=GW73BsN9Ya3SRysWGyhqF3D0AqR7KAW+5Snyee4JiwqkbIk3fY5NtCBB2cjdAilh6 Tyg26cJKLmjj047Ae6P+KkEvCK7IAdsdV6QXvWdaBikB/RMBp8Lh96y2OpVQJDZ/vF F32G5Jh+N/E97us8oWxqaR/XNn6s53Gv+F3+O4zg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390824AbgAPRQH (ORCPT ); Thu, 16 Jan 2020 12:16:07 -0500 Received: from mail.kernel.org ([198.145.29.99]:33198 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390971AbgAPROV (ORCPT ); Thu, 16 Jan 2020 12:14:21 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E7EC6246B8; Thu, 16 Jan 2020 17:14:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579194860; bh=Pt1wIy+Ga/MODLru/Fw2LqJ2BaxDv6nVC/Ngcmk9cFE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RtoqgRwkivpcJC2Asl5zeaJ2O+0wGaQxfTPwDYu0Ybm/BIQ4Fi6A3E9TdpBievH5h rXshNCoMC3J9SV7GwYXVXIHk2zEAUX9rGVZ2iFv29d5OYwikWXcfxsFPJ6BoJacFjs 56W9e+JlD11DqFijKxeqIKrwNjdU8KrzWH7nWGhI= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Oliver O'Halloran , Michael Ellerman , Sasha Levin , linuxppc-dev@lists.ozlabs.org Subject: [PATCH AUTOSEL 4.19 655/671] powerpc/powernv: Disable native PCIe port management Date: Thu, 16 Jan 2020 12:04:53 -0500 Message-Id: <20200116170509.12787-392-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200116170509.12787-1-sashal@kernel.org> References: <20200116170509.12787-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Oliver O'Halloran [ Upstream commit 9d72dcef891030545f39ad386a30cf91df517fb2 ] On PowerNV the PCIe topology is (currently) managed by the powernv platform code in Linux in cooperation with the platform firmware. Linux's native PCIe port service drivers operate independently of both and this can cause problems. The main issue is that the portbus driver will conflict with the platform specific hotplug driver (pnv_php) over ownership of the MSI used to notify the host when a hotplug event occurs. The portbus driver claims this MSI on behalf of the individual port services because the same interrupt is used for hotplug events, PMEs (on root ports), and link bandwidth change notifications. The portbus driver will always claim the interrupt even if the individual port service drivers, such as pciehp, are compiled out. The second, bigger, problem is that the hotplug port service driver fundamentally does not work on PowerNV. The platform assumes that all PCI devices have a corresponding arch-specific handle derived from the DT node for the device (pci_dn) and without one the platform will not allow a PCI device to be enabled. This problem is largely due to historical baggage, but it can't be resolved without significant re-factoring of the platform PCI support. We can fix these problems in the interim by setting the "pcie_ports_disabled" flag during platform initialisation. The flag indicates the platform owns the PCIe ports which stops the portbus driver from being registered. This does have the side effect of disabling all port services drivers that is: AER, PME, BW notifications, hotplug, and DPC. However, this is not a huge disadvantage on PowerNV since these services are either unused or handled through other means. Fixes: 66725152fb9f ("PCI/hotplug: PowerPC PowerNV PCI hotplug driver") Signed-off-by: Oliver O'Halloran Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191118065553.30362-1-oohall@gmail.com Signed-off-by: Sasha Levin --- arch/powerpc/platforms/powernv/pci.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c index db230a35609b..c846300b7836 100644 --- a/arch/powerpc/platforms/powernv/pci.c +++ b/arch/powerpc/platforms/powernv/pci.c @@ -1095,6 +1095,23 @@ void __init pnv_pci_init(void) if (!firmware_has_feature(FW_FEATURE_OPAL)) return; +#ifdef CONFIG_PCIEPORTBUS + /* + * On PowerNV PCIe devices are (currently) managed in cooperation + * with firmware. This isn't *strictly* required, but there's enough + * assumptions baked into both firmware and the platform code that + * it's unwise to allow the portbus services to be used. + * + * We need to fix this eventually, but for now set this flag to disable + * the portbus driver. The AER service isn't required since that AER + * events are handled via EEH. The pciehp hotplug driver can't work + * without kernel changes (and portbus binding breaks pnv_php). The + * other services also require some thinking about how we're going + * to integrate them. + */ + pcie_ports_disabled = true; +#endif + /* Look for IODA IO-Hubs. */ for_each_compatible_node(np, NULL, "ibm,ioda-hub") { pnv_pci_init_ioda_hub(np); -- 2.20.1