* [PATCH][next] rsi: fix missing null pointer check from a failed ieee80211_probereq_get call
From: Colin King @ 2019-02-21 12:35 UTC (permalink / raw)
To: Amitkumar Karwar, Siva Rebbagondla, Kalle Valo, David S . Miller,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The call to ieee80211_probereq_get can return NULL if a skb allocation
fails, so add a null pointer check and free an earlier skb on the error
exit return path.
Fixes: 7fdcb8e12660 ("rsi: add support for hardware scan offload")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index 8c17842ac507..844f2fac298f 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -1726,6 +1726,10 @@ int rsi_send_bgscan_probe_req(struct rsi_common *common,
probereq_skb = ieee80211_probereq_get(common->priv->hw, vif->addr, ssid,
ssid_len, scan_req->ie_len);
+ if (!probereq_skb) {
+ dev_kfree_skb(skb);
+ return -ENOMEM;
+ }
memcpy(&skb->data[frame_len], probereq_skb->data, probereq_skb->len);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH wireless-drivers-next 2/2] brcmfmac: print firmware reported general status errors
From: Arend Van Spriel @ 2019-02-21 10:45 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Rafał Miłecki
In-Reply-To: <20190221103325.28228-2-zajec5@gmail.com>
On 2/21/2019 11:33 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Firmware may report general errors using a special message type. Add
> basic support for it by simply decoding & printing an error number.
>
> A sample situation in which firmware reports a buf error:
> CONSOLE: 027084.733 no host response IOCTL buffer available..so fail the request
> will now produce a "Firmware reported general error: 9" on the host.
Could have meaningful message instead of a number. I can do that in
follow up patch if you do not have the information.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> .../broadcom/brcm80211/brcmfmac/msgbuf.c | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
> index d711dc8ed606..d3780eae7f19 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
> @@ -134,6 +134,14 @@ struct msgbuf_completion_hdr {
> __le16 flow_ring_id;
> };
>
> +/* Data struct for the MSGBUF_TYPE_GEN_STATUS */
> +struct msgbuf_gen_status {
> + struct msgbuf_common_hdr msg;
> + struct msgbuf_completion_hdr compl_hdr;
> + __le16 write_idx;
> + __le32 rsvd0[3];
> +};
> +
> /* Data struct for the MSGBUF_TYPE_RING_STATUS */
> struct msgbuf_ring_status {
> struct msgbuf_common_hdr msg;
> @@ -1194,6 +1202,18 @@ brcmf_msgbuf_process_rx_complete(struct brcmf_msgbuf *msgbuf, void *buf)
> brcmf_netif_rx(ifp, skb);
> }
>
> +static void brcmf_msgbuf_process_gen_status(struct brcmf_msgbuf *msgbuf,
> + void *buf)
> +{
> + struct msgbuf_gen_status *gen_status = buf;
> + struct brcmf_pub *drvr = msgbuf->drvr;
> + int err;
> +
> + err = le16_to_cpu(gen_status->compl_hdr.status);
> + if (err)
> + bphy_err(drvr, "Firmware reported general error: %d\n", err);
> +}
> +
> static void brcmf_msgbuf_process_ring_status(struct brcmf_msgbuf *msgbuf,
> void *buf)
> {
> @@ -1273,6 +1293,10 @@ static void brcmf_msgbuf_process_msgtype(struct brcmf_msgbuf *msgbuf, void *buf)
>
> msg = (struct msgbuf_common_hdr *)buf;
> switch (msg->msgtype) {
> + case MSGBUF_TYPE_GEN_STATUS:
> + brcmf_dbg(MSGBUF, "MSGBUF_TYPE_GEN_STATUS\n");
> + brcmf_msgbuf_process_gen_status(msgbuf, buf);
> + break;
> case MSGBUF_TYPE_RING_STATUS:
> brcmf_dbg(MSGBUF, "MSGBUF_TYPE_RING_STATUS\n");
> brcmf_msgbuf_process_ring_status(msgbuf, buf);
>
^ permalink raw reply
* [PATCH wireless-drivers-next 2/2] brcmfmac: print firmware reported general status errors
From: Rafał Miłecki @ 2019-02-21 10:33 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190221103325.28228-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
Firmware may report general errors using a special message type. Add
basic support for it by simply decoding & printing an error number.
A sample situation in which firmware reports a buf error:
CONSOLE: 027084.733 no host response IOCTL buffer available..so fail the request
will now produce a "Firmware reported general error: 9" on the host.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../broadcom/brcm80211/brcmfmac/msgbuf.c | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index d711dc8ed606..d3780eae7f19 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -134,6 +134,14 @@ struct msgbuf_completion_hdr {
__le16 flow_ring_id;
};
+/* Data struct for the MSGBUF_TYPE_GEN_STATUS */
+struct msgbuf_gen_status {
+ struct msgbuf_common_hdr msg;
+ struct msgbuf_completion_hdr compl_hdr;
+ __le16 write_idx;
+ __le32 rsvd0[3];
+};
+
/* Data struct for the MSGBUF_TYPE_RING_STATUS */
struct msgbuf_ring_status {
struct msgbuf_common_hdr msg;
@@ -1194,6 +1202,18 @@ brcmf_msgbuf_process_rx_complete(struct brcmf_msgbuf *msgbuf, void *buf)
brcmf_netif_rx(ifp, skb);
}
+static void brcmf_msgbuf_process_gen_status(struct brcmf_msgbuf *msgbuf,
+ void *buf)
+{
+ struct msgbuf_gen_status *gen_status = buf;
+ struct brcmf_pub *drvr = msgbuf->drvr;
+ int err;
+
+ err = le16_to_cpu(gen_status->compl_hdr.status);
+ if (err)
+ bphy_err(drvr, "Firmware reported general error: %d\n", err);
+}
+
static void brcmf_msgbuf_process_ring_status(struct brcmf_msgbuf *msgbuf,
void *buf)
{
@@ -1273,6 +1293,10 @@ static void brcmf_msgbuf_process_msgtype(struct brcmf_msgbuf *msgbuf, void *buf)
msg = (struct msgbuf_common_hdr *)buf;
switch (msg->msgtype) {
+ case MSGBUF_TYPE_GEN_STATUS:
+ brcmf_dbg(MSGBUF, "MSGBUF_TYPE_GEN_STATUS\n");
+ brcmf_msgbuf_process_gen_status(msgbuf, buf);
+ break;
case MSGBUF_TYPE_RING_STATUS:
brcmf_dbg(MSGBUF, "MSGBUF_TYPE_RING_STATUS\n");
brcmf_msgbuf_process_ring_status(msgbuf, buf);
--
2.20.1
^ permalink raw reply related
* [PATCH wireless-drivers-next 1/2] brcmfmac: fix size of the struct msgbuf_ring_status
From: Rafał Miłecki @ 2019-02-21 10:33 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
This updates host struct to match the in-firmawre definition. It's a
cosmetic change as it only applies to the reserved struct space.
Fixes: c988b78244df ("brcmfmac: print firmware reported ring status errors")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index aef2d4092872..d711dc8ed606 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -139,7 +139,7 @@ struct msgbuf_ring_status {
struct msgbuf_common_hdr msg;
struct msgbuf_completion_hdr compl_hdr;
__le16 write_idx;
- __le32 rsvd0[5];
+ __le16 rsvd0[5];
};
struct msgbuf_rx_event {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH wireless-drivers-next] brcmfmac: add basic validation of shared RAM address
From: Arend Van Spriel @ 2019-02-21 10:30 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <CACna6rxXJWwysJTauSKAb6rLeaXi1CBZSGcFNA5Nxn0ncQnG4Q@mail.gmail.com>
On 2/21/2019 10:27 AM, Rafał Miłecki wrote:
> On Thu, 21 Feb 2019 at 09:59, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 2/21/2019 9:01 AM, Rafał Miłecki wrote:
>>> On Wed, 20 Feb 2019 at 11:31, Rafał Miłecki <zajec5@gmail.com> wrote:
>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>
>>>> While experimenting with firmware loading I ended up in a state of
>>>> firmware reporting shared RAM address 0x04000001. It was causing:
>>>> [ 94.448015] Unable to handle kernel paging request at virtual address cd680001
>>>> due to reading out of the mapped memory.
>>>>
>>>> This patch adds some basic validation to avoid kernel crashes due to the
>>>> unexpected firmware behavior.
>>>
>>> For a reference for the further hackers. That has been caused by a
>>> BCMA_CORE_SYS_MEM core on my BCM4366/4 not being up.
>>
>> Thanks, Rafał
>>
>> Does that happen all the time or in some specific scenario. Anyway, it
>> seems like we need to add a check in brcmf_chip_sysmem_ramsize() and
>> bringup the core if needed. Although, I am curious in what the state the
>> other cores are at that time. Might need a chip-wide reset.
>
> It happens after brcmf_pcie_reset_device() which is probably a 100%
> expected case ;)
Did not check what that function exactly does, but could be expected.
> Normally brcmfmac does not call brcmf_pcie_reset_device() between
> brcmf_chip_sysmem_ramsize() and the brcmf_pcie_download_fw_nvram() so
> it was only my hacking that caused that issue for me.
Ah. Can only wish you happy hacking then ;-)
Gr. AvS
^ permalink raw reply
* Re: [PATCH wireless-drivers-next] brcmfmac: add basic validation of shared RAM address
From: Rafał Miłecki @ 2019-02-21 9:27 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER <brcm80211-dev-list.pdl@broadcom.com>,,
Rafał Miłecki
In-Reply-To: <92e8bf1e-3be9-96f2-93e9-ac504a609929@broadcom.com>
On Thu, 21 Feb 2019 at 09:59, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 2/21/2019 9:01 AM, Rafał Miłecki wrote:
> > On Wed, 20 Feb 2019 at 11:31, Rafał Miłecki <zajec5@gmail.com> wrote:
> >> From: Rafał Miłecki <rafal@milecki.pl>
> >>
> >> While experimenting with firmware loading I ended up in a state of
> >> firmware reporting shared RAM address 0x04000001. It was causing:
> >> [ 94.448015] Unable to handle kernel paging request at virtual address cd680001
> >> due to reading out of the mapped memory.
> >>
> >> This patch adds some basic validation to avoid kernel crashes due to the
> >> unexpected firmware behavior.
> >
> > For a reference for the further hackers. That has been caused by a
> > BCMA_CORE_SYS_MEM core on my BCM4366/4 not being up.
>
> Thanks, Rafał
>
> Does that happen all the time or in some specific scenario. Anyway, it
> seems like we need to add a check in brcmf_chip_sysmem_ramsize() and
> bringup the core if needed. Although, I am curious in what the state the
> other cores are at that time. Might need a chip-wide reset.
It happens after brcmf_pcie_reset_device() which is probably a 100%
expected case ;)
Normally brcmfmac does not call brcmf_pcie_reset_device() between
brcmf_chip_sysmem_ramsize() and the brcmf_pcie_download_fw_nvram() so
it was only my hacking that caused that issue for me.
--
Rafał
^ permalink raw reply
* Re: [PATCH wireless-drivers-next] brcmfmac: add basic validation of shared RAM address
From: Arend Van Spriel @ 2019-02-21 8:59 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <CACna6rwwDN6svzWMGbxYXDp5CN8C=A=fV224QcfoLcACQQgLDA@mail.gmail.com>
On 2/21/2019 9:01 AM, Rafał Miłecki wrote:
> On Wed, 20 Feb 2019 at 11:31, Rafał Miłecki <zajec5@gmail.com> wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> While experimenting with firmware loading I ended up in a state of
>> firmware reporting shared RAM address 0x04000001. It was causing:
>> [ 94.448015] Unable to handle kernel paging request at virtual address cd680001
>> due to reading out of the mapped memory.
>>
>> This patch adds some basic validation to avoid kernel crashes due to the
>> unexpected firmware behavior.
>
> For a reference for the further hackers. That has been caused by a
> BCMA_CORE_SYS_MEM core on my BCM4366/4 not being up.
Thanks, Rafał
Does that happen all the time or in some specific scenario. Anyway, it
seems like we need to add a check in brcmf_chip_sysmem_ramsize() and
bringup the core if needed. Although, I am curious in what the state the
other cores are at that time. Might need a chip-wide reset.
Regards,
Arend
^ permalink raw reply
* Re: Does Linux Kernel 5.0-rc7 Support High Efficiency Wireless IEEE 802.11ax and IEEE 802.11ay (Wi-Fi Alliance Wi-Fi 6)?
From: Johannes Berg @ 2019-02-21 8:38 UTC (permalink / raw)
To: Turritopsis Dohrnii Teo En Ming, linux-wireless
In-Reply-To: <CANnei0E3kjvSEz2_7AxNhMVBfqEy76=3o05j9ogLvvj-04MCww@mail.gmail.com>
On Thu, 2019-02-21 at 13:05 +0800, Turritopsis Dohrnii Teo En Ming
wrote:
> Good afternoon from Singapore,
>
> Does Linux Kernel 5.0-rc7 Support High Efficiency Wireless IEEE
> 802.11ax and IEEE 802.11ay (Wi-Fi Alliance Wi-Fi 6)?
Depends what you want. But no, basically no, or at least not that
version and not yet.
> ===BEGIN EMAIL SIGNATURE===
>
[...]
> ===END EMAIL SIGNATURE===
Please remove this when you post to this list.
johannes
^ permalink raw reply
* [PATCH v2] iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_debug_range_resp
From: Nathan Chancellor @ 2019-02-21 8:06 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Nick Desaulniers,
Nathan Chancellor, Arnd Bergmann
In-Reply-To: <20190219182105.19933-1-natechancellor@gmail.com>
Clang warns:
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: warning:
comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka 'long
long *') and 'uint64_t *' (aka 'unsigned long long *'))
[-Wcompare-distinct-pointer-types]
do_div(rtt_avg, 6666);
^~~~~~~~~~~~~~~~~~~~~
include/asm-generic/div64.h:222:28: note: expanded from macro 'do_div'
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
1 warning generated.
do_div expects an unsigned dividend. Use div_s64, which expects a signed
dividend.
Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM")
Link: https://github.com/ClangBuiltLinux/linux/issues/372
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Fix logic (as the return value of div{,64}_s64 must be used), thanks
to Arnd for the review.
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
index e9822a3ec373..94132cfd1f56 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
@@ -460,9 +460,7 @@ static int iwl_mvm_ftm_range_resp_valid(struct iwl_mvm *mvm, u8 request_id,
static void iwl_mvm_debug_range_resp(struct iwl_mvm *mvm, u8 index,
struct cfg80211_pmsr_result *res)
{
- s64 rtt_avg = res->ftm.rtt_avg * 100;
-
- do_div(rtt_avg, 6666);
+ s64 rtt_avg = div_s64(res->ftm.rtt_avg * 100, 6666);
IWL_DEBUG_INFO(mvm, "entry %d\n", index);
IWL_DEBUG_INFO(mvm, "\tstatus: %d\n", res->status);
--
2.21.0.rc1
^ permalink raw reply related
* Re: [PATCH wireless-drivers-next] brcmfmac: add basic validation of shared RAM address
From: Rafał Miłecki @ 2019-02-21 8:01 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER <brcm80211-dev-list.pdl@broadcom.com>,,
Rafał Miłecki
In-Reply-To: <20190220103047.8960-1-zajec5@gmail.com>
On Wed, 20 Feb 2019 at 11:31, Rafał Miłecki <zajec5@gmail.com> wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> While experimenting with firmware loading I ended up in a state of
> firmware reporting shared RAM address 0x04000001. It was causing:
> [ 94.448015] Unable to handle kernel paging request at virtual address cd680001
> due to reading out of the mapped memory.
>
> This patch adds some basic validation to avoid kernel crashes due to the
> unexpected firmware behavior.
For a reference for the further hackers. That has been caused by a
BCMA_CORE_SYS_MEM core on my BCM4366/4 not being up.
^ permalink raw reply
* Re: [PATCH] iwlwifi: mvm: Use div64_s64 instead of do_div in iwl_mvm_debug_range_resp
From: Luciano Coelho @ 2019-02-21 7:33 UTC (permalink / raw)
To: Nathan Chancellor, Arnd Bergmann
Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, linux-wireless, Networking, Linux Kernel Mailing List,
Nick Desaulniers
In-Reply-To: <20190220175615.GA1312@archlinux-ryzen>
On Wed, 2019-02-20 at 10:56 -0700, Nathan Chancellor wrote:
> On Wed, Feb 20, 2019 at 11:51:34AM +0100, Arnd Bergmann wrote:
> > On Tue, Feb 19, 2019 at 7:22 PM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-
> > > initiator.c b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-
> > > initiator.c
> > > index e9822a3ec373..92b22250eb7d 100644
> > > --- a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> > > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> > > @@ -462,7 +462,7 @@ static void iwl_mvm_debug_range_resp(struct
> > > iwl_mvm *mvm, u8 index,
> > > {
> > > s64 rtt_avg = res->ftm.rtt_avg * 100;
> > >
> > > - do_div(rtt_avg, 6666);
> > > + div64_s64(rtt_avg, 6666);
> >
> > This is wrong: div64_s64 does not modify its argument like
> > do_div(), but
> > it returns the result instead. You also don't want to divide by a
> > 64-bit
> > value when the second argument is a small constant.
> >
> > I think the correct way should be
> >
> > s64 rtt_avg = div_s64(res->ftm.rtt_avg * 100, 6666);
> >
> > If you know that the value is positive, using unsigned types
> > and div_u64() would be slightly faster.
> >
> > Arnd
>
> Thanks for the review and explanation, Arnd.
>
> Luca, could you drop this version so I can resend it?
Sure, please do! I already applied this internally, but I can just fix
it with your new patch and that will be squashed before being sent
upstream, so it will look like your second patch.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] mt76: usb: fix warning in mt76u_buf_free
From: Lorenzo Bianconi @ 2019-02-21 7:15 UTC (permalink / raw)
To: Kalle Valo; +Cc: nbd, linux-wireless, sgruszka, lorenzo.bianconi, dan.carpenter
In-Reply-To: <87bm3520bq.fsf@purkki.adurom.net>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
> lorenzo@kernel.org writes:
>
> > From: Lorenzo Bianconi <lorenzo@kernel.org>
> >
> > Fix following static checker warning in mt76u_buf_free:
> > drivers/net/wireless/mediatek/mt76/usb.c:372 mt76u_buf_free()
> > warn: address of 'urb->sg[i]' is non-NULL
> >
> > There is no need to check sg page pointer since urb->num_sgs
> > has been already validated in mt76u_fill_rx_sg
> >
> > Fixes: cb83585e1121 ("mt76: usb: fix possible memory leak in mt76u_buf_free")
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> The merge window is really close, should I take this directly to
> wireless-drivers-next?
Hi Kalle,
I think this patch can go in Felix's tree for the moment since it just fixes the warning,
the intended behaviour is to run skb_free_frag()
Regards,
Lorenzo
>
> BTW, Lorenzo please add your name to SMTP From line to make threading
> cleaner:
>
> From: lorenzo@kernel.org
>
> --
> Kalle Valo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] mt76: usb: fix warning in mt76u_buf_free
From: Kalle Valo @ 2019-02-21 5:10 UTC (permalink / raw)
To: lorenzo; +Cc: nbd, linux-wireless, sgruszka, lorenzo.bianconi, dan.carpenter
In-Reply-To: <bfd5659680fb3ef89554a48ff950d74dd88240dd.1550706341.git.lorenzo@kernel.org>
lorenzo@kernel.org writes:
> From: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Fix following static checker warning in mt76u_buf_free:
> drivers/net/wireless/mediatek/mt76/usb.c:372 mt76u_buf_free()
> warn: address of 'urb->sg[i]' is non-NULL
>
> There is no need to check sg page pointer since urb->num_sgs
> has been already validated in mt76u_fill_rx_sg
>
> Fixes: cb83585e1121 ("mt76: usb: fix possible memory leak in mt76u_buf_free")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
The merge window is really close, should I take this directly to
wireless-drivers-next?
BTW, Lorenzo please add your name to SMTP From line to make threading
cleaner:
From: lorenzo@kernel.org
--
Kalle Valo
^ permalink raw reply
* Does Linux Kernel 5.0-rc7 Support High Efficiency Wireless IEEE 802.11ax and IEEE 802.11ay (Wi-Fi Alliance Wi-Fi 6)?
From: Turritopsis Dohrnii Teo En Ming @ 2019-02-21 5:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Turritopsis Dohrnii Teo En Ming
Good afternoon from Singapore,
Does Linux Kernel 5.0-rc7 Support High Efficiency Wireless IEEE
802.11ax and IEEE 802.11ay (Wi-Fi Alliance Wi-Fi 6)?
Thank you.
===BEGIN EMAIL SIGNATURE===
The Gospel for all Targeted Individuals (TIs):
[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers
Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html
********************************************************************************************
Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic
Qualifications as at 14 Feb 2019
[1] https://tdtemcerts.wordpress.com/
[2] https://tdtemcerts.blogspot.sg/
[3] https://www.scribd.com/user/270125049/Teo-En-Ming
===END EMAIL SIGNATURE===
^ permalink raw reply
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Kalle Valo @ 2019-02-21 4:39 UTC (permalink / raw)
To: Grant Grundler
Cc: Toke Høiland-Jørgensen, linux-wireless, Johannes Berg,
wgong, ath10k, wgong
In-Reply-To: <CANEJEGuBoRMBJBOrFOYyPtiJSMfTahrVgTfxZ2ift6Q5uGazFA@mail.gmail.com>
Grant Grundler <grundler@google.com> writes:
> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> Grant Grundler <grundler@google.com> writes:
>>
>> >> And, well, Grant's data is from a single test in a noisy
>> >> environment where the time series graph shows that throughput is all over
>> >> the place for the duration of the test; so it's hard to draw solid
>> >> conclusions from (for instance, for the 5-stream test, the average
>> >> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
>> >> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
>> >> used in this test, so I can't go verify it myself; so the only thing I
>> >> can do is grumble about it here... :)
>> >
>> > It's a fair complaint and I agree with it. My counter argument is the
>> > opposite is true too: most ideal benchmarks don't measure what most
>> > users see. While the data wgong provided are way more noisy than I
>> > like, my overall "confidence" in the "conclusion" I offered is still
>> > positive.
>>
>> Right. I guess I would just prefer a slightly more comprehensive
>> evaluation to base a 4x increase in buffer size on...
>
> Kalle, is this why you didn't accept this patch? Other reasons?
Just for reference, here are patchwork links:
https://patchwork.kernel.org/cover/10559729/
https://patchwork.kernel.org/patch/10559731/
https://patchwork.kernel.org/patch/10559733/
The mac80211 patch is accepted and the ath10k patch is deferred. IIRC I
put it deferred as I didn't see a real consensus about the patch and was
supposed to look at it later, but haven't done yet. I don't have any
issues with the patch, except maybe removing the duplicate define for
9377 (which I can easily fix in the pending branch).
--
Kalle Valo
^ permalink raw reply
* [PATCH] mt76: usb: fix warning in mt76u_buf_free
From: lorenzo @ 2019-02-20 23:57 UTC (permalink / raw)
To: nbd
Cc: linux-wireless, sgruszka, lorenzo.bianconi, dan.carpenter,
Lorenzo Bianconi
In-Reply-To: <cover.1550706341.git.lorenzo@kernel.org>
From: Lorenzo Bianconi <lorenzo@kernel.org>
Fix following static checker warning in mt76u_buf_free:
drivers/net/wireless/mediatek/mt76/usb.c:372 mt76u_buf_free()
warn: address of 'urb->sg[i]' is non-NULL
There is no need to check sg page pointer since urb->num_sgs
has been already validated in mt76u_fill_rx_sg
Fixes: cb83585e1121 ("mt76: usb: fix possible memory leak in mt76u_buf_free")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/usb.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index cbfddf2ebfeb..ac3da948d43a 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -364,16 +364,11 @@ mt76u_buf_alloc(struct mt76_dev *dev, struct mt76u_buf *buf)
void mt76u_buf_free(struct mt76u_buf *buf)
{
struct urb *urb = buf->urb;
- struct scatterlist *sg;
int i;
- for (i = 0; i < urb->num_sgs; i++) {
- sg = &urb->sg[i];
- if (!sg)
- continue;
+ for (i = 0; i < urb->num_sgs; i++)
+ skb_free_frag(sg_virt(&urb->sg[i]));
- skb_free_frag(sg_virt(sg));
- }
if (buf->buf)
skb_free_frag(buf->buf);
--
2.20.1
^ permalink raw reply related
* [PATCH 3/3] mt76: usb: simplify mt76u_tx_build_sg routine
From: lorenzo @ 2019-02-20 22:35 UTC (permalink / raw)
To: nbd; +Cc: linux-wireless, sgruszka, lorenzo.bianconi, Lorenzo Bianconi
In-Reply-To: <cover.1550701735.git.lorenzo@kernel.org>
From: Lorenzo Bianconi <lorenzo@kernel.org>
Use skb_to_sgvec instad of skb_to_sgvec_nomark in mt76u_tx_build_sg.
Remove nsgs check in mt76u_tx_build_sg since it is already performed
by skb_to_sgvec
Suggested-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/usb.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 211ef7876de2..cbfddf2ebfeb 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -719,23 +719,12 @@ static int
mt76u_tx_build_sg(struct mt76_dev *dev, struct sk_buff *skb,
struct urb *urb)
{
- struct sk_buff *iter;
- int nsgs;
-
if (!dev->usb.sg_en)
return 0;
- nsgs = 1 + skb_shinfo(skb)->nr_frags;
- skb_walk_frags(skb, iter)
- nsgs += 1 + skb_shinfo(iter)->nr_frags;
-
- memset(urb->sg, 0, sizeof(*urb->sg) * MT_SG_MAX_SIZE);
-
- nsgs = min_t(int, MT_SG_MAX_SIZE, nsgs);
- sg_init_marker(urb->sg, nsgs);
- urb->num_sgs = nsgs;
-
- return skb_to_sgvec_nomark(skb, urb->sg, 0, skb->len);
+ sg_init_table(urb->sg, MT_SG_MAX_SIZE);
+ urb->num_sgs = skb_to_sgvec(skb, urb->sg, 0, skb->len);
+ return urb->num_sgs;
}
static int
--
2.20.1
^ permalink raw reply related
* [PATCH 2/3] mt76: usb: simplify rx buffer allocation
From: lorenzo @ 2019-02-20 22:35 UTC (permalink / raw)
To: nbd; +Cc: linux-wireless, sgruszka, lorenzo.bianconi, Lorenzo Bianconi
In-Reply-To: <cover.1550701735.git.lorenzo@kernel.org>
From: Lorenzo Bianconi <lorenzo@kernel.org>
Squash mt76u_buf_alloc_sg and mt76u_buf_alloc and remove duplicated
code. Reuse mt76u_refill_rx in mt76u_buf_alloc
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 2 -
drivers/net/wireless/mediatek/mt76/usb.c | 76 ++++++++---------------
2 files changed, 27 insertions(+), 51 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index a689af307a71..3b674228542d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -751,8 +751,6 @@ void mt76u_single_wr(struct mt76_dev *dev, const u8 req,
const u16 offset, const u32 val);
int mt76u_init(struct mt76_dev *dev, struct usb_interface *intf);
void mt76u_deinit(struct mt76_dev *dev);
-int mt76u_buf_alloc(struct mt76_dev *dev, struct mt76u_buf *buf,
- int len, int data_len, gfp_t gfp);
void mt76u_buf_free(struct mt76u_buf *buf);
int mt76u_submit_buf(struct mt76_dev *dev, int dir, int index,
struct mt76u_buf *buf, gfp_t gfp,
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 76c952c29c6e..211ef7876de2 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -324,41 +324,41 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76u_buf *buf,
}
static int
-mt76u_buf_alloc_sg(struct mt76_dev *dev, struct mt76u_buf *buf,
- int nsgs, int len, int sglen, gfp_t gfp)
+mt76u_refill_rx(struct mt76_dev *dev, struct mt76_queue *q,
+ struct mt76u_buf *buf, int nsgs, gfp_t gfp)
{
- buf->urb = usb_alloc_urb(0, gfp);
- if (!buf->urb)
- return -ENOMEM;
-
- buf->urb->sg = devm_kcalloc(dev->dev, nsgs, sizeof(*buf->urb->sg),
- gfp);
- if (!buf->urb->sg)
- return -ENOMEM;
-
- sg_init_table(buf->urb->sg, nsgs);
- buf->dev = dev;
-
- return mt76u_fill_rx_sg(dev, buf, nsgs, len, sglen);
+ if (dev->usb.sg_en) {
+ return mt76u_fill_rx_sg(dev, buf, nsgs, q->buf_size,
+ SKB_WITH_OVERHEAD(q->buf_size));
+ } else {
+ buf->buf = page_frag_alloc(&q->rx_page, q->buf_size, gfp);
+ return buf->buf ? 0 : -ENOMEM;
+ }
}
-int mt76u_buf_alloc(struct mt76_dev *dev, struct mt76u_buf *buf,
- int len, int data_len, gfp_t gfp)
+static int
+mt76u_buf_alloc(struct mt76_dev *dev, struct mt76u_buf *buf)
{
struct mt76_queue *q = &dev->q_rx[MT_RXQ_MAIN];
- buf->urb = usb_alloc_urb(0, gfp);
+ buf->len = SKB_WITH_OVERHEAD(q->buf_size);
+ buf->dev = dev;
+
+ buf->urb = usb_alloc_urb(0, GFP_KERNEL);
if (!buf->urb)
return -ENOMEM;
- buf->buf = page_frag_alloc(&q->rx_page, len, gfp);
- if (!buf->buf)
- return -ENOMEM;
+ if (dev->usb.sg_en) {
+ buf->urb->sg = devm_kcalloc(dev->dev, MT_SG_MAX_SIZE,
+ sizeof(*buf->urb->sg),
+ GFP_KERNEL);
+ if (!buf->urb->sg)
+ return -ENOMEM;
- buf->len = data_len;
- buf->dev = dev;
+ sg_init_table(buf->urb->sg, MT_SG_MAX_SIZE);
+ }
- return 0;
+ return mt76u_refill_rx(dev, q, buf, MT_SG_MAX_SIZE, GFP_KERNEL);
}
void mt76u_buf_free(struct mt76u_buf *buf)
@@ -519,20 +519,6 @@ static void mt76u_complete_rx(struct urb *urb)
spin_unlock_irqrestore(&q->lock, flags);
}
-static int
-mt76u_refill_rx(struct mt76_dev *dev, struct mt76_queue *q,
- struct mt76u_buf *buf, int nsgs)
-{
- if (dev->usb.sg_en) {
- return mt76u_fill_rx_sg(dev, buf, nsgs, q->buf_size,
- SKB_WITH_OVERHEAD(q->buf_size));
- } else {
- buf->buf = page_frag_alloc(&q->rx_page, q->buf_size,
- GFP_ATOMIC);
- return buf->buf ? 0 : -ENOMEM;
- }
-}
-
static void mt76u_rx_tasklet(unsigned long data)
{
struct mt76_dev *dev = (struct mt76_dev *)data;
@@ -549,7 +535,8 @@ static void mt76u_rx_tasklet(unsigned long data)
count = mt76u_process_rx_entry(dev, buf);
if (count > 0) {
- err = mt76u_refill_rx(dev, q, buf, count);
+ err = mt76u_refill_rx(dev, q, buf, count,
+ GFP_ATOMIC);
if (err < 0)
break;
}
@@ -605,16 +592,7 @@ static int mt76u_alloc_rx(struct mt76_dev *dev)
q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
q->ndesc = MT_NUM_RX_ENTRIES;
for (i = 0; i < q->ndesc; i++) {
- if (dev->usb.sg_en)
- err = mt76u_buf_alloc_sg(dev, &q->entry[i].ubuf,
- MT_SG_MAX_SIZE, q->buf_size,
- SKB_WITH_OVERHEAD(q->buf_size),
- GFP_KERNEL);
- else
- err = mt76u_buf_alloc(dev, &q->entry[i].ubuf,
- q->buf_size,
- SKB_WITH_OVERHEAD(q->buf_size),
- GFP_KERNEL);
+ err = mt76u_buf_alloc(dev, &q->entry[i].ubuf);
if (err < 0)
return err;
}
--
2.20.1
^ permalink raw reply related
* [PATCH 1/3] mt76: usb: introduce mt76u_fill_bulk_urb routine
From: lorenzo @ 2019-02-20 22:35 UTC (permalink / raw)
To: nbd; +Cc: linux-wireless, sgruszka, lorenzo.bianconi, Lorenzo Bianconi
In-Reply-To: <cover.1550701735.git.lorenzo@kernel.org>
From: Lorenzo Bianconi <lorenzo@kernel.org>
Add mt76u_fill_bulk_urb to initialize tx/rx urbs and
remove duplicate code
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/usb.c | 45 ++++++++++++++----------
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index db2ef648431f..76c952c29c6e 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -381,9 +381,10 @@ void mt76u_buf_free(struct mt76u_buf *buf)
}
EXPORT_SYMBOL_GPL(mt76u_buf_free);
-int mt76u_submit_buf(struct mt76_dev *dev, int dir, int index,
- struct mt76u_buf *buf, gfp_t gfp,
- usb_complete_t complete_fn, void *context)
+static void
+mt76u_fill_bulk_urb(struct mt76_dev *dev, int dir, int index,
+ struct mt76u_buf *buf, usb_complete_t complete_fn,
+ void *context)
{
struct usb_interface *intf = to_usb_interface(dev->dev);
struct usb_device *udev = interface_to_usbdev(intf);
@@ -397,6 +398,14 @@ int mt76u_submit_buf(struct mt76_dev *dev, int dir, int index,
usb_fill_bulk_urb(buf->urb, udev, pipe, data, buf->len,
complete_fn, context);
+}
+
+int mt76u_submit_buf(struct mt76_dev *dev, int dir, int index,
+ struct mt76u_buf *buf, gfp_t gfp,
+ usb_complete_t complete_fn, void *context)
+{
+ mt76u_fill_bulk_urb(dev, dir, index, buf, complete_fn,
+ context);
trace_submit_urb(dev, buf->urb);
return usb_submit_urb(buf->urb, gfp);
@@ -729,11 +738,16 @@ static void mt76u_complete_tx(struct urb *urb)
}
static int
-mt76u_tx_build_sg(struct sk_buff *skb, struct urb *urb)
+mt76u_tx_build_sg(struct mt76_dev *dev, struct sk_buff *skb,
+ struct urb *urb)
{
- int nsgs = 1 + skb_shinfo(skb)->nr_frags;
struct sk_buff *iter;
+ int nsgs;
+
+ if (!dev->usb.sg_en)
+ return 0;
+ nsgs = 1 + skb_shinfo(skb)->nr_frags;
skb_walk_frags(skb, iter)
nsgs += 1 + skb_shinfo(iter)->nr_frags;
@@ -751,12 +765,8 @@ mt76u_tx_queue_skb(struct mt76_dev *dev, struct mt76_queue *q,
struct sk_buff *skb, struct mt76_wcid *wcid,
struct ieee80211_sta *sta)
{
- struct usb_interface *intf = to_usb_interface(dev->dev);
- struct usb_device *udev = interface_to_usbdev(intf);
- u8 *data = NULL, ep = q2ep(q->hw_idx);
struct mt76u_buf *buf;
u16 idx = q->tail;
- unsigned int pipe;
int err;
if (q->queued == q->ndesc)
@@ -768,19 +778,16 @@ mt76u_tx_queue_skb(struct mt76_dev *dev, struct mt76_queue *q,
return err;
buf = &q->entry[idx].ubuf;
+ buf->buf = skb->data;
+ buf->len = skb->len;
buf->done = false;
- if (dev->usb.sg_en) {
- err = mt76u_tx_build_sg(skb, buf->urb);
- if (err < 0)
- return err;
- } else {
- data = skb->data;
- }
+ err = mt76u_tx_build_sg(dev, skb, buf->urb);
+ if (err < 0)
+ return err;
- pipe = usb_sndbulkpipe(udev, dev->usb.out_ep[ep]);
- usb_fill_bulk_urb(buf->urb, udev, pipe, data, skb->len,
- mt76u_complete_tx, buf);
+ mt76u_fill_bulk_urb(dev, USB_DIR_OUT, q2ep(q->hw_idx),
+ buf, mt76u_complete_tx, buf);
q->tail = (q->tail + 1) % q->ndesc;
q->entry[idx].skb = skb;
--
2.20.1
^ permalink raw reply related
* [PATCH 0/3] simplify usb layer buffer allocation
From: lorenzo @ 2019-02-20 22:35 UTC (permalink / raw)
To: nbd; +Cc: linux-wireless, sgruszka, lorenzo.bianconi, Lorenzo Bianconi
From: Lorenzo Bianconi <lorenzo@kernel.org>
Simplify usb rx buffer allocation.
Simplify mt76u_tx_build_sg routine.
This series is based on 'mt76usb: allow mt76u_bulk_msg be used for reads'
https://patchwork.kernel.org/patch/10822469/
Lorenzo Bianconi (3):
mt76: usb: introduce mt76u_fill_bulk_urb routine
mt76: usb: simplify rx buffer allocation
mt76: usb: simplify mt76u_tx_build_sg routine
drivers/net/wireless/mediatek/mt76/mt76.h | 2 -
drivers/net/wireless/mediatek/mt76/usb.c | 132 +++++++++-------------
2 files changed, 53 insertions(+), 81 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: bug report: iwlwifi: mvm: support mac80211 TXQs model
From: Johannes Berg @ 2019-02-20 21:12 UTC (permalink / raw)
To: Colin Ian King, Sara Sharon, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, linux-wireless@vger.kernel.org, netdev
Cc: Kalle Valo, David S. Miller, linux-kernel@vger.kernel.org
In-Reply-To: <427786ae-159a-a7d1-2334-46656d3f2b51@canonical.com>
On Wed, 2019-02-20 at 14:40 +0000, Colin Ian King wrote:
>
> ..when the used_hw_queues initialization was removed:
>
> @@ -360,8 +300,6 @@ int iwl_mvm_mac_ctxt_init(struct iwl_mvm *mvm,
> struct ieee80211_vif *vif)
> mvm->hw, IEEE80211_IFACE_ITER_RESUME_ALL,
> iwl_mvm_mac_iface_iterator, &data);
>
> - used_hw_queues = iwl_mvm_get_used_hw_queues(mvm, vif);
> -
> /*
> * In the case we're getting here during resume, it's similar to
> * firmware restart, and with RESUME_ALL the iterator will find
>
>
> I'm not 100% sure if the right thing to do is just to now initialize
> used_hw_queues to zero; it's not entirely clear what the initial value
> should be now.
My gut feeling says that we should just remove all of the code - we no
longer use the vif->hw_queue stuff. Which also explains why we didn't
notice any problems from this :)
Something like
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index aa308f7e7989..f90383943c62 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -263,8 +263,7 @@ int iwl_mvm_mac_ctxt_init(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
.found_vif = false,
};
u32 ac;
- int ret, i, queue_limit;
- unsigned long used_hw_queues;
+ int ret, i;
lockdep_assert_held(&mvm->mutex);
@@ -341,38 +340,9 @@ int iwl_mvm_mac_ctxt_init(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
INIT_LIST_HEAD(&mvmvif->time_event_data.list);
mvmvif->time_event_data.id = TE_MAX;
- /* No need to allocate data queues to P2P Device MAC and NAN.*/
if (vif->type == NL80211_IFTYPE_P2P_DEVICE ||
- vif->type == NL80211_IFTYPE_NAN) {
- for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
- vif->hw_queue[ac] = IEEE80211_INVAL_HW_QUEUE;
-
+ vif->type == NL80211_IFTYPE_NAN)
return 0;
- }
-
- /*
- * queues in mac80211 almost entirely independent of
- * the ones here - no real limit
- */
- queue_limit = IEEE80211_MAX_QUEUES;
-
- /*
- * Find available queues, and allocate them to the ACs. When in
- * DQA-mode they aren't really used, and this is done only so the
- * mac80211 ieee80211_check_queues() function won't fail
- */
- for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
- u8 queue = find_first_zero_bit(&used_hw_queues, queue_limit);
-
- if (queue >= queue_limit) {
- IWL_ERR(mvm, "Failed to allocate queue\n");
- ret = -EIO;
- goto exit_fail;
- }
-
- __set_bit(queue, &used_hw_queues);
- vif->hw_queue[ac] = queue;
- }
/* Allocate the CAB queue for softAP and GO interfaces */
if (vif->type == NL80211_IFTYPE_AP ||
I'll think about it a bit more and test it out, thanks for the report!
johannes
^ permalink raw reply related
* [bug report] mt76: usb: fix possible memory leak in mt76u_buf_free
From: Dan Carpenter @ 2019-02-20 20:57 UTC (permalink / raw)
To: lorenzo.bianconi; +Cc: linux-wireless, linux-mediatek
Hello Lorenzo Bianconi,
The patch cb83585e1121: "mt76: usb: fix possible memory leak in
mt76u_buf_free" from Feb 10, 2019, leads to the following static
checker warning:
drivers/net/wireless/mediatek/mt76/usb.c:372 mt76u_buf_free()
warn: address of 'urb->sg[i]' is non-NULL
drivers/net/wireless/mediatek/mt76/usb.c
362 }
363
364 void mt76u_buf_free(struct mt76u_buf *buf)
365 {
366 struct urb *urb = buf->urb;
367 struct scatterlist *sg;
368 int i;
369
370 for (i = 0; i < urb->num_sgs; i++) {
371 sg = &urb->sg[i];
--> 372 if (!sg)
^^^
This address isn't NULL. Was something else intended?
373 continue;
374
375 skb_free_frag(sg_virt(sg));
376 }
377 if (buf->buf)
378 skb_free_frag(buf->buf);
379
380 usb_free_urb(buf->urb);
381 }
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Grant Grundler @ 2019-02-20 19:15 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Johannes Berg, wgong, wgong, ath10k, linux-wireless
In-Reply-To: <871sa7ylmi.fsf@toke.dk>
On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Grant Grundler <grundler@google.com> writes:
>
> >> And, well, Grant's data is from a single test in a noisy
> >> environment where the time series graph shows that throughput is all over
> >> the place for the duration of the test; so it's hard to draw solid
> >> conclusions from (for instance, for the 5-stream test, the average
> >> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
> >> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
> >> used in this test, so I can't go verify it myself; so the only thing I
> >> can do is grumble about it here... :)
> >
> > It's a fair complaint and I agree with it. My counter argument is the
> > opposite is true too: most ideal benchmarks don't measure what most
> > users see. While the data wgong provided are way more noisy than I
> > like, my overall "confidence" in the "conclusion" I offered is still
> > positive.
>
> Right. I guess I would just prefer a slightly more comprehensive
> evaluation to base a 4x increase in buffer size on...
Kalle, is this why you didn't accept this patch? Other reasons?
Toke, what else would you like to see evaluated?
I generally want to see three things measured when "benchmarking"
technologies: throughput, latency, cpu utilization
We've covered those three I think "reasonably".
What does a "4x increase in memory" mean here? Wen, how much more
memory does this cause ath10k to use?
If a "4x increase in memory" means I'm using 1MB instead of 256KB, I'm
not going worry about that on a system with 2GB-16GB of RAM if it
doubles the throughput of the WIFI for a given workload. I expect
routers with 128-256MB RAM would make that tradeoff as well assuming
they don't have other RAM-demanding workload.
cheers,
grant
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2019-02-20
From: Kalle Valo @ 2019-02-20 19:08 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi, david.e.box, joe.konno
In-Reply-To: <8bf655adcf1e58a5e2fd25404a3ae3693cd9e154.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> This is the fifth and last batch of patches intended for v5.1. This
> includes the last two patchsets I sent. Usual development work. More
> details about the contents in the tag description.
>
> As agreed, I'm sending this before kbuildbot finished its tests, but we
> can fix any problems that may arise.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit 6c88e0ce5ebcbac8ac930c0149c217c6aa7ab0a3:
>
> Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2019-02-20 20:01:27 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2019-02-20
>
> for you to fetch changes up to 085486de833e383705bce61dbde8d31077f5b8ca:
>
> iwlwifi: add new cards for 22000 and killer series and change the market name (2019-02-20 20:48:01 +0200)
>
> ----------------------------------------------------------------
> Fifth batch of iwlwifi patches intended for v5.1
>
> * Some small fixes and continued work on the new debugging
> infrastructure;
> * Greg's debugfs clean-ups;
> * Some janitorial patches from the community;
> * Fix to one false-positive compiler warning;
> * VHT extended NSS support;
> * New PCI IDs for 9260 and 22000 series;
> * Other general bugfixes and cleanups;
>
> ----------------------------------------------------------------
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* pull-request: iwlwifi-next 2019-02-20
From: Luca Coelho @ 2019-02-20 18:56 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi, david.e.box, joe.konno
[-- Attachment #1: Type: text/plain, Size: 5470 bytes --]
Hi Kalle,
This is the fifth and last batch of patches intended for v5.1. This
includes the last two patchsets I sent. Usual development work. More
details about the contents in the tag description.
As agreed, I'm sending this before kbuildbot finished its tests, but we
can fix any problems that may arise.
Please let me know if there are any issues.
Cheers,
Luca.
The following changes since commit 6c88e0ce5ebcbac8ac930c0149c217c6aa7ab0a3:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2019-02-20 20:01:27 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2019-02-20
for you to fetch changes up to 085486de833e383705bce61dbde8d31077f5b8ca:
iwlwifi: add new cards for 22000 and killer series and change the market name (2019-02-20 20:48:01 +0200)
----------------------------------------------------------------
Fifth batch of iwlwifi patches intended for v5.1
* Some small fixes and continued work on the new debugging
infrastructure;
* Greg's debugfs clean-ups;
* Some janitorial patches from the community;
* Fix to one false-positive compiler warning;
* VHT extended NSS support;
* New PCI IDs for 9260 and 22000 series;
* Other general bugfixes and cleanups;
----------------------------------------------------------------
Andrei Otcheretianski (1):
iwlwifi: mvm: Set TX_CMD_FLG_PROT_REQUIRE correctly
Arnd Bergmann (1):
iwlwifi: fix false-positive maybe-uninitialized warning
Greg Kroah-Hartman (3):
iwlwifi: dvm: no need to check return value of debugfs_create functions
iwlwifi: fw: no need to check return value of debugfs_create functions
iwlwifi: iwl-drv: no need to check return value of debugfs_create functions
Gustavo A. R. Silva (2):
iwlwifi: eeprom-parse: use struct_size() in kzalloc()
iwlwifi: nvm-parse: use struct_size() in kzalloc()
Ihab Zhaika (2):
iwlwifi: add new card for 9260 series
iwlwifi: add new cards for 22000 and killer series and change the market name
Ilan Peer (2):
iwlwifi: mvm: Don't request HW restart if already requested
iwlwifi: mvm: Allow retries for probe responses
Johannes Berg (4):
iwlwifi: mvm: fix error path in iwl_mvm_mac_setup_register()
iwlwifi: nvm-parse: advertise IEEE80211_VHT_EXT_NSS_BW_CAPABLE in VHT
iwlwifi: mvm: remove IWL_MVM_INIT_STATUS_REG_HW_INIT_COMPLETE
iwlwifi: mvm: implement VHT extended NSS support in rs.c
Liad Kaufman (1):
iwlwifi: mvm: add read debugfs for he_sniffer_params
Sara Sharon (3):
iwlwifi: mvm: reject new beacons when in inject mode
iwlwifi: mvm: support non-transmitting AP
iwlwifi: mvm: add some debug data to TX path
Shahar S Matityahu (8):
iwlwifi: remove redundant condition from prior alive dump flow
iwlwifi: dbg_ini: fix infinite time ignore consecutive dumps
iwlwifi: dbg_ini: add print to iwl_dump_ini_mem in case of invalid range
iwlwifi: dbg_ini: make memory dump get_size handler include headers
iwlwifi: dbg_ini: make fill_range handler accept generic range pointer
iwlwifi: dbg_ini: add region to fill_header handler
iwlwifi: dbg_ini: implement Tx fifos dump
iwlwifi: dbg_ini: implement Rx fifos dump
Triebitz (1):
iwlwifi: pcie: allocate rb_stts's for all queues in one place
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 8 +-
drivers/net/wireless/intel/iwlwifi/dvm/agn.h | 9 +-
drivers/net/wireless/intel/iwlwifi/dvm/debugfs.c | 44 +--------
drivers/net/wireless/intel/iwlwifi/dvm/main.c | 5 +-
drivers/net/wireless/intel/iwlwifi/fw/api/dbg-tlv.h | 13 +--
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 508 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------
drivers/net/wireless/intel/iwlwifi/fw/debugfs.c | 11 +--
drivers/net/wireless/intel/iwlwifi/fw/debugfs.h | 9 +-
drivers/net/wireless/intel/iwlwifi/fw/error-dump.h | 32 +++++-
drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 22 -----
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c | 3 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 25 +++--
drivers/net/wireless/intel/iwlwifi/mvm/constants.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 32 +++++-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 8 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 8 ++
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 18 ++--
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 8 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 23 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 27 ++++--
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 99 +++++++++++--------
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 9 +-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 66 ++++++++++---
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 4 +-
27 files changed, 690 insertions(+), 308 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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