On Tue, 2007-07-03 at 19:38 +0800, Li Yang-r58472 wrote: > > -----Original Message----- > > From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] > > 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: > > > > -----Original Message----- > > > > From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] > > > > 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: > > > > > > -----Original Message----- > > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED] On > > > > > > 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. > > > > > > > > > > > > > This patch makes the PHY optional for ucc_geth.c ethernet > > > driver. > > > > > > > This is useful to support a direct mii to mii connection to, > for > > > > > example, > > > > > > > a onboard swicth. > > > > > > > > > > > > > > Signed-off-by: Joakim Tjernlund > <[EMAIL PROTECTED]> > > > > > > ---- > > > > > Hi Joakim, > > > > > > > > > > I'm wondering if we really need to have the option to disable > > > phylib. > > > > > > > > maybe, but it has to be dynamic too. I need to use PHY on UCC2 and > mii > > > > on UCC3 and UCC4. > > > > > > > > > Actually we have made phylib selected by default for ucc_geth. > Many > > > L2 > > > > > switch chips have the capacity to be controlled. Therefore they > can > > > be > > > > > managed as a phy device. > > > > > > > > Yes, they can be but why force a PHY impl. when its is of no use? > The > > > > only thing the eth driver needs from the it is speed and duplex. > If > > > > 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 > > > as for ethtool interface). Currently this is implementation through > > > phydev interface. IMHO, it will be easier to maintain if we only > use > > > 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. > > > > > > > > > > > > > > For the MII interface which is not > > > > > configurable, shouldn't we use the fixed phy support from > Vitaly? > > > > > > > > Well, I think the the fixed phy is great when your eth driver > requires > > > a > > > > PHY, but it is a workaround with extra processing overhead. IMHO > the > > > > best impl. is to make the PHY optional in the eth driver and as > you > > > can > > > > 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. > > > > > > > > > > > An useful extension would be to add a new propety in the DTS to > hold > > > > initial speed and duplex(perhaps extend phy-connection-type). This > > > > would be useful for the fixed driver too as one could derive speed > and > > > > duplex for the fixed phy from that property instead of creating a > > > fixed > > > > phy for each speed and duplex one want to support. > > > > > > I agree that there should be a device node to configure it. The > current > > > 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 > > > 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
OK, but then a new property in PHY node is needed which holds the initial speed and duplex. initial-phy-capacity = <speed duplex> ? This should be useful for real PHYs too if, for instance, autoneg isn't working/supported/wanted. Maybe it should be: initial-phy-capacity = <speed duplex autoneg> or initial-phy-capability = <speed duplex autoneg> Jocke - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
