From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Tue, 08 Jan 2008 11:27:45 -0500 Subject: [U-Boot-Users] MII / RMII In-Reply-To: <200801080543.18095.sr@denx.de> References: <1196375148.13652.156.camel@elrond.atmel.sweden> <2acbd3e40801071735r374fbdfdt3797e207fe54976b@mail.gmail.com> <200801080543.18095.sr@denx.de> Message-ID: <4783A481.1040004@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Stefan Roese wrote: > On Tuesday 08 January 2008, Andy Fleming wrote: > >>> I think that if you use an Ethernet and need to differentiate >>> between MII and RMII they should be mutually exclusive. >>> You either define CONFIG_RMII OR CONFIG_MII but not both. >>> If you have a PHY on the chip, then you do not define any of the two. >>> MII uses more pins and maybe different pins, so a port for a CPU >>> should differentiate. >>> >> I'm a little late to this, but I feel I should make sure people are aware >> that CONFIG_MII and CONFIG_RMII are not, in this case, two different >> options for the same concept. CONFIG_MII is the option you enable to allow >> MII Management operations to be done. It should *probably* be called >> CONFIG_MDIO. >> > > Yes, this would be good. Anyone interested in fixing up a patch for this? > I think it's a noble idea, but probably a can of worms in practice. The use of the term 'MII' is rampant, for example we have 'mii' commands, and 'bbmii' commands. These both really concern MDIO, but I doubt we want to change them. The real culprit is RMII. As Andy has pointed out, RMII is a data plane alternative to MII, but shares the MDIO control plane. RMII is a hardware configuration, and as such is 'set and forget' and highly implementation-specific. Having a global CONFIG_RMII makes no sense. If anything, CONFIG_RMII should be changed to stuff like CONFIG_TSEC_RMII_2 etc. (a quickly made-up example with no grounding in reality), where the hardware binding is obvious. regards, Ben