Netdev List
 help / color / mirror / Atom feed
* 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] 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 v3 6/7] net: Rename skb_frag_t size to bv_len
From: Matthew Wilcox @ 2019-07-24 11:41 UTC (permalink / raw)
  To: David Laight; +Cc: davem@davemloft.net, hch@lst.de, netdev@vger.kernel.org
In-Reply-To: <b47b0b19e5594b97af62352dc0dbffcc@AcuMS.aculab.com>

On Wed, Jul 24, 2019 at 10:49:03AM +0000, David Laight wrote:
> This is 'just plain stupid'.
> The 'bv_' prefix of the members of 'struct bvec' is there so that 'grep'
> (etc) can be used to find the uses of the members.
> 
> In a 'struct skb_frag_struct' a sensible prefix might be 'sf_'.
> 
> OTOH it might be sensible to use (or embed) a 'struct bvec'
> instead of 'skb_frag_struct'.

Maybe you should read patch 7/7.  Or 0/7.

^ 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

* [PATCH] Build fixes for skb_frag_size conversion
From: Matthew Wilcox @ 2019-07-24 11:36 UTC (permalink / raw)
  To: netdev, davem; +Cc: Matthew Wilcox (Oracle)

From: "Matthew Wilcox (Oracle)" <willy@infradead.org>

I missed a few places.  One is in some ifdeffed code which will probably
never be re-enabled; the others are in drivers which can't currently be
compiled on x86.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
 drivers/atm/he.c                               | 7 +++----
 drivers/net/ethernet/aeroflex/greth.c          | 2 +-
 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c    | 3 ++-
 drivers/staging/octeon/ethernet-tx.c           | 2 +-
 drivers/target/iscsi/cxgbit/cxgbit_target.c    | 2 +-
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 211607986134..70b00ae4ec38 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -2580,10 +2580,9 @@ he_send(struct atm_vcc *vcc, struct sk_buff *skb)
 			slot = 0;
 		}
 
-		tpd->iovec[slot].addr = dma_map_single(&he_dev->pci_dev->dev,
-			(void *) page_address(frag->page) + frag->page_offset,
-				frag->size, DMA_TO_DEVICE);
-		tpd->iovec[slot].len = frag->size;
+		tpd->iovec[slot].addr = skb_frag_dma_map(&he_dev->pci_dev->dev,
+				frag, 0, skb_frag_size(frag), DMA_TO_DEVICE);
+		tpd->iovec[slot].len = skb_frag_size(frag);
 		++slot;
 
 	}
diff --git a/drivers/net/ethernet/aeroflex/greth.c b/drivers/net/ethernet/aeroflex/greth.c
index 010a2f48aea5..2a9f8643629c 100644
--- a/drivers/net/ethernet/aeroflex/greth.c
+++ b/drivers/net/ethernet/aeroflex/greth.c
@@ -110,7 +110,7 @@ static void greth_print_tx_packet(struct sk_buff *skb)
 
 		print_hex_dump(KERN_DEBUG, "TX: ", DUMP_PREFIX_OFFSET, 16, 1,
 			       skb_frag_address(&skb_shinfo(skb)->frags[i]),
-			       skb_shinfo(skb)->frags[i].size, true);
+			       skb_frag_size(&skb_shinfo(skb)->frags[i]), true);
 	}
 }
 
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index f38c3fa7d705..9c4d1afa34e5 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1958,7 +1958,7 @@ static int skb_to_sg_fd(struct dpaa_priv *priv,
 	/* populate the rest of SGT entries */
 	for (i = 0; i < nr_frags; i++) {
 		frag = &skb_shinfo(skb)->frags[i];
-		frag_len = frag->size;
+		frag_len = skb_frag_size(frag);
 		WARN_ON(!skb_frag_page(frag));
 		addr = skb_frag_dma_map(dev, frag, 0,
 					frag_len, dma_dir);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 00991df44ed6..e529d86468b8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -787,7 +787,8 @@ static inline int mtk_cal_txd_req(struct sk_buff *skb)
 	if (skb_is_gso(skb)) {
 		for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
 			frag = &skb_shinfo(skb)->frags[i];
-			nfrags += DIV_ROUND_UP(frag->size, MTK_TX_DMA_BUF_LEN);
+			nfrags += DIV_ROUND_UP(skb_frag_size(frag),
+						MTK_TX_DMA_BUF_LEN);
 		}
 	} else {
 		nfrags += skb_shinfo(skb)->nr_frags;
diff --git a/drivers/staging/octeon/ethernet-tx.c b/drivers/staging/octeon/ethernet-tx.c
index cc12c78f73f1..46a6fcf1414d 100644
--- a/drivers/staging/octeon/ethernet-tx.c
+++ b/drivers/staging/octeon/ethernet-tx.c
@@ -284,7 +284,7 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device *dev)
 
 			hw_buffer.s.addr =
 				XKPHYS_TO_PHYS((u64)skb_frag_address(fs));
-			hw_buffer.s.size = fs->size;
+			hw_buffer.s.size = skb_drag_size(fs);
 			CVM_OCT_SKB_CB(skb)[i + 1] = hw_buffer.u64;
 		}
 		hw_buffer.s.addr = XKPHYS_TO_PHYS((u64)CVM_OCT_SKB_CB(skb));
diff --git a/drivers/target/iscsi/cxgbit/cxgbit_target.c b/drivers/target/iscsi/cxgbit/cxgbit_target.c
index 93212b9fd310..c25315431ad0 100644
--- a/drivers/target/iscsi/cxgbit/cxgbit_target.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_target.c
@@ -1448,7 +1448,7 @@ cxgbit_lro_skb_merge(struct cxgbit_sock *csk, struct sk_buff *skb, u8 pdu_idx)
 		hpdu_cb->frags++;
 		hpdu_cb->hfrag_idx = hfrag_idx;
 
-		len = skb_frag_size(&hssi->frags[hfrag_idx]);;
+		len = skb_frag_size(&hssi->frags[hfrag_idx]);
 		hskb->len += len;
 		hskb->data_len += len;
 		hskb->truesize += len;
-- 
2.20.1


^ permalink raw reply related

* 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

* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-24 11:34 UTC (permalink / raw)
  To: Jon Hunter, Jose Abreu, Ilias Apalodimas
  Cc: David Miller, robin.murphy@arm.com, lists@bofh.nu,
	Joao.Pinto@synopsys.com, alexandre.torgue@st.com,
	maxime.ripard@bootlin.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com, wens@csie.org,
	mcoquelin.stm32@gmail.com, linux-tegra@vger.kernel.org,
	peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <33de62bf-2f8a-bf00-9260-418b12bed24c@nvidia.com>

From: Jon Hunter <jonathanh@nvidia.com>
Date: Jul/24/2019, 12:10:47 (UTC+00:00)

> 
> On 24/07/2019 11:04, Jose Abreu wrote:
> 
> ...
> 
> > Jon, I was able to replicate (at some level) your setup:
> > 
> > # dmesg | grep -i arm-smmu
> > [    1.337322] arm-smmu 70040000.iommu: probing hardware 
> > configuration...
> > [    1.337330] arm-smmu 70040000.iommu: SMMUv2 with:
> > [    1.337338] arm-smmu 70040000.iommu:         stage 1 translation
> > [    1.337346] arm-smmu 70040000.iommu:         stage 2 translation
> > [    1.337354] arm-smmu 70040000.iommu:         nested translation
> > [    1.337363] arm-smmu 70040000.iommu:         stream matching with 128 
> > register groups
> > [    1.337374] arm-smmu 70040000.iommu:         1 context banks (0 
> > stage-2 only)
> > [    1.337383] arm-smmu 70040000.iommu:         Supported page sizes: 
> > 0x61311000
> > [    1.337393] arm-smmu 70040000.iommu:         Stage-1: 48-bit VA -> 
> > 48-bit IPA
> > [    1.337402] arm-smmu 70040000.iommu:         Stage-2: 48-bit IPA -> 
> > 48-bit PA
> > 
> > # dmesg | grep -i stmmac
> > [    1.344106] stmmaceth 70000000.ethernet: Adding to iommu group 0
> > [    1.344233] stmmaceth 70000000.ethernet: no reset control found
> > [    1.348276] stmmaceth 70000000.ethernet: User ID: 0x10, Synopsys ID: 
> > 0x51
> > [    1.348285] stmmaceth 70000000.ethernet:     DWMAC4/5
> > [    1.348293] stmmaceth 70000000.ethernet: DMA HW capability register 
> > supported
> > [    1.348302] stmmaceth 70000000.ethernet: RX Checksum Offload Engine 
> > supported
> > [    1.348311] stmmaceth 70000000.ethernet: TX Checksum insertion 
> > supported
> > [    1.348320] stmmaceth 70000000.ethernet: TSO supported
> > [    1.348328] stmmaceth 70000000.ethernet: Enable RX Mitigation via HW 
> > Watchdog Timer
> > [    1.348337] stmmaceth 70000000.ethernet: TSO feature enabled
> > [    1.348409] libphy: stmmac: probed
> > [ 4159.140990] stmmaceth 70000000.ethernet eth0: PHY [stmmac-0:01] 
> > driver [Generic PHY]
> > [ 4159.141005] stmmaceth 70000000.ethernet eth0: phy: setting supported 
> > 00,00000000,000062ff advertising 00,00000000,000062ff
> > [ 4159.142359] stmmaceth 70000000.ethernet eth0: No Safety Features 
> > support found
> > [ 4159.142369] stmmaceth 70000000.ethernet eth0: IEEE 1588-2008 Advanced 
> > Timestamp supported
> > [ 4159.142429] stmmaceth 70000000.ethernet eth0: registered PTP clock
> > [ 4159.142439] stmmaceth 70000000.ethernet eth0: configuring for 
> > phy/gmii link mode
> > [ 4159.142452] stmmaceth 70000000.ethernet eth0: phylink_mac_config: 
> > mode=phy/gmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0 
> > an=1
> > [ 4159.142466] stmmaceth 70000000.ethernet eth0: phy link up 
> > gmii/1Gbps/Full
> > [ 4159.142475] stmmaceth 70000000.ethernet eth0: phylink_mac_config: 
> > mode=phy/gmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> > [ 4159.142481] stmmaceth 70000000.ethernet eth0: Link is Up - 1Gbps/Full 
> > - flow control rx/tx
> > 
> > The only missing point is the NFS boot that I can't replicate with this 
> > setup. But I did some sanity checks:
> > 
> > Remote Enpoint:
> > # dd if=/dev/urandom of=output.dat bs=128M count=1
> > # nc -c 192.168.0.2 1234 < output.dat
> > # md5sum output.dat 
> > fde9e0818281836e4fc0edfede2b8762  output.dat
> > 
> > DUT:
> > # nc -l -c -p 1234 > output.dat
> > # md5sum output.dat 
> > fde9e0818281836e4fc0edfede2b8762  output.dat
> 
> On my setup, if I do not use NFS to mount the rootfs, but then manually
> mount the NFS share after booting, I do not see any problems reading or
> writing to files on the share. So I am not sure if it is some sort of
> race that is occurring when mounting the NFS share on boot. It is 100%
> reproducible when using NFS for the root file-system.

I don't understand how can there be corruption then unless the IP AXI 
parameters are misconfigured which can lead to sporadic undefined 
behavior.

These prints from your logs:
[   14.579392] Run /init as init process
/init: line 58: chmod: command not found
[ 10:22:46 ] L4T-INITRD Build DATE: Mon Jul 22 10:22:46 UTC 2019
[ 10:22:46 ] Root device found: nfs
[ 10:22:46 ] Ethernet interfaces: eth0
[ 10:22:46 ] IP Address: 10.21.140.41

Where are they coming from ? Do you have any extra init script ?

---
Thanks,
Jose Miguel Abreu

^ 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 04/10] sfc-falcon: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
  Cc: Solarflare linux maintainers, Edward Cree, Martin Habets,
	David S . Miller, 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/ethernet/sfc/falcon/efx.c           | 6 +++---
 drivers/net/ethernet/sfc/falcon/falcon_boards.c | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/sfc/falcon/efx.c b/drivers/net/ethernet/sfc/falcon/efx.c
index 9b15c39ac670..eecc348b1c32 100644
--- a/drivers/net/ethernet/sfc/falcon/efx.c
+++ b/drivers/net/ethernet/sfc/falcon/efx.c
@@ -2256,7 +2256,7 @@ static struct notifier_block ef4_netdev_notifier = {
 static ssize_t
 show_phy_type(struct device *dev, struct device_attribute *attr, char *buf)
 {
-	struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct ef4_nic *efx = dev_get_drvdata(dev);
 	return sprintf(buf, "%d\n", efx->phy_type);
 }
 static DEVICE_ATTR(phy_type, 0444, show_phy_type, NULL);
@@ -2999,7 +2999,7 @@ static int ef4_pci_probe(struct pci_dev *pci_dev,
 
 static int ef4_pm_freeze(struct device *dev)
 {
-	struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct ef4_nic *efx = dev_get_drvdata(dev);
 
 	rtnl_lock();
 
@@ -3020,7 +3020,7 @@ static int ef4_pm_freeze(struct device *dev)
 static int ef4_pm_thaw(struct device *dev)
 {
 	int rc;
-	struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct ef4_nic *efx = dev_get_drvdata(dev);
 
 	rtnl_lock();
 
diff --git a/drivers/net/ethernet/sfc/falcon/falcon_boards.c b/drivers/net/ethernet/sfc/falcon/falcon_boards.c
index 839189dab98e..2d85d1386ed9 100644
--- a/drivers/net/ethernet/sfc/falcon/falcon_boards.c
+++ b/drivers/net/ethernet/sfc/falcon/falcon_boards.c
@@ -357,7 +357,7 @@ static int sfe4001_poweron(struct ef4_nic *efx)
 static ssize_t show_phy_flash_cfg(struct device *dev,
 				  struct device_attribute *attr, char *buf)
 {
-	struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct ef4_nic *efx = dev_get_drvdata(dev);
 	return sprintf(buf, "%d\n", !!(efx->phy_mode & PHY_MODE_SPECIAL));
 }
 
@@ -365,7 +365,7 @@ static ssize_t set_phy_flash_cfg(struct device *dev,
 				 struct device_attribute *attr,
 				 const char *buf, size_t count)
 {
-	struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct ef4_nic *efx = dev_get_drvdata(dev);
 	enum ef4_phy_mode old_mode, new_mode;
 	int err;
 
-- 
2.20.1


^ permalink raw reply related

* [PATCH net-next 03/10] sfc: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:26 UTC (permalink / raw)
  Cc: Solarflare linux maintainers, Edward Cree, Martin Habets,
	David S . Miller, 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/ethernet/sfc/ef10.c |  4 ++--
 drivers/net/ethernet/sfc/efx.c  | 10 +++++-----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 16d6952c312a..0ec13f520e90 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -508,7 +508,7 @@ static ssize_t efx_ef10_show_link_control_flag(struct device *dev,
 					       struct device_attribute *attr,
 					       char *buf)
 {
-	struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct efx_nic *efx = dev_get_drvdata(dev);
 
 	return sprintf(buf, "%d\n",
 		       ((efx->mcdi->fn_flags) &
@@ -520,7 +520,7 @@ static ssize_t efx_ef10_show_primary_flag(struct device *dev,
 					  struct device_attribute *attr,
 					  char *buf)
 {
-	struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct efx_nic *efx = dev_get_drvdata(dev);
 
 	return sprintf(buf, "%d\n",
 		       ((efx->mcdi->fn_flags) &
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index ab58b837df47..2fef7402233e 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -2517,7 +2517,7 @@ static struct notifier_block efx_netdev_notifier = {
 static ssize_t
 show_phy_type(struct device *dev, struct device_attribute *attr, char *buf)
 {
-	struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct efx_nic *efx = dev_get_drvdata(dev);
 	return sprintf(buf, "%d\n", efx->phy_type);
 }
 static DEVICE_ATTR(phy_type, 0444, show_phy_type, NULL);
@@ -2526,7 +2526,7 @@ static DEVICE_ATTR(phy_type, 0444, show_phy_type, NULL);
 static ssize_t show_mcdi_log(struct device *dev, struct device_attribute *attr,
 			     char *buf)
 {
-	struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct efx_nic *efx = dev_get_drvdata(dev);
 	struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
 
 	return scnprintf(buf, PAGE_SIZE, "%d\n", mcdi->logging_enabled);
@@ -2534,7 +2534,7 @@ static ssize_t show_mcdi_log(struct device *dev, struct device_attribute *attr,
 static ssize_t set_mcdi_log(struct device *dev, struct device_attribute *attr,
 			    const char *buf, size_t count)
 {
-	struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct efx_nic *efx = dev_get_drvdata(dev);
 	struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
 	bool enable = count > 0 && *buf != '0';
 
@@ -3654,7 +3654,7 @@ static int efx_pci_sriov_configure(struct pci_dev *dev, int num_vfs)
 
 static int efx_pm_freeze(struct device *dev)
 {
-	struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct efx_nic *efx = dev_get_drvdata(dev);
 
 	rtnl_lock();
 
@@ -3675,7 +3675,7 @@ static int efx_pm_freeze(struct device *dev)
 static int efx_pm_thaw(struct device *dev)
 {
 	int rc;
-	struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+	struct efx_nic *efx = dev_get_drvdata(dev);
 
 	rtnl_lock();
 
-- 
2.20.1


^ permalink raw reply related

* [PATCH net-next 02/10] forcedeth: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:26 UTC (permalink / raw)
  Cc: David S . Miller, 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/ethernet/nvidia/forcedeth.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index b327b29f5d57..ecca794c55e2 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -6126,8 +6126,7 @@ static void nv_remove(struct pci_dev *pci_dev)
 #ifdef CONFIG_PM_SLEEP
 static int nv_suspend(struct device *device)
 {
-	struct pci_dev *pdev = to_pci_dev(device);
-	struct net_device *dev = pci_get_drvdata(pdev);
+	struct net_device *dev = dev_get_drvdata(device);
 	struct fe_priv *np = netdev_priv(dev);
 	u8 __iomem *base = get_hwbase(dev);
 	int i;
-- 
2.20.1


^ permalink raw reply related

* [PATCH net-next 01/10] net: marvell: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:26 UTC (permalink / raw)
  Cc: Mirko Lindner, Stephen Hemminger, David S . Miller, 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/ethernet/marvell/skge.c | 6 ++----
 drivers/net/ethernet/marvell/sky2.c | 3 +--
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 9ac854c2b371..06dffee81e02 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -4078,8 +4078,7 @@ static void skge_remove(struct pci_dev *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int skge_suspend(struct device *dev)
 {
-	struct pci_dev *pdev = to_pci_dev(dev);
-	struct skge_hw *hw  = pci_get_drvdata(pdev);
+	struct skge_hw *hw  = dev_get_drvdata(dev);
 	int i;
 
 	if (!hw)
@@ -4103,8 +4102,7 @@ static int skge_suspend(struct device *dev)
 
 static int skge_resume(struct device *dev)
 {
-	struct pci_dev *pdev = to_pci_dev(dev);
-	struct skge_hw *hw  = pci_get_drvdata(pdev);
+	struct skge_hw *hw  = dev_get_drvdata(dev);
 	int i, err;
 
 	if (!hw)
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c
index f518312ffe69..762fe0821923 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -5160,8 +5160,7 @@ static void sky2_remove(struct pci_dev *pdev)
 
 static int sky2_suspend(struct device *dev)
 {
-	struct pci_dev *pdev = to_pci_dev(dev);
-	struct sky2_hw *hw = pci_get_drvdata(pdev);
+	struct sky2_hw *hw = dev_get_drvdata(dev);
 	int i;
 
 	if (!hw)
-- 
2.20.1


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox