Start fleshing out the NVRAM  handling side of things.

The NVRAM data here is:

* 7260 specific at the moment, since the openbsd driver is
  7260 specific.  Sigh.
* Doesn't go direct to the NIC to read the NVRAM - it instead
  sends commands to the firmware to fetch NVRAM sections.

So this requires the whole command submission/completion path
to actually work and work right.  Since right now I've only half
implemented it (we can send commands, but we fail to sleep until
they're done) then the kernel panics.

The kernel is panicing at this point because the completion
interrupt actually fires during attach but we're currently
shutting down things.

I've started trying to address this.  Adding an sc_inactive
variable to the iwa_softc isn't enough - unfortunately
there's still issues with things being freed whilst the shutdown
path is being called.

So, I need to figure out what's going on here..
Disable the interrupt path by setting sc_inactive=1 if iwa_attach()
fails.

Do this in the lock so the interrupt path - that also grabs the lock -
will see this as failed and abort early.

This prevents a panic during attach failure - the intr code still
tries to handle an interrupt and although the USE_ICT flag is 1,
the ict data area is NULL.
* Fix the firmware command response check to be correct;
* Call iwn_cmd_done() to complete a command.

The sleeping command isn't waking up yet; I need to figure that
particular bit out.
Re-implement the command wakeup bits.

This mirrors what's done in if_iwn - it sleeps on the descriptor
ring slot and will wake up when it's done.

This does time out after 5 seconds, rather than sleeping forever.
But it doesn't really know (yet) if the hardware has gone away
or the NIC was reset.  I'm going to have to handle that particular
gem later on, once all of this mess is finshed.

Next up - figuring out how to get the command response back
to the original caller, and then making sure everything is
freed correctly once it's done.
Ok, this is a mostly-comment commit, but I think it's worth
describing what I've found in the driver(s) here.

The linux driver implements a blocking / synchronous command
interface as well as a way to get the reply data linked back
to the command that expects it.

However, it does some shady looking page stealing tricks behind
the scenes if the command indicated it wants the response
(WANT_SKB.)  This both means "I want the response data" and
"I'm going to be responsible for freeing it."

So, there seems to be some shady looking response path that is
moving the reply page(s) to the caller and, although I haven't found
it yet, it's replenishing them with new ones.

So the caller gets the buffers for the response.  It doesn't allocate
space to copy the response into - it just gets said response buffers.

The linux driver implements iwl_free_resp() as "free the underlying
pages that we stole back to the kernel."

The openbsd driver doesn't do this.  It's doing both a global
"want response" sleep/turnstile and it's also doing a per-descriptor
sleep for the response.  The global "want response" turnstile looks
like it's supposed to handle waiting for the response to complete -
it then will wakeup whatever's waiting for that.  But it's only doing
the sleep in iwm_send_cmd() - I don't really understand how the
receive / interrupt path is protected from concurrent packets being
received and churned through the ring whilst some thread is waiting
for the response wakeup so it can do its own thing.  the only thing
this is preventing is a second command coming along and wanting
a response - but I bet high enough data packet rates could cause
an overflow.

So, ugh.  I have to figure out what I'm going to do for the
FreeBSD version of this, as everything is SMP'-y and it's quite
possible we'll have this mess running concurrent at some point.

The cheat way is to allocate a new mbuf for that ring slot and
"gift" the mbuf to the transmit slot.  Then the response would
really just be an mbuf that's being freed in iwa_free_resp().
However, this means I'm going to be refilling mbufs in the
interrupt routine /and/ I have to hack up the iwl driver to
keep the mbuf pointer around as well as the iwl_rx_packet
reference (which is to the mbuf payload, not the mbuf itself.)

The cleaner, less efficient and more work way is to for now
require command responses to be copied into a buffer that the caller
allocates.  Commands won't happen anywhere near as often as
received packets, so we may as well just copy the frame out
and immediately release the mbuf back to the caller.  This requires
that I change all the routines to supply an actual response
buffer.

However it may not be that bad - I think once I implement the
actual RX packet path I'll end up recycling RX buffers and mbufs
anyway as that's what happens when RX slots get handed up to
the net80211 input side.  So, maybe I should just bite the
bullet and "steal" the mbuf away here.

Grr. Just, grr.

I should also have some value that gets set (or maybe just
a NULL pointer) if we fail to get the buffer during a command
response.  eg, if we try to allocate an mbuf to replace the
command slot with and we fail to do so.  I don't know what
the NIC will do if rx buffer slots are NULL.

Grrrr....
Start fleshing out a TODO list.
Implement a notification path back from the RX path through
to the TX command slot back to the original iwl_host_cmd that
initiated the command.

This is like Linux - there's a backpointer ("meta") that lets
the iwlwifi/trans code notify the original iwl_host_cmd of
the receive buffer with the contents its after.

This seems to work enough to not crash but I have no idea yet
whether the data that is showing up is correct.  It's certainly
failing the NVM read check.
Ah - this particular knob controls whether the RX buffers are 2k or 4k.
Add debugging!
.. add more debugging related to bringing up the PHY config.
Dump command contents out when sending.
* Use the config eeprom size, rather than a hard-coded value
* Add more debugging
Fix attach/detach/reattach.

* set inactive when attaching; clear when it's being setup and
  set it again upon error.

* Allocate the lock early.
Correct the le*_cpup() macros.

This makes the NVRAM read work!