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
