Add some more chip IDs to bcma_pmu_get_alp_clock()
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of hard coding these values use the existing constants.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The messages are currently hard coding "1ms", which does not match
the actual timeout being used.
Signed-off-by: Robert Shade <robert.shade@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Marco Fonseca reported a issue with his carl9170 device:
"I'm seeing a problem with the carl driver. If I change channels
repeatedly on the 2.4ghz band, monitoring (e.g. tcpdump) will
eventually halt. I've seen this on various versions of the carl
driver/firmware (both from 1.9.4 to 1.9.7)"
<http://marc.info/?l=linux-wireless&m=136381302428113>
The culprit was identified as "fast channel change feature" which
according to Adrian Chadd is: "... notoriously unreliable and
really only fully debugged on some very later chips."
<http://marc.info/?l=linux-wireless&m=136416984531380>
Therefore, this patch removes the fast channel change feature.
The phy will now always have to go through a cold reset when
changing channels, but it should no longer become deaf.
Cc: Marco Fonseca <marco@tampabay.rr.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix settings not being applied when the device is idle and the firmware
gets reloaded (because of changing from STA to AP mode). This caused
the device using the wrong channel (and likely band), e.g. a 5 GHz only
card still defaulted to channel 6 in the 2.4 GHz band when left
unconfigured.
This issue was always present, but only made visible with "mwl8k: Do not
call mwl8k_cmd_set_rf_channel unconditionally" (0f4316b9), since before
that the channel was (re-)configured at the next _config call even when
it did not change from the mac80211 perspective.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is possible to configure the ucode to automatically send the probe
responses to the clients after they send a probe request. At least for
WPS the userspace needs to answer the probe requests and we do not know
a way to say to the ucode to just handle the normal probe requests, so
for now no probe requests should be handled by the ucode.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The ucode is able to answer probe response by itself. This writes such
a template into the specific memory. Currently the probe requests are
also send to mac80211 so there are more answers send to a requesting
client. We have to make the ucode stop sending probe requests to the
driver.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To send the correct probe response the hardware needs to know the SSID
when it changed.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This makes it possible that a beacon template provided by mac80211 is
written to the hardware for constant beaconing.
This is based on an old version of brcmsmac, on b43 and the spec b43 is
based on.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make brcms_c_set_beacon_period() write the beacon period to the
hardware if a new one is set.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This was a read only member, replace it with pub->up.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This was a read only member. The checks using BSS are replaced by
better fitting checks of the new type member.
The change in brcms_c_tbtt() was based on code from b43, in
brcms_c_ps_allowed() the same happens with BSS being true or false,
beaconing and probe responses are just needed in ap mode.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This makes it possible to easily check in which mode the device is
currently running. This also adds a function to start station mode.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
setting the tsf is needed to start a timer to make beaconing in AP mode
work.
This is based on older versions of brcmsmac and b43.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of defining the magic values in the code use constants.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
FW can be woken up even by accessing device registers; we need
not explicitily enable interrupts for doing this. Future PCIe
devices will not be woken up by writing to host registers.
This patch enables driver to wake up device by reading FW status
register.
Also devices with sleep cookie enabled need some more time before
proceeding with processing. Handle this by adding a delay loop.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We have received interrupt from device means FW is not sleeping.
In this case make sure wakeup handler for PCIe is not invoked by
setting adapter->pm_wakeup_fw_try to false.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Enabling PCIe host interrupt may accidently wake up the card
when it's in sleep.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 6236dc2e2 ("brcmsmac: remove some redundant chip common workarounds")
removed the last uses.
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The spectral data provided via relay-fs introduces a buffering
latency given by the subbuf_size. To meet the requirements for
delay-sensitive applications (like real-time spectral plotter),
reduce subbuf_size and increase n_subbufs.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When calculating "offset" for final RSSI calibration we're using numbers
bigger than s8 can hold. We have for example:
offset[j] = 232 - poll_results[j];
formula. If poll_results[j] is small enough (it usually is) we treat
number's bit as a sign bit. For example 232 - 1 becomes:
0xE8 - 0x1 = 0xE7, which is not 231 but -25.
This code was introduced in e0c9a0219a
and caused stability regression on some cards, for ex. BCM4322.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
il4965_rs_initialize_lq checks to see if sta is null, however, before that
check il4965_rs_use_green dereferences sta when intializing use_green.
Avoid a potential null pointer dereference error by only calling
il4965_rs_use_green after we are sure sta is not null.
Smatch analysis:
drivers/net/wireless/iwlegacy/4965-rs.c:2160 il4965_rs_initialize_lq() warn:
variable dereferenced before check 'sta' (see line 2155)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The following issue was reported.
WARNING: at net/mac80211/util.c:599 ieee80211_can_queue_work.isra.7+0x32/0x40 [mac80211]()
Hardware name: iMac12,1
queueing ieee80211 work while going to suspend
Pid: 0, comm: swapper/0 Tainted: PF O 3.8.2-206.fc18.x86_64 #1
Call Trace: Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642992] <IRQ>
[<ffffffff8105e61f>] warn_slowpath_common+0x7f/0xc0
[<ffffffffa0581420>] ? ath_start_rx_poll+0x70/0x70 [ath9k]
<ffffffff8105e716>] warn_slowpath_fmt+0x46/0x50
[<ffffffffa045b542>] ieee80211_can_queue_work.isra.7+0x32/0x40
Fix this by avoiding to queue the work if our device has
already been marked as suspended or stopped.
Reported-by: Parag Warudkar <parag.lkml@gmail.com>
Tested-by: Parag Warudkar <parag.lkml@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Intermittently, b43 will report "Out of order TX status report on DMA ring".
When this happens, the driver must be reset before communication can resume.
The cause of the problem is believed to be an error in the closed-source
firmware; however, all versions of the firmware are affected.
This change uses the observation that the expected status is always 2 less
than the observed value, and supplies a fake status report to skip one
header/data pair.
Not all devices suffer from this problem, but it can occur several times
per second under heavy load. As each occurence kills the unmodified driver,
this patch makes if possible for the affected devices to function. The patch
logs only the first instance of the reset operation to prevent spamming
the logs.
Tested-by: Chris Vine <chris@cvine.freeserve.co.uk>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We're using "mind" variable to find the VCM that got the best polling
results. For each VCM we calculte "currd" which is compared to the
"mind". For PHY rev3+ "currd" gets values around 14k-40k. Looking for a
value smaller than 40 makes no sense, so increase the initial value.
This fixes a regression introduced in 3.4 by commit:
e0c9a0219a
(my BCM4322 performance dropped from 18,4Mb/s to 9,26Mb/s)
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit b6fc28a158.
This commit is reported to cause a regression in the support for some
revisions of 4313 ePA devices.
http://marc.info/?l=linux-wireless&m=136360340200943&w=2
Conflicts:
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
Reported-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This caused issues with tracing as it's longer than
the buffer size used there.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This module parameter isn't and won't be used. So ignore
its value and set BT_CH_ANNOUNCE unconditionally.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The BCM5354 SoC has a build in ieee80211 core rev 13 with a LP-PHY on
it. This devices has a sprom version 3 stored in the nvram. This patch
removes the warning and uses the opo values from the sprom as mentioned
in the specs.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These attributes should be in the sprom for rev 2 and 3, but they were
not read out.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With this patch the same registers are written, but this access is now
protected by a lock.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, default VHT configuration from the firmware is used
for the VHT operations. Adding vhtcfg command to configure the
firmware based on input received from cfg.
Enable VHT for AP mode only when cfg80211_ap_settings has a
VHT IE i.e., when ieee80211ac is set to 1 in the hostapd.conf.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add proper alignment at first packet copy, to avoid extra copies made later
in networking stack.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move processing of received packets to tasklet from hard-irq context.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RX path has extra copying of packets, that can be avoided.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use dedicated DMA coherent buffers for RX urbs, to avoid allocation of large
skbuffs in hard-irq context and improve performance.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch is a bug fix for an issue wherein power save was not
working for PCIe. This happens because for processing power save
sleep confirm command we pull skb so that skb->data points ahead
of interface header. We use same skb to get other cmda responses
as well. So if we don't push skb after processing cmd response,
it results into reduction in skb->len and finally skb->len reaches
zero. This causes failure in processing sleep command response.
Fix this by pushing skb by INTF_HEADER_LEN at the end of command
response processing.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Drivers that don't use chanctxes cannot perform VHT association because
they still use a "backward compatibility" pair of {ieee80211_channel,
nl80211_channel_type} in ieee80211_conf and ieee80211_local.
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
[fix kernel-doc]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Spin locks and completions are expensive in hard IRQ context and cause
problems with RT kernels. In RT kernels, both spin locks and
completions can schedule(), so we can't use them in hard irq context.
Move handling code into the irq thread function to avoid that.
Reported-by: Gregoire Gentil <gregoire@alwaysinnovating.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
We were printing out all the hex dumps regardless of whether dynamic
debugging was enabled or not. Now that print_hex_dump_debug() has
been implemented, we can use that instead.
Reported-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Don't ignore dummy packets when our queues are empty. This causes dummy
packets never to be sent when traffic is not suspended by FW thresholds,
which happens only in high Tx throughput situations. This may hurt Rx
performance.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The wlcore state was checked without the mutex being taken. This leads
to WARN_ONs sometimes if a notification arrives when the driver
is on, but the mutex is only taken after it is off. This usually
happens if stopping the driver while connected to a network.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Save the sequence number of the broadcast AP link in the wlvif. For each
connected station, save the sequence number in the drv_priv part of
ieee80211_sta. Use the saved numbers on recovery/resume, with the
obligatory increment on recovery.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Dont use free_sta() on AP global links. It would fail an internal check
within the function and various structures within the link struct would
not be reset.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Print board type, PG with metal and ROM versions.
This might help debugging HW related issues.
Signed-off-by: Victor Goldenshtein <victorg@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
For STA we report beacon loss to higher levels so that wpa_s
can attempt to roam without disconnecting. In case of P2P CLI
we don't want to attempt roaming and instead disconnect immediately
upon beacon loss.
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
On !CONFIG_SMP builds spin_is_locked always returns 0. Assert the
locking using assert_spin_locked, which is written to behave correctly
in all cases.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
report the average beacon rssi which is calculated
by firmware for roaming statistics instead of the
last rx packet rssi. this results a more accurate
rssi reporting
Signed-off-by: Nadim Zubidat <nadimz@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Accumulate the total number of sent packets per-link to find out how far
the encryption sequence number has progressed. Use this number as the
initial security sequence number after recovery.
This consolidates security sequence handling for both chip families, as
we no longer have to rely on 12xx specific Tx completion.
A fortunate side effect of this is correct management of seq numbers for
AP roles and multi-role scenarios.
When a link is removed we save the last seq number on a persistent part
of the wlvif. This helps the data survive through recoveries/suspends,
which also entail changes in the hlid of the link.
This functionality is STA only currently.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The HLID of a STA can change, particularly during recovery. Don't cache
the HLID before it was potentially allocated.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
commit 144614f3eebd7d only allowed a single active link when
turning on the optimization, ignoring the fact that an AP has two
additional global links.
Use 3 links as an indication for a single active link. Use the
FW PSM bits to verify the extra active link belongs to the AP role.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Maximum number of supported RX BA sessions depends on chip type.
wl18xx supports 5 RX BA sessions while wl12xx supports 3.
Signed-off-by: Igal Chernobelsky <igalc@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
It is requiered to enter sleep mode with smaller delay in forced PS mode.
This fixes issue of testing force PS mode during VoIP traffic where packets
are sent every 20ms. Chip never enters ps mode with default 30 ms delay
in such test.
Signed-off-by: Igal Chernobelsky <igalc@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Add P2P NoA settings for STA mode.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
[fix docs]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Schedule different time event based on the ROC type
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Increase the maximal remain on channel time as longer remain
on channel requests are handled by the FW using fragmented
time events.
This reduces the number of user/kernel space iterations during
flows such as p2p_listen. In addition it is currently required
for flows which require longer duration such as p2p_sd.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The RF-kill wakeup trigger flag is set in the wrong command,
which means it won't work. Also fix the comment in the TCP
wakeup trigger code -- the firmware was changed to look at
all the different trigger flags.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We should disable MIMO only if bt_traffic_load goes up to 3.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is the right source of information for the valid Tx
antennas, not the NVM.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This data should taken from TLVs and not from the NVM. This
is true for the value written in CSR_HW_IF_CONFIG_REG too.
Also, no need to set the CSR_HW_IF_CONFIG_REG_BIT_MAC_SI bit
for 7000 devices which are the only devices currently
supported.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In firmware "listener" (monitor) mode, we still need to
open up the filters with the filter flags to receive all
frames.
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This has valuable data about RFkill state seen from the fw
side.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
5ghz_disable has no effect any longer, that was changed during
refactoring of EEPROM reading/parsing. Remove it, wpa_supplicant
allow now to specify frequencies, on which device will operate.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
1. Quota for the monitor interface should be added only if there is
a channel context assigned to the interface.
2. In the unassign channel context flow, need to remove the quota
for the monitor interface binding, before unbinding.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This feature is not implemented yet in firmware.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The masks were wrong. They should be 0xffffffff when SCO,
HID or SNIFF profiles are used. They should be 0xffff0000
in any other case (default) to get a bit more throughput
when the BT profile allows for it.
Fix a debug print on the way.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
My new tracing code for ath6kl introduced these warnings on 64-bit:
trace.h:38:1: warning: format '%d' expects argument of type 'int',
but argument 4 has type 'size_t' [-Wformat]
trace.h:61:1: warning: format '%d' expects argument of type 'int',
but argument 4 has type 'size_t' [-Wformat]
trace.h:84:1: warning: format '%d' expects argument of type 'int',
but argument 6 has type 'size_t' [-Wformat]
trace.h:119:1: warning: format '%d' expects argument of type 'int',
but argument 7 has type 'size_t' [-Wformat]
trace.h:173:1: warning: format '%d' expects argument of type 'int',
but argument 3 has type 'size_t' [-Wformat]
trace.h:193:1: warning: format '%d' expects argument of type 'int',
but argument 5 has type 'size_t' [-Wformat]
trace.h:221:1: warning: format '%d' expects argument of type 'int',
but argument 5 has type 'size_t' [-Wformat]
Fix them by using %zd.
Reported-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is a race between the restart flow and the workers.
The workers are cancelled after the fw is already killed
and might send HCMD when there is fw to handle them.
Simply check that there is a fw to which the HCMD can be
sent before actually sending it.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We didn't update the internal of the PCIe transport when
we read the RFkill state directly. Fix that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As reported by Ben Hutchings, there was a harmless issue in
the checks being done on the lengths of the TBs while
building the TFD for a multi-TB host command.
Cc: stable@vger@kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In AP mode, don't attempt to program GTKs into the
device, they're used for TX only so not needed and
programming them causes error messages. Also, in
this case and if key programming fails, avoid trying
to remove the key that isn't present later.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The code removed in this patch was used for bring up on
older NICs. No MVM capable fw will ever be released for
older NICs, so remove that code.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When an interface change type, the CAB queue must be reassigned,
do this in hwsim to avoid warnings/crashes.
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Based on:
RT5592_IQCalibration()
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/cips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Enable support to 5592 chip.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
TXWI_STRUC
RXWI_STRUC
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/include/chip/rtmp_mac.h
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipAGCAdjust()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_RTMPAGCInit()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
AsicBBPWriteWithRxChain()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rtmp_chip.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This makes order of initialization of various registers similar like
on vendor driver.
Based on:
NICInitializeAsic()
RT5592LoadRFNormalModeSetup()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtmp_init.c
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chip/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
GetIQCalibration()
IQCalibration()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rtmp_chip.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipSwitchChannel()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipSwitchChannel()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
InitFrequencyCalibrationMode()
RT5592_ChipCap
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/frq_cal.c
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592LoadRFNormalModeSetup()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592LoadRFNormalModeSetup()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592RFRegisters()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592RFRegisters()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592RFRegisters()
RF5592Reg_2G_5G[]
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
This patch also merge common frequency adjustment (RF_R17 settings)
code. Further work is needed, to setup more RF/BBP/MAC registers after
that.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add BBP registers initialization common with other chipsets, but for now
performed only for 5592.
Based on:
NICInitBBP()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtmp_init.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592BbpRegisters()
NICInitBBP()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtmp_init.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592MacRegisters()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
On vendor driver we do not initialize TX_SW_CFG{1,2}. However the same
difference is between rt2x00 and vendor driver for 5390 chip.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipSwitchChannel()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipSwitchChannel()
RT5592_Frequency_Plan_Xtal20M[]
RT5592_Frequency_Plan_Xtal40M[]
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add basic defines for 5592 chip. It can not be enabled until
CONFIG_RT2800USB_RT55XX configuration option will be provided in the
Kconfig.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In case the spec->channels was not specified, print warning instead
of hard crash the kernel.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2800 hardware sometimes reorders tx frames when transmitting to
multiple BA enabled STAs concurrently.
For example a tx queue
[ STA1 | STA2 | STA1 | STA2 ]
can result in the tx status reports
[ STA1 | STA1 | STA2 | STA2 ]
when the hw decides to put the frames for STA1 in one AMPDU.
To mitigate this effect associate the currently processed tx status
to the first frame in the tx queue with a matching wcid.
This patch fixes several problems related to incorrect tx status
reporting. Furthermore the tx rate selection is much more stable when
communicating with multiple STAs.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit db36f79237
since I'm going to use the data pointer that was removed in
a follow up patch.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Firmware returned VHT cap has the same format that cfg80211
expects. There is no need to parse the vht cap from the firmware
and then set it to ieee80211_sta_vht_cap. Just copying is
sufficient.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
curr_cmd points to the command that is in processing or waiting
for its command response from firmware. If the function shutdown
happens to occur at this time we should cancel the cmd timer and
put the command back to free queue.
Cc: <stable@vger.kernel.org> # 3.8
Tested-by: Marco Cesarano <marco@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During rmmod mwifiex_sdio processing FUNC_SHUTDOWN command is
sent to firmware. Firmware expcets only FUNC_INIT once WLAN
function is shut down.
Any command pending in the command queue should be ignored and
freed.
Cc: <stable@vger.kernel.org> # 3.8
Tested-by: Daniel Drake <dsd@laptop.org>
Tested-by: Marco Cesarano <marco@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Running the following script repeatedly on XO-4 with SD8787
produces command timeout and system lockup.
insmod mwifiex_sdio.ko
sleep 1
ifconfig eth0 up
iwlist eth0 scan &
sleep 0.5
rmmod mwifiex_sdio
mwifiex_send_cmd_async() is called for sync as well as async
commands. (mwifiex_send_cmd_sync() internally calls it for
sync command.)
"adapter->cmd_queued" gets filled inside mwifiex_send_cmd_async()
routine for both types of commands. But it is used only for sync
commands in mwifiex_wait_queue_complete(). This could lead to a
race when two threads try to queue a sync command with another
sync/async command simultaneously.
Get rid of global variable and pass command node as a parameter
to mwifiex_wait_queue_complete() to fix the problem.
Cc: <stable@vger.kernel.org> # 3.8
Reported-by: Daniel Drake <dsd@laptop.org>
Tested-by: Daniel Drake <dsd@laptop.org>
Tested-by: Marco Cesarano <marco@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The beacon and multicast-buffer queues are managed by the beacon
tasklet, and the generic tx path hang check does not help in any way
here. Running it on those queues anyway can introduce some race
conditions leading to unnecessary chip resets.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit 'ath9k_hw: fix calibration issues on chainmask that don't
include chain 0' changed the hardware chainmask to the chip chainmask
for the duration of the calibration, but the revert to user
configuration in the reset path runs too early.
That causes some issues with limiting the number of antennas (including
spurious failure in hardware-generated packets).
Fix this by reverting the chainmask after the essential parts of the
calibration that need the workaround, and before NF calibration is run.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com>
Tested-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are a number of situations in which mac80211 only
really needs to flush queues for one virtual interface,
and in fact during this frames might be transmitted on
other virtual interfaces. Calculate and pass a queue
bitmap to the driver so it knows which queues to flush.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Either first 3 bytes of the first received tcp segment or last one
over MTU size file can be loss due to the byte alignment problem.
Although ATH6KL_HTC_ALIGN_BYTES was defined for 'extra bytes for htc header
alignment' in the patch "Fix buffer alignment for scatter-gather
I/O"(1df94a857), there exists the bytes loss issue which means that it will be
truncated 3 bytes in the transmitted file contents if a file which has over MTU
size is transferred through TCP/IP stack. It doesn't look like TCP/IP stack
bug of 3.5 or the latest version of kernel but the byte alignment issue. This
patch is to use the roundup() function for the byte alignment rather than the
predefined ATH6KL_HTC_ALIGN_BYTES.
kvalo: fixed indentation
Signed-off-by: Myoungje Kim <mjei78@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Dan found a check from ath6kl_rx() which doesn't make any sense at all:
" 1327 if (status || !(skb->data + HTC_HDR_LENGTH)) {
^^^^^^^^^^^^^^^^^^^^^^^^^^
skb->data is a pointer. This pointer math is always going to be false.
Should it be testing "packet->act_len < HTC_HDR_LENGTH" or something?"
I don't know what the check really was supposed to do, but I think Dan's guess
is right. Fix it accordingly.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Dan reported that smatch found a possible issue in ath6kl_wmi_beginscan_cmd()
where we might access sc->supp_rates beyond the end. It shouldn't happen as
ar->wiphy->bands always have just the first two bands set, but add an extra
check just to be sure.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Now all log messages are sent through the tracing infrastruture as well.
Tracing point doesn't follow debug_mask module parameter, instead it sends
all debug messages, so once you enable ath6kl_log_dbg tracing point you will
get a lot of messages. Needs to be discussed if this is sensible or not.
The overhead should be small enough and we anyway include debug level as
well so it's easy to filter in user space.
I wasn't really sure what to do with ath6kl_dbg_dump() and for now decided
that it also sends the buffer to user space. But most likely in the future
ath6kl_dbg_dump() should go away in favor of using proper tracing points, but
we will see.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add tracing points for htc layer, just dumping the packets to user space.
I wasn't really sure what to do with the status value, it might not always
be accurate, but I included it anyway.
I skipped htc_pipe (and usb) implementation for now. Need to add those
tracepoints later.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add a tracing point for hif irq and dump the register content to user space.
This is in hif.c as we could use the same code also with SPI but, as ath6kl
doesn't SPI and most likely never will be, this is used just by SDIO so
name the trace point as ath6kl_sdio_irq to make it easier to manage filters.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add basic tracing infrastructure support to ath6kl and which can be
enabled with CONFIG_ATH6KL_TRACING.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Julien reported that ar6004 usb device fails to initialise
after host has been rebooted and power is still on for the ar6004 device. He
found out that doing a cold reset fixes the issue.
I wasn't sure what would be the best way to detect if target needs a reset so I
settled on checking a timeout from htc_wait_recv_ctrl_message().
Reported-by: Julien Massot <jmassot@aldebaran-robotics.com>
Tested-by: Julien Massot <jmassot@aldebaran-robotics.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It was annoying to debug usb warm reboot initialisation problems as many usb
related functions just ignored errors and it wasn't obvious from the kernel
logs what was failing. Fix all that so that error messages are printed and
errors are handled properly.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Printin the firmware capabilities during the first firmware boot makes it easier to find out what
features firmware supports.
Obligatory screenshot:
[21025.678481] ath6kl: ar6003 hw 2.1.1 sdio fw 3.2.0.144 api 3
[21025.678667] ath6kl: firmware supports: sched-scan,sta-p2pdev-duplex,rsn-cap-override
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The firmware images are shared with libertas_sdio WiFi chip and used to be
in libertas/ subtree in linux-firmware. As btmrvl_sdio used to look into
the linux-firmware root, it ended up being unsuccessful. Since the
firmware files are not specific to the libertas hardware, they're being
moved into mrvl/ now.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
It was another sequence I recognized in HT-PHY dump:
phy_read(0x00c7) -> 0x0001
phy_read(0x00c3) -> 0x0000
phy_write(0x00c3) <- 0x0002
phy_read(0x00c3) -> 0x0000
phy_write(0x00c3) <- 0x0000
The difference to N-PHY is that it writes to 6 tables instead of a one
(after above).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Don't enable it until we have (almost?) whole TX power management
figured out. It's similar to the N-PHY, the difference is that we call a
"fix" *before* disabling power control.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It was just another similar-to-N-PHY and easy-to-track routine:
write32 0xb0601408 <- 0x00002057
phy_read(0x0001) -> 0x0000
phy_write(0x0001) <- 0x4000
phy_write(0x0001) <- 0x0000
write32 0xb0601408 <- 0x00002055
(b43_phy_ht_force_rf_sequence was moved up unmodified)
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On N-PHY it's also done after TX power fix, so it was easy to spot.
Unfortunately the MMIO logs I have from ndsiwrapper include channels
1-12 only, so enabling code for 13 and 14 is just a N-PHY-based guess.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On N-PHY after B43_PHY_B_TEST operation there is a call to TX power fix
function which iterates over available cores. It matches our HT-PHY code
which means it's probably also some TX fix.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After comparing operations on reg 0xB on N and HT it seems to be the
same register with similar ops. Implement them for HT-PHY.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It you take a look at N-PHY analog switch function it touches every core
on the chipset. It seems HT-PHY does they same, it just has 3 cores
instead of 2 (which make sense since BCM4331 is 3x3). Rename AFE defines
to include core id.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Firmware got support for temperature measurement.
There are 2 temperature sensors: MAC and radio
"not available" temperature - reported by FW as 0 or ~0
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adjust driver for changes in the FW API.
Noticeable changes in the FW are:
- temperature sensing
- infrastructure for multiple connections
- infrastructure for P2P
- signal strength indication
This commit introduces only changes that are required to support same functionality
as previous firmware, no new features.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
New firmware allows for shorter SW reset procedure.
After SW reset, FW raises "fw done" IRQ, at this
moment mailbox control structures are initialized, driver caches it.
New status bit wil_status_reset_done introduced to track completion
of the reset. It is set by "fw ready" irq, and required for WMI rx flow
to access control structures.
WMI Tx flow protected by other status bit, wil_status_fwready. It can't
be set before wil_status_reset_done is set by design.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
user space get notified through kobject_uevent_env(), that might sleep and thus
should run in thread context.
Move user space notification to the thread handler, while mark FW is non-functional
right in the hard IRQ.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pass to cfg80211 all management frames.
Used by wpa_supplicant.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Avoid unnecessary frame parsing
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move wmi_connect_worker() to the main.c and change names for consistency.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Extra reference was taken by mistake.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On the DMG band, there is no 'normal' beacon frame.
Instead, transmitted is short 'DMG beacon' frame, that do not include IE's
So, beacon IE's are not relevant for the DMG band.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Firmware indicated block ack agreement status change.
For now, just log it.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Firmware indicates linkup/linkdown when data path becomes ready.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This functionality now integrated in kernel, local hack not needed any more
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove including <linux/version.h> that don't need it.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since commit e565275 entitled "ssb: pci: Standardize a function to get mac
address", the SPROM readout of the MAC has had the values flipped so that
00:11:22:33:44:55 became 11:00:33:22:55:44. The fix has been tested on both
little- and big-endian architectures.
Reported-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since v3.9-rc1 the kernel has basic support for Ralink WiSoC. The config symbols
are named slightly different than before. Fix the rt2x00 to match the new
symbols.
The commit causing this breakage is:
commit ae2b5bb657
Author: John Crispin <blogic@openwrt.org>
Date: Sun Jan 20 22:05:30 2013 +0100
MIPS: ralink: adds Kbuild files
Signed-off-by: John Crispin <blogic@openwrt.org>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently the caps are parsed on every firmware reload, causing any
channel flags to be cleared.
When there is a firmware to interface mode mismatch, the triggered
firmware reload causes a reset of the regulatory settings, causing all
channels to become available:
root@openrouter:/# iw phy phy0 info
Wiphy phy0
Band 1:
(...)
Frequencies:
* 2412 MHz [1] (0.0 dBm)
* 2417 MHz [2] (0.0 dBm)
* 2422 MHz [3] (0.0 dBm)
* 2427 MHz [4] (0.0 dBm)
* 2432 MHz [5] (0.0 dBm)
* 2437 MHz [6] (0.0 dBm)
* 2442 MHz [7] (0.0 dBm)
* 2447 MHz [8] (0.0 dBm)
* 2452 MHz [9] (0.0 dBm)
* 2457 MHz [10] (0.0 dBm)
* 2462 MHz [11] (0.0 dBm)
* 2467 MHz [12] (0.0 dBm)
* 2472 MHz [13] (0.0 dBm)
* 2484 MHz [14] (0.0 dBm)
(...)
To prevent this, only parse the caps on the first firmware load during
hardware probe, and store them locally to know we have already parsed
them.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make local functions and tables static. Make ops table
Mark 3945 ops as read_mostly.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Initialize fw_entry to NULL to prevent cleanup code from passing
bogus pointer to release_firmware() when priv allocation fails.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It's harmless, but Smatch complains if we use "htc_hdr->eid" before
doing the bounds check.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
tx_timeout doesn't always lead to a cmd_timeout. There are
occurrences where cmd_timeout never gets triggered for a long
time and we encounter a kernel crash. In this patch, we track
the consecutive timeouts (tx_timeout_cnt). When tx_timeout_cnt
exceeds the threshold, trigger a card reset thereby avoiding a
kernel crash.
Signed-off-by: Ashok Nagarajan <asnagarajan@chromium.org>
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Host sleep wakeup condition is configured using this command.
Supports Wake-on: pumb
For examples:
wake-on any unicast packets:
ethtool -s mlan0 wol u
wake-on multicast/broadcast packet:
ethtool -s mlan0 wol mb
wake-on unicast packets and MAC events:
ethtool -s mlan0 wol pu
wake-on unicast/multicast/broadcast packets and MAC events:
ethtool -s mlan0 wol pmbu
disable all wake-on options:
ethtool -s mlan0 wol d
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
