netdev - Re: phylib usage

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] [day] [month] [year] [list]

Message-id: <1176498990.3567.5.camel@dhollis-lnx.sunera.com>
Date:	Fri, 13 Apr 2007 17:16:30 -0400
From:	David Hollis <dhollis@...ehollis.com>
To:	Andy Fleming <afleming@...escale.com>
Cc:	Kim Phillips <kim.phillips@...escale.com>,
	Lennert Buytenhek <buytenh@...tstofly.org>,
	netdev@...r.kernel.org
Subject: Re: phylib usage

On Fri, 2007-04-13 at 13:00 -0500, Andy Fleming wrote:

> 
> >
> > Or are there too many cases where NIC x needs to do these fiddlings  
> > with
> > PHY y, where as NIC z has to do different fiddlings with PHY y?
> 
> 
> I worry about this point, but I believe that a proper abstraction  
> must be possible.  In almost every case, the PHY is a separate  
> device, which I have to think means that it can have its own driver,  
> decoupled from the ethernet driver.
> 

Yeah, it would be the biggest sticking point.  I'm curious as to whether
it is an actual issue, or more of a "I do it this way and it works, but
the phylib driver does it a different way and I don't like that" or some
such nonsense.

> >
> > Again, I don't have a lot of experience with Ethernet devices but in
> > looking at a lot of the different driver code, it looks like they all
> > fiddle with the PHYs in basically the same way, though some drivers do
> > more, some less.  Most likely due to lack of access to errata and such
> > or issues just not cropping up that need to be fixed.
> 
> 
> I agree.  I've been a little disheartened to see all the patches that  
> have come through to fix bugs in the PHY-handling code of various  
> ethernet drivers.  It would be great if that code could all get  
> collected into the PHY lib.  Then we'd only have to fix the bug once,  
> rather than once for every ethernet driver that uses that particular  
> PHY.
> 

Absolutely.  What really got me interested when phylib came around is
that the Ax88178 GBE device uses an external phy and the sample code I
received from ASIX had support for all different kinds of phy's (all of
which happen to be in phylib at the moment) but the code was atrocious.
Totally unmanageable, undocumented, you just couldn't tell what it was
doing.  I love the idea of having the device use phylib so I don't even
have to care what kind of phy may get hooked onto the device by an OEM.
As long as phylib has a driver, it just works.  I always like the idea
of passing off the handling of something to someone else so it's less
for me to be concerned with (heck, asix.c already piggy backs all over
usbnet.c so all that the driver is really doing is the setup and device
specific management, all other bits are handled in usbnet)

> If anyone has looked at porting an ethernet driver to the PHY lib,  
> and found it lacks a necessary feature, I'd love to hear about those  
> experiences.  The locking issue is a big one, but I, too, think that  
> it should be fairly straightforward to work around.
> 

Locking is the biggest sticking point for me.  The only other issue I
see is the string for the bus name (doesn't it turn out like phy0:0 or
something, it's been awhile).  I don't seem to have a way to map back to
what it turns in to, or I haven't figured out a way yet.  Nothing
insurmountable.

-- 
David Hollis <dhollis@...ehollis.com>

-
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