Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp5738801pxb; Mon, 28 Mar 2022 17:03:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxBreW094MO6e4UtHUTaaWSpKS6TqRws4vm9zbOjKY1wKnBefGR9ux9IwyeDdywPOdKnvhZ X-Received: by 2002:a65:4649:0:b0:385:fb06:c6c0 with SMTP id k9-20020a654649000000b00385fb06c6c0mr11605047pgr.569.1648512190845; Mon, 28 Mar 2022 17:03:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648512190; cv=none; d=google.com; s=arc-20160816; b=n+GOzulftpSS1YQEHax71zbXTqR0QVa/pzFZt4t12q96CFdVa5tdB0iZFCVbI0Kz6R Ur4yARPN2BDUi7TEBxIpFh3p5V7KLMi/DKUsY19HZ5KdFAXVCkRdc2fta+zX9tNMcmzq lEyXuLRDY7WNvT7w9hUzUjLgVzGkktrE2B1UCFQDF3y0qIUxNA2J0XLIcbTlcSPdNtlT U1JbLySsdrppo2DOojTAA54iLJ2sARF8xEzfm6d0HU7POpIhdVspNlaKcKADXhQfk5GU R7rfiP/RjKPnJi1Zfkjk7jfpj/3UX+KxfXIf5x0tfTAd+Ee9HqAGq0752s+Ow9ASX8a4 QAuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=TAxxCoUclhBV+W3CubdMnWvJohL/w5ZoRYu+B3/yHU0=; b=lkPU7aiUr7XN6bSVrmjW4fMKf7V5kQP92+mpZVxmkgF50Pjws/jF9Vv6WIm98PGMoT 2JwcA2Zc8QlSSl5gr7APuPtqbOG36Kg+Drd4Y6lT0Z4pnWaKneEGH1IPBF3Glgo85+uk hv7wWQMr/lPc8sYnUkEOc8Zk61XEFSkpQh35RJ6L1IUZz+TGe4tm3Oap9ohYYHwS4t7H 16PDOeae70mEACfBk2OWQYbiWyzV0lzJXdYffbi9lb0Vop2Yq3YB425guCV4qEv9Ilnd RduYUyKCdhJ2ItyuyVkG4OxJRsT0tWUP+mxZz/neP1NyIrnIl99EPQ7pY6pUGjRifn0u NwfA== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id k15-20020a17090a514f00b001c68931879bsi1021410pjm.135.2022.03.28.17.02.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 17:03:10 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 059B250E3C; Mon, 28 Mar 2022 16:32:14 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230472AbiC1Xds (ORCPT + 99 others); Mon, 28 Mar 2022 19:33:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230396AbiC1Xdq (ORCPT ); Mon, 28 Mar 2022 19:33:46 -0400 Received: from relay5.hostedemail.com (relay5.hostedemail.com [64.99.140.40]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 795984BFD6; Mon, 28 Mar 2022 16:32:04 -0700 (PDT) Received: from omf18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 3A451120857; Mon, 28 Mar 2022 23:32:02 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf18.hostedemail.com (Postfix) with ESMTPA id 03F042E; Mon, 28 Mar 2022 23:31:53 +0000 (UTC) Message-ID: <8569d431ce4e1d64ae271f0498c7a0395d2c5c7e.camel@perches.com> Subject: Re: [PATCH 03/16] PCI: dwc: Add more verbose link-up message From: Joe Perches To: Serge Semin , Jingoo Han , Gustavo Pimentel , Bjorn Helgaas , Lorenzo Pieralisi , Rob Herring , Krzysztof =?UTF-8?Q?Wilczy=C5=84ski?= Cc: Serge Semin , Alexey Malahov , Pavel Parkhomenko , Frank Li , Manivannan Sadhasivam , Rob Herring , linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 28 Mar 2022 16:31:53 -0700 In-Reply-To: <20220324013734.18234-4-Sergey.Semin@baikalelectronics.ru> References: <20220324013734.18234-1-Sergey.Semin@baikalelectronics.ru> <20220324013734.18234-4-Sergey.Semin@baikalelectronics.ru> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.40.4-1ubuntu2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspamout05 X-Rspamd-Queue-Id: 03F042E X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Stat-Signature: meuo49tiime8xmtnwejfrcwtzrcjaoci X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX181O1cQlVu9KyimR2kDvRtMJRaMI+j7axg= X-HE-Tag: 1648510313-438953 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2022-03-24 at 04:37 +0300, Serge Semin wrote: > Printing just "link up" isn't that much informative especially when it > comes to working with the PCI Express bus. Even if the link is up, due to > multiple reasons the bus performance can degrade to slower speeds or to > narrower width than both Root Port and its partner is capable of. In that > case it would be handy to know the link specifications as early as > possible. So let's add a more verbose message to the busy-wait link-state > method, which will contain the link speed generation and the PCIe bus > width in case if the link up state is discovered. Otherwise an error will > be printed to the system log. > > Signed-off-by: Serge Semin > --- > drivers/pci/controller/dwc/pcie-designware.c | 22 +++++++++++++++----- > 1 file changed, 17 insertions(+), 5 deletions(-) > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c [] > @@ -528,14 +528,26 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci) > > /* Check if the link is up or not */ > for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) { > - if (dw_pcie_link_up(pci)) { > - dev_info(pci->dev, "Link up\n"); > - return 0; > - } > + if (dw_pcie_link_up(pci)) > + break; > + > usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX); > } > > - dev_info(pci->dev, "Phy link never came up\n"); > + if (retries < LINK_WAIT_MAX_RETRIES) { > + u32 offset, val; > + > + offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); > + val = dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKSTA); > + > + dev_info(pci->dev, "PCIe Gen.%u x%u link up\n", > + FIELD_GET(PCI_EXP_LNKSTA_CLS, val), > + FIELD_GET(PCI_EXP_LNKSTA_NLW, val)); > + > + return 0; > + } > + > + dev_err(pci->dev, "Phy link never came up\n"); > > return -ETIMEDOUT; > } IMO: it's generally bette to test the error condition and unindent the typical return. if (retries >= LINK_WAIT_MAX_RETRIES) { dev_err(pci->dev, "Phy link never came up\n"); return -ETIMEDOUT; } offset = ... val = ... dev_info(...) return 0; }