[EMAIL PROTECTED] wrote:
On (06/18/07 13:06), [EMAIL PROTECTED] wrote:
The very idea of directly setting the link-speed and link-duplex is one
that I'm uncomfortable with. This hides important details, such as
whether the mode is forced, or is it an 802.3u negotiated speed?
I'm sure that solving this is just a simple matter of code...
To some extent. And to some extent it is the user-interface we
want to present via dladm. The ieee802.3(5) definition enumerates all the
(speed, duplex) possibilities for MII, e.g., 1000fdx, 1000hdx, 100fdx,
100hdx etc. otoh, on a laptop with functionial wifi, I get,
among other things:
LINK PROPERTY VALUE DEFAULT POSSIBLE
:
wpi0 speed 54 --
1,2,5.5,6,9,11,12,18,24,36,48,54
I'm not sure which is preferable, but, since some interfaces like
bge (rightly or wrongly) have the concept of "transfer-speed" as a
driver.conf property, I chose to separate speed and duplex.
Let me ask the question another way: by setting speed and duplex separately,
is it actually possible to hit a permutation that would not happen
with the predefined <speed>{f,h}dx definition?
Setting the speed/duplex directly is not a good idea for ethernet
(802.3). Instead one should really configure autonegotiation
parameters. I'd far far rather that the speed/duplex properties only be
observable.
For 802.11, the speed is something that needs to be allowed to adjust
dynamically. Some chipsets allow the driver to limit the maximum or
minimum speeds, but generally adjusting the link speed due to
environmental conditions is something that chipset should be allowed to
do. Hence, for 802.11, its also a bad idea to set "speed". (Instead,
the "operating mode", such as a, b, g, turbo-g, turbo-a, etc. should be
selected.)
Please, lets stay away from directly setting "speed", or "duplex" !
-- Garrett
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
