linux-stable.git/drivers/net/ethernet/amd, branch linux-6.2.y

net: amd: Fix link leak when verifying config failed

2023-05-11T14:11:19+00:00

[ Upstream commit d325c34d9e7e38d371c0a299d415e9b07f66a1fb ]

After failing to verify configuration, it returns directly without
releasing link, which may cause memory leak.

Paolo Abeni thinks that the whole code of this driver is quite
"suboptimal" and looks unmainatained since at least ~15y, so he
suggests that we could simply remove the whole driver, please
take it into consideration.

Simon Horman suggests that the fix label should be set to
"Linux-2.6.12-rc2" considering that the problem has existed
since the driver was introduced and the commit above doesn't
seem to exist in net/net-next.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Gan Gecen 
Reviewed-by: Dongliang Mu 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

amd-xgbe: Delay AN timeout during KR training

2023-01-13T05:50:37+00:00

AN restart triggered during KR training not only aborts the KR training
process but also move the HW to unstable state. Driver has to wait upto
500ms or until the KR training is completed before restarting AN cycle.

Fixes: 7c12aa08779c ("amd-xgbe: Move the PHY support into amd-xgbe")
Co-developed-by: Sudheesh Mavila 
Signed-off-by: Sudheesh Mavila 
Signed-off-by: Raju Rangoju 
Acked-by: Shyam Sundar S K 
Signed-off-by: Jakub Kicinski

amd-xgbe: TX Flow Ctrl Registers are h/w ver dependent

2023-01-13T05:50:37+00:00

There is difference in the TX Flow Control registers (TFCR) between the
revisions of the hardware. The older revisions of hardware used to have
single register per queue. Whereas, the newer revision of hardware (from
ver 30H onwards) have one register per priority.

Update the driver to use the TFCR based on the reported version of the
hardware.

Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver")
Co-developed-by: Ajith Nayak 
Signed-off-by: Ajith Nayak 
Signed-off-by: Raju Rangoju 
Acked-by: Shyam Sundar S K 
Signed-off-by: Jakub Kicinski

net: amd-xgbe: add missed tasklet_kill

2022-12-30T07:33:05+00:00

The driver does not call tasklet_kill in several places.
Add the calls to fix it.

Fixes: 85b85c853401 ("amd-xgbe: Re-issue interrupt if interrupt status not cleared")
Signed-off-by: Jiguang Xiao 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2022-12-13T08:49:29+00:00

Merge in the left-over fixes before the net-next pull-request.

net/mptcp/subflow.c
  d3295fee3c75 ("mptcp: use proper req destructor for IPv6")
  36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()")

Signed-off-by: Paolo Abeni

net: amd-xgbe: Check only the minimum speed for active/passive cables

2022-12-12T10:05:36+00:00

There are cables that exist that can support speeds in excess of 10GbE.
The driver, however, restricts the EEPROM advertised nominal bitrate to
a specific range, which can prevent usage of cables that can support,
for example, up to 25GbE.

Rather than checking that an active or passive cable supports a specific
range, only check for a minimum supported speed.

Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
Signed-off-by: Tom Lendacky 
Signed-off-by: David S. Miller

net: amd-xgbe: Fix logic around active and passive cables

2022-12-12T10:05:36+00:00

SFP+ active and passive cables are copper cables with fixed SFP+ end
connectors. Due to a misinterpretation of this, SFP+ active cables could
end up not being recognized, causing the driver to fail to establish a
connection.

Introduce a new enum in SFP+ cable types, XGBE_SFP_CABLE_FIBER, that is
the default cable type, and handle active and passive cables when they are
specifically detected.

Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
Signed-off-by: Tom Lendacky 
Signed-off-by: David S. Miller

net: amd: lance: don't call dev_kfree_skb() under spin_lock_irqsave()

2022-12-12T09:56:17+00:00

It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.

It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
The difference between them is free reason, dev_kfree_skb_irq() means
the SKB is dropped in error and dev_consume_skb_irq() means the SKB
is consumed in normal.

In these two cases, dev_kfree_skb() is called consume the xmited SKB,
so replace it with dev_consume_skb_irq().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang 
Signed-off-by: David S. Miller

ptp: xgbe: convert to .adjfine and adjust_by_scaled_ppm

2022-10-31T11:14:16+00:00

The xgbe implementation of .adjfreq is implemented in terms of a
straight forward "base * ppb / 1 billion" calculation.

Convert this driver to .adjfine and use adjust_by_scaled_ppm to calculate
the new addend value.

Signed-off-by: Jacob Keller 
Acked-by: Richard Cochran 
Acked-by: Tom Lendacky 
Cc: Shyam Sundar S K 
Signed-off-by: David S. Miller

amd-xgbe: add the bit rate quirk for Molex cables

2022-10-22T05:40:22+00:00

The offset 12 (bit-rate) of EEPROM SFP DAC (passive) cables is expected
to be in the range 0x64 to 0x68. However, the 5 meter and 7 meter Molex
passive cables have the rate ceiling 0x78 at offset 12.

Add a quirk for Molex passive cables to extend the rate ceiling to 0x78.

Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
Signed-off-by: Raju Rangoju 
Acked-by: Tom Lendacky 
Signed-off-by: Jakub Kicinski