freebsd-dev/sys/dev/dc
Pyun YongHyeon d7e9ac7523 When driver is run for the first time there would be no established
link such that calling dc_setcfg() right after media change would
be meaningless unless controller in question is not Davicom DM9102.
Ideally dc_setcfg() should be called when speed/duplex is resolved
otherwise it would reprogram controller with wrong speed/duplex
information.  Because MII status change callback already calls
dc_setcfg() I think calling dc_setcfg() in dc_init_locked() is
wrong.  For instance, it would take some time to establish a link
after mii_mediachg(), so blindly calling dc_setcfg() right after
mii_mediachg() will always yield wrong media configuration.

Extend dc_ifmedia_upd() to handle media change and still allow
21143 and Davidcom controllers program speed/duplex regardless of
current resolved speed/duplex of link. In theory 21143 may not need
to call dc_setcfg() right after media change, but leave it as it is
because there are too many variants to test that change.  Probably
dc(4) shall need a PHY reset in dc_ifmedia_upd() but it's hard to
verify correctness of the change.

This change reliably makes ULi M5263 establish a link.

While I'm here correctly report media change result. Previously it
always reported a success.
2011-10-24 20:26:37 +00:00
..
dcphy.c Remove duplicate header includes 2011-06-28 08:36:48 +00:00
if_dc.c When driver is run for the first time there would be no established 2011-10-24 20:26:37 +00:00
if_dcreg.h s/u_intXX_t/uintXX_t/g 2011-02-19 03:32:10 +00:00
pnphy.c Remove duplicate header includes 2011-06-28 08:36:48 +00:00