> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> @@ -2971,7 +2971,11 @@ static int ath6kl_stop_ap(struct wiphy *wiphy,
> struct net_device *dev)
> return -ENOTCONN;
>
> ath6kl_wmi_disconnect_cmd(ar->wmi, vif->fw_vif_idx);
> +
> + spin_lock_bh(&vif->if_lock);
>
C bitfields are problematic and best avoided. Developers
interacting with hardware registers find themselves searching
for easy-to-use alternatives. Common approach is to define
structures or sets of macros containing mask and shift pair.
Operations on the register are then performed as follows:
Use the newly added linux/bitfield.h.
Signed-off-by: Jakub Kicinski
---
drivers/net/wireless/mediatek/mt7601u/dma.h | 2 -
drivers/net/wireless/mediatek/mt7601u/mt7601u.h | 5 +-
drivers/net/wireless/mediatek/mt7601u/util.h| 77 -
3 files changed, 4 insertions(+
Hi!
This set moves to a global header file macros which I find
very useful and worth popularising. The basic problem is
that since C bitfields are not very dependable accessing
subfields of registers becomes slightly inconvenient.
It is nice to have the necessary mask and shift operations
wrapped
Hi Kalle,
Here are some patches intended for 4.8. I have a lot more patches
pending in our internal tree, but I decided to take smaller steps
because it's easier to find a few hours to push a few patches than it
is to find many hours to send all pending patches. Is it okay for you
if I send a bu
The commit 7311ea850079 ("mwifiex: fix AP start problem for newly added
interface") attempted to fix an issue when a new AP interface is added.
But the patch didn't check the return value of the functions doing the
firmware calls and returned an error even if the functions didn't fail.
This preve
Hi,
On Thu, Jun 30, 2016 at 3:21 PM, Brian Norris wrote:
> The PCIe driver didn't mask the host interrupts before trying to tear
> down. This causes lockups at reboot or rmmod when using MSI-X on 8997,
> since the MSI handler gets confused and locks up the system.
>
> Also tested on 8897, which d
When disabling tethering after having enabled it, the ath6kl driver does
not set the IFF_LOWER_UP flag to 0 (carrier off) on the wlan interface.
The upper layers (eg. connman) are not notified of the tethering mode
status change. So, tethering can not be activated anymore.
This patch adds a netif
These 3 patchs fix problems detected when using tethering mode with a
AR9374 chipset.
Pierre Le Magourou (3):
ath6kl: Fix WLAN tethering authentication problem.
ath6kl: Fix wrong regulatory domain disconnection.
ath6kl: Unset IFF_LOWER_UP flag on AP mode leave.
drivers/net/wireless/ath/ath
When enabling WLAN tethering, a new AP is visible and a STA could
connect to it. When the STA tries to authenticate to the newly created
AP, the WPA authentication mechanism is stuck in the 1/4 msg of 4-Way
Handshake.
In ath6kl_rx(), the ath6kl_find_sta() function is looking for the
h_source field
One minute after a successful connection, the kernel checks if the
frequency and the channel width are well configured for the country we
are in. (regulatory domain)
ath6kl driver was setting the NL80211_CHAN_HT20 channel without checking
for the HT capabilities. (we should have NL80211_CHAN_NO_HT
just to comply with current ath9k_hw_nvram_read to return value, hence
behaving reacting accordingly.
Signed-off-by: Eduardo Abinader
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003
just to comply with current ath9k_hw_nvram_read to return value, hence
behaving reacting accordingly.
Signed-off-by: Eduardo Abinader
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003
From: Shengzhen Li
As interrupt is read in interrupt handler as well as interrupt processing
thread, we observed a corner case issue for MSI in which interrupt gets
processed twice.
This patch moves interrupt reading code for MSI mode from
mwifiex_interrupt_status() to mwifiex_pcie_process_int()
As hw cycle counters in QCA4019 wraparound independantly in QCA4019
it is possible cycle counter and rx clear counter would wraparound
at the same time. Current logic assumes only one of the counters
would wraparound at anytime. Fix this by moving 'else' part to
another 'if'.
Fixes: 8e100354a98 ("
Ignore this patch. Sorry for the noise.
-Original Message-
From: linux-wireless-ow...@vger.kernel.org
[mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of
c_tr...@qti.qualcomm.com
Sent: Friday, July 01, 2016 3:22 PM
To: ath...@lists.infradead.org
Cc: linux-wireless@vger.kernel.org;
From: Tamizh chelvam
BTCOEX feature is not available in all qca40xx chipsets.
To expose the btcoex support, this patch add btcoex_support
flag in device tree. If this value is 1 then the hardware
supports btcoex and 0 for not support.
Signed-off-by: Tamizh chelvam
---
v3:
* separated from ath
On Friday, July 1, 2016 10:17:37 AM CEST Arend Van Spriel wrote:
>
> On 1-7-2016 4:08, Rob Herring wrote:
> > On Wed, Jun 29, 2016 at 04:04:31PM +0200, Hans de Goede wrote:
> >> Add a brcm,nvram_file_name dt property to allow overruling the default
> >> nvram filename for sdio devices. The idea is
On 1-7-2016 11:07, Rafał Miłecki wrote:
> On 30 June 2016 at 21:24, Michael Eskowitz wrote:
>> insmod brcmfmac.ko
>> firmware_path=ISM4334X_Wifi_FW_6.10.190.49_P.bin
>> nvram_path=ISM4334X_NVRAM_C1.txt
>>
>> I receive the following errors:
>>
>> brcmfmac: Unknown symbol brcmu_pktq
On 30 June 2016 at 21:24, Michael Eskowitz wrote:
> insmod brcmfmac.ko
> firmware_path=ISM4334X_Wifi_FW_6.10.190.49_P.bin
> nvram_path=ISM4334X_NVRAM_C1.txt
>
> I receive the following errors:
>
> brcmfmac: Unknown symbol brcmu_pktq_mlen (err 0)
> brcmfmac: Unknown symbol
Hi,
On 30 June 2016 at 21:23, Arend Van Spriel wrote:
>
>
> On 30-6-2016 13:31, Arnd Bergmann wrote:
>> On Thursday, June 30, 2016 12:25:15 PM CEST Hans de Goede wrote:
So then how about making use of a more specific compatible string?
e.g.
brcmf {
compatible
On Thursday, June 30, 2016 9:23:56 PM CEST Arend Van Spriel wrote:
>
> On 30-6-2016 13:31, Arnd Bergmann wrote:
> > On Thursday, June 30, 2016 12:25:15 PM CEST Hans de Goede wrote:
> >>> So then how about making use of a more specific compatible string?
> >>>
> >>> e.g.
> >>>
> >>> brcmf {
> >>>
On 1-7-2016 4:08, Rob Herring wrote:
> On Wed, Jun 29, 2016 at 04:04:31PM +0200, Hans de Goede wrote:
>> Add a brcm,nvram_file_name dt property to allow overruling the default
>> nvram filename for sdio devices. The idea is that we can specify a
>> board specific nvram file, e.g. brcmfmac43362-ap
On 30-6-2016 21:24, Michael Eskowitz wrote:
> I am trying to bring up the brcmfmac driver on an iMX6 Ultralite board. I
> have both a 43341 and 43362 Wi-Fi SDIO module up and running on this
> platform already using the standard bcmdhd. I am told by some Broadcom
> folks that the brcmfmac driver
From: Tamizh chelvam
This patch adds testmode support for 10.4 based chipsets
and added code swap support for UTF binary.
Signed-off-by: Tamizh chelvam
---
drivers/net/wireless/ath/ath10k/testmode.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/wire
From: Tamizh chelvam
Currently testmode events for 10.x firmware are processed from
10.1 wmi event processing. This patch is used to handle testmode
events in 10.2 and 10.4 based firmware.
Signed-off-by: Tamizh chelvam
---
drivers/net/wireless/ath/ath10k/wmi.c | 26 ++
From: Tamizh chelvam
Preparation to make use of firmware_swap_code_seg_info for UTF binary.
Signed-off-by: Tamizh chelvam
---
drivers/net/wireless/ath/ath10k/core.c |6 +++---
drivers/net/wireless/ath/ath10k/core.h |6 ++
drivers/net/wireless/ath/ath10k/swap.c | 26 ++
From: Tamizh chelvam
* The below patches add testmode support for 10.4.
* Some of the codeswap related code in ath10k for example code which
initializes the code swap segment works only on normal fw, below patches
make such code generic so that it can be used for utf binary as well.
Tamiz
28 matches
Mail list logo
