[U-Boot-Users] MII / RMII

[Ben Warren <bwarren@qstreams.com>]

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