From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Thu, 29 Nov 2007 15:31:51 -0500 Subject: [U-Boot-Users] MII / RMII In-Reply-To: References: Message-ID: <474F21B7.7050701@qstreams.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 Guennadi, Guennadi Liakhovetski wrote: > Hi, > > 1. Does it make sense at all to define CONFIG_RMII without defining > CONFIG_MII? The question is meant not really theoretical as in what > meaning RMII has, rather how the macro CONFIG_RMII is supposed to be used? > For example, tests like > > #if defined(CONFIG_MII) && defined(CONFIG_RMII) > > isn't checking for CONFIG_MII redundant? > > I wouldn't say it's redundant, but that's only because I think both are stupid. Neither of these CONFIGs should be generalized, since they are inherently hardware dependent. RMII vs. MII is a data plane hardware decision, and the only relevant software is typically a small amount of code that sets a register in the Ethernet controller for the proper bus. > 2. cpu/at32ap/at32ap7000/gpio.c also tests CONFIG_RMII. at32ap is an AVR32 > CPU and this macro is only defined in a few MPC8XX configurations, so, > this test doesn't seem to make much sense in the current tree. > > 3. drivers/qe/uec_phy.c tests CONFIG_RMII_MODE, which doesn't occur > anywhere else in the tree. The driver is enabled in some MPC85xx and > MPC83xx configs. > > 4. drivers/macb.c tests for "RMII or MII mode" by jest checking > > #ifdef CONFIG_RMII > ... > #else > ... > #endif > > i.e., not for > > #elif defined CONFIG_MII > > This driver is only enabled in include/configs/atstk1002.h, which is also > an AVR32 config, and it neither defines MII nor RMII. > > Yeah, see how the meaning is interpreted differently by each controller driver? CONFIG_RMII and CONFIG_MII make about as much sense as Wookies on Endor. It would be better to have: CONFIG_MACB_MODE_MII and CONFIG_MACB_MODE_RMII etc. Add multiple interfaces with different connections (e.g. controller 1 is connected MII and controller 2 is RMII) and then what? Something else I've noticed: Almost everywhere that CONFIG_MII is tested, it's done like this: #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) Looks like maybe something's not needed... Anyway, the entire Ethernet driver structure is ripe for a refactoring, to use a cheesy software engineering term. Since it's becoming very common to have more than one Ethernet controller on a board, I think we need to move more toward defining features on a per-port basis. > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > regards, Ben