* 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
* [PATCH net-next 07/10] iwlwifi: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, 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/intel/iwlwifi/pcie/drv.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index ea2a03d4bf55..fe76e1540d39 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -1248,8 +1248,7 @@ int iwl_pci_fw_exit_d0i3(struct iwl_trans *trans)
#ifdef CONFIG_IWLWIFI_PCIE_RTPM
static int iwl_pci_runtime_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
+ struct iwl_trans *trans = dev_get_drvdata(device);
int ret;
IWL_DEBUG_RPM(trans, "entering runtime suspend\n");
@@ -1269,8 +1268,7 @@ static int iwl_pci_runtime_suspend(struct device *device)
static int iwl_pci_runtime_resume(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
+ struct iwl_trans *trans = dev_get_drvdata(device);
enum iwl_d3_status d3_status;
IWL_DEBUG_RPM(trans, "exiting runtime suspend (resume)\n");
@@ -1285,8 +1283,7 @@ static int iwl_pci_runtime_resume(struct device *device)
static int iwl_pci_system_prepare(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
+ struct iwl_trans *trans = dev_get_drvdata(device);
IWL_DEBUG_RPM(trans, "preparing for system suspend\n");
@@ -1308,8 +1305,7 @@ static int iwl_pci_system_prepare(struct device *device)
static void iwl_pci_system_complete(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
+ struct iwl_trans *trans = dev_get_drvdata(device);
IWL_DEBUG_RPM(trans, "completing system suspend\n");
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 06/10] iwlegacy: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Stanislaw Gruszka, 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/intel/iwlegacy/common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c
index 4a88e35d58d7..73f7bbf742bc 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -4942,8 +4942,7 @@ EXPORT_SYMBOL(il_add_beacon_time);
static int
il_pci_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct il_priv *il = pci_get_drvdata(pdev);
+ struct il_priv *il = dev_get_drvdata(device);
/*
* This function is called when system goes into suspend state
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 05/10] ath: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Jiri Slaby, Nick Kossifidis, Luis Chamberlain, Kalle Valo,
David S . Miller, QCA ath9k Development, Maya Erez,
linux-wireless, netdev, linux-kernel, wil6210, 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/ath/ath5k/pci.c | 3 +--
drivers/net/wireless/ath/ath9k/pci.c | 5 ++---
drivers/net/wireless/ath/wil6210/pcie_bus.c | 6 ++----
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/pci.c b/drivers/net/wireless/ath/ath5k/pci.c
index c6156cc38940..e1378e203611 100644
--- a/drivers/net/wireless/ath/ath5k/pci.c
+++ b/drivers/net/wireless/ath/ath5k/pci.c
@@ -301,8 +301,7 @@ ath5k_pci_remove(struct pci_dev *pdev)
#ifdef CONFIG_PM_SLEEP
static int ath5k_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 ath5k_hw *ah = hw->priv;
ath5k_led_off(ah);
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 92b2dd396436..f3461b193c7a 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -1021,13 +1021,12 @@ static void ath_pci_remove(struct pci_dev *pdev)
static int ath_pci_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct ieee80211_hw *hw = pci_get_drvdata(pdev);
+ struct ieee80211_hw *hw = dev_get_drvdata(device);
struct ath_softc *sc = hw->priv;
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
if (test_bit(ATH_OP_WOW_ENABLED, &common->op_flags)) {
- dev_info(&pdev->dev, "WOW is enabled, bypassing PCI suspend\n");
+ dev_info(device, "WOW is enabled, bypassing PCI suspend\n");
return 0;
}
diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index 9f5a914abc18..1b0625987d76 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -631,8 +631,7 @@ static int __maybe_unused wil6210_pm_resume(struct device *dev)
static int __maybe_unused wil6210_pm_runtime_idle(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct wil6210_priv *wil = pci_get_drvdata(pdev);
+ struct wil6210_priv *wil = dev_get_drvdata(dev);
wil_dbg_pm(wil, "Runtime idle\n");
@@ -646,8 +645,7 @@ static int __maybe_unused wil6210_pm_runtime_resume(struct device *dev)
static int __maybe_unused wil6210_pm_runtime_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct wil6210_priv *wil = pci_get_drvdata(pdev);
+ struct wil6210_priv *wil = dev_get_drvdata(dev);
if (test_bit(wil_status_suspended, wil->status)) {
wil_dbg_pm(wil, "trying to suspend while suspended\n");
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 00/10] Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:25 UTC (permalink / raw)
Cc: Mirko Lindner, Stephen Hemminger, Jiri Slaby, Nick Kossifidis,
Luis Chamberlain, Stanislaw Gruszka, Kalle Valo,
QCA ath9k Development, Maya Erez, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, Amitkumar Karwar,
Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu, Igor Mitsyanko,
Avinash Patil, Sergey Matyukevich, Ping-Ke Shih,
Intel Linux Wireless, David S . Miller,
Solarflare linux maintainers, Edward Cree, Martin Habets, netdev,
wil6210, linux-wireless, linux-kernel, Chuhong Yuan
These patches use dev_get_drvdata instead of
using to_pci_dev + pci_get_drvdata to make
code simpler.
Chuhong Yuan (10):
net: marvell: Use dev_get_drvdata where possible
forcedeth: Use dev_get_drvdata where possible
sfc: Use dev_get_drvdata where possible
sfc-falcon: Use dev_get_drvdata where possible
ath: Use dev_get_drvdata where possible
iwlegacy: Use dev_get_drvdata where possible
iwlwifi: Use dev_get_drvdata where possible
mwifiex: pcie: Use dev_get_drvdata
qtnfmac_pcie: Use dev_get_drvdata
rtlwifi: rtl_pci: Use dev_get_drvdata
drivers/net/ethernet/marvell/skge.c | 6 ++----
drivers/net/ethernet/marvell/sky2.c | 3 +--
drivers/net/ethernet/nvidia/forcedeth.c | 3 +--
drivers/net/ethernet/sfc/ef10.c | 4 ++--
drivers/net/ethernet/sfc/efx.c | 10 +++++-----
drivers/net/ethernet/sfc/falcon/efx.c | 6 +++---
drivers/net/ethernet/sfc/falcon/falcon_boards.c | 4 ++--
drivers/net/wireless/ath/ath5k/pci.c | 3 +--
drivers/net/wireless/ath/ath9k/pci.c | 5 ++---
drivers/net/wireless/ath/wil6210/pcie_bus.c | 6 ++----
drivers/net/wireless/intel/iwlegacy/common.c | 3 +--
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 12 ++++--------
drivers/net/wireless/marvell/mwifiex/pcie.c | 8 ++------
drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 4 ++--
drivers/net/wireless/realtek/rtlwifi/pci.c | 6 ++----
15 files changed, 32 insertions(+), 51 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [RFC PATCH] rtw88: use txpwr_lmt_cfg_pair struct, not arrays
From: Kalle Valo @ 2019-07-24 11:23 UTC (permalink / raw)
To: Brian Norris; +Cc: linux-wireless, Yan-Hsuan Chuang, Brian Norris
In-Reply-To: <20190713013232.215138-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> We're just trusting that these tables are of the right dimensions, when
> we could do better by just using the struct directly. Let's expose the
> struct txpwr_lmt_cfg_pair instead.
>
> The table changes were made by using some Vim macros, so that should
> help prevent any translation mistakes along the way.
>
> Remaining work: get the 'void *data' out of the generic struct
> rtw_table; all of these tables really deserve to be their own data
> structure, with proper type fields.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
To me this looks like a clear improvement and I'm inclined to apply it. Tony,
what do you think?
--
https://patchwork.kernel.org/patch/11042813/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
From: Kalle Valo @ 2019-07-24 11:14 UTC (permalink / raw)
To: Eugeniu Rosca
Cc: Geert Uytterhoeven, Simon Horman, David S. Miller,
Greg Kroah-Hartman, Randy Dunlap, Tony Lindgren, Ulf Hansson,
John Stultz, linux-wireless, netdev, linux-kernel,
Spyridon Papageorgiou, Joshua Frkuska, George G . Davis,
Andrey Gusakov, Linux-Renesas, Eugeniu Rosca, Eugeniu Rosca
In-Reply-To: <20190607172958.20745-1-erosca@de.adit-jv.com>
Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
> The wl1837mod datasheet [1] says about the WL_IRQ pin:
>
> ---8<---
> SDIO available, interrupt out. Active high. [..]
> Set to rising edge (active high) on powerup.
> ---8<---
>
> That's the reason of seeing the interrupt configured as:
> - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
>
> We assert that all those platforms have the WL_IRQ pin connected
> to the SoC _directly_ (confirmed on HiKey 970 [2]).
>
> That's not the case for R-Car Kingfisher extension target, which carries
> a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> IRQ_TYPE_LEVEL_LOW.
>
> Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> support platform dependent interrupt types") made a special case out
> of these interrupt types. After this commit, it is impossible to provide
> an IRQ configuration via DTS which would describe an inverter present
> between the WL18* chip and the SoC, generating the need for workarounds
> like [3].
>
> Create a boolean OF property, called "invert-irq" to specify that
> the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
>
> This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> the DTS configuration [4] combined with the "invert-irq" property.
>
> [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
> [4] https://patchwork.kernel.org/patch/10895879/
> ("arm64: dts: ulcb-kf: Add support for TI WL1837")
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Based on the discussion I'm dropping this. Please resend once there's a
conclusion.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10982491/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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