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

lists.openwall.net		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 linux-cve-announce 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 19:38:00 +0800
From:	"Li Yang-r58472" <LeoLi@...escale.com>
To:	<joakim.tjernlund@...nsmode.se>
Cc:	"linuxppc-dev Development" <linuxppc-dev@...abs.org>,
	"Netdev" <netdev@...r.kernel.org>,
	"Fleming Andy-afleming" <afleming@...escale.com>
Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.

> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@...nsmode.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@...nsmode.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@...r.kernel.org
> > > > [mailto:netdev-owner@...r.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@...nsmode.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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html