In addition to the NOCOPY flag, add a DUP flag that
tells the transport to kmemdup() the buffer and free
it after the command completes.

Currently this is only supported for a single buffer
in a given command, but that could be extended if it
should be needed.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When tracing in iwlwifi, we get all data. Most of
the time, we don't need it, and it just takes up
a lot of extra space in the trace.

Make this optional by recording the data into two
separate trace events if it is needed. Without it,
record only the content of non-data and EAPOL TX
frames.

As a result, tracing without the data tracepoints
will record meta information including the 802.11
headers for all frames but will not record the
contents of data frames to reduce trace overhead.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When we kill the radio with the RF kill button we could access
the HW after having stopped the APM which would result in the
warning below.

The flow goes like this:
* RF kill
	iwlwifi notifies the stack which stops the driver
	fw sends CARD_STATE_NOTIFICATION
* iwl_trans_pcie_stop_device stops the APM
* the tasklet runs and calls to iwl_rx_handle
* iwl_rx_handle calls iwl_rx_queue_restock
* iwl_rx_queue_restock tries to access the HW...

[255908.543823] ------------[ cut here ]------------
[255908.543843] WARNING: at drivers/net/wireless/iwlwifi/iwl-io.c:150 iwl_grab_nic_access+0x79/0xb0 [iwlwifi]()
[255908.543849] Hardware name: Latitude E6410
[255908.543852] Timeout waiting for hardware access (CSR_GP_CNTRL 0x000003d8)
[255908.543856] Modules linked in: iwlmvm iwlwifi mac80211 [...]
[255908.543935] Pid: 0, comm: swapper Tainted: G        W   3.1.0 #1
[255908.543939] Call Trace:
[255908.543950]  [<c1046e42>] warn_slowpath_common+0x72/0xa0
[255908.543980]  [<c1046f13>] warn_slowpath_fmt+0x33/0x40
[255908.543992]  [<fa4bb3b9>] iwl_grab_nic_access+0x79/0xb0 [iwlwifi]
[255908.544004]  [<fa4bb9eb>] iwl_write_direct32+0x2b/0xa0 [iwlwifi]
[255908.544018]  [<fa4c0ff9>] iwl_rx_queue_update_write_ptr+0x89/0x1d0 [iwlwifi]
[255908.544054]  [<fa4c1250>] iwlagn_rx_queue_restock+0x110/0x140 [iwlwifi]
[255908.544067]  [<fa4c234d>] iwl_irq_tasklet+0x82d/0xf40 [iwlwifi]
[255908.544096]  [<c104e11e>] tasklet_action+0xbe/0x100
[255908.544102]  [<c104d91e>] __do_softirq+0xae/0x1f0
[255908.544227] ---[ end trace d150f49345d85009 ]---

Prevent this.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Remove outdated iwlagn prefix to a few functions and fix comments
that were not accurate.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

These stubs are from internal experimental code
and aren't needed in the driver in the kernel
so just remove them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

iwl_dbgfs_fh_reg_read() can cause crashes and/or
BUG_ON in slub because the ifdefs are wrong, the
code in iwl_dump_fh() should use DEBUGFS, not
DEBUG to protect the buffer writing code.

Also, while at it, clean up the arguments to the
function, some code and make it generally safer.

Cc: stable@vger.kernel.org
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Until now, the response handler of a Host Command got the
exact same pointer that was also given to the DMA engine.
We almost never need to the Host Command that was sent while
handling its response, but when we do need it, we see that
the command has been modified.

This mystery has been elucidated. The FH (our DMA engine)
writes its meta data on the buffer in the DRAM. Of course it
copies the buffer to the NIC first. This was known to happen
for Tx command, but as a matter of fact, it happens to all
TFD brought by the FH which doesn't care much about what it
brings from DRAM to internal SRAM.

So copy the Host Command to yet another buffer so that we
can properly pass the buffer that was sent originally to the
fw. Do that only if it was request by the user since very
few flows need to get the HCMD sent in the response handler.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no need to check trans for non-null
here as it has already been checked in the
caller. This fixes an smatch warning that we
check after having dereferenced it.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This variable was accessed without taking the lock.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Structure the code a bit more and move all PCIe code
including the hardware configuration files into a
PCIe specific subdirectory.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Mostly clean up indentation around parentheses
after if, function calls, etc. and also a few
unneeded line breaks and some other things.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The debug prints were wrong and buggy. The HW pointer wasn't printed
correctly, it was mixed up with the pointer to the rxbuf.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

By default, iwlwifi uses order-1 pages (8 KB) to store incoming frames,
but doesnt say so in skb->truesize.

This makes very possible to exhaust kernel memory since these skb evade
normal socket memory accounting.

As struct ieee80211_hdr is going to be pulled before calling IP stack,
there is no need to use dev_alloc_skb() to reserve NET_SKB_PAD bytes.
alloc_skb() is ok in this driver, allowing more tailroom.

Pull beginning of frame in skb header, in the hope we can reuse order-1
pages in the driver immediately for small frames and reduce their
truesize to the minimum (linear skbs)
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Neal Cardwell <ncardwell@google.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Having cmd[], meta[] and skbs[] as separate arrays
in the TX queue structure is cache inefficient as
we need the data for a given entry together.

To improve this, create an array with these three
members (allocate meta as part of that struct) so
we have the data we need together located together
improving cache footprint.

The downside is that we need to allocate a lot of
memory in one chunk, about 10KiB (on 64-bit) which
isn't very efficient.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Instead of using the shared area that we be killed.
Remove the pointer to config from shared since it is not
used any more.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The command strings are needed through the layers for
debug and error messages, but can differ with opmode.
As a result, we need to give the command names to the
transport layer as configuration.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The code has been changed, move the definitions to the proper file
being used by the code.
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The HCMD_ACTIVE bit is only used in trans.
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When WiMax takes over the RF, inform the op_mode.
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

That way it isn't needed in hw_params, which
is shared data. It also isn't really what we
should configure in the transport, that is
better just 4k/8k, so configure a bool and
derive the page order in the transport. This
also means the transport doesn't need access
to the module parameter any more.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move the POWER_PMI to the op_mode where it is changed.  The trans needs
to check it frequently, so shadow the status in the trans and update it
in trans when it infrequently changes.
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Error log reporting does not belong to the
transport layer, but to the op_mode loading
the ucode, as it is the entity which knows
about the ucode loaded, and what the error
information means.

Move device logging pointers from the
transport layer to op_mode.

With this change, transport layer only
reports an error to the op_mode, which will
figure out what to do with the error. This
causes the driver to now dump out error logs
when the command queue is stuck as well.

Also, move the debugfs entry for event logs
out of the transport layer and into op_mode.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

A whole bunch of messages, even some recent ones,
didn't include a trailing newline so add it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The flow handler (hardware) can put multiple
frames into a single RX buffer. To handle
this, walk the RX buffer and check if there
are multiple valid packets in it.

To let the upper layer handle this correctly
introduce rxb_offset() which is needed when
we pass pages to mac80211 -- we need to know
the offset into the page there.

Also change the page handling scheme to use
refcounting. Anyone who needs a page will
"steal" it, which marks it as having been
used & refcounts it. The RX handler then has
to free its own reference and must not reuse
the page.

Finally, do not set the bit asking the FH to
give us each packet in a single buffer. This
really enables the feature.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This wait queue really belongs to the transport
layer, as it is used for sending synchronous
commands to the HW.

However, only op_mode knows about errors and
exceptional conditions, so make this queue
accessible by the op_mode.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Mohammed Shafi ran into [1] the SEQ_RX_FRAME workaround
warning with a statistics notification, this means we
can't just remove it as we'd hoped.

Abstract it out so that the higher layer can configure
this as a kind of "filter" in the transport.

[1] http://mid.gmane.org/CAD2nsn1_DzbRHuSbS_1rFNzuux_9pW1-pABEasQ01_y7-ndO5w@mail.gmail.comReported-by: NMohammed Shafi <shafi.wireless@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

BIg portion of "iwlwifi: remove max_txq_num from hw_params" was
missing during merge, here is the fix for it.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The command queue number is required by the transport
layer, but it can be determined only by the op mode.
Move this parameter to the dvm op mode, and configure
the transport layer using an API.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Continue splitting the status bits between transport and op_mode.
All but a few are separated.
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If device is disabled by rfkill switch, do not enable all interrupts,
but only CSR_INT_BIT_RF_KILL to receive rfkill state change. Unblocking
other interrupts might cause problems, since driver can not be prepared
for receive them.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wmb(), rmb() are not needed when writel(), readl() are used as
accessors for MMIO. We use them indirectly via iowrite32(),
ioread32().

What is needed mmiowb(), for synchronizing writes coming from
different CPUs on PCIe bridge (see in patch comments). This
fortunately is not needed on x86, where mmiowb() is just
defined as compiler barrier. As iwlwifi devices are most likely
not used on anything other than x86, this is not so important
fix.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Before we write to the device registers always check if
iwl_grap_nic_access() was successful.

On the way change return type of grab_nic_access() to bool, and add
likely()/unlikely() statement.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All variables related to uCode loading (the
waitqueue and done indication) should be in
the PCI-E transport's private data as this
is transport specific. Move them there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The transport doesn't need to include iwl-core.h any more.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Tracing used the priv pointer as an identifier,
which has the problem that we don't have it in
all code, and also some people say no pointers
should be "leaked" to userspace.

Use the device name instead, it is more useful
anyway.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There's no need to copy shadow_reg_enable into
hw_params since it is a pure hardware parameter
that will never change, we can access it from
the config directly.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The transport layer should only check the
hardware RF kill status, not impose any
policy or reaction based on it, so move
that out of it into the op_mode.

For now keep the restriction on loading
firmware, that will have to be removed
later.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This file was recently introduced, but then
directly abused -- it contained private data
that shouldn't have been used by anything
but the implementation of firmware requests
and some very core code. Now that it is no
longer accessed by any code but the code in
iwl-drv.c, we can dissolve it.

Also rename the iwl_nic struct to iwl_drv to
better reflect where and how it is used.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Through the driver, struct iwl_fw will
store the firmware. Split this out into
a separate file, iwl-fw.h, and make all
other code use it. To do this, also move
the log pointers into it, and remove the
knowledge of "nic" from everything.

Now the op_mode has a fw pointer, and
(unfortunately) for now the shared data
also needs to keep one for the transport
to access dump the error log -- I think
that will move later.

Since I wanted to constify the firmware
pointers, some more changes were needed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>