Ben,
I have a specific question on the way we handle phy address
in SPEAr.
>> +
>> +static u8 find_phy(struct eth_device *dev)
>> +{
>> + u8 phy_addr = 0;
>> + u16 ctrl, oldctrl;
>> +
>> + do {
>> + eth_mdio_read(dev, phy_addr, PHY_BMCR,&ctrl);
>> + oldctrl = ctrl& PHY_BMCR_AUTON;
>> +
>> + ctrl ^= PHY_BMCR_AUTON;
>> + eth_mdio_write(dev, phy_addr, PHY_BMCR, ctrl);
>> + eth_mdio_read(dev, phy_addr, PHY_BMCR,&ctrl);
>> + ctrl&= PHY_BMCR_AUTON;
>> +
>> + if (ctrl == oldctrl) {
>> + phy_addr++;
>> + } else {
>> + ctrl ^= PHY_BMCR_AUTON;
>> + eth_mdio_write(dev, phy_addr, PHY_BMCR, ctrl);
>> + break;
>> + }
>> + } while (phy_addr< 32);
>> +
>> + return phy_addr;
>> +}
>> +
>>
As you can see we use an auto-probing mechanism implemented as find_phy()
routine. This auto-probing is also used in other cases, like the
drivers/net/mcfmii.c (mii_discover_phy()).
Actually I'm not sure this auto-probing mechanism is correct, as it
works only
in case (very used) in which the MAC-PHY are in 1:1 relationship.
Instead, the MDIO bus nature implies that there might be N MACs and M
PHYs connected
to the bus, so the auto-probing would not work.
See here some comments on the same:
http://lists.ozlabs.org/pipermail/devicetree-discuss/2010-February/001670.html
In our PCB we have the 1:1 relationship, but since the dw_eth.c driver
is generic, it
might be used on differently designed pcb.
What is your general opinion in that?
Should we implement it differently?
Regards,
Arm
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
