* [PATCH v3 2/2] rtw88: pci: Use DMA sync instead of remapping in RX ISR
From: Jian-Hong Pan @ 2019-07-10 8:38 UTC (permalink / raw)
To: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, Larry Finger,
David Laight, Christoph Hellwig
Cc: linux-wireless, netdev, linux-kernel, linux, Daniel Drake,
Jian-Hong Pan, stable
In-Reply-To: <20190709161550.GA8703@infradead.org>
Since each skb in RX ring is reused instead of new allocation, we can
treat the DMA in a more efficient way by DMA synchronization.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: <stable@vger.kernel.org>
---
v2:
- New patch by following [PATCH v3 1/2] rtw88: pci: Rearrange the
memory usage for skb in RX ISR.
v3:
- Remove rtw_pci_sync_rx_desc_cpu and call dma_sync_single_for_cpu in
rtw_pci_rx_isr directly.
- Remove the return value of rtw_pci_sync_rx_desc_device.
- Use DMA_FROM_DEVICE instead of PCI_DMA_FROMDEVICE.
drivers/net/wireless/realtek/rtw88/pci.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index e9fe3ad896c8..485d30c06935 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -206,6 +206,23 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb,
return 0;
}
+static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
+ struct rtw_pci_rx_ring *rx_ring,
+ u32 idx, u32 desc_sz)
+{
+ struct device *dev = rtwdev->dev;
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ int buf_sz = RTK_PCI_RX_BUF_SIZE;
+
+ dma_sync_single_for_device(dev, dma, buf_sz, DMA_FROM_DEVICE);
+
+ buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
+ idx * desc_sz);
+ memset(buf_desc, 0, sizeof(*buf_desc));
+ buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
+ buf_desc->dma = cpu_to_le32(dma);
+}
+
static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev,
struct rtw_pci_rx_ring *rx_ring,
u8 desc_size, u32 len)
@@ -782,8 +799,8 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
rtw_pci_dma_check(rtwdev, ring, cur_rp);
skb = ring->buf[cur_rp];
dma = *((dma_addr_t *)skb->cb);
- pci_unmap_single(rtwpci->pdev, dma, RTK_PCI_RX_BUF_SIZE,
- PCI_DMA_FROMDEVICE);
+ dma_sync_single_for_cpu(rtwdev->dev, dma, RTK_PCI_RX_BUF_SIZE,
+ DMA_FROM_DEVICE);
rx_desc = skb->data;
chip->ops->query_rx_desc(rtwdev, rx_desc, &pkt_stat, &rx_status);
@@ -818,7 +835,8 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
next_rp:
/* new skb delivered to mac80211, re-enable original skb DMA */
- rtw_pci_reset_rx_desc(rtwdev, skb, ring, cur_rp, buf_desc_sz);
+ rtw_pci_sync_rx_desc_device(rtwdev, dma, ring, cur_rp,
+ buf_desc_sz);
/* host read next element in ring */
if (++cur_rp >= ring->r.len)
--
2.22.0
^ permalink raw reply related
* [PATCH v3 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
From: Jian-Hong Pan @ 2019-07-10 8:38 UTC (permalink / raw)
To: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, Larry Finger,
David Laight, Christoph Hellwig
Cc: linux-wireless, netdev, linux-kernel, linux, Daniel Drake,
Jian-Hong Pan, stable
In-Reply-To: <20190709161550.GA8703@infradead.org>
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, by 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>
---
v2:
- Allocate new data-sized skb and put data into it, then pass it to
mac80211. Reuse the original skb in RX ring by DMA sync.
- Modify the commit message.
- Introduce following [PATCH v3 2/2] rtw88: pci: Use DMA sync instead
of remapping in RX ISR.
v3:
- Same as v2.
drivers/net/wireless/realtek/rtw88/pci.c | 49 +++++++++++-------------
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index cfe05ba7280d..e9fe3ad896c8 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
u32 pkt_offset;
u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
u32 buf_desc_sz = chip->rx_buf_desc_sz;
+ u32 new_len;
u8 *rx_desc;
dma_addr_t dma;
@@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
pkt_stat.shift;
- if (pkt_stat.is_c2h) {
- /* keep rx_desc, halmac needs it */
- skb_put(skb, pkt_stat.pkt_len + pkt_offset);
+ /* discard current skb if the new skb cannot be allocated as a
+ * new one in rx ring later
+ */
+ new_len = pkt_stat.pkt_len + pkt_offset;
+ new = dev_alloc_skb(new_len);
+ if (WARN_ONCE(!new, "rx routine starvation\n"))
+ goto next_rp;
+
+ /* put the DMA data including rx_desc from phy to new skb */
+ skb_put_data(new, skb->data, new_len);
- /* pass offset for further operation */
- *((u32 *)skb->cb) = pkt_offset;
- skb_queue_tail(&rtwdev->c2h_queue, skb);
+ if (pkt_stat.is_c2h) {
+ /* pass rx_desc & offset for further operation */
+ *((u32 *)new->cb) = pkt_offset;
+ skb_queue_tail(&rtwdev->c2h_queue, new);
ieee80211_queue_work(rtwdev->hw, &rtwdev->c2h_work);
} else {
- /* remove rx_desc, maybe use skb_pull? */
- skb_put(skb, pkt_stat.pkt_len);
- skb_reserve(skb, pkt_offset);
-
- /* alloc a smaller skb to mac80211 */
- new = dev_alloc_skb(pkt_stat.pkt_len);
- if (!new) {
- new = skb;
- } else {
- skb_put_data(new, skb->data, skb->len);
- dev_kfree_skb_any(skb);
- }
- /* TODO: merge into rx.c */
- rtw_rx_stats(rtwdev, pkt_stat.vif, skb);
+ /* remove rx_desc */
+ skb_pull(new, pkt_offset);
+
+ rtw_rx_stats(rtwdev, pkt_stat.vif, new);
memcpy(new->cb, &rx_status, sizeof(rx_status));
ieee80211_rx_irqsafe(rtwdev->hw, new);
}
- /* skb delivered to mac80211, alloc a new one in rx ring */
- new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
- if (WARN(!new, "rx routine starvation\n"))
- return;
-
- ring->buf[cur_rp] = new;
- rtw_pci_reset_rx_desc(rtwdev, new, ring, cur_rp, buf_desc_sz);
+next_rp:
+ /* new skb delivered to mac80211, re-enable original skb DMA */
+ rtw_pci_reset_rx_desc(rtwdev, skb, ring, cur_rp, buf_desc_sz);
/* host read next element in ring */
if (++cur_rp >= ring->r.len)
--
2.22.0
^ permalink raw reply related
* RE: [PATCH v2 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
From: Tony Chuang @ 2019-07-10 8:36 UTC (permalink / raw)
To: Jian-Hong Pan, Kalle Valo, David S . Miller, Larry Finger,
David Laight
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com, Daniel Drake,
stable@vger.kernel.org
In-Reply-To: <20190709102059.7036-1-jian-hong@endlessm.com>
> Subject: [PATCH v2 1/2] rtw88: pci: Rearrange the memory usage for skb in
> RX ISR
>
> 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>
> ---
> drivers/net/wireless/realtek/rtw88/pci.c | 49 +++++++++++-------------
> 1 file changed, 22 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> b/drivers/net/wireless/realtek/rtw88/pci.c
> index cfe05ba7280d..e9fe3ad896c8 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> struct rtw_pci *rtwpci,
> u32 pkt_offset;
> u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
> u32 buf_desc_sz = chip->rx_buf_desc_sz;
> + u32 new_len;
> u8 *rx_desc;
> dma_addr_t dma;
>
> @@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> struct rtw_pci *rtwpci,
> pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
> pkt_stat.shift;
>
> - if (pkt_stat.is_c2h) {
> - /* keep rx_desc, halmac needs it */
> - skb_put(skb, pkt_stat.pkt_len + pkt_offset);
> + /* discard current skb if the new skb cannot be allocated as a
> + * new one in rx ring later
> + */
> + new_len = pkt_stat.pkt_len + pkt_offset;
> + new = dev_alloc_skb(new_len);
> + if (WARN_ONCE(!new, "rx routine starvation\n"))
> + goto next_rp;
> +
> + /* put the DMA data including rx_desc from phy to new skb */
> + skb_put_data(new, skb->data, new_len);
>
> - /* pass offset for further operation */
> - *((u32 *)skb->cb) = pkt_offset;
> - skb_queue_tail(&rtwdev->c2h_queue, skb);
> + if (pkt_stat.is_c2h) {
> + /* pass rx_desc & offset for further operation */
> + *((u32 *)new->cb) = pkt_offset;
> + skb_queue_tail(&rtwdev->c2h_queue, new);
> ieee80211_queue_work(rtwdev->hw, &rtwdev->c2h_work);
> } else {
> - /* remove rx_desc, maybe use skb_pull? */
> - skb_put(skb, pkt_stat.pkt_len);
> - skb_reserve(skb, pkt_offset);
> -
> - /* alloc a smaller skb to mac80211 */
> - new = dev_alloc_skb(pkt_stat.pkt_len);
> - if (!new) {
> - new = skb;
> - } else {
> - skb_put_data(new, skb->data, skb->len);
> - dev_kfree_skb_any(skb);
> - }
> - /* TODO: merge into rx.c */
> - rtw_rx_stats(rtwdev, pkt_stat.vif, skb);
> + /* remove rx_desc */
> + skb_pull(new, pkt_offset);
> +
> + rtw_rx_stats(rtwdev, pkt_stat.vif, new);
> memcpy(new->cb, &rx_status, sizeof(rx_status));
> ieee80211_rx_irqsafe(rtwdev->hw, new);
> }
>
> - /* skb delivered to mac80211, alloc a new one in rx ring */
> - new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
> - if (WARN(!new, "rx routine starvation\n"))
> - return;
> -
> - ring->buf[cur_rp] = new;
> - rtw_pci_reset_rx_desc(rtwdev, new, ring, cur_rp, buf_desc_sz);
> +next_rp:
> + /* new skb delivered to mac80211, re-enable original skb DMA */
> + rtw_pci_reset_rx_desc(rtwdev, skb, ring, cur_rp, buf_desc_sz);
>
> /* host read next element in ring */
> if (++cur_rp >= ring->r.len)
> --
> 2.22.0
Now it looks good to me. Thanks.
Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Yan-Hsuan
^ permalink raw reply
* [net-next] mwifiex: use eth_broadcast_addr() to assign broadcast address
From: Mao Wenan @ 2019-07-10 7:25 UTC (permalink / raw)
To: amitkarwar, nishants, gbhat, huxinming820, kvalo
Cc: linux-wireless, kernel-janitors, Mao Wenan
This patch is to use eth_broadcast_addr() to assign broadcast address
insetad of memcpy().
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
drivers/net/wireless/marvell/mwifiex/tdls.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/tdls.c b/drivers/net/wireless/marvell/mwifiex/tdls.c
index 18e654d..0931304 100644
--- a/drivers/net/wireless/marvell/mwifiex/tdls.c
+++ b/drivers/net/wireless/marvell/mwifiex/tdls.c
@@ -731,7 +731,6 @@ mwifiex_construct_tdls_action_frame(struct mwifiex_private *priv,
u16 status_code, struct sk_buff *skb)
{
struct ieee80211_mgmt *mgmt;
- u8 bc_addr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
int ret;
u16 capab;
struct ieee80211_ht_cap *ht_cap;
@@ -765,7 +764,7 @@ mwifiex_construct_tdls_action_frame(struct mwifiex_private *priv,
memmove(pos + ETH_ALEN, &mgmt->u.action.category,
sizeof(mgmt->u.action.u.tdls_discover_resp));
/* init address 4 */
- memcpy(pos, bc_addr, ETH_ALEN);
+ eth_broadcast_addr(pos);
ret = mwifiex_tdls_append_rates_ie(priv, skb);
if (ret) {
--
2.7.4
^ permalink raw reply related
* Re: [5.2 regression] rtwpci + amd iommu
From: Ján Veselý @ 2019-07-10 6:09 UTC (permalink / raw)
To: Tony Chuang; +Cc: linux-wireless
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D1864503@RTITMBSVM04.realtek.com.tw>
Hi,
thanks for a prompt reply.
the patch applies with minor changes (the LPS mod param message and -2
lines offsets), but it works.
The system now lists available wi-fi networks and connects to known
networks all while the iommu is enabled.
feel free to add my tested-by,
regards,
Jan
On Wed, Jul 10, 2019 at 1:12 AM Tony Chuang <yhchuang@realtek.com> wrote:
>
> > Hi,
> >
> > after updating to 5.2 the wi-fi driver stopped working when the iommu
> > is enabled.
> > It fails to list the available wi-fi networks or connect to a known one.
> > booting with amd_iommu=off works around the problem.
> > The staging version in 5.1 and older worked OK with the iommu enabled
> >
> > The device is:
> > 04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822BE
> > 802.11a/b/g/n/ac WiFi adapter
> >
> > I do see an IOMMU error in dmesg, but the originating device does not
> > match the nics pci location:
> > Jul 08 15:03:14 host kernel: rtw_pci 0000:04:00.0: start vif
> > xx:xx:xx:xx:xx:xx on port 0
> > Jul 08 15:03:14 host kernel: iommu ivhd0: AMD-Vi: Event logged
> > [INVALID_DEVICE_REQUEST device=00:00.1 pasid=0x00000
> > address=0xfffffffdf8140200 flags=0x0a00]
> > Jul 08 15:03:14 host kernel: rtw_pci 0000:04:00.0: stop vif
> > xx:xx:xx:xx:xx:xx on port 0
> > Jul 08 15:03:14 host NetworkManager[790]: <info> [1562612594.8992]
> > device (wlp4s0): set-hw-addr: set MAC address to yy:yy:yy:yy:yy:yy
> > (scanning)
> > Jul 08 15:03:15 host kernel: rtw_pci 0000:04:00.0: start vif
> > yy:yy:yy:yy:yy:yy on port 0
> >
> > let me know if I should provide any further info.
> > thanks,
> > Jan
> >
>
>
> Hi,
>
> I am not sure if enabling MSI interrupt is going to help.
> You can try the patch attached, if it works, I will send it to upstream.
> Thanks
>
> Yan-Hsuan
^ permalink raw reply
* RE: [5.2 regression] rtwpci + amd iommu
From: Tony Chuang @ 2019-07-10 5:12 UTC (permalink / raw)
To: Ján Veselý, linux-wireless
In-Reply-To: <CA+K+NcRWLeE3-vah=urveMVxcgXYO0yFHYD=WNeuX_TdZ9+8-A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]
> Hi,
>
> after updating to 5.2 the wi-fi driver stopped working when the iommu
> is enabled.
> It fails to list the available wi-fi networks or connect to a known one.
> booting with amd_iommu=off works around the problem.
> The staging version in 5.1 and older worked OK with the iommu enabled
>
> The device is:
> 04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822BE
> 802.11a/b/g/n/ac WiFi adapter
>
> I do see an IOMMU error in dmesg, but the originating device does not
> match the nics pci location:
> Jul 08 15:03:14 host kernel: rtw_pci 0000:04:00.0: start vif
> xx:xx:xx:xx:xx:xx on port 0
> Jul 08 15:03:14 host kernel: iommu ivhd0: AMD-Vi: Event logged
> [INVALID_DEVICE_REQUEST device=00:00.1 pasid=0x00000
> address=0xfffffffdf8140200 flags=0x0a00]
> Jul 08 15:03:14 host kernel: rtw_pci 0000:04:00.0: stop vif
> xx:xx:xx:xx:xx:xx on port 0
> Jul 08 15:03:14 host NetworkManager[790]: <info> [1562612594.8992]
> device (wlp4s0): set-hw-addr: set MAC address to yy:yy:yy:yy:yy:yy
> (scanning)
> Jul 08 15:03:15 host kernel: rtw_pci 0000:04:00.0: start vif
> yy:yy:yy:yy:yy:yy on port 0
>
> let me know if I should provide any further info.
> thanks,
> Jan
>
Hi,
I am not sure if enabling MSI interrupt is going to help.
You can try the patch attached, if it works, I will send it to upstream.
Thanks
Yan-Hsuan
[-- Attachment #2: 0001-rtw88-pci-add-MSI-interrupt-support.patch --]
[-- Type: application/octet-stream, Size: 5082 bytes --]
From 570d6ed8585855a8c6aee20e6d319829ebef6bc7 Mon Sep 17 00:00:00 2001
From: Yu-Yen Ting <steventing@realtek.com>
Date: Wed, 29 May 2019 16:31:27 +0800
Subject: [PATCH] rtw88: pci: add MSI interrupt support
The MSI interrupt should be enabled on certain platform.
Add the module parameter disable_msi to force disable the MSI interrupt
Signed-off-by: Yu-Yen Ting <steventing@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
---
drivers/net/wireless/realtek/rtw88/main.c | 5 ++++
drivers/net/wireless/realtek/rtw88/main.h | 1 +
drivers/net/wireless/realtek/rtw88/pci.c | 47 +++++++++++++++++++++++++++++--
drivers/net/wireless/realtek/rtw88/pci.h | 1 +
4 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index b8e0519..d86e05e 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -15,13 +15,18 @@
static bool rtw_fw_support_lps;
unsigned int rtw_debug_mask;
+bool rtw_disable_msi;
+
EXPORT_SYMBOL(rtw_debug_mask);
+EXPORT_SYMBOL(rtw_disable_msi);
module_param_named(support_lps, rtw_fw_support_lps, bool, 0644);
module_param_named(debug_mask, rtw_debug_mask, uint, 0644);
+module_param_named(disable_msi, rtw_disable_msi, bool, 0644);
MODULE_PARM_DESC(support_lps, "Set Y to enable Leisure Power Save support, to turn radio off between beacons");
MODULE_PARM_DESC(debug_mask, "Debugging mask");
+MODULE_PARM_DESC(disable_msi, "Set Y to disable MSI interrupt support");
static struct ieee80211_channel rtw_channeltable_2g[] = {
{.center_freq = 2412, .hw_value = 1,},
diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
index 92730507..ca603ba 100644
--- a/drivers/net/wireless/realtek/rtw88/main.h
+++ b/drivers/net/wireless/realtek/rtw88/main.h
@@ -28,6 +28,7 @@
#define HW_FEATURE_LEN 13
extern unsigned int rtw_debug_mask;
+extern bool rtw_disable_msi;
extern const struct ieee80211_ops rtw_ops;
extern struct rtw_chip_info rtw8822b_hw_spec;
extern struct rtw_chip_info rtw8822c_hw_spec;
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index 353871c..817b4ab 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -861,6 +861,7 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void *dev)
if (!rtwpci->irq_enabled)
goto out;
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -880,6 +881,8 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void *dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+
out:
spin_unlock(&rtwpci->irq_lock);
@@ -1090,6 +1093,45 @@ static struct rtw_hci_ops rtw_pci_ops = {
.write_data_h2c = rtw_pci_write_data_h2c,
};
+static int rtw_pci_request_irq(struct rtw_dev *rtwdev, struct pci_dev *pdev)
+{
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ int ret;
+
+ if (!rtw_disable_msi) {
+ ret = pci_enable_msi(pdev);
+ if (ret) {
+ rtw_warn(rtwdev, "failed to enable msi, using legacy irq\n");
+ } else {
+ rtw_warn(rtwdev, "pci msi enabled\n");
+ rtwpci->msi_enabled = true;
+ }
+ }
+
+ ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler, IRQF_SHARED,
+ KBUILD_MODNAME, rtwdev);
+ if (ret) {
+ rtw_err(rtwdev, "failed to request irq\n");
+ if (rtwpci->msi_enabled) {
+ pci_disable_msi(pdev);
+ rtwpci->msi_enabled = false;
+ }
+ }
+
+ return ret;
+}
+
+static void rtw_pci_free_irq(struct rtw_dev *rtwdev, struct pci_dev *pdev)
+{
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+
+ free_irq(pdev->irq, rtwdev);
+ if (rtwpci->msi_enabled) {
+ pci_disable_msi(pdev);
+ rtwpci->msi_enabled = false;
+ }
+}
+
static int rtw_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
@@ -1144,8 +1186,7 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = rtw_pci_request_irq(rtwdev, pdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1184,7 +1225,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ rtw_pci_free_irq(rtwdev, pdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
diff --git a/drivers/net/wireless/realtek/rtw88/pci.h b/drivers/net/wireless/realtek/rtw88/pci.h
index 87824a4..a8e369c 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.h
+++ b/drivers/net/wireless/realtek/rtw88/pci.h
@@ -186,6 +186,7 @@ struct rtw_pci {
spinlock_t irq_lock;
u32 irq_mask[4];
bool irq_enabled;
+ bool msi_enabled;
u16 rx_tag;
struct rtw_pci_tx_ring tx_rings[RTK_MAX_TX_QUEUE_NUM];
--
2.7.4
^ permalink raw reply related
* RE: [PATCH 09/12] rtw88: Fix misuse of GENMASK macro
From: Tony Chuang @ 2019-07-10 5:07 UTC (permalink / raw)
To: Joe Perches, Andrew Morton
Cc: Kalle Valo, David S. Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Huang
In-Reply-To: <0de52d891d7925b02f4f0fe2c750d076e55434d9.1562734889.git.joe@perches.com>
> Subject: [PATCH 09/12] rtw88: Fix misuse of GENMASK macro
>
> Arguments are supposed to be ordered high then low.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/wireless/realtek/rtw88/rtw8822b.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> index 1172f6c0605b..d61d534396c7 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> @@ -997,7 +997,7 @@ static void rtw8822b_do_iqk(struct rtw_dev *rtwdev)
> rtw_write_rf(rtwdev, RF_PATH_A, RF_DTXLOK, RFREG_MASK, 0x0);
>
> reload = !!rtw_read32_mask(rtwdev, REG_IQKFAILMSK, BIT(16));
> - iqk_fail_mask = rtw_read32_mask(rtwdev, REG_IQKFAILMSK,
> GENMASK(0, 7));
> + iqk_fail_mask = rtw_read32_mask(rtwdev, REG_IQKFAILMSK,
> GENMASK(7, 0));
> rtw_dbg(rtwdev, RTW_DBG_PHY,
> "iqk counter=%d reload=%d do_iqk_cnt=%d
> n_iqk_fail(mask)=0x%02x\n",
> counter, reload, ++do_iqk_cnt, iqk_fail_mask);
> --
That's correct. Thanks.
Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Yan-Hsuan
^ permalink raw reply
* [PATCH 00/12] treewide: Fix GENMASK misuses
From: Joe Perches @ 2019-07-10 5:04 UTC (permalink / raw)
To: Andrew Morton, Patrick Venture, Nancy Yuen, Benjamin Fair,
Andrew Jeffery, openbmc, linux-kernel, linux-aspeed,
linux-arm-kernel, linux-amlogic, netdev, linux-mediatek,
linux-stm32, linux-wireless, linux-media
Cc: dri-devel, linux-iio, linux-mmc, devel, alsa-devel
These GENMASK uses are inverted argument order and the
actual masks produced are incorrect. Fix them.
Add checkpatch tests to help avoid more misuses too.
Joe Perches (12):
checkpatch: Add GENMASK tests
clocksource/drivers/npcm: Fix misuse of GENMASK macro
drm: aspeed_gfx: Fix misuse of GENMASK macro
iio: adc: max9611: Fix misuse of GENMASK macro
irqchip/gic-v3-its: Fix misuse of GENMASK macro
mmc: meson-mx-sdio: Fix misuse of GENMASK macro
net: ethernet: mediatek: Fix misuses of GENMASK macro
net: stmmac: Fix misuses of GENMASK macro
rtw88: Fix misuse of GENMASK macro
phy: amlogic: G12A: Fix misuse of GENMASK macro
staging: media: cedrus: Fix misuse of GENMASK macro
ASoC: wcd9335: Fix misuse of GENMASK macro
drivers/clocksource/timer-npcm7xx.c | 2 +-
drivers/gpu/drm/aspeed/aspeed_gfx.h | 2 +-
drivers/iio/adc/max9611.c | 2 +-
drivers/irqchip/irq-gic-v3-its.c | 2 +-
drivers/mmc/host/meson-mx-sdio.c | 2 +-
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
drivers/net/ethernet/mediatek/mtk_sgmii.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/descs.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 4 ++--
drivers/net/wireless/realtek/rtw88/rtw8822b.c | 2 +-
drivers/phy/amlogic/phy-meson-g12a-usb2.c | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +-
scripts/checkpatch.pl | 15 +++++++++++++++
sound/soc/codecs/wcd-clsh-v2.c | 2 +-
14 files changed, 29 insertions(+), 14 deletions(-)
--
2.15.0
^ permalink raw reply
* [PATCH 09/12] rtw88: Fix misuse of GENMASK macro
From: Joe Perches @ 2019-07-10 5:04 UTC (permalink / raw)
To: Andrew Morton, Yan-Hsuan Chuang
Cc: Kalle Valo, David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <cover.1562734889.git.joe@perches.com>
Arguments are supposed to be ordered high then low.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/realtek/rtw88/rtw8822b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
index 1172f6c0605b..d61d534396c7 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
@@ -997,7 +997,7 @@ static void rtw8822b_do_iqk(struct rtw_dev *rtwdev)
rtw_write_rf(rtwdev, RF_PATH_A, RF_DTXLOK, RFREG_MASK, 0x0);
reload = !!rtw_read32_mask(rtwdev, REG_IQKFAILMSK, BIT(16));
- iqk_fail_mask = rtw_read32_mask(rtwdev, REG_IQKFAILMSK, GENMASK(0, 7));
+ iqk_fail_mask = rtw_read32_mask(rtwdev, REG_IQKFAILMSK, GENMASK(7, 0));
rtw_dbg(rtwdev, RTW_DBG_PHY,
"iqk counter=%d reload=%d do_iqk_cnt=%d n_iqk_fail(mask)=0x%02x\n",
counter, reload, ++do_iqk_cnt, iqk_fail_mask);
--
2.15.0
^ permalink raw reply related
* [5.2 regression] rtwpci + amd iommu
From: Ján Veselý @ 2019-07-10 4:38 UTC (permalink / raw)
To: linux-wireless; +Cc: yhchuang
Hi,
after updating to 5.2 the wi-fi driver stopped working when the iommu
is enabled.
It fails to list the available wi-fi networks or connect to a known one.
booting with amd_iommu=off works around the problem.
The staging version in 5.1 and older worked OK with the iommu enabled
The device is:
04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822BE
802.11a/b/g/n/ac WiFi adapter
I do see an IOMMU error in dmesg, but the originating device does not
match the nics pci location:
Jul 08 15:03:14 host kernel: rtw_pci 0000:04:00.0: start vif
xx:xx:xx:xx:xx:xx on port 0
Jul 08 15:03:14 host kernel: iommu ivhd0: AMD-Vi: Event logged
[INVALID_DEVICE_REQUEST device=00:00.1 pasid=0x00000
address=0xfffffffdf8140200 flags=0x0a00]
Jul 08 15:03:14 host kernel: rtw_pci 0000:04:00.0: stop vif
xx:xx:xx:xx:xx:xx on port 0
Jul 08 15:03:14 host NetworkManager[790]: <info> [1562612594.8992]
device (wlp4s0): set-hw-addr: set MAC address to yy:yy:yy:yy:yy:yy
(scanning)
Jul 08 15:03:15 host kernel: rtw_pci 0000:04:00.0: start vif
yy:yy:yy:yy:yy:yy on port 0
let me know if I should provide any further info.
thanks,
Jan
^ permalink raw reply
* Re: [PATCH 4/7] mmc: sdio: Drop powered-on re-init at runtime resume and HW reset
From: Doug Anderson @ 2019-07-09 23:35 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linux MMC List, Adrian Hunter, Brian Norris, Shawn Lin,
Guenter Roeck, Heiko Stuebner, Kalle Valo, Arend Van Spriel,
linux-wireless
In-Reply-To: <CAPDyKFpN38G-Oj-+cKcxQ8z8K7M_0sA6_CTSKuxvez2s3Td+xw@mail.gmail.com>
Hi,
On Tue, Jul 9, 2019 at 5:02 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Mon, 8 Jul 2019 at 23:12, Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Mon, Jul 8, 2019 at 3:54 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > >
> > > On Thu, 4 Jul 2019 at 02:02, Doug Anderson <dianders@chromium.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Tue, Jun 18, 2019 at 8:35 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > >
> > > > > To use the so called powered-on re-initialization of an SDIO card, the
> > > > > power to the card must obviously have stayed on. If not, the initialization
> > > > > will simply fail.
> > > > >
> > > > > In the runtime suspend case, the card is always powered off. Hence, let's
> > > > > drop the support for powered-on re-initialization during runtime resume, as
> > > > > it doesn't make sense.
> > > > >
> > > > > Moreover, during a HW reset, the point is to cut the power to the card and
> > > > > then do fresh re-initialization. Therefore drop the support for powered-on
> > > > > re-initialization during HW reset.
> > > > >
> > > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > > > > ---
> > > > > drivers/mmc/core/sdio.c | 8 +-------
> > > > > 1 file changed, 1 insertion(+), 7 deletions(-)
> > > >
> > > > This has been on my list of things to test for a while but I never
> > > > quite got to it...
> > > >
> > > > ...and then, today, I spent time bisecting why the "reset"
> > > > functionality of miwfiex is broken on my 4.19 kernel [1]. AKA, this
> > > > is broken:
> > > >
> > > > cd /sys/kernel/debug/mwifiex/mlan0
> > > > echo 1 > reset
> > > >
> > > > I finally bisected the problem and tracked it down to commit
> > > > ca8971ca5753 ("mmc: dw_mmc: Prevent runtime PM suspend when SDIO IRQs
> > > > are enabled"), which embarrassingly has my Tested-by on it. I guess I
> > > > never tested the Marvell reset call. :-/
> > > >
> > > > I dug a little and found that when the Marvell code did its reset we
> > > > ended up getting a call to dw_mci_enable_sdio_irq(enb=0) and never saw
> > > > a dw_mci_enable_sdio_irq(enb=1) after. I tracked it down further and
> > > > found that specifically it was the call to mmc_signal_sdio_irq() in
> > > > mmc_sdio_power_restore() that was making the call. The call stack
> > > > shown for the "enb=0" call:
> > > >
> > > > [<c071a290>] (dw_mci_enable_sdio_irq) from [<c070a960>]
> > > > (mmc_sdio_power_restore+0x98/0xc0)
> > > > [<c070a960>] (mmc_sdio_power_restore) from [<c070a9b4>]
> > > > (mmc_sdio_reset+0x2c/0x30)
> > > > [<c070a9b4>] (mmc_signal_sdio_irq) from [<c06ff160>] (mmc_hw_reset+0xbc/0x138)
> > > > [<c06ff160>] (mmc_hw_reset) from [<bf1bbad8>]
> > > > (mwifiex_sdio_work+0x5d4/0x678 [mwifiex_sdio])
> > > > [<bf1bbad8>] (mwifiex_sdio_work [mwifiex_sdio]) from [<c0247cd0>]
> > > > (process_one_work+0x290/0x4b4)
> > > >
> > > > I picked your patch here (which gets rid of the call to
> > > > mmc_signal_sdio_irq()) and magically the problem went away because
> > > > there is no more call to mmc_signal_sdio_irq().
> > > >
> > > > I personally don't have lots of history about the whole
> > > > "powered_resume" code path. I checked and mmc_card_keep_power() was 0
> > > > in my test case of getting called from hw_reset, so the rest of this
> > > > patch doesn't affect me at all. This surprised me a little since I
> > > > saw "MMC_PM_KEEP_POWER" being set in mwifiex but then I realized that
> > > > it was only set for the duration of suspend and then cleared by the
> > > > core. ;-)
> > > >
> > > > I will also say that I don't have any test case or knowledge of how
> > > > SDIO runtime suspend/resume is supposed to work since on dw_mmc SDIO
> > > > cards are currently not allowed to runtime suspend anyway. ;-)
> > > >
> > > >
> > > > So I guess the result of all that long-winded reply is that for on
> > > > rk3288-veyron-jerry:
> > > >
> > > > Fixes: ca8971ca5753 ("mmc: dw_mmc: Prevent runtime PM suspend when
> > > > SDIO IRQs are enabled")
> > > > Tested-by: Douglas Anderson <dianders@chromium.org>
> > >
> > > Thanks a lot for testing and for your detailed feedback. I have
> > > amended the patch by adding your tags above.
> >
> > Sure! I'm going to try to do some detailed testing on the next patch
> > too to confirm it's OK, but I have a few other tasks to get to first.
> > ;-)
> >
> >
> > > Moreover, we seems to need this for stable as well, but I am leaving
> > > that to be managed as a separate task. We may even consider the hole
> > > series for stable, but that requires more testing first.
> >
> > Sure, makes sense. We'll pick it to the Chrome OS 4.19 kernel
> > directly but it's usually nice to get fixes like this into stable so
> > everyone can benefit.
> >
> >
> > > > One last note is that, though Marvell WiFi works after a reset after
> > > > this commit, Marvell Bluetooth (on the same SDIO module) doesn't. I
> > > > guess next week it'll be another bisect...
> > >
> > > Is the Bluetooth connected to the same SDIO interface, thus the
> > > Bluetooth driver is an SDIO func driver?
> >
> > Yes, it's a SDIO func driver connected to the same interface. So far
> > I've managed to confirm the problem on:
> >
> > v4.4 (plus 76ae3e26ea43 mwifiex: add debugfs file for testing reset of card)
> > v4.9
> > next-20190708
> >
> > ...so it seems like it's not a "regression", it's just never worked.
> > :-P I guess I'll have to see if I can figure out what's different in
> > our chromeos-3.14 kernel. Ah, I see. In 3.14 we had this solution:
> >
> > pr_err("Resetting card...\n");
> > mmc_remove_host(reset_host);
> > /* 200ms delay is based on experiment with sdhci controller */
> > mdelay(200);
> > reset_host->rescan_entered = 0;
> > mmc_add_host(reset_host);
> >
> > ...I think that didn't fly upstream. ...but I can confirm that this works fine:
> >
> > cd /sys/bus/platform/drivers/dwmmc_rockchip
> > echo ff0d0000.dwmmc > unbind
> > sleep .5
> > echo ff0d0000.dwmmc > bind
> >
> > ...so I guess this boils down to: how does the mwifiex reset code not
> > behave like a full removal and re-insertion of the card? Oh, but
> > maybe that's obvious. We're doing all the reset / re-init from the
> > WiFi side of things (mwifiex_sdio_card_reset_work) but I don't think
> > anything is communicated to the Bluetooth side of things. Presumably
> > this is just totally broken for everyone? ...or am I confused?
>
> Nope, that is most likely what is happening.
>
> I am not sure what is the best method to deal with this. Perhaps we
> should invent some callback the SDIO core code can call, for each
> active SDIO func on the particular SDIO card that becomes reset.
>
> Or is there a better way you think?
I didn't get a chance to fully dig today, but I keep thinking that the
cleanest way would be if I could somehow tell the MMC core to pretend
to unplug the card and then re-plug it in. Then we could go through
all the standard code paths. I remember the last time I looked for a
nice way to do that I couldn't find one.
...barring that I wonder if it's enough to just remove and re-add all
the active SDIO funcs?
-Doug
^ permalink raw reply
* Re: [PATCH 7/7] mmc: sdio: Drop unused in-parameter from mmc_sdio_init_card()
From: Doug Anderson @ 2019-07-09 21:31 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linux MMC List, Adrian Hunter, Brian Norris, Shawn Lin,
Guenter Roeck, Heiko Stuebner, Kalle Valo, Arend Van Spriel,
linux-wireless
In-Reply-To: <20190618153448.27145-8-ulf.hansson@linaro.org>
Hi,
On Tue, Jun 18, 2019 at 8:35 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> The "powered_resume" in-parameter to mmc_sdio_init_card() has now become
> redundant as all callers set it to 0. Therefore let's just drop it.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/mmc/core/sdio.c | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH 6/7] mmc: sdio: Drop unused in-parameter to mmc_sdio_reinit_card()
From: Doug Anderson @ 2019-07-09 21:29 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linux MMC List, Adrian Hunter, Brian Norris, Shawn Lin,
Guenter Roeck, Heiko Stuebner, Kalle Valo, Arend Van Spriel,
linux-wireless
In-Reply-To: <20190618153448.27145-7-ulf.hansson@linaro.org>
Hi,
On Tue, Jun 18, 2019 at 8:35 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> The "powered_resume" in-parameter to mmc_sdio_reinit_card() has now become
> redundant as all callers set it to 0. Therefore let's just drop it.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/mmc/core/sdio.c | 18 ++++++------------
> 1 file changed, 6 insertions(+), 12 deletions(-)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH 3/7] mmc: sdio: Move comment about re-initialization to mmc_sdio_reinit_card()
From: Doug Anderson @ 2019-07-09 21:27 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linux MMC List, Adrian Hunter, Brian Norris, Shawn Lin,
Guenter Roeck, Heiko Stuebner, Kalle Valo, Arend Van Spriel,
linux-wireless
In-Reply-To: <20190618153448.27145-4-ulf.hansson@linaro.org>
Hi,
On Tue, Jun 18, 2019 at 8:35 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> The comment in mmc_sdio_power_restore() belongs in mmc_sdio_reinit_card(),
> which was created during a previous commit that re-factored some code. Fix
> this by moving the comment into mmc_sdio_reinit_card().
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/mmc/core/sdio.c | 34 +++++++++++++++++-----------------
> 1 file changed, 17 insertions(+), 17 deletions(-)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH 5/7] mmc: sdio: Don't re-initialize powered-on removable SDIO cards at resume
From: Doug Anderson @ 2019-07-09 21:26 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linux MMC List, Adrian Hunter, Brian Norris, Shawn Lin,
Guenter Roeck, Heiko Stuebner, Kalle Valo, Arend Van Spriel,
linux-wireless
In-Reply-To: <20190618153448.27145-6-ulf.hansson@linaro.org>
Hi,
On Tue, Jun 18, 2019 at 8:35 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> It looks like the original idea behind always doing a re-initialization of
> a removable SDIO card during system resume in mmc_sdio_resume(), is to try
> to play safe to detect whether the card has been removed.
>
> However, this seems like a really a bad idea as it will most likely screw
> things up, especially when the card is expected to remain powered on during
> system suspend by the SDIO func driver.
>
> Let's fix this, simply by trusting that the detect work checks if the card
> is alive and inserted, which is being scheduled at the PM_POST_SUSPEND
> notification anyway.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/mmc/core/sdio.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
I'm not sure if it's even worth mentioning since the device I tested
was rk3288-veyron (both WiFi variants) and we have a non-removable,
powered-in-suspend, wakeup-disabled card. That means it isn't
affected at all by your change. ...but I suppose I can at least
confirm that your change didn't break me if that's worth anything.
:-P
Tested-by: Douglas Anderson <dianders@chromium.org>
I would also say that, though I don't have any history here, your
patch seems reasonable to me. So you can add a:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH 2/7] mmc: sdio: Drop mmc_claim|release_host() in mmc_sdio_power_restore()
From: Doug Anderson @ 2019-07-09 21:25 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linux MMC List, Adrian Hunter, Brian Norris, Shawn Lin,
Guenter Roeck, Heiko Stuebner, Kalle Valo, Arend Van Spriel,
linux-wireless
In-Reply-To: <20190618153448.27145-3-ulf.hansson@linaro.org>
Hi,
On Tue, Jun 18, 2019 at 8:35 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> The function mmc_sdio_power_restore() is called either from
> mmc_sdio_runtime_resume() or from mmc_sdio_hw_reset(). Both callers either
> claims/releases the host or require its callers to do so. Therefore let's
> drop the redundant calls to mmc_claim|release_host() in
> mmc_sdio_power_restore().
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/mmc/core/sdio.c | 4 ----
> 1 file changed, 4 deletions(-)
Without being an expert, I looked through the code and as far as I can
tell this is fine. Specifically:
* I agree there are two calls and mmc_sdio_runtime_resume() clearly claims.
* The only call to mmc_sdio_hw_reset() looks to be mmc_hw_reset();
looking through calls to mmc_hw_reset() I see the claims. It's super
obvious in the 3 cases in "drivers/net" and I decided that I didn't
need to look at block.c because that shouldn't be a codepath that
affects SDIO.
Thus:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
I also don't see this patch causing any problems on the rk3288-veyron
boards I tested it on. Thus:
Tested-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH v1 01/22] docs: Documentation/*.txt: rename all ReST files to *.rst
From: Rob Herring @ 2019-07-09 17:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, linux-fbdev, linux-ia64, kvm, linux-sh,
linux-pci, dri-devel, platform-driver-x86, kernel-hardening,
sparclinux, linux-arch, linux-s390, Jonathan Corbet, x86,
linux-security-module, devicetree, linux-watchdog,
Mauro Carvalho Chehab, linux-block, linux-gpio,
openipmi-developer, linux-arm-kernel, linaro-mm-sig, linux-parisc,
linux-mm, netdev, linux-wireless, linux-kernel, iommu,
linux-crypto
In-Reply-To: <6b6b6db8d6de9b66223dd6d4b43eb60ead4c71d7.1560891322.git.mchehab+samsung@kernel.org>
On Tue, Jun 18, 2019 at 06:05:25PM -0300, Mauro Carvalho Chehab wrote:
> Those files are actually at ReST format. Ok, currently, they
> don't belong to any place yet at the organized book series,
> but we don't want patches to break them as ReST files. So,
> rename them and add a :orphan: in order to shut up warning
> messages like those:
>
> ...
> Documentation/svga.rst: WARNING: document isn't included in any toctree
> Documentation/switchtec.rst: WARNING: document isn't included in any toctree
> ...
>
> Later patches will move them to a better place and remove the
> :orphan: markup.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>
> I had to remove the long list of maintainers got by
> getpatch.pl, as it was too long. I opted to keep only the
> mailing lists.
>
> Documentation/ABI/removed/sysfs-class-rfkill | 2 +-
> Documentation/ABI/stable/sysfs-class-rfkill | 2 +-
> Documentation/ABI/stable/sysfs-devices-node | 2 +-
> Documentation/ABI/testing/procfs-diskstats | 2 +-
> Documentation/ABI/testing/sysfs-block | 2 +-
> .../ABI/testing/sysfs-class-switchtec | 2 +-
> .../ABI/testing/sysfs-devices-system-cpu | 4 +-
> .../{DMA-API-HOWTO.txt => DMA-API-HOWTO.rst} | 2 +
> Documentation/{DMA-API.txt => DMA-API.rst} | 8 ++-
> .../{DMA-ISA-LPC.txt => DMA-ISA-LPC.rst} | 4 +-
> ...{DMA-attributes.txt => DMA-attributes.rst} | 2 +
> Documentation/{IPMI.txt => IPMI.rst} | 2 +
> .../{IRQ-affinity.txt => IRQ-affinity.rst} | 2 +
> .../{IRQ-domain.txt => IRQ-domain.rst} | 2 +
> Documentation/{IRQ.txt => IRQ.rst} | 2 +
> .../{Intel-IOMMU.txt => Intel-IOMMU.rst} | 2 +
> Documentation/PCI/pci.rst | 8 +--
> Documentation/{SAK.txt => SAK.rst} | 3 +-
> Documentation/{SM501.txt => SM501.rst} | 2 +
> Documentation/admin-guide/hw-vuln/l1tf.rst | 2 +-
> .../admin-guide/kernel-parameters.txt | 4 +-
> .../{atomic_bitops.txt => atomic_bitops.rst} | 3 +-
> Documentation/block/biodoc.txt | 2 +-
> .../{bt8xxgpio.txt => bt8xxgpio.rst} | 3 +-
> Documentation/{btmrvl.txt => btmrvl.rst} | 2 +
> ...-mapping.txt => bus-virt-phys-mapping.rst} | 54 +++++++++---------
> ...g-warn-once.txt => clearing-warn-once.rst} | 2 +
> Documentation/{cpu-load.txt => cpu-load.rst} | 2 +
> .../{cputopology.txt => cputopology.rst} | 2 +
> Documentation/{crc32.txt => crc32.rst} | 2 +
> Documentation/{dcdbas.txt => dcdbas.rst} | 2 +
> ...ging-modules.txt => debugging-modules.rst} | 2 +
> ...hci1394.txt => debugging-via-ohci1394.rst} | 2 +
> Documentation/{dell_rbu.txt => dell_rbu.rst} | 3 +-
> Documentation/device-mapper/statistics.rst | 4 +-
> .../devicetree/bindings/phy/phy-bindings.txt | 2 +-
Acked-by: Rob Herring <robh@kernel.org>
> Documentation/{digsig.txt => digsig.rst} | 2 +
> Documentation/driver-api/usb/dma.rst | 6 +-
> Documentation/driver-model/device.rst | 2 +-
> Documentation/{efi-stub.txt => efi-stub.rst} | 2 +
> Documentation/{eisa.txt => eisa.rst} | 2 +
> Documentation/fb/vesafb.rst | 2 +-
> Documentation/filesystems/sysfs.txt | 2 +-
> ...ex-requeue-pi.txt => futex-requeue-pi.rst} | 2 +
> .../{gcc-plugins.txt => gcc-plugins.rst} | 2 +
> Documentation/gpu/drm-mm.rst | 2 +-
> Documentation/{highuid.txt => highuid.rst} | 4 +-
> .../{hw_random.txt => hw_random.rst} | 2 +
> .../{hwspinlock.txt => hwspinlock.rst} | 2 +
> Documentation/ia64/irq-redir.rst | 2 +-
> .../{intel_txt.txt => intel_txt.rst} | 2 +
> .../{io-mapping.txt => io-mapping.rst} | 2 +
> .../{io_ordering.txt => io_ordering.rst} | 2 +
> Documentation/{iostats.txt => iostats.rst} | 2 +
> ...flags-tracing.txt => irqflags-tracing.rst} | 3 +-
> Documentation/{isa.txt => isa.rst} | 2 +
> Documentation/{isapnp.txt => isapnp.rst} | 2 +
> ...hreads.txt => kernel-per-CPU-kthreads.rst} | 4 +-
> Documentation/{kobject.txt => kobject.rst} | 6 +-
> Documentation/{kprobes.txt => kprobes.rst} | 3 +-
> Documentation/{kref.txt => kref.rst} | 2 +
> Documentation/laptops/thinkpad-acpi.rst | 6 +-
> Documentation/{ldm.txt => ldm.rst} | 5 +-
> Documentation/locking/rt-mutex.rst | 2 +-
> ...kup-watchdogs.txt => lockup-watchdogs.rst} | 2 +
> Documentation/{lsm.txt => lsm.rst} | 2 +
> Documentation/{lzo.txt => lzo.rst} | 2 +
> Documentation/{mailbox.txt => mailbox.rst} | 2 +
> Documentation/memory-barriers.txt | 6 +-
> ...hameleon-bus.txt => men-chameleon-bus.rst} | 2 +
> Documentation/networking/scaling.rst | 4 +-
> .../{nommu-mmap.txt => nommu-mmap.rst} | 2 +
> Documentation/{ntb.txt => ntb.rst} | 2 +
> Documentation/{numastat.txt => numastat.rst} | 3 +-
> Documentation/{padata.txt => padata.rst} | 2 +
> ...port-lowlevel.txt => parport-lowlevel.rst} | 2 +
> ...-semaphore.txt => percpu-rw-semaphore.rst} | 2 +
> Documentation/{phy.txt => phy.rst} | 2 +
> Documentation/{pi-futex.txt => pi-futex.rst} | 2 +
> Documentation/{pnp.txt => pnp.rst} | 13 +++--
> ...reempt-locking.txt => preempt-locking.rst} | 4 +-
> Documentation/{pwm.txt => pwm.rst} | 2 +
> Documentation/{rbtree.txt => rbtree.rst} | 54 +++++++++---------
> .../{remoteproc.txt => remoteproc.rst} | 4 +-
> Documentation/{rfkill.txt => rfkill.rst} | 2 +
> ...ust-futex-ABI.txt => robust-futex-ABI.rst} | 2 +
> ...{robust-futexes.txt => robust-futexes.rst} | 2 +
> Documentation/{rpmsg.txt => rpmsg.rst} | 2 +
> Documentation/{rtc.txt => rtc.rst} | 8 ++-
> Documentation/s390/vfio-ccw.rst | 6 +-
> Documentation/{sgi-ioc4.txt => sgi-ioc4.rst} | 2 +
> Documentation/{siphash.txt => siphash.rst} | 2 +
> .../{smsc_ece1099.txt => smsc_ece1099.rst} | 2 +
> .../{speculation.txt => speculation.rst} | 2 +
> .../{static-keys.txt => static-keys.rst} | 2 +
> Documentation/{svga.txt => svga.rst} | 2 +
> .../{switchtec.txt => switchtec.rst} | 4 +-
> .../{sync_file.txt => sync_file.rst} | 2 +
> Documentation/sysctl/kernel.txt | 4 +-
> Documentation/sysctl/vm.txt | 2 +-
> Documentation/{tee.txt => tee.rst} | 2 +
> .../{this_cpu_ops.txt => this_cpu_ops.rst} | 2 +
> Documentation/trace/kprobetrace.rst | 2 +-
> .../translations/ko_KR/memory-barriers.txt | 6 +-
> Documentation/translations/zh_CN/IRQ.txt | 4 +-
> .../translations/zh_CN/filesystems/sysfs.txt | 2 +-
> .../translations/zh_CN/io_ordering.txt | 4 +-
> ...access.txt => unaligned-memory-access.rst} | 2 +
> ...ed-device.txt => vfio-mediated-device.rst} | 4 +-
> Documentation/{vfio.txt => vfio.rst} | 2 +
> .../{video-output.txt => video-output.rst} | 3 +-
> Documentation/watchdog/hpwdt.rst | 2 +-
> Documentation/x86/topology.rst | 2 +-
> Documentation/{xillybus.txt => xillybus.rst} | 2 +
> Documentation/{xz.txt => xz.rst} | 2 +
> Documentation/{zorro.txt => zorro.rst} | 7 ++-
> MAINTAINERS | 56 +++++++++----------
> arch/Kconfig | 4 +-
> arch/arm/Kconfig | 2 +-
> arch/ia64/hp/common/sba_iommu.c | 12 ++--
> arch/ia64/sn/pci/pci_dma.c | 4 +-
> arch/parisc/Kconfig | 2 +-
> arch/parisc/kernel/pci-dma.c | 2 +-
> arch/sh/Kconfig | 2 +-
> arch/sparc/Kconfig | 2 +-
> arch/unicore32/include/asm/io.h | 2 +-
> arch/x86/Kconfig | 4 +-
> arch/x86/include/asm/dma-mapping.h | 4 +-
> arch/x86/kernel/amd_gart_64.c | 2 +-
> block/partitions/Kconfig | 2 +-
> drivers/base/core.c | 2 +-
> drivers/char/Kconfig | 4 +-
> drivers/char/hw_random/core.c | 2 +-
> drivers/char/ipmi/Kconfig | 2 +-
> drivers/char/ipmi/ipmi_si_hotmod.c | 2 +-
> drivers/char/ipmi/ipmi_si_intf.c | 2 +-
> drivers/dma-buf/Kconfig | 2 +-
> drivers/gpio/Kconfig | 2 +-
> drivers/parisc/sba_iommu.c | 16 +++---
> drivers/pci/switch/Kconfig | 2 +-
> drivers/platform/x86/Kconfig | 4 +-
> drivers/platform/x86/dcdbas.c | 2 +-
> drivers/platform/x86/dell_rbu.c | 2 +-
> drivers/pnp/isapnp/Kconfig | 2 +-
> drivers/vfio/Kconfig | 2 +-
> drivers/vfio/mdev/Kconfig | 2 +-
> include/asm-generic/bitops/atomic.h | 2 +-
> include/linux/dma-mapping.h | 2 +-
> include/linux/hw_random.h | 2 +-
> include/linux/io-mapping.h | 2 +-
> include/linux/jump_label.h | 2 +-
> include/linux/kobject.h | 2 +-
> include/linux/kobject_ns.h | 2 +-
> include/linux/rbtree.h | 2 +-
> include/linux/rbtree_augmented.h | 2 +-
> include/media/videobuf-dma-sg.h | 2 +-
> init/Kconfig | 2 +-
> kernel/dma/debug.c | 2 +-
> kernel/padata.c | 2 +-
> lib/Kconfig | 2 +-
> lib/Kconfig.debug | 2 +-
> lib/crc32.c | 2 +-
> lib/kobject.c | 4 +-
> lib/lzo/lzo1x_decompress_safe.c | 2 +-
> lib/xz/Kconfig | 2 +-
> mm/Kconfig | 2 +-
> mm/nommu.c | 2 +-
> samples/kprobes/kprobe_example.c | 2 +-
> samples/kprobes/kretprobe_example.c | 2 +-
> scripts/gcc-plugins/Kconfig | 2 +-
> security/Kconfig | 2 +-
> tools/include/linux/rbtree.h | 2 +-
> tools/include/linux/rbtree_augmented.h | 2 +-
> 173 files changed, 397 insertions(+), 242 deletions(-)
> rename Documentation/{DMA-API-HOWTO.txt => DMA-API-HOWTO.rst} (99%)
> rename Documentation/{DMA-API.txt => DMA-API.rst} (99%)
> rename Documentation/{DMA-ISA-LPC.txt => DMA-ISA-LPC.rst} (98%)
> rename Documentation/{DMA-attributes.txt => DMA-attributes.rst} (99%)
> rename Documentation/{IPMI.txt => IPMI.rst} (99%)
> rename Documentation/{IRQ-affinity.txt => IRQ-affinity.rst} (99%)
> rename Documentation/{IRQ-domain.txt => IRQ-domain.rst} (99%)
> rename Documentation/{IRQ.txt => IRQ.rst} (99%)
> rename Documentation/{Intel-IOMMU.txt => Intel-IOMMU.rst} (99%)
> rename Documentation/{SAK.txt => SAK.rst} (99%)
> rename Documentation/{SM501.txt => SM501.rst} (99%)
> rename Documentation/{atomic_bitops.txt => atomic_bitops.rst} (99%)
> rename Documentation/{bt8xxgpio.txt => bt8xxgpio.rst} (99%)
> rename Documentation/{btmrvl.txt => btmrvl.rst} (99%)
> rename Documentation/{bus-virt-phys-mapping.txt => bus-virt-phys-mapping.rst} (93%)
> rename Documentation/{clearing-warn-once.txt => clearing-warn-once.rst} (96%)
> rename Documentation/{cpu-load.txt => cpu-load.rst} (99%)
> rename Documentation/{cputopology.txt => cputopology.rst} (99%)
> rename Documentation/{crc32.txt => crc32.rst} (99%)
> rename Documentation/{dcdbas.txt => dcdbas.rst} (99%)
> rename Documentation/{debugging-modules.txt => debugging-modules.rst} (98%)
> rename Documentation/{debugging-via-ohci1394.txt => debugging-via-ohci1394.rst} (99%)
> rename Documentation/{dell_rbu.txt => dell_rbu.rst} (99%)
> rename Documentation/{digsig.txt => digsig.rst} (99%)
> rename Documentation/{efi-stub.txt => efi-stub.rst} (99%)
> rename Documentation/{eisa.txt => eisa.rst} (99%)
> rename Documentation/{futex-requeue-pi.txt => futex-requeue-pi.rst} (99%)
> rename Documentation/{gcc-plugins.txt => gcc-plugins.rst} (99%)
> rename Documentation/{highuid.txt => highuid.rst} (99%)
> rename Documentation/{hw_random.txt => hw_random.rst} (99%)
> rename Documentation/{hwspinlock.txt => hwspinlock.rst} (99%)
> rename Documentation/{intel_txt.txt => intel_txt.rst} (99%)
> rename Documentation/{io-mapping.txt => io-mapping.rst} (99%)
> rename Documentation/{io_ordering.txt => io_ordering.rst} (99%)
> rename Documentation/{iostats.txt => iostats.rst} (99%)
> rename Documentation/{irqflags-tracing.txt => irqflags-tracing.rst} (99%)
> rename Documentation/{isa.txt => isa.rst} (99%)
> rename Documentation/{isapnp.txt => isapnp.rst} (98%)
> rename Documentation/{kernel-per-CPU-kthreads.txt => kernel-per-CPU-kthreads.rst} (99%)
> rename Documentation/{kobject.txt => kobject.rst} (99%)
> rename Documentation/{kprobes.txt => kprobes.rst} (99%)
> rename Documentation/{kref.txt => kref.rst} (99%)
> rename Documentation/{ldm.txt => ldm.rst} (98%)
> rename Documentation/{lockup-watchdogs.txt => lockup-watchdogs.rst} (99%)
> rename Documentation/{lsm.txt => lsm.rst} (99%)
> rename Documentation/{lzo.txt => lzo.rst} (99%)
> rename Documentation/{mailbox.txt => mailbox.rst} (99%)
> rename Documentation/{men-chameleon-bus.txt => men-chameleon-bus.rst} (99%)
> rename Documentation/{nommu-mmap.txt => nommu-mmap.rst} (99%)
> rename Documentation/{ntb.txt => ntb.rst} (99%)
> rename Documentation/{numastat.txt => numastat.rst} (99%)
> rename Documentation/{padata.txt => padata.rst} (99%)
> rename Documentation/{parport-lowlevel.txt => parport-lowlevel.rst} (99%)
> rename Documentation/{percpu-rw-semaphore.txt => percpu-rw-semaphore.rst} (99%)
> rename Documentation/{phy.txt => phy.rst} (99%)
> rename Documentation/{pi-futex.txt => pi-futex.rst} (99%)
> rename Documentation/{pnp.txt => pnp.rst} (98%)
> rename Documentation/{preempt-locking.txt => preempt-locking.rst} (99%)
> rename Documentation/{pwm.txt => pwm.rst} (99%)
> rename Documentation/{rbtree.txt => rbtree.rst} (94%)
> rename Documentation/{remoteproc.txt => remoteproc.rst} (99%)
> rename Documentation/{rfkill.txt => rfkill.rst} (99%)
> rename Documentation/{robust-futex-ABI.txt => robust-futex-ABI.rst} (99%)
> rename Documentation/{robust-futexes.txt => robust-futexes.rst} (99%)
> rename Documentation/{rpmsg.txt => rpmsg.rst} (99%)
> rename Documentation/{rtc.txt => rtc.rst} (99%)
> rename Documentation/{sgi-ioc4.txt => sgi-ioc4.rst} (99%)
> rename Documentation/{siphash.txt => siphash.rst} (99%)
> rename Documentation/{smsc_ece1099.txt => smsc_ece1099.rst} (99%)
> rename Documentation/{speculation.txt => speculation.rst} (99%)
> rename Documentation/{static-keys.txt => static-keys.rst} (99%)
> rename Documentation/{svga.txt => svga.rst} (99%)
> rename Documentation/{switchtec.txt => switchtec.rst} (98%)
> rename Documentation/{sync_file.txt => sync_file.rst} (99%)
> rename Documentation/{tee.txt => tee.rst} (99%)
> rename Documentation/{this_cpu_ops.txt => this_cpu_ops.rst} (99%)
> rename Documentation/{unaligned-memory-access.txt => unaligned-memory-access.rst} (99%)
> rename Documentation/{vfio-mediated-device.txt => vfio-mediated-device.rst} (99%)
> rename Documentation/{vfio.txt => vfio.rst} (99%)
> rename Documentation/{video-output.txt => video-output.rst} (99%)
> rename Documentation/{xillybus.txt => xillybus.rst} (99%)
> rename Documentation/{xz.txt => xz.rst} (99%)
> rename Documentation/{zorro.txt => zorro.rst} (99%)
^ permalink raw reply
* Re: [PATCH v2 2/2] rtw88: pci: Use DMA sync instead of remapping in RX ISR
From: Christoph Hellwig @ 2019-07-09 16:15 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, Larry Finger,
David Laight, linux-wireless, netdev, linux-kernel, linux,
Daniel Drake
In-Reply-To: <20190709102059.7036-2-jian-hong@endlessm.com>
On Tue, Jul 09, 2019 at 06:21:01PM +0800, Jian-Hong Pan wrote:
> Since each skb in RX ring is reused instead of new allocation, we can
> treat the DMA in a more efficient way by DMA synchronization.
>
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> ---
> drivers/net/wireless/realtek/rtw88/pci.c | 35 ++++++++++++++++++++++--
> 1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
> index e9fe3ad896c8..28ca76f71dfe 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -206,6 +206,35 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb,
> return 0;
> }
>
> +static int rtw_pci_sync_rx_desc_cpu(struct rtw_dev *rtwdev, dma_addr_t dma)
> +{
> + struct device *dev = rtwdev->dev;
> + int buf_sz = RTK_PCI_RX_BUF_SIZE;
> +
> + dma_sync_single_for_cpu(dev, dma, buf_sz, PCI_DMA_FROMDEVICE);
> +
> + return 0;
> +}
No need to return a value from this helper. In fact I'm not even sure
you need the helper at all. Also please use the DMA_FROM_DEVICE
constant instead of the deprecated PCI variant.
> +static int rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
> + struct rtw_pci_rx_ring *rx_ring,
> + u32 idx, u32 desc_sz)
> +{
> + struct device *dev = rtwdev->dev;
> + struct rtw_pci_rx_buffer_desc *buf_desc;
> + int buf_sz = RTK_PCI_RX_BUF_SIZE;
> +
> + dma_sync_single_for_device(dev, dma, buf_sz, PCI_DMA_FROMDEVICE);
> +
> + buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
> + idx * desc_sz);
> + memset(buf_desc, 0, sizeof(*buf_desc));
> + buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
> + buf_desc->dma = cpu_to_le32(dma);
> +
> + return 0;
> +}
Same comment on the PCI constant and the return value here.
^ permalink raw reply
* Re: [PATCH v3 1/3] nl80211: Update uapi for CMD_FRAME_WAIT_CANCEL
From: Denis Kenzior @ 2019-07-09 15:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <20190701153317.27170-1-denkenz@gmail.com>
ping?
Regards,
-Denis
^ permalink raw reply
* [PATCH v2 2/2] mt76: usb: remove unneeded {put,get}_unaligned
From: Stanislaw Gruszka @ 2019-07-09 15:14 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi
In-Reply-To: <20190709151455.24003-1-sgruszka@redhat.com>
Compiler give us guaranties on variables alignment, so use
an variable as buffer when read/write registers and remove
unneeded {put,get}_unaligned.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 5 ++++-
drivers/net/wireless/mediatek/mt76/usb.c | 8 ++++----
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 56bf93a8988e..094e6e543542 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -389,7 +389,10 @@ enum mt76u_out_ep {
#define MCU_RESP_URB_SIZE 1024
struct mt76_usb {
struct mutex usb_ctrl_mtx;
- u8 data[32];
+ union {
+ u8 data[32];
+ __le32 reg_val;
+ };
struct tasklet_struct rx_tasklet;
struct delayed_work stat_work;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 828939e78a3b..00069c2536f8 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -95,9 +95,9 @@ static u32 __mt76u_rr(struct mt76_dev *dev, u32 addr)
ret = __mt76u_vendor_request(dev, req,
USB_DIR_IN | USB_TYPE_VENDOR,
- 0, offset, usb->data, sizeof(__le32));
+ 0, offset, &usb->reg_val, sizeof(__le32));
if (ret == sizeof(__le32))
- data = get_unaligned_le32(usb->data);
+ data = le32_to_cpu(usb->reg_val);
trace_usb_reg_rr(dev, addr, data);
return data;
@@ -131,10 +131,10 @@ static void __mt76u_wr(struct mt76_dev *dev, u32 addr, u32 val)
}
offset = addr & ~MT_VEND_TYPE_MASK;
- put_unaligned_le32(val, usb->data);
+ usb->reg_val = cpu_to_le32(val);
__mt76u_vendor_request(dev, req,
USB_DIR_OUT | USB_TYPE_VENDOR, 0,
- offset, usb->data, sizeof(__le32));
+ offset, &usb->reg_val, sizeof(__le32));
trace_usb_reg_wr(dev, addr, val);
}
--
2.20.1
^ permalink raw reply related
* [PATCH v2 1/2] mt76: usb: fix endian in mt76u_copy
From: Stanislaw Gruszka @ 2019-07-09 15:14 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi
In-Reply-To: <20190709151455.24003-1-sgruszka@redhat.com>
In contrast to mt76_wr() which we use to program registers,
on mt76_wr_copy() we should not change endian of the data.
Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 5be584ca7497..828939e78a3b 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -165,11 +165,11 @@ static void mt76u_copy(struct mt76_dev *dev, u32 offset,
mutex_lock(&usb->usb_ctrl_mtx);
for (i = 0; i < DIV_ROUND_UP(len, 4); i++) {
- put_unaligned_le32(val[i], usb->data);
+ put_unaligned(val[i], (u32 *) usb->data);
ret = __mt76u_vendor_request(dev, MT_VEND_MULTI_WRITE,
USB_DIR_OUT | USB_TYPE_VENDOR,
0, offset + i * 4, usb->data,
- sizeof(__le32));
+ sizeof(u32));
if (ret < 0)
break;
}
--
2.20.1
^ permalink raw reply related
* [PATCH v2 0/2] mt76: usb: alignment and endianes improvements
From: Stanislaw Gruszka @ 2019-07-09 15:14 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi
Fix endian bug and do some minor optimizations in mt76u_{copy,rr,wr} .
v1 -> v2:
- drop patch 3
- fix pointer size in patch 1
Stanislaw Gruszka (2):
mt76: usb: fix endian in mt76u_copy
mt76: usb: remove unneeded {put,get}_unaligned
drivers/net/wireless/mediatek/mt76/mt76.h | 5 ++++-
drivers/net/wireless/mediatek/mt76/usb.c | 12 ++++++------
2 files changed, 10 insertions(+), 7 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH 3/3] mt76: usb: use full intermediate buffer in mt76u_copy
From: Felix Fietkau @ 2019-07-09 13:45 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: Lorenzo Bianconi
In-Reply-To: <20190709101223.GB3099@redhat.com>
On 2019-07-09 12:12, Stanislaw Gruszka wrote:
> On Tue, Jul 02, 2019 at 05:06:01PM +0200, Stanislaw Gruszka wrote:
>> Instead of use several 4 bytes usb requests, use full 32 bytes buffer
>> to copy data to device. With the change we use less requests and copy
>> exact data size to the device regardless size is multiple of 4 or not.
>
> And this does not work correctly on some usb hosts, request which
> are not multiple of 4 do not ended being written to hardware,
> what results in original problem of having last part of beacon
> corrupted.
>
> I would prefer to drop this set - and I would post 2 patches
> (first patch fixed and third dropped). But since this is now in
> Felix's wireless tree I guess I need to post fixes on top of this
> set?
I haven't sent out a pull request yet, so I can still drop those patches
and apply replacements.
- Felix
^ permalink raw reply
* KASAN: global-out-of-bounds Read in load_next_firmware_from_table
From: syzbot @ 2019-07-09 12:27 UTC (permalink / raw)
To: andreyknvl, davem, gregkh, kvalo, libertas-dev, linux-kernel,
linux-usb, linux-wireless, netdev, syzkaller-bugs, tglx
Hello,
syzbot found the following crash on:
HEAD commit: 7829a896 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=12fd0e9ba00000
kernel config: https://syzkaller.appspot.com/x/.config?x=f6d4561982f71f63
dashboard link: https://syzkaller.appspot.com/bug?extid=98156c174c5a2cad9f8f
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=125f669ba00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=146b806ba00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com
usb 1-1: Direct firmware load for libertas/usb8388_v5.bin failed with error
-2
usb 1-1: Direct firmware load for libertas/usb8388.bin failed with error -2
usb 1-1: Direct firmware load for usb8388.bin failed with error -2
==================================================================
BUG: KASAN: global-out-of-bounds in
load_next_firmware_from_table+0x267/0x2d0
drivers/net/wireless/marvell/libertas/firmware.c:99
Read of size 8 at addr ffffffff860942b8 by task kworker/1:1/21
CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.2.0-rc6+ #13
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events request_firmware_work_func
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x67/0x231 mm/kasan/report.c:188
__kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
kasan_report+0xe/0x20 mm/kasan/common.c:614
load_next_firmware_from_table+0x267/0x2d0
drivers/net/wireless/marvell/libertas/firmware.c:99
helper_firmware_cb+0xdc/0x100
drivers/net/wireless/marvell/libertas/firmware.c:70
request_firmware_work_func+0x126/0x242
drivers/base/firmware_loader/main.c:785
process_one_work+0x905/0x1570 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x30b/0x410 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the variable:
fw_table+0x98/0x5c0
Memory state around the buggy address:
ffffffff86094180: fa fa fa fa 00 04 fa fa fa fa fa fa 00 00 05 fa
ffffffff86094200: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
> ffffffff86094280: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 00
^
ffffffff86094300: 00 00 00 01 fa fa fa fa 00 00 00 00 02 fa fa fa
ffffffff86094380: fa fa fa fa 00 03 fa fa fa fa fa fa 00 00 00 00
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH 4/7] mmc: sdio: Drop powered-on re-init at runtime resume and HW reset
From: Ulf Hansson @ 2019-07-09 12:01 UTC (permalink / raw)
To: Doug Anderson
Cc: Linux MMC List, Adrian Hunter, Brian Norris, Shawn Lin,
Guenter Roeck, Heiko Stuebner, Kalle Valo, Arend Van Spriel,
linux-wireless
In-Reply-To: <CAD=FV=UfHd=_gqEMajABV19Mb=G-tz6VptDQa48g4kUPxo-A6g@mail.gmail.com>
On Mon, 8 Jul 2019 at 23:12, Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Mon, Jul 8, 2019 at 3:54 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Thu, 4 Jul 2019 at 02:02, Doug Anderson <dianders@chromium.org> wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jun 18, 2019 at 8:35 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >
> > > > To use the so called powered-on re-initialization of an SDIO card, the
> > > > power to the card must obviously have stayed on. If not, the initialization
> > > > will simply fail.
> > > >
> > > > In the runtime suspend case, the card is always powered off. Hence, let's
> > > > drop the support for powered-on re-initialization during runtime resume, as
> > > > it doesn't make sense.
> > > >
> > > > Moreover, during a HW reset, the point is to cut the power to the card and
> > > > then do fresh re-initialization. Therefore drop the support for powered-on
> > > > re-initialization during HW reset.
> > > >
> > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > > > ---
> > > > drivers/mmc/core/sdio.c | 8 +-------
> > > > 1 file changed, 1 insertion(+), 7 deletions(-)
> > >
> > > This has been on my list of things to test for a while but I never
> > > quite got to it...
> > >
> > > ...and then, today, I spent time bisecting why the "reset"
> > > functionality of miwfiex is broken on my 4.19 kernel [1]. AKA, this
> > > is broken:
> > >
> > > cd /sys/kernel/debug/mwifiex/mlan0
> > > echo 1 > reset
> > >
> > > I finally bisected the problem and tracked it down to commit
> > > ca8971ca5753 ("mmc: dw_mmc: Prevent runtime PM suspend when SDIO IRQs
> > > are enabled"), which embarrassingly has my Tested-by on it. I guess I
> > > never tested the Marvell reset call. :-/
> > >
> > > I dug a little and found that when the Marvell code did its reset we
> > > ended up getting a call to dw_mci_enable_sdio_irq(enb=0) and never saw
> > > a dw_mci_enable_sdio_irq(enb=1) after. I tracked it down further and
> > > found that specifically it was the call to mmc_signal_sdio_irq() in
> > > mmc_sdio_power_restore() that was making the call. The call stack
> > > shown for the "enb=0" call:
> > >
> > > [<c071a290>] (dw_mci_enable_sdio_irq) from [<c070a960>]
> > > (mmc_sdio_power_restore+0x98/0xc0)
> > > [<c070a960>] (mmc_sdio_power_restore) from [<c070a9b4>]
> > > (mmc_sdio_reset+0x2c/0x30)
> > > [<c070a9b4>] (mmc_signal_sdio_irq) from [<c06ff160>] (mmc_hw_reset+0xbc/0x138)
> > > [<c06ff160>] (mmc_hw_reset) from [<bf1bbad8>]
> > > (mwifiex_sdio_work+0x5d4/0x678 [mwifiex_sdio])
> > > [<bf1bbad8>] (mwifiex_sdio_work [mwifiex_sdio]) from [<c0247cd0>]
> > > (process_one_work+0x290/0x4b4)
> > >
> > > I picked your patch here (which gets rid of the call to
> > > mmc_signal_sdio_irq()) and magically the problem went away because
> > > there is no more call to mmc_signal_sdio_irq().
> > >
> > > I personally don't have lots of history about the whole
> > > "powered_resume" code path. I checked and mmc_card_keep_power() was 0
> > > in my test case of getting called from hw_reset, so the rest of this
> > > patch doesn't affect me at all. This surprised me a little since I
> > > saw "MMC_PM_KEEP_POWER" being set in mwifiex but then I realized that
> > > it was only set for the duration of suspend and then cleared by the
> > > core. ;-)
> > >
> > > I will also say that I don't have any test case or knowledge of how
> > > SDIO runtime suspend/resume is supposed to work since on dw_mmc SDIO
> > > cards are currently not allowed to runtime suspend anyway. ;-)
> > >
> > >
> > > So I guess the result of all that long-winded reply is that for on
> > > rk3288-veyron-jerry:
> > >
> > > Fixes: ca8971ca5753 ("mmc: dw_mmc: Prevent runtime PM suspend when
> > > SDIO IRQs are enabled")
> > > Tested-by: Douglas Anderson <dianders@chromium.org>
> >
> > Thanks a lot for testing and for your detailed feedback. I have
> > amended the patch by adding your tags above.
>
> Sure! I'm going to try to do some detailed testing on the next patch
> too to confirm it's OK, but I have a few other tasks to get to first.
> ;-)
>
>
> > Moreover, we seems to need this for stable as well, but I am leaving
> > that to be managed as a separate task. We may even consider the hole
> > series for stable, but that requires more testing first.
>
> Sure, makes sense. We'll pick it to the Chrome OS 4.19 kernel
> directly but it's usually nice to get fixes like this into stable so
> everyone can benefit.
>
>
> > > One last note is that, though Marvell WiFi works after a reset after
> > > this commit, Marvell Bluetooth (on the same SDIO module) doesn't. I
> > > guess next week it'll be another bisect...
> >
> > Is the Bluetooth connected to the same SDIO interface, thus the
> > Bluetooth driver is an SDIO func driver?
>
> Yes, it's a SDIO func driver connected to the same interface. So far
> I've managed to confirm the problem on:
>
> v4.4 (plus 76ae3e26ea43 mwifiex: add debugfs file for testing reset of card)
> v4.9
> next-20190708
>
> ...so it seems like it's not a "regression", it's just never worked.
> :-P I guess I'll have to see if I can figure out what's different in
> our chromeos-3.14 kernel. Ah, I see. In 3.14 we had this solution:
>
> pr_err("Resetting card...\n");
> mmc_remove_host(reset_host);
> /* 200ms delay is based on experiment with sdhci controller */
> mdelay(200);
> reset_host->rescan_entered = 0;
> mmc_add_host(reset_host);
>
> ...I think that didn't fly upstream. ...but I can confirm that this works fine:
>
> cd /sys/bus/platform/drivers/dwmmc_rockchip
> echo ff0d0000.dwmmc > unbind
> sleep .5
> echo ff0d0000.dwmmc > bind
>
> ...so I guess this boils down to: how does the mwifiex reset code not
> behave like a full removal and re-insertion of the card? Oh, but
> maybe that's obvious. We're doing all the reset / re-init from the
> WiFi side of things (mwifiex_sdio_card_reset_work) but I don't think
> anything is communicated to the Bluetooth side of things. Presumably
> this is just totally broken for everyone? ...or am I confused?
Nope, that is most likely what is happening.
I am not sure what is the best method to deal with this. Perhaps we
should invent some callback the SDIO core code can call, for each
active SDIO func on the particular SDIO card that becomes reset.
Or is there a better way you think?
Kind regards
Uffe
^ 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