Instead of modifying the HT SMPS capability field
for stations, track the SMPS mode explicitly in a
new field in the station struct and use it in the
drivers that care about it. This simplifies the
code using it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This patch check output of pci_map_single() calls. I missed them on
my previous patch "iwlegacy: check for dma mapping errors", which
fixed only pci_map_page() calls.
To handle remaining possible dma mappings errors, we need to rearrange
ilXXXX_tx_skb() and il_enqueue_hcmd() functions.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We do not correctly change interface type when switching from
IBSS mode to STA mode, that results in microcode errors.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=886946
Reported-by: Jaroslav Skarvada <jskarvad@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Dump implementation of flush, which just wait until all TX queues
become empty.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the standard #defines rather than creating local definitions for
PCIe Capability ASPM fields.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
il_pcie_link_ctl() has only one call site and no longer provides any useful
abstraction, so collapse it into the caller.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Instead of copying from a constant array
(which is still needed for other purposes)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's no need to export the il_pci_suspend
and il_pci_resume functions since they're only
referenced from il_pm_ops. The latter can also
be defined using SIMPLE_DEV_PM_OPS instead of
open-coding it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some drivers (iwlegacy, iwlwifi and rt2x00) today use the
bss_conf.last_tsf value. By itself though that value is
completely worthless since it may be ancient. What really
is needed is synchronisation between some device time and
the TSF.
To clarify this, rename bss_conf.last_tsf to sync_tsf and
add sync_device_ts which is obtained from rx_status which
gets a new field device_timestamp for this purpose. This
is intentionally not using the mactime field since that
is used for other things and in IBSS is expected to sync
with the IBSS's TSF which isn't necessarily true for the
device timestamp.
Also, since we have the information and it's useful even
before the connection has been established, give all the
timing details to the driver before authenticating.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is iwlegacy version of:
commit 342bbf3fee
Author: Johannes Berg <johannes.berg@intel.com>
Date: Sun Mar 4 08:50:46 2012 -0800
iwlwifi: always monitor for stuck queues
If we only monitor while associated, the following
can happen:
- we're associated, and the queue stuck check
runs, setting the queue "touch" time to X
- we disassociate, stopping the monitoring,
which leaves the time set to X
- almost 2s later, we associate, and enqueue
a frame
- before the frame is transmitted, we monitor
for stuck queues, and find the time set to
X, although it is now later than X + 2000ms,
so we decide that the queue is stuck and
erroneously restart the device
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Every now and then, after resuming from suspend, the iwlegacy driver
prints
iwl4965 0000:03:00.0: Queue 2 stuck for 2000 ms.
iwl4965 0000:03:00.0: On demand firmware reload
I have no idea what causes these errors. But the code currently uses
wd_timeout in the first error. wd_timeout will generally be set at
IL_DEF_WD_TIMEOUT (ie, 2000). Perhaps printing for how long the queue
was actually stuck can clarify the cause of these errors.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Current commit 0775f9f90c
"mac80211: remove spurious BSSID change flag" exposed bug on iwlegacy,
that we do not set BSSID address correctly and then device was not able
to receive frames after successful associate.
On the way fix scan canceling comment. Apparently ->post_associate()
do cancel scan itself, but scan cancel on BSS_CHANGED_BSSID is needed.
I'm not sure why, but when I removed it, I had frequent auth failures:
wlan4: send auth to 54:e6:fc:98:63:fe (try 1/3)
wlan4: send auth to 54:e6:fc:98:63:fe (try 2/3)
wlan4: send auth to 54:e6:fc:98:63:fe (try 3/3)
wlan4: authentication with 54:e6:fc:98:63:fe timed out
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This il->vif is dereferenced in different part of iwlegacy code, so do
not nullify it. This should fix random crashes observed in companion
with microcode errors i.e. crash in il3945_config_ap().
Additionally this should address also
WARNING: at drivers/net/wireless/iwlegacy/common.c:4656 il_mac_remove_interface
at least one of the possible reasons of that warning.
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This value is not really very useful by itself,
yet some drivers (including iwlwifi until I can
figure out what it should do) use it. At least
rename it to "last_tsf" to indicate the meaning
and add a note that it may be really old.
I suspect the value may become useful combined
with the rx_status->mactime, but we don't (yet)
store that value and pass it to the driver.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If rfkill is on il_grab_nic_access() fail and we can not write to the
various registers during stop procedure. Write to those registers
unconditionally instead.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The same data can be gathered using monitor mode.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John 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 iwlegacy devices are most likely
not used on anything other than x86, this is not so important
fix.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Before we write to the device register always check if
_il_grap_nic_access() was successful.
Change type return type _il_grap_nic_access() to bool, and
add likely()/unlikely() statements.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Print dump stack when the device is not responding. This should give
some more clue about the reason of failure. Also change the message we
print, since "MAC in deep sleep" is kinda confusing.
On the way add unlikely(), as fail to gain NIC access is hmm ...
unlikely.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It's just wrapper to sk_buff pointers ...
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
