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

net: usb: ax88179_178a: fix link status when link is set to down/up

2024-05-25T14:30:54+00:00

commit ecf848eb934b03959918f5269f64c0e52bc23998 upstream.

The idea was to keep only one reset at initialization stage in order to
reduce the total delay, or the reset from usbnet_probe or the reset from
usbnet_open.

I have seen that restarting from usbnet_probe is necessary to avoid doing
too complex things. But when the link is set to down/up (for example to
configure a different mac address) the link is not correctly recovered
unless a reset is commanded from usbnet_open.

So, detect the initialization stage (first call) to not reset from
usbnet_open after the reset from usbnet_probe and after this stage, always
reset from usbnet_open too (when the link needs to be rechecked).

Apply to all the possible devices, the behavior now is going to be the same.

cc: stable@vger.kernel.org # 6.6+
Fixes: 56f78615bcb1 ("net: usb: ax88179_178a: avoid writing the mac address before first reading")
Reported-by: Isaac Ganoung 
Reported-by: Yongqin Liu 
Signed-off-by: Jose Ignacio Tornos Martinez 
Reviewed-by: Simon Horman 
Link: https://lore.kernel.org/r/20240510090846.328201-1-jtornosm@redhat.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net: ks8851: Fix another TX stall caused by wrong ISR flag handling

2024-05-25T14:30:53+00:00

commit 317a215d493230da361028ea8a4675de334bfa1a upstream.

Under some circumstances it may happen that the ks8851 Ethernet driver
stops sending data.

Currently the interrupt handler resets the interrupt status flags in the
hardware after handling TX. With this approach we may lose interrupts in
the time window between handling the TX interrupt and resetting the TX
interrupt status bit.

When all of the three following conditions are true then transmitting
data stops:

  - TX queue is stopped to wait for room in the hardware TX buffer
  - no queued SKBs in the driver (txq) that wait for being written to hw
  - hardware TX buffer is empty and the last TX interrupt was lost

This is because reenabling the TX queue happens when handling the TX
interrupt status but if the TX status bit has already been cleared then
this interrupt will never come.

With this commit the interrupt status flags will be cleared before they
are handled. That way we stop losing interrupts.

The wrong handling of the ISR flags was there from the beginning but
with commit 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX
buffer overrun") the issue becomes apparent.

Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun")
Cc: "David S. Miller" 
Cc: Eric Dumazet 
Cc: Jakub Kicinski 
Cc: Paolo Abeni 
Cc: Simon Horman 
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org # 5.10+
Signed-off-by: Ronald Wahl 
Reviewed-by: Simon Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

wifi: iwlwifi: Use request_module_nowait

2024-05-25T14:30:53+00:00

commit 3d913719df14c28c4d3819e7e6d150760222bda4 upstream.

This appears to work around a deadlock regression that came in
with the LED merge in 6.9.

The deadlock happens on my system with 24 iwlwifi radios, so maybe
it something like all worker threads are busy and some work that needs
to complete cannot complete.

Link: https://lore.kernel.org/linux-kernel/20240411070718.GD6194@google.com/
Fixes: f5c31bcf604d ("Merge tag 'leds-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds")
Signed-off-by: Ben Greear 
Link: https://msgid.link/20240430234212.2132958-1-greearb@candelatech.com
[also remove unnecessary "load_module" var and now-wrong comment]
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

wifi: mt76: mt7915: add missing chanctx ops

2024-05-17T10:18:09+00:00

commit 2f7cf3b61d85228ae749b6cb8eda1e1df9d4926f upstream.

Looks like this was missed in the initial patch that made
the conversion to the emulated chanctx drivers.

Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Tested-by: James Courtier-Dutton 
Signed-off-by: Ben Greear 
Signed-off-by: Felix Fietkau 
Signed-off-by: Greg Kroah-Hartman

net: dsa: mv88e6xxx: read cmode on mv88e6320/21 serdes only ports

2024-05-09T09:48:20+00:00

On the mv88e6320 and 6321 switch family, port 0/1 are serdes only ports.
Modified the mv88e6352_get_port4_serdes_cmode function to pass a port
number since the register set of the 6352 is equal on the 6320/21.

Signed-off-by: Steffen Bätz 
Reviewed-by: Andrew Lunn 
Reviewed-by: Fabio Estevam 
Link: https://lore.kernel.org/r/20240508072944.54880-3-steffen@innosonix.de
Signed-off-by: Paolo Abeni

net: dsa: mv88e6xxx: add phylink_get_caps for the mv88e6320/21 family

2024-05-09T09:47:49+00:00

As of commit de5c9bf40c45 ("net: phylink: require supported_interfaces to
be filled")
Marvell 88e6320/21 switches fail to be probed:

...
mv88e6085 30be0000.ethernet-1:00: phylink: error: empty supported_interfaces
error creating PHYLINK: -22
...

The problem stems from the use of mv88e6185_phylink_get_caps() to get
the device capabilities.
Since there are serdes only ports 0/1 included, create a new dedicated
phylink_get_caps for the 6320 and 6321 to properly support their
set of capabilities.

Fixes: de5c9bf40c45 ("net: phylink: require supported_interfaces to be filled")
Signed-off-by: Steffen Bätz 
Reviewed-by: Andrew Lunn 
Reviewed-by: Fabio Estevam 
Link: https://lore.kernel.org/r/20240508072944.54880-2-steffen@innosonix.de
Signed-off-by: Paolo Abeni

net: hns3: fix kernel crash when devlink reload during initialization

2024-05-09T08:47:32+00:00

The devlink reload process will access the hardware resources,
but the register operation is done before the hardware is initialized.
So, processing the devlink reload during initialization may lead to kernel
crash.

This patch fixes this by registering the devlink after
hardware initialization.

Fixes: cd6242991d2e ("net: hns3: add support for registering devlink for VF")
Fixes: 93305b77ffcb ("net: hns3: fix kernel crash when devlink reload during pf initialization")
Signed-off-by: Yonglong Liu 
Signed-off-by: Jijie Shao 
Signed-off-by: Paolo Abeni

net: hns3: fix port vlan filter not disabled issue

2024-05-09T08:47:32+00:00

According to hardware limitation, for device support modify
VLAN filter state but not support bypass port VLAN filter,
it should always disable the port VLAN filter. but the driver
enables port VLAN filter when initializing, if there is no
VLAN(except VLAN 0) id added, the driver will disable it
in service task. In most time, it works fine. But there is
a time window before the service task shceduled and net device
being registered. So if user adds VLAN at this time, the driver
will not update the VLAN filter state,  and the port VLAN filter
remains enabled.

To fix the problem, if support modify VLAN filter state but not
support bypass port VLAN filter, set the port vlan filter to "off".

Fixes: 184cd221a863 ("net: hns3: disable port VLAN filter when support function level VLAN filter control")
Fixes: 2ba306627f59 ("net: hns3: add support for modify VLAN filter state")
Signed-off-by: Yonglong Liu 
Signed-off-by: Jijie Shao 
Reviewed-by: Simon Horman 
Signed-off-by: Paolo Abeni

net: hns3: use appropriate barrier function after setting a bit value

2024-05-09T08:47:32+00:00

There is a memory barrier in followed case. When set the port down,
hclgevf_set_timmer will set DOWN in state. Meanwhile, the service task has
different behaviour based on whether the state is DOWN. Thus, to make sure
service task see DOWN, use smp_mb__after_atomic after calling set_bit().

          CPU0                        CPU1
========================== ===================================
hclgevf_set_timer_task()    hclgevf_periodic_service_task()
  set_bit(DOWN,state)         test_bit(DOWN,state)

pf also has this issue.

Fixes: ff200099d271 ("net: hns3: remove unnecessary work in hclgevf_main")
Fixes: 1c6dfe6fc6f7 ("net: hns3: remove mailbox and reset work in hclge_main")
Signed-off-by: Peiyang Wang 
Signed-off-by: Jijie Shao 
Reviewed-by: Simon Horman 
Signed-off-by: Paolo Abeni

net: hns3: release PTP resources if pf initialization failed

2024-05-09T08:47:32+00:00

During the PF initialization process, hclge_update_port_info may return an
error code for some reason. At this point,  the ptp initialization has been
completed. To void memory leaks, the resources that are applied by ptp
should be released. Therefore, when hclge_update_port_info returns an error
code, hclge_ptp_uninit is called to release the corresponding resources.

Fixes: eaf83ae59e18 ("net: hns3: add querying fec ability from firmware")
Signed-off-by: Peiyang Wang 
Signed-off-by: Jijie Shao 
Reviewed-by: Hariprasad Kelam 
Signed-off-by: Paolo Abeni