lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 3 Jul 2007 16:22:55 +0800
From:	"Li Yang-r58472" <>
To:	<>
Cc:	"linuxppc-dev Development" <>,
	"Netdev" <>,
	"Fleming Andy-afleming" <>
Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.

> -----Original Message-----
> From: Joakim Tjernlund []
> 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:
> > [] 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
> > > > This is useful to support a direct mii to mii connection to, for
> > example,
> > > > a onboard swicth.
> > > >
> > > > Signed-off-by: Joakim Tjernlund <>
> > > ----
> > Hi Joakim,
> >
> > I'm wondering if we really need to have the option to disable
> 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
> > switch chips have the capacity to be controlled.  Therefore they can
> > 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.

> > 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
> 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
> 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
> 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
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists