present changes:
- Make Yukon-2 FE+ (88E8040, 88E8042) work
- 88E8057 is a Yukon 2 Ultra 2, and this might make it work on a little
shiny green box in Japan
- Prevent null pointer dereference that could happen when we process an RX
interrupt that was queued while stopping the interface.
- Remove holdover XMAC II writes/reads inherited from sk as
they aren't required and cause problems like the 88E8072
hard locking a system when enabling macsec bypass.
- Bypass macsec on extreme/supreme based chips.
Makes my 88E8072 work.
- Add detach support to a few more drivers, and in others do the neccessary
operations in the detach function in the right order.
towards resolution of PR kern/53301 but will need more work
tested by John Halfpenny on another 8040/Yukon-2 FE+ and reported
improving behaviour (system hang to stall) so committing as stopgap; also
tested on my SK-9E22 (Yukon-2 XL), there works without any issues both before
and after
the extra bytes. The PCB embeds the biggest static FPU state, but our
real FPU state may be smaller (FNSAVE), so we don't need to memcpy the
extra unused bytes.
This just moves the timer-arming logic from xen_initclocks into
xen_resumeclocks so that it runs on resume too.
I hypothesize that this is necessary for Xen to resume. Otherwise,
how could the one-shot timer possibly by rearmed? On the other hand,
it is conceivable that something automatically rearms it.
This also reorders the initialization so that we establish a timer
interrupt handler first, and _then_ arm the timer. If the order
matters, it is hard to imagine that the other way is correct:
conceivably, the interrupt could arrive before we've established the
handler, and then there's nothing to rearm it.
Whether this is _sufficient_ for Xen to resume, I don't know.
Symptoms recently reported in
<https://mail-index.netbsd.org/port-xen/2018/06/15/msg009207.html>
look different from how I would expect this to manifest, which is as
a system wedged because there's no no hardclock activity.
ok cherry
Compile-tested only -- kernel still runs but I haven't exercised this
code path.
By code inspection, this change or something like it is obviously
_necessary_ for Xen MP suspend/resume -- otherwise there's no logic
to suspend/resume the clocks on any CPU except the one that actually
triggers sysctl -w machdep.xen.suspend=1.
Whether this change is _sufficient_ for Xen MP suspend/resume to
work, I don't know.
ok cherry
instead of just the current pass. Fixes an issue where a driver with a
lower match number and early pass number will attach instead of a better
match on a later pass.
jdolecek