Re: [PATCH] net: mdio-octeon: Add PCI driver binding.

From: David Daney
Date: Thu Sep 24 2015 - 18:04:38 EST


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.



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) \
^
[...]


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/