linux-stable.git/drivers/net/ethernet/broadcom, branch v5.5

net: bcmgenet: Use netif_tx_napi_add() for TX NAPI

2020-01-25T09:31:28+00:00

Before commit 7587935cfa11 ("net: bcmgenet: move NAPI initialization to
ring initialization") moved the code, this used to be
netif_tx_napi_add(), but we lost that small semantic change in the
process, restore that.

Fixes: 7587935cfa11 ("net: bcmgenet: move NAPI initialization to ring initialization")
Signed-off-by: Florian Fainelli 
Acked-by: Doug Berger 
Signed-off-by: David S. Miller

bnxt_en: Do not treat DSN (Digital Serial Number) read failure as fatal.

2020-01-18T13:38:29+00:00

DSN read can fail, for example on a kdump kernel without PCIe extended
config space support.  If DSN read fails, don't set the
BNXT_FLAG_DSN_VALID flag and continue loading.  Check the flag
to see if the stored DSN is valid before using it.  Only VF reps
creation should fail without valid DSN.

Fixes: 03213a996531 ("bnxt: move bp->switch_id initialization to PF probe")
Reported-by: Marc Smith 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller

bnxt_en: Fix ipv6 RFS filter matching logic.

2020-01-18T13:38:29+00:00

Fix bnxt_fltr_match() to match ipv6 source and destination addresses.
The function currently only checks ipv4 addresses and will not work
corrently on ipv6 filters.

Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller

bnxt_en: Fix NTUPLE firmware command failures.

2020-01-18T13:38:29+00:00

The NTUPLE related firmware commands are sent to the wrong firmware
channel, causing all these commands to fail on new firmware that
supports the new firmware channel.  Fix it by excluding the 3
NTUPLE firmware commands from the list for the new firmware channel.

Fixes: 760b6d33410c ("bnxt_en: Add support for 2nd firmware message channel.")
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller

net: systemport: Fixed queue mapping in internal ring map

2020-01-17T12:31:14+00:00

We would not be transmitting using the correct SYSTEMPORT transmit queue
during ndo_select_queue() which looks up the internal TX ring map
because while establishing the mapping we would be off by 4, so for
instance, when we populate switch port mappings we would be doing:

switch port 0, queue 0 -> ring index #0
switch port 0, queue 1 -> ring index #1
...
switch port 0, queue 3 -> ring index #3
switch port 1, queue 0 -> ring index #8 (4 + 4 * 1)
...

instead of using ring index #4. This would cause our ndo_select_queue()
to use the fallback queue mechanism which would pick up an incorrect
ring for that switch port. Fix this by using the correct switch queue
number instead of SYSTEMPORT queue number.

Fixes: 25c440704661 ("net: systemport: Simplify queue mapping logic")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller

drivers/net/b44: Change to non-atomic bit operations on pwol_mask

2020-01-05T22:21:23+00:00

Atomic operations that span cache lines are super-expensive on x86
(not just to the current processor, but also to other processes as all
memory operations are blocked until the operation completes). Upcoming
x86 processors have a switch to cause such operations to generate a #AC
trap. It is expected that some real time systems will enable this mode
in BIOS.

In preparation for this, it is necessary to fix code that may execute
atomic instructions with operands that cross cachelines because the #AC
trap will crash the kernel.

Since "pwol_mask" is local and never exposed to concurrency, there is
no need to set bits in pwol_mask using atomic operations.

Directly operate on the byte which contains the bit instead of using
__set_bit() to avoid any big endian concern due to type cast to
unsigned long in __set_bit().

Suggested-by: Peter Zijlstra 
Signed-off-by: Fenghua Yu 
Signed-off-by: Tony Luck 
Signed-off-by: David S. Miller

bnx2x: Fix accounting of vlan resources among the PFs

2019-12-26T23:27:14+00:00

While testing max vlan configuration on the PF, firmware gets
assert as driver was configuring number of vlans more than what
is supported per port/engine, it was figured out that there is an
implicit vlan (hidden default vlan consuming hardware cam entry resource)
which is configured default for all the clients (PF/VFs) on client_init
ramrod by the adapter implicitly, so when allocating resources among the
PFs this implicit vlan should be considered or total vlan entries should
be reduced by one to accommodate that default/implicit vlan entry.

Signed-off-by: Manish Chopra 
Signed-off-by: Ariel Elior 
Signed-off-by: David S. Miller

bnx2x: Use appropriate define for vlan credit

2019-12-26T23:27:14+00:00

Although it has same value as MAX_MAC_CREDIT_E2,
use MAX_VLAN_CREDIT_E2 appropriately.

Signed-off-by: Manish Chopra 
Signed-off-by: Ariel Elior 
Signed-off-by: David S. Miller

bnx2x: Fix logic to get total no. of PFs per engine

2019-12-14T20:59:16+00:00

Driver doesn't calculate total number of PFs configured on a
given engine correctly which messed up resources in the PFs
loaded on that engine, leading driver to exceed configuration
of resources (like vlan filters etc.) beyond the limit per
engine, which ended up with asserts from the firmware.

Signed-off-by: Manish Chopra 
Signed-off-by: Ariel Elior 
Signed-off-by: Jakub Kicinski

bnx2x: Do not handle requests from VFs after parity

2019-12-14T20:59:16+00:00

Parity error from the hardware will cause PF to lose the state
of their VFs due to PF's internal reload and hardware reset following
the parity error. Restrict any configuration request from the VFs after
the parity as it could cause unexpected hardware behavior, only way
for VFs to recover would be to trigger FLR on VFs and reload them.

Signed-off-by: Manish Chopra 
Signed-off-by: Ariel Elior 
Signed-off-by: Jakub Kicinski