| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Part of reorganising wireless drivers directory and Kconfig.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
* bug fix for TDLS
* fixes and cleanups in scan
* support of several scan plans
* improvements in FTM
* fixes in FW API
* improvements in the failure paths when the bus is dead
* other various small things here and there
|
|
The hardware bug in the commit mentioned below forces us
not to re-enable the clock gating in the Host Cluster.
The impact on the power consumption is minimal and it allows
the WAKE_ME interrupt to propagate.
CC: <stable@vger.kernel.org> [4.1+]
Fixes: c9fdec9f3970 ("iwlwifi: pcie: fix prepare card flow")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B
device ID.
Cc: <stable@vger.kernerl.org> [3.13+]
Reported-by: Jeremy <jeremy.bomkamp@gmail.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The mac80211 patch to pass the NAPI struct only changed iwlwifi to
store the NAPI struct, but we can do better: pass it directly from
the lower transport layer to the opmode during RX, and then on to
mac80211 from there.
When we add multiple RX queues, we can then pass the appropriate
NAPI struct properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
As a preperation for multiple RX queues change the RBD
allocation model.
The new model includes a background allocator. The allocator is
called by the interrupt handler when there are two released
buffers by the queue, and the allocator starts allocating eight
pages per request.
When the queue has released 8 pages it tries claiming the
request. If the pages are not ready - it keeps claiming.
This new model should make sure that RBDs are always available
across the multiple queues.
The RBDs are transferred between the allocator and the queue.
The queue moves the free RBDs upon freeing them to the allocator.
The allocator moves them back to the queue's possession when the
request is claimed.
The allocator has an initial pool to make sure there are always RBDs
available for the request completion.
Release of the buffers at exit is done per pools - the allocator
frees its own initial pool and the queue frees its own pool.
Existing code refactor -
-Queue's initial pool is the size of the queue only as the allocation
of the new buffers no longer uses this pool.
-Removal of replenish background work, and replenish calls in the
interrupt handler and restock().
-The replenish() and the rxq used_list are used only during
initialization.
-Moved page allocation to a new function for code reuse.
New code -
Allocator code - new structure and functions.
Interrupt handler uses the allocator functions for replenishing buffers.
Reuse of the restock() method.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Conflicts:
drivers/net/wireless/iwlwifi/pcie/internal.h
|
|
Change the FW debug trigger tlv to include a monitor only
option. Setting this option to true will cause fw dump triggers
to only collect monitor data and skip other dumps such as
SMEM, SRAM, CSR, PRPH, etc.
This option is used when accessing the different parts of the
firmware memory is not wanted and can cause unwanted behavior
like when debugging TX latency.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Allow frag SKBs in PCIe and advertise the maximum number of frags
to the opmode. As a fallback. linearize the SKB if it exceeds the
maximum number of fragments. This allows using the hardware better
(filling more TBs) and should improve performance when used by the
opmode.
Also adjust tracing to be able to deal with this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Add support for dumping all the RBs in the RX queue
when FW error occurs.
This will assist debugging.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Family 8000 products has 2 embedded processors, the first
known as LMAC (lower MAC) and implements the functionality from
previous products, the second one is known as UMAC (upper MAC)
and is used mainly for driver offloads as well as new features.
The UMAC is typically “less” real-time than the LMAC and is used
for higher level controls.
The UMAC's code/data size is estimated to be in the mega-byte arena,
taking into account the code it needs to replace in the driver and
the set of new features.
In order to allow the UMAC to execute code that is bigger than its code
memory, we allow the UMAC embedded processor to page out code pages on
DRAM.
When the device is master on the bus(PCI) the driver saves the UMAC's
image pages in blocks of 32K in the DRAM and sends the layout of the
pages to the FW. The FW can load / unload the pages on its own.
The driver can support up to 1 MB of pages.
Add paging mechanism for the UMAC on PCI in order to allow the program
to use a larger virtual space while using less physical memory on the
device.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Since the CSR_DRAM_INIT_TBL_WRITE_POINTER bit wasn't set
on ict reset, in some flows (like disable ict followed by
immediate reset ict) the driver and hardware went out
of sync (the driver cleared the ict_index, while the hw
kept it intact).
Fix it by setting the flag when resetting ict.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Some CSR registers have to be configured also
in case of suspend/resume with unified image
(which doesn't includes reconfiguration flow).
Reuse the existing d3_suspend/d3_resume trans ops,
while making sure some configurations are a bit
different, according to the wowlan type.
After this change, we no longer need the special
wowlan_d0i3 configurations done in iwl_pci_resume,
as they are already being done in the d3_resume op.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The firmware debug infrastructure allows the user to
provide a firmware that will toggle a few registers to
configure the debugging capabilities.
On certain devices, certain operations are forbidden.
Executing a forbidden operation will cause the hardware to
die in a way that only driver unload / load will bring it
back to life.
Fortunately, there is a way to know in advance if those
operations will be accepted by the device. This is where
the new PRPH_BLOCKBIT operation plays its role. If the bit
X from PRPH register Y is set, then we should prevent any
further register configuration. When that happens, drop a
line in the kernel log since this is really an error state:
the user won't have his device configured as he expected.
Add operations that will be used in the future:
INDIRECT_ASSIGN, INDIRECT_SETBIT, and INDIRECT_CLEARBIT.
Other debugging configurations (such as destination
configuration for the monitor) will take place in any case.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Existing UMAC commands already use the long header, but are sent
with group 0 and the long header inserted manually. Move them to
the group 1 to take advantage of the header building in the low-
level transport.
Existing firmware ignores the group_id field (it's reserved) and
the first firmware that really supports long command headers can
parse all commands in both group 0 (with short header) and group
1 (with long header.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
As the firmware is slowly running out of command IDs and grouping of
commands is desirable anyway, the firmware is extending the command
header from 4 bytes to 8 bytes to introduce a group (in place of the
former flags field, since that's always 0 on commands and thus can
be easily used to distinguish between the two.
In order to support this most easily in the driver widen the command
command ID used in the command sending functions and encode the new
values (group and version) in the ID. That way existing code doesn't
have to be changed (since the higher bits are 0 automatically) and
newer code can easily use the new ID generation function to create a
value to use in place of just the command ID.
Signed-off-by: Aviya Erenfeld <aviya.erenfeld@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The 'flags' field really has been reserved in the firmware API for a
very long time, probably since 4965. As a consequence, the field is
always 0 and checking for a IWL_CMD_FAILED_MSK flag makes no sense.
Rename the field to 'reserved', get rid of IWL_CMD_FAILED_MSK and
all the code for it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
In iwlmvm firmwares, the Byte count written in the scheduler
byte count table is in DWORDs and not in bytes.
We should check that this value fits in the 12 bits and
the value can be either in bits of in DWORD or bytes
depending on the firmware. Check the value after the
translation to DWORDs is done (if needed).
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
In a few places, we were disabling interrupts but didn't
make sure that the interrupt handler has finished running.
Add calls to synchronize_irq() to ensure we finish handling
the interrupts before we free resources or other things that
could lead to a crash if the interrupt were to be handled
later.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
When the firmware crashes, we can't expect the Tx queues to
progress. Cancel their timer.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
With the previous patch series, no opmode continues using the
command or handler_status (i.e. the return value from the RX)
so it can be removed now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
During NIC initialization shared HW is reset and this disables the
scheduler. Some HW platforms do not activate the scheduler after it.
Consequently all HCMD sent by the driver stay at the queues which cause
to queue stuck.
Set the scheduler to work on auto active mode so it would be activated upon
change over one of the queues' write pointer.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The stuck queue detection mechanism allows to detect queues
that are stuck. For sleeping clients, a queue may rightfully
be stuck: if a poor client implementation stays asleep for
more than 10s, then we don't want to trigger recovery flows
because of that client.
In order to cope with this, I added a mechanism that
monitors the state of the client: when a client goes to
sleep, the timer of his queues is frozen. When he wakes up,
the timer is reset to the right value so that if a client
was awake for more than 10s and the queues are stuck, only
then, the recovery flow will kick in.
This is valid only on non-shared queues: A-MPDU queues.
There was a bug in case we Tx to a sleeping client that has
an empty A-MPDU queue: the timer was armed to now + 10s.
This is bad, but pretty harmless.
The problem is that when the client wakes up, the timer is
modified to be now + remainder. But remainder is 0 since the
queue was empty when that client went to sleep...
Fix this by checking the state of the client before playing
with the timer when we add a packet to an empty queue.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
When the card is not owned by the PCIe bus, we need to
acquire ownership first. This flow is implemented in
iwl_pcie_prepare_card_hw. Because of a hardware bug, we
need to disable link power management before we can
request ownership otherwise the other user of the device
won't get notified that we are requesting the device which
will prevent us from acquire ownership.
Same holds for the down flow where we need to make sure
that any other potential user is notified that the driver
is going down.
CC: <stable@vger.kernel.org> [4.1]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
This reverts commit 5f17570354f91275b0a37a4da33d29a2ab57d32e.
This patch introduced a high latency in buffer allocation
under extreme load. This latency caused a firmwre crash.
The same scenario works fine with this patch reverted.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Add new 3165 devices support.
Add one new 8000 series device support.
Remove support for 0x0000, 0xC030 and 0xD030 sub-system IDs
in the 8000 series.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
For 8000 series, we need to access the device to know what
firmware to load. Before we do so, we need to prepare the
device otherwise we might not be able to access the
hardware.
Fixes: c278754a21e6 ("iwlwifi: mvm: support family 8000 B2/C steps")
CC: <stable@vger.kernel.org> [4.1]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
iwl_trans_pcie_alloc needs to return a non-zero value
if it fails. Otherwise the iwl_drv_start will think that
the allocation succeeded.
Remove the duplication of err and ret variable and use ret
which is the name we usually use in other places of the
driver.
Fixes: c278754a21e6 ("iwlwifi: mvm: support family 8000 B2/C steps")
CC: <stable@vger.kernel.org> [4.1]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
While cleanig the access to those hw-dependent registers,
instead of using the product family type, wrong condition was added
mistakenly and enabled 8000 family devices a forbidden access
to HW registers, fix it.
Fixes: 95411d0455cc ("iwlwifi: pcie: Control access to the NIC's PM registers via iwl_cfg")
Signed-off-by: Dreyfuss, Haim <haim.dreyfuss@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
This allows to ensure that we don't have races between them.
A user reported that stop_device was called twice upon
rfkill interrupt after suspend. When the interrupts are
enabled, and right after when we directly check the rfkill
state.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
new driver mt7601u for MediaTek Wi-Fi devices MT7601U
ath10k:
* qca6174 power consumption improvements, enable ASPM etc (Michal)
wil6210:
* support Wi-Fi Simple Configuration in STA mode
iwlwifi:
* a few fixes (re-enablement of interrupts for certain new
platforms that have special power states)
* Rework completely the RBD allocation model towards new
multi RX hardware.
* cleanups
* scan reworks continuation (Luca)
mwifiex:
* improve firmware debug functionality
rtlwifi:
* update regulatory database
brcmfmac:
* cleanup and new feature support in PCIe code
* alternative nvram loading for router support
====================
Conflicts:
drivers/net/wireless/iwlwifi/Kconfig
Trivial conflict in iwlwifi Kconfig, two commits adding
the same two chip numbers to the help text, but order
transposed.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
As a preperation for multiple RX queues change the RBD
allocation model.
The new model includes a background allocator. The allocator is
called by the interrupt handler when there are two released
buffers by the queue, and the allocator starts allocating eight
pages per request.
When the queue has released 8 pages it tries claiming the
request. If the pages are not ready - it keeps claiming.
This new model should make sure that RBDs are always available
across the multiple queues.
The RBDs are transferred between the allocator and the queue.
The queue moves the free RBDs upon freeing them to the allocator.
The allocator moves them back to the queue's possession when the
request is claimed.
The allocator has an initial pool to make sure there are always RBDs
available for the request completion.
Release of the buffers at exit is done per pools - the allocator
frees its own initial pool and the queue frees its own pool.
Existing code refactor -
-Queue's initial pool is the size of the queue only as the allocation
of the new buffers no longer uses this pool.
-Removal of replenish background work, and replenish calls in the
interrupt handler and restock().
-The replenish() and the rxq used_list are used only during
initialization.
-Moved page allocation to a new function for code reuse.
New code -
Allocator code - new structure and functions.
Interrupt handler uses the allocator functions for replenishing buffers.
Reuse of the restock() method.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
On resume, all the interrupts are masked (CSR_INT_MASK is 0),
and ict is disabled.
Re-configure them both.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Allow a cleaner way to access those hw-dependent registers,
instead of using the product family type etc.
Signed-off-by: Avri Altman <avri.altman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Conflicts:
drivers/net/phy/amd-xgbe-phy.c
drivers/net/wireless/iwlwifi/Kconfig
include/net/mac80211.h
iwlwifi/Kconfig and mac80211.h were both trivial overlapping
changes.
The drivers/net/phy/amd-xgbe-phy.c file got removed in 'net-next' and
the bug fix that happened on the 'net' side is already integrated
into the rest of the amd-xgbe driver.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This check for family type is redundant as the if clause above
checks a family-dependent Boolean (which is not set for family 8000 anyway).
Signed-off-by: Avri Altman <avri.altman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
This was spot by Coccinelle.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The transport modules all need to allocate memory and set up
certain values. Refactor that code into a new common function
to share it and to simplify the error handling.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The cmd_in_flight tracking was introduced to workaround faulty
power management hardware, by having the driver keep the NIC
awake as long as there are commands in flight. However, some of
the code handling this workaround was unconditionally executed,
which resulted with an inconsistent state where the driver assumed
that the NIC was awake although it wasn't.
Fix this by renaming 'cmd_in_flight' to 'cmd_hold_nic_awake' and
handling the NIC requested awake state only for hardwares for
which the workaround is needed.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
We should not call the iwl_pcie_set_pwr() functions in the
suspend/resume flows for family 8000, because the register used is
locked in devices from this family. Doing this causes an NMI
protection error (RT_NMI_INTERRUPT_PREG_PROTECTION).
To fix this, skip those calls if the device family is
IWL_DEVICE_FAMILY_8000.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Conflicts:
drivers/net/wireless/iwlwifi/Kconfig
|
|
Disabling the clocks is a standard procedure while stopping the
device. On family 8000 however, disabling the bus master DMA clock
increases the NIC's power consumption.
To fix this, skip this call if the device family is
IWL_DEVICE_FAMILY_8000.
Signed-off-by: Avri Altman <avri.altman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
When we use an external buffer, it is allocated from the
t DRAM and can be as big as 64MB. This buffer is huge and
might not be needed for the specific issue being chased.
Especially if lots of dumps are going to be created.
Allow to limit the size of the buffer in the configuration.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
This adds support for configuring and retrieving the FW
monitor in MARBH mode.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Our device needs two different firmwares: the INIT firmware
and the operational (OPER) firmware. The first one is run
when the driver loads and it returns calibrations results
as well as the NVM. The second one implements the WiFi
protocol.
If the wlan interface is not brought up, the device is put
to low power state: no firmware will be running. When the
interface is brought up, we would run the OPER firmware
only and reuse the results of the run of the INIT firmware
when the driver was loaded. This is changing with this
patch.
We now run the INIT firmware every time mac80211 calls
start(). The penalty for that is minimal since the INIT
firwmare run fast. I now also avoid to power down the device
between the INIT and OPER firmware on certains buses.
The motivation for this change is that there are components
on the device (MFUART) that are triggered by the INIT
firmware and need the device to be powered up in order to
keep running. Powering the device down between the INIT and
OPER firmware would stop these components and prevent them
from running again since they are triggered by the INIT
firmware only.
The new flow allows this and also allows to trigger these
components again when the interface is brought up after
it has been brought down.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
In the case of a DMA mapping error on the last iteration of
the loop of the allocation of memory of the FW monitor we
indeed free the pages, but don't NULL out the page variable
thus allowing for the possibility of setting the FW monitor
variables with invalid data to use.
Fixes: c2d202017da1 ("iwlwifi: pcie: add firmware monitor capabilities")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
* some more work on LAR
* fixes for UMAC scan
* more work on debugging framework
* more work for 8000 devices
* cleanups and small bugfixes
|
|
Conflicts:
drivers/net/usb/asix_common.c
drivers/net/usb/sr9800.c
drivers/net/usb/usbnet.c
include/linux/usb/usbnet.h
net/ipv4/tcp_ipv4.c
net/ipv6/tcp_ipv6.c
The TCP conflicts were overlapping changes. In 'net' we added a
READ_ONCE() to the socket cached RX route read, whilst in 'net-next'
Eric Dumazet touched the surrounding code dealing with how mini
sockets are handled.
With USB, it's a case of the same bug fix first going into net-next
and then I cherry picked it back into net.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The semaphore may not be accessible. Fix the debug prints
accordingly.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
These early versions are no longer supported.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
