On Sun, 07 Jul 2013 12:52:52 +0200
Sebastian Hesselbarth<sebastian.hesselbarth@xxxxxxxxx> wrote:
The error below is a naming issue for the port. As there is only one
port per controller, both reg properties of the port nodes of
kirkwood.dtsi have to be<0> as they determine the register offset
within the controller registers. As mentioned before, KW has a
dual-controller, single port configuration.
So the wrong reg property in kirkwood.dtsi is a bug and I will update
the patch.
Second, mv643xx_eth as in net-next does a
platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number)
which will cause two devices named mv643xx_eth_port.0 if you change
both of the reg property to<0>.
A quick fix would be to change the above to
platform_device_alloc(pnp->name, ppd.port_number)
so the port devices will be named after the device nodes name.
Also, for this I will prepare a patch. But the rename of the port
devices could again raise the clock gating/loosing MAC issue.
In my case it's a non-issue as the studid D-Link U-Boot doesn't even
setup a mac for eth1, so there's nothing to lose ;).
(I know again, why I hate this shared/port separation of mv643xx_eth)
Anyway, can you please try to have both ports reg properties set
to<0>, with nodes named ethernet0-port@0 and ethernet1-port@0,
and the platform_device_alloc in mv643xx_eth modified?
In addition I added a static counter for the allocated devs (to not
overwrite the pointers in port_platdev[]).
That seems to work, as now eth1 comes up and works (successfully got a
IP through DHCP).