* Re: Implementing Mikrotik IE
From: Josef Miegl @ 2019-08-22 21:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: Sebastian Gottschall, linux-wireless
In-Reply-To: <0452a0cbb36bcffa8371a58dfd931864c1f79eef.camel@sipsolutions.net>
On August 22, 2019 10:08:13 PM GMT+02:00, Johannes Berg <johannes@sipsolutions.net> wrote:
>On Thu, 2019-08-22 at 09:00 +0200, Johannes Berg wrote:
>>
>> Perhaps it expects the 4-way-HS to already be in 4-addr frame format,
>or
>> something else special in the 4-way-HS if you have WDS?
>
>I think this is actually the right guess.
Yes, it indeed it! Thank you so much Johannes!
>As a hack, you could do
>
>--- a/net/mac80211/tx.c
>+++ b/net/mac80211/tx.c
>@@ -2623,8 +2623,7 @@ static struct sk_buff *ieee80211_build_hdr(struct
>ieee80211_sub_if_data *sdata,
> memcpy(hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
> memcpy(hdr.addr3, sdata->u.mgd.bssid, ETH_ALEN);
> hdrlen = 24;
>- } else if (sdata->u.mgd.use_4addr &&
>- cpu_to_be16(ethertype) !=
>sdata->control_port_protocol) {
>+ } else if (sdata->u.mgd.use_4addr) {
> fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS |
> IEEE80211_FCTL_TODS);
> /* RA TA DA SA */
>
>
>in mac80211, then it should send 4-addr frames even for EAPOL.
Works great. Is there a possibility that a toggle for this could be accepted upstream? After all, WDS isn't really standardized.
Thank you!
Josef
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Johannes Berg @ 2019-08-22 20:08 UTC (permalink / raw)
To: Josef Miegl; +Cc: Sebastian Gottschall, linux-wireless
In-Reply-To: <5ee160209eb1f9e70f6224c393389266280d7d80.camel@sipsolutions.net>
On Thu, 2019-08-22 at 09:00 +0200, Johannes Berg wrote:
>
> Perhaps it expects the 4-way-HS to already be in 4-addr frame format, or
> something else special in the 4-way-HS if you have WDS?
I think this is actually the right guess.
The working capture you sent me has the EAPOL 2/4 in a 4-addr frame:
ToDS=1, FromDS=1
A1/RA = AP
A2/TA = STA
A3/DA = AP
A4/SA = STA
The non-working capture has the EAPOL 2/4 in 3-addr format, as you'd
expect in the Linux 4-addr AP/STA case:
ToDS=1, FromDS=0
A1/RA = AP
A2/TA,SA = STA
A3/DA = AP
Since it's basically ignoring the message 2 (it just says "handshake
timed out" later) it's almost certainly expecting *only* the 4-addr
format.
As a hack, you could do
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2623,8 +2623,7 @@ static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,
memcpy(hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
memcpy(hdr.addr3, sdata->u.mgd.bssid, ETH_ALEN);
hdrlen = 24;
- } else if (sdata->u.mgd.use_4addr &&
- cpu_to_be16(ethertype) != sdata->control_port_protocol) {
+ } else if (sdata->u.mgd.use_4addr) {
fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS |
IEEE80211_FCTL_TODS);
/* RA TA DA SA */
in mac80211, then it should send 4-addr frames even for EAPOL.
johannes
^ permalink raw reply
* [PATCH] regdb: fix compatibility with python2
From: Johannes Berg @ 2019-08-22 19:46 UTC (permalink / raw)
To: linux-wireless, Seth Forshee; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Various changes in the commit mentioned below broke
compatibility with python2. Restore it in a way that
makes it worth with both versions.
Fixes: f3c4969c2485 ("wireless-regdb: make scripts compatible with Python 3")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
db2bin.py | 2 +-
db2fw.py | 2 +-
dbparse.py | 3 +--
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/db2bin.py b/db2bin.py
index 28cd7d2ed373..29ae3136d5cb 100755
--- a/db2bin.py
+++ b/db2bin.py
@@ -118,7 +118,7 @@ reg_country_ptr.set()
for alpha2 in countrynames:
coll = countries[alpha2]
# struct regdb_file_reg_country
- output.write(struct.pack('>BBxBI', alpha2[0], alpha2[1], coll.dfs_region, reg_rules_collections[coll.permissions]))
+ output.write(struct.pack('>2sxBI', alpha2, coll.dfs_region, reg_rules_collections[coll.permissions]))
if len(sys.argv) > 3:
diff --git a/db2fw.py b/db2fw.py
index 0c0f030c0c63..3affd5a8e0fa 100755
--- a/db2fw.py
+++ b/db2fw.py
@@ -85,7 +85,7 @@ countrynames = list(countries)
countrynames.sort()
for alpha2 in countrynames:
coll = countries[alpha2]
- output.write(struct.pack('>BB', alpha2[0], alpha2[1]))
+ output.write(struct.pack('>2s', alpha2))
country_ptrs[alpha2] = PTR(output)
output.write(b'\x00' * 4)
diff --git a/dbparse.py b/dbparse.py
index 993f757b2cb1..5f7e08200fa0 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -1,6 +1,5 @@
#!/usr/bin/env python
-from builtins import bytes
from functools import total_ordering
import sys, math
from math import ceil, log
@@ -359,7 +358,7 @@ class DBParser(object):
for cname in cnames:
if len(cname) != 2:
self._warn("country '%s' not alpha2" % cname)
- cname = bytes(cname, 'ascii')
+ cname = cname.encode('ascii')
if not cname in self._countries:
self._countries[cname] = Country(dfs_region, comments=self._comments)
self._current_countries[cname] = self._countries[cname]
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] nl80211: add NL80211_CMD_UPDATE_FT_IES to supported commands
From: Johannes Berg @ 2019-08-22 18:08 UTC (permalink / raw)
To: Brian Norris, Matthew Wang; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190822180737.GA177276@google.com>
On Thu, 2019-08-22 at 11:07 -0700, Brian Norris wrote:
> On Thu, Aug 22, 2019 at 10:48:06AM -0700, Matthew Wang wrote:
> > Add NL80211_CMD_UPDATE_FT_IES to supported commands. In mac80211 drivers,
> > this can be implemented via existing NL80211_CMD_AUTHENTICATE and
> > NL80211_ATTR_IE, but non-mac80211 drivers have a separate command for
> > this. A driver supports FT if it either is mac80211 or supports this
> > command.
> >
> > Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
>
> FWIW:
>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
>
> > Change-Id: I93e3d09a6d949466d1aea48bff2c3ad862edccc6
>
> Oops :)
:)
No worries, I can edit that out.
johannes
^ permalink raw reply
* Re: [PATCH] nl80211: add NL80211_CMD_UPDATE_FT_IES to supported commands
From: Brian Norris @ 2019-08-22 18:07 UTC (permalink / raw)
To: Matthew Wang; +Cc: johannes, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190822174806.2954-1-matthewmwang@chromium.org>
On Thu, Aug 22, 2019 at 10:48:06AM -0700, Matthew Wang wrote:
> Add NL80211_CMD_UPDATE_FT_IES to supported commands. In mac80211 drivers,
> this can be implemented via existing NL80211_CMD_AUTHENTICATE and
> NL80211_ATTR_IE, but non-mac80211 drivers have a separate command for
> this. A driver supports FT if it either is mac80211 or supports this
> command.
>
> Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
FWIW:
Reviewed-by: Brian Norris <briannorris@chromium.org>
> Change-Id: I93e3d09a6d949466d1aea48bff2c3ad862edccc6
Oops :)
^ permalink raw reply
* [PATCH] nl80211: add NL80211_CMD_UPDATE_FT_IES to supported commands
From: Matthew Wang @ 2019-08-22 17:48 UTC (permalink / raw)
To: johannes; +Cc: davem, linux-wireless, netdev, linux-kernel, Matthew Wang
Add NL80211_CMD_UPDATE_FT_IES to supported commands. In mac80211 drivers,
this can be implemented via existing NL80211_CMD_AUTHENTICATE and
NL80211_ATTR_IE, but non-mac80211 drivers have a separate command for
this. A driver supports FT if it either is mac80211 or supports this
command.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Change-Id: I93e3d09a6d949466d1aea48bff2c3ad862edccc6
---
net/wireless/nl80211.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fd05ae1437a9..c2f9e6b429b2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2065,6 +2065,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
CMD(add_tx_ts, ADD_TX_TS);
CMD(set_multicast_to_unicast, SET_MULTICAST_TO_UNICAST);
CMD(update_connect_params, UPDATE_CONNECT_PARAMS);
+ CMD(update_ft_ies, UPDATE_FT_IES);
}
#undef CMD
--
2.23.0.187.g17f5b7556c-goog
^ permalink raw reply related
* Re: [PATCH] bcma: fix incorrect update of BCMA_CORE_PCI_MDIO_DATA
From: Johannes Berg @ 2019-08-22 16:55 UTC (permalink / raw)
To: Colin King, Hauke Mehrtens, Rafał Miłecki,
linux-wireless
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190822133524.6274-1-colin.king@canonical.com>
On Thu, 2019-08-22 at 14:35 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> An earlier commit re-worked the setting of the bitmask and is now
> assigning v with some bit flags rather than bitwise or-ing them
> into v, consequently the earlier bit-settings of v are being lost.
> Fix this by replacing an assignment with the bitwise or instead.
>
> Addresses-Coverity: ("Unused value")
> Fixes: 2be25cac8402 ("bcma: add constants for PCI and use them")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/bcma/driver_pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bcma/driver_pci.c b/drivers/bcma/driver_pci.c
> index f499a469e66d..d219ee947c07 100644
> --- a/drivers/bcma/driver_pci.c
> +++ b/drivers/bcma/driver_pci.c
> @@ -78,7 +78,7 @@ static u16 bcma_pcie_mdio_read(struct bcma_drv_pci *pc, u16 device, u8 address)
> v |= (address << BCMA_CORE_PCI_MDIODATA_REGADDR_SHF_OLD);
> }
>
> - v = BCMA_CORE_PCI_MDIODATA_START;
> + v |= BCMA_CORE_PCI_MDIODATA_START;
The same bug/issue is in bcma_pcie_mdio_write() btw.
It *seems* correct to me - otherwise the "address" parameter to the
function is entirely unused, which can't really be right.
There are only two code paths that ever get here:
* bcma_pcicore_serdes_workaround
* bcma_core_pci_power_save
The register at 0 is BCMA_CORE_PCI_CTL, which only has a few bits so
even bad values written there by accident might not hurt much ...
So it seems possible that it was just always broken.
johannes
^ permalink raw reply
* Re: [PATCH] bcma: fix incorrect update of BCMA_CORE_PCI_MDIO_DATA
From: Larry Finger @ 2019-08-22 16:38 UTC (permalink / raw)
To: Colin Ian King, Hauke Mehrtens, Rafał Miłecki,
linux-wireless
Cc: kernel-janitors, linux-kernel
In-Reply-To: <31258833-174f-080b-489e-85d3556bd1de@canonical.com>
On 8/22/19 11:11 AM, Colin Ian King wrote:
> On 22/08/2019 17:03, Larry Finger wrote:
>> On 8/22/19 8:35 AM, Colin King wrote:
>>> From: Colin Ian King <colin.king@canonical.com>
>>>
>>> An earlier commit re-worked the setting of the bitmask and is now
>>> assigning v with some bit flags rather than bitwise or-ing them
>>> into v, consequently the earlier bit-settings of v are being lost.
>>> Fix this by replacing an assignment with the bitwise or instead.
>>>
>>> Addresses-Coverity: ("Unused value")
>>> Fixes: 2be25cac8402 ("bcma: add constants for PCI and use them")
>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>>> ---
>>> drivers/bcma/driver_pci.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/bcma/driver_pci.c b/drivers/bcma/driver_pci.c
>>> index f499a469e66d..d219ee947c07 100644
>>> --- a/drivers/bcma/driver_pci.c
>>> +++ b/drivers/bcma/driver_pci.c
>>> @@ -78,7 +78,7 @@ static u16 bcma_pcie_mdio_read(struct bcma_drv_pci
>>> *pc, u16 device, u8 address)
>>> v |= (address << BCMA_CORE_PCI_MDIODATA_REGADDR_SHF_OLD);
>>> }
>>> - v = BCMA_CORE_PCI_MDIODATA_START;
>>> + v |= BCMA_CORE_PCI_MDIODATA_START;
>>> v |= BCMA_CORE_PCI_MDIODATA_READ;
>>> v |= BCMA_CORE_PCI_MDIODATA_TA;
>>
>> I'm not sure the "Fixes" attribute is correct.
>>
>> The changes for this section in commit 2be25cac8402 are
>>
>> - v = (1 << 30); /* Start of Transaction */
>> - v |= (1 << 28); /* Write Transaction */
>> - v |= (1 << 17); /* Turnaround */
>> - v |= (0x1F << 18);
>> + v = BCMA_CORE_PCI_MDIODATA_START;
>> + v |= BCMA_CORE_PCI_MDIODATA_WRITE;
>> + v |= (BCMA_CORE_PCI_MDIODATA_DEV_ADDR <<
>> + BCMA_CORE_PCI_MDIODATA_DEVADDR_SHF);
>> + v |= (BCMA_CORE_PCI_MDIODATA_BLK_ADDR <<
>> + BCMA_CORE_PCI_MDIODATA_REGADDR_SHF);
>> + v |= BCMA_CORE_PCI_MDIODATA_TA;
>>
>> Because the code has done quite a bit of work on v just above this
>> section, I agree that this is likely an error, but that error happened
>> in an earlier commit. Thus 2be25cac8402 did not introduce the error,
>> merely copied it.
>
> Ugh, this goes back further. I didn't spot that. I'm less confident of
> what the correct settings should be now.
>
>>
>> Has this change been tested?
>
> Afraid not, I don't have the H/W.
I admit that I looked at this only because I found it hard to believe that the
collective wisdom of the list would have missed the usage of "=" instead of
"|=". At least that test was passed. :)
Larry
^ permalink raw reply
* Re: [PATCH] bcma: fix incorrect update of BCMA_CORE_PCI_MDIO_DATA
From: Colin Ian King @ 2019-08-22 16:11 UTC (permalink / raw)
To: Larry Finger, Hauke Mehrtens, Rafał Miłecki,
linux-wireless
Cc: kernel-janitors, linux-kernel
In-Reply-To: <d3c16158-ef89-f5ee-2f67-4357c70e8fe9@lwfinger.net>
On 22/08/2019 17:03, Larry Finger wrote:
> On 8/22/19 8:35 AM, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> An earlier commit re-worked the setting of the bitmask and is now
>> assigning v with some bit flags rather than bitwise or-ing them
>> into v, consequently the earlier bit-settings of v are being lost.
>> Fix this by replacing an assignment with the bitwise or instead.
>>
>> Addresses-Coverity: ("Unused value")
>> Fixes: 2be25cac8402 ("bcma: add constants for PCI and use them")
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>> ---
>> drivers/bcma/driver_pci.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/bcma/driver_pci.c b/drivers/bcma/driver_pci.c
>> index f499a469e66d..d219ee947c07 100644
>> --- a/drivers/bcma/driver_pci.c
>> +++ b/drivers/bcma/driver_pci.c
>> @@ -78,7 +78,7 @@ static u16 bcma_pcie_mdio_read(struct bcma_drv_pci
>> *pc, u16 device, u8 address)
>> v |= (address << BCMA_CORE_PCI_MDIODATA_REGADDR_SHF_OLD);
>> }
>> - v = BCMA_CORE_PCI_MDIODATA_START;
>> + v |= BCMA_CORE_PCI_MDIODATA_START;
>> v |= BCMA_CORE_PCI_MDIODATA_READ;
>> v |= BCMA_CORE_PCI_MDIODATA_TA;
>
> I'm not sure the "Fixes" attribute is correct.
>
> The changes for this section in commit 2be25cac8402 are
>
> - v = (1 << 30); /* Start of Transaction */
> - v |= (1 << 28); /* Write Transaction */
> - v |= (1 << 17); /* Turnaround */
> - v |= (0x1F << 18);
> + v = BCMA_CORE_PCI_MDIODATA_START;
> + v |= BCMA_CORE_PCI_MDIODATA_WRITE;
> + v |= (BCMA_CORE_PCI_MDIODATA_DEV_ADDR <<
> + BCMA_CORE_PCI_MDIODATA_DEVADDR_SHF);
> + v |= (BCMA_CORE_PCI_MDIODATA_BLK_ADDR <<
> + BCMA_CORE_PCI_MDIODATA_REGADDR_SHF);
> + v |= BCMA_CORE_PCI_MDIODATA_TA;
>
> Because the code has done quite a bit of work on v just above this
> section, I agree that this is likely an error, but that error happened
> in an earlier commit. Thus 2be25cac8402 did not introduce the error,
> merely copied it.
Ugh, this goes back further. I didn't spot that. I'm less confident of
what the correct settings should be now.
>
> Has this change been tested?
Afraid not, I don't have the H/W.
>
> Larry
^ permalink raw reply
* Re: [PATCH] bcma: fix incorrect update of BCMA_CORE_PCI_MDIO_DATA
From: Larry Finger @ 2019-08-22 16:03 UTC (permalink / raw)
To: Colin King, Hauke Mehrtens, Rafał Miłecki,
linux-wireless
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190822133524.6274-1-colin.king@canonical.com>
On 8/22/19 8:35 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> An earlier commit re-worked the setting of the bitmask and is now
> assigning v with some bit flags rather than bitwise or-ing them
> into v, consequently the earlier bit-settings of v are being lost.
> Fix this by replacing an assignment with the bitwise or instead.
>
> Addresses-Coverity: ("Unused value")
> Fixes: 2be25cac8402 ("bcma: add constants for PCI and use them")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/bcma/driver_pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bcma/driver_pci.c b/drivers/bcma/driver_pci.c
> index f499a469e66d..d219ee947c07 100644
> --- a/drivers/bcma/driver_pci.c
> +++ b/drivers/bcma/driver_pci.c
> @@ -78,7 +78,7 @@ static u16 bcma_pcie_mdio_read(struct bcma_drv_pci *pc, u16 device, u8 address)
> v |= (address << BCMA_CORE_PCI_MDIODATA_REGADDR_SHF_OLD);
> }
>
> - v = BCMA_CORE_PCI_MDIODATA_START;
> + v |= BCMA_CORE_PCI_MDIODATA_START;
> v |= BCMA_CORE_PCI_MDIODATA_READ;
> v |= BCMA_CORE_PCI_MDIODATA_TA;
I'm not sure the "Fixes" attribute is correct.
The changes for this section in commit 2be25cac8402 are
- v = (1 << 30); /* Start of Transaction */
- v |= (1 << 28); /* Write Transaction */
- v |= (1 << 17); /* Turnaround */
- v |= (0x1F << 18);
+ v = BCMA_CORE_PCI_MDIODATA_START;
+ v |= BCMA_CORE_PCI_MDIODATA_WRITE;
+ v |= (BCMA_CORE_PCI_MDIODATA_DEV_ADDR <<
+ BCMA_CORE_PCI_MDIODATA_DEVADDR_SHF);
+ v |= (BCMA_CORE_PCI_MDIODATA_BLK_ADDR <<
+ BCMA_CORE_PCI_MDIODATA_REGADDR_SHF);
+ v |= BCMA_CORE_PCI_MDIODATA_TA;
Because the code has done quite a bit of work on v just above this section, I
agree that this is likely an error, but that error happened in an earlier
commit. Thus 2be25cac8402 did not introduce the error, merely copied it.
Has this change been tested?
Larry
^ permalink raw reply
* Re: PROBLEM: 5.3.0-rc* causes iwlwifi failure
From: Luca Coelho @ 2019-08-22 14:27 UTC (permalink / raw)
To: Chris Clayton, Stuart Little; +Cc: LKML, linux-wireless
In-Reply-To: <5e3ed328-7eea-f112-45d7-4ddee04c4b77@googlemail.com>
On Thu, 2019-08-22 at 09:59 +0100, Chris Clayton wrote:
> Thanks, Stuart.
>
> On 18/08/2019 11:55, Stuart Little wrote:
> > On Sun, Aug 18, 2019 at 09:17:59AM +0100, Chris Clayton wrote:
> > >
> > > On 17/08/2019 22:44, Stuart Little wrote:
> > > > After some private coaching from Serge Belyshev on git-revert I can confirm that reverting that commit atop the current tree resolves the issue (the wifi card scans for and finds networks just fine, no dmesg errors reported, etc.).
> > > >
> > >
> > > I've reported the "Microcode SW error detected" issue too, but, wrongly, only to LKML. I'll point that thread to this
> > > one. I've also been experiencing my network stopping working after suspend resume, but haven't got round to reporting
> > > that yet.
> > >
> > > What was the git magic that you acquired to revert the patch, please?
> > >
>
> By following the advice below, I reverted 4fd445a2c855bbcab81fbe06d110e78dbd974a5b and using the resultant kernel I
> haven't seen the "Microcode SW error detected" again. I am, however, still experiencing the problem of my network not
> working after resume from suspend. I've reported it to LKML, so it can be followed there should anyone need/want to.
FWIW, we're tracking the iwlwifi bug here:
https://bugzilla.kernel.org/show_bug.cgi?id=204151
I'm thinking about how to solve this and will probably have a proper
patch by the end of the week.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] bcma: fix incorrect update of BCMA_CORE_PCI_MDIO_DATA
From: Colin King @ 2019-08-22 13:35 UTC (permalink / raw)
To: Hauke Mehrtens, Rafał Miłecki, linux-wireless
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
An earlier commit re-worked the setting of the bitmask and is now
assigning v with some bit flags rather than bitwise or-ing them
into v, consequently the earlier bit-settings of v are being lost.
Fix this by replacing an assignment with the bitwise or instead.
Addresses-Coverity: ("Unused value")
Fixes: 2be25cac8402 ("bcma: add constants for PCI and use them")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/bcma/driver_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bcma/driver_pci.c b/drivers/bcma/driver_pci.c
index f499a469e66d..d219ee947c07 100644
--- a/drivers/bcma/driver_pci.c
+++ b/drivers/bcma/driver_pci.c
@@ -78,7 +78,7 @@ static u16 bcma_pcie_mdio_read(struct bcma_drv_pci *pc, u16 device, u8 address)
v |= (address << BCMA_CORE_PCI_MDIODATA_REGADDR_SHF_OLD);
}
- v = BCMA_CORE_PCI_MDIODATA_START;
+ v |= BCMA_CORE_PCI_MDIODATA_START;
v |= BCMA_CORE_PCI_MDIODATA_READ;
v |= BCMA_CORE_PCI_MDIODATA_TA;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] mt76: remove empty flag in mt76_txq_schedule_list
From: Lorenzo Bianconi @ 2019-08-22 12:44 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Lorenzo Bianconi, nbd, linux-wireless
In-Reply-To: <20190822123757.GA28300@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]
> On Thu, Aug 22, 2019 at 01:50:52PM +0200, Lorenzo Bianconi wrote:
> > > On Thu, Aug 22, 2019 at 11:49:10AM +0200, Lorenzo Bianconi wrote:
> > > > Remove empty flag in mt76_txq_schedule_list and mt76_txq_send_burst
> > > > since we just need retry_q length to notify mac80211 to reschedule the
> > > > current tx queue
> > > >
> > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > ---
> > > > drivers/net/wireless/mediatek/mt76/tx.c | 23 +++++++----------------
> > > > 1 file changed, 7 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> > > > index d7982aa83c11..51d69329ed06 100644
> > > > --- a/drivers/net/wireless/mediatek/mt76/tx.c
> > > > +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> > > > @@ -378,7 +378,7 @@ EXPORT_SYMBOL_GPL(mt76_release_buffered_frames);
> > > >
> > > > static int
> > > > mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
> > > > - struct mt76_txq *mtxq, bool *empty)
> > > > + struct mt76_txq *mtxq)
> > > > {
> > > > struct ieee80211_txq *txq = mtxq_to_txq(mtxq);
> > > > enum mt76_txq_id qid = mt76_txq_get_qid(txq);
> > > > @@ -392,16 +392,12 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
> > > > bool probe;
> > > > int idx;
> > > >
> > > > - if (test_bit(MT_WCID_FLAG_PS, &wcid->flags)) {
> > > > - *empty = true;
> > > > + if (test_bit(MT_WCID_FLAG_PS, &wcid->flags))
> > > > return 0;
> > >
> > > This changes behaviour for station in PS state. If retry_q is not
> > > empty, now we will be rescheduling tx queue for STA in PS mode.
> > > Not sure if this is problem or not, though.
> >
> > good point..looking at the code it seems not a issue since we will not actually
> > tx frames for PS stations. What do you think?
>
> I do not see how changing this could possibly break things, but it
> was explicitly added by below commit, with changelog sugesting it is
> needed:
>
> commit d225581df3147060bc99e931b11f7cf2dcb1b2ca
> Author: Felix Fietkau <nbd@nbd.name>
> Date: Mon Jan 21 17:33:38 2019 +0100
>
> mt76: avoid scheduling tx queues for powersave stations
>
> In case a tx queue wake call arrives after a client has transitioned to
> powersave, make sure that the queue is not kept active until the client
> has left powersave mode
>
> Stanislaw
This is exactly what I am saying, we need the 'if block' in mt76_txq_send_burst
in order to avoid scheduling tx queue for station in powersave but the empty
flag seems not necessary.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] mt76: remove empty flag in mt76_txq_schedule_list
From: Stanislaw Gruszka @ 2019-08-22 12:37 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190822115052.GC3350@localhost.localdomain>
On Thu, Aug 22, 2019 at 01:50:52PM +0200, Lorenzo Bianconi wrote:
> > On Thu, Aug 22, 2019 at 11:49:10AM +0200, Lorenzo Bianconi wrote:
> > > Remove empty flag in mt76_txq_schedule_list and mt76_txq_send_burst
> > > since we just need retry_q length to notify mac80211 to reschedule the
> > > current tx queue
> > >
> > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > ---
> > > drivers/net/wireless/mediatek/mt76/tx.c | 23 +++++++----------------
> > > 1 file changed, 7 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> > > index d7982aa83c11..51d69329ed06 100644
> > > --- a/drivers/net/wireless/mediatek/mt76/tx.c
> > > +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> > > @@ -378,7 +378,7 @@ EXPORT_SYMBOL_GPL(mt76_release_buffered_frames);
> > >
> > > static int
> > > mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
> > > - struct mt76_txq *mtxq, bool *empty)
> > > + struct mt76_txq *mtxq)
> > > {
> > > struct ieee80211_txq *txq = mtxq_to_txq(mtxq);
> > > enum mt76_txq_id qid = mt76_txq_get_qid(txq);
> > > @@ -392,16 +392,12 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
> > > bool probe;
> > > int idx;
> > >
> > > - if (test_bit(MT_WCID_FLAG_PS, &wcid->flags)) {
> > > - *empty = true;
> > > + if (test_bit(MT_WCID_FLAG_PS, &wcid->flags))
> > > return 0;
> >
> > This changes behaviour for station in PS state. If retry_q is not
> > empty, now we will be rescheduling tx queue for STA in PS mode.
> > Not sure if this is problem or not, though.
>
> good point..looking at the code it seems not a issue since we will not actually
> tx frames for PS stations. What do you think?
I do not see how changing this could possibly break things, but it
was explicitly added by below commit, with changelog sugesting it is
needed:
commit d225581df3147060bc99e931b11f7cf2dcb1b2ca
Author: Felix Fietkau <nbd@nbd.name>
Date: Mon Jan 21 17:33:38 2019 +0100
mt76: avoid scheduling tx queues for powersave stations
In case a tx queue wake call arrives after a client has transitioned to
powersave, make sure that the queue is not kept active until the client
has left powersave mode
Stanislaw
^ permalink raw reply
* [PATCH][next] mac80211: minstrel_ht: fix infinite loop because supported is not being shifted
From: Colin King @ 2019-08-22 12:20 UTC (permalink / raw)
To: Felix Fietkau, Johannes Berg, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently the for-loop will spin forever if variable supported is
non-zero because supported is never changed. Fix this by adding in
the missing right shift of supported.
Addresses-Coverity: ("Infinite loop")
Fixes: 48cb39522a9d ("mac80211: minstrel_ht: improve rate probing for devices with static fallback")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/mac80211/rc80211_minstrel_ht.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index a01168514840..0ef2633349b5 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -634,7 +634,7 @@ minstrel_ht_rate_sample_switch(struct minstrel_priv *mp,
u16 supported = mi->supported[g_idx];
supported >>= mi->max_tp_rate[0] % MCS_GROUP_RATES;
- for (i = 0; supported; i++) {
+ for (i = 0; supported; supported >>= 1, i++) {
if (!(supported & 1))
continue;
--
2.20.1
^ permalink raw reply related
* RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio
From: Toke Høiland-Jørgensen @ 2019-08-22 12:12 UTC (permalink / raw)
To: Wen Gong, Wen Gong, ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <86d0eabcc63849efa914f2c14a3cd59f@aptaiexm02f.ap.qualcomm.com>
Wen Gong <wgong@qti.qualcomm.com> writes:
>> -----Original Message-----
>> From: Toke Høiland-Jørgensen <toke@redhat.com>
>> Sent: Wednesday, August 21, 2019 6:10 PM
>> To: Wen Gong <wgong@qti.qualcomm.com>; Wen Gong
>> <wgong@codeaurora.org>; ath10k@lists.infradead.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: [EXT] RE: [PATCH 4/7] ath10k: disable TX complete indication of htt
>> for sdio
>>
>> Wen Gong <wgong@qti.qualcomm.com> writes:
>>
>> >> -----Original Message-----
>> >> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Toke
>> >> Høiland-Jørgensen
>> >> Sent: Tuesday, August 20, 2019 8:24 PM
>> >> To: Wen Gong <wgong@codeaurora.org>; ath10k@lists.infradead.org
>> >> Cc: linux-wireless@vger.kernel.org
>> >> Subject: [EXT] Re: [PATCH 4/7] ath10k: disable TX complete indication of
>> htt
>> > When this patch applied, firmware will not indicate tx complete for tx
>> > Data, it only indicate HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND,
>> > This htt msg will tell how many data tx complete without status(status
>> maybe success/fail).
>>
>> Ah, so this is basically a counter of how much data is currently queued
>> in the firmware?
> Yes.
>>
>> >> And could you explain what the credits thing is for, please? :)
>> > For high latency bus chip, all the tx data's content(include ip/udp/tcp
>> header
>> > and payload) will be transfer to firmware's memory via bus.
>> > And firmware has limited memory for tx data, the tx data's content must
>> > Saved in firmware memory before it tx complete, if ath10k transfer tx
>> > data more than the limit, firmware will occur error. The credit is used
>> > to avoid ath10k exceed the limit.
>>
>> What's a typical limit in the firmware?
> It is 96 data packet in my test. It can changed in firmware code.
Right, I see. Is this counter available in all ath10k firmware, or is it
SDIO only?
I'm asking because this could also be a way of implementing something
like Byte Queue Limits (though I'm not sure how effective it would be).
-Toke
^ permalink raw reply
* Re: [PATCH] mt76: remove empty flag in mt76_txq_schedule_list
From: Lorenzo Bianconi @ 2019-08-22 11:50 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190822103629.GA2368@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
> On Thu, Aug 22, 2019 at 11:49:10AM +0200, Lorenzo Bianconi wrote:
> > Remove empty flag in mt76_txq_schedule_list and mt76_txq_send_burst
> > since we just need retry_q length to notify mac80211 to reschedule the
> > current tx queue
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > drivers/net/wireless/mediatek/mt76/tx.c | 23 +++++++----------------
> > 1 file changed, 7 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> > index d7982aa83c11..51d69329ed06 100644
> > --- a/drivers/net/wireless/mediatek/mt76/tx.c
> > +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> > @@ -378,7 +378,7 @@ EXPORT_SYMBOL_GPL(mt76_release_buffered_frames);
> >
> > static int
> > mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
> > - struct mt76_txq *mtxq, bool *empty)
> > + struct mt76_txq *mtxq)
> > {
> > struct ieee80211_txq *txq = mtxq_to_txq(mtxq);
> > enum mt76_txq_id qid = mt76_txq_get_qid(txq);
> > @@ -392,16 +392,12 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
> > bool probe;
> > int idx;
> >
> > - if (test_bit(MT_WCID_FLAG_PS, &wcid->flags)) {
> > - *empty = true;
> > + if (test_bit(MT_WCID_FLAG_PS, &wcid->flags))
> > return 0;
>
> This changes behaviour for station in PS state. If retry_q is not
> empty, now we will be rescheduling tx queue for STA in PS mode.
> Not sure if this is problem or not, though.
good point..looking at the code it seems not a issue since we will not actually
tx frames for PS stations. What do you think?
Regards,
Lorenzo
>
> Stanislaw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] rtw88: remove redundant assignment to pointer debugfs_topdir
From: Colin King @ 2019-08-22 11:37 UTC (permalink / raw)
To: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Pointer debugfs_topdir is initialized to a value that is never read
and it is re-assigned later. The initialization is redundant and can
be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtw88/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/debug.c b/drivers/net/wireless/realtek/rtw88/debug.c
index 383b04c16703..5d235968d475 100644
--- a/drivers/net/wireless/realtek/rtw88/debug.c
+++ b/drivers/net/wireless/realtek/rtw88/debug.c
@@ -672,7 +672,7 @@ static struct rtw_debugfs_priv rtw_debug_priv_rsvd_page = {
void rtw_debugfs_init(struct rtw_dev *rtwdev)
{
- struct dentry *debugfs_topdir = rtwdev->debugfs;
+ struct dentry *debugfs_topdir;
debugfs_topdir = debugfs_create_dir("rtw88",
rtwdev->hw->wiphy->debugfsdir);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] mt76: remove empty flag in mt76_txq_schedule_list
From: Stanislaw Gruszka @ 2019-08-22 10:36 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <fb24ac317768ec71d16354ef6cd2a9c10931c75d.1566466668.git.lorenzo@kernel.org>
On Thu, Aug 22, 2019 at 11:49:10AM +0200, Lorenzo Bianconi wrote:
> Remove empty flag in mt76_txq_schedule_list and mt76_txq_send_burst
> since we just need retry_q length to notify mac80211 to reschedule the
> current tx queue
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/wireless/mediatek/mt76/tx.c | 23 +++++++----------------
> 1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> index d7982aa83c11..51d69329ed06 100644
> --- a/drivers/net/wireless/mediatek/mt76/tx.c
> +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> @@ -378,7 +378,7 @@ EXPORT_SYMBOL_GPL(mt76_release_buffered_frames);
>
> static int
> mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
> - struct mt76_txq *mtxq, bool *empty)
> + struct mt76_txq *mtxq)
> {
> struct ieee80211_txq *txq = mtxq_to_txq(mtxq);
> enum mt76_txq_id qid = mt76_txq_get_qid(txq);
> @@ -392,16 +392,12 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
> bool probe;
> int idx;
>
> - if (test_bit(MT_WCID_FLAG_PS, &wcid->flags)) {
> - *empty = true;
> + if (test_bit(MT_WCID_FLAG_PS, &wcid->flags))
> return 0;
This changes behaviour for station in PS state. If retry_q is not
empty, now we will be rescheduling tx queue for STA in PS mode.
Not sure if this is problem or not, though.
Stanislaw
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: apply calibration-free data from OTP
From: Lorenzo Bianconi @ 2019-08-22 10:02 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <20190821191443.36764-1-nbd@nbd.name>
[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]
> MT7615 chips usually come pre-calibrated, even when used on embedded boards.
> In that case, the on-flash EEPROM data needs to be merged with some data
> from OTP ROM.
> Run this merge if the external EEPROM data is valid and OTP has valid fields.
>
Tested-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> .../wireless/mediatek/mt76/mt7615/eeprom.c | 38 +++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
> index dc94f52e6e8b..515bb58e19fd 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
> @@ -154,6 +154,42 @@ int mt7615_eeprom_get_power_index(struct mt7615_dev *dev,
> return index;
> }
>
> +static void mt7615_apply_cal_free_data(struct mt7615_dev *dev)
> +{
> + static const u16 ical[] = {
> + 0x53, 0x54, 0x55, 0x56, 0x57, 0x5c, 0x5d, 0x62, 0x63, 0x68,
> + 0x69, 0x6e, 0x6f, 0x73, 0x74, 0x78, 0x79, 0x82, 0x83, 0x87,
> + 0x88, 0x8c, 0x8d, 0x91, 0x92, 0x96, 0x97, 0x9b, 0x9c, 0xa0,
> + 0xa1, 0xaa, 0xab, 0xaf, 0xb0, 0xb4, 0xb5, 0xb9, 0xba, 0xf4,
> + 0xf7, 0xff,
> + 0x140, 0x141, 0x145, 0x146, 0x14a, 0x14b, 0x154, 0x155, 0x159,
> + 0x15a, 0x15e, 0x15f, 0x163, 0x164, 0x168, 0x169, 0x16d, 0x16e,
> + 0x172, 0x173, 0x17c, 0x17d, 0x181, 0x182, 0x186, 0x187, 0x18b,
> + 0x18c
> + };
> + static const u16 ical_nocheck[] = {
> + 0x110, 0x111, 0x112, 0x113, 0x114, 0x115, 0x116, 0x117, 0x118,
> + 0x1b5, 0x1b6, 0x1b7, 0x3ac, 0x3ad, 0x3ae, 0x3af, 0x3b0, 0x3b1,
> + 0x3b2
> + };
> + u8 *eeprom = dev->mt76.eeprom.data;
> + u8 *otp = dev->mt76.otp.data;
> + int i;
> +
> + if (!otp)
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(ical); i++)
> + if (!otp[ical[i]])
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(ical); i++)
> + eeprom[ical[i]] = otp[ical[i]];
> +
> + for (i = 0; i < ARRAY_SIZE(ical_nocheck); i++)
> + eeprom[ical_nocheck[i]] = otp[ical_nocheck[i]];
> +}
> +
> int mt7615_eeprom_init(struct mt7615_dev *dev)
> {
> int ret;
> @@ -166,6 +202,8 @@ int mt7615_eeprom_init(struct mt7615_dev *dev)
> if (ret && dev->mt76.otp.data)
> memcpy(dev->mt76.eeprom.data, dev->mt76.otp.data,
> MT7615_EEPROM_SIZE);
> + else
> + mt7615_apply_cal_free_data(dev);
>
> mt7615_eeprom_parse_hw_cap(dev);
> memcpy(dev->mt76.macaddr, dev->mt76.eeprom.data + MT_EE_MAC_ADDR,
> --
> 2.17.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] mt76: remove empty flag in mt76_txq_schedule_list
From: Lorenzo Bianconi @ 2019-08-22 9:49 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka
Remove empty flag in mt76_txq_schedule_list and mt76_txq_send_burst
since we just need retry_q length to notify mac80211 to reschedule the
current tx queue
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/tx.c | 23 +++++++----------------
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index d7982aa83c11..51d69329ed06 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -378,7 +378,7 @@ EXPORT_SYMBOL_GPL(mt76_release_buffered_frames);
static int
mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
- struct mt76_txq *mtxq, bool *empty)
+ struct mt76_txq *mtxq)
{
struct ieee80211_txq *txq = mtxq_to_txq(mtxq);
enum mt76_txq_id qid = mt76_txq_get_qid(txq);
@@ -392,16 +392,12 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
bool probe;
int idx;
- if (test_bit(MT_WCID_FLAG_PS, &wcid->flags)) {
- *empty = true;
+ if (test_bit(MT_WCID_FLAG_PS, &wcid->flags))
return 0;
- }
skb = mt76_txq_dequeue(dev, mtxq, false);
- if (!skb) {
- *empty = true;
+ if (!skb)
return 0;
- }
info = IEEE80211_SKB_CB(skb);
if (!(wcid->tx_info & MT_WCID_TX_INFO_SET))
@@ -432,10 +428,8 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
return -EBUSY;
skb = mt76_txq_dequeue(dev, mtxq, false);
- if (!skb) {
- *empty = true;
+ if (!skb)
break;
- }
info = IEEE80211_SKB_CB(skb);
cur_ampdu = info->flags & IEEE80211_TX_CTL_AMPDU;
@@ -482,8 +476,6 @@ mt76_txq_schedule_list(struct mt76_dev *dev, enum mt76_txq_id qid)
spin_lock_bh(&hwq->lock);
while (1) {
- bool empty = false;
-
if (sq->swq_queued >= 4)
break;
@@ -515,10 +507,9 @@ mt76_txq_schedule_list(struct mt76_dev *dev, enum mt76_txq_id qid)
spin_lock_bh(&hwq->lock);
}
- ret += mt76_txq_send_burst(dev, sq, mtxq, &empty);
- if (skb_queue_empty(&mtxq->retry_q))
- empty = true;
- ieee80211_return_txq(dev->hw, txq, !empty);
+ ret += mt76_txq_send_burst(dev, sq, mtxq);
+ ieee80211_return_txq(dev->hw, txq,
+ !skb_queue_empty(&mtxq->retry_q));
}
spin_unlock_bh(&hwq->lock);
--
2.21.0
^ permalink raw reply related
* Re: PROBLEM: 5.3.0-rc* causes iwlwifi failure
From: Chris Clayton @ 2019-08-22 8:59 UTC (permalink / raw)
To: Stuart Little; +Cc: LKML, linux-wireless
In-Reply-To: <20190818105530.GA1247@chirva-void>
Thanks, Stuart.
On 18/08/2019 11:55, Stuart Little wrote:
> On Sun, Aug 18, 2019 at 09:17:59AM +0100, Chris Clayton wrote:
>>
>>
>> On 17/08/2019 22:44, Stuart Little wrote:
>>> After some private coaching from Serge Belyshev on git-revert I can confirm that reverting that commit atop the current tree resolves the issue (the wifi card scans for and finds networks just fine, no dmesg errors reported, etc.).
>>>
>>
>> I've reported the "Microcode SW error detected" issue too, but, wrongly, only to LKML. I'll point that thread to this
>> one. I've also been experiencing my network stopping working after suspend resume, but haven't got round to reporting
>> that yet.
>>
>> What was the git magic that you acquired to revert the patch, please?
>>
By following the advice below, I reverted 4fd445a2c855bbcab81fbe06d110e78dbd974a5b and using the resultant kernel I
haven't seen the "Microcode SW error detected" again. I am, however, still experiencing the problem of my network not
working after resume from suspend. I've reported it to LKML, so it can be followed there should anyone need/want to.
>
> $ git revert <offending commit>
>
> This will fail as noted, but will place in a revert mode where you can fix the errors.
>
> $ git status
>
> will show (it did in my case, for the latest Linux tree at the time I did this) a modified file
>
> drivers/net/wireless/intel/iwlwifi/mvm/fw.c
>
> to be committed without issue and a conflicted file
>
> drivers/net/wireless/intel/iwlwifi/mvm/nvm.c
>
> whose conflicts you have to first resolve.
>
> I then opened that conflicted file in a text editor and simply removed everything between the lines
>
> <<<<<<< HEAD
>
> and
>
>>>>>>>> parent of 4fd445a2c855... iwlwifi: mvm: Add log information about SAR status
>
> (inclusive). This resolved the conflict, whereupon
>
> $ git revert --continue
>
> and
>
> $ git commit -a
>
> will finish the reversion.
>
>>> On Sat, Aug 17, 2019 at 11:59:59AM +0300, Serge Belyshev wrote:
>>>>
>>>>> I am on an Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz running Linux
>>>>> x86_64 (Slackware), with a custom-compiled 5.3.0-rc4 (.config
>>>>> attached).
>>>>>
>>>>> I am using the Intel wifi adapter on this machine:
>>>>>
>>>>> 02:00.0 Network controller: Intel Corporation Device 24fb (rev 10)
>>>>>
>>>>> with the iwlwifi driver. I am attaching the output to 'lspci -vv -s
>>>>> 02:00.0' as the file device-info.
>>>>>
>>>>> All 5.3.0-rc* versions I have tried (including rc4) cause multiple
>>>>> dmesg iwlwifi-related errors (dmesg attached). Examples:
>>>>>
>>>>> iwlwifi 0000:02:00.0: Failed to get geographic profile info -5
>>>>> iwlwifi 0000:02:00.0: Microcode SW error detected. Restarting 0x82000000
>>>>> iwlwifi 0000:02:00.0: 0x00000038 | BAD_COMMAND
>>>>>
>>>>
>>>> I have my logs filled with similar garbage throughout 5.3-rc*. Also
>>>> since 5.3-rcsomething not only it WARNS in dmesg about firmware failure,
>>>> but completely stops working after suspend/resume cycle.
>>>>
>>>> It looks like that:
>>>>
>>>> commit 4fd445a2c855bbcab81fbe06d110e78dbd974a5b
>>>> Author: Haim Dreyfuss <haim.dreyfuss@intel.com>
>>>> Date: Thu May 2 11:45:02 2019 +0300
>>>>
>>>> iwlwifi: mvm: Add log information about SAR status
>>>>
>>>> Inform users when SAR status is changing.
>>>>
>>>> Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
>>>> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>>>>
>>>>
>>>> is the culprit. (manually) reverting it on top of 5.3-rc4 makes
>>>> everything work again.
>>>
^ permalink raw reply
* [PATCH 1/2] mt76: do not send BAR frame on tx aggregation flush stop
From: Felix Fietkau @ 2019-08-22 8:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Balakrishna Bandi
There is no need to send a BAR frame after stopping aggregation, and doing
so could lead to sending class 3 frames after deauthentication from an AP
Signed-off-by: Balakrishna Bandi <b.balakrishna@globaledgesoft.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 1 -
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 -
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
index e35c1e4da7ea..25d5b1608bc9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
@@ -578,7 +578,6 @@ mt7603_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
case IEEE80211_AMPDU_TX_STOP_FLUSH:
case IEEE80211_AMPDU_TX_STOP_FLUSH_CONT:
mtxq->aggr = false;
- ieee80211_send_bar(vif, sta->addr, tid, mtxq->agg_ssn);
mt7603_mac_tx_ba_reset(dev, msta->wcid.idx, tid, -1);
break;
case IEEE80211_AMPDU_TX_START:
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index e2a84f717051..87c748715b5d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -473,7 +473,6 @@ mt7615_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
case IEEE80211_AMPDU_TX_STOP_FLUSH:
case IEEE80211_AMPDU_TX_STOP_FLUSH_CONT:
mtxq->aggr = false;
- ieee80211_send_bar(vif, sta->addr, tid, mtxq->agg_ssn);
mt7615_mcu_set_tx_ba(dev, params, 0);
break;
case IEEE80211_AMPDU_TX_START:
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index dbd9d99225ff..aec73a0295e8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -390,7 +390,6 @@ int mt76x02_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
case IEEE80211_AMPDU_TX_STOP_FLUSH:
case IEEE80211_AMPDU_TX_STOP_FLUSH_CONT:
mtxq->aggr = false;
- ieee80211_send_bar(vif, sta->addr, tid, mtxq->agg_ssn);
break;
case IEEE80211_AMPDU_TX_START:
mtxq->agg_ssn = IEEE80211_SN_TO_SEQ(ssn);
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] mt76: remove offchannel check in tx scheduling
From: Felix Fietkau @ 2019-08-22 8:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Balakrishna Bandi
In-Reply-To: <20190822083622.48998-1-nbd@nbd.name>
tx queues are already disabled by mac80211 during scanning or other
off-channel activity. There is no need to repeat the check in mt76,
since scheduled queues are selected by mac80211 as well.
Signed-off-by: Balakrishna Bandi <b.balakrishna@globaledgesoft.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 5 -----
drivers/net/wireless/mediatek/mt76/mt76.h | 1 -
drivers/net/wireless/mediatek/mt76/tx.c | 6 ++----
3 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 32ddbf088817..fa481d2f11bd 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -406,11 +406,6 @@ void mt76_set_channel(struct mt76_dev *dev)
bool offchannel = hw->conf.flags & IEEE80211_CONF_OFFCHANNEL;
int timeout = HZ / 5;
- if (offchannel)
- set_bit(MT76_OFFCHANNEL, &dev->state);
- else
- clear_bit(MT76_OFFCHANNEL, &dev->state);
-
wait_event_timeout(dev->tx_wait, !mt76_has_tx_pending(dev), timeout);
if (dev->drv->update_survey)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 38f2b17581ef..d67c6a26c87c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -272,7 +272,6 @@ enum {
MT76_STATE_MCU_RUNNING,
MT76_SCANNING,
MT76_RESET,
- MT76_OFFCHANNEL,
MT76_REMOVED,
MT76_READING_STATS,
};
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index d7982aa83c11..c22a05f06fd0 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -427,8 +427,7 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_sw_queue *sq,
if (probe)
break;
- if (test_bit(MT76_OFFCHANNEL, &dev->state) ||
- test_bit(MT76_RESET, &dev->state))
+ if (test_bit(MT76_RESET, &dev->state))
return -EBUSY;
skb = mt76_txq_dequeue(dev, mtxq, false);
@@ -487,8 +486,7 @@ mt76_txq_schedule_list(struct mt76_dev *dev, enum mt76_txq_id qid)
if (sq->swq_queued >= 4)
break;
- if (test_bit(MT76_OFFCHANNEL, &dev->state) ||
- test_bit(MT76_RESET, &dev->state)) {
+ if (test_bit(MT76_RESET, &dev->state)) {
ret = -EBUSY;
break;
}
--
2.17.0
^ permalink raw reply related
* [PATCH] net/wireless: Delete unnecessary checks before the macro call “dev_kfree_skb”
From: Markus Elfring @ 2019-08-22 8:30 UTC (permalink / raw)
To: linux-wireless, linux-arm-kernel, linux-mediatek, ath10k,
David S. Miller, Felix Fietkau, Kalle Valo, Lorenzo Bianconi,
Matthias Brugger, Roy Luo, Ryder Lee, Solomon Peachy,
Stanislaw Gruszka
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 22 Aug 2019 10:20:10 +0200
The dev_kfree_skb() function performs also input parameter validation.
Thus the test around the shown calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/wireless/ath/ath10k/wmi.c | 4 +---
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 8 ++------
drivers/net/wireless/intel/iwlegacy/common.c | 8 ++------
drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c | 5 +----
drivers/net/wireless/st/cw1200/scan.c | 3 +--
5 files changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 4f707c6394bb..d384293429b4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -9440,7 +9440,5 @@ void ath10k_wmi_detach(struct ath10k *ar)
}
cancel_work_sync(&ar->svc_rdy_work);
-
- if (ar->svc_rdy_skb)
- dev_kfree_skb(ar->svc_rdy_skb);
+ dev_kfree_skb(ar->svc_rdy_skb);
}
diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
index b82da75a9ae3..4b3b166f6f2a 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
@@ -2302,9 +2302,7 @@ __il3945_down(struct il_priv *il)
il3945_hw_txq_ctx_free(il);
exit:
memset(&il->card_alive, 0, sizeof(struct il_alive_resp));
-
- if (il->beacon_skb)
- dev_kfree_skb(il->beacon_skb);
+ dev_kfree_skb(il->beacon_skb);
il->beacon_skb = NULL;
/* clear out any free frames */
@@ -3847,9 +3845,7 @@ il3945_pci_remove(struct pci_dev *pdev)
il_free_channel_map(il);
il_free_geos(il);
kfree(il->scan_cmd);
- if (il->beacon_skb)
- dev_kfree_skb(il->beacon_skb);
-
+ dev_kfree_skb(il->beacon_skb);
ieee80211_free_hw(il->hw);
}
diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c
index 73f7bbf742bc..4e7e64f46ea8 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -5182,8 +5182,7 @@ il_mac_reset_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
memset(&il->current_ht_config, 0, sizeof(struct il_ht_config));
/* new association get rid of ibss beacon skb */
- if (il->beacon_skb)
- dev_kfree_skb(il->beacon_skb);
+ dev_kfree_skb(il->beacon_skb);
il->beacon_skb = NULL;
il->timestamp = 0;
@@ -5302,10 +5301,7 @@ il_beacon_update(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
}
spin_lock_irqsave(&il->lock, flags);
-
- if (il->beacon_skb)
- dev_kfree_skb(il->beacon_skb);
-
+ dev_kfree_skb(il->beacon_skb);
il->beacon_skb = skb;
timestamp = ((struct ieee80211_mgmt *)skb->data)->u.beacon.timestamp;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c b/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c
index d61c686e08de..d6487cd67cca 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c
@@ -88,10 +88,7 @@ int mt76x02_mac_set_beacon(struct mt76x02_dev *dev, u8 vif_idx,
for (i = 0; i < ARRAY_SIZE(dev->beacons); i++) {
if (vif_idx == i) {
force_update = !!dev->beacons[i] ^ !!skb;
-
- if (dev->beacons[i])
- dev_kfree_skb(dev->beacons[i]);
-
+ dev_kfree_skb(dev->beacons[i]);
dev->beacons[i] = skb;
__mt76x02_mac_set_beacon(dev, bcn_idx, skb);
} else if (force_update && dev->beacons[i]) {
diff --git a/drivers/net/wireless/st/cw1200/scan.c b/drivers/net/wireless/st/cw1200/scan.c
index c46b044b7f7b..988581cc134b 100644
--- a/drivers/net/wireless/st/cw1200/scan.c
+++ b/drivers/net/wireless/st/cw1200/scan.c
@@ -120,8 +120,7 @@ int cw1200_hw_scan(struct ieee80211_hw *hw,
++priv->scan.n_ssids;
}
- if (frame.skb)
- dev_kfree_skb(frame.skb);
+ dev_kfree_skb(frame.skb);
mutex_unlock(&priv->conf_mutex);
queue_work(priv->workqueue, &priv->scan.work);
return 0;
--
2.23.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox