Previously, each bus type was responsible for freeing the firmware
structure, but some did that badly. Move responsibility for freeing
firmware into firmware.c so that it's done once and correctly, instead
of happening in multiple places in bus-specific code.
This fixes a use-after-free bug found by Dr. H. Nikolaus Schaller where
the SDIO code forgot to NULL priv->helper_fw after freeing it.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add spectral scan feature on HT40 channels for ath9k. This patch extends
previous capability added by Simon Wunderlich
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Reviewed-by: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Tested-by: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add nf parameter to ath9k_hw_getchan_noise() in order to compute NF for EXT
chains with the same scale of noise floor calculated on CTL chains.
ath9k_hw_getchan_noise() will be used in ath_process_fft() for spectral scan on
HT40 channels
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It's a fairly big one, with the following highlights:
- NFC digital layer implementation: Most NFC chipsets implement the NFC
digital layer in firmware, but others have more basic functionalities
and expect the host to implement the digital layer. This layer sits
below the NFC core.
- Sony's port100 support: This is "soft" NFC USB dongle that expects the
digital layer to be implemented on the host. This is the first user of
our NFC digital stack implementation.
- Secure element API: We now provide a netlink API for enabling,
disabling and discovering NFC attached (embedded or UICC ones) secure
elements. With some userspace help, this allows us to support NFC
payments.
Only the pn544 driver currently supports that API.
- NCI SPI fixes and improvements: In order to support NCI devices over
SPI, we fixed and improved our NCI/SPI implementation. The currently
most deployed NFC NCI chipset, Broadcom's bcm2079x, supports that mode
and we're planning to use our NCI/SPI framework to implement a
driver for it.
- pn533 fragmentation support in target mode: This was the only missing
feature from our pn533 impementation. We now support fragmentation in
both Tx and Rx modes, in target mode.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSUqvzAAoJEIqAPN1PVmxKKHEP/1mK8kWx9ZZ8egkrkzaTw4lW
J9uJq2kTGv5tfEfWjuigAhz5kHB6qLTJLx8FEBZAHazLfa4Az0Zm2G7I7+GTQAMV
Mw+uAAI22GGnNgdTNzXDAqgS76Eul2PiWf2UwAbKFZWiyEj5Vf/eZBJAS9nTKLM3
En37wBjvMpVgj6ZwOHKsqPR801NSa3HiM653tkmgSsk3QVL3b7s+kynSuAtshsmA
twzymUoJFfYePVnQNRnT3PVPR6w0tRNs4vdq8j5UUuoj1vgKC0/h6nIz2aCURwyE
j1pQlSy4ykASM8QZNI2jv3VaOFxmASig2GOgzvCeBZOmCBdlNq13ZY/T0SmmiYES
LTbg6Pmh5BXID95GqcFcJaC+iS+QNZK+RWhNYmj+JWCuqZ9Qcja3++IoQ7m/pAip
WfyQsO7lD7wPhXUu4IMxfyKNu8u4nCiHdBMp7TBVXiWIVUMxIcoM0auNW4O1qSvW
eLq0f1oqQXE9hIrJ4oYUZmn9D5CKRLIXr9SVcmat+VxmV/+jFgV5cMQIGRdDAEUq
4g5g7Avbpkkccn9wdFaIm0VpxMebaNFSWVfBOw4L7PF56lqns6shBcq3W3OvDf60
/Tn0oe9Qqvr17xarJackFkF8beBkJaKOJv9M5+KjlVgGexcNMMTIiwj8aPl6+mqC
t5n6tCp0g941jB3qAV2G
=K1A5
-----END PGP SIGNATURE-----
Merge tag 'nfc-next-3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next
Samuel Ortiz <sameo@linux.intel.com> says:
"This is the first NFC pull request for the 3.13 kernel.
It's a fairly big one, with the following highlights:
- NFC digital layer implementation: Most NFC chipsets implement the NFC
digital layer in firmware, but others have more basic functionalities
and expect the host to implement the digital layer. This layer sits
below the NFC core.
- Sony's port100 support: This is "soft" NFC USB dongle that expects the
digital layer to be implemented on the host. This is the first user of
our NFC digital stack implementation.
- Secure element API: We now provide a netlink API for enabling,
disabling and discovering NFC attached (embedded or UICC ones) secure
elements. With some userspace help, this allows us to support NFC
payments.
Only the pn544 driver currently supports that API.
- NCI SPI fixes and improvements: In order to support NCI devices over
SPI, we fixed and improved our NCI/SPI implementation. The currently
most deployed NFC NCI chipset, Broadcom's bcm2079x, supports that mode
and we're planning to use our NCI/SPI framework to implement a
driver for it.
- pn533 fragmentation support in target mode: This was the only missing
feature from our pn533 impementation. We now support fragmentation in
both Tx and Rx modes, in target mode."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Integers need to be multiplied before division.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The fw_rx_stats entry in debugfs was getting truncated because the
internal buffer used to hold the string was too short. The
calculation of the needed buffer size was rather bogus.
Simplify the calculation by multiplying the number of entries in the
entire structure by the size of each data line and adding the size of
the header lines.
Additionally, add the mac_id value, which was missing.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The activity grading indication from the firmware should
not be used in this case, but the bt_status in the firwmare
notification.
Fix that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The firmware always expects the Coex Mode to be set.
Moreover, the firmware expects bit 0 is the valid bits to
be set all the times.
I misunderstood the API and didn't set these bits when
commands are sent to update the paramters of the Coex. As
a result, the firmware understood that the BT Coex was
disabled (Coex mode = 0) and ignored all the updates (valid
bit 0 clear).
Fix that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Section size limitation to 6000 is incorrect.
NVM file need to support bigger sections in order
to support PAPD tables.
Signed-off-by: Idan Kahlon <idanx.kahlon@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Maor Perez <maorx.perez@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ath10k_wmi_cmd_send() will now sleep if there are no credits available.
To make it easier to catch callers in atomic context add might_sleep()
to the function.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k_bss_assoc() was calling ath10k_peer_assoc(), which can sleep, under
atomic rcu_read_lock() and causing scheduing while atomic errors. Workaround
that by delaying the call to ath10k_wmi_peer_assoc().
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
mac80211 interface iteration functions that were
used originally iterated over interfaces that
weren't re-added to the driver during recovery.
Since internal vif list is now used it's safe to
remove the safe-guard as internal vif list is
based on add/remove_interface function which
guarantees that vdev is created in FW before it is
iterated over.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Recent HTC/WMI changes introduced the bug. ath10k
was using _atomic iteration function with
sleepable functions.
mac80211 provides another iteration function but
it cannot be safely called in hw_config() callback
due to local->iflist_mtx being possibly acquired
already.
The patch uses internal vif list for iteration
purposes and removes/refactors no longer necessary
_iter functions.
Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
mac80211 interface interations functions have
peculiar locking issues. This patch introduces
internal (to ath10k) vif list that will be used
for vif iteration purposes.
kvalo: remove extra INIT_LIST_HEAD()
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
If something failed along add_interface() setup it
was possible to leak a vdev id, vdev and peer.
This could end up with leaked FW state or FW crash
(assuming add_interface() failure wasn't a result of
a crash).
kvalo: rebased, whitespace fixes
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Recent WMI/HTC changes made it possible for WMI
commands to sleep (if there's not enough HTC TX
credits to submit a command). TX path is in an
atomic context so calling WMI commands in it is
wrong.
This simply moves WEP key index update to a worker
and fixes the 'scheduling while atomic' bug.
This still leaves multiple WEP key handling laggy,
i.e. some frames may be TXed with an old/different
key (although recipient should still be able to RX
them).
kvalo: changed the title
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Return -EOPNOTSUPP if given parameter is not supported by firmware.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Rename WMI_CMD_UNDEFINED to WMI_CMD_UNSUPPORTED. This is more
accurate here. Also return -EOPNOTSUPP instead of -EINVAL in
wmi_cmd_send().
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
10.X firmware does not support WMI_VDEV_PARAM_TX_ENCAP_TYPE.
It's a known limitation and we should not warn about this.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Read the current IAC LAP values when initializing the controller. The
values are not used, but it is good to have them in the trace files
for debugging purposes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
When initializing a controller make sure to read out the number of
supported IAC and store its result. This value is needed to determine
if limited discoverable for BR/EDR can be configured or not.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The scan window parameter for connection establishment and passive
scanning needs to be smaller or equal than the scan interval.
Instead of waiting for a controller to reject these values later on,
just reject them right away.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
If a socket was bound to an address type other than BR/EDR (such as LE)
we should reject trying to connect it to a BR/EDR address. The same
applies for binding to BR/EDR and trying to connect to non-BR/EDR.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We need to verify that the bdaddr type passed to connect() and bind() is
within the set of valid values. If it is not we need to cleanly fail
with EINVAL.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch converts Set Discoverable to use an asynchronous request
along with its own completion callback. This is necessary for splitting
raw HCI socket use cases from mgmt, as well as for enabling the hooking
up of Advertising parameters together with the HCI_DISCOVERABLE flag
(coming in later patches).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Now that the connectable setting is also applicable for the LE side it's
possible that the HCI_CONNECTABLE flag is already set when changing the
BR/EDR setting from false to true while the controller is powered. In
this situation we need to update the BR/EDR scan mode to reflect the
setting. Additionally, since HCI_CONNECTABLE also applies to LE we must
not clear the HCI_CONNECTABLE flag when disabling bredr.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The set_bredr_scan() function will soon be needed by the set_bredr()
function, so move it to a new location to avoid having to add a forward
declaration.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch updates the Set Connectable Management command to also update
the LE advertising type to either connectable or non-connectable
advertising. An extra helper function is needed for getting the right
advertising type since we can not only rely on the HCI_CONNECTABLE flag
but must also check for a pending Set Connectable command (in which case
the flag does not yet have its final value).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
lready have rf_vals_3x with same values. Hence rf_vals_3053 is removed
in this patch.
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update rf registers to use the same values that the MediaTek/Ralink
reference driver DPO_RT5572_LinuxSTA_2.6.1.3_20121022 uses.
References:
RF5390RegTable in chips/rt5390.c
RF5392RegTable in chips/rt5390.c
Tested on TP-Link TL-WN727N and D-Link DWA-140 Rev.b3 usb wifi dongles.
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Accessing it to get the current operating channel is racy and in the way
of further channel handling related changes
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is not exposed as a configuration option anyway
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Preparation for adding the scanning state machine to ath9k
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rework its wrapper function to make it more generic, using it as a
replacement for previous calls to ath9k_cmn_update_ichannel.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There was some duplication between channelFlags and chanmode, as well as
a lot of redundant checks based on the combinations of flags.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The hardware is always configured with OFDM support enabled
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hardware 802.11b-only mode isn't supported by the driver (the device is
configured for 802.11n/g instead). Simplify the code by removing checks
for it.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use wrappers where available. Simplifies code and helps with further
improvements to the channel data structure
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's no shared code for handling both rx and tx buffers, and tx
buffers require a lot more metadata than rx buffers.
Using a separate data structure for rx reduces memory usage and improves
cache footprint.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drivers/net/wireless/ath/wcn36xx/debug.c:27:11-31: WARNING opportunity for simple_open, see also structure on line 106
/c/kernel-tests/src/i386/drivers/net/wireless/ath/wcn36xx/debug.c:27:11-31: WARNING opportunity for simple_open, see also structure on line 148
This removes an open coded simple_open() function
and replaces file operations references to the function
with simple_open() instead.
Generated by: coccinelle/api/simple_open.cocci
CC: Eugene Krasnikov <k.eugene.e@gmail.com>
CC: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the appropriate helper functions instead of
directly accessing the rt2x00dev->cap_flags field
to check device capability flags.
This improves readability of the code a bit.
Compile tested only.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the appropriate helper functions instead of
directly accessing the rt2x00dev->cap_flags field
to check device capability flags.
This improves readability of the code a bit.
Compile tested only.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the appropriate helper functions instead of
directly accessing the rt2x00dev->cap_flags field
to check device capability flags.
This improves readability of the code a bit.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the appropriate helper functions instead of
directly accessing the rt2x00dev->cap_flags field
to check device capability flags.
This improves readability of the code a bit.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The rt2x00 code directly accesses the 'cap_flags'
field of 'struct rt2x00_dev' when checking presence
of a given capability flag. The direct access needs
long expressions which lowers readability of the code.
Add a few helper functions which can be used to test
device capabilities without directly accessing the
cap_flags filed.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Dan Williams
Lorenzo Bianconi
John W. Linville
David Spinadel
Luciano Coelho
Emmanuel Grumbach
Idan Kahlon
Kalle Valo
Michal Kazior
Bartosz Markowski
Marcel Holtmann
Johan Hedberg
Kevin Lo
Amitkumar Karwar
Felix Fietkau
Fengguang Wu
Gabor Juhos