On 09/24/2015 03:14 PM, David Miller wrote:
From: David Daney <ddaney@xxxxxxxxxxxxxxxxxx>
Date: Thu, 24 Sep 2015 15:04:23 -0700
On 09/24/2015 02:52 PM, David Miller wrote:
From: David Daney <ddaney.cavm@xxxxxxxxx>
Date: Tue, 22 Sep 2015 17:41:36 -0700
From: David Daney <david.daney@xxxxxxxxxx>
When the Cavium mdio-octeon devices appear in the Thunder family of
arm64 based SoCs, they show up as PCI devices. Add PCI driver
wrapping so the driver is bound in the standard PCI device scan.
When in this form, a single PCI device may have more than a single
bus, we call this a "nexus" of buses. The standard firmware
device_for_each_child_node() iterator is used to find the individual
buses underneath the "nexus".
Update the device tree binding documentation for the new PCI driver
binding.
Signed-off-by: David Daney <david.daney@xxxxxxxxxx>
This patch breaks the build:
For which architecture?
I tested it on mips and arm64. I will try x86, as I guess that is
where you tried your test build.
x86-64.
There is, somewhat of, a method behind the madness here.
In order to use MSI-X interrupts, we need a corresponding PCI
device. Now, this driver doesn't currently use interrupts, but other
devices in the SoC do, so they must be PCI devices.
"I need this thing, which isn't needed, therefore I'm making this
change."
That is not the exact argument. It is really more like this:
1) The firmware is supplying a uniform view of the devices by making
them all PCI devices. This is done because:
a) Devices that use interrupts must be PCI.
b) Uniformity is good.
2) The OF device tree nodes for PCI devices do not result in the
creation of a platform device.
3) If there is no platform device, platform device driver binding does
not occur, and the device is useless to the kernel.
So, we think it is a good change. I don't really want to argue about
the semantics of it being a "needed change".
Sorry, that's not a good argument.
ACPI nodes have names and whatnot as well.
So I haven't heard a compelling argument so far.
So why not just implement this cleanly and using the existing
framework now, and then when you have a legitimate reason for making a
major change to the probing scheme you can do it then.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
