Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp815216imm; Thu, 31 May 2018 09:51:18 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKml4KMBCkZMVu4o7halGMW/WtDGruUBaOcIvC6HryvFhr7X9t4VBc/M++lN9sW/AIz38sF X-Received: by 2002:a17:902:329:: with SMTP id 38-v6mr7781526pld.328.1527785478433; Thu, 31 May 2018 09:51:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527785478; cv=none; d=google.com; s=arc-20160816; b=XStE1g5cgDNkSXXsK5+H2FTj84gLMBS8QC0oLncnV/UazrOwEZqrZnKTRGVgakQedf yo6yMzAaKLmmprIwnatZ2FWGS2MeaSiEu8iNaRtTKWlveQ6qZhVWgQLGBfAKrjCx06eA 6WS/kOeCKNyqKwQMyCLE+1+C50r02GvT5jWcRJULCmqANcGZZu/qtaOj8qouYW/afC34 QDU4KT7/mEWBFKZAPOrorpjeWbMUnxswkzdtGIz9kBtd0cKs6NxM96VvtuTYjTXL6Uea Hlqd3O02puHnP6XU2iRHytHHFcyhcKX/l2qn849MiSgMdnLKIc07S2V0Jcc1laEe6g2z Nk1w== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=S/Lj+p929P9xHRJaywd2pyUNPYIrdEShlJxkh9f0/ds=; b=o6/PujGS/SBjnlJ7stJQALT1g7+FmWBlDkMlHbXGgnJ4ZiD6Hb4//NTYhzzshHSQ2z //6CKbtbKDJGMzfv/Og8YhDVs6enNVluQAuXDBsDPZNHlC3MLTJH5YMXpLzM02+rwrXX zQJoiuE1DHgrRHmcbigEmB4BIFpBBCxx3wmbKqEvMGi4YLk6n5lhYJqVhl49BZrNNNxn 6frTXWKgLj8HX38pAnf8e592ZXnaaNG5LGMbZSFnU/QkBxqEetIrf9jX54ruNyFEiDQD RdUAGBHc5NXpeZSQQeuCOiUq595dVzXnlJxKiPQSAom/yZluSndgSKchD7S8Lv40zsML 0bYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gki0/DJd; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e1-v6si29859788pgr.167.2018.05.31.09.51.04; Thu, 31 May 2018 09:51:18 -0700 (PDT) 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=@gmail.com header.s=20161025 header.b=gki0/DJd; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755737AbeEaQt1 (ORCPT + 99 others); Thu, 31 May 2018 12:49:27 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:38729 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755696AbeEaQtZ (ORCPT ); Thu, 31 May 2018 12:49:25 -0400 Received: by mail-oi0-f68.google.com with SMTP id d5-v6so17069638oib.5; Thu, 31 May 2018 09:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S/Lj+p929P9xHRJaywd2pyUNPYIrdEShlJxkh9f0/ds=; b=gki0/DJdB6Trv9ttOovzYM5KJkR5LrAlmdYEtQpYLKdSDMPoj73DPUiPP+vCowgwhU unxh2gia/ZXDO2feIG+qmWkhSsVhhVw5WJ1NW0pNwFusTNWLccxPPsLLw4qk4bOzBtvF ivrJRtNihW4Oz/3y2lC0fuwIr9Oz5vNAJf8PLpFddCKaK40tCXN6XGCd1MxzlOLrLc+P sskGdZI4Kepue6zxXOlJvi1/tJj9IfVf66Q8am5vZm7CJj2tVJBTyariqUTE3S8xluHw Jp/4+aYZHr7YNQ6RI0nuc3umK9Iq5V2ZyHcaTXRTUPQybNTmjOjGrg+2tJnXlc6JXewC NMQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S/Lj+p929P9xHRJaywd2pyUNPYIrdEShlJxkh9f0/ds=; b=DxPaYJwlG2SeeaBn6hHDtVuj+o9DlEGlsbRCVJPPNbQBoKbQSPH9QDzGr1a4EQuWD5 8ad6xcCu7ct9iFvk9jwT4i47XMA6BXNQU0z9QJ1ocThweiAIr6QnMAevUlpicL5j2sJh rm5YZ9V1QzFpy4wAIw0o+W8Z7AEZL8PBELO+KnxmTZhsFSipWEtqGDCRVtIBYVGIjO+m Gxjqeh7/VD4edNJvhj3+uQ6Wqc55zmKctEgoaYMYhRMMJ8I+ZNPv2fFoL9oGg2cO3uVW 01YVRHmkvROZlh4990cFHthKGgNVteqwaJG2+GCSMvmQhJL+DZG+rVNayXBtQCJbFTND 9Wlg== X-Gm-Message-State: APt69E2OeNk3r9grgXIbGmaK4blTyWQKtXAiPzoIcSGctwjC1At2hk2i xPACA0T3OEcj2Xz2nN2BKoEmcQH+yXA= X-Received: by 2002:aca:5e43:: with SMTP id s64-v6mr4060397oib.332.1527785363800; Thu, 31 May 2018 09:49:23 -0700 (PDT) Received: from nuclearis2_1.gtech (c-98-201-114-184.hsd1.tx.comcast.net. [98.201.114.184]) by smtp.gmail.com with ESMTPSA id d92-v6sm8210952otb.32.2018.05.31.09.49.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 09:49:22 -0700 (PDT) Subject: Re: [PATCH] PCI: Check for PCIe downtraining conditions To: Sinan Kaya , Alex_Gagniuc@Dellteam.com, bhelgaas@google.com Cc: Austin.Bolen@dell.com, Shyam.Iyer@dell.com, keith.busch@intel.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org References: <20180531150535.9684-1-mr.nuke.me@gmail.com> <28004506-24f0-6d10-2d1e-074e0483d2f9@codeaurora.org> <4e0611c872054e768daa96b302651db3@ausx13mps321.AMER.DELL.COM> <3b8a895b-3080-7ddb-cbfd-5aa972e9bf65@gmail.com> <35563ce3-e235-096c-4b9b-5f3664d67d0f@codeaurora.org> <093b2789-39a1-db9e-5783-b0488b3c9ccd@gmail.com> <32d58835-2f35-0b80-38d0-b9ff603619dd@codeaurora.org> From: "Alex G." Message-ID: <54071f83-5d0d-04a0-d448-0c99ec0ffc4f@gmail.com> Date: Thu, 31 May 2018 11:49:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <32d58835-2f35-0b80-38d0-b9ff603619dd@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/31/2018 11:13 AM, Sinan Kaya wrote: > On 5/31/2018 12:01 PM, Alex G. wrote: >>> PCI: Add pcie_print_link_status() to log link speed and whether it's limited >> This one, I have, but it's not what I need. This looks at the available >> bandwidth from root port to endpoint, whereas I'm only interested in >> downtraining between endpoint and upstream port. > > I see what you are saying. > > With a little bit of effort, you can reuse the same code. > > Here is an attempt. > > You can probably extend pcie_bandwidth_available() to put an optional parent bridge > device for your own use case and terminate the loop around here. > > https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/pci/pci.c#L5182 > > Then, you can use the existing code to achieve what you are looking for via > pcie_print_link_status() by adding an optional parent parameter. > > bw_cap = pcie_bandwidth_capable(dev, &speed_cap, &width_cap); > bw_avail = pcie_bandwidth_available(dev, &limiting_dev, &speed, &width, *parent*); That's confusing. I'd expect _capable() and _available() to be symmetrical. They either both look at one link only, or both go down to the root port. Though it seems _capable() is link-local, and _available() is down to root port. > > If parent parameter is NULL, code can walk all the way to root as it is doing today. > If it is not, then will terminate the loop on the first iteration. >