Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp547261pxu; Tue, 6 Oct 2020 12:42:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvdFNmj49jNsqtZS+YyvHZGF2lPrYpT2JpKNgzz1pv4vBj2KLJxQSYPVvuWCzsGBIzkiAZ X-Received: by 2002:a05:6402:7d2:: with SMTP id u18mr7484309edy.69.1602013369177; Tue, 06 Oct 2020 12:42:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602013369; cv=none; d=google.com; s=arc-20160816; b=tlDHHN6JChwwRTZQE3o8Dfheh70HqnxfOLWUf3PtH+PveOWM87CpVmDtE/ePzYkPPV y20xQ1LDpXINcWIc1b9dI7UylEJYkgyM0gPDrA6AvLcncik6gztAmwAjNfypQ0DLCDHM 8q5dtLxBhd3nlFF9D6xi9hp+AJEoRS/1Csh5ckSpinFbj6VTvZF/UzRSfShaxDi15hme NhYnzjLnlohxo6hxZfN7l9ZomaZOMRpk7GvH4q8wUaXL1SwHZCUIN/7BY5f5uzYtRSjO o2CxwmLkHgfi/yq+1fJCM6g9m3LK9T07JyCcTDXMJtHmDhLV0TgZE6S5mXq6HEWlbmY9 i5/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Iy+VO2BVRtrBg+jVkRKtz/sb9rLwsmjo+8iFpZeTOFA=; b=qB1Imzf0ZyQm8ESLjuqoKGXkOI9oV0LpQ/osG2ce0e12NDuVnH9Dw7ofQ/TYUi3B6A qFYW5o6p+41egV9909hUd4NWCFxtS2DoakbnjLXNs9HZoIhMT0413uFaN8ay7jBUofSK bIxRbMXLkffW50JOFf3yLQ2BYB4adgAtoO6rp/Vne9vKPbHPbTZDDtKHfbqM+gnZFrmu DoCKv9aWp4pdp3i09NO041TB8sn0xMHfmrm1sSBH+0FNhQr5TJaEhvuTGJd4BwRo5rn4 SBKj3dZZjI+ZiIHzZ9RaTcPg05D2YsFsh5YxXLVH+eTT4JnVJeL3HfJ9sxZhPOJ5C+hT h9KQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q21si3164289edg.592.2020.10.06.12.42.26; Tue, 06 Oct 2020 12:42:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727140AbgJFTif (ORCPT + 99 others); Tue, 6 Oct 2020 15:38:35 -0400 Received: from bmailout3.hostsharing.net ([176.9.242.62]:35539 "EHLO bmailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725943AbgJFTie (ORCPT ); Tue, 6 Oct 2020 15:38:34 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (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 bmailout3.hostsharing.net (Postfix) with ESMTPS id E95E1100EF4DD; Tue, 6 Oct 2020 21:38:30 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id B7738656AC; Tue, 6 Oct 2020 21:38:30 +0200 (CEST) Date: Tue, 6 Oct 2020 21:38:30 +0200 From: Lukas Wunner To: Sanjay R Mehta Cc: bhelgaas@google.com, andriy.shevchenko@linux.intel.com, stuart.w.hayes@gmail.com, mr.nuke.me@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] PCI: pciehp: Add check for DL_ACTIVE bit in pciehp_check_link_status() Message-ID: <20201006193830.GA32510@wunner.de> References: <1602008668-43646-1-git-send-email-Sanju.Mehta@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1602008668-43646-1-git-send-email-Sanju.Mehta@amd.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 06, 2020 at 01:24:28PM -0500, Sanjay R Mehta wrote: > if DL_ACTIVE bit is set it means that there is no need to check > PCI_EXP_LNKSTA_LT bit, as DL_ACTIVE would have set only if the link > is already trained. Hence adding a check which takes care of this > scenario. Sorry for being dense but I don't understand this at all: The PCI_EXP_DPC_CAP_DL_ACTIVE bit which you check here indicates that the port is capable of sending an ERR_COR interrupt whenever the link transitions from inactive to active. What is the connection to the PCI_EXP_LNKSTA_LT bit (which indicates that the link is still being trained)? Also, the negation of a bitwise AND is always either 0 or 1 (!(lnk_status & PCI_EXP_DPC_CAP_DL_ACTIVE)), so bit 0 is set or not set. However PCI_EXP_LNKSTA_LT is bit 11. A bitwise AND of bit 11 and 0 is always 0, so the expression can never be 1. Am I missing something? Thanks, Lukas > Signed-off-by: Sanjay R Mehta > --- > drivers/pci/hotplug/pciehp_hpc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c > index 53433b3..81d1348 100644 > --- a/drivers/pci/hotplug/pciehp_hpc.c > +++ b/drivers/pci/hotplug/pciehp_hpc.c > @@ -309,7 +309,8 @@ int pciehp_check_link_status(struct controller *ctrl) > > pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status); > ctrl_dbg(ctrl, "%s: lnk_status = %x\n", __func__, lnk_status); > - if ((lnk_status & PCI_EXP_LNKSTA_LT) || > + if (((lnk_status & PCI_EXP_LNKSTA_LT) & > + !(lnk_status & PCI_EXP_DPC_CAP_DL_ACTIVE)) || > !(lnk_status & PCI_EXP_LNKSTA_NLW)) { > ctrl_err(ctrl, "link training error: status %#06x\n", > lnk_status); > -- > 2.7.4