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