Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp454168pxk; Thu, 1 Oct 2020 06:36:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/dIuPFz5MW/ywk3VTPWQ5y8W+NEoRQep9JWXmEADDBmE7GlOpDwDAaas2rpU8yW/yE7B3 X-Received: by 2002:a17:906:28c4:: with SMTP id p4mr8103350ejd.345.1601559390369; Thu, 01 Oct 2020 06:36:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601559390; cv=none; d=google.com; s=arc-20160816; b=OE4fNuzdor/SsE+5OUxqYPAuDiiG0AJrR36m0ZoKnoV4odTiu9FF/k9idjLsi6APvY 240yfq8Uo66cKTGD85XZX1yh8ONHCxD8CbFKqnGO2J0vsq9aKpw//F05I6KpAHUy5QOW P2BgJSE4EHoKw3pc4gkCyKpeCjVs7bSrJXEbRh+pRPzb6efWOfcy1maxjL5vx8xY3/Mr ES1RWf5laStKJBpyGx9RW2vHAn6+fzWsCTn1WW1kqCZpTgoIBh4PJ7VFxuhOzdEobUPo SVSO02trzTmLcUaV3gbT6ykDQMZdT9Krln4/LywJDYRA+0xwS8vHGNLMK+qFxmANfax8 8Bmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=8zovruMDRzF30alX1PETs26OJnbOMMxKkERomI+AH/k=; b=oLBewSet9YuA5dNgtkCiZVScHr8VGvdKSEJU2nXRhVs/A6f3GvDQMj8rFAO6Sbg0YL t3TQEcwNi/l2ZDek5kBTCl4bcaxC/JRsMD5sULUhG5aDxoj+ncceT4wwZ6pJwDeuHayi WgGwUbXs0VII6rcXMBc/r1QquiD/BwmVjYfO1GmnrBawRVGEleZoCoqCxO8/2bgcZJrU SCzA2CXtBGXgEcFBvUfZ4jvFyBbUg3hRbImOXwT9nUjEI84C8qxm2rIUuXe++0eBIcM4 AEWawN9lL+uW2tzUYLWlDQLuru5Ey0kRqu4K+qV02HlvrWnm/RGTzo8fQis6F5X16sWN zyjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=HKDjAPwN; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g3si3440085edq.113.2020.10.01.06.36.01; Thu, 01 Oct 2020 06:36:30 -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=@ti.com header.s=ti-com-17Q1 header.b=HKDjAPwN; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732230AbgJANcU (ORCPT + 99 others); Thu, 1 Oct 2020 09:32:20 -0400 Received: from fllv0015.ext.ti.com ([198.47.19.141]:49602 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731993AbgJANcT (ORCPT ); Thu, 1 Oct 2020 09:32:19 -0400 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 091DW9M1122907; Thu, 1 Oct 2020 08:32:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1601559129; bh=8zovruMDRzF30alX1PETs26OJnbOMMxKkERomI+AH/k=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=HKDjAPwN13aROT4VgymsouY0d1uXP3iTjHKWU+mBY2nkOSXn1bFOKwoYe8dlFTpq6 YuffONTlMEbxL2o19Rk1MAR8baAbd9cgx5glWUKBYwVPeZL65DhJtQhQU4vQGtKw1p 2ANjwGpYinjDLv8ndl7ut/jJJAcSHqEMIZX4P7Io= Received: from DLEE110.ent.ti.com (dlee110.ent.ti.com [157.170.170.21]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTP id 091DW9B0128460; Thu, 1 Oct 2020 08:32:09 -0500 Received: from DLEE104.ent.ti.com (157.170.170.34) by DLEE110.ent.ti.com (157.170.170.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Thu, 1 Oct 2020 08:32:08 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Thu, 1 Oct 2020 08:32:08 -0500 Received: from [10.250.232.108] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 091DW5Js093105; Thu, 1 Oct 2020 08:32:06 -0500 Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops To: Rob Herring CC: Gustavo Pimentel , "Z.q. Hou" , Lorenzo Pieralisi , "linux-kernel@vger.kernel.org" , PCI , Bjorn Helgaas , Michael Walle , Ard Biesheuvel References: <20200916054130.8685-1-Zhiqiang.Hou@nxp.com> <20200928093911.GB12010@e121166-lin.cambridge.arm.com> <9ac53f04-f2e8-c5f9-e1f7-e54270ec55a0@ti.com> From: Kishon Vijay Abraham I Message-ID: <67ac959f-561e-d1a0-2d89-9a85d5f92c72@ti.com> Date: Thu, 1 Oct 2020 19:02:04 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On 30/09/20 8:31 pm, Rob Herring wrote: > On Wed, Sep 30, 2020 at 8:22 AM Kishon Vijay Abraham I wrote: >> >> Hi, >> >> On 29/09/20 10:41 pm, Rob Herring wrote: >>> On Tue, Sep 29, 2020 at 10:24 AM Gustavo Pimentel >>> wrote: >>>> >>>> On Tue, Sep 29, 2020 at 5:5:41, Z.q. Hou wrote: >>>> >>>>> Hi Lorenzo, >>>>> >>>>> Thanks a lot for your comments! >>>>> >>>>>> -----Original Message----- >>>>>> From: Lorenzo Pieralisi >>>>>> Sent: 2020年9月28日 17:39 >>>>>> To: Z.q. Hou >>>>>> Cc: Rob Herring ; linux-kernel@vger.kernel.org; PCI >>>>>> ; 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 >>>>>> >>>>>> On Thu, Sep 24, 2020 at 04:24:47AM +0000, Z.q. Hou wrote: >>>>>>> Hi Rob, >>>>>>> >>>>>>> Thanks a lot for your comments! >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rob Herring >>>>>>>> Sent: 2020年9月18日 23:28 >>>>>>>> To: Z.q. Hou >>>>>>>> Cc: 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 >>>>>>>> >>>>>>>> On Fri, Sep 18, 2020 at 5:02 AM Z.q. Hou >>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Rob, >>>>>>>>> >>>>>>>>> Thanks a lot for your comments! >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rob Herring >>>>>>>>>> Sent: 2020年9月17日 4:29 >>>>>>>>>> To: Z.q. Hou >>>>>>>>>> Cc: 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 >>>>>>>>>> >>>>>>>>>> On Tue, Sep 15, 2020 at 11:49 PM Zhiqiang Hou >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> From: Hou Zhiqiang >>>>>>>>>>> >>>>>>>>>>> On NXP Layerscape platforms, it results in SError in the >>>>>>>>>>> enumeration of the PCIe controller, which is not connecting >>>>>>>>>>> with an Endpoint device. And it doesn't make sense to >>>>>>>>>>> enumerate the Endpoints when the PCIe link is down. So this >>>>>>>>>>> patch added the link up check to avoid to fire configuration >>>>>> transactions on link down bus. >>>>>>>>>> >>>>>>>>>> Michael reported the same issue as well. >>>>>>>>>> >>>>>>>>>> What happens if the link goes down between the check and the >>>>>> access? >>>>>>>>> >>>>>>>>> This patch cannot cover this case, and will get the SError. >>>>>>>>> But I think it makes sense to avoid firing transactions on link down bus. >>>>>>>> >>>>>>>> That's impossible to do without a race even in h/w. >>>>>>> >>>>>>> Agree. >>>>>>> >>>>>>>> >>>>>>>>>> It's a racy check. I'd like to find an alternative solution. >>>>>>>>>> It's even worse if Layerscape is used in ECAM mode. I looked at >>>>>>>>>> the EDK2 setup for layerscape[1] and it looks like root ports >>>>>>>>>> are just skipped if link >>>>>>>> is down. >>>>>>>>>> Maybe a link down just never happens once up, but if so, then we >>>>>>>>>> only need to check it once and fail probe. >>>>>>>>> >>>>>>>>> Many customers connect the FPGA Endpoint, which may establish PCIe >>>>>>>>> link after the PCIe enumeration and then rescan the PCIe bus, so I >>>>>>>>> think it should not exit the probe of root port even if there is >>>>>>>>> not link up >>>>>>>> during enumeration. >>>>>>>> >>>>>>>> That's a good reason. I want to unify the behavior here as it varies >>>>>>>> per platform currently and wasn't sure which way to go. >>>>>>>> >>>>>>>> >>>>>>>>>> I've dug into this a bit more and am curious about the >>>>>>>>>> PCIE_ABSERR register setting which is set to: >>>>>>>>>> >>>>>>>>>> #define PCIE_ABSERR_SETTING 0x9401 /* Forward error of >>>>>>>>>> non-posted request */ >>>>>>>>>> >>>>>>>>>> It seems to me this is not what we want at least for config >>>>>>>>>> accesses, but commit 84d897d6993 where this was added seems to >>>>>>>>>> say otherwise. Is it not possible to configure the response per access >>>>>> type? >>>>>>>>> >>>>>>>>> Thanks a lot for your investigation! >>>>>>>>> The story is like this: Some customers worry about these silent >>>>>>>>> error (DWC PCIe IP won't forward the error of outbound non-post >>>>>>>>> request by default), so we were pushed to enable the error >>>>>>>>> forwarding to AXI in the commit >>>>>>>>> 84d897d6993 as you saw. But it cannot differentiate the config >>>>>>>>> transactions from the MEM_rd, except the Vendor ID access, which >>>>>>>>> is controlled by a separate bit and it was set to not forward >>>>>>>>> error of access >>>>>>>> of Vendor ID. >>>>>>>>> So we think it's okay to enable the error forwarding, the SError >>>>>>>>> should not occur, because after the enumeration it won't access >>>>>>>>> the >>>>>>>> non-existent functions. >>>>>>>> >>>>>>>> We've rejected upstream support for platforms aborting on config >>>>>>>> accesses[1]. I think there's clear consensus that aborting is the >>>>>>>> wrong behavior. >>>>>>>> >>>>>>>> Do MEM_wr errors get forwarded? Seems like that would be enough. >>>>>>>> Also, wouldn't page faults catch most OOB accesses anyways? You need >>>>>>>> things page aligned anyways with an IOMMU and doing userspace access >>>>>>>> or guest assignment. >>>>>>> >>>>>>> Yes, errors of MEM_wr can be forwarded. >>>>>>> >>>>>>>> >>>>>>>> Here's another idea, how about only enabling forwarding errors if >>>>>>>> the link is up? If really would need to be configured any time the >>>>>>>> link state changes rather than just at probe. I'm not sure if you >>>>>>>> have a way to disable it on link down though. >>>>>>> >>>>>>> Dug deeper into this issue and found the setting of not forwarding >>>>>>> error of non-existent Vender ID access counts on the link partner: 1. >>>>>>> When there is a link partner (namely link up), it will return 0xffff >>>>>>> when read non-existent function Vendor ID and won't forward error to >>>>>>> AXI. 2. When no link partner (link down), it will forward the error >>>>>>> of reading non-existent function Vendor ID to AXI and result in >>>>>>> SError. >>>>>>> >>>>>>> I think this is a DWC PCIe IP specific issue but not get feedback from >>>>>>> design team. I'm thinking to disable this error forwarding just like >>>>>>> other platforms, since when these errors (UR, CA and CT) are detected, >>>>>>> AER driver can also report the error and try to recover. >>>>>> >>>>>> I take this as you shall send a patch to fix this issue shortly, is this correct ? >>>>> >>>>> The issue becomes complex: >>>>> I reviewed the DWC PCIe databook of verion 4.40a which is used on Layerscape platforms, and it said that " Your RC application should not generate CFG requests until it has confirmed that the link is up by sampling the smlh_link_up and rmlh_link_up outputs". >>>>> So, the link up checking should not be remove before each outbound CFG access. >>>>> Gustavo, can you share more details on the link up checking? Does it only exist in the 4.40a? >>>> >>>> Hi Zhiqiang, >>>> >>>> According to the information that I got from the IP team you are correct, >>>> the same requirement still exists on the newer IP versions. >>> >>> How is that possible in a race free way? >>> >>> Testing on meson and layerscape (with the forwarding of errors >>> disabled) shows a link check is not needed. But then dra7xx seems to >>> need one (or has some f/w setup). >> >> Yeah, I don't see any registers in the DRA7x PCIe wrapper for disabling >> error forwarding. > > It's a DWC port logic register AFAICT, but perhaps not present in all versions. Okay. I see there's a register PCIECTRL_PL_AXIS_SLV_ERR_RESP which has a reset value of 0. It has four bit-fields, RESET_TIMEOUT_ERR_MAP, NO_VID_ERR_MAP, DBI_ERR_MAP and SLAVE_ERR_MAP. I'm not seeing any difference in behavior if I set all these bits. Maybe it requires platform support too. I'll check this with our design team. Meanwhile would it be okay to add linkup check atleast for DRA7X so that we could have it booting in linux-next? Thanks Kishon