Hi Guennadi,
Guennadi Liakhovetski wrote:
Hi,
- 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.
- 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.
- 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.
- 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