Hi Armando,
On 4/23/2010 3:32 AM, Armando VISCONTI wrote:
> 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?
>
I agree that MDIO bus probing doesn't make much sense. I don't know
anything about your SOC, but the ones that I work with typically have
multiple MACs (data link) but only one MDIO bus (control link). The end
result is multiple PHYs on a multi-drop bus, and there's no way of
knowing which one has its data link connected to which MAC.
I'd prefer to see it hard-coded, either through a CONFIG option or an
environment variable.
> Regards,
> Arm
regards,
Ben
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
