On 09/18/2015 12:45 PM, Arnd Bergmann wrote:
On Friday 18 September 2015 10:00:32 David Daney wrote:
On 09/18/2015 12:19 AM, Arnd Bergmann wrote:
On Thursday 17 September 2015 15:41:33 David Daney wrote:
From: David Daney <david.daney@xxxxxxxxxx>
The on-chip devices all have fixed bars. So, fix them up.
Signed-off-by: David Daney <david.daney@xxxxxxxxxx>
You should be able to just mark the BARs as fixed in DT
I think we can switch to PCI_PROBE_ONLY, and have all non-fixed BAR
devices configured by firmware. This may significantly simplify any
quirks required in the kernel.
In the case of ACPI, there is no DT. So we would need a different
solution for ACPI. What would you recommend for ACPI?
I would expect that this does not matter at all on ACPI, because
the devices that need it are not hot-plugged, and all boot-time
devices are probed by the firmware: the ACPI PCI implementation
does not reassign any BARs, except for the hotplug case.
Also, can you point me to the OF device tree specification where it
tells how to specify PCI BAR addresses, I would especially be interested
in knowing how to specify fixed SRIOV BAR addresses in the device tree.
This is the 'n' bit mentioned sections 2.1.3 and 2.2.1.1 of the
PCI binding. When it is set, the OS is not supposed to try to
reassign the BAR even on machines that otherwise do a complete
rescan.
The PCI binding traditionally requires you to list all PCI devices
in DT, Linux as an extension (for the flattened DT format) allows
leaving out the devices, but in this case you probably need to
list every device that has a fixed BAR.
Yes, it is a bit of a hack. That is why I put it in its own file, and
only try to hack up PCI devices that exactly match the vendor and device
ids that need fixing.
IMHO, putting infrastructure into drivers/pci/probe.c, et al. to handle
this would be much more intrusive.
My guess is that it's already there, but even if it's not, this is a
generic well-defined case that has a standardized binding, and we should
implement that.
For the record: The PCI Enhanced Allocation (EA) capability (approved
by PCI SIG on 23 October 2014) is the proper way to handle this going
forward. However, this is not yet implemented in the SoCs that this
patch addresses. Our plan is to implement the EA capability in the core
PCI code, so that we do not need to keep adding devices to this fixup code.
Good, but still this should only be required for the embedded case where
you don't have a firmware to probe the bus.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
