Messages in this thread | | | Date | Fri, 30 Jun 2023 23:29:52 -0700 | Subject | Re: [PATCH v3 2/2] PCI: pciehp: Clear the optional capabilities in DEVCTL2 on a hot-plug | From | Smita Koralahalli <> |
| |
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
| |