re-add missing multicast check, thanks bz!

fix the seqno update routines to wrap things appropriately.
This bit me when doing some work on if_rsu

Address bz's comment - yup, this works with seqno offload and
with it just not populated in the driver encap path. Neat!

I assume it just works fine? :-)

Note: my hope is to eventually delete the TX lock entirely; this sets the ground work to first experiment and test various drivers in this stack.

migrate prefix to net80211_

rename prefix to net80211_

use net80211_ prefix

update commit message (locally)

In D50642#1156201, @bz wrote:

So i was thinking if we can start using ieee80211 for standards things and use a net80211 prefix for our own stuff (at least for anything new or we change)?

In D50638#1156017, @bz wrote:

Need to check all the other places which may have changed implicit behaviour too and they all need the same comment,

update from bz; matches what's in CCMP

I think this looks fine. I'm personally not too worried about breaking things in ipfw to make them much cleaner/clearer/less error prone, as long as we document it in UPDATING.

tested on my MSI GE76 raider that was exhibiting this w/ firefox/pulseaudio; it no longer happens. Thanks!

It's better than the status quo in -HEAD, so let's get it in and then churn some more on making it recover better!

technically (cry) ucast will eventually be keyix 0 and keyix 1, but not the WEP/global slots. Aiee. :-)

This doesn't apply cleanly on -head, it requires D49827 first

I'm finally updating my GE76 w/ AX210 to test iwx and iwlwifi in -head out, so I'll have to apply this to actually get it to pass a suspend/resume pass. stay tuned!

I'm still not a big fan of putting the strings in the kernel syscall ABI (as i guarantee someone's gonna end up writing stuff that depends upon the content of the strings!), but I /am/ a fan of how the kernel source is being updated with errors. We can at least grep for the macro use to see what they're doing, and they're a no-op if it's not compiled in.

In D50386#1153172, @markj wrote:

In D50386#1152459, @adrian wrote:

In D50386#1152342, @christos wrote:

The bug D50488 solves could be a reason why the callout was being rescheduled.

It could be, but I still think it's worth being more defensive in making sure we clean things up / stop things right.

Again, the change in the patch introduces a new bug: if callout_stop() returns 0, then the callout thread is blocked on the softc lock, which means that it's waiting for the callout_stop() caller to release the lock, which means that the loop while (callout_stop(&sc->callout) == 0) ; never terminates.

comments from bz

comments from bz

In D49419#1147670, @bz wrote:

Sorry I don't know; this window came up in a restored browser session; I thought I had submitted this ages ago.

In D50128#1152638, @kgalazka wrote:

I would assume if you hold the fw semaphore you'd have exclusive access to the adapter..

I don't know how I missed that while reading the datasheets, but there are two registers used for SW/FW synchronization. IXGBE_SWSM is used to ensure that only one SW thread is accessing HW. I'm sorry for misleading you.

We /may/ need to move the child bus attach stuff to a new iflib routine that's documented to being called without the ctx lock held?

Because @kbowling is right about the semaphore I think we don't need to use a iflib CTX lock for MDIO read operation. For writes I think CTX lock is still required. Some operations on PHY use read/modify/write pattern (e.g. ixgbe_init_ext_t_x550em). Without CTX lock write from MDIO bus may get between that read and write.

Regarding E610 - it does have IXGBE_MSCA register, but it's strongly advised to use ACI commands for PHY access instead. It may be better idea to not add independent interface but set phy->ops.read_reg_mdi and phy->ops.write_reg_mdi for X553 backplane and rely on phy.ops.read_reg and phy.ops.write_reg to do the right thing for given HW.

In D50386#1152342, @christos wrote:

The bug D50488 solves could be a reason why the callout was being rescheduled.

So this panics the kernel if e6000sw is built in or loaded at boot time.