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-next>] [day] [month] [year] [list]
Date:	Tue, 10 Apr 2007 14:41:01 -0400
From:	David Hollis <>
Subject: phylib usage

I've been keeping an eye on PHYLIB since it's addition to the kernel
some time ago and I'm a bit curious as to why it doesn't seem to have
much up-take among other drivers.  A quick check of the kernel source
shows only two users (AU1000 and gianfar) and both look to be embedded
type devices.  Are there fundamental issues with PHYLIB that prevent it
from being more widely used?  Is it an element of "the driver ain't
broke, I'm not going to rework my PHY handling at this point"?  Is PHY
handling something that is just too difficult to fully abstract with
various specialty nics?

To semi-answer one of my own questions, I was hoping to use PHYLIB with
asix.c (a USB Ethernet driver) since the newer devices now have external
PHYs and it appears that there are quite a few different ones in use by
various OEMs but I found that the locking in use wasn't amenable to USB
operations, since USB calls can sleep.  This doesn't seem like an
insurmountable problem however.

The main reason I even ask is that it seems rather odd to have so many
drivers that seem to have the same PHY's and yet each driver has to deal
with various errata and quirks of the PHY.  Having it all abstracted
makes for one location to deal with things and everybody wins.

David Hollis <>

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