The IFSPEED() macro should probably be confined to the bowels of the
mac_ether.c implementation.
I'm a little confused though about mc_notify. Who calls this, and
when? I *suspect* that the role is reversed here, and rather than
mc_notify() being an entry point in the driver, its the other way
around, and the driver should call mii_notify() to make the framework
understand that a change has happened.
The other tidbit is that I'm not entirely sure that the drivers need to
have access to the mii_xxx functions directly. While they could be
useful, I think I see them being *more* useful to the framework itself.
To that end, it does also seem that the framework could do with knowing
that the part is an MII based device, and hence provide mii-equivalents
for some of the functionality that currently exists in device drivers
directly. (I'm thinking for things like mac_stat() and the Brussels
property interfaces.)
-- Garrett
Steven Stallion wrote:
> (Cross posted to networking-discuss for notification only; I'm
> anticipating most of the discussion will take place in driver-discuss)
>
> All,
>
> I've roughed out an interface for providing generic MII/GMII support in
> mac_ether (Garrett D'Amore mentioned this may make a worthwhile
> modification).
>
> I tried to keep these changes in the same spirit of GLDv3. It is
> intended that mac_ether will be responsible for GLDv3 link notification
> and kstats.
>
> A webrev is available here:
> http://cr.opensolaris.org/~stallion/mac_ether/latest/
>
> A quick explanation of changes:
>
> mac.h
> -----
>
> I added an enum for link_speed_t; this was made since we already
> maintain the link_duplex_t and link_state_t. link_speed_t is very useful
> when setting a specific speed via MII.
>
> The IFSPEED macro was added as an afterthought; I find it generally
> annoying that the ifspeed kstat typically is reported using a magic
> multiple (1000000). *val = IFSPEED(foop->speed) is much clearer than
> *val = foop->speed * 1000000.
>
> mac_ether.h
> -----------
>
> This contains the bulk of the changes. I've added what I thought the
> minimal MII/GMII interface should be. There are of course a number of
> features supported by MII which probably arent useful in the day-to-day
> (i.e. collision test, loopback, and so forth).
>
> Thoughts?
>
>
_______________________________________________
networking-discuss mailing list
[email protected]
