The ref_lock that was recently added is missing initialization
which makes lockdep unhappy and is generally a bad idea.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In order to config the FW and to allocate monitor buffer driver should
run the function iwl_pcie_apply_destination immediately after FW sections
are loaded.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Reviewed-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Enter d0i3 on suspend, and exit d0i3. Wait for the
command responses in both cases.

Use this mode in case of pcie trans.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Implement the ref/unref trans ops and track both tx and
host command queues (and hold references while they
are not empty).
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When the driver is unload, the Manageability Engine should
know about that - send an event to inform it about this
event.
Reviewed-by: NReuven Borok <reuven.borok@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

New FW has chunks that are larger than the size limit of the
FH's DMA. To make sure we don't crash it - actively limit the
max size of each chunk.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When we reset the device, the CSR_INT gets cleared as well
as CSR_INT_MASK. Meaning that we shouldn't get any interrupt
but, due to a hardware bug, recent devices will keep sending
interrupts. This leads to an interrupt storm while stopping
the device.
The way to fix this is to ACK all the interrupts after the
device is reset so that the value of CSR_INT will stay
0xffffffff.

Fixes: 522713c8 ("iwlwifi: pcie: properly reset the device")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Until this patch, dumping the monitor data could be done only
for PCIe external (DRAM) mode in 7000 HW family. This patch
allows to pull the monitor data also on other families, and
also to pull the monitor data if an internal buffer is used.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Sometimes there is a need to configure some registers for
setting some FW properties, such as the FW monitor mode
(internal/external). This patch supports setting this for
PCIe mode.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Adds all FH registers between FH_MEM_UPPER_BOUND and
FH_MEM_LOWER_BOUND (which should be readable to the driver)
to the dump data when it is collected.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The ucode load flow changed for B0 hardware step.
Change the code accordingly.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Not doing so would allow other possible users of the device
to take ownership and prevent normal WiFi operation.

This fixes the second part of:
https://bugzilla.kernel.org/show_bug.cgi?id=87191Reviewed-by: NMoshe Harel <moshe.harel@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Toggle the LMPM_CHICK register when writing chunks into the FW's extended
SRAM. This tells the FW to put the chunk into a different memory space.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

We were toggling the wrong bit when we reset the device,
fix that. Moreover, since the reset can take time, we need
to wait before we set the rfkill interrupt. Not doing so
can be racy since the driver is enabling the rfkill
interrupt while the device is resetting which will clear
all the registers including the CSR_INT_MASK.
This can basically lead to a situation where we don't
enable the rfkill interrupt. If that happens, the user will
not be able to re-enable the device when de-asserting
rfkill.

This scenario happened to the submitter of:
https://bugzilla.kernel.org/show_bug.cgi?id=87191Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This is fully backward compatible with older platforms.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In some rare cases, the firmware can put the device to
sleep after the driver requested the access. This is
because the access request can take a short time to be
propagated to the firmware.

If that happens, the driver may think that it has access
since the firmware hasn't put the device to sleep yet, but
right after the driver's check, the firmware might put the
device to sleep.

Warn when this happens by allowing the firmware to finish
the "put the device sleep" flow so that the driver will
not get access to the device. This will make the issue
visible.

This still doesn't fix the race, but at least it makes
it more visible.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The length counting previously done had an error in it, causing
the length down the data dumping function to be shorter than it
should be, causing the end of the data to get truncated off and
lost.

Cc: <stable@vger.kernel.org> [3.17+]
Fixes: 67c65f2c ("iwlwifi: dump periphery registers to fw-error-dump")
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If the RFkill interrupt fires while we calibrate, it would
make the firmware fail and the driver wasn't able to recover.
Change the flow so that the driver will kill the firmware
in that case.

Since we have now two flows that are calling
trans_stop_device (the RFkill interrupt and the
op_mode_mvm_start function) - we need to better sync this.
Use the STATUS_DEVICE_ENABLED in the pcie transport in an
atomic way to achieve this.

This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=86231

CC: <stable@vger.kernel.org> [3.10+]
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi features a debug mechanism that allows to dump
binary data which is helpful to debug the firmware.
Until now, this data was made available for the userspace
through debugfs. For this exact purpose, devcoredump was
created. Move to the new infrastructure.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In the new format the "CSS section" has the same TLV type
as the "mem section". So we need to run the secured flow
for all the 8000 products.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When the ARC is reset when we exit from Sx in case we had
WoWLAN running, we can't access the prph before we reset
the NIC.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Otherwise we have no way to know that the buffer hasn't been
allocated.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

iwl_poll_bit may return a strictly positive value when the
poll doesn't match on the first try.
This was caught when WoWLAN started failing upon resume
even if the poll_bit actually succeeded.

Also change a wrong print. If we reach the end of
iwl_pcie_prepare_card_hw, it means that we couldn't
get the devices.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The LTR is the handshake between the device and the root
complex about the latency allowed when the bus exits power
save. This configuration was missing and this led to high
latency in the link power up. The end user could experience
high latency in the network because of this.

Cc: <stable@vger.kernel.org> [3.10+]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Align the trans->hw_rev variable format with previous series
format.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Rather than ANDing with a mask - use existing macros, which
are more readable.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This configuration is not needed for dvm, and it actually
broke it.
Reported-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Our legal structure changed at some point (see wikipedia), but
we forgot to immediately switch over to the new copyright
notice.

For files that we have modified in the time since the change,
add the proper copyright notice now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add the Control Status Registers to the firmware error dump
infrastructure.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Use the fw-error-dump infrastructure to dump the periphery
registers. Only certain ranges are readable, so dump only
these.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The mvm op_mode won't allocate the buffer for the transport
any more. The transport allocates its own buffer and mvm
is in charge of splicing the buffers in the debugfs hook.

This makes the repartition easier to handle.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This is matches the convention of the other structures.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The format of the CSR_HW_REV register has changed in 8000
HW family. To keep backwards compatibility, we store the
value of this register as usual in trans->hw_rev, only we
store it in the old format in this variable.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This adds need_update and write_actual to rx_queue and need_update
and an HCMD indicator to tx_queue.

On my card, rx_queue now looks like:

read: 181
write: 180
write_actual: 176
need_update: 0
free_count: 40
closed_rb_num: 181

tx_queue now looks like:

hwq 00: read=29 write=30 use=1 stop=0 need_update=0
hwq 01: read=0 write=0 use=1 stop=0 need_update=0
hwq 02: read=128 write=128 use=1 stop=0 need_update=0
hwq 03: read=0 write=0 use=1 stop=0 need_update=0
hwq 04: read=94 write=94 use=1 stop=0 need_update=0 HCMD
hwq 05: read=0 write=0 use=0 stop=0 need_update=0
hwq 06: read=0 write=0 use=0 stop=0 need_update=0
hwq 07: read=0 write=0 use=0 stop=0 need_update=0
hwq 08: read=0 write=0 use=0 stop=0 need_update=0
hwq 09: read=0 write=0 use=0 stop=0 need_update=0
hwq 10: read=0 write=0 use=0 stop=0 need_update=0
hwq 11: read=0 write=0 use=0 stop=0 need_update=0
hwq 12: read=0 write=0 use=0 stop=0 need_update=0
hwq 13: read=0 write=0 use=0 stop=0 need_update=0
hwq 14: read=0 write=0 use=0 stop=0 need_update=0
hwq 15: read=0 write=0 use=0 stop=0 need_update=0
hwq 16: read=0 write=0 use=0 stop=0 need_update=0
hwq 17: read=0 write=0 use=0 stop=0 need_update=0
hwq 18: read=0 write=0 use=0 stop=0 need_update=0
hwq 19: read=0 write=0 use=0 stop=0 need_update=0

This may help with debugging queue stalls.
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This allows to use the firmware monitor. This capability
uses a lot of contiguous memory (up to 64MB), so make its
usage module parameter dependent.

The driver will try to allocate as much contiguous memory
as possible downgrading its requirements until the
allocation succeeds.

Dump this data into the fw-error dump file when an error
happens.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Some races with the hardware can happen when we take
ownership of the device. Don't give up after the first try.

Cc: <stable@vger.kernel.org>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In case RFKILL is in KILL position, the NIC will issue an
interrupt straight away. This interrupt won't be sent
because it is masked in the hardware.
But if our interrupt service routine is called for another
reason (SHARED_IRQ), then we'll look at the interrupt cause
and service it. This can cause bad things if we are not
ready yet.
Explicitly clean the interrupt cause register to make sure
we won't service anything before we are ready to.

Cc: <stable@vger.kernel.org> [3.14]
Reported-and-tested-by: NAlexander Monakov <amonakov@gmail.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When a firmware error occurs, capture the last 32 commands
(which are still in memory) in the error dump debugfs file.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This variable always tracks a constant value (256) so there's
no need to have it. Removing it simplifies code generation,
reducing the .text size (by about 240 bytes on x86-64.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

While the scan_cmd should really be allocated in init (and
we do fail init in case the allocation failed), it doesn't
mean we should lock up the machine if something really bad
happened.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>