Re: [RFC PATCH net 2/2] amd-xgbe: Avoid sleeping in napi_disable() while holding a spinlock

On 10/15/19 8:49 AM, James Morse wrote: > xgbe_powerdown() takes an irqsave spinlock, then calls napi_disable() > via xgbe_napi_disable(). napi_disable() might call msleep(). > DEBUG_ATOMIC_SLEEP isn't happy about this: > | BUG: sleeping function called from invalid context at ../net/core/dev.c:633

Re: [RFC PATCH net 1/2] amd-xgbe: Avoid sleeping in flush_workqueue() while holding a spinlock

On 10/15/19 8:49 AM, James Morse wrote: > xgbe_powerdown() takes an irqsave spinlock, then calls flush_workqueue() > which takes a mutex. DEBUG_ATOMIC_SLEEP isn't happy about this: > | BUG: sleeping function called from invalid context at [...] mutex.c:281 > | in_atomic(): 1, irqs_disabled(): 128,

Re: -Wsizeof-array-div warnings in ethernet drivers

On 9/17/19 2:32 AM, Nathan Chancellor wrote: > Hi all, > > Clang recently added a new diagnostic in r371605, -Wsizeof-array-div, > that tries to warn when sizeof(X) / sizeof(Y) does not compute the > number of elements in an array X (i.e., sizeof(Y) is wrong). See that > commit for more details: >

Re: [PATCH 04/17] xgbe: no need to check return value of debugfs_create functions

On 8/6/19 11:11 AM, Greg Kroah-Hartman 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. > > This cleans up a lot of unneeded code and logic around the d

Re: [PATCH net-next 1/3] net: stmmac: Fix NAPI poll in TX path when in multi-queue

On 2/15/19 6:35 PM, Florian Fainelli wrote: > On 2/15/19 5:42 AM, Jose Abreu wrote: >> Commit 8fce33317023 introduced the concept of NAPI per-channel and >> independent cleaning of TX path. >> >> This is currently breaking performance in some cases. The scenario >> happens when all packets are be

Re: [PATCH net-next v2 1/4] net: phy: start state machine in phy_start only

On 1/21/19 12:36 PM, Heiner Kallweit wrote: > On 21.01.2019 17:35, Andrew Lunn wrote: >> On Sun, Jan 20, 2019 at 10:01:15AM +0100, Heiner Kallweit wrote: >>> The state machine is a no-op before phy_start() has been called. >>> Therefore let's enable it in phy_start() only. In phy_start() >>> let's

[PATCH] amd-xgbe: Fix mdio access for non-zero ports and clause 45 PHYs

The XGBE hardware has support for performing MDIO operations using an MDIO command request. The driver mistakenly uses the mdio port address as the MDIO command request device address instead of the MDIO command request port address. Additionally, the driver does not properly check for and create a

Re: [PATCH V2] amd-xgbe: set skb to NULL after freeing it

On 11/28/2018 03:06 AM, Pan Bian wrote: > The buffer skb is freed via dev_kfree_skb in a loop. After freeing skb, > the value of packet_count is updated via packet_count++. If packet_count > happens to equal the upper bound budget, the loop will be broken and skb > may be assigned to rdata->state

RE: amd-xgbe e0700000.xgmac: DMA-API: device driver tries to sync DMA memory it has not allocated

Hi Kim, Actually I took a closer look at the DMA debug code and it's an 8k boundary that is crossed. I've been able to reproduce the issue so I'll see if my fix takes care of it. Thanks, Tom -Original Message- From: Lendacky, Thomas Sent: Thursday, July 02, 2015 3

RE: amd-xgbe e0700000.xgmac: DMA-API: device driver tries to sync DMA memory it has not allocated

02, 2015 2:02 PM To: Lendacky, Thomas Cc: netdev@vger.kernel.org Subject: amd-xgbe e070.xgmac: DMA-API: device driver tries to sync DMA memory it has not allocated Hi Tom, A pristine 4.1 kernel with CONFIG_DMA_API_DEBUG=y produces this call trace on an AMD Seattle: [ 112.896576]