- 29 Oct, 2012 33 commits
-
-
Hante Meuleman authored
Variable iswl always gets initialised to the same and support for this var is not needed. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hante Meuleman authored
Refactor the functions that are related to getting and setting data to and and from the firmware. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
carl9170_handle_mpdu is the final part of the rx path of the driver. It splits the raw data streams from the device into skb packets and passes them on to mac80211. As a result of continuous updates, it grew over the years when new code was added by the following commits: - report A-MPDU status - fix HT peer BA session corruption - A-MPDU frame type filter - ... This patch splits the routine into two stages. The first stage only deals with the details about extracting and verifying the data from the incoming stream. Whereas the second stage packs it into skbs and passes it on to mac80211. Reported-by: Javier Lopez <jlopex@cozybit.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Avinash Patil authored
We derive mwifiex_private structure which is per interface from received skb's rx_info. Once priv is derived, same priv can be propagated to other functions instead of callee deriving priv from rx_info again. 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>
-
Avinash Patil authored
During start_ap handler, some rates come as extended supported rates IE - part of beacon tail IE. This patch adds support for parsing them and adding to bss_rates TLV for bss_start command to firmware. 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>
-
Amitkumar Karwar authored
This reverts commit 34202e28 We made "34202ee.." because we didn't support custom regulatory rules at that time. But now we use our own custom regulatory rules, so it needs to be changed back. Also, chan->max_power calculations in cfg80211 were broken. Hence we started using chan->max_reg_power. Now it has got fixed in following commit. commit 5e31fc08 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Tue Jul 24 08:35:39 2012 +0200 wireless: reg: restore previous behaviour of chan->max_power calculations Hence we will use chan->max_power instead of chan->max_reg_power. 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>
-
Amitkumar Karwar authored
If MWIFIEX_DISABLE_CHAN_FILT bit in scan mode bitmap is set, firmware will turn off the filtering of scan responses from adjacent channels. Currently the bit is set only for internal SSID specific scan performed during association. We will set it for user requested SSID specific scan as well. 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>
-
Amitkumar Karwar authored
mwifiex_request_scan() takes care of synchronous internal scan performed by driver during association. Currently the semaphore acquired for the scan is unnecessarily released at the end of different paths. Also, failure paths returning error code other than "-1" are not considered. We will release it at the end of routine to fix above issues. 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>
-
Amitkumar Karwar authored
When the interface is down, we will abort scan by calling cfg80211_scan_done() with abort option. This fixes WARN_ON triggered by cfg80211 in wdev_cleanup_work(). Driver's internal variables/flags are cleared once we get response for current scan command. Meanwhile we will block new scan request from cfg80211. 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>
-
Amitkumar Karwar authored
We will delay/abort scan operation based on traffic for low priority scan. 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>
-
Yuanhan Liu authored
This will fix warnings like following when CONFIG_PM_SLEEP is not set: warning: 'xxx_suspend' defined but not used [-Wunused-function] warning: 'xxx_resume' defined but not used [-Wunused-function] Because SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) Only references the callbacks on CONFIG_PM_SLEEP (instead of CONFIG_PM). Cc: John W. Linville <linville@tuxdriver.com> Cc: "Rafał Miłecki" <zajec5@gmail.com> Cc: linux-wireless@vger.kernel.org Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
When the BT connection is initiated by headset, it's possible that headset requests to make one A2DP and one Voice connection over the same link. BT firmware will send a new profile A2DP_Voice in this case. So WLAN has to take care of this new profile for tuning BTCOEX parameters. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Whenever i_coff of IQ calibration is too high, AR9565 drops max rx rate to MCS4. Skipping IQ update at this time can avoid this problem for AR9565. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
While resuming from S3, BT host issues HCI reset command and it causes BT firmware to busy with security key calculation. At this movement, WLAN detects MCI hardware error of MCI_CONT_INFO_TIMEOUT and then it starts the recovery sequence repeatedly. Too many recovery sequences would exhaust the BT kernel message pool. This patch imposes a duration between consecutive BT recovery procedure. Thus it solves BT firmware panic issue reported in AR9565. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bala Shanmugam authored
TXIQ and RXIQ share the same data path to upload the measurement result, we should turn off RXIQ calibration while re-calibrating radio Signed-off-by: Bala Shanmugam <bkamatch@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bala Shanmugam authored
Signed-off-by: Bala Shanmugam <bkamatch@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Self generated MCI messages is configured to use chain 1. As ar9565 is 1x1 solution, It can not use Chain 1. Hence fix Chain 1 for ar9462 alone. Not doing so, could affect WLAN connectivity in ar9565 as LNA sharing is not informed by BT. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
The simulataneous transmission of both WLAN and BT might cause increase in power levels. To avoid regulatory violation, WLAN tx power will be adjusted according to BT power index based on avaliability of BT scheduling messages. WLAN tx power reduction might affect its performance. So WLAN tx power is only be lowered when the signal strength is good enough. Otherwise concurrent tx will be disabled and WLAN uses it default power levels. Also concurrent tx is disabled whenever WLAN is moving to off-channel which might be used by BT. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
It is useful to have channel mode in caldata to find out whether operaing channel is in HT40/20 when we are currently on offchannel. It will be used by BTCOEX to enable/disable concurrent tx mechanism later. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
This feature enables both WLAN and BT can transmit simultaneously by setting WLAN and BT to equal priorities. Whenever both are transmitting, it might violate regulatory power limits. To avoid regulatory violation, WLAN tx power will be adjusted according to BT power index based on avaliability of BT scheduling message. If the combined power exceeds threshold, BT transmission will be held off. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
WLAN updates channel bitmap when associated and disassociated. Channel bitmap will reflect whare are the channels used or affected by WLAN and BT should avoid using those. Not doing so, could affect BT traffic as both WLAN and BT is operating on same channel. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mohammed Shafi Shajakhan authored
Currently ath9k need to have beacon interval matched between STA mode and beaconing mode. Advertize this through interface combinations. Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mohammed Shafi Shajakhan authored
Once the driver advertizes interface combination logic based on its firmware/hardware limitation, cfg80211 takes care of all the necessary logic such as maximum beaconing vifs, standlone interface etc. Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mohammed Shafi Shajakhan authored
This will allow us to create virtual interface the driver supports. Also this ensures multivif support and limitation advertised by the driver is taken care in cfg80211 itself. Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mohammed Shafi Shajakhan authored
When WLAN is idle ensure we downgrade to FTP_STOMP_LOW weight (from STOMP_LOW) to provide more bandwidth for BT FTP profile. WLAN's idleness can be estimated by taking into account of the rx data packets and just ignore beacons, qos nullfunc etc. Also update bt_wait_time even if the chip is in NETWORK SLEEP mode. This should help BT throughput when WLAN is idle. Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
Several people have complained about an unusual and undocumented feature of the AR9170 hardware: In siffer mode, the hardware generates spurious ACK frames for every received frame... even broadcasts. The reason for this malfunction is unknown: <http://marc.info/?l=linux-wireless&m=134517238506033> But there's a workaround: Instead of the special sniffer mode, the hardware will be put into station mode and all rx filters are disabled. Reported-by: Johannes Berg <johannes@sipsolutions.net> Reported-by: Marco Fonseca <marco@tampabay.rr.com> Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0John W. Linville authored
This is the first NFC pull request for 3.8 With this one we have: - pn544 p2p support. - pn544 physical and HCI layers separation. We are getting the pn544 driver ready to support non i2c physical layers. - LLCP SNL (Service Name Lookup). This is the NFC p2p service discovery protocol. - LLCP datagram sockets (connection less) support. - IDR library usage for NFC devices indexes assignement. - NFC netlink extension for setting and getting LLCP link characteristics. - Various code style fixes and cleanups spread over the pn533, LLCP, HCI and pn544 code.
-
- 28 Oct, 2012 1 commit
-
-
Thierry Escande authored
NFC_CMD_LLC_GET_PARAMS: request LTO, RW, and MIUX parameters for a device NFC_CMD_LLC_SET_PARAMS: set one or more of LTO, RW, and MIUX parameters for a device. LTO must be set before the link is up otherwise -EINPROGRESS is returned. RW and MIUX can be set at anytime and will be passed in subsequent CONNECT and CC messages. If one of the passed parameters is wrong none is set and -EINVAL is returned. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
- 26 Oct, 2012 6 commits
-
-
Samuel Ortiz authored
The Tx queues are no longer valid when we receive a disconnection or when the LLCP link goes down. In the later case we also purge the entire local Tx queue. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Kees Cook authored
This config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it. Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Kees Cook authored
This config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it. Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Kees Cook authored
This config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it. Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Szymon Janc authored
Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-
Samuel Ortiz authored
As a consequence the NFC device IDs won't be increasing all the time, as IDR provides the first available ID. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
-