From: ian.molton@codethink.co.uk (Ian Molton)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/7] mv643xx.c: Add basic device tree support.
Date: Wed, 08 Aug 2012 12:51:02 +0100 [thread overview]
Message-ID: <502252A6.4090409@codethink.co.uk> (raw)
In-Reply-To: <50223428.6030506@codethink.co.uk>
On 08/08/12 10:40, Ian Molton wrote:
> On 08/08/12 09:16, Arnd Bergmann wrote:
>
>> I'd prefer to take the entire series through the arm-soc tree from
>> the kirkwood maintainers. We first have to work out the bindings
>> though, since the current patch introduces a new one that is
>> incompatible with the one we were using on powerpc with open
>> firmware before.
Looking at the ethernet-group stuff, specifically from
arch/powerpc/boot/dts/prpmc2800.dts, which I've taken as a base for
the below:
The SMI / PHY stuff should look very similar, so I'm happy with something
like:
mdio at 2000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "mdio";
compatible = "marvell,mv643xx-mdio";
phy0: ethernet-phy at 0 {
device_type = "ethernet-phy";
compatible = "marvell,whatever";
interrupts = <76>;
interrupt-parent = <&mpic>;
reg = <0 32>; // Auto probed phy addr
};
phy1: ethernet-phy at 3 {
device_type = "ethernet-phy";
compatible = "marvell,whatever";
interrupts = <77>;
interrupt-parent = <&mpic>;
reg = <3 1>; // specified phy addr
};
... and so on.
}
Where we can use the reg parameter to allow auto-probing, by
specifying a size of 32 (32 phy addrs max).
The ethernet driver itself is more complicated:
We have the following considerations:
* we have one MDIO bus, typically, shared between all the MACs / PHYs.
* each ethernet device can multiple ports (up to three), each with its
own MAC/PHY.
* MAC <-> PHY mapping can be specified, probed (ugh!) or a (gah!)
mix of the two.
* existing D-T users, albeit not well documented / code complete.
* some port address ranges overlap (MIB counters, MCAST / UNICAST
tables, etc.
The existing ethernet-group idea only works because the current
platform-device based driver doesnt really do proper resource
management, and thus the MAC registers are actually mapped by
the MDIO driver.
I don't think that preserving this bad behaviour is a good idea, which
leaves us with two choices:
1) My preferred solution - allow each device to specify up to three
interrupts, MACs, and PHYs. This is clean in that it doesnt require
multiply instantiating a driver three times over the same address
space.
ethernet at 2400 {
compatible = "marvell,mv643xx-eth";
reg = <0x2400 0x1c00>
interrupt_parent = <&mpic>;
ports = <3>;
interrupts = <4>, <5>, <6>;
phys = <&phy0>, <&phy1>, <&phy2>;
};
ethernet at 6400 {
compatible = "marvell,mv643xx-eth";
reg = <0x6400 0x1c00>
interrupt_parent = <&mpic>;
ports = <1>;
interrupts = <4>;
phys = <&phy3>;
};
Note that the address is 2400, not 2000 - since this driver no longer
would share its address range with the MDIO driver.
This method would require a small amount of rework in the driver to
set up <n> ports, rather than just one.
2) Create some kind of pseudo-ethernet group device that manages
all the work for some sort of lightweight ethernet device, one per
port. This can never be done cleanly since the port address ranges
overlap:
pseudo_eth at 2400 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,mv643xx-shared-eth"
reg = <0x2400 0x1c00>;
ethernet at 0 {
compatible = "marvell,mv643xx-port";
interrupts = <4>;
interrupt_parent = <&mpic>;
phy = <&phy0>;
};
ethernet at 1 {
compatible = "marvell,mv643xx-port";
interrupts = <5>;
interrupt_parent = <&mpic>;
phy = <&phy1>;
};
ethernet at 2 {
compatible = "marvell,mv643xx-port";
interrupts = <6>;
interrupt_parent = <&mpic>;
phy = <&phy2>;
};
}
pseudo_eth at 6400 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,mv643xx-shared-eth"
reg = <0x6400 0x1c00>;
ethernet at 0 {
compatible = "marvell,mv643xx-port";
interrupts = <4>;
interrupt_parent = <&mpic>;
phy = <&phy3>;
};
};
Thoughts?
-Ian
WARNING: multiple messages have this Message-ID (diff)
From: Ian Molton <ian.molton@codethink.co.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: David Miller <davem@davemloft.net>,
linux-arm-kernel@lists.infradead.org, andrew@lunn.ch,
thomas.petazzoni@free-electrons.com, ben.dooks@codethink.co.uk,
netdev@vger.kernel.org
Subject: Re: [PATCH v3 0/7] mv643xx.c: Add basic device tree support.
Date: Wed, 08 Aug 2012 12:51:02 +0100 [thread overview]
Message-ID: <502252A6.4090409@codethink.co.uk> (raw)
In-Reply-To: <50223428.6030506@codethink.co.uk>
On 08/08/12 10:40, Ian Molton wrote:
> On 08/08/12 09:16, Arnd Bergmann wrote:
>
>> I'd prefer to take the entire series through the arm-soc tree from
>> the kirkwood maintainers. We first have to work out the bindings
>> though, since the current patch introduces a new one that is
>> incompatible with the one we were using on powerpc with open
>> firmware before.
Looking at the ethernet-group stuff, specifically from
arch/powerpc/boot/dts/prpmc2800.dts, which I've taken as a base for
the below:
The SMI / PHY stuff should look very similar, so I'm happy with something
like:
mdio@2000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "mdio";
compatible = "marvell,mv643xx-mdio";
phy0: ethernet-phy@0 {
device_type = "ethernet-phy";
compatible = "marvell,whatever";
interrupts = <76>;
interrupt-parent = <&mpic>;
reg = <0 32>; // Auto probed phy addr
};
phy1: ethernet-phy@3 {
device_type = "ethernet-phy";
compatible = "marvell,whatever";
interrupts = <77>;
interrupt-parent = <&mpic>;
reg = <3 1>; // specified phy addr
};
... and so on.
}
Where we can use the reg parameter to allow auto-probing, by
specifying a size of 32 (32 phy addrs max).
The ethernet driver itself is more complicated:
We have the following considerations:
* we have one MDIO bus, typically, shared between all the MACs / PHYs.
* each ethernet device can multiple ports (up to three), each with its
own MAC/PHY.
* MAC <-> PHY mapping can be specified, probed (ugh!) or a (gah!)
mix of the two.
* existing D-T users, albeit not well documented / code complete.
* some port address ranges overlap (MIB counters, MCAST / UNICAST
tables, etc.
The existing ethernet-group idea only works because the current
platform-device based driver doesnt really do proper resource
management, and thus the MAC registers are actually mapped by
the MDIO driver.
I don't think that preserving this bad behaviour is a good idea, which
leaves us with two choices:
1) My preferred solution - allow each device to specify up to three
interrupts, MACs, and PHYs. This is clean in that it doesnt require
multiply instantiating a driver three times over the same address
space.
ethernet@2400 {
compatible = "marvell,mv643xx-eth";
reg = <0x2400 0x1c00>
interrupt_parent = <&mpic>;
ports = <3>;
interrupts = <4>, <5>, <6>;
phys = <&phy0>, <&phy1>, <&phy2>;
};
ethernet@6400 {
compatible = "marvell,mv643xx-eth";
reg = <0x6400 0x1c00>
interrupt_parent = <&mpic>;
ports = <1>;
interrupts = <4>;
phys = <&phy3>;
};
Note that the address is 2400, not 2000 - since this driver no longer
would share its address range with the MDIO driver.
This method would require a small amount of rework in the driver to
set up <n> ports, rather than just one.
2) Create some kind of pseudo-ethernet group device that manages
all the work for some sort of lightweight ethernet device, one per
port. This can never be done cleanly since the port address ranges
overlap:
pseudo_eth@2400 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,mv643xx-shared-eth"
reg = <0x2400 0x1c00>;
ethernet@0 {
compatible = "marvell,mv643xx-port";
interrupts = <4>;
interrupt_parent = <&mpic>;
phy = <&phy0>;
};
ethernet@1 {
compatible = "marvell,mv643xx-port";
interrupts = <5>;
interrupt_parent = <&mpic>;
phy = <&phy1>;
};
ethernet@2 {
compatible = "marvell,mv643xx-port";
interrupts = <6>;
interrupt_parent = <&mpic>;
phy = <&phy2>;
};
}
pseudo_eth@6400 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,mv643xx-shared-eth"
reg = <0x6400 0x1c00>;
ethernet@0 {
compatible = "marvell,mv643xx-port";
interrupts = <4>;
interrupt_parent = <&mpic>;
phy = <&phy3>;
};
};
Thoughts?
-Ian
next prev parent reply other threads:[~2012-08-08 11:51 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 14:34 [PATCH v3 0/7] mv643xx.c: Add basic device tree support Ian Molton
2012-08-07 14:34 ` Ian Molton
2012-08-07 14:34 ` [PATCH v3 1/7] Initial csb1724 board support (FDT) Ian Molton
2012-08-07 14:34 ` Ian Molton
2012-08-07 14:34 ` [PATCH v3 2/7] mv643xx.c: Remove magic numbers Ian Molton
2012-08-07 14:34 ` Ian Molton
2012-08-07 14:34 ` [PATCH v3 3/7] mv643xx.c: Add basic device tree support Ian Molton
2012-08-07 14:34 ` Ian Molton
2012-08-07 14:56 ` Arnd Bergmann
2012-08-07 14:56 ` Arnd Bergmann
2012-08-07 15:56 ` Ian Molton
2012-08-07 15:56 ` Ian Molton
2012-08-07 20:25 ` Arnd Bergmann
2012-08-07 20:25 ` Arnd Bergmann
2012-08-07 20:25 ` Arnd Bergmann
2012-08-07 14:34 ` [PATCH v3 4/7] kirkwood: Add fixups for DT based mv643xx ethernet Ian Molton
2012-08-07 14:34 ` Ian Molton
2012-08-07 14:34 ` [PATCH v3 5/7] csb1724: Enable device tree based mv643xx ethernet support Ian Molton
2012-08-07 14:34 ` Ian Molton
2012-08-07 14:34 ` [PATCH v3 6/7] DT: Convert all kirkwood boards with mv643xx that use DT Ian Molton
2012-08-07 14:34 ` Ian Molton
2012-08-07 14:34 ` [PATCH v3 7/7] NET: mv643xx: remove device name macro Ian Molton
2012-08-07 14:34 ` Ian Molton
2012-08-07 23:29 ` [PATCH v3 0/7] mv643xx.c: Add basic device tree support David Miller
2012-08-07 23:29 ` David Miller
2012-08-08 0:31 ` Matt Sealey
2012-08-08 0:31 ` Matt Sealey
2012-08-08 8:16 ` Arnd Bergmann
2012-08-08 8:16 ` Arnd Bergmann
2012-08-08 8:59 ` David Miller
2012-08-08 8:59 ` David Miller
2012-08-08 9:40 ` Ian Molton
2012-08-08 9:40 ` Ian Molton
2012-08-08 9:42 ` Ian Molton
2012-08-08 9:42 ` Ian Molton
2012-08-08 11:51 ` Ian Molton [this message]
2012-08-08 11:51 ` Ian Molton
2012-08-08 12:39 ` Arnd Bergmann
2012-08-08 12:39 ` Arnd Bergmann
2012-08-08 13:19 ` Ian Molton
2012-08-08 13:19 ` Ian Molton
2012-08-09 10:59 ` Ian Molton
2012-08-09 10:59 ` Ian Molton
2012-08-09 10:59 ` Ian Molton
2012-08-09 11:43 ` Arnd Bergmann
2012-08-09 11:43 ` Arnd Bergmann
2012-08-09 11:43 ` Arnd Bergmann
2012-08-09 15:21 ` Ian Molton
2012-08-09 15:21 ` Ian Molton
2012-08-09 15:21 ` Ian Molton
2012-08-10 10:49 ` Arnd Bergmann
2012-08-10 10:49 ` Arnd Bergmann
2012-08-10 10:49 ` Arnd Bergmann
2012-08-13 10:00 ` Ian Molton
2012-08-13 10:00 ` Ian Molton
2012-08-13 10:00 ` Ian Molton
2012-08-16 16:30 ` Ian Molton
2012-08-16 16:30 ` Ian Molton
2012-08-16 16:30 ` Ian Molton
2012-09-10 14:22 ` Arnd Bergmann
2012-09-10 14:22 ` Arnd Bergmann
2012-09-10 14:22 ` Arnd Bergmann
2012-09-11 6:03 ` Benjamin Herrenschmidt
2012-09-11 6:03 ` Benjamin Herrenschmidt
2012-09-11 6:03 ` Benjamin Herrenschmidt
2012-10-21 1:52 ` Jason Cooper
2012-10-21 1:52 ` Jason Cooper
2012-10-21 1:52 ` Jason Cooper
2012-08-17 12:13 ` Arnd Bergmann
2012-08-17 12:13 ` Arnd Bergmann
2012-08-17 12:13 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502252A6.4090409@codethink.co.uk \
--to=ian.molton@codethink.co.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.