Steven Stallion wrote:
>> Steven Stallion writes:
>>
>>>> Right, see
>>>> http://gdamore.blogspot.com/2008/08/why-you-dont-want-to-force-link-modes.html
>>>> for my most recent rant on this particular topic.
>>>>
>>> I'm suddenly reminded of hours spent in the lab years ago trying to get
>>> a
>>> PIX and ProCurve to play nice...
>>>
>>> It really sounds like this behavior could be abstracted out and placed
>>> into a capability. Essentially all you would really need is a couple of
>>> utility functions to simplify exposing a set of adv_ props, and to read
>>> (in order of 802.3 precedence) a set of config modes.
>>>
>> I'm not sure what "capability" means here, but I do agree with you
>> that having an analysis tool that reads the various stable
>> configuration and status bits and produces a human-ready report (along
>> with a diagnosis) would be extremely useful -- and not terribly hard
>> to write.
>>
>> This is something that's been discussed more than once ...
>>
>
> A Nemo/GLDv3 capability (i.e. MAC_CAPAB_ADV or somesuch).
>
> Essentially a driver which wants to use this cap would register a couple
> of callbacks so Nemo could request what the device will advertise and
> provide a utility function or two for getting any en_ modes which have
> been set by the user.
>
> As far as stable status bits, this pretty well limits the cap to devices
> which support MII/GMII/XGMII xcvrs.
>
> Right now, I am also working on adding 802.3 MII/GMII support as a
> capability to Nemo; this just seemed to be another cap that could be added
> (pretty simply actually) which would life a little easier for driver
> dev's.
>
Actually, the current approach, where MII bits are expressed directly,
is pretty simple for most devices. The reason for this is that most
devices (at least modern ones) actually expose MII registers directly to
the driver, and so there is a one-to-one correspondence between what
gets requested and what gets set. Trying to abstract this further would
actually make *more* work for such drivers.
Now there are *some* devices (some dnet variants using SYM are good
examples... mxfe has the same problem) where the MII registers are *not*
exposed, but abstracted somehow. This is mostly older devices, designed
before 802.3u was ratified, and they have more work to do. I'd rather
leave the work for those devices, and keep the more modern ones simple.
-- Garrett
>
>
_______________________________________________
networking-discuss mailing list
[email protected]
