[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56047367.3060101@caviumnetworks.com>
Date: Thu, 24 Sep 2015 15:04:23 -0700
From: David Daney <ddaney@...iumnetworks.com>
To: David Miller <davem@...emloft.net>
CC: <ddaney.cavm@...il.com>, <linux-kernel@...r.kernel.org>,
<robh+dt@...nel.org>, <pawel.moll@....com>, <mark.rutland@....com>,
<ijc+devicetree@...lion.org.uk>, <galak@...eaurora.org>,
<devicetree@...r.kernel.org>, <f.fainelli@...il.com>,
<netdev@...r.kernel.org>, <david.daney@...ium.com>
Subject: Re: [PATCH] net: mdio-octeon: Add PCI driver binding.
On 09/24/2015 02:52 PM, David Miller wrote:
> From: David Daney <ddaney.cavm@...il.com>
> Date: Tue, 22 Sep 2015 17:41:36 -0700
>
>> From: David Daney <david.daney@...ium.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@...ium.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) \
> ^
[...]
>
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists