linux-stable.git/drivers/net, branch v6.2.15

i40e: use int for i40e_status

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

commit 5180ff1364bc26c031b54a68a80aa90ce0028b70 upstream.

To prepare for removal of i40e_status, change the variables
from i40e_status to int. This eases the transition when values
are changed to return standard int error codes over enum i40e_status.

As such changes often also change variable orders, a cleanup
is also applied here to make variables conform to RCT and
some lines are also reformatted where applicable.

Signed-off-by: Jan Sokolowski 
Tested-by: Gurucharan G  (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: Remove string printing for i40e_status

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

commit 5d968af27a166e055bdd5f832f095d809eadb992 upstream.

Remove the i40e_stat_str() function which prints the string
representation of the i40e_status error code. With upcoming changes
moving away from i40e_status, there will be no need for this function

Signed-off-by: Jan Sokolowski 
Tested-by: Gurucharan G  (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: Remove unused i40e status codes

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

commit 9d135352bb5d885a7b21417103423301a40c1b8b upstream.

In an effort to remove i40e status codes and replace them
with standard kernel errornums, unused values of i40e_status_code
were removed.

Signed-off-by: Jan Sokolowski 
Tested-by: Gurucharan G  (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

wifi: rtw89: fix potential race condition between napi_init and napi_enable

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

commit 47515664ecfbde11425dff121f298ae4499425c9 upstream.

A race condition can happen if netdev is registered, but NAPI isn't
initialized yet, and meanwhile user space starts the netdev that will
enable NAPI. Then, it hits BUG_ON():

 kernel BUG at net/core/dev.c:6423!
 invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91
 Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022
 RIP: 0010:napi_enable+0x3f/0x50
 Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ...
 RSP: 0018:ffffada1414f3548 EFLAGS: 00010246
 RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000
 RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0
 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58
 R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001
 FS:  00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0
 PKRU: 55555554
 Call Trace:
  
  rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8]
  rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]
  rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]
  drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]
  ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]
  ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]
  __dev_open+0xe0/0x180
  __dev_change_flags+0x1da/0x250
  dev_change_flags+0x26/0x70
  do_setlink+0x37c/0x12c0
  ? ep_poll_callback+0x246/0x290
  ? __nla_validate_parse+0x61/0xd00
  ? __wake_up_common_lock+0x8f/0xd0

To fix this, follow Jonas' suggestion to switch the order of these
functions and move register netdev to be the last step of PCI probe.
Also, correct the error handling of rtw89_core_register_hw().

Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
Cc: stable@vger.kernel.org
Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Link: https://lore.kernel.org/linux-wireless/CAOiHx=n7EwK2B9CnBR07FVA=sEzFagb8TkS4XC_qBNq8OwcYUg@mail.gmail.com/T/#t
Suggested-by: Jonas Gorski 
Tested-by: Larry Finger
Reviewed-by: Larry Finger
Signed-off-by: Ping-Ke Shih 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230323082839.20474-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman

wifi: rtw88: rtw8821c: Fix rfe_option field width

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

commit 14705f969d98187a1cc2682e0c9bd2e230b8098f upstream.

On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the
vendor driver suggests that the field width of rfe_option is 5 bit,
so rfe_option should be masked with 0x1f.

Without this the rfe_option comparisons with 2 further down the
driver evaluate as false when they should really evaluate as true.
The effect is that 2G channels do not work.

rfe_option is also used as an array index into rtw8821c_rfe_defs[].
rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support,
likely because rfe_option reads as 0x22. As this now becomes 0x2,
rtw8821c_rfe_defs[34] is no longer used and can be removed.

Note that this might not be the whole truth. In the vendor driver
there are indeed places where the unmasked rfe_option value is used.
However, the driver has several places where rfe_option is tested
with the pattern if (rfe_option == 2 || rfe_option == 0x22) or
if (rfe_option == 4 || rfe_option == 0x24), so that rfe_option BIT(5)
has no influence on the code path taken. We therefore mask BIT(5)
out from rfe_option entirely until this assumption is proved wrong
by some chip variant we do not know yet.

Signed-off-by: Sascha Hauer 
Tested-by: Alexandru gagniuc 
Tested-by: Larry Finger 
Tested-by: ValdikSS 
Cc: stable@vger.kernel.org
Reviewed-by: Ping-Ke Shih 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230417140358.2240429-3-s.hauer@pengutronix.de
Signed-off-by: Greg Kroah-Hartman

wifi: rtl8xxxu: RTL8192EU always needs full init

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

commit d46e04ccd40457a0119b76e11ab64a2ad403e138 upstream.

Always run the entire init sequence (rtl8xxxu_init_device()) for
RTL8192EU. It's what the vendor driver does too.

This fixes a bug where the device is unable to connect after
rebooting:

wlp3s0f3u2: send auth to ... (try 1/3)
wlp3s0f3u2: send auth to ... (try 2/3)
wlp3s0f3u2: send auth to ... (try 3/3)
wlp3s0f3u2: authentication with ... timed out

Rebooting leaves the device powered on (partially? at least the
firmware is still running), but not really in a working state.

Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith 
Acked-by: Jes Sorensen 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/4eb111a9-d4c4-37d0-b376-4e202de7153c@gmail.com
Signed-off-by: Greg Kroah-Hartman

nfp: fix incorrect pointer deference when offloading IPsec with bonding

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

commit 63cfd210034c772fad047afa13dd5a4664b0a72e upstream.

There are two pointers in struct xfrm_dev_offload, *dev, *real_dev.
The *dev points whether bonding interface or real interface, if
bonding IPsec offload is used, it points bonding interface; if not,
it points real interface. And *real_dev always points real interface.
So nfp should always use real_dev instead of dev.

Prior to this change the system becomes unresponsive when offloading
IPsec for a device which is a lower device to a bonding device.

Fixes: 859a497fe80c ("nfp: implement xfrm callbacks and expose ipsec offload feature to upper layer")
CC: stable@vger.kernel.org
Signed-off-by: Huanhuan Wang 
Acked-by: Simon Horman 
Signed-off-by: Louis Peens 
Link: https://lore.kernel.org/r/20230420140125.38521-1-louis.peens@corigine.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

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

net: dpaa: Fix uninitialized variable in dpaa_stop()

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

[ Upstream commit 461bb5b97049a149278f2c27a3aa12af16da6a2e ]

The return value is not initialized on the success path.

Fixes: 901bdff2f529 ("net: fman: Change return type of disable to void")
Signed-off-by: Dan Carpenter 
Acked-by: Madalin Bucur 
Reviewed-by: Sean Anderson 
Link: https://lore.kernel.org/r/8c9dc377-8495-495f-a4e5-4d2d0ee12f0c@kili.mountain
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: stmmac:fix system hang when setting up tag_8021q VLAN for DSA ports

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

[ Upstream commit 35226750f7ab9d49140d95bc7d38a2a9b0f4fdfc ]

The system hang because of dsa_tag_8021q_port_setup()->
				stmmac_vlan_rx_add_vid().

I found in stmmac_drv_probe() that cailing pm_runtime_put()
disabled the clock.

First, when the kernel is compiled with CONFIG_PM=y,The stmmac's
resume/suspend is active.

Secondly,stmmac as DSA master,the dsa_tag_8021q_port_setup() function
will callback stmmac_vlan_rx_add_vid when DSA dirver starts. However,
The system is hanged for the stmmac_vlan_rx_add_vid() accesses its
registers after stmmac's clock is closed.

I would suggest adding the pm_runtime_resume_and_get() to the
stmmac_vlan_rx_add_vid().This guarantees that resuming clock output
while in use.

Fixes: b3dcb3127786 ("net: stmmac: correct clocks enabled in stmmac_vlan_rx_kill_vid()")
Reviewed-by: Jacob Keller 
Signed-off-by: Yan Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin