Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp222595imp; Wed, 20 Feb 2019 23:37:30 -0800 (PST) X-Google-Smtp-Source: AHgI3IZNulzqjMkBAIr4KiNt85r05Iw/OfEuk6GTgFuUDD+bEfQs1vGjA+Wai1K0l/8I/enL/gFU X-Received: by 2002:a62:35c7:: with SMTP id c190mr39944893pfa.76.1550734650866; Wed, 20 Feb 2019 23:37:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550734650; cv=none; d=google.com; s=arc-20160816; b=B9k1FYBa6CqBjGM59WYDCGQBkSVqJyeWcdzht4sU/gvGU1CXEu/FLChrLtYl0R0BBW uZHWjjw1iQSUglzevcesMsU/ecYqYoxG2hD/WMTEaXvgg+s2TOemuJcCtHCF4furxS3Y lPUrxaorKsewsTUby0pXkKeITrz+WDIzqeGHrZEaqE2coq0RvprOEwNMKX+BzC2CmegF HT33eVW0Kei+dSWRM9GC++RAXzgSV8DhipraTtu0v+ec2gCq0jxVwVNyfU4dWQEc+mO0 87mktyjyC9LSZWnTBppm3D3u0SMdDnag/p4LHDtrE533ujhw0xHtr9VWdvIH2PfCn+P2 wW8Q== 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:references:message-id:subject:cc :to:from:date; bh=EWIzXMvXG/Y69UbllHYhp2oN68tNrsd+bHB2M+NpFR4=; b=dHW7XOvpDP3f+MhXHNWGLv6NaWJGYjJELVnki+dqrWCugPre+257jgoh1fAT8b1lpH vUublbEh2Gylaowmc8C1pwsMSRZd3PCt2bByAxP0TmWn3LOGz1f6893OMrK+rs464wDt odk73UWNAhOQBlWtZq28vstccTmJEXgt+iYLY6pncwoBQGUZ8SpPTlY1W4CfmiPiXxgr rbmKV6ZKKMgtvL9dleym/ZEte5R0NA2H+5Fc/mMzC269ByhWcSM0Cg2zHtjZP+6+2Rt8 FIhasOLMdd3k7lfdFqlbCOm4zQDLAFW9/4cH+kcI2Q0/naKtI8IRs07pVSbsMtYKeLXy beSA== 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 z3si20698280plo.39.2019.02.20.23.37.15; Wed, 20 Feb 2019 23:37:30 -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 S1726360AbfBUHgh (ORCPT + 99 others); Thu, 21 Feb 2019 02:36:37 -0500 Received: from bmailout1.hostsharing.net ([83.223.95.100]:33933 "EHLO bmailout1.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725648AbfBUHgg (ORCPT ); Thu, 21 Feb 2019 02:36:36 -0500 Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id 7625130000CC0; Thu, 21 Feb 2019 08:36:34 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 529EB326AD; Thu, 21 Feb 2019 08:36:34 +0100 (CET) Date: Thu, 21 Feb 2019 08:36:34 +0100 From: Lukas Wunner To: Alexandru Gagniuc Cc: bhelgaas@google.com, austin_bolen@dell.com, alex_gagniuc@dellteam.com, keith.busch@intel.com, Shyam_Iyer@Dell.com, okaya@kernel.org, linux-pci@vger.kernel.org, "Gustavo A. R. Silva" , linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC v2 2/4] PCI: pciehp: Do not turn off slot if presence comes up after link Message-ID: <20190221073634.snvazxlzgvjhilaz@wunner.de> References: <20190220012031.10741-1-mr.nuke.me@gmail.com> <20190220012031.10741-3-mr.nuke.me@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190220012031.10741-3-mr.nuke.me@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 19, 2019 at 07:20:28PM -0600, Alexandru Gagniuc wrote: > @@ -213,6 +213,21 @@ void pciehp_handle_disable_request(struct controller *ctrl) > ctrl->request_result = pciehp_disable_slot(ctrl, SAFE_REMOVAL); > } > > +static bool is_delayed_presence_up_event(struct controller *ctrl, u32 events) > +{ > + bool present, link_active; > + > + if (!ctrl->inband_presence_disabled) > + return false; > + > + present = pciehp_card_present(ctrl); > + link_active = pciehp_check_link_active(ctrl); > + > + if (!present || !link_active || events & PCI_EXP_SLTSTA_DLLSC) > + return false; > + > + return true; > +} > void pciehp_handle_presence_or_link_change(struct controller *ctrl, u32 events) Newline please after the closing curly brace. > @@ -220,13 +235,22 @@ void pciehp_handle_presence_or_link_change(struct controller *ctrl, u32 events) > /* > * If the slot is on and presence or link has changed, turn it off. > * Even if it's occupied again, we cannot assume the card is the same. > + * When the card is swapped, we also expect a change in link state, > + * without which, it's likely presence became high after link-active. > */ Maybe it's just me but I find the code comment difficult to understand. How about something along the lines of: /* * If the slot is on and presence or link has changed, turn it off. * Even if it's occupied again, we cannot assume the card is the same. + * + * An exception is a delayed "Card present" after a "Link Up". + * This can happen on controllers with in-band presence disabled, + * PCIe r5.0 sec X.Y.Z. */ > mutex_lock(&ctrl->state_lock); > + present = pciehp_card_present(ctrl); > + link_active = pciehp_check_link_active(ctrl); > switch (ctrl->state) { These two assignments appear to be superfluous as you're also performing them in pciehp_check_link_active(). Thanks, Lukas