From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= Date: Mon, 23 Jul 2012 19:43:16 +0200 (CEST) Subject: [U-Boot] [PATCH 1/2] net: fec_mxc: Fix setting of RCR for xMII In-Reply-To: <9848F2DB572E5649BA045B288BE08FBEE2D9DD@039-SN2MPN1-021.039d.mgd.msft.net> Message-ID: <1816188593.462586.1343065396037.JavaMail.root@advansee.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Andy, On Mon, Jul 23, 2012 at 04:11:22AM, Duan Fugang-B38611 wrote: > With flow control (FCE) feature, it depends on the hardware support. > I.MX serial Ethernet ip (FEC, enet) can support the features, and it > don't need to enable flow control in 100Mbps transition in fact. > As our test result, if Ethernet rx bandwidth more than 140Mbps, FCE > feature can be helpful to resolve FIFO overruns issue. > In uboot, Ethernet has no the similar cases needed so big bandwidth, > so it don't care FCE feature. OK. > With fec_open enables full-duplex in TCR regardless of xcv_type, it > is not reasonable. > The good method must be use auto-negotiation and check phy duplex > status, you can refer to net/mxc_fec.c file. I agree. I don't have time to fix this right now. Perhaps you or someone else can handle this. There does not seem to be any bug tracking system in U-Boot, so I don't know if something specific should be done to report this. Anyway, this does not seem to be an issue for current hardware using this driver, so there is no emergency. I also noticed that fec_eth_phy_config calls phy_connect with PHY_INTERFACE_MODE_RGMII regardless of xcv_type, which does not seem appropriate. Best regards, Beno?t