Messages in this thread | | | Date | Thu, 24 Sep 2015 15:12:03 -0700 | From | David Daney <> | Subject | Re: [PATCH] net: mdio-octeon: Add PCI driver binding. |
| |
On 09/24/2015 03:04 PM, David Daney wrote: > On 09/24/2015 02:52 PM, David Miller wrote: >> From: David Daney <ddaney.cavm@gmail.com> >> Date: Tue, 22 Sep 2015 17:41:36 -0700 >> >>> From: David Daney <david.daney@cavium.com> >>> >>> 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@cavium.com> >> >> 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. > > >> >> CC [M] drivers/net/phy/mdio-octeon.o >> In file included from drivers/net/phy/mdio-octeon.c:13:0: >> include/linux/module.h:128:27: error: redefinition of ‘__inittest’ >> static inline initcall_t __inittest(void) \ >>
OK, I reproduced this failure. It happens with a module build only.
Sorry for the breakage, I will fix it and resubmit.
David Daney
^ > [...] > >> >> And frankly I'm not sure I like this change anyways. If the OF nodes >> are there, simply add code to match on those OF nodes. >> >> This is better than assuming what sits underneath a PCI node, without >> any checks for the 'name' or 'compatible' properties at all. That's >> what they are there for afterall. > > 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. > > The idea is to have the type of all drivers uniformly be PCI, rather > than a random mix of PCI and platform, and then switch them back and > forth as PCI features are/are-not used in the driver. > > Also we need to consider ACPI firmware in addition to OF device tree. > > David Daney >
| |