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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 17 May 2017 16:13:02 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     John Garry <john.garry@...wei.com>
Cc:     "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        John Garry <john.garry2@...l.dcu.ie>, linuxarm@...wei.com,
        linux-scsi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 09/22] scsi: hisi_sas: retrieve SAS address for pci-based controller

On Wed, May 17, 2017 at 3:37 PM, John Garry <john.garry@...wei.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.

        Arnd