Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3983867imm; Mon, 6 Aug 2018 14:22:36 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc6Jgvxn4RpB6h8SqL2Qn4J+8IJORLNefimJ/sEeO3CrfRNcnnBS+cEYq+WkE8+U18UeSpR X-Received: by 2002:a63:ec43:: with SMTP id r3-v6mr15588082pgj.295.1533590555988; Mon, 06 Aug 2018 14:22:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533590555; cv=none; d=google.com; s=arc-20160816; b=dS/SAF37Cn+uOr1hn/W0JNj1uFyqNXQu9t35t76rf4NugFE0Pc3jlC0dT01cRA52HI JzzgJz3Eejp22sqA7vvMjzUJKHRiaMvLlcvFSx4gaBREq97ZkyfOca/QZqMEky3/LVOw 5ES392NmJ9fUzbuh0XszspsIG5rM35sJWxKY6uHqoBzrjQ13jzGziQB8BAC9vOM/ADV8 h+VYZVsSsueVIhOsv5jnsNvRv7xORtVK0lzpSNp91VzJ+3hnhGDULrQuYSQMo1RhXeSX AZpaBsmxULbIYiq2WgVwsjO3LKPSNeWhSAhwz9FHSlRbpEmXW0fSrdoY2cWvbbmLI8vx PgzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=SOg3RV8SRZCbnagjoEakArIwehGS+D2YXWWhBkXef64=; b=g1rYUguhndPCxRkNDIBxq9IhROJFXQ20fiLh2JC/isvslQ6Wadee1pgnnX05l3jT/P 5myuHGxRd/2S1PjTwnq/IyjqO3WALRGO/n8DBcSdxbahqhBO+Ol0ZcpPNixaRaHrDFJJ x3XOMQYf1CBdwrkWy6pZhguXo3pHxbJBAnvtkLXisz11+HjwfiOrPxVNou+GVh68gifZ SLuijJayN+X1R9yiMwM4JaE1a54Q5WcGDGgsKgeEJxnmf01Fp4IsvWhZwUQpGDUnmuWh 2hdi0Qve/MPAns1UV7quM3MOdL3ViE6X3r0bmlQhWWPlZx7ajJsMvCfvq1gIob40bC1+ l/yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=a0HsPQUz; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o126-v6si580617pfg.102.2018.08.06.14.22.21; Mon, 06 Aug 2018 14:22:35 -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=@google.com header.s=20161025 header.b=a0HsPQUz; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733286AbeHFV5T (ORCPT + 99 others); Mon, 6 Aug 2018 17:57:19 -0400 Received: from mail-yw1-f65.google.com ([209.85.161.65]:36989 "EHLO mail-yw1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727585AbeHFV5S (ORCPT ); Mon, 6 Aug 2018 17:57:18 -0400 Received: by mail-yw1-f65.google.com with SMTP id w76-v6so4049922ywg.4 for ; Mon, 06 Aug 2018 12:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SOg3RV8SRZCbnagjoEakArIwehGS+D2YXWWhBkXef64=; b=a0HsPQUzp+dDL+Kj6jG6XC0T5+Egcjof4Suj+875d0AH14F+ZJpY5a0ulCjjp6nLPt N7CgOEc5yJnsoP9mQVdNJeEDo4+TevLIGtw0o40O66tvj3YZRpoYukv2vrPjn1mKJ24n UMzvskfUxv7AiwwuSs9eNu8st67QTiW3sH3OCCmTKNPk9i7ZG9ypPaXiL9Q9Yd8HZcIb nqvTRYNxHxFyxHjaguRyxUgkkWVMIvyUvVPT7bX/HuHDVfqGJse5QqM2BnFinhwc7Xtd w1lt9wJ7re/i9e09QVD86/2yU1GB9M68lpLBdwRF+R3LcPMeXi+GxwXTfz+9pQqOOLM1 MY+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SOg3RV8SRZCbnagjoEakArIwehGS+D2YXWWhBkXef64=; b=gDMYTGNn5TgexxUEvADDOHpt7w1CGT5xRp3S8v/qC9n595Go1yWy9f+L1hwMHt42Vp ljv9i5AdLcWyzqh0lk3eKXWBHwfjFjDW1WuW6QiIVZmqgmiGYSwjK+W/r2EdS+xOoEY/ SOlD0UXM+VMguKfdsPKmSEOcAYzg0aSu1CEv5fXxp+AsxuXInJ5zEOmMz5IJjgRiy3ZG SMKWK6SZFTeo0ck0zsqrBDfI+2UYvC9hckJaUXyTBkK3dPMFF1TRziXXFtPEIllqdJv/ CUfD84AiqEMC9JYupBoR67zlvoTfjDgyRuXjrj4kEMxr2sZbgbdepfmuN5k1Wc42tTXb D3xw== X-Gm-Message-State: AOUpUlGWOf5N7gdPyTM5vjPieIhA7EWr6S8WKboZlaz6imsim9Sz1LOw lHrM4jUEDXPGgShH5oFDJrJ2hL5Zwbw5e61Q9d5I X-Received: by 2002:a0d:ea95:: with SMTP id t143-v6mr8426786ywe.383.1533584800967; Mon, 06 Aug 2018 12:46:40 -0700 (PDT) MIME-Version: 1.0 References: <20180718215359.GG128988@bhelgaas-glaptop.roam.corp.google.com> <20180723200339.23943-1-mr.nuke.me@gmail.com> <20180723140143.1a46902f@cakuba.netronome.com> <1b914780-e342-6aee-ffb2-ef81ac3ddd29@gmail.com> <7424c5ba-ae44-3d8d-9dd5-360e17b6e3b9@mellanox.com> In-Reply-To: From: Bjorn Helgaas Date: Mon, 6 Aug 2018 14:46:28 -0500 Message-ID: Subject: Re: [PATCH v5] PCI: Check for PCIe downtraining conditions To: Alex_Gagniuc@dellteam.com Cc: Tal Gilboa , mr.nuke.me@gmail.com, jakub.kicinski@netronome.com, linux-pci@vger.kernel.org, Keith Busch , Austin.Bolen@dell.com, Shyam.Iyer@dell.com, "Kirsher, Jeffrey T" , ariel.elior@cavium.com, michael.chan@broadcom.com, ganeshgr@chelsio.com, tariqt@mellanox.com, Dave Airlie , Alex Deucher , "Marciniszyn, Mike" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 6, 2018 at 1:39 PM wrote: > > On 08/05/2018 02:06 AM, Tal Gilboa wrote: > > On 7/31/2018 6:10 PM, Alex G. wrote: > >> On 07/31/2018 01:40 AM, Tal Gilboa wrote: > >> [snip] > >>>>>> @@ -2240,6 +2258,9 @@ static void pci_init_capabilities(struct > >>>>>> pci_dev *dev) > >>>>>> /* Advanced Error Reporting */ > >>>>>> pci_aer_init(dev); > >>>>>> + /* Check link and detect downtrain errors */ > >>>>>> + pcie_check_upstream_link(dev); > >>>> > >>>> This is called for every PCIe device right? Won't there be a > >>>> duplicated print in case a device loads with lower PCIe bandwidth > >>>> than needed? > >>> > >>> Alex, can you comment on this please? > >> > >> Of course I can. > >> > >> There's one print at probe() time, which happens if bandwidth < max. I > >> would think that's fine. There is a way to duplicate it, and that is if > >> the driver also calls print_link_status(). A few driver maintainers who > >> call it have indicated they'd be fine with removing it from the driver, > >> and leaving it in the core PCI. > > > > We would be fine with that as well. Please include the removal in your > > patches. > > What's the proper procedure? Do I wait for confirmation from Bjorn > before knocking on maintainer's doors, or do I William Wallace into > their trees and demand they merge the removal (pending Bjorn's approval > on the other side) ? Post a v4 series that does the PCI core stuff as well as removing the driver code. Bjorn