From: Richard Retanubun <RichardRetanubun@RuggedCom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Net: Fec: Question about CONFIG_SYS_DISCOVER_PHY
Date: Mon, 27 Apr 2009 14:41:55 -0400 [thread overview]
Message-ID: <49F5FC73.2010202@RuggedCom.com> (raw)
Hello,
My M5271EVB based board connects the SMI of the FEC PHY to an external entity and not to the SMI controller of the CPU.
The MII bus is still connected between the CPU and the FEC PHY. The phy is then bootstrapped to be [100BaseT FullDuplex No AutoNeg].
I wanted to use something similar to CONFIG_FIXED_PHY as in the ppc driver, the one I found for ColdFire is CONFIG_SYS_DISCOVER_PHY
However, when I tried to use it (by commenting out CONFIG_SYS_DISCOVER_PHY), I got this compile error:
mcffec.c: In function 'mcffec_initialize':
mcffec.c:615: error: 'mcffec_miiphy_read' undeclared (first use in this function)
mcffec.c:615: error: (Each undeclared identifier is reported only once
mcffec.c:615: error: for each function it appears in.)
mcffec.c:615: error: 'mcffec_miiphy_write' undeclared (first use in this function)
make[1]: *** [mcffec.o] Error 1
make: *** [drivers/net/libnet.a] Error 2
I manage to make it work using the diffs below and by #undef-ing CONFIG_MII, CONFIG_MII_INIT and CONFIG_CMD_MII,
in by board header file. I am a bit ignorant as to how ugly my changes might be, if it has a hope of being mainlined,
I can clean it up a bit.
Also, I am kinda suprised that the network connection works anyway even when I still keep CONFIG_SYS_DISCOVER_PHY defined.
I've been trying to find the 'magic' spot where even though the PHY is not being recognized, the system continue to work
and assume/fallback to [100BaseT FullDuplex] Is this a known fallback method? where can I find the logic?
my uClinux seems to work as well, so does Linux have the same fallback?
Any feedback is appreciated.
- Richard Retanubun.
<Start of patch>
diff --git a/drivers/net/mcffec.c b/drivers/net/mcffec.c
index 64be5de..e3416b5 100644
--- a/drivers/net/mcffec.c
+++ b/drivers/net/mcffec.c
@@ -139,9 +139,11 @@ int fec_send(struct eth_device *dev, volatile void *packet, int length)
struct fec_info_s *info = dev->priv;
volatile fec_t *fecp = (fec_t *) (info->iobase);
int j, rc;
- u16 phyStatus;
+#ifdef CONFIG_MII
+ u16 phyStatus;
miiphy_read(dev->name, info->phy_addr, PHY_BMSR, &phyStatus);
+#endif /* CONFIG_MII */
/* section 16.9.23.3
* Wait for ready
diff --git a/drivers/net/mcfmii.c b/drivers/net/mcfmii.c
index 4f1c0a0..909e247 100644
--- a/drivers/net/mcfmii.c
+++ b/drivers/net/mcfmii.c
@@ -144,7 +144,6 @@ uint mii_send(uint mii_cmd)
return (mii_reply & 0xffff); /* data read from phy */
}
-#endif /* CONFIG_SYS_DISCOVER_PHY || (CONFIG_MII) */
#if defined(CONFIG_SYS_DISCOVER_PHY)
int mii_discover_phy(struct eth_device *dev)
@@ -328,5 +327,5 @@ int mcffec_miiphy_write(char *devname, unsigned char addr, unsigned char reg,
return 0;
}
-
+#endif /* CONFIG_SYS_DISCOVER_PHY || (CONFIG_MII) */
#endif /* CONFIG_CMD_NET, FEC_ENET & NET_MULTI */
reply other threads:[~2009-04-27 18:41 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49F5FC73.2010202@RuggedCom.com \
--to=richardretanubun@ruggedcom.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox