Re: [PATCH 09/22] scsi: hisi_sas: retrieve SAS address for pci-based controller

[John Garry]

> > 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

> .