* Re: [PATCH v5 1/5] rt2x00: remove unneeded check
From: Kalle Valo @ 2019-02-19 15:19 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Tomislav Požega, Daniel Golle, Felix Fietkau,
Mathias Kresin
In-Reply-To: <1550052556-7158-2-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> From: Tomislav Požega <pozega.tomislav@gmail.com>
>
> Remove band check from rf53xx channel config routine since all chips
> using it are single band.
>
> Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
5 patches applied to wireless-drivers-next.git, thanks.
17ae2acd1a6f rt2x00: remove unneeded check
5991a2ecd070 rt2x00: remove confusing AGC register
9ad3b5565445 rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band
7aca14885ede rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7620
c7ff1bfeaf1c rt2800: comment and simplify AGC init for RT6352
--
https://patchwork.kernel.org/patch/10809543/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] carl9170: clean up a clamp() call
From: Kalle Valo @ 2019-02-19 15:18 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Christian Lamparter, linux-wireless, kernel-janitors
In-Reply-To: <20190218093154.GC7712@kadam>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> The parameter order for clamp is supposed to be clamp(value, low, high).
> When we write it in this order it's equivalent to
> min(head->plcp[3] & 0x7f, 75) which works in this context where the min
> is zero. But it's not a correct use of the API.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
dc76bb1e12e9 carl9170: clean up a clamp() call
--
https://patchwork.kernel.org/patch/10817541/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtl818x_pci: Remove set but not used variables 'io_addr, mem_addr'
From: Kalle Valo @ 2019-02-19 15:18 UTC (permalink / raw)
To: YueHaibing
Cc: John W. Linville, Colin Ian King, YueHaibing, linux-wireless,
netdev, kernel-janitors
In-Reply-To: <20190218075226.183964-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c: In function 'rtl8180_probe':
> drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c:1727:15: warning:
> variable 'io_addr' set but not used [-Wunused-but-set-variable]
>
> drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c:1726:16: warning:
> variable 'mem_addr' set but not used [-Wunused-but-set-variable]
>
> They're never used since introduction.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
b9b81d152cfb rtl818x_pci: Remove set but not used variables 'io_addr, mem_addr'
--
https://patchwork.kernel.org/patch/10817425/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] orinoco : Replace function name in string with __func__
From: Kalle Valo @ 2019-02-19 15:17 UTC (permalink / raw)
To: Keyur Patel
In-Reply-To: <20190217162548.18257-1-iamkeyur96@gmail.com>
Keyur Patel <iamkeyur96@gmail.com> wrote:
> From: Keyur Patel <iamkeyur96@gmail.com>
>
> Replace hard coded function name with __func__, to
> improve robustness and to conform to the Linux kernel coding
> style. Issue found using checkpatch.
>
> Signed-off-by: Keyur Patel <iamkeyur96@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
25f87d8b63b8 orinoco : Replace function name in string with __func__
--
https://patchwork.kernel.org/patch/10817203/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: don't advertise IBSS features without FW support
From: Kalle Valo @ 2019-02-19 15:16 UTC (permalink / raw)
To: Brian Norris
Cc: Ganapathi Bhat, Nishant Sarmukadam, Amitkumar Karwar, Xinming Hu,
linux-kernel, linux-wireless, Karthik D A, Brian Norris
In-Reply-To: <20190215003129.98298-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> As it is, doing something like
>
> # iw phy phy0 interface add foobar type ibss
>
> on a firmware that doesn't have ad-hoc support just yields failures of
> HostCmd_CMD_SET_BSS_MODE, which happened to return a '-1' error code
> (-EPERM? not really right...) and sometimes may even crash the firmware
> along the way.
>
> Let's parse the firmware capability flag while registering the wiphy, so
> we don't allow attempting IBSS at all, and we get a proper -EOPNOTSUPP
> from nl80211 instead.
>
> Fixes: e267e71e68ae ("mwifiex: Disable adhoc feature based on firmware capability")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
6f21ab30469d mwifiex: don't advertise IBSS features without FW support
--
https://patchwork.kernel.org/patch/10814041/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net] mwifiex: Fix NL80211_TX_POWER_LIMITED
From: Kalle Valo @ 2019-02-19 15:15 UTC (permalink / raw)
To: Adrian Bunk
Cc: netdev, Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat,
Xinming Hu, linux-wireless
In-Reply-To: <20190213135938.13664-1-bunk@kernel.org>
Adrian Bunk <bunk@kernel.org> wrote:
> NL80211_TX_POWER_LIMITED was treated as NL80211_TX_POWER_AUTOMATIC,
> which is the opposite of what should happen and can cause nasty
> regulatory problems.
>
> if/else converted to a switch without default to make gcc warn
> on unhandled enum values.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
65a576e27309 mwifiex: Fix NL80211_TX_POWER_LIMITED
--
https://patchwork.kernel.org/patch/10810011/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas_tf: remove set but not used variable 'flags'
From: Kalle Valo @ 2019-02-19 15:14 UTC (permalink / raw)
To: YueHaibing
Cc: Colin Ian King, YueHaibing, linux-wireless, kernel-janitors,
netdev
In-Reply-To: <20190213014917.164506-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/marvell/libertas_tf/main.c: In function 'lbtf_rx':
> drivers/net/wireless/marvell/libertas_tf/main.c:554:15: warning:
> variable 'flags' set but not used [-Wunused-but-set-variable]
>
> It never used and can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Steve deRosier <derosier@cal-sierra.com>
Patch applied to wireless-drivers-next.git, thanks.
e97cb6ea71b0 libertas_tf: remove set but not used variable 'flags'
--
https://patchwork.kernel.org/patch/10808997/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/3] libertas_tf: move hardware callbacks to a separate structure
From: Kalle Valo @ 2019-02-19 15:13 UTC (permalink / raw)
To: Lubomir Rintel
Cc: David S. Miller, linux-wireless, linux-kernel, Lubomir Rintel
In-Reply-To: <20190210195217.18817-2-lkundrak@v3.sk>
Lubomir Rintel <lkundrak@v3.sk> wrote:
> We'll need to talk to the firmware to get a hardware address before
> device is registered with ieee80211 subsystem at the end of
> lbtf_add_card(). Hooking the callbacks after that is too late.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Failed to compile:
drivers/net/wireless/marvell/libertas_tf/main.c: In function 'lbtf_add_card':
drivers/net/wireless/marvell/libertas_tf/main.c:603:309: error: 'udev' undeclared (first use in this function); did you mean 'cdev'?
lbtf_deb_usbd(&udev->dev, "Error programming the firmware\n");
^
cdev
drivers/net/wireless/marvell/libertas_tf/main.c:603:309: note: each undeclared identifier is reported only once for each function it appears in
make[5]: *** [drivers/net/wireless/marvell/libertas_tf/main.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[4]: *** [drivers/net/wireless/marvell/libertas_tf] Error 2
make[3]: *** [drivers/net/wireless/marvell] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
3 patches set to Changes Requested.
10804885 [1/3] libertas_tf: move hardware callbacks to a separate structure
10804881 [2/3] libertas_tf: don't defer firmware loading until start()
10804883 [3/3] libertas_tf: get the MAC address before registering the device
--
https://patchwork.kernel.org/patch/10804885/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas_tf: fix signal reporting
From: Kalle Valo @ 2019-02-19 15:12 UTC (permalink / raw)
To: Lubomir Rintel
Cc: David S. Miller, linux-wireless, linux-kernel, Lubomir Rintel
In-Reply-To: <20190210194822.18539-1-lkundrak@v3.sk>
Lubomir Rintel <lkundrak@v3.sk> wrote:
> Instead of exposing the signal-to-noise ration, calculate the actual signal
> level taking the noise floor into account.
>
> Also, flip the SIGNAL_DBM bit on, so that mac80211 exposes the signal
> level along with the station info in scan results. This fills
> NetworkManager's "nmcli d wifi output" output with colors, bars and joy.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Patch applied to wireless-drivers-next.git, thanks.
b723dbb313f0 libertas_tf: fix signal reporting
--
https://patchwork.kernel.org/patch/10804879/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas_tf: move the banner to a more appropriate place
From: Kalle Valo @ 2019-02-19 15:11 UTC (permalink / raw)
To: Lubomir Rintel
Cc: David S. Miller, linux-wireless, linux-kernel, Lubomir Rintel
In-Reply-To: <20190210194811.18345-1-lkundrak@v3.sk>
Lubomir Rintel <lkundrak@v3.sk> wrote:
> Also, turn it to a dev_info() to make checkpatch.pl happy.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Patch applied to wireless-drivers-next.git, thanks.
c7a5682ded7e libertas_tf: move the banner to a more appropriate place
--
https://patchwork.kernel.org/patch/10804877/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas_tf: don't set URB_ZERO_PACKET on IN USB transfer
From: Kalle Valo @ 2019-02-19 15:10 UTC (permalink / raw)
To: Lubomir Rintel
Cc: David S. Miller, linux-wireless, linux-kernel, Lubomir Rintel,
stable
In-Reply-To: <20190210194749.18135-1-lkundrak@v3.sk>
Lubomir Rintel <lkundrak@v3.sk> wrote:
> It doesn't make sense and the USB core warns on each submit of such
> URB, easily flooding the message buffer with tracebacks.
>
> Analogous issue was fixed in regular libertas driver in commit 6528d8804780
> ("libertas: don't set URB_ZERO_PACKET on IN USB transfer").
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Patch applied to wireless-drivers-next.git, thanks.
607076a904c4 libertas_tf: don't set URB_ZERO_PACKET on IN USB transfer
--
https://patchwork.kernel.org/patch/10804875/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas_tf: lower the debug level of command trace
From: Kalle Valo @ 2019-02-19 15:10 UTC (permalink / raw)
To: Lubomir Rintel
Cc: David S. Miller, linux-wireless, linux-kernel, Lubomir Rintel
In-Reply-To: <20190210194735.17939-1-lkundrak@v3.sk>
Lubomir Rintel <lkundrak@v3.sk> wrote:
> Logging each and every command response is way too much for INFO level.
> Silence this, unless CONFIG_LIBERTAS_THINFIRM_DEBUG has been enabled.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Patch applied to wireless-drivers-next.git, thanks.
744972b2c4d2 libertas_tf: lower the debug level of command trace
--
https://patchwork.kernel.org/patch/10804873/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rsi: remove set but not used variables 'info, vif'
From: Kalle Valo @ 2019-02-19 15:09 UTC (permalink / raw)
To: YueHaibing
Cc: Amitkumar Karwar, Siva Rebbagondla, YueHaibing, linux-wireless,
netdev, kernel-janitors
In-Reply-To: <20190218075156.183879-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/rsi/rsi_91x_main.c: In function 'rsi_prepare_skb':
> drivers/net/wireless/rsi/rsi_91x_main.c:127:24: warning:
> variable 'vif' set but not used [-Wunused-but-set-variable]
>
> drivers/net/wireless/rsi/rsi_91x_main.c:124:28: warning:
> variable 'info' set but not used [-Wunused-but-set-variable]
>
> They're not used any more since 160ee2a11ce0 ("rsi: fill rx_params only once.")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
6f6e4f98ee52 rsi: remove set but not used variables 'info, vif'
--
https://patchwork.kernel.org/patch/10817423/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rsi: fix spelling mistakes
From: Kalle Valo @ 2019-02-19 15:09 UTC (permalink / raw)
To: Siva Rebbagondla
Cc: linux-wireless, amitkarwar, siva.rebbagondla, rishikesh.basu
In-Reply-To: <1549970914-3880-1-git-send-email-siva8118@gmail.com>
Siva Rebbagondla <siva8118@gmail.com> wrote:
> From: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com>
>
> Trivial fixes to spelling mistakes in various files in rsi folder.
>
> Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com>
Patch applied to wireless-drivers-next.git, thanks.
b9c767fdde61 rsi: fix spelling mistakes
--
https://patchwork.kernel.org/patch/10807785/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rsi: fix a typo in a debug message
From: Kalle Valo @ 2019-02-19 15:08 UTC (permalink / raw)
To: Dan Carpenter
Cc: Amitkumar Karwar, Prameela Rani Garnepudi, Siva Rebbagondla,
linux-wireless, kernel-janitors
In-Reply-To: <20190209090009.GA4865@kadam>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> There is a \b (backspace) character in the message that wasn't intended.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Patch applied to wireless-drivers-next.git, thanks.
e8242ad03883 rsi: fix a typo in a debug message
--
https://patchwork.kernel.org/patch/10804409/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: remove set but not used variable 'old_state'
From: Kalle Valo @ 2019-02-19 15:08 UTC (permalink / raw)
To: YueHaibing
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, YueHaibing, linux-wireless, netdev,
brcm80211-dev-list.pdl, brcm80211-dev-list, kernel-janitors
In-Reply-To: <20190218080846.187942-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_state_change':
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:578:6: warning:
> variable 'old_state' set but not used [-Wunused-but-set-variable]
>
> It's never used and can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
e4d1b2716b88 brcmfmac: remove set but not used variable 'old_state'
--
https://patchwork.kernel.org/patch/10817429/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: rework bphy_err() to take struct brcmf_pub argument
From: Kalle Valo @ 2019-02-19 15:07 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190215144554.6860-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This macro will be used in more places not just the cfg80211.c. It makes
> sense to pass some common struct to it as "struct wiphy" is mostly
> referenced in cfg80211 code only.
>
> A very common one (used above the bus abstraction layer) is struct
> brcmf_pub. Many functions already keep reference to it which will make
> using bphy_err() simpler. It should also allow extending that macro's
> logic if it's ever needed.
>
> This improves code recently added in the commit 3ef005b82e2a ("brcmfmac:
> add bphy_err() and use it in the cfg80211.c").
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Patch applied to wireless-drivers-next.git, thanks.
16e646768396 brcmfmac: rework bphy_err() to take struct brcmf_pub argument
--
https://patchwork.kernel.org/patch/10815043/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/2] brcmfmac: improve code handling bandwidth of firmware reported channels
From: Kalle Valo @ 2019-02-19 15:06 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190211220454.19850-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> 1) Use switch to simplify/improve the code & avoid some duplication
> 2) Add warning for unsupported values
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2 patches applied to wireless-drivers-next.git, thanks.
f4e183293b87 brcmfmac: improve code handling bandwidth of firmware reported channels
30519cbe339a brcmfmac: support firmware reporting 160 MHz channels
--
https://patchwork.kernel.org/patch/10806865/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: print firmware reported ring status errors
From: Kalle Valo @ 2019-02-19 15:06 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190208142439.21479-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Firmware is capable of reporting ring status. It's used e.g. to signal
> some problem with a specific ring setup. This patch adds support for
> printing ring & error number which may be useful for debugging setup
> issues.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Patch applied to wireless-drivers-next.git, thanks.
c988b78244df brcmfmac: print firmware reported ring status errors
--
https://patchwork.kernel.org/patch/10803203/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/6] brcmfmac: assure SSID length from firmware is limited
From: Kalle Valo @ 2019-02-19 15:05 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1550148232-4309-2-git-send-email-arend.vanspriel@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> The SSID length as received from firmware should not exceed
> IEEE80211_MAX_SSID_LEN as that would result in heap overflow.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
6 patches applied to wireless-drivers-next.git, thanks.
1b5e2423164b brcmfmac: assure SSID length from firmware is limited
a4176ec356c7 brcmfmac: add subtype check for event handling in data path
aaf6a5e86e36 brcmfmac: create debugfs files for bus-specific layer
92d3b88b1029 brcmfmac: disable MBSS feature for bcm4330 device
4ab2cf03da91 brcmfmac: check and dump trap info during sdio probe
a250c91c1762 brcmfmac: use chipname in brcmf_fw_alloc_request() for error path as well
--
https://patchwork.kernel.org/patch/10812617/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/8] rtlwifi: Remove CamelCase variables from base code
From: Kalle Valo @ 2019-02-19 15:04 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190214223644.8035-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> There are a number of CamelCase variables remaining in the source
> files of modules rtl_pci, rtl_usb, and rtlwifi.
>
> The following checkpatch excettions are also fixed:
>
> for_kalle1/0001-rtlwifi-Remove-CamelCase-variables-from-base-code.patch
> -----------------------------------------------------------------------
> CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] !=
> rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]'
> #68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377:
> + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] !=
> + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) ||
> + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
> + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i +
> 1])) {
>
> CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
> rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i +
> 1]'
> #68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377:
> + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] !=
> + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) ||
> + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
> + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i +
> 1])) {
>
> WARNING: line over 80 characters
> #70: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:379:
> + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
>
> CHECK: No space is necessary after a cast
> #186: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:396:
> + status->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc);
>
> CHECK: No space is necessary after a cast
> #208: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c:335:
> + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc);
>
> CHECK: No space is necessary after a cast
> #243: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:301:
> + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc);
>
> CHECK: No space is necessary after a cast
> #252: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:368:
> + stats.rx_is40mhzpacket = (bool) GET_RX_DESC_BW(rxdesc);
>
> CHECK: No space is necessary after a cast
> #265: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c:475:
> + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc);
>
> WARNING: Unnecessary space before function pointer arguments
> #455: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:1462:
> + void (*writen_sync) (struct rtl_priv *rtlpriv, u32 addr, void *buf,
>
> WARNING: Unnecessary space before function pointer arguments
> #483: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:2257:
> + void (*fill_fake_txdesc) (struct ieee80211_hw *hw, u8 *pdesc,
>
> Note that not all checkpatch exceptions are addressed. Those will be
> handled in later patches.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
8 patches applied to wireless-drivers-next.git, thanks.
e703c5dd2d69 rtlwifi: Remove CamelCase variables from base code
2171def56daf rtlwifi: btcoexist: Remove CamelCase variable
d420110635ad rtlwifi: rtl8188ee: Remove CamelCase variable
ff9704538e6d rtlwifi: rtl8192{c,u}: Remove CamelCase variables
b83faeda028b rtlwifi: rtl8188de: Remove CamelCase variables
2a83ad1fe330 rtlwifi: rtl8192se: Remove CamelCase variables
92a1aa25c782 rtlwifi: rtl8723{be,ae}: Remove CamelCase variables
9c66a7e5d39c rtlwifi: rtl8821ae: Remove CamelCase variables
--
https://patchwork.kernel.org/patch/10813947/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 01/13] rtlwifi: Replace old-style license information
From: Kalle Valo @ 2019-02-19 15:01 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190214195920.1504-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> The traditional license information is replaced by the SPDX form. There
> are no code changes.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
13 patches applied to wireless-drivers-next.git, thanks.
d27a76fa5a66 rtlwifi: Replace old-style license information
8c0863125229 rtlwifi: btcoex: Replace old-style license information
fbb352862190 rtlwifi: rtl8188ee: Replace old-style license information
e70113691804 rtlwifi: rtl8192com: Replace old-style license information
0770f718458e rtlwifi: rtl8192ce: Replace old-style license information
b44febedbb8d rtlwifi: rtl8192cu: Replace old-style license information
5bd4f692e0eb rtlwifi: rtl8192de: Replace old-style license information
647f21b10292 rtlwifi: rtl8192ee: Replace old-style license information
6f3fcdc88e53 rtlwifi: rtl8192se: Replace old-style license information
48fa0b4d58dc rtlwifi: rtl8723ae: Replace old-style license information
93121c03e0ce rtlwifi: rtl8723be: Replace old-style license information
2a7274ee12cc rtlwifi: rtl8723_common: Replace old-style license information
03f3dd37f095 rtlwifi: rtl8821ae: Replace old-style license information
--
https://patchwork.kernel.org/patch/10813683/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: pull request: mt76 2019-02-18
From: Kalle Valo @ 2019-02-19 14:48 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <13bb375f-9800-3b09-d7c2-c97b263691b5@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> here's another pull request for 5.1
>
> - Felix
>
> The following changes since commit f77ecde5f206195cdce16dd2ac92d7ca0305ba2b:
>
> Merge tag 'iwlwifi-next-for-kalle-2019-02-14' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next (2019-02-18 20:10:46 +0200)
>
> are available in the Git repository at:
>
> https://github.com/nbd168/wireless tags/mt76-for-kvalo-2019-02-18
>
> for you to fetch changes up to 9f688473408b6334c5da5ec085f9ea1954675fe7:
>
> mt76: mt76x2: simplify per-chain signal strength handling (2019-02-18 20:41:50 +0100)
>
> ----------------------------------------------------------------
> mt76 patches for 5.1
>
> * beacon support for USB devices (mesh+ad-hoc only)
> * mt76x0 tx power fixes
> * fixes for encryption, calibration and ED/CCA
> * more code unification
> * USB fixes
> * fix for using the correct hweight8 function
>
> ----------------------------------------------------------------
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] ath10k: Enable support for beacon interval per VAP
From: Dundi Raviteja @ 2019-02-19 12:24 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Dundi Raviteja
Enable support to configure different beacon interval per VAP.
To support this feature, map different beacon interval service bit
to wmi tlv service.
Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
Signed-off-by: Dundi Raviteja <dundi@codeaurora.org>
---
This change is dependent on the below patchset
ath10k: Add support for ack rssi value of management tx packets (https://patchwork.kernel.org/patch/10809631/)
---
drivers/net/wireless/ath/ath10k/mac.c | 33 +++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 3 +++
2 files changed, 36 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e49b367..09c4705 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -8232,6 +8232,30 @@ void ath10k_mac_destroy(struct ath10k *ar)
},
};
+static struct
+ieee80211_iface_combination ath10k_tlv_qcs_bcn_int_if_comb[] = {
+ {
+ .limits = ath10k_tlv_if_limit,
+ .num_different_channels = 1,
+ .max_interfaces = 4,
+ .beacon_int_infra_match = true,
+ .beacon_int_min_gcd = 1,
+ .n_limits = ARRAY_SIZE(ath10k_tlv_if_limit),
+ },
+ {
+ .limits = ath10k_tlv_qcs_if_limit,
+ .num_different_channels = 2,
+ .max_interfaces = 4,
+ .n_limits = ARRAY_SIZE(ath10k_tlv_qcs_if_limit),
+ },
+ {
+ .limits = ath10k_tlv_if_limit_ibss,
+ .num_different_channels = 1,
+ .max_interfaces = 2,
+ .n_limits = ARRAY_SIZE(ath10k_tlv_if_limit_ibss),
+ },
+};
+
static const struct ieee80211_iface_limit ath10k_10_4_if_limits[] = {
{
.max = 1,
@@ -8642,6 +8666,15 @@ int ath10k_mac_register(struct ath10k *ar)
ath10k_tlv_qcs_if_comb;
ar->hw->wiphy->n_iface_combinations =
ARRAY_SIZE(ath10k_tlv_qcs_if_comb);
+
+ if (test_bit
+ (WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT,
+ ar->wmi.svc_map)) {
+ ar->hw->wiphy->iface_combinations =
+ ath10k_tlv_qcs_bcn_int_if_comb;
+ ar->hw->wiphy->n_iface_combinations =
+ ARRAY_SIZE(ath10k_tlv_qcs_bcn_int_if_comb);
+ }
} else {
ar->hw->wiphy->iface_combinations = ath10k_tlv_if_comb;
ar->hw->wiphy->n_iface_combinations =
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index e07e990..9f78502 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -1567,6 +1567,9 @@ enum wmi_tlv_service {
SVCMAP(WMI_TLV_SERVICE_THERM_THROT,
WMI_SERVICE_THERM_THROT,
WMI_TLV_MAX_SERVICE);
+ SVCMAP(WMI_TLV_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT,
+ WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT,
+ WMI_TLV_MAX_SERVICE);
}
#undef SVCMAP
--
1.9.1
^ permalink raw reply related
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Felix Fietkau @ 2019-02-19 12:19 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Stefan Wahren, Lorenzo Bianconi, Alan Stern, Doug Anderson,
Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <20190219104208.GA22999@redhat.com>
On 2019-02-19 11:42, Stanislaw Gruszka wrote:
> On Mon, Feb 18, 2019 at 07:52:27PM +0100, Felix Fietkau wrote:
>> On 2019-02-18 16:03, Stanislaw Gruszka wrote:
>> > On Mon, Feb 18, 2019 at 03:43:26PM +0100, Felix Fietkau wrote:
>> >> On 2019-02-18 14:52, Stanislaw Gruszka wrote:
>> >> > On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
>> >> >> this is a misunderstanding. The warning is about memory alignment to 32 bit addresses, not about page alignment. This is a typical ARM restriction. Maybe we need to make sure in mt76 that the DMA buffer needs to be aligned. But it's also possible that the warning isn't the root cause of our problem.
>> >> >>
>> >> >
>> >> > I see, it needs 4 bytes alignment . There is already dwc2 code checks
>> >> > that and allocate new buffer if the alignment is not right:
>> >> > dwc2_alloc_dma_aligned_buffer(), but it does nothing if urb->sg
>> >> > is not NULL. I thought mt76usb already provide aligned buffers, but
>> >> > looks it does not for one TX special case, which are PROBE REQUEST
>> >> > frames. Other frames are aligned by inserting L2 header pad. One
>> >> > solution for this would be just submit urb with NULL sg (same as
>> >> > Lorenzo's patches do, but still allocating buffers via buf->sg),
>> >> > but I think, you have right, we should provide 4 bytes aligned buffers
>> >> > by default as other DMA hardware may require that. I'm attaching yet
>> >> > another patch to test, which fix up alignment for PROBE REQUEST frames.
>> >> This approach looks completely wrong to me. MMIO based hardware does not
>> >> need 4-byte aligned buffers at all, other USB controllers do not need
>> >> this either.
>> >> As Lorenzo already pointed out, re-aligning the buffer is *very*
>> >> expensive, so we should not do this in the driver just to work around
>> >> quirks in a particular USB host driver.
>> >
>> > I decided to this patch because I thought some other USB & MMIO DMA
>> > platforms might also require this alignment. But it was never triggered
>> > in MMIO because on those mt76 is used in AP mode, hence no PROBE
>> > REQUEST frames (and scan can be passive on STA mode).
>> mt76 is regularly used and tested in STA and Mesh mode as well.
>> No DMA alignment related issues there.
>
> The question is why we need to do 2 bytes header pad ? Is this because
> ieee802.11 header length for mt76 hardware has to be multiple of 4 or
> it has to be aligned to 4 bytes? It would be strange if length has
> to be fixed to 4 bytes and alignment not. However this could be
> needed on some platforms and not on others.
Not sure why it was added in the hardware, but the MAC assumes that the
header is padded to a multiple of 4 bytes in the buffer after it has
been copied to device memory via DMA or USB.
Because of that, it has nothing to do with the alignment of the source
buffer, so the two should not be mixed up.
>> >> The way I see it, we have two choices.
>> >> 1. Fix dwc2 to do its alignment quirk for the urb->sg != NULL case
>> >> 2. Rely on urb->transfer_buffer and keep urb->sg NULL
>> >
>> > I agree, if this is only needed for dwc2. Though I would investigate
>> > if this is not a bug on other platforms as well.
>> >From what I can see, using Lorenzo's patches seems to be the better
>> solution, since they avoid these corner cases in dwc2 (and maybe other
>> drivers as well). I will apply them and then we'll see if we need to do
>> any further improvements later on.
>
> They work on rpi dwc2, but they do not address root of the problem.
> There is clearly something wrong how mt76usb handle SG, what is not
> fixed. And adding disable_usb_sg module parameter for hcd's supporting
> SG should be red flag.
I think we're simply dealing with multiple issues here, only some of
which are fixed by Lorenzo's patches.
I'm pretty sure it's still wrong for mt76 to try to align its buffers,
since the Linux USB API supports non-aligned transfer buffers and it
should be up to the controller driver to deal with that.
dwc2 tries to do that, but that has limitations which I already pointed
out and which are properly dealt with by Lorenzo's patches.
Any other issues with sg should be investigated separately, they are
probably unrelated to this one.
- 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