Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1704016

Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP

From Oza Oza <oza.oza@broadcom.com>
Newsgroups linux.kernel
Subject Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP
Date 2017-08-04 16:20 +0200
Message-ID <uaLCi-867-9@gated-at.bofh.it> (permalink)
References (3 earlier) <uajG2-5ML-27@gated-at.bofh.it> <uatvH-3WM-9@gated-at.bofh.it> <uaDOq-2Wc-7@gated-at.bofh.it> <uaE7M-3ja-3@gated-at.bofh.it> <uaKPU-7wS-33@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Aug 4, 2017 at 6:57 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Aug 04, 2017 at 11:40:46AM +0530, Oza Oza wrote:
>> On Fri, Aug 4, 2017 at 11:29 AM, Oza Oza <oza.oza@broadcom.com> wrote:
>> > On Fri, Aug 4, 2017 at 12:27 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> >> On Thu, Aug 03, 2017 at 01:50:29PM +0530, Oza Oza wrote:
>> >>> On Thu, Aug 3, 2017 at 2:34 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> >>> > On Thu, Jul 06, 2017 at 08:39:41AM +0530, Oza Pawandeep wrote:
> ...
>
>> >>> > What about CRS status for a config *write*?  There's nothing here to
>> >>> > reissue those.
>> >>>
>> >>> No, we do not need there, because read will always be issued first
>> >>> before any write.
>> >>> so we do not need to implement write.
>> >>
>> >> How so?  As far as I know, there's nothing in the spec that requires
>> >> the first config access to a device to be a read, and there are
>> >> reasons why we might want to do a write first:
>> >> http://lkml.kernel.org/r/5952D144.8060609@oracle.com
>> >>
>> >
>> > I understand your point here. my thinking was during enumeration
>> > process first read will always be issued
>> > such as vendor/device id.
>> > I will extend this implementation for write.
>>
>> I am sorry, but I just released that, it is not possible to implement
>> retry for write.
>> the reason is:
>>
>> we have indirect way of accessing configuration space access.
>> for e.g.
>> for config write:
>>
>> A) write to to addr register.
>> B) write to data register
>>
>> now above those 2 registers are implemented by host bridge (not in
>> PCIe core IP).
>> there is no way of knowing for software, if write has to be retried.
>>
>> e.g. I can not read data register (step B) to check if write was successful.
>> I have double checked this with internal ASIC team here.
>
> The bottom line is that you're saying this hardware cannot correctly
> support CRS.  Maybe the workaround you're proposing will work in many
> cases, but we need to acknowledge in the code and changelog that there
> are issues we might trip over.

yes this is precisely right.

1) I will have to add notes in the code as you are suggesting.
2) I will add documentation notes in the Change-log.

But even going forward, we will still have one more separate register
in host bridge,
which will be dedicated to CRS. but again to a very limited extent.
because CRS software visibility bit will not have any effect, (e.g. HW
is not going to consider it).

Regards,
Oza.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from  EP Bjorn Helgaas <helgaas@kernel.org> - 2017-08-02 23:10 +0200
  Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP Oza Oza <oza.oza@broadcom.com> - 2017-08-03 10:30 +0200
    Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from  EP Bjorn Helgaas <helgaas@kernel.org> - 2017-08-03 21:00 +0200
      Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP Oza Oza <oza.oza@broadcom.com> - 2017-08-04 08:00 +0200
        Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP Oza Oza <oza.oza@broadcom.com> - 2017-08-04 08:20 +0200
          Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from  EP Bjorn Helgaas <helgaas@kernel.org> - 2017-08-04 15:30 +0200
            Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP Oza Oza <oza.oza@broadcom.com> - 2017-08-04 16:20 +0200
              Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from  EP Bjorn Helgaas <helgaas@kernel.org> - 2017-08-04 16:40 +0200
        Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from  EP Bjorn Helgaas <helgaas@kernel.org> - 2017-08-04 15:40 +0200
          Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP Oza Oza <oza.oza@broadcom.com> - 2017-08-04 16:20 +0200
          Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from  EP Bjorn Helgaas <helgaas@kernel.org> - 2017-08-04 16:40 +0200
          Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP Oza Oza <oza.oza@broadcom.com> - 2017-08-04 16:40 +0200

csiph-web