On 3/22/2018 8:46 AM, Benjamin Herrenschmidt wrote: > On Thu, 2018-03-22 at 07:25 -0400, okaya@xxxxxxxxxxxxxx wrote: >>>>> >>> >>> That tells me that there is no guarantee by spec that we'll get >>> ffff's, instead we might get HW stalls, or other really nasty >>> effects when probing a register other than 0 (VID/DID) for CRS. >> >> AFAIK, spec also mentions that sw needs to observe 0xffffffff for all >> other registers other than vendor id during CRS period. > > This isnt what's in the 3.1a spec at least ... section 2.3.2 explains > the specified behaviour which is, for any register other than 0 > (VID/DID), to re-issue the request... > I don't have any hard preference on this. Bjorn wanted code to work for systems with and without CRS capability. That was the reason we stayed away from 0xffff0001. CRS just gives you HW implementation defined retries for non vendor-id register like you mentioned. If device does not reply in this period of polling time, you should get all 1s eventually back. All 1s is the spec way of saying device doesn't exist for config transactions. Some HW can poll indefinitely or other HW can return immediately. If CRS visibility is supported & enabled, polling indefinitely and hogging the CPU wouldn't be the best HW implementation. > Now, it can have a timeout, and thus might be completed as a failed > transaction after a while, but it's a sub-optimal way (ie, we'll end up > hogging the CPU on loads) and it's not 100% clear that a failed > transaction returns as all 1's (it should but ...). > > I can make sure it happens the way the code expects on powerpc, I'm not > too worried about that, but I think for such a generic function, it > would make sense to stick a bit closer to the spec. > Cheers, > Ben. > > -- 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.
