[RFC] Patch to Abstract Ethernet PHY support (using driver model)

[Eugene Surovegin]

On Fri, Jan 14, 2005 at 03:55:18PM +0100, J?rn Engel wrote:
> Wrt. the proposed PHY lib, I agree.  Didn't even bother to look at the
> code, it's mere size said enough.
> 
> But an abstraction different from drivers/net/mii.c is needed to
> handle the 5325 chip.  Or, you could have the special cases all over
> in your code, but that's a) ugly and b) more code.  I used to have
> such a mess and after doing the proper abstraction, it line count went
> down.

Well, I still fail to see what is so _special_ about this chip that it 
needs "proper abstraction". Could you elaborate, please?

The way I handled this in my drivers was clean and simple - 
"there-is-no-PHY". And this wasn't in any case chip-specific and was 
set up through OCP in board support code. So I'm kinda puzzled what 
"ugliness and more code" you are talking about.

We can also make a fake PHY which will always indicate link, will have 
fixed speed/duplex capabilities and will not support autoneg. If you 
think this is more elegant, OK, I might even agree with you :).

Please, note that wrt current discussion we are interested only in CPU 
port, not other 5 ports which aren't connected to the CPU at all. This 
is completely different stuff and yes, if we want to expose them in 
some way we need another abstraction. But abstraction of switch chips 
is a big and complex thing - they are very different, and frankly this 
one you mentioned is quite "feature-challenged" and will not make 
a good "model" chip IMHO :).

--
Eugene