From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753260AbdHWDV3 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 22 Aug 2017 23:21:29 -0400
Received: from smtp.codeaurora.org ([198.145.29.96]:55450 "EHLO
        smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753057AbdHWDV1 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 22 Aug 2017 23:21:27 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 5CC1D603D2
Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org
Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org
Subject: Re: [PATCH V10 2/3] PCI: handle CRS returned by device after FLR
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, timur@codeaurora.org,
        alex.williamson@redhat.com, linux-arm-msm@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        Bjorn Helgaas <bhelgaas@google.com>, linux-kernel@vger.kernel.org
References: <1502470596-4112-1-git-send-email-okaya@codeaurora.org>
 <1502470596-4112-2-git-send-email-okaya@codeaurora.org>
 <20170818210134.GO28977@bhelgaas-glaptop.roam.corp.google.com>
 <4da26c10-3426-e752-4a59-25bb59cde8cd@codeaurora.org>
 <20170821180030.GB28977@bhelgaas-glaptop.roam.corp.google.com>
From: Sinan Kaya <okaya@codeaurora.org>
Message-ID: <48497e49-21c2-9289-f546-2b0ef938beb0@codeaurora.org>
Date: Tue, 22 Aug 2017 23:21:24 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170821180030.GB28977@bhelgaas-glaptop.roam.corp.google.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 8/21/2017 2:00 PM, Bjorn Helgaas wrote:
> On Mon, Aug 21, 2017 at 09:44:09AM -0400, Sinan Kaya wrote:
>> Hi Bjorn,
>>
>> On 8/18/2017 5:01 PM, Bjorn Helgaas wrote:

> 
> It would still be interesting to see the lspci output.  Likely <MAbort
> in the upstream bridge will be set even before the FLR because of
> aborts during enumeration.  The PCI core should probably clear that
> after enumeration.  I expect that if you manually clear it with
> setpci, do the lspci, do the FLR, do another lspci, you will probably
> see <MAbort being set by this pci_flr_wait() loop.  We might want to
> consider clearing it here as well.


     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 345
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 00002000-00002fff
        Memory behind bridge: 00100000-002fffff
        Prefetchable memory behind bridge: 0000090400000000-00000904001fffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-

FLR reset here with CRS to the NVMe drive.
	
     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 345
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 00002000-00002fff
        Memory behind bridge: 00100000-002fffff
        Prefetchable memory behind bridge: 0000090400000000-00000904001fffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	
I don't see <MAbort getting set. 




-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.