Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753543AbdFMRAh (ORCPT ); Tue, 13 Jun 2017 13:00:37 -0400 Received: from mail-vk0-f49.google.com ([209.85.213.49]:36218 "EHLO mail-vk0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752846AbdFMRAf (ORCPT ); Tue, 13 Jun 2017 13:00:35 -0400 MIME-Version: 1.0 In-Reply-To: <20170612214848.GC28578@bhelgaas-glaptop.roam.corp.google.com> References: <20170609231617.20243-1-yinghai@kernel.org> <20170612214848.GC28578@bhelgaas-glaptop.roam.corp.google.com> From: Yinghai Lu Date: Tue, 13 Jun 2017 10:00:33 -0700 X-Google-Sender-Auth: HKAlpNOpeQ-3BmzvDdXR83avif0 Message-ID: Subject: Re: [PATCH v3] PCI: Workaround wrong flags completions for IDT switch To: Bjorn Helgaas Cc: Bjorn Helgaas , "linux-pci@vger.kernel.org" , Linux Kernel Mailing List , James Puthukattukaran Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2364 Lines: 53 On Mon, Jun 12, 2017 at 2:48 PM, Bjorn Helgaas wrote: > On Fri, Jun 09, 2017 at 04:16:17PM -0700, Yinghai Lu wrote: >> From: James Puthukattukaran >> >> The IDT switch incorrectly flags an ACS source violation on a read config >> request to an end point device on the completion (IDT 89H32H8G3-YC, >> errata #36) even though the PCI Express spec states that completions are >> never affected by ACS source violation (PCI Spec 3.1, Section 6.12.1.1). > > Can you include a URL where this erratum is published? If not, can > you include the actual erratum text here? Ok. > > Have you considered ways to make this patch apply only to the affected > IDT switches? Currently it applies to *all* devices. But we need to apply that workaround before we know vendorid/deviceid under that root port or downstream port. > > The purpose of the pci_bus_read_dev_vendor_id() path is to support the > Configuration Request Retry Status feature (see PCIe r3.1, sec 2.3.2), > which works by special handling of config reads of the Vendor ID after > a reset. Normally, that Vendor ID read would be the first access to > a device when we enumerate it. > > This patch adds config reads and writes of the ACS capability *before* > the Vendor ID read. At that point we don't even know whether the > device exists. If it doesn't exist, pci_find_ext_capability() would > read 0xffffffff data, and it probably fails reasonably gracefully. > > But if the device *does* exist, I think this patch breaks the CRS > Software Visibility feature. Without this patch, we try to read > Vendor ID, and the device may return a CRS Completion Status. If CRS > visibility is enabled, the root complex may complete the request by > returning 0x0001 for the Vendor ID, in which case we sleep and try > again later. > > With this patch, we first try to read the ACS capability. If the > device returns a CRS Completion Status, the root complex is required > to reissue the config request. This is the required behavior > regardless of whether CRS Software Visibility is enabled, so I think > this effectively disables that feature. The workaround (acs reading etc) is applied to root port or downstream port. and pci_bus_read_dev_vendor_id() is for reading vendorid of device under that root port or downstream port. Thanks Yinghai