[meta-xilinx] emacps driver fails on 2nd probe

Edward Wingate edwingate8 at gmail.com
Thu Oct 15 21:50:20 PDT 2015


This commit seems to break emacps driver probing when doing more than 1 probe:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/commit/?id=965b8e54c45b60e9d346178c8285552c3d70c28d

By getting rid of the mdio entry and moving the phy entries up a
level, this emacps code will now get the resource address of the amba
node instead of the ps7-ethernet nodes:
https://github.com/Xilinx/linux-xlnx/blob/f672c6bf89ae093b147e244f13d9e5886c5bfdbc/drivers/net/ethernet/xilinx/xilinx_emacps.c#L912-L913

When doing more than one enet probe, it'll succeed the first time
using the amba resource address (when it should be using the
ps7_ethernet_0 e000b000 address) and fail the second time because
it'll use the amba resource address again (when this time it should be
using ps7_ethernet_1 e000c000 address).  I was able to fix it by going
back to using np instead of npp to get the resource address:
of_address_to_resource(np, 0, &res);

Since I know I'll be using emacps driver to support the
gmii2rgmii-phy-handle, I guess I could just put the mdio entry back
into the device tree.  Having the mdio entry caused the macb driver to
do unnecessary scan:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2015-April/000956.html

But what is the proper solution here that is compatible with macb and
emacps driver?  For those using emacps driver, just curious what is in
your /sys/class/mdio_bus directory?  I think it should be e000b000
and/or e000c000.  But with this apparent bug, it'll be some other
address.  Doesn't seem to affect any functionality though if there's
only one enet device.



More information about the meta-xilinx mailing list