Apart from DVM, all firmware uses the same base API, and there's
code outside iwlmvm that needs to interact with it. Reflect this
in the source better and reorganize the firmware API to a new
fw/api/ directory.

While at it, split the already pretty large fw-api.h file into a
number of smaller files, going from almost 3k lines in there to
a maximum number of lines less than 1k.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There's a lot of mvm code that really should be more generic
and part of the iwlwifi module. Start by making a place to
keep such code - in the new "fw" subdirectory - and already
move the firmware related header files there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case we need to move the scheduler write pointer by
steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck.
This leads to hardware error interrupts with status:
0x5A5A5A5A or alike.

In order to work around this, detect in the transport
layer that we are going to hit this case and tell iwlmvm
to increment the sequence number of the packets. This
allows to keep the requirement that the WiFi sequence
number is in sync with the index in the scheduler Tx queue
and it also allows to avoid the problematic sequence.
This means that from time to time, we will start a queue
from ssn + 1, but that shouldn't be a problem since we
don't switch to new queues for AMPDU now that we have
DQA which allows to keep the same queue while toggling
the AMPDU state.

This bug has been fixed on 9000 devices and up.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When toggling the RF-kill pin quickly in succession, the driver can
get rather confused because it might be in the process of shutting
down, expecting all commands to go through quickly due to rfkill,
but the transport already thinks the device is accessible again,
even though it previously shut it down. This leads to bugs, and I
even observed a kernel panic.

Avoid this by making the PCIe code only report that the radio is
enabled again after the higher layers actually decided to shut it
off.

This also pulls out this common RF-kill checking code into a common
function called by both transport generations and also moves it to
the direct method - in the internal helper we don't really care
about the RF-kill status anymore since we won't report it up until
the stop anyway.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we removed dev_cmd_headroom, the check for dev_cmd_ptr == NULL
became unnecessary, since we just return dev_cmd_ptr anyway.  Cleanup
the function to avoid useless code.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In order to more clearly document which parts of this file
are firmware API and which are something else, split the
firmware API into a separate file to include here.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The kernel-doc here is on an enum, so don't tag it as struct
but correctly as enum instead, preventing an error.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Now that we have 512 queues, add a wait for single TX
queue to gen2.
This replaces gen1 wait_tx_queues_empty, which was limited
to 32 queues.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Rename current wait_tx_queue_empty to wait_tx_queues_empty since
it waits for multiple queues (up to 32).
Next patch will add a wait for single TX queue which is needed for
gen2 to be scalable for 512.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Avoid using the old define since it will enlarge necessary
structs for previous HW.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In TVQM firmware returns the value of the queue ID and code
should accept it.
The TX queue config API was changed. Move to new API.
This has to be done in parallel in mvm and pcie.
Do not move yet to 512 queues since there are some opens
with enabling it.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

For a000 FW moved to 15 as management TID.
The change for us is fairly local - translate old TID to 15
when enabling and disabling a queue, and make sure to cover
it also on TX responses.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In a000 devices the TX handling is different in a few ways:
* Queues are allocated dynamically
* DQA is enabled by default
* Driver shouldn't access TFH registers - ucode configures it
  all in SCD_QUEUE_CFG command

Support all this in a new API with op mode, where op mode sends
the command, transport will allocate the queue dynamically, fill
in DMA properties, send the command to FW and get the ID back.
Current implementation only sets the new transport API and fills
the DMA properties.
Future patches will complete the other parts.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We don't need this parameter anymore, since we always pass 0 anyway.
Remove it from the structure and from all the relevant functions.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This reverts commit 8aacf4b7 ("iwlwifi: introduce trans API
to get byte count table").
The commit is not needed as a better approach will be taken.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Due to firmware design considerations, move to wide ID for
all commands.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In future HW the byte count table address will be configured
by ucode per queue. Add API to expose the byte count table to
the opmode
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

New hardware supports bigger TFDs and TBs.
Introduce the new formats and adjust defines and code
relying on old format.
Changing the actual TFD allocation is trickier and
deferred to the next patch.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

All transports has this structure. By moving it to be
shared, we can get rid of casting to the specific transport
in probe and remove.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The PCIe transport needs to store two pointers in each TX SKB, and
currently assumes mac80211's ieee80211_tx_info is present in the CB
to do that.

In order to remove that assumption, have the opmodes pass in the
offset to where the pointers can be stored in the CB and use the
offset in the PCIe code.

To make the disentanglement complete, remove mac80211.h includes
from everywhere in the generic iwlwifi code. This required adding
an include of cfg80211.h in one place.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Support DQA queue sharing when no free queue exists for
allocation to a STA that already exists. This means that
a single queue will serve more than a single TID (although
the RA will be the same for all TIDs served).

We try to choose the lowest AC possible, to ensure the
shared queues have the lowest possible combined AC
requirements. The queue to share is chosen only from the
same RA's DATA queues as follows (in descending priority):
 1. An AC_BE queue
 2. Same AC queue
 3. Highest AC queue that is lower than new AC
 4. Any existing AC (there always is at least 1 DATA queue)

If any aggregations existed for any of the TIDs of the
shared queue - they are stopped (the FW is notified), but
no delBA is sent.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add a warning in case packet didn't end up in the HW
destined queue.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

rx_phy notification is no longer sent in devices with
multiple rx queues.
All the needed data is now set in the metadata - update
code accordingly to reflect all the features as in the
previous RX path.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Currently there is one to one function between device id to it's ucode.
The new generation devices allows to combine different phy and mac images.
Now we have two different ucode images with the same device id.
Read RF ID to identify phy image and overwrite it if needed.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

For some reason, this was defined as a signed variable.
Make it unsigned.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

With these ops, we can know when we are about to enter system suspend.
This allows us to exit D0i3 state before entering suspend.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

No need to include net/ip6_checksum.h twice.
Remove TODOs.
Remove trailing space.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Currently when the driver is configured with wowlan parameters, and enters
D3 mode, the driver switches the FW image to D3, and when it exists
suspend, it reloads the D0 image.

If the firmware supports the consolidation of the D0 & D3 images there is
no need to load the D3 image on suspend, and no need to reload the D0
image on resume.

Do not switch images on suspend / resume, for firmwares that support
consolidated images.
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Enable runtime power management (RTPM) for PCIe devices and implement
the corresponding functions to enable D0i3 mode when the device is
idle.

Additionally, remove some unnecessary #ifdef's because the RTPM code
will not be called if runtime PM is not configured.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The debug functions of fw-dbg.c don't really need to modify
the trigger and the description they receive as a parameter.
Constify the pointers.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In case of bad trans state (i.e. fw is not loaded) bail
out immediately instead of calling the trans, which might
not be fully initialized yet.

Also add WARN_ON_ONCE to help debugging where the errorneous
call is coming from.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the callers used silent = false.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When the op_mode sends an skb whose payload is bigger than
MSS, PCIe will create an A-MSDU out of it. PCIe assumes
that the skb that is coming from the op_mode can fit in one
A-MSDU. It is the op_mode's responsibility to make sure
that this guarantee holds.

Additional headers need to be built for the subframes.
The TSO core code takes care of the IP / TCP headers and
the driver takes care of the 802.11 subframe headers.

These headers are stored on a per-cpu page that is re-used
for all the packets handled on that same CPU. Each skb
holds a reference to that page and releases the page when
it is reclaimed. When the page gets full, it is released
and a new one is allocated.

Since any SKB that doesn't go through the fast-xmit path
of mac80211 will be segmented, we can assume here that the
packet is not WEP / TKIP and has a proper SNAP header.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The transport will need to use the info->driver_data
pointers. Since the op_mode has this memory hot in cache,
clear it there.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Allow to configure the driver to pretend to have TX CSUM
offload support. This will be useful to test the TSO flows
that will come in further patches.
This configuration is disabled by default.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

ilw@linux.intel.com is not available anymore.
linuxwifi@intel.com should be used instead.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The d0i3_mode variable is used to distinguish between transports that
handle d0i3 entry during suspend by themselves (i.e. the slave
transports) and those which rely on the op_mode layer to do it.  The
reason why the former do it by themselves is that they need to
transition from d0i3 in runtime_suspend into d0i3 in system-wide
suspend and this transition needs to happen before the op_mode's
suspend flow is called.

The wowlan_d0i3 element is also a bit confusing, because it just
reflects the wowlan->any value for the trans to understand.  This is a
bit unclear in the code and not generic enough for future use.

To make it clearer and to generalize the platform power mode settings,
introduce two variables to indicate the platform power management
modes used by the transport.

Additionally, in order not to take too big a step in one patch, treat
this new variables semantically in the same way as the old d0i3_mode
element, introducing a iwl_mvm_enter_d0i3_on_suspend() function to
help with that.

This commit also adds the foundation for a new concept where the
firmware configuration state (i.e. D0, D3 or D0i3) is abstracted from
the platform PM mode we are in (i.e. runtime suspend or system-wide
suspend).
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Host commands now have a group id, express this in printed messages.
Signed-off-by: NSharon Dvir <sharon.dvir@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This function got too big to be inlined. Uninline it.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This allows the op_mode to request from the transport to
call a callback when an ASYNC commands is completed by
the firmware. The same callback will be called for all the
commands. Pass the command whose response triggers the
callback as a parameter to the callback itself.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>