Hi Arnd,
Currently there is no pci device listed in the ACPI tables.
What I am doing is declaring a fake device in the root of the System bus
tree of the ACPI tables, and in the kernel driver finding it by matching the
name. It is not the ACPI companion for the pci device.
So I think that we can define the pci device under the pci bus in the ACPI
tables, and define the ADR and DSD. Then we would have an ACPI companion for
the device, and from that get the SAS address.
Yes, that would be much better, and allow us to use the device properties
interface directly. An additional advantage is that the property definition
can be exactly the same as for the v1/v2 platform_device properties
for anything that might be needed across all versions. sas-addr already
fits in there, and there might be additional properties you need in the
future.
Hi Arnd,
OK, we'll try this.
As for other properties, phy and queue count are common to all versions.
However, I need to consider more if I should add these - maybe it is ok.
The reason we did not hardcode these for v1/v2 was that these were
variable for controllers inter and intra SoC.
hip08 only has 1 controller, and I have been told that each controller
will have a unique pci device id that for future SoCs, so it's viable to
hardcode.
An alternative to this ACPI device method is for UEFI to write the SAS
address to a defined free location in device's pci config space, which the
driver can read.
That sounds ok as well, it would be nice to not rely on firmware data here,
but I'd have to see how the implementation ends up: IIRC you should
not just put the data at a fixed location in the config space but instead use
the 'extended capabilities' infrastructure to find the data.
PCI_EXT_CAP_ID_VNDR might be the right one here, but I don't
know enough about this, so please consult with someone who does
(or the PCIe specification).
Right, we'll keep ACPI table description as plan A.
Arnd
Much appreciated,
John
.
