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: Alexander Monakov <amonakov@gmail.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel 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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel 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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The 'reset' argument is clearly a boolean, so use bool instead
of u8 with 0/1 values.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
7000 device series have a fix for this hardware feature.
Stop disabling it, and get an improvement in Tx throughput.
This feature allows the scheduler to fetch more frames on
the fly while an A-MPDU is being built - which means that
we can get larger A-MPDU. This, of course, give an
improvement in the Tx throughput.
Signed-off-by: Emmanuel 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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This must not happen - otherwise we might keep flushing
forever.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This will be used later to flush / wait for queues that are
related to a specific vif.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This define is related to the firmware packaging and is
needed by more than one transport.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Besides the different allocation flags, they are really
the same. Pass the gfp_t flags as a parameter, and unify
them.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Similar to the recent RX queue patch, this changes the need_update
handling for the TX queues to be clearer and only done when needed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When updating the write pointer, the TX queue should be locked
to get consistent state, fix that in the interrupt handler.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Instead of using u8 to hold logic values, use bool.
Also fix a comment, the return value is no longer relevant.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When shadow registers are enabled, then need_update never needs
to be set, so move the need_update handling into the function
that really needs to do it (iwl_pcie_rxq_inc_wr_ptr) and also
separate the check when it woke up. While at it, convert it to
bool.
This also clarifies the locking and means the irq_lock needs to
no longer be held for any such updates.
The irq_lock also doesn't have to be held for restocking since
everything else locks the RX queue properly, so remove that and
finally disentangle the two locks entirely so there aren't any
dependencies between the two left.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Use the new NAPI infrastructure added to mac80211 to get
GRO. We don't really implement NAPI since we don't have
a real poll function and we never schedule a NAPI poll.
Instead of this, we collect all the packets we got from a
single interrupt and then call napi_gro_flush().
This allows us to benefit from GRO. In half duplex medium
like WiFi, its main advantage is that it reduces the number
of TCP Acks, hence improving the TCP Rx performance.
Since we call the Rx path with a spinlock held, remove
the might_sleep mention from the op_mode's API.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Ido Yariv <ido@wizery.com>
[Squash different patches and rewrite the commit message]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
A hardware bug had been discovered on 7260 / 3160 and 7265
and the workaround for this bug is to force the NIC to stay
awake as long as we have host commands in flight. This
workaround has been introduced for all NICs in a previous
patch:
b943949105 ("iwlwifi: pcie: keep the NIC awake when commands are in flight")
In newer NICs, this bug is solved, so we can let the NIC go
to sleep even when we send commands. The hardware will wake
up when we increment the scheduler write pointer.
Make the workaround conditional to only use it on affected
hardware.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When indicating RF-kill toggle to the higher layer, that
may in turn call back to the transport (for MVM at least)
to turn off the device quickly. Instead of that, allow it
to return whether or not the device should be turned off,
this gets rid of the call indirection and will help make
the API more consistent when we go back to non-threaded
interrupts again for PCIe.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
1. Enable LP XTAL to avoid HW bug where device may consume much
power if FW is not loaded after device reset. LP XTAL is
disabled by default after device HW reset. Configure device's
"persistence" mode to avoid resetting XTAL again when SHRD_HW_RST
occurs in S3.
2. Add methods to access SHR (shared block memory space) directly from PCI
bus w/o need to power up MAC HW.
Shared internal registers (e.g. SHR_APMG_GP1, SHR_APMG_XTAL_CFG)can be
accessed directly from PCI bus through SHR arbiter even when MAC HW is
powered down. This is possible due to indirect read/write via
HEEP_CTRL_WRD_PCIEX_CTRL (0xEC) and HEEP_CTRL_WRD_PCIEX_DATA (0xF4)
registers.
Use iwl_write32()/iwl_read32() family to access these registers. The MAC HW
need not be powered up so no "grab inc access" is required.
For example, to read from SHR_APMG_GP1 register (0x1DC),
first, write to the control register:
HEEP_CTRL_WRD_PCIEX_CTRL[15:0] = 0x1DC (offset of the SHR_APMG_GP1 register)
HEEP_CTRL_WRD_PCIEX_CTRL[29:28] = 2 (read access)
second, read from the data register HEEP_CTRL_WRD_PCIEX_DATA[31:0].
To write the register, first, write to the data register
HEEP_CTRL_WRD_PCIEX_DATA[31:0] and then:
HEEP_CTRL_WRD_PCIEX_CTRL[15:0] = 0x1DC (offset of the SHR_APMG_GP1 register)
HEEP_CTRL_WRD_PCIEX_CTRL[29:28] = 3 (write access)
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This message triggers on systems that don't support the API,
so suppress them when not debugging as it's not useful to
see it there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Update of the HW IDs for the 7265 series.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In case the firmware didn't assert but we want to restart
it, e.g. we didn't get the reply for a host command, or the
Tx queues are stuck, we should stop the firmware by
provoking an interrupt. This allows to better debug the
firmware in these bad scenarios.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
There are a number of things in the .data section that should
really be in .rodata, for example all ops structs and strings.
Mark everything const that can be, leaving the .data section
pretty much empty.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The various code blocks in iwl_pcie_[rt]xq_inc_wr_ptr
finally do the same things, so just merge them
all and make the functions cleaner.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Newer devices have two embedded CPUs, and the firwmare for
both of them is include in the .ucode file requested upon
enumeration.
An empty section with address=0xFFFFCCCC separates between
the sections intended for cpu1 and the sections intended
for cpu2.
Update the driver to parse the .ucode file with this format
and act accordingly.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Some platforms may have power limitations on PCIe cards connected to
specific root ports.
This information is encoded as part of the ACPI tables, for instance:
<snip>
Name (SPLX, Package (0x02)
{
Zero,
Package (0x03)
{
0x07,
0x00000500,
0x80000000
}
})
Method (SPLC, 0, Serialized)
{
Return (SPLX)
}
</snip>
The structure returned contains the domain type, the default power
limitation and the default time window (reserved for future use).
Upon PCI probing, call the relevant ACPI method, parse the returned
structure, and save the power limitation.
Signed-off-by: Ido Yariv <idox.yariv@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In iwl_pcie_int_cause_non_ict, trans_pcie is used for lockdep
purposes only. Since this might not be enabled, trans_pcie
finds itself without user leading to a complaint from gcc.
Avoid using trans_pcie by inlining IWL_TRANS_GET_PCIE_TRANS.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The code seems fine, as buf won't be assigned when an error
is returned, but checking for the error first is easier to
understand.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Also handle the bypass mode in which the second CPU doesn't
interfere.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This configuration is invalid for this family.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Dor Shaish <dor.shaish@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This register is not present in 8000 family devices.
There is prph register instead.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Dor Shaish <dor.shaish@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
APMG HW block was removed in this NIC, hence, no need to
configure it.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
None of the devices supported by iwldvm have support for
shadow registers. This means that we wake the NIC
when we increment the write pointer on Tx ring.
This happened even before my bad commit mentionned below.
Since my commit below, we wake up the NIC when we put a
host command on the ring regardless of shadow register
support. This means that in iwldvm (when the NIC doesn't
support shadow register), we wake up the NIC twice:
pcie_enqueue_hcmd:
wake up the NIC
iwl_pcie_txq_inc_wr_ptr:
wake up the NIC - no shadow reg support
Since waking up the NIC means that we need to acquire a
spinlock, this obviously leads to a recursive spinlock
and hence a freeze.
Fixes: b943949105 ("iwlwifi: pcie: keep the NIC awake when commands are in flight")
Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Add an inline helper function for getting an RX packet's
length or payload length and use it throughout the code
(most of which I did using an spatch.)
While at it, adjust some code, and remove a bogus comment
from the dvm calibration code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Enabling the oscillator consumes slightly more power (100uA)
but allows to make sure that we exit from L1 on time.
Not doing so might lead to a PCIe specification violation
since we might wake up from L1 at the wrong time.
This issue has been identified on 3160 and 7260 only.
On older NICs L1 off is not enabled, on newer NICs (7265),
the issue is fixed.
When the bug occurs the user sees that the NIC has
disappeared from the PCI bridge, any access to the device
returns 0xff.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=64541
and has been extensively discussed here:
http://markmail.org/thread/mfmpzqt3r333n4bo
Cc: stable@vger.kernel.org [3.10+]
Fixes: 99cd471423 ("iwlwifi: add 7000 series device configuration")
Reported-and-tested-by: wzyboy <wzyboy@wzyboy.org>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The access to the CSR_RESET reg should be done as a complete
DWORD and not by setting a bit. This is the right way to reset
the device.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Calling stop_device when start_fw wasn't called would issue:
Stopping tx queues that aren't allocated...
Also allow the op_mode to call stop_device and then to
disable the Tx queues - in that case just silently ignore
the disabling on the Tx queues, since the PRPH registers
aren't reachable any more.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This is useless and introduces a dependency between rfkill
and stop_device - the op_mode can't call stop_device from
the rfkill notification since it would lead to an endless
recursion.
Next patches will need to do so.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
