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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 17 Apr 2009 20:32:42 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	netdev <netdev@...r.kernel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Porting the ibm_newemac driver to use phylib (and other PHY/MAC 
	questions)

Hello,

I'm currently fiddling with a custom embedded prototype board using
the ibm_newemac driver with some currently-unsupported PHYs.  Those
PHYs *are* supported by phylib, but the emac driver seems to have its
own PHY layer cribbed from the sungem driver.  I'm curious if there's
some particular reason it hasn't been ported (aside from "nobody has
bothered yet").

I've temporarily hacked a PHY driver together for the moment, but it
would be much easier for us to maintain and update our board if the
PHY drivers were integrated.  As a result I'm also interested in how
complicated it might be to port the driver (and possibly sungem as
well) over to phylib, if that is indeed feasible.  Also, if I end up
going that route, are there others available with other hardware
variants who would be willing to test my patches on their boards?

As an aside, would there be any interest in adding an ethtool option
to enable the features of many PHYs which allow them to transmit data
even if their receive port has no link (specifically fiber cards, but
a few copper cards can do something similar).  From a cursory glance,
a third "duplex" configuration option would seem to make the most
sense from an end-user point of view.  Specifically, the existing
options are "full" (simultaneous transmit/receive), "half"
(time-multiplexed transmit/receive).  Perhaps a "tx" or "tx-only"
option would be sensible?  Now, the receiving card probably doesn't
need an "rx-only" mode as "full" should do that just fine; though
perhaps some cards with unidirectional-link-detection would use
"rx-only" to intentionally disable that support.  Once an extra couple
constants are added to linux/ethtool.h and the appropriate config
options added to ethtool, it should just be up to the drivers to
detect and handle those config options, no?

Comments and suggestions much appreciated.

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists