From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Warren <biggerbadderben@gmail.com>
Date: Sun, 25 Apr 2010 22:02:49 -0700
Subject: [U-Boot] [PATCH 07/17] SPEAr : Network driver support added
In-Reply-To: <4BD17747.2010307@st.com>
References: <1271836483-15978-1-git-send-email-vipin.kumar@st.com>	<1271836483-15978-2-git-send-email-vipin.kumar@st.com>	<1271836483-15978-3-git-send-email-vipin.kumar@st.com>	<1271836483-15978-4-git-send-email-vipin.kumar@st.com>	<1271836483-15978-5-git-send-email-vipin.kumar@st.com>	<1271836483-15978-6-git-send-email-vipin.kumar@st.com>	<1271836483-15978-7-git-send-email-vipin.kumar@st.com>	<1271836483-15978-8-git-send-email-vipin.kumar@st.com>
	<4BCF3A89.2070607@gmail.com> <4BD17747.2010307@st.com>
Message-ID: <4BD51E79.4020401@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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