From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755448AbdERJJq (ORCPT ); Thu, 18 May 2017 05:09:46 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:6782 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755074AbdERJJm (ORCPT ); Thu, 18 May 2017 05:09:42 -0400 Subject: Re: [PATCH 09/22] scsi: hisi_sas: retrieve SAS address for pci-based controller To: Arnd Bergmann References: <1495018197-120535-1-git-send-email-john.garry@huawei.com> <1495018197-120535-10-git-send-email-john.garry@huawei.com> CC: "James E.J. Bottomley" , "Martin K. Petersen" , John Garry , , , "Linux Kernel Mailing List" From: John Garry Message-ID: <10ad7e70-b0c4-8ee6-c5e8-74ee6511f171@huawei.com> Date: Thu, 18 May 2017 10:09:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.181.157] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.591D64BC.0124,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8a7cc9d082228fb27a4a4f1eead498d8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> 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 > . >