On Thu, Nov 21, 2019 at 10:03:27AM +0800, Shawn Lin wrote: > From da9db487615c3687a0823c54d8d0790cbd4f79a2 Mon Sep 17 00:00:00 2001 > From: Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> > Date: Thu, 21 Nov 2019 09:45:12 +0800 > Subject: [PATCH] WFT: PCI: rockchip: play game with unsupported request from > EP > > Native defect prevents this RC far from supporting any response > from EP which UR filed is set. Take a big hammer to take over > Serror handler and work around it. Peter, now that you have a way to at least boot, can you collect the output of "sudo lspci -vvxxx"? When we're enumerating devices, we don't know ahead of time which devices exist, so we try to read the Vendor ID for each *possible* device. If the device doesn't exist, that config read should be terminated with an Unsupported Request completion (see the implementation note at the end of PCIe r5.0, sec 2.3.2). So far this is all standard PCIe hardware behavior (and sorry if this is all obvious). Sec 6.2.5 and 6.2.6 show several configuration bits that affect how that UR is handled and ultimately reported, possibly via SERR#. In most Linux systems, a UR completion does not cause an SERR#, but the PCI core does not manage those configuration bits directly (it probably *should* be more proactive about this), so this is more a result of how platform firmware set them than anything else. I'm speculating that you may have PCI_COMMAND_SERR and similar bits set, which will cause SERR# in cases where we don't see SERR# on other platforms. Your lspci output should show this. Bjorn
