Re: [PATCH v3 2/2] PCI: pciehp: Clear the optional capabilities in DEVCTL2 on a hot-plug

[Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>]

On 6/28/2023 6:25 AM, Lukas Wunner wrote:
> On Tue, Jun 27, 2023 at 10:38:54AM -0700, Smita Koralahalli wrote:
>> Okay, I see there are no objections except for Bjorn/Jay's comments on
>>
>> "But there could be devices where AtomicOps are nominally supported but
>> untested or broken.."
>>
>> Would this be an issue?
> 
> I think you said that BIOS enables AtomicOps on certain AMD machines?
> Or did that observation only apply to 10 Bit tags?

Yes, that observation right now applies only to 10 bit tags.

> 
> If BIOS does enable AtomicOps, it would be interesting to know which
> logic BIOS follows, i.e. how does it determine whether to set
> AtomicOp Requester Enable on Endpoints?

I agree this is a very good thing to know. I have followed up with the 
BIOS team to get some pointers on this. I will get back to you soon.

> 
> It would also be interesting to know how far that BIOS has proliferated,
> i.e. how much experience with various Endpoint devices exists in the
> real world.  If it turns out that BIOS has enabled the feature for
> years on a wide range of Endpoints without any issues, I think
> that would render concerns mute that enabling it in the kernel
> might cause regressions.
> 
> I don't know why the spec says that "discovery of AtomicOp Requester
> capabilities is outside the scope of this specification".  I imagine
> it would be possible to set AtomicOp Requester Enable, then read it
> to determine whether the bit is now indeed 1 or hard-wired to 0.
> In the latter case, AtomicOp Requester capabilities can be assumed
> to be absent.  So that would be a way to make do without any other
> specific discovery of AtomicOp Requester capabilities.
> 
> Thanks,
> 
> Lukas