On Tuesday 23 September 2014 18:40:46 Sebastian Hesselbarth wrote:
> On 09/23/2014 06:29 PM, Arnd Bergmann wrote:
> > On Tuesday 23 September 2014 17:45:52 Sebastian Hesselbarth wrote:
> >> For reference, this is what we have for MVEBU SoCs with multiple ports
> >> per controller:
> >>
> >> eth: ethernet-ctrl@72000 {
> >> compatible = "marvell,orion-eth";
> ...
> >> reg = <0x72000 0x4000>;
> ...
> >>
> >> ethernet-port@0 {
> >> compatible = "marvell,orion-eth-port";
> ...
> >> phy-handle = <ðphy>;
> >> };
> >> };
> >>
> >> mdio: mdio-bus@72004 {
> >> compatible = "marvell,orion-mdio";
> ...
> >> reg = <0x72004 0x84>;
> ..
> >> ethphy: ethernet-phy {
> >> /* set phy address in board file */
> >> };
> >> };
>
> > But in this example, you have the same registers and the same
> > clocks in two nodes, which are even used by the same device driver
> > at the moment. It's not a big issue, but my feeling is that Antoine's
> > approach was actually better because it more closely reflects
> > the way that the hardware is built.
>
> I was not referring to the separate mdio bus node, but putting the
> ethernet-phy node as a child of ethernet-ctrl.
Ah, got it (I think). Yes, that makes sense.
The part I don't understand yet is how one uses multiple ports. pxa168_eth.c
seems to be written with the assumption that only one port is ever used at
a time, while mv643xx_eth.c can actually use multiple ports simultaneously.
Do you think that is that a hardware limitation of pxa168_eth or a feature
that nobody so far has needed from the driver?
If there is only one port and we just have to know which one that is,
I don't think we need the child nodes, but if one can have multiple
ports operate independently then the driver will need a rework
to actually be usable with that configuration.
Arnd
--
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
