In AP mode, configure the fw to pass beacons from
foreign APs, in order to be able to set the ht
protection IE properly.
Add the same filters in case of GO (which didn't have
any configured filter_flags, probably by mistake)
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Instead of code the fixed values, use a C99 initializer.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Randy fixes a few issues in iwlwifi's Kconfig. Because of
this, 'Debugging options' was not indented under iwlwifi
using menuconfig.
I added a few other fixes on the way, like the link to the
website and added 7265 in the supported NICs.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
[ Commit message + other fixes ]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The variable ret does not need to be assigned when declaring it. So
remove this initial assignment.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The ath3k driver is treating the version information badly when it
comes to loading the right firmware version and comparing that it
actually matches with the hardware.
Initially this showed up as this:
CHECK drivers/bluetooth/ath3k.c
drivers/bluetooth/ath3k.c:373:17: warning: cast to restricted __le32
drivers/bluetooth/ath3k.c:435:17: warning: cast to restricted __le32
However when fixing this by actually using __packed and __le32 for
the ath3_version structure, more issues came up:
CHECK drivers/bluetooth/ath3k.c
drivers/bluetooth/ath3k.c:381:32: warning: incorrect type in assignment (different base types)
drivers/bluetooth/ath3k.c:381:32: expected restricted __le32 [usertype] rom_version
drivers/bluetooth/ath3k.c:381:32: got int [signed] <noident>
drivers/bluetooth/ath3k.c:382:34: warning: incorrect type in assignment (different base types)
drivers/bluetooth/ath3k.c:382:34: expected restricted __le32 [usertype] build_version
drivers/bluetooth/ath3k.c:382:34: got int [signed] <noident>
drivers/bluetooth/ath3k.c:386:28: warning: restricted __le32 degrades to integer
drivers/bluetooth/ath3k.c:386:56: warning: restricted __le32 degrades to integer
This patch fixes every instance of the firmware version handling and
makes sure it is endian safe and uses proper unaligned access.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When HCI_CONNECTABLE is set the code has been enabling passive scanning
in order to be consistent with BR/EDR and accept connections from any
device doing directed advertising to us. However, some hardware
(particularly CSR) can get very noisy even when doing duplicates
filtering, making this feature waste resources.
Considering that the feature is for fairly corner-case use (devices
who'd use directed advertising would likely be in the whitelist anyway)
it's better to disable it for now. It may still be brought back later,
possibly with a better implementation (e.g. through improved scan
parameters).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
.set_bdaddr handler is implemented for public address configuration.
A reboot restores the bdaddr to its original address.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Implemented .set_bdaddr handler provided by bluetooth stack for
Marvell devices for public address configuration.
A reboot restores the bdaddr to its original address.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We don't need wall-clock time here, and in most configurations
that care, there are already timestamps in the kernel using
CONFIG_PRINTK_TIME=y.
Reported-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In managed mode if the driver is getting a re-associate command
from cfg80211, driver deauthenticates with the AP internally and
sends a disconnected event to cfg80211 before completion of its
association process. The disconnected event then modifies the
SSID length as wdev->ssid_len = 0. So, upon receiving the connect
result event from driver, cfg80211 is unable to get that BSS from
the device's BSS list and generates the following WARN_ON message.
WARNING: CPU: 0 PID: 857 at net/wireless/sme.c:658
__cfg80211_connect_result+0x3a6/0x3e0 [cfg80211]()
Avoid re-association while the device is already associated to a
network. Also remove the internal deauthentication from the
association path.
Signed-off-by: Ujjal Roy <royujjal@gmail.com>
Signed-off-by: Avinash Patil <patila@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>
This local variable is not used anywhere in function.
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>
By the way add few chipsets that were tracked with "wl" dumps.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Seems to be required by some hardware, wl does it every time.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Set up tx power for each MRR segment in the tx descriptor
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Packets originally buffered for the regular hardware tx queues can end
up being transmitted through the U-APSD queue (via PS-Poll or U-APSD).
When packets are dropped due to retransmit failures, the pending frames
counter is not always updated properly.
Fix this by keeping track of the queue that a frame was accounted for in
the ath_frame_info struct, and using that on completion to decide
whether the counter should be updated.
This fixes some spurious transmit queue hangs.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Just like in case of SSB SPROMs they are encoded in a bit tricky way.
SPROM struct already uses s8 type and it's supposed to store decoded
values.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is needed to properly handle early 802.11n devices like BCM4321.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
New register area defined in the firmware
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Firmware sets this register with the offset of the firmware trace area
within the peripheral memory region. Critical for the firmware trace
to work
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use single data source for all information regarding the firmware
memory map. With this change "ucode_xxx" regions disappears since
they are in fact part of larger "upper area" region
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If copy_from_user() fails, buffer allocated for parameters would leak
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Variable 'ctx' declarad again in the inner loop. Should use
one from outer loop instead.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
New hardware release appears; it require some changes to properly support it.
Introduce struct wil_board and "board" attribute in wil6210_priv;
keep hardware variant information in this structure.
fill it on probe(). Used in the reset flow.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The EOPNOTSUPP and ENOTSUPP errors are very similar in meaning, but
ENOTSUPP is a fairly new addition to POSIX. Not all libc versions know
about the value the kernel uses for ENOTSUPP so it's better to use
EOPNOTSUPP to ensure understandable error messages.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When lockdep isn't compiled, a local variable isn't used
(it's only in a macro argument), annotate it to suppress
the compiler warning.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When we're not pairable we should still allow us to act as initiators
for pairing, i.e. the HCI_PAIRABLE flag should only be affecting
incoming pairing attempts. This patch fixes the relevant checks for the
hci_io_capa_request_evt() and hci_pin_code_request_evt() functions.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Even though our side requests authentication, the original action that
caused it may be remotely triggered, such as an incoming L2CAP or RFCOMM
connect request. To track this information introduce a new hci_conn flag
called HCI_CONN_AUTH_INITIATOR.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We're interested in whether an authentication request is because of a
remote or local action. So far hci_conn_security() has been used both
for incoming and outgoing actions (e.g. RFCOMM or L2CAP connect
requests) so without some modifications it cannot know which peer is
responsible for requesting authentication.
This patch adds a new "bool initiator" parameter to hci_conn_security()
to indicate which side is responsible for the request and updates the
current users to pass this information correspondingly.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When a new hci_conn object is created the remote SSP authentication
requirement is set to the invalid value 0xff to indicate that it is
unknown. Once pairing completes however the code was leaving it as-is.
In case a new pairing happens over the same connection it is important
that we reset the value back to unknown so that the pairing code doesn't
make false assumptions about the requirements.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the current process is exiting, lingering on socket close will make
it unkillable, so we should avoid it.
Reproducer:
#include <sys/types.h>
#include <sys/socket.h>
#define BTPROTO_L2CAP 0
#define BTPROTO_SCO 2
#define BTPROTO_RFCOMM 3
int main()
{
int fd;
struct linger ling;
fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
//or: fd = socket(PF_BLUETOOTH, SOCK_DGRAM, BTPROTO_L2CAP);
//or: fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO);
ling.l_onoff = 1;
ling.l_linger = 1000000000;
setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));
return 0;
}
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
If user space has a NoInputNoOutput IO capability it makes no sense to
bother it with confirmation requests. This patch updates both SSP and
SMP to check for the local IO capability before sending a user
confirmation request to user space.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit 6c53823ae0 reshuffled the way the
authentication requirement gets set in the hci_io_capa_request_evt()
function, but at the same time it failed to update an if-statement where
cp.authentication is used before it has been initialized. The correct
value the code should be looking for in this if-statement is
conn->auth_type.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org # 3.16
The unwanted frame types are already handled in 'default' case
of the switch/case below.
The str_ptr is allocated but it can be leaked if the length check
fails in the REQUEST/RESP cases. Fix it by allocating sta_ptr
after the length checks.
Reported-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should check the blacklist no matter what, meaning also when we're
not connectable. This patch fixes the respective logic in the function
making the decision whether to accept a connection or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When we have at least one LE slave connection most (probably all)
controllers will refuse to initiate any new connections. To avoid
unnecessary failures simply check for this situation up-front and skip
the connection attempt.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Most (probably all) controllers can only deal with a single slave LE
connection at a time. This patch adds a counter for such connections so
that the number can be quickly looked up without iterating the
connections list.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We need to be able to track slave vs master LE connections in
hci_conn_hash, and to be able to do that we need to know the role of the
connection by the time hci_conn_add_has() is called. This means in
practice the hci_conn_add() call that creates the hci_conn_object.
This patch adds a new role parameter to hci_conn_add() function to give
the object its initial role value, and updates the callers to pass the
appropriate role to it. Since the function now takes care of
initializing both conn->role and conn->out values we can remove some
other unnecessary assignments.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
To make the code more understandable it makes sense to use the new HCI
defines for connection role instead of a "bool master" parameter. This
makes it immediately clear when looking at the function calls what the
last parameter is describing.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Having a dedicated u8 role variable in the hci_conn struct greatly
simplifies tracking of the role, since this is the native way that it's
represented on the HCI level.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
All HCI commands and events, including LE ones, use 0x00 for master role
and 0x01 for slave role. It makes therefore sense to add generic defines
for these instead of the current LE_CONN_ROLE_MASTER. Having clean
defines will also make it possible to provide simpler internal APIs.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
