在 2022/6/2 17:23, Bjorn Helgaas 写道:
On Thu, Jun 02, 2022 at 12:28:40PM +0800, Huacai Chen wrote:
Hi, Bjorn,
On Wed, Jun 1, 2022 at 7:14 AM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
On Sat, Apr 30, 2022 at 04:48:43PM +0800, Huacai Chen wrote:
On LS2K/LS7A, some unexisting devices don't return 0xffffffff when
scanning. This is a hardware flaw but we can only avoid it by software
now.
What happens in other situations that normally cause Unsupported
Request or similar errors? For example, memory reads/writes to a
device in D3hot should cause an Unsupported Request error. I'm
wondering whether other error handling assumptions might be broken
on LS2K/LS7A.
Hardware engineers told me that the problem is due to pin
multiplexing, under some configurations, a PCI device is unusable but
the read request doesn't return 0xffffffff.
What happens if a driver does a mem read to a device that's in D3hot?
Just did experiment on my hardware (which is a MIPS-era LS3A4000 with
LS7A).
It turns out that the hardware simply returns 0xffffffff for all reads and
ignore writes.
The PCIe controller of LS7A is a customized dwc and it should response
with a SLVERR transaction on LS7A's internalAXI bus. However the bus
we used to connect LS7A with CPU is incapable to pass this SLVERR
information to CPU and thus it just provides a false result.
All LS7A's on-chip devices connected on PCI bus don't expose any
PCI power management capability. Though they have power management
registers elsewhere and generally we won't touch them when kernel
is running.
Thanks
- Jiaxun
