* 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
* [PATCH] ipw2x00: fix spelling mistake "initializationg" -> "initialization"
From: Colin King @ 2019-08-22 22:00 UTC (permalink / raw)
To: Stanislav Yakovlev, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in an IPW_DEBUG_INFO message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index fa55d2ccbfab..ed0f06532d5e 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -2721,7 +2721,7 @@ static void ipw_eeprom_init_sram(struct ipw_priv *priv)
/* Do not load eeprom data on fatal error or suspend */
ipw_write32(priv, IPW_EEPROM_LOAD_DISABLE, 0);
} else {
- IPW_DEBUG_INFO("Enabling FW initializationg of SRAM\n");
+ IPW_DEBUG_INFO("Enabling FW initialization of SRAM\n");
/* Load eeprom data on fatal error or suspend */
ipw_write32(priv, IPW_EEPROM_LOAD_DISABLE, 1);
--
2.20.1
^ permalink raw reply related
* Re: [linuxwifi] Intel Centrino Ultimate N 6300 regression
From: Antanas Uršulis @ 2019-08-22 22:42 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAG6aBkW09YFz4asHZkhWBUenBiT3dgb7iGXBCq8KkCM09QXjLg@mail.gmail.com>
I was investigating what appears to be the same issue on my T420
Thinkpad and at least found a workaround (and perhaps a clue for where
the bug could lie).
On 22/08/2019 01:12, Nigel Sollars wrote:
> Interesting to be sure, so here are the versions of kernel and wpa_supplicant,
>
> 5.2.9-200.fc30.x86_64
> wpa_supplicant-2.8-2.fc30.x86_64
Are you using NetworkManager by chance? I stumbled across a Red Hat bug
report[0] involving 'CTRL-EVENT-SCAN-FAILED ret=-22' and the proprietary
broadcom driver. A comment there[1] describes a workaround for their
issue, by making NetworkManager not randomise the MAC address during
access point scans.
Adopting that workaround also works for my Centrino Ultimate-N 6300 (rev
3e). Create a config file /etc/NetworkManager/conf.d/iwl.conf with contents:
[device]
match-device=driver:iwlwifi
wifi.scan-rand-mac-address=no
Then restart NetworkManager. Alternatively, downgrading wpa_supplicant
(to 2.7-r3 on Gentoo ~amd64) also works for me.
- Antanas
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1703745
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1703745#c56
^ permalink raw reply
* Re: pull-request: wireless-drivers 2019-08-21
From: David Miller @ 2019-08-22 23:12 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel, johannes
In-Reply-To: <87zhk359wd.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Wed, 21 Aug 2019 09:07:30 +0300
> here's a pull request to net for 5.3, more info below. I will be offline
> the next week, but Johannes should be able to help if there are any
> issues.
Pulled, thanks Kalle.
^ permalink raw reply
* RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio
From: Wen Gong @ 2019-08-23 2:46 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Wen Gong,
ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <874l29pffy.fsf@toke.dk>
> -----Original Message-----
> From: Toke Høiland-Jørgensen <toke@redhat.com>
> Sent: Thursday, August 22, 2019 8:12 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
> >> 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?
>
It is only for SDIO.
For PCIE, it does not have credit limit, firmware memory only need to save
The tx descriptor, not need for palyload.
> 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 46/49] ath11k: add wmi.h
From: Vasanthakumar Thiagarajan @ 2019-08-23 4:21 UTC (permalink / raw)
To: Johannes Berg
Cc: Kalle Valo, linux-wireless, ath11k, devicetree,
linux-wireless-owner
In-Reply-To: <c60afe716cc9ce3b511d8be0b04958342dfea908.camel@sipsolutions.net>
On 2019-08-21 01:59, Johannes Berg wrote:
> On Tue, 2019-08-20 at 18:48 +0300, Kalle Valo wrote:
>>
>> +enum wmi_cmd_group {
>> + /* 0 to 2 are reserved */
>> + WMI_GRP_START = 0x3,
>> + WMI_GRP_SCAN = WMI_GRP_START, /* 0x3 */
>> + WMI_GRP_PDEV, /* 0x4 */
>
> If you're going to spell out the numbers anyway, why not do it in C
> rather than a comment?
>
> WMI_GRP_PDEV = 0x4,
>
> would tell you just as much, and be much less error-prone.
Sure, we'll do it that way.
>
>> +struct wmi_pdev_set_hw_mode_cmd_param {
>> + u32 tlv_header;
>> + u32 pdev_id;
>> + u32 hw_mode_index;
>> + u32 num_band_to_mac;
>> +} __packed;
>
> Does it really makes sense for something to be using "u32" (i.e. host
> endian) but then __packed (kinda tagging it as "I am using this with
> the
> hardware, don't change the layout")?
Yes, this is mainly for tagging. Since Copy Engine does the
byte-swapping when working with big-endian
system, these are declared in host endian. Removing __packed also fine,
I guess.
>
> That really applies to a lot of the things here.
>
>> +struct channel_param {
>> + u8 chan_id;
>> + u8 pwr;
>> + u32 mhz;
>> + u32 half_rate:1,
>> + quarter_rate:1,
>> + dfs_set:1,
>> + dfs_set_cfreq2:1,
>> + is_chan_passive:1,
>> + allow_ht:1,
>> + allow_vht:1,
>> + set_agile:1;
>> + u32 phy_mode;
>> + u32 cfreq1;
>> + u32 cfreq2;
>> + char maxpower;
>> + char minpower;
>> + char maxregpower;
>> + u8 antennamax;
>> + u8 reg_class_id;
>> +} __packed;
>
> Bitfields in FW structs are even less likely to work right, I'd avoid
> that.
>
> (and if you have this copy engine do endian conversion, then the u8
> fields won't work right since that ending seems to be working on u32s?)
>
> That probably all applies elsewhere too, but the file is pretty long
> ;-)
Sure, we'll clean this up.
>
> Personally, I'd also consider splitting internal driver usage stuff and
> FW API into different files, but that's your decision. I just find it
> lets me understand it better even when I'm looking at it myself.
>
Sure, this will look better.
Thanks,
Vasanth
^ permalink raw reply
* pull request: iwlwifi firmware updates 2019-08-23
From: Luca Coelho @ 2019-08-23 4:45 UTC (permalink / raw)
To: linux-firmware@kernel.org
Cc: linux-wireless@vger.kernel.org, linuxwifi, kyle@infradead.org,
jwboyer@kernel.org, ben@decadent.org.uk, dor.shaish
[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]
Hi,
This contains some updated firmwares for all our currently maintained
FW binaries.
Please pull or let me know if there are any issues.
--
Cheers,
Luca.
The following changes since commit c0fb3d9862477e31717e04e008debf6328b8980a:
check_whence: Add copy-firmware.sh to the list of ignored files (2019-08-21 08:03:43 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-08-23
for you to fetch changes up to 40e4162adfc91390f6fbbd8269f9439832af1dde:
iwlwifi: update FWs to core45-152 release (2019-08-23 07:35:14 +0300)
----------------------------------------------------------------
Update iwlwifi firmwares to Core45-152
----------------------------------------------------------------
Luca Coelho (1):
iwlwifi: update FWs to core45-152 release
WHENCE | 22 +++++++++++-----------
iwlwifi-8000C-36.ucode | Bin 2401356 -> 2401356 bytes
iwlwifi-8265-36.ucode | Bin 2414592 -> 2414592 bytes
iwlwifi-9000-pu-b0-jf-b0-46.ucode | Bin 1467952 -> 1462068 bytes
iwlwifi-9260-th-b0-jf-b0-46.ucode | Bin 1469012 -> 1463820 bytes
iwlwifi-Qu-b0-hr-b0-48.ucode | Bin 1106204 -> 1106228 bytes
iwlwifi-Qu-b0-jf-b0-48.ucode | Bin 1052772 -> 1052796 bytes
iwlwifi-Qu-c0-hr-b0-48.ucode | Bin 1106224 -> 1106248 bytes
iwlwifi-Qu-c0-jf-b0-48.ucode | Bin 1052792 -> 1052816 bytes
iwlwifi-QuZ-a0-hr-b0-48.ucode | Bin 1105644 -> 1105668 bytes
iwlwifi-QuZ-a0-jf-b0-48.ucode | Bin 1052584 -> 1052608 bytes
iwlwifi-cc-a0-48.ucode | Bin 1096680 -> 1096704 bytes
12 files changed, 11 insertions(+), 11 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 07/10] iwlwifi: Use dev_get_drvdata where possible
From: Luciano Coelho @ 2019-08-23 5:09 UTC (permalink / raw)
To: Chuhong Yuan
Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, David S . Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20190724112738.13457-1-hslester96@gmail.com>
On Wed, 2019-07-24 at 19:27 +0800, Chuhong Yuan wrote:
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
This patch is not relevant anymore because we have removed all
D0i3/runtime PM code.
Thanks anyway!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] iwlwifi: remove redundant assignment to variable bufsz
From: Luca Coelho @ 2019-08-23 5:10 UTC (permalink / raw)
To: Colin King, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Kalle Valo, David S . Miller,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190801164419.3439-1-colin.king@canonical.com>
On Thu, 2019-08-01 at 17:44 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The variable bufsz is being initialized with a value that is never
> read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
Thanks! I applied this to our internal tree and it will reach the
mainline following our usual upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] iwlwifi: mvm: fix old-style declaration
From: Luciano Coelho @ 2019-08-23 5:17 UTC (permalink / raw)
To: YueHaibing, johannes.berg, emmanuel.grumbach, linuxwifi, kvalo,
sara.sharon
Cc: linux-kernel, netdev, linux-wireless
In-Reply-To: <20190726141838.19424-1-yuehaibing@huawei.com>
On Fri, 2019-07-26 at 22:18 +0800, YueHaibing wrote:
> There expect the 'static' keyword to come first in a
> declaration, and we get a warning for this with "make W=1":
>
> drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:427:1: warning:
> 'static' is not at beginning of declaration [-Wold-style-declaration]
> drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:434:1: warning:
> 'static' is not at beginning of declaration [-Wold-style-declaration]
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
Thanks! Johannes applied this in our internal tree a few weeks ago and
it will reach the mainline following our usual upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] iwlwifi: mvm: fix unaligned read of rx_pkt_status
From: Luca Coelho @ 2019-08-23 5:23 UTC (permalink / raw)
To: Wang Xuerui, linux-wireless
In-Reply-To: <20190223083543.6009-2-wangxuerui@qiniu.com>
On Sat, 2019-02-23 at 16:35 +0800, Wang Xuerui wrote:
> This is present since the introduction of iwlmvm.
> Example stack trace on MIPS:
>
> [<ffffffffc0789328>] iwl_mvm_rx_rx_mpdu+0xa8/0xb88 [iwlmvm]
> [<ffffffffc0632b40>] iwl_pcie_rx_handle+0x420/0xc48 [iwlwifi]
>
> Tested with a Wireless AC 7265 for ~6 months, confirmed to fix the
> problem. No other unaligned accesses are spotted yet.
>
> Signed-off-by: Wang Xuerui <wangxuerui@qiniu.com>
> Tested-by: Wang Xuerui <wangxuerui@qiniu.com>
> ---
Thanks! I have applied this to our internal tree and it will reach the
mainline following our normal upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v2] rtw88: pci: enable MSI interrupt
From: Daniel Drake @ 2019-08-23 6:37 UTC (permalink / raw)
To: yhchuang; +Cc: briannorris, gojun077, jano.vesely, kvalo, linux-wireless, linux
In-Reply-To: <1565166487-22048-1-git-send-email-yhchuang@realtek.com>
> + rtw_pci_disable_interrupt(rtwdev, rtwpci);
I checked the discussion on the v1 patch thread but I still don't follow
this.
You're worried about the case where we're inside the interrupt handler and:
1. We read the interrupt status to note what needs to be done
2. <another interrupt arrives here, requiring other work to be done>
3. We clear the interrupt status bits
4. We proceed to handle the interrupt but missing any work requested by
the interrupt in step 2.
Is that right?
I'm not an expert here, but I don't think this is something that drivers
have to worry about. Surely the interrupt controller can be expected to
have a mechanism to "queue up" any interrupt that arrives while an
interrupt is being handled? Otherwise handling of all types of
edge-triggered interrupts (not just MSI) would be overly painful across the
board.
See e.g. https://patchwork.kernel.org/patch/3333681/ as a reference for
what correct interrupt controller behaviour should look like.
> + ret = pci_enable_msi(pdev);
pci_enable_msi() is "deprecated, don't use"
Thanks
Daniel
^ permalink raw reply
* Re: [RFC/RFT v2] rt2x00: do not set IEEE80211_TX_STAT_AMPDU_NO_BACK on tx status
From: Stanislaw Gruszka @ 2019-08-23 6:51 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <20190712103228.17658-1-sgruszka@redhat.com>
On Fri, Jul 12, 2019 at 12:32:28PM +0200, Stanislaw Gruszka wrote:
> According to documentation IEEE80211_TX_STAT_AMPDU_NO_BACK is suppose
> to be used when we do not receive BA (BlockAck). However on rt2x00 we
> use it when remote station fail to decode one or more subframes within
> AMPDU (some bits are not set in BlockAck bitmap). Setting the flag result
> in sent of BAR (BlockAck Request) frame and this might result of abuse
> of BA session, since remote station can sent BA with incorrect
> sequence numbers after receiving BAR. This problem is visible especially
> when connecting two rt2800 devices.
>
> Previously I observed some performance benefits when using the flag
> when connecting with iwlwifi devices. But currently possibly due
> to recent changes in rt2x00 removing the flag has no effect on
> those test cases.
>
> So remove the IEEE80211_TX_STAT_AMPDU_NO_BACK.
>
> Additionally partially mimic mt76 behaviour: send BAR when
> starting/stopping BA session to workaround problems with some buggy
> clients. Do not sent BAR on PS wakeup since we lack all PS handling
> code what mt76 has.
Currently Felix posted patch that removed sending BAR on BA session
stop. And I do not see necessity for sending BAR on start, so I will
precede with first version of this patch, that just remove NO_BACK
flag.
Stanislaw
^ permalink raw reply
* [PATCH] rt2x00: do not set IEEE80211_TX_STAT_AMPDU_NO_BACK on tx status
From: Stanislaw Gruszka @ 2019-08-23 7:09 UTC (permalink / raw)
To: linux-wireless
Cc: Felix Fietkau, Daniel Golle, Tomislav Požega, Mathias Kresin
According to documentation IEEE80211_TX_STAT_AMPDU_NO_BACK is suppose
to be used when we do not recive BA (BlockAck). However on rt2x00 we
use it when remote station fail to decode one or more subframes within
AMPDU (some bits are not set in BlockAck bitmap). Setting the flag result
in sent of BAR (BlockAck Request) frame and this might result of abuse
of BA session, since remote station can sent BA with incorrect
sequence numbers after receiving BAR. This problem is visible especially
when connecting two rt2800 devices.
Previously I observed some performance benefits when using the flag
when connecting with iwlwifi devices. But currently possibly due
to reacent changes in rt2x00 removing the flag has no effect on
those test cases.
So remove the IEEE80211_TX_STAT_AMPDU_NO_BACK.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index 9d158237ac67..c3eab767bc21 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -371,9 +371,6 @@ static void rt2x00lib_fill_tx_status(struct rt2x00_dev *rt2x00dev,
IEEE80211_TX_CTL_AMPDU;
tx_info->status.ampdu_len = 1;
tx_info->status.ampdu_ack_len = success ? 1 : 0;
-
- if (!success)
- tx_info->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK;
}
if (rate_flags & IEEE80211_TX_RC_USE_RTS_CTS) {
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v2] rtw88: pci: enable MSI interrupt
From: Ján Veselý @ 2019-08-23 7:22 UTC (permalink / raw)
To: Daniel Drake
Cc: Tony Chuang, briannorris, gojun077, kvalo, linux-wireless, linux
In-Reply-To: <20190823063728.14117-1-drake@endlessm.com>
On Fri, Aug 23, 2019 at 2:37 AM Daniel Drake <drake@endlessm.com> wrote:
>
> > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
>
> I checked the discussion on the v1 patch thread but I still don't follow
> this.
>
> You're worried about the case where we're inside the interrupt handler and:
> 1. We read the interrupt status to note what needs to be done
> 2. <another interrupt arrives here, requiring other work to be done>
> 3. We clear the interrupt status bits
> 4. We proceed to handle the interrupt but missing any work requested by
> the interrupt in step 2.
>
> Is that right?
>
> I'm not an expert here, but I don't think this is something that drivers
> have to worry about. Surely the interrupt controller can be expected to
> have a mechanism to "queue up" any interrupt that arrives while an
> interrupt is being handled? Otherwise handling of all types of
> edge-triggered interrupts (not just MSI) would be overly painful across the
> board.
That's my understanding as well.
entering the interrupt vector clears the IFLAG, so any interrupt will
wait until the IFLAG is restored, or delivered to a different CPU.
wouldn't it be safer to enable interrupts only _after_ registering the
handler in the "rtw_pci_request_irq" function?
regards,
Jan
>
> See e.g. https://patchwork.kernel.org/patch/3333681/ as a reference for
> what correct interrupt controller behaviour should look like.
>
> > + ret = pci_enable_msi(pdev);
>
> pci_enable_msi() is "deprecated, don't use"
>
> Thanks
> Daniel
>
^ permalink raw reply
* [PATCH] brcmfmac: replace strncpy() by strscpy()
From: Xulin Sun @ 2019-08-23 7:47 UTC (permalink / raw)
To: kvalo
Cc: stefan.wahren, xulin.sun, linux-kernel, netdev,
brcm80211-dev-list, brcm80211-dev-list.pdl, linux-wireless,
arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, davem, stanley.hsu
The strncpy() may truncate the copied string,
replace it by the safer strscpy().
To avoid below compile warning with gcc 8.2:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:In function 'brcmf_vndr_ie':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4227:2:
warning: 'strncpy' output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation]
strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Xulin Sun <xulin.sun@windriver.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b6d0df354b36..7ad60374fa96 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4226,9 +4226,7 @@ brcmf_parse_vndr_ies(const u8 *vndr_ie_buf, u32 vndr_ie_len,
static u32
brcmf_vndr_ie(u8 *iebuf, s32 pktflag, u8 *ie_ptr, u32 ie_len, s8 *add_del_cmd)
{
-
- strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
- iebuf[VNDR_IE_CMD_LEN - 1] = '\0';
+ strscpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN);
put_unaligned_le32(1, &iebuf[VNDR_IE_COUNT_OFFSET]);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] brcmfmac: replace strncpy() by strscpy()
From: Arend Van Spriel @ 2019-08-23 8:18 UTC (permalink / raw)
To: Xulin Sun, kvalo
Cc: stefan.wahren, linux-kernel, netdev, brcm80211-dev-list,
brcm80211-dev-list.pdl, linux-wireless, franky.lin,
hante.meuleman, chi-hsien.lin, wright.feng, davem, stanley.hsu
In-Reply-To: <20190823074708.20081-1-xulin.sun@windriver.com>
On 8/23/2019 9:47 AM, Xulin Sun wrote:
> The strncpy() may truncate the copied string,
> replace it by the safer strscpy().
>
> To avoid below compile warning with gcc 8.2:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:In function 'brcmf_vndr_ie':
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4227:2:
> warning: 'strncpy' output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation]
> strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Xulin Sun <xulin.sun@windriver.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
^ permalink raw reply
* RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio
From: Toke Høiland-Jørgensen @ 2019-08-23 8:39 UTC (permalink / raw)
To: Wen Gong, Wen Gong, ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <250d064103394dfd864c1281f0da3d83@aptaiexm02f.ap.qualcomm.com>
Wen Gong <wgong@qti.qualcomm.com> writes:
>> -----Original Message-----
>> From: Toke Høiland-Jørgensen <toke@redhat.com>
>> Sent: Thursday, August 22, 2019 8:12 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
>> >> 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?
>>
> It is only for SDIO.
> For PCIE, it does not have credit limit, firmware memory only need to save
> The tx descriptor, not need for palyload.
OK, too bad. Thanks for the explanations :)
-Toke
^ permalink raw reply
* [PATCH] mt76: make mt76_rx_convert static
From: Stanislaw Gruszka @ 2019-08-23 8:46 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo
mt76_rx_convert() not need to be exported any longer.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 3 +--
drivers/net/wireless/mediatek/mt76/mt76.h | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index fa481d2f11bd..1a2c143b34d0 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -484,7 +484,7 @@ void mt76_wcid_key_setup(struct mt76_dev *dev, struct mt76_wcid *wcid,
}
EXPORT_SYMBOL(mt76_wcid_key_setup);
-struct ieee80211_sta *mt76_rx_convert(struct sk_buff *skb)
+static struct ieee80211_sta *mt76_rx_convert(struct sk_buff *skb)
{
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
struct mt76_rx_status mstat;
@@ -511,7 +511,6 @@ struct ieee80211_sta *mt76_rx_convert(struct sk_buff *skb)
return wcid_to_sta(mstat.wcid);
}
-EXPORT_SYMBOL(mt76_rx_convert);
static int
mt76_check_ccmp_pn(struct sk_buff *skb)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index d67c6a26c87c..570c159515a0 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -749,8 +749,6 @@ int mt76_sta_state(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
void __mt76_sta_remove(struct mt76_dev *dev, struct ieee80211_vif *vif,
struct ieee80211_sta *sta);
-struct ieee80211_sta *mt76_rx_convert(struct sk_buff *skb);
-
int mt76_get_min_avg_rssi(struct mt76_dev *dev);
int mt76_get_txpower(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
--
1.9.3
^ permalink raw reply related
* Re: [bug report] iwlwifi: Add support for SAR South Korea limitation
From: Luciano Coelho @ 2019-08-23 8:47 UTC (permalink / raw)
To: Dan Carpenter, haim.dreyfuss; +Cc: linux-wireless
In-Reply-To: <20190806142435.GA13072@mwanda>
Hi Dan,
On Tue, 2019-08-06 at 17:24 +0300, Dan Carpenter wrote:
> Hello Haim Dreyfuss,
>
> The patch 0c3d7282233c: "iwlwifi: Add support for SAR South Korea
> limitation" from Feb 27, 2019, leads to the following static checker
> warning:
>
> drivers/net/wireless/intel/iwlwifi/fw/acpi.c:166 iwl_acpi_get_mcc()
> warn: passing a valid pointer to 'PTR_ERR'
>
> drivers/net/wireless/intel/iwlwifi/fw/acpi.c
> 153 int iwl_acpi_get_mcc(struct device *dev, char *mcc)
> 154 {
> 155 union acpi_object *wifi_pkg, *data;
> 156 u32 mcc_val;
> 157 int ret, tbl_rev;
> 158
> 159 data = iwl_acpi_get_object(dev, ACPI_WRDD_METHOD);
> 160 if (IS_ERR(data))
> 161 return PTR_ERR(data);
> 162
> 163 wifi_pkg = iwl_acpi_get_wifi_pkg(dev, data, ACPI_WRDD_WIFI_DATA_SIZE,
> 164 &tbl_rev);
> 165 if (IS_ERR(wifi_pkg) || tbl_rev != 0) {
> ^^^^^^^^^^^^
> wifi_pkg is not a valid error code. Also it feels like it might be more
> future proof to blacklist rev 1 instead of whitelisting rev 0.
Yeah, this code is wrong. If wifi_pkg is valid but tbl_rev is != 0,
then we will return a valid pointer instead of an error. I'll fix
this.
But regarding blacklisting one, I think it's better as it is. We mean
that the only revision we support is 0, if we get 1 or higher, we
return -EINVAL, because we handle it. When we add support for other
revisions, we need to change it.
> 166 ret = PTR_ERR(wifi_pkg);
> 167 goto out_free;
> 168 }
Thanks for reporting!
(and yeah, I'll handle the other occurrences you mentioned too).
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH 0/3] mt76: channel switch related cleanups
From: Stanislaw Gruszka @ 2019-08-23 8:52 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo
Stanislaw Gruszka (3):
mt76: remove redundant mt76_txq_schedule_all
mt76: mt76x0: remove redundant chandef copy
mt76: mt76x0: remove unneeded return value on set channel
drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 1 -
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 2 --
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 -
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 15 ++++-----------
drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 4 ++--
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 9 +++------
drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c | 1 -
drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c | 2 --
drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c | 1 -
9 files changed, 9 insertions(+), 27 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH 1/3] mt76: remove redundant mt76_txq_schedule_all
From: Stanislaw Gruszka @ 2019-08-23 8:52 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo
In-Reply-To: <1566550337-6287-1-git-send-email-sgruszka@redhat.com>
Waking tx queues will cause that txq's will be scheduled. Calling
mt76_txq_schedule_all() while queues are blocked is not necessary.
We will not get any skb's from ieee80211_tx_dequeue() anyway, but
patch changes that transmit of mtxq->retry_q skb's will be a bit
deferred (on the moment after channel switch or other situation
when we wake up queues).
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 1 -
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 2 --
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 -
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 2 --
drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c | 1 -
drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c | 2 --
drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c | 1 -
7 files changed, 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
index c328192307c4..eb33de264c8a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
@@ -1344,7 +1344,6 @@ static void mt7603_mac_watchdog_reset(struct mt7603_dev *dev)
napi_schedule(&dev->mt76.napi[1]);
ieee80211_wake_queues(dev->mt76.hw);
- mt76_txq_schedule_all(&dev->mt76);
}
static u32 mt7603_dma_debug(struct mt7603_dev *dev, u8 index)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
index 25d5b1608bc9..3a1b18795e05 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
@@ -170,8 +170,6 @@ void mt7603_init_edcca(struct mt7603_dev *dev)
clear_bit(MT76_RESET, &dev->mt76.state);
- mt76_txq_schedule_all(&dev->mt76);
-
ieee80211_queue_delayed_work(mt76_hw(dev), &dev->mt76.mac_work,
msecs_to_jiffies(MT7603_WATCHDOG_TIME));
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 87c748715b5d..41ca44ffb058 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -158,7 +158,6 @@ static int mt7615_set_channel(struct mt7615_dev *dev)
clear_bit(MT76_RESET, &dev->mt76.state);
mutex_unlock(&dev->mt76.mutex);
- mt76_txq_schedule_all(&dev->mt76);
ieee80211_queue_delayed_work(mt76_hw(dev), &dev->mt76.mac_work,
MT7615_WATCHDOG_TIME);
return ret;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
index 3bc665643e51..562249eb918c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
@@ -33,8 +33,6 @@
}
mt76x02_pre_tbtt_enable(dev, true);
- mt76_txq_schedule_all(&dev->mt76);
-
return ret;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
index dc773070481d..fdc0297c1d27 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
@@ -513,7 +513,6 @@ static void mt76x02_watchdog_reset(struct mt76x02_dev *dev)
ieee80211_restart_hw(dev->mt76.hw);
} else {
ieee80211_wake_queues(dev->mt76.hw);
- mt76_txq_schedule_all(&dev->mt76);
}
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
index 4971685aafe8..8275a211fd20 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
@@ -68,8 +68,6 @@
tasklet_enable(&dev->dfs_pd.dfs_tasklet);
tasklet_enable(&dev->mt76.pre_tbtt_tasklet);
- mt76_txq_schedule_all(&dev->mt76);
-
return ret;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
index eb73cb856c81..d5bfffd6099d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c
@@ -58,7 +58,6 @@ static void mt76x2u_stop(struct ieee80211_hw *hw)
mutex_unlock(&dev->mt76.mutex);
mt76x02_pre_tbtt_enable(dev, true);
- mt76_txq_schedule_all(&dev->mt76);
return err;
}
--
1.9.3
^ permalink raw reply related
* [PATCH 2/3] mt76: mt76x0: remove redundant chandef copy
From: Stanislaw Gruszka @ 2019-08-23 8:52 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo
In-Reply-To: <1566550337-6287-1-git-send-email-sgruszka@redhat.com>
We set dev->mt76.chandef in mt76_set_channel() already.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index 31f988e86d92..1d00aa5da95b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -944,7 +944,6 @@ int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
freq1 = chandef->center_freq1;
channel = chandef->chan->hw_value;
rf_bw_band = (channel <= 14) ? RF_G_BAND : RF_A_BAND;
- dev->mt76.chandef = *chandef;
switch (chandef->width) {
case NL80211_CHAN_WIDTH_40:
--
1.9.3
^ permalink raw reply related
* [PATCH 3/3] mt76: mt76x0: remove unneeded return value on set channel
From: Stanislaw Gruszka @ 2019-08-23 8:52 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo
In-Reply-To: <1566550337-6287-1-git-send-email-sgruszka@redhat.com>
We allways return 0 from mt76x0_phy_set_channel(), no need to pass
return value upward.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 13 ++++---------
drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 4 ++--
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 8 +++-----
3 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
index 562249eb918c..8a3bb924bef4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
@@ -8,18 +8,16 @@
#include <linux/etherdevice.h>
#include "mt76x0.h"
-static int
+static void
mt76x0_set_channel(struct mt76x02_dev *dev, struct cfg80211_chan_def *chandef)
{
- int ret;
-
cancel_delayed_work_sync(&dev->cal_work);
mt76x02_pre_tbtt_enable(dev, false);
if (mt76_is_mmio(dev))
tasklet_disable(&dev->dfs_pd.dfs_tasklet);
mt76_set_channel(&dev->mt76);
- ret = mt76x0_phy_set_channel(dev, chandef);
+ mt76x0_phy_set_channel(dev, chandef);
/* channel cycle counters read-and-clear */
mt76_rr(dev, MT_CH_IDLE);
@@ -32,20 +30,17 @@
tasklet_enable(&dev->dfs_pd.dfs_tasklet);
}
mt76x02_pre_tbtt_enable(dev, true);
-
- return ret;
}
int mt76x0_config(struct ieee80211_hw *hw, u32 changed)
{
struct mt76x02_dev *dev = hw->priv;
- int ret = 0;
mutex_lock(&dev->mt76.mutex);
if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
ieee80211_stop_queues(hw);
- ret = mt76x0_set_channel(dev, &hw->conf.chandef);
+ mt76x0_set_channel(dev, &hw->conf.chandef);
ieee80211_wake_queues(hw);
}
@@ -67,6 +62,6 @@ int mt76x0_config(struct ieee80211_hw *hw, u32 changed)
mutex_unlock(&dev->mt76.mutex);
- return ret;
+ return 0;
}
EXPORT_SYMBOL_GPL(mt76x0_config);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h b/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
index caa87f0c3cb8..26517e062bdb 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
@@ -54,8 +54,8 @@ static inline bool is_mt7630(struct mt76x02_dev *dev)
/* PHY */
void mt76x0_phy_init(struct mt76x02_dev *dev);
int mt76x0_phy_wait_bbp_ready(struct mt76x02_dev *dev);
-int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
- struct cfg80211_chan_def *chandef);
+void mt76x0_phy_set_channel(struct mt76x02_dev *dev,
+ struct cfg80211_chan_def *chandef);
void mt76x0_phy_set_txpower(struct mt76x02_dev *dev);
void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool power_on);
#endif
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index 1d00aa5da95b..711a352dfd5c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -909,8 +909,8 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool power_on)
}
EXPORT_SYMBOL_GPL(mt76x0_phy_calibrate);
-int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
- struct cfg80211_chan_def *chandef)
+void mt76x0_phy_set_channel(struct mt76x02_dev *dev,
+ struct cfg80211_chan_def *chandef)
{
u32 ext_cca_chan[4] = {
[0] = FIELD_PREP(MT_EXT_CCA_CFG_CCA0, 0) |
@@ -1004,7 +1004,7 @@ int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
/* enable vco */
mt76x0_rf_set(dev, MT_RF(0, 4), BIT(7));
if (scan)
- return 0;
+ return;
mt76x02_init_agc_gain(dev);
mt76x0_phy_calibrate(dev, false);
@@ -1012,8 +1012,6 @@ int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
ieee80211_queue_delayed_work(dev->mt76.hw, &dev->cal_work,
MT_CALIBRATE_INTERVAL);
-
- return 0;
}
static void mt76x0_phy_temp_sensor(struct mt76x02_dev *dev)
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 1/3] mt76: remove redundant mt76_txq_schedule_all
From: Felix Fietkau @ 2019-08-23 9:27 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: Lorenzo Bianconi, Ryder Lee, Roy Luo
In-Reply-To: <1566550337-6287-2-git-send-email-sgruszka@redhat.com>
On 2019-08-23 10:52, Stanislaw Gruszka wrote:
> Waking tx queues will cause that txq's will be scheduled. Calling
> mt76_txq_schedule_all() while queues are blocked is not necessary.
> We will not get any skb's from ieee80211_tx_dequeue() anyway, but
> patch changes that transmit of mtxq->retry_q skb's will be a bit
> deferred (on the moment after channel switch or other situation
> when we wake up queues).
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Waking tx queues will not always cause txqs to be scheduled - only if an
attempt to dequeue was blocked because queues were stopped at that time.
Because of that, I don't think this patch is correct.
- Felix
^ permalink raw reply
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