[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMSpPPenUvGVwTf9ZKJoK08fm6L-0c=anPUaRRZdkHBzhGO-dA@mail.gmail.com>
Date: Wed, 23 Aug 2017 21:32:06 +0530
From: Oza Oza <oza.oza@...adcom.com>
To: Sinan Kaya <okaya@...eaurora.org>
Cc: Bjorn Helgaas <helgaas@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
Jon Mason <jonmason@...adcom.com>,
BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
Andy Gospodarek <gospo@...adcom.com>,
linux-pci <linux-pci@...r.kernel.org>,
linux-kernel@...r.kernel.org,
Oza Pawandeep <oza.pawandeep@...il.com>,
Timur Tabi <timur@...eaurora.org>,
Alex Williamson <alex.williamson@...hat.com>
Subject: Re: [PATCH v7 1/2] PCI: iproc: Retry request when CRS returned from EP
On Wed, Aug 23, 2017 at 9:22 PM, Sinan Kaya <okaya@...eaurora.org> wrote:
> Hi Oza,
>
>> In working Enumuration case I get following:
>> [ 9.125976] pci 0000:00:00.0: bridge configuration invalid ([bus
>> 00-00]), re-configuring
>> [ 9.134267] where=0x0 val=0xffff0001
>> [ 9.146946] where=0x0 val=0xffff0001
>> [ 9.158943] where=0x0 val=0xffff0001
>> [ 9.170945] where=0x0 val=0xffff0001
>> [ 9.186945] where=0x0 val=0xffff0001
>> [ 9.210944] where=0x0 val=0xffff0001
>> [ 9.250943] where=0x0 val=0xffff0001
>> [ 9.322942] where=0x0 val=0xffff0001
>> [ 9.458943] where=0x0 val=0xffff0001
>> [ 9.726942] where=0x0 val=0x9538086 >> actual vendor and device id.
>>
>> so I think I have to retry in RC driver, so the old code still holds good.
>> except that I have to do factoring out
> You need to return 0xFFFF0001 for vendor ID register and return 0xFFFFFFFF for
> other registers like COMMAND register during the CRS period.
>
Hi Sinan,
Although I don't disagree entirely with your suggestion, but at the same time,
I am not sure, in RC driver I should have special case for vendor id
and device id, and have another case for rest of the configuration
access.
my thinking is, the RC driver should closely reflect the PCI iproc HW
behaviour (in a generic way, rather than handling vendor/device id
case separately)
Bjorn, please comment as how do you see it being handled.
Regards,
Oza.
>>
>> please let me know If I missed anything, or you want me to try anything else.
>
> Sinan
Powered by blists - more mailing lists