Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1170508pxk; Fri, 18 Sep 2020 05:49:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXf6OhEVll9kEt4F7G4xDCRhmHdtwWBXMmOg4dWQuVjy35T31UMtsSVy8Mxe65ZDhx25Ll X-Received: by 2002:a50:ed94:: with SMTP id h20mr38305301edr.184.1600433367894; Fri, 18 Sep 2020 05:49:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600433367; cv=none; d=google.com; s=arc-20160816; b=x4j3Ug1JdaSzTdYJ+fgWIXK3hb/OoE2yMrF21Za5ou+ghp5RPlzRgQDe2gAcOx+Gcq lWYFNcobcyydJ2aqcTTnYXOsippnZXOnrjMW1YlBzxI0dn5JqL91wG1GWMw3QfjjTD4q iEEjDtXXmtfG1h5mZZ8hGA7jMsvkQGHi0/wdXCDjRtmbZrc6CxA971rUHo+U3hIF+VOu DSA7yelbeqg2Dyxy+iI2kjGzXwm4xOZUuLdXiSdU8Iy0NCgYEuSdFd1ZwcOqzuDJZdeF 5KmlsJAe2FS/FVRFYlqM2gKcjFlwR2dn4PZSXWlU4FOEkNas8PtzWTgqmWJUrIVZoc0W nmMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=+BtL83RCLK6CDdHB+5raQI1siVXldYx/1bwgzUQVZtU=; b=bW5VPniAVwP3qDReM8gxuSjsGfLGkzA9MBwFlvJspEWDCI5QbRHClTmusQYw0cwS/h lr3uSMLbOLvVkr/QS++NBWIdq16D3OawthSxkCRK6N/ZuQFxI8jG49g/ONTKrZnIdxR3 u/jqE77JuitW10qyT5+si/NHkMMjMdUTIvk2ffT3tJUtSKK2R5fiOBGU26n3Q3VfvHMx s7KZSAFYfO07mD3e45afz5qCc1zc63rurhFBFpjadzoaKQWqSVVceIQvwpYBEjd25oZa I5czR8fJOq3+Nsrcz7E/pMhxkT99PGCZKpD34aogKbAAoVGDqoQXRb4Z5Hwd0MHBWD2g LzVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=zQlHWti5; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cb11si2028122edb.361.2020.09.18.05.49.04; Fri, 18 Sep 2020 05:49:27 -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; dkim=pass header.i=@kernel.org header.s=default header.b=zQlHWti5; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727026AbgIRMrO (ORCPT + 99 others); Fri, 18 Sep 2020 08:47:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:34888 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726461AbgIRMrN (ORCPT ); Fri, 18 Sep 2020 08:47:13 -0400 Received: from localhost (52.sub-72-107-123.myvzw.com [72.107.123.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 505E623600; Fri, 18 Sep 2020 12:47:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600433232; bh=T2S8dkpDTSwWKVpBKiH0LOb9Www4+IJXitnPi6pfvQI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=zQlHWti5x0Rtt729xb+cWuja0eA8sW7ZIkA9eO1fi/XzXq48oBvSuSif1C19KU1pw P6YtwpwN8n2MaoEqIdDLIqF2P1KhL+QXPMqAQKlaxYODQLnnrhEJrrCxyYBLs7s52h oNg/fKAS4lDc5rTrWZ2BJKczDaPKFX/h2wF+qFJI= Date: Fri, 18 Sep 2020 07:47:10 -0500 From: Bjorn Helgaas To: "Z.q. Hou" Cc: Rob Herring , "linux-kernel@vger.kernel.org" , PCI , Lorenzo Pieralisi , Bjorn Helgaas , Gustavo Pimentel , Michael Walle , Ard Biesheuvel Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops Message-ID: <20200918124710.GA1800067@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 18, 2020 at 11:02:07AM +0000, Z.q. Hou wrote: > But now the SError is exactly caused by the first access of the > non-existent function, I dug into the kernel enumeration code and > found it will fire a 4Byte CFG read transaction to read the Vendor > ID and Device ID together, so I suspect the root cause is access the > Device ID of a non-existent function triggers SError. > > So the alternative solution seems to correct the PCIe enumeration, I > will submit a patch to let the first access only read the Vendor ID. If it is incorrect for the first access to be a 32-bit read of both the Vendor and the Device ID, please cite the relevant section of the spec in your patch. I don't like to make changes to generic code to accommodate specific pieces of hardware because then we restrict future changes based on some device that will soon be obsolete and forgotten. I'm pretty sure the spec language about CRS handling is careful to talk about "reads that *include* Vendor ID", not just "reads of Vendor ID", so the implication is that it covers 32-bit reads as well as 16-bit reads. Bjorn