Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1475919ybv; Thu, 20 Feb 2020 21:22:10 -0800 (PST) X-Google-Smtp-Source: APXvYqwFhvZZvrCXJrKLjFpoUJAq/6vATPcvq6DM3n3hbatxzzHPZOdBP32kzHagBLKf7ke8GeMq X-Received: by 2002:aca:f1c2:: with SMTP id p185mr583254oih.87.1582262529874; Thu, 20 Feb 2020 21:22:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582262529; cv=none; d=google.com; s=arc-20160816; b=O2eMwwwizk4KDh9KxF/39Ef2BJeSldLcKC3+FXAvNbTrEVlZfp9kKtxBpJOEwD0rxp 1B/uG9OoUPmtTWwwNgKHqrPRQ38NX2C1duoSdL+MtsXE/FnU5OmfvoY1qq30A6bRxqav Jzs8o8PFF4RULAI9wtTbGwL6XxzuZ4AYtK1xYltR8zHBORLtBdpWpq+2qXV/znC16GhL CwRwmg/JbTbYvoubONGum/wGHtBUJuKYtvPJ0WHoC7bgA9ujbwf7fjRDx88wRPszwif/ KrBSG1B1b53UX0i/L0n/ix8SnJTKscjtpAnSKpaGy5DDwjwLaYDFwituTthquqkVNGUv RXxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=FcHd1surxFv8GA5uVzEdd6JTxgVDS+du+geFP+sYdaQ=; b=bfN4cZtsykAbUqQTShnh7GQtSg2loj/g+XEWb7I1HgKfs3rLQy3BKsqNiH9uoo+CuL dCXUO2AvrPeBViy1R/fGkUX/22Cg6FN7JQJw6wJYukkjY/m2YlnWigYqR92Wi6KFbGNn u1xuir9alLCxqRSuq9vb9nREILwb7v26DIboDFRZAxEkerQz2CyTl3VrIVSYxe1GAoSi sP78z6gEp1XEWqEHGEq57s26hE+KXVX75ulZt3znyIYzMSkwv/FhKqI9MSoGQfxAZCQE lWTspsGttbceSInJl6GbqowdVmTsBWyREaV0Snwxgcy8+QbcSHREKBPzqZ2pF7/LEYgX /9rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=rZFfbt3I; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u204si276248oia.55.2020.02.20.21.21.57; Thu, 20 Feb 2020 21:22:09 -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; dkim=pass header.i=@kernel.org header.s=default header.b=rZFfbt3I; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726250AbgBUFVt (ORCPT + 99 others); Fri, 21 Feb 2020 00:21:49 -0500 Received: from mail.kernel.org ([198.145.29.99]:50150 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725800AbgBUFVt (ORCPT ); Fri, 21 Feb 2020 00:21:49 -0500 Received: from localhost (c-98-207-104-244.hsd1.ca.comcast.net [98.207.104.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7BD0D208C4; Fri, 21 Feb 2020 05:21:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582262508; bh=k+xWkXE9GanKA1I/TU4Il80HQEcFWT0VW7It7YnO+zk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=rZFfbt3Ind5n5SyHSLZN3GqLiBN5qUpHq45nLTBbtrWN4pYOamrXosFr3rLw5C/H3 KXTCjKCkEVfNrc3FHCGrEZdoEj4qiNosTJKLYEpodgKj5VoLN/LxWXvyGg7shdIyqf 2OguAs98pfUFkh7ppaynQ/11UWTr64XVMtVAZPTc= Date: Thu, 20 Feb 2020 23:21:47 -0600 From: Bjorn Helgaas To: Stuart Hayes Cc: Austin Bolen , keith.busch@intel.com, Alexandru Gagniuc , "Rafael J . Wysocki" , Mika Westerberg , Andy Shevchenko , "Gustavo A . R . Silva" , Sinan Kaya , Oza Pawandeep , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, lukas@wunner.de Subject: Re: [PATCH v4 3/3] PCI: pciehp: Add dmi table for in-band presence disabled Message-ID: <20200221052147.GA154040@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191025190047.38130-4-stuart.w.hayes@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 25, 2019 at 03:00:47PM -0400, Stuart Hayes wrote: > Some systems have in-band presence detection disabled for hot-plug PCI > slots, but do not report this in the slot capabilities 2 (SLTCAP2) register. This doesn't seem quite accurate to me. PCI_EXP_SLTCAP2_IBPD does not actually tell us whether in-band presence detection is disabled. It only tells us whether it *can* be disabled. I think I know what you mean, but this text suggests that PCI_EXP_SLTCAP2_IBPD not being set is the defect, and I don't think it is. IIUC, even if PCI_EXP_SLTCAP2_IBPD were set, PCI_EXP_SLTCTL_IBPD_DISABLE would have no effect because in-band presence detect just isn't supported at all regardless of how we set PCI_EXP_SLTCTL_IBPD_DISABLE. > On these systems, presence detect can become active well after the link is > reported to be active, which can cause the slots to be disabled after a > device is connected. > > Add a dmi table to flag these systems as having in-band presence disabled. > > Signed-off-by: Stuart Hayes > --- > v4 > add comment to dmi table > > drivers/pci/hotplug/pciehp_hpc.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c > index 02d95ab27a12..9541735bd0aa 100644 > --- a/drivers/pci/hotplug/pciehp_hpc.c > +++ b/drivers/pci/hotplug/pciehp_hpc.c > @@ -14,6 +14,7 @@ > > #define dev_fmt(fmt) "pciehp: " fmt > > +#include > #include > #include > #include > @@ -26,6 +27,24 @@ > #include "../pci.h" > #include "pciehp.h" > > +static const struct dmi_system_id inband_presence_disabled_dmi_table[] = { > + /* > + * Match all Dell systems, as some Dell systems have inband > + * presence disabled on NVMe slots (but don't support the bit to Is there something that restricts these slots to being used only for NVMe? If not, I'd rather simply say that some Root Ports don't support in-band presence detect. You say it's "disabled", which suggests that it could be *enabled*. But I have the impression that it's actually just not supported at all (or maybe it's disabled by the BIOS via some non-architected mechanism). > + * report it). Setting inband presence disabled should have no > + * negative effect, except on broken hotplug slots that never > + * assert presence detect--and those will still work, they will > + * just have a bit of extra delay before being probed. > + */ > + { > + .ident = "Dell System", > + .matches = { > + DMI_MATCH(DMI_OEM_STRING, "Dell System"), > + }, > + }, > + {} > +}; > + > static inline struct pci_dev *ctrl_dev(struct controller *ctrl) > { > return ctrl->pcie->port; > @@ -895,6 +914,9 @@ struct controller *pcie_init(struct pcie_device *dev) > ctrl->inband_presence_disabled = 1; > } > > + if (dmi_first_match(inband_presence_disabled_dmi_table)) > + ctrl->inband_presence_disabled = 1; This doesn't seem quite right: the DMI table should only apply to built-in ports, not to ports on plugin cards. If we plug in a switch with hotplug-capable downstream ports, and those ports do not advertise PCI_EXP_SLTCAP2_IBPD, I think this code sets "inband_presence_disabled" for those ports even though it is not disabled. IIUC, that will make this plugin card behave differently in a Dell system than it will in other systems, and that doesn't seem right to me. > /* > * If empty slot's power status is on, turn power off. The IRQ isn't > * requested yet, so avoid triggering a notification with this command. > -- > 2.18.1 >