RE: [PATCH] ucc_geth.c, make PHY device optional.
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
RE: [PATCH] ucc_geth.c, make PHY device optional.
{snip}
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
How about separate autoneg to a property dumb-phy, which indicates the
PHY/switch doesn't provide MII register interface. Therefore, it should
use the fixed speed and duplex from device node rather than registers.
- Leo
-
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
Re: [PATCH] ucc_geth.c, make PHY device optional.
How about separate autoneg to a property dumb-phy, which indicates the PHY/switch doesn't provide MII register interface. Something like that I suppose. But don't call it dumb phy, nor fake phy, nor anything similar -- there simply is _no_ phy. If the Linux code wants to pretend there is one, that's one thing, but there is no need to do any of this trickery in the device tree. Therefore, it should use the fixed speed and duplex from device node rather than registers. Yes. Segher - 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
Re: [PATCH] ucc_geth.c, make PHY device optional.
On Wed, 2007-07-04 at 15:32 +0200, Segher Boessenkool wrote: How about separate autoneg to a property dumb-phy, which indicates the PHY/switch doesn't provide MII register interface. Something like that I suppose. But don't call it dumb phy, nor fake phy, nor anything similar -- there simply is _no_ phy. If the Linux code wants to pretend there is one, that's one thing, but there is no need to do any of this trickery in the device tree. Therefore, it should use the fixed speed and duplex from device node rather than registers. Yes. Not sure I follow, something like this? initial-phy-capacity = speed duplex no-mdio-interface autoneg does not fit in there. 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
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? Perhaps this should live in BSP code instead? 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
RE: [PATCH] ucc_geth.c, make PHY device optional.
-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 - 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
