mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	John Garry <john.garry2@mail.dcu.ie>, <linuxarm@huawei.com>,
	<linux-scsi@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 09/22] scsi: hisi_sas: retrieve SAS address for pci-based controller
Date: Wed, 17 May 2017 17:45:05 +0100	[thread overview]
Message-ID: <dd20a241-b137-6779-63c9-6b881fc393c7@huawei.com> (raw)
In-Reply-To: <CAK8P3a0bo7L07X18_0e2vswLmCb+cu4CrzSoGKb0jk-yrKxTbQ@mail.gmail.com>

On 17/05/2017 15:13, Arnd Bergmann wrote:
> On Wed, May 17, 2017 at 3:37 PM, John Garry <john.garry@huawei.com> wrote:
>> On 17/05/2017 13:37, Arnd Bergmann wrote:
>
>>> Since this uses the _DSD information that was introduced for compatibility
>>> between device tree and ACPI based data, why not write the code so that
>>> it can work for both?
>>>
>>> Ideally this should just look up the property for pci_dev->fwnode, but I'm
>>> not entirely sure if this works the same way on ACPI and DT today.
>>>
>>
>> Hi Arnd,
>>
>> There is no relation at all between the pci device and the ACPI DSDT, apart
>> from the fact that the device node name is known by the driver, that being
>> "SAS0". I am not 100% comfortable with this, as we are introducing some sort
>> of device indexing in the driver.
>>
>> Please note that Cavium did something similar on their thunderx network
>> driver:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/cavium/thunder/thunder_bgx.c?h=v4.12-rc1#n1162
>>
>> As for your suggestion, in theory it could be ok to have a pci_dev->fwnode,
>> and this would work for Unified Device Properties Interface (if that is
>> indeed what you mean). But how to create/match this fwnode?
>
> pci_scan_device sets the dev->of_node field for DT based probing, we
> could add a trivial patch to set the fwnode field as well if that isn't
> already done elsewhere.
>
>>From what I can tell, the ACPI code sets up a 'companion' device for
> any PCI device that is listed in the ACPI tables, at least it refers to
> that later on, but I could not figure out where it actually gets set.
>

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.

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.

Much appreciated,
John

>         Arnd
>
> .
>

  reply	other threads:[~2017-05-17 16:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-17 10:49 [PATCH 00/22] hisi_sas: hip08 support John Garry
2017-05-17 10:49 ` [PATCH 01/22] scsi: hisi_sas: fix timeout check in hisi_sas_internal_task_abort() John Garry
2017-05-17 10:49 ` [PATCH 02/22] scsi: hisi_sas: optimise the usage of hisi_hba.lock John Garry
2017-05-17 10:49 ` [PATCH 03/22] scsi: hisi_sas: relocate get_ata_protocol() John Garry
2017-05-17 10:49 ` [PATCH 04/22] scsi: hisi_sas: relocate sata_done_v2_hw() John Garry
2017-05-17 10:49 ` [PATCH 05/22] scsi: hisi_sas: relocate get_ncq_tag_v2_hw() John Garry
2017-05-17 10:49 ` [PATCH 06/22] scsi: hisi_sas: add pci_dev in hisi_hba struct John Garry
2017-05-17 10:49 ` [PATCH 07/22] scsi: hisi_sas: add the initialisation for pci-based controller John Garry
2017-05-17 12:33   ` Arnd Bergmann
2017-05-17 13:03     ` John Garry
2017-05-17 10:49 ` [PATCH 08/22] scsi: hisi_sas: add bare v3 hw driver John Garry
2017-05-17 10:49 ` [PATCH 09/22] scsi: hisi_sas: retrieve SAS address for pci-based controller John Garry
2017-05-17 12:37   ` Arnd Bergmann
2017-05-17 13:37     ` John Garry
2017-05-17 14:13       ` Arnd Bergmann
2017-05-17 16:45         ` John Garry [this message]
2017-05-17 19:23           ` Arnd Bergmann
2017-05-18  9:09             ` John Garry
2017-05-17 10:49 ` [PATCH 10/22] scsi: hisi_sas: add v3 hw init John Garry
2017-05-17 10:49 ` [PATCH 11/22] scsi: hisi_sas: add v3 hw PHY init John Garry
2017-05-17 10:49 ` [PATCH 12/22] scsi: hisi_sas: add phy up/down/bcast and channel ISR John Garry
2017-05-17 10:49 ` [PATCH 13/22] scsi: hisi_sas: add v3 cq interrupt handler John Garry
2017-05-17 10:49 ` [PATCH 14/22] scsi: hisi_sas: add v3 code to send SSP frame John Garry
2017-05-17 10:49 ` [PATCH 15/22] scsi: hisi_sas: add v3 code to send SMP frame John Garry
2017-05-17 10:49 ` [PATCH 16/22] scsi: hisi_sas: add v3 code to send ATA frame John Garry
2017-05-17 10:49 ` [PATCH 17/22] scsi: hisi_sas: add v3 code for itct setup and free John Garry
2017-05-17 10:49 ` [PATCH 18/22] scsi: hisi_sas: add v3 code to send internal abort command John Garry
2017-05-17 10:49 ` [PATCH 19/22] scsi: hisi_sas: add get_wideport_bitmap_v3_hw() John Garry
2017-05-17 10:49 ` [PATCH 20/22] scsi: hisi_sas: Add v3 code to support ECC and AXI bus fatal error John Garry
2017-05-17 12:27   ` Arnd Bergmann
2017-05-17 12:38     ` John Garry
2017-06-13 14:05       ` John Garry
2017-05-17 10:49 ` [PATCH 21/22] scsi: hisi_sas: add v3 code to fill some more hw function pointers John Garry
2017-05-17 10:49 ` [PATCH 22/22] scsi: hisi_sas: modify internal abort dev flow for v3 hw John Garry
2017-05-17 12:38 ` [PATCH 00/22] hisi_sas: hip08 support Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd20a241-b137-6779-63c9-6b881fc393c7@huawei.com \
    --to=john.garry@huawei.com \
    --cc=arnd@arndb.de \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=john.garry2@mail.dcu.ie \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®