From mboxrd@z Thu Jan  1 00:00:00 1970
From: Armando VISCONTI <armando.visconti@st.com>
Date: Fri, 23 Apr 2010 12:32:39 +0200
Subject: [U-Boot] [PATCH 07/17] SPEAr : Network driver support added
In-Reply-To: <4BCF3A89.2070607@gmail.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>
Message-ID: <4BD17747.2010307@st.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

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