On Tue, Dec 1, 2020 at 1:05 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > On Mon, Nov 30, 2020 at 04:11:42PM -0500, Jim Quinlan wrote: > > Whereas most PCIe HW returns 0xffffffff on illegal accesses and the like, > > by default Broadcom's STB PCIe controller effects an abort. This simple > > handler determines if the PCIe controller was the cause of the abort and if > > so, prints out diagnostic info. > > What happens during enumeration? pci_bus_generic_read_dev_vendor_id() > assumes a read of Vendor ID returns 0xffffffff if the device doesn't > exist. > > I assume this case doesn't cause the abort you're referring to here, > or nothing would work. I think this enumeration case results in PCIe > Unsupported Request errors (PCIe r5.0, sec 2.3.2 implementation note). Hi Bjorn, Yes, our controller makes a special case to allow for config-space accesses to the dev_id and vendor_id registers. even if the device is missing. That being said, it will abort on any access if the link is down. However, the 7216-type SOCs bring PCIe error-reporting HW but also have a mode where 0xffffffff is returned on improper accesses, just like many other controllers. We are debating whether we should turn this on by default. Regards, Jim Quinlan Broadcom STB > > Bjorn
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature