On Thu, Jan 04, 2024 at 08:01:06PM +0530, Vidya Sagar wrote: > On 8/1/2023 1:29 AM, Lukas Wunner wrote: > > As an alternative to disabling ACS, have you explored masking ACS > > Violations (PCI_ERR_UNC_ACSV) upon de-enumeration of a device and > > unmasking them after assignment of a bus number? > > I explored this option and it seemed to work as expected. But, the issue > is that this works only if the AER registers are owned by the OS. If the > AER registers are owned by the firmware (i.e. Firmware-First approach of > handling the errors), OS is not supposed to access the AER registers and > there is no indication from the OS to the firmware as to when the > enumeration is completed and time is apt to unmask the ACSViolation > errors in the AER's Uncorrectable Error Mask register. > Any thoughts on accommodating the Firmware-First approach also? Are you actually using firmware-controlled AER or is it a theoretical question? PCI Firmware Spec r3.3 sec 4.6.12 talks about a _DSM to disable DPC on surprise-hotplug-capable ports. Maybe that would be an option? BTW what happens if the system resumes from sleep and a device in a hotplug-capable port doesn't have a bus number configured yet (because it's been powered off and is now in D0uninitialized state)? Could the ACS Violations then occur as well? Do we have to mask ACS Violations *generally* on Root Ports and Downstream Ports when going to system sleep and unmask them after setting a bus number in the attached device on resume? And I suppose that would not only be necessary for hotplug ports? Thanks, Lukas
