Messages in this thread | | | Subject | Re: [PATCH 09/22] scsi: hisi_sas: retrieve SAS address for pci-based controller | From | John Garry <> | Date | Thu, 18 May 2017 10:09:02 +0100 |
| |
>> 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
> . >
| |