From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19B9AC433EF for ; Wed, 8 Sep 2021 12:22:22 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6CB896113D for ; Wed, 8 Sep 2021 12:22:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6CB896113D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 28CC583354; Wed, 8 Sep 2021 14:22:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="ZErjJB27"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 760D782C84; Wed, 8 Sep 2021 14:03:04 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 2184882BC4 for ; Wed, 8 Sep 2021 14:03:01 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=kabel@kernel.org Received: by mail.kernel.org (Postfix) with ESMTPSA id 70C7561131; Wed, 8 Sep 2021 12:02:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631102579; bh=aMcw7C3POQx0Cwlmu/eWFzPhECxAgEAR4E+ptJ4QwF4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZErjJB27JmOLwLvAzI/83DGx7pzrnAgYSNKGaWExteNebsGNC3xi1rZbsk8fv0+qn J8psOxa0T/AQKuDKkrflforFc0D9JnidfIrx1kI6Ft+EM2v8w+uoxSO9XWgbFmgUC1 s7KGgrJyP7mIHKSRQcuugKyQVVuPF6uqdnpImnsSMagjTFMPXAIKaoyYblvxd24OqK mVpVuuPnEfvfmTCOqgIKDUP4cs7o0s6wIMl2uLEOHJnmobhjrPeHeuEB9wMgNyLqi/ kS8+5pPSRgEW23//AOuM437o7oUkLSovNfi1VlidkXen8FIK5suksxA/S9dJHQMt09 BfUp3JY2ZmbSQ== Date: Wed, 8 Sep 2021 14:02:56 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Bin Meng Cc: Simon Glass , Stefan Roese , U-Boot Mailing List , Pali =?UTF-8?B?Um9ow6Fy?= Subject: Re: [PATCH u-boot] dm: pci: Fix handling of errors when scanning device Message-ID: <20210908140256.393aeb9a@dellmb> In-Reply-To: References: <20210907160708.31547-1-marek.behun@nic.cz> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 08 Sep 2021 14:22:00 +0200 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Wed, 8 Sep 2021 09:06:28 +0800 Bin Meng wrote: > On Wed, Sep 8, 2021 at 12:07 AM Marek Beh=C3=BAn > wrote: > > > > From: Pali Roh=C3=A1r > > > > Some PCIe controller's read_config() method support indicating error > > directly via return value, but some cannot distinguish all-ones (or > > all-zeros) read response from an error. > > > > The current code in pci_bind_bus_devices() interprets all-ones / > > all-zeros in PCI_VENDOR_ID register as "nothing connected", and > > continues the cycle, but an error returned via return value breaks > > the cycle. > > > > This is wrong for the PCIe controllers which return this error via > > return value. > > > > Handle all errors when reading PCI_VENDOR_ID the same way. > > > > This fixes enumeration of PCI devices for example when there is a > > PCI bridge connected behind another PCI bridge and not all ports are > > connected to a device, and the controller (for example Aardvark) > > translates the UR error (Unsupported Request) as -EOPNOTSUPP. > > > > Signed-off-by: Pali Roh=C3=A1r > > Signed-off-by: Marek Beh=C3=BAn > > --- > > drivers/pci/pci-uclass.c | 9 +-------- > > 1 file changed, 1 insertion(+), 8 deletions(-) > > =20 >=20 > Is it possible to update these PCI controller drivers to fill in > vendor id to all zeros when there is an errror? It is, but we think it is wrong. If the PCI controller supports reporting errors, they should be propagated. What we might want to change in those controller drivers, though, is error numbers, so that they are the same for each controller. For example Unsupported Request should be always translated to EOPNOTSUPP. Marek