Skip to content

L
linux
Switch branch/tag
  1. 26 Jun, 2024 2 commits
  3. 24 Jun, 2024 8 commits
  5. 19 Jun, 2024 7 commits
  7. 17 Jun, 2024 4 commits
    • Harshitha Prem's avatar
      wifi: ath12k: Remove unused ath12k_base from ath12k_hw · 4f15b06e
      Harshitha Prem authored 
      Currently, device (ab) reference in hardware abstraction (ah)
is not used anywhere. Also, with multiple device group abstraction,
hardware abstraction would be coupled with device group abstraction
rather than single device.

Hence, remove the ab reference from hardware abstraction.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Signed-off-by: default avatarHarshitha Prem <quic_hprem@quicinc.com>
Acked-by: default avatarJeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240529060939.4156281-1-quic_hprem@quicinc.com
      4f15b06e
    • Aaradhana Sahu's avatar
      wifi: ath12k: Fix WARN_ON during firmware crash in split-phy · 670d4949
      Aaradhana Sahu authored 
      Whenever firmware is crashed in split-phy below WARN_ON() triggered:

WARNING: CPU: 3 PID: 82 at net/mac80211/driver-ops.c:41 drv_stop+0xac/0xbc
Modules linked in: ath12k qmi_helpers
CPU: 3 PID: 82 Comm: kworker/3:2 Tainted: G      D W          6.9.0-next-20240520-00113-gd981a3784e15 #39
Hardware name: Qualcomm Technologies, Inc. IPQ9574/AP-AL02-C9 (DT)
Workqueue: events_freezable ieee80211_restart_work
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drv_stop+0xac/0xbc
lr : ieee80211_stop_device+0x54/0x64
sp : ffff8000848dbb20
x29: ffff8000848dbb20 x28: 0000000000000790 x27: ffff000014d78900
x26: ffff000014d791f8 x25: ffff000007f0d9b0 x24: 0000000000000018
x23: 0000000000000001 x22: 0000000000000000 x21: ffff000014d78e10
x20: ffff800081dc0000 x19: ffff000014d78900 x18: ffffffffffffffff
x17: ffff7fffbca84000 x16: ffff800083fe0000 x15: ffff800081dc0b48
x14: 0000000000000076 x13: 0000000000000076 x12: 0000000000000001
x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff8000848db980
x8 : ffff000000dddfc0 x7 : 0000000000000400 x6 : ffff800083b012d8
x5 : ffff800083b012d8 x4 : 0000000000000000 x3 : ffff000014d78398
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000014d78900
Call trace:
 drv_stop+0xac/0xbc
 ieee80211_stop_device+0x54/0x64
 ieee80211_do_stop+0x5a0/0x790
 ieee80211_stop+0x4c/0x178
 __dev_close_many+0xb0/0x150
 dev_close_many+0x88/0x130
 dev_close.part.171+0x44/0x74
 dev_close+0x1c/0x28
 cfg80211_shutdown_all_interfaces+0x44/0xfc
 ieee80211_restart_work+0xfc/0x14c
 process_scheduled_works+0x18c/0x2dc
 worker_thread+0x13c/0x314
 kthread+0x118/0x124
 ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---

The warning in question is from drv_stop():

	if (WARN_ON(!local->started))
		return;

The sequence of WARN_ON() is:
Thread 1:
-Firmware crash calls ath12k_core_reset().
-Call ieee80211_restart_hw() inside
 ath12k_core_post_reconfigure_recovery() which schedules worker
 for both hardware.
-Wait for completion of ab->recovery_start.

Thread 2 (worker thread):
-One hardware acquires rtnl_lock() inside ieee80211_restart_hw() and
 calls ath12k_mac_wait_reconfigure() into ath12k_mac_op_start().
-Hardware is waiting for ab->reconfigure_complete but at this time
 recovery_start_count value is 1 because another worker thread
 (local->restart_work) is still waiting for rtnl_lock().
 recovery_start_count is not equal to number of radios
 (2 in split-phy). So ab->recovery_start complete does not set
 due to this, thread 1 is still waiting and not able to perform
 hif power down up and firmware reload.
-Wait timeout happens for ab->reconfigure_complete and comeback
 to caller (ath12k_mac_op_start()) and sends WMI command to
 crashed firmware and gets error.
-This returns error to drv_start() and local->started is set to false.
-Hardware calls cfg80211_shutdown_all_interfaces() after receiving error
 inside ieee80211_restart_work() and goes to drv_stop(), here we trigger
 WARN_ON as local->started is false.

To fix this issue call ieee80211_restart_hw() after firmware has been
reloaded. Now, each hardware can send WMI command to firmware
successfully. With this fix we don't need to wait for
ab->recovery_start completion so remove
ath12k_mac_wait_reconfigure().

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 HW2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Signed-off-by: default avatarAaradhana Sahu <quic_aarasahu@quicinc.com>
Acked-by: default avatarJeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240529034405.2863150-1-quic_aarasahu@quicinc.com
      670d4949
    • Bartosz Golaszewski's avatar
      dt-bindings: net: wireless: describe the ath12k PCI module · aa17d384
      Bartosz Golaszewski authored 
      Add device-tree bindings for the ATH12K module found in the WCN7850
package.
Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240605122106.23818-3-brgl@bgdev.pl
      aa17d384
    • Bartosz Golaszewski's avatar
      dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390 · 71839a92
      Bartosz Golaszewski authored 
      Add a PCI compatible for the ATH11K module on QCA6390 and describe the
power inputs from the PMU that it consumes.
Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240605122106.23818-2-brgl@bgdev.pl
      71839a92
  9. 11 Jun, 2024 16 commits
  11. 10 Jun, 2024 3 commits
    • David S. Miller's avatar
      Merge branch 'fix-changing-dsa-conduit' · 2ba6d157
      David S. Miller authored 
      Marek Behún says:

====================
Fix changing DSA conduit

This series fixes an issue in the DSA code related to host interface UC
address installed into port FDB and port conduit address database when
live-changing port conduit.

The first patch refactores/deduplicates the installation/uninstallation
of the interface's MAC address and the second patch fixes the issue.

Cover letter for v1 and v2:
  https://patchwork.kernel.org/project/netdevbpf/cover/20240429163627.16031-1-kabel@kernel.org/
  https://patchwork.kernel.org/project/netdevbpf/cover/20240502122922.28139-1-kabel@kernel.org/
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ba6d157
    • Marek Behún's avatar
      net: dsa: update the unicast MAC address when changing conduit · eef8e906
      Marek Behún authored 
      When changing DSA user interface conduit while the user interface is up,
DSA exhibits different behavior in comparison to when the interface is
down. This different behavior concerns the primary unicast MAC address
stored in the port standalone FDB and in the conduit device UC database.

If we put a switch port down while changing the conduit with
  ip link set sw0p0 down
  ip link set sw0p0 type dsa conduit conduit1
  ip link set sw0p0 up
we delete the address in dsa_user_close() and install the (possibly
different) address in dsa_user_open().

But when changing the conduit on the fly, the old address is not
deleted and the new one is not installed.

Since we explicitly want to support live-changing the conduit, uninstall
the old address before calling dsa_port_assign_conduit() and install the
(possibly different) new address after the call.

Because conduit change might also trigger address change (the user
interface is supposed to inherit the conduit interface MAC address if no
address is defined in hardware (dp->mac is a zero address)), move the
eth_hw_addr_inherit() call from dsa_user_change_conduit() to
dsa_port_change_conduit(), just before installing the new address.

Although this is in theory a flaw in DSA core, it needs not be
backported, since there is currently no DSA driver that can be affected
by this. The only DSA driver that supports changing conduit is felix,
and, as explained by Vladimir Oltean [1]:

  There are 2 reasons why with felix the bug does not manifest itself.

  First is because both the 'ocelot' and the alternate 'ocelot-8021q'
  tagging protocols have the 'promisc_on_conduit = true' flag. So the
  unicast address doesn't have to be in the conduit's RX filter -
  neither the old or the new conduit.

  Second, dsa_user_host_uc_install() theoretically leaves behind host
  FDB entries installed towards the wrong (old) CPU port. But in
  felix_fdb_add(), we treat any FDB entry requested towards any CPU port
  as if it was a multicast FDB entry programmed towards _all_ CPU ports.
  For that reason, it is installed towards the port mask of the PGID_CPU
  port group ID:

	if (dsa_port_is_cpu(dp))
		port = PGID_CPU;

Therefore no Fixes tag for this change.

[1] https://lore.kernel.org/netdev/20240507201827.47suw4fwcjrbungy@skbuf/Signed-off-by: default avatarMarek Behún <kabel@kernel.org>
Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
Tested-by: default avatarVladimir Oltean <olteanv@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eef8e906
    • Marek Behún's avatar
      net: dsa: deduplicate code adding / deleting the port address to fdb · 77f75412
      Marek Behún authored 
      The sequence
  if (dsa_switch_supports_uc_filtering(ds))
    dsa_port_standalone_host_fdb_add(dp, addr, 0);
  if (!ether_addr_equal(addr, conduit->dev_addr))
    dev_uc_add(conduit, addr);
is executed both in dsa_user_open() and dsa_user_set_mac_addr().

Its reverse is executed both in dsa_user_close() and
dsa_user_set_mac_addr().

Refactor these sequences into new functions dsa_user_host_uc_install()
and dsa_user_host_uc_uninstall().
Signed-off-by: default avatarMarek Behún <kabel@kernel.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      77f75412
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7