* Re: [PATCH wireless-drivers-next v2] mwifiex: use eth_broadcast_addr() to assign broadcast address
From: Kalle Valo @ 2019-07-24 11:56 UTC (permalink / raw)
To: Mao Wenan
Cc: amitkarwar, nishants, gbhat, huxinming820, linux-wireless,
kernel-janitors
In-Reply-To: <20190724062545.119041-1-maowenan@huawei.com>
Mao Wenan <maowenan@huawei.com> wrote:
> This patch is to use eth_broadcast_addr() to assign broadcast address
> insetad of memcpy().
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
15e830e90fde mwifiex: use eth_broadcast_addr() to assign broadcast address
--
https://patchwork.kernel.org/patch/11056129/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: remove assignment to itself
From: Kalle Valo @ 2019-07-24 11:55 UTC (permalink / raw)
To: pkshih; +Cc: dcb314, Larry.Finger, linux-wireless
In-Reply-To: <20190723031023.6777-1-pkshih@realtek.com>
<pkshih@realtek.com> wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> Module parameters of 'sw_crypto' and 'disable_watchdog' are false by
> default. If new value is desired, we can do it during inserting module,
> assignment existing in source code is not reasonable.
>
> Reported-by: David Binderman <dcb314@hotmail.com>
> CC: Larry Finger <Larry.Finger@lwfinger.net>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
b43d6c8e8d7f rtlwifi: remove assignment to itself
--
https://patchwork.kernel.org/patch/11053745/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: don't net_ratelimit() CONSOLE messages on firmware crash
From: Kalle Valo @ 2019-07-24 11:54 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Winnie Chang, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190721195217.26838-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Firmware crash is a pretty rare event and can't happen too frequently as
> it has to be followed by a hardware reinitialization and config reload.
> It should be safe to don't use net_ratelimit() when it happens.
>
> For reporting & debugging purposes it's important to provide a complete
> log as the last lines are actually the most important. This change
> modifies brcmfmac to print all messages in an unlimited way in that
> specific case. With this change there should be finally a backtrace of
> firmware finally visible after a crash.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
e3b1d879ccda brcmfmac: don't net_ratelimit() CONSOLE messages on firmware crash
--
https://patchwork.kernel.org/patch/11051195/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] libertas_tf: Use correct channel range in lbtf_geo_init
From: Kalle Valo @ 2019-07-24 11:53 UTC (permalink / raw)
To: YueHaibing
Cc: davem, lkundrak, derosier, linux-kernel, netdev, linux-wireless,
YueHaibing
In-Reply-To: <20190716144218.20608-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> It seems we should use 'range' instead of 'priv->range'
> in lbtf_geo_init(), because 'range' is the corret one
> related to current regioncode.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
2ec4ad49b98e libertas_tf: Use correct channel range in lbtf_geo_init
--
https://patchwork.kernel.org/patch/11046191/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rtw88: debug: dump tx power indexes in use
From: Kalle Valo @ 2019-07-24 11:53 UTC (permalink / raw)
To: yhchuang; +Cc: linux-wireless, briannorris
In-Reply-To: <1563254900-9219-1-git-send-email-yhchuang@realtek.com>
<yhchuang@realtek.com> wrote:
> From: Zong-Zhe Yang <kevin_yang@realtek.com>
>
> Add a read entry in debugfs to dump current tx power
> indexes in use for each path and each rate section.
> The corresponding power bases, power by rate, and
> power limit are also included.
>
> Also this patch fixes unused function warning.
>
> Fixes: b741422218ef ("rtw88: refine flow to get tx power index")
> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
8812022cb2fd rtw88: debug: dump tx power indexes in use
--
https://patchwork.kernel.org/patch/11045263/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: btcoex: fix issue possible condition with no effect (if == else)
From: Kalle Valo @ 2019-07-24 11:52 UTC (permalink / raw)
To: Hariprasad Kelam
Cc: Ping-Ke Shih, David S. Miller, YueHaibing, Hariprasad Kelam,
Larry Finger, Nathan Chancellor, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20190712191535.GA4215@hari-Inspiron-1545>
Hariprasad Kelam <hariprasad.kelam@gmail.com> wrote:
> fix below issue reported by coccicheck
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:514:1-3:
> WARNING: possible condition with no effect (if == else)
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
9a29f7d8476c rtlwifi: btcoex: fix issue possible condition with no effect (if == else)
--
https://patchwork.kernel.org/patch/11042665/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mt7601u: use params->ssn value directly
From: Kalle Valo @ 2019-07-24 11:52 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Jakub Kicinski
In-Reply-To: <20190712120949.GA21396@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> There is no point to use pointer to params->ssn.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Acked-by: Jakub Kicinski <kubakici@wp.pl>
Patch applied to wireless-drivers-next.git, thanks.
f0248ec49bde mt7601u: use params->ssn value directly
--
https://patchwork.kernel.org/patch/11042213/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/7] Revert "brcmfmac: fix NULL pointer derefence during USB disconnect"
From: Kalle Valo @ 2019-07-24 11:51 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1562835912-1404-2-git-send-email-arend.vanspriel@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> This reverts commit 5cdb0ef6144f47440850553579aa923c20a63f23. Subsequent
> changes make rework the driver code fixing the issue differently.
>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
7 patches applied to wireless-drivers-next.git, thanks.
a84a60ccdd65 Revert "brcmfmac: fix NULL pointer derefence during USB disconnect"
14fcfd1cc0c0 brcmfmac: change the order of things in brcmf_detach()
c613085b7494 brcmfmac: avoid firmware command in brcmf_netdev_open() when bus is down
c33330ac06fe brcmfmac: clear events in brcmf_fweh_detach() will always fail
1ac11ae949dd brcmfmac: avoid firmware commands when bus is down
e0bfb9601d48 brcmfmac: simply remove flowring if bus is down
4b11c915f00c brcmfmac: remove unnecessary strlcpy() upon obtaining "ver" iovar
--
https://patchwork.kernel.org/patch/11039459/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/3] brcmfmac: add 160MHz in chandef_to_chanspec()
From: Kalle Valo @ 2019-07-24 11:50 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1562834732-31508-2-git-send-email-arend.vanspriel@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> The function chandef_to_chanspec() was not handling 160MHz bandwidth
> resulting in wrong encoding of the channel. That resulting in firmware
> rejecting the provided channel specification.
>
> 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>
3 patches applied to wireless-drivers-next.git, thanks.
f491645f0394 brcmfmac: add 160MHz in chandef_to_chanspec()
011a56a3336a brcmfmac: enable DFS_OFFLOAD extended feature if supported
fa9050927fa8 brcmfmac: allow 160MHz in custom regulatory rules
--
https://patchwork.kernel.org/patch/11039449/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v4 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
From: Kalle Valo @ 2019-07-24 11:49 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Yan-Hsuan Chuang, David S . Miller, Larry Finger, David Laight,
Christoph Hellwig, linux-wireless, netdev, linux-kernel, linux,
Daniel Drake, Jian-Hong Pan, stable
In-Reply-To: <20190711052427.5582-1-jian-hong@endlessm.com>
Jian-Hong Pan <jian-hong@endlessm.com> wrote:
> Testing with RTL8822BE hardware, when available memory is low, we
> frequently see a kernel panic and system freeze.
>
> First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
>
> rx routine starvation
> WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822 rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
>
> Then we see a variety of different error conditions and kernel panics,
> such as this one (trimmed):
>
> rtw_pci 0000:02:00.0: pci bus timeout, check dma status
> skbuff: skb_over_panic: text:00000000091b6e66 len:415 put:415 head:00000000d2880c6f data:000000007a02b1ea tail:0x1df end:0xc0 dev:<NULL>
> ------------[ cut here ]------------
> kernel BUG at net/core/skbuff.c:105!
> invalid opcode: 0000 [#1] SMP NOPTI
> RIP: 0010:skb_panic+0x43/0x45
>
> When skb allocation fails and the "rx routine starvation" is hit, the
> function returns immediately without updating the RX ring. At this
> point, the RX ring may continue referencing an old skb which was already
> handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> bad things happen.
>
> This patch allocates a new, data-sized skb first in RX ISR. After
> copying the data in, we pass it to the upper layers. However, if skb
> allocation fails, we effectively drop the frame. In both cases, the
> original, full size ring skb is reused.
>
> In addition, to fixing the kernel crash, the RX routine should now
> generally behave better under low memory conditions.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Cc: <stable@vger.kernel.org>
2 patches applied to wireless-drivers-next.git, thanks.
ee6db78f5db9 rtw88: pci: Rearrange the memory usage for skb in RX ISR
29b68a920f6a rtw88: pci: Use DMA sync instead of remapping in RX ISR
--
https://patchwork.kernel.org/patch/11039275/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas: Add missing sentinel at end of if_usb.c fw_table
From: Kalle Valo @ 2019-07-24 11:49 UTC (permalink / raw)
To: Kevin Easton
Cc: linux-wireless, andreyknvl, davem, libertas-dev, linux-kernel,
syzbot, netdev, syzkaller-bugs
In-Reply-To: <20190710133138.GA31901@ip-172-31-14-16>
Kevin Easton <kevin@guarana.org> wrote:
> This sentinel tells the firmware loading process when to stop.
>
> Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com
> Signed-off-by: Kevin Easton <kevin@guarana.org>
Patch applied to wireless-drivers-next.git, thanks.
764f3f1ecffc libertas: Add missing sentinel at end of if_usb.c fw_table
--
https://patchwork.kernel.org/patch/11038493/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 09/12] rtw88: Fix misuse of GENMASK macro
From: Kalle Valo @ 2019-07-24 11:48 UTC (permalink / raw)
To: Joe Perches
Cc: Andrew Morton, Yan-Hsuan Chuang, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <0de52d891d7925b02f4f0fe2c750d076e55434d9.1562734889.git.joe@perches.com>
Joe Perches <joe@perches.com> wrote:
> Arguments are supposed to be ordered high then low.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
5ff29d836d1b rtw88: Fix misuse of GENMASK macro
--
https://patchwork.kernel.org/patch/11037805/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] libertas: Fix a double free in if_spi_c2h_data()
From: Kalle Valo @ 2019-07-24 11:46 UTC (permalink / raw)
To: Dan Williams
Cc: Philip Rakity, libertas-dev, kernel-janitors, linux-wireless,
Lubomir Rintel, Allison Randal, Dan Carpenter
In-Reply-To: <ee4472e4728becc9713962ba264742cb1f337098.camel@redhat.com>
Dan Williams <dcbw@redhat.com> wrote:
> The lbs_process_rxed_packet() frees the skb. It didn't originally, but
> we fixed it in commit f54930f36311 ("libertas: don't leak skb on receive
> error").
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
Failed to compile:
drivers/net/wireless/marvell/libertas/if_spi.c: In function 'if_spi_c2h_data':
drivers/net/wireless/marvell/libertas/if_spi.c:771:11: error: expected ';' before '}' token
goto out
^
;
}
~
make[5]: *** [drivers/net/wireless/marvell/libertas/if_spi.o] Error 1
make[4]: *** [drivers/net/wireless/marvell/libertas] 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
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/11033059/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wl3501_cs: remove redundant variable rc
From: Kalle Valo @ 2019-07-24 11:45 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190705103732.30568-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The variable rc is being initialized with a value that is never
> read and it is being updated later with a new value that is returned.
> The variable is redundant and can be replaced with a return 0 as
> there are no other return points in this function.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
c032461936de wl3501_cs: remove redundant variable rc
--
https://patchwork.kernel.org/patch/11032441/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas: remove redundant assignment to variable ret
From: Kalle Valo @ 2019-07-24 11:44 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, libertas-dev, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190705081734.15292-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The variable ret 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>
Patch applied to wireless-drivers-next.git, thanks.
4c8a46851019 libertas: remove redundant assignment to variable ret
--
https://patchwork.kernel.org/patch/11032181/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Kalle Valo @ 2019-07-24 11:44 UTC (permalink / raw)
To: Chris Chiu
Cc: jes.sorensen, davem, linux-wireless, netdev, linux-kernel, linux
In-Reply-To: <20190704105528.74028-1-chiu@endlessm.com>
Chris Chiu <chiu@endlessm.com> wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due to some incorrect
> register settings.
>
> Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> we realized that the 8723bu's enable_rf() does the same thing as
> rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> the cause of the wifi weak tx power. The vendor driver will set
> the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> mechanism, by the function halbtc8723b1ant_PsTdma.
>
> This commit hand over the antenna control to PTA(Packet Traffic
> Arbitration), which compares the weight of bluetooth/wifi traffic
> then determine whether to continue current wifi traffic or not.
> After PTA take control, The wifi signal will be back to normal and
> the bluetooth scan can also work at the same time. However, the
> btcoexist still needs to be handled under different circumstances.
> If there's a BT connection established, the wifi still fails to
> connect until BT disconnected.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
Patch applied to wireless-drivers-next.git, thanks.
18e714687bea rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
--
https://patchwork.kernel.org/patch/11031397/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rt2x00: no need to check return value of debugfs_create functions
From: Kalle Valo @ 2019-07-24 11:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stanislaw Gruszka, Helmut Schaa, David S. Miller, linux-wireless,
netdev
In-Reply-To: <20190703113956.GA26652@kroah.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Because we don't need to save the individual debugfs files and
> directories, remove the local storage of them and just remove the entire
> debugfs directory in a single call, making things a lot simpler.
>
> Cc: Stanislaw Gruszka <sgruszka@redhat.com>
> Cc: Helmut Schaa <helmut.schaa@googlemail.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
1dc244064c47 rt2x00: no need to check return value of debugfs_create functions
--
https://patchwork.kernel.org/patch/11029367/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 2/2] rt2x00usb: remove unnecessary rx flag checks
From: Kalle Valo @ 2019-07-24 11:42 UTC (permalink / raw)
To: Soeren Moch
Cc: Stanislaw Gruszka, Soeren Moch, Helmut Schaa, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20190701105314.9707-2-smoch@web.de>
Soeren Moch <smoch@web.de> wrote:
> In contrast to the TX path, there is no need to separately read the transfer
> status from the device after receiving RX data. Consequently, there is no
> real STATUS_PENDING RX processing queue entry state.
> Remove the unnecessary ENTRY_DATA_STATUS_PENDING flag checks from the RX path.
> Also remove the misleading comment about reading RX status from device.
>
> Suggested-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Signed-off-by: Soeren Moch <smoch@web.de>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
3b902fa811cf rt2x00usb: remove unnecessary rx flag checks
--
https://patchwork.kernel.org/patch/11025559/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rsi: return explicit error values
From: Kalle Valo @ 2019-07-24 11:42 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, amitkarwar, siva8118, linux-wireless, netdev
In-Reply-To: <1561645802-1279-1-git-send-email-info@metux.net>
"Enrico Weigelt, metux IT consult" <info@metux.net> wrote:
> From: Enrico Weigelt <info@metux.net>
>
> Explicitly return constants instead of variable (and rely on
> it to be explicitly initialized), if the value is supposed
> to be fixed anyways. Align it with the rest of the driver,
> which does it the same way.
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
Patch applied to wireless-drivers-next.git, thanks.
231e83fdcd03 rsi: return explicit error values
--
https://patchwork.kernel.org/patch/11019801/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] marvell wireless: cleanup -- make error values consistent
From: Kalle Valo @ 2019-07-24 11:39 UTC (permalink / raw)
To: Pavel Machek
Cc: amitkarwar, nishants, gbhat, huxinming820, davem, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190724095015.GA6592@amd>
Pavel Machek <pavel@ucw.cz> wrote:
> Surrounding code uses -ERRNO as a result, so don't pass plain -1.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
The title prefix should be "mwifiex:", I'll fix that.
--
https://patchwork.kernel.org/patch/11056525/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] drivers: net: wireless: rsi: return explicit error values
From: Kalle Valo @ 2019-07-24 11:36 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, amitkarwar, siva8118, linux-wireless, netdev
In-Reply-To: <1561645802-1279-1-git-send-email-info@metux.net>
"Enrico Weigelt, metux IT consult" <info@metux.net> wrote:
> From: Enrico Weigelt <info@metux.net>
>
> Explicitly return constants instead of variable (and rely on
> it to be explicitly initialized), if the value is supposed
> to be fixed anyways. Align it with the rest of the driver,
> which does it the same way.
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
I'll fix the title prefix to only have "rsi:", no need to have the full
directory path there.
--
https://patchwork.kernel.org/patch/11019801/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 2/2] mwifiex: Make use of the new sdio_trigger_replug() API to reset
From: Kalle Valo @ 2019-07-24 11:35 UTC (permalink / raw)
To: Douglas Anderson
Cc: Ulf Hansson, Adrian Hunter, Ganapathi Bhat, linux-wireless,
Andreas Fenkart, Brian Norris, Amitkumar Karwar, linux-rockchip,
Wolfram Sang, Nishant Sarmukadam, netdev, Avri Altman, linux-mmc,
davem, Xinming Hu, Douglas Anderson, linux-kernel
In-Reply-To: <20190722193939.125578-3-dianders@chromium.org>
Douglas Anderson <dianders@chromium.org> wrote:
> As described in the patch ("mmc: core: Add sdio_trigger_replug()
> API"), the current mwifiex_sdio_card_reset() is broken in the cases
> where we're running Bluetooth on a second SDIO func on the same card
> as WiFi. The problem goes away if we just use the
> sdio_trigger_replug() API call.
>
> NOTE: Even though with this new solution there is less of a reason to
> do our work from a workqueue (the unplug / plug mechanism we're using
> is possible for a human to perform at any time so the stack is
> supposed to handle it without it needing to be called from a special
> context), we still need a workqueue because the Marvell reset function
> could called from a context where sleeping is invalid and thus we
> can't claim the host. One example is Marvell's wakeup_timer_fn().
>
> Cc: Andreas Fenkart <afenkart@gmail.com>
> Cc: Brian Norris <briannorris@chromium.org>
> Fixes: b4336a282db8 ("mwifiex: sdio: reset adapter using mmc_hw_reset")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
I assume this is going via some other tree so I'm dropping this from my
queue. If I should apply this please resend once the dependency is in
wireless-drivers-next.
Patch set to Not Applicable.
--
https://patchwork.kernel.org/patch/11053351/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net-next 10/10] rtlwifi: rtl_pci: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 11:28 UTC (permalink / raw)
Cc: Ping-Ke Shih, Kalle Valo, David S . Miller, linux-wireless,
netdev, linux-kernel, Chuhong Yuan
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>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 4055e0ab75ba..7d96fe5f1a44 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -2409,8 +2409,7 @@ EXPORT_SYMBOL(rtl_pci_disconnect);
****************************************/
int rtl_pci_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct ieee80211_hw *hw = pci_get_drvdata(pdev);
+ struct ieee80211_hw *hw = dev_get_drvdata(dev);
struct rtl_priv *rtlpriv = rtl_priv(hw);
rtlpriv->cfg->ops->hw_suspend(hw);
@@ -2422,8 +2421,7 @@ EXPORT_SYMBOL(rtl_pci_suspend);
int rtl_pci_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct ieee80211_hw *hw = pci_get_drvdata(pdev);
+ struct ieee80211_hw *hw = dev_get_drvdata(dev);
struct rtl_priv *rtlpriv = rtl_priv(hw);
rtlpriv->cfg->ops->hw_resume(hw);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 09/10] qtnfmac_pcie: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
David S . Miller, linux-wireless, netdev, linux-kernel,
Chuhong Yuan
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>
---
drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
index e4e9344b6982..8ae318b5fe54 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
@@ -430,7 +430,7 @@ static int qtnf_pcie_suspend(struct device *dev)
struct qtnf_pcie_bus_priv *priv;
struct qtnf_bus *bus;
- bus = pci_get_drvdata(to_pci_dev(dev));
+ bus = dev_get_drvdata(dev);
if (!bus)
return -EFAULT;
@@ -443,7 +443,7 @@ static int qtnf_pcie_resume(struct device *dev)
struct qtnf_pcie_bus_priv *priv;
struct qtnf_bus *bus;
- bus = pci_get_drvdata(to_pci_dev(dev));
+ bus = dev_get_drvdata(dev);
if (!bus)
return -EFAULT;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 08/10] mwifiex: pcie: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Kalle Valo, David S . Miller, linux-wireless, netdev,
linux-kernel, Chuhong Yuan
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>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index b54f73e3d508..eff06d59e9df 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -150,10 +150,8 @@ static bool mwifiex_pcie_ok_to_access_hw(struct mwifiex_adapter *adapter)
static int mwifiex_pcie_suspend(struct device *dev)
{
struct mwifiex_adapter *adapter;
- struct pcie_service_card *card;
- struct pci_dev *pdev = to_pci_dev(dev);
+ struct pcie_service_card *card = dev_get_drvdata(dev);
- card = pci_get_drvdata(pdev);
/* Might still be loading firmware */
wait_for_completion(&card->fw_done);
@@ -195,10 +193,8 @@ static int mwifiex_pcie_suspend(struct device *dev)
static int mwifiex_pcie_resume(struct device *dev)
{
struct mwifiex_adapter *adapter;
- struct pcie_service_card *card;
- struct pci_dev *pdev = to_pci_dev(dev);
+ struct pcie_service_card *card = dev_get_drvdata(dev);
- card = pci_get_drvdata(pdev);
if (!card->adapter) {
dev_err(dev, "adapter structure is not valid\n");
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox