-----Original Message-----
From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
Sent: Tuesday, July 03, 2007 7:20 PM
To: Li Yang-r58472
Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.

On Tue, 2007-07-03 at 16:22 +0800, Li Yang-r58472 wrote:

quoted

quoted

-----Original Message-----
From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
Sent: Tuesday, July 03, 2007 3:21 PM
To: Li Yang-r58472
Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.

On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:

quoted

quoted

-----Original Message-----
From: netdev-owner@vger.kernel.org

[mailto:netdev-owner@vger.kernel.org] On

quoted

Behalf Of Joakim Tjernlund
Sent: Tuesday, July 03, 2007 8:52 AM
To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
Subject: [PATCH] ucc_geth.c, make PHY device optional.

quoted

This patch makes the PHY optional for ucc_geth.c ethernet

driver.

quoted

quoted

quoted

quoted

This is useful to support a direct mii to mii connection to,

for

quoted

quoted

quoted

example,

quoted

quoted

a onboard swicth.

Signed-off-by: Joakim Tjernlund

[off-list ref]

quoted

quoted

quoted

quoted

----

Hi Joakim,

I'm wondering if we really need to have the option to disable

phylib.

quoted

maybe, but it has to be dynamic too. I need to use PHY on UCC2 and

mii

quoted

quoted

on UCC3 and UCC4.

quoted

Actually we have made phylib selected by default for ucc_geth.

Many

quoted

L2

quoted

quoted

switch chips have the capacity to be controlled.  Therefore they

can

quoted

be

quoted

quoted

managed as a phy device.

Yes, they can be but why force a PHY impl. when its is of no use?

The

quoted

quoted

only thing the eth driver needs from the it is speed and duplex.

If

quoted

quoted

these are fixed, you don't need to talk with a PHY.

The driver needs to get and set the link speed/status on runtime

(such

quoted

as for ethtool interface).  Currently this is implementation through
phydev interface.  IMHO, it will be easier to maintain if we only

use

quoted

this standard interface, rather than use different interfaces for
different cases.

hmm maybe, but there is no need to much around with speed/status
from user space. The speed and duplex must be set before user space
is up.

quoted

quoted

quoted

For the MII interface which is not
configurable, shouldn't we use the fixed phy support from

Vitaly?

quoted

quoted

Well, I think the the fixed phy is great when your eth driver

requires

quoted

a

quoted

PHY, but it is a workaround with extra processing overhead. IMHO

the

quoted

quoted

best impl. is to make the PHY optional in the eth driver and as

you

quoted

can

quoted

see from the patch, that was really simple.

I agree there is overhead. However, it will have the advantage of
abstracting all the PHY related stuff out of controller driver.

quoted

An useful extension would be to add a new propety in the DTS to

hold

quoted

quoted

initial speed and duplex(perhaps extend phy-connection-type). This
would be useful for the fixed driver too as one could derive speed

and

quoted

quoted

duplex for the fixed phy from that property instead of creating a

fixed

quoted

phy for each speed and duplex one want to support.

I agree that there should be a device node to configure it.  The

current

quoted

fixed phy driver is a little bit too complex to emulate the register
access.  Maybe it's better to have a null phy driver which just

reads

quoted

PHY capacity and status from device node.

A null phy driver is better than the current fixed phy, I agree.
Where would you like to put initial speed and duplex? In a fake phy

node

or in the ethernet node?

I think a fake phy node is better.

- Leo