[PATCH] ucc_geth.c, make PHY device optional.

[PATCH] ucc_geth.c, make PHY device optional.

[Joakim Tjernlund]

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 <joakim.tjernlund@transmode.se>
----
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 32bb748..8630294 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2273,7 +2273,8 @@ static void ucc_geth_stop(struct ucc_geth_private *ugeth)
 	ugeth_disable(ugeth, COMM_DIR_RX_AND_TX);
 
 	/* Tell the kernel the link is down */
-	phy_stop(phydev);
+	if (phydev)
+		phy_stop(phydev);
 
 	/* Mask all interrupts */
 	out_be32(ugeth->uccf->p_ucce, 0x00000000);
@@ -3687,14 +3688,16 @@ static int ucc_geth_open(struct net_device *dev)
 				   dev->dev_addr[5],
 				   &ugeth->ug_regs->macstnaddr1,
 				   &ugeth->ug_regs->macstnaddr2);
-
-	err = init_phy(dev);
+	err = 0;
+	if (ugeth->ug_info->mdio_bus != ~0)
+		err = init_phy(dev);
 	if (err) {
 		ugeth_err("%s: Cannot initialize PHY, aborting.", dev->name);
 		return err;
 	}
 
-	phy_start(ugeth->phydev);
+	if (ugeth->phydev)
+		phy_start(ugeth->phydev);
 
 	err =
 	    request_irq(ugeth->ug_info->uf_info.irq, ucc_geth_irq_handler, 0,
@@ -3726,8 +3729,9 @@ static int ucc_geth_close(struct net_device *dev)
 	ugeth_vdbg("%s: IN", __FUNCTION__);
 
 	ucc_geth_stop(ugeth);
-
-	phy_disconnect(ugeth->phydev);
+	
+	if (ugeth->phydev)
+		phy_disconnect(ugeth->phydev);
 	ugeth->phydev = NULL;
 
 	netif_stop_queue(dev);
@@ -3807,17 +3811,16 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
 	ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
 
 	ph = of_get_property(np, "phy-handle", NULL);
-	phy = of_find_node_by_phandle(*ph);
-
-	if (phy == NULL)
-		return -ENODEV;
-
-	/* set the PHY address */
-	prop = of_get_property(phy, "reg", NULL);
-	if (prop == NULL)
-		return -1;
-	ug_info->phy_address = *prop;
-
+	if (ph != NULL) {
+		phy = of_find_node_by_phandle(*ph);
+		if (phy == NULL)
+			return -ENODEV;
+		/* set the PHY address */
+		prop = of_get_property(phy, "reg", NULL);
+		if (prop == NULL)
+			return -1;
+		ug_info->phy_address = *prop;
+	}
 	/* get the phy interface type, or default to MII */
 	prop = of_get_property(np, "phy-connection-type", NULL);
 	if (!prop) {
@@ -3857,19 +3860,22 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
 		ug_info->uf_info.utftt = UCC_GETH_UTFTT_GIGA_INIT;
 	}
 
-	/* Set the bus id */
-	mdio = of_get_parent(phy);
+	ug_info->mdio_bus = ~0; /* Means no MDIO bus */
+	if (ph) {
+		/* Set the bus id */
+		mdio = of_get_parent(phy);
 
-	if (mdio == NULL)
-		return -1;
+		if (mdio == NULL)
+			return -1;
 
-	err = of_address_to_resource(mdio, 0, &res);
-	of_node_put(mdio);
+		err = of_address_to_resource(mdio, 0, &res);
+		of_node_put(mdio);
 
-	if (err)
-		return -1;
+		if (err)
+			return -1;
 
-	ug_info->mdio_bus = res.start;
+		ug_info->mdio_bus = res.start;
+	}
 
 	printk(KERN_INFO "ucc_geth: UCC%1d at 0x%8x (irq = %d) \n",
 		ug_info->uf_info.ucc_num + 1, ug_info->uf_info.regs,

[PATCH] ucc_geth.c, make PHY device optional.

[Joakim Tjernlund]

> 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 <joakim.tjernlund@transmode.se>
----
[SNIP patch sent last Friday]

Since this is my last week before vacation, I would really like to
get feedback on this patch sooner than later :)

 Jocke

RE: [PATCH] ucc_geth.c, make PHY device optional.

[Li Yang-r58472]

> -----Original Message-----
> From: netdev-owner@vger.kernel.org
[mailto:netdev-owner@vger.kernel.org] 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.
>=20
> > 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 <joakim.tjernlund@transmode.se>
> ----
Hi Joakim,

I'm wondering if we really need to have the option to disable phylib.
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.  For the MII interface which is not
configurable, shouldn't we use the fixed phy support from Vitaly?

- Leo

RE: [PATCH] ucc_geth.c, make PHY device optional.

[Joakim Tjernlund]

On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org
> [mailto:netdev-owner@vger.kernel.org] 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 <joakim.tjernlund@transmode.se>
> > ----
> 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.

> 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.

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.

 Jocke

RE: [PATCH] ucc_geth.c, make PHY device optional.

[Li Yang-r58472]

> -----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.
>=20
> On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org
> > [mailto:netdev-owner@vger.kernel.org] 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 <joakim.tjernlund@transmode.se>
> > > ----
> > Hi Joakim,
> >
> > I'm wondering if we really need to have the option to disable
phylib.
>=20
> maybe, but it has to be dynamic too. I need to use PHY on UCC2 and mii
> on UCC3 and UCC4.
>=20
> > 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.
>=20
> 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.

>=20
> > For the MII interface which is not
> > configurable, shouldn't we use the fixed phy support from Vitaly?
>=20
> 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.

>=20
> 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.

- Leo

RE: [PATCH] ucc_geth.c, make PHY device optional.

[Joakim Tjernlund]

On Tue, 2007-07-03 at 16:22 +0800, Li Yang-r58472 wrote:
> > -----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:
> > > > -----Original Message-----
> > > > From: netdev-owner@vger.kernel.org
> > > [mailto:netdev-owner@vger.kernel.org] 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 <joakim.tjernlund@transmode.se>
> > > > ----
> > > 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

RE: [PATCH] ucc_geth.c, make PHY device optional.

[Li Yang-r58472]

> -----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.
>=20
> On Tue, 2007-07-03 at 16:22 +0800, Li Yang-r58472 wrote:
> > > -----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:
> > > > > -----Original Message-----
> > > > > From: netdev-owner@vger.kernel.org
> > > > [mailto:netdev-owner@vger.kernel.org] 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
<joakim.tjernlund@transmode.se>
> > > > > ----
> > > > 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.
>=20
> 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.
>=20
> >
> > >
> > > > 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.
>=20
> 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

RE: [PATCH] ucc_geth.c, make PHY device optional.

[Joakim Tjernlund]

On Tue, 2007-07-03 at 19:38 +0800, Li Yang-r58472 wrote:
> > -----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:
> > > > -----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:
> > > > > > -----Original Message-----
> > > > > > From: netdev-owner@vger.kernel.org
> > > > > [mailto:netdev-owner@vger.kernel.org] 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
> <joakim.tjernlund@transmode.se>
> > > > > > ----
> > > > > 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

RE: [PATCH] ucc_geth.c, make PHY device optional.

[Li Yang-r58472]

{snip}
>=20
> OK, but then a new property in PHY node is needed which holds
> the initial speed and duplex.
> initial-phy-capacity =3D <speed duplex> ?
> This should be useful for real PHYs too if, for instance, autoneg
isn't
> working/supported/wanted.
>=20
> Maybe it should be:
> initial-phy-capacity =3D <speed duplex autoneg>
> or
> initial-phy-capability =3D <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

Re: [PATCH] ucc_geth.c, make PHY device optional.

[Segher Boessenkool]

> 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

Re: [PATCH] ucc_geth.c, make PHY device optional.

[Joakim Tjernlund]

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