forked from luck/tmp_suning_uos_patched
6eb237c41a
The status register of the PCI configuration space of PCI-to-PCI bridges contain some read-only bits, and so write-1-to-clear bits. So, the Linux PCI core sometimes writes 0xffff to this status register, and in the current PCI-to-PCI bridge emulation code of the Marvell driver, we do take all those 1s being written. Even the read-only bits are being overwritten. For now, all the read-only bits should be emulated to have the zero value. The other bits, that are write-1-to-clear bits are used to report various kind of errors, and are never set by the emulated bridge, so there is no need to support this write-1-to-clear bits mechanism. As a conclusion, the easiest solution is to simply emulate this status register by returning zero when read, and ignore the writes to it. This has two visible effects: * The devsel is no longer 'unknown' in, i.e Flags: bus master, 66MHz, user-definable features, ?? devsel, latency 0 becomes: Flags: bus master, 66MHz, user-definable features, fast devsel, latency 0 in lspci -v. This was caused by a value of 11b being read for devsel, which is an invalid value. This 11b value being read was due to a previous write of 0xffff into the status register. * The capability list is no longer broken, because we indicate to the Linux PCI core that we don't have a Capabilities Pointer in the PCI configuration space of this bridge. The following message is therefore no longer visible in lspci -v: Capabilities: [fc] <chain broken> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> |
||
---|---|---|
.. | ||
Kconfig | ||
Makefile | ||
pci-mvebu.c |