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, 03 Jul 2007 09:20:46 +0200
From:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
To:	Li Yang-r58472 <LeoLi@...escale.com>
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.

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.

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