linux-kernel - Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions)

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]

Message-ID: <f73f7ab80904171732n41832d0hc62978e57bbcc32e@mail.gmail.com>
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/