1. 27 Jun, 2024 1 commit
  2. 26 Jun, 2024 2 commits
  3. 24 Jun, 2024 8 commits
  4. 19 Jun, 2024 7 commits
  5. 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
  6. 11 Jun, 2024 16 commits
  7. 10 Jun, 2024 2 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