1. Mar 17, 2020
    • Manikanta Pubbisetty's avatar
      ath11k: enable PN offload · 1441b2f2
      Manikanta Pubbisetty authored
      
      
      Enabling PN checking in the hardware; hardware checks
      the PN of the received packets and reports the errors
      to the host for further handling; default action is to
      drop such packets. TSC (TKIP sequence counter)
      validation is also offloaded.
      
      Hardware validates PN/TSC only for unicast packets;
      for group addressed packets, PN validation is done
      in mac80211.
      
      PN errors are reported to the driver via WBM RX release
      ring and can be dumped by using the following command.
      
      "cat /sys/kernel/debug/ath11k/soc_rx_stats | grep -i pn"
      
      Sample Output:
      PN check fail: 210
      
      Signed-off-by: default avatarManikanta Pubbisetty <mpubbise@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      1441b2f2
    • Manikanta Pubbisetty's avatar
      ath11k: handle RX fragments · 243874c6
      Manikanta Pubbisetty authored
      
      
      IPQ8074 HW has support to verify the PN of the received frames.
      For all frames except for fragmented ones, HW checks the PN and
      delivers them to the driver. For fragmented frames, driver is
      required to do a little more; it has to reassemble the fragments
      and then reinject them to the HW for verifying the PN. Currently,
      to keep the logic simple, PN verifcation is disabled in HW and is
      handled in mac80211 for all the frames (fragmented and unfragmented).
      
      On the contrary, offloading PN Validation to the HW brings important
      benefits. It reduces CPU cycles spent on the host CPU for verifying
      the same; helps in enabling features which improve performance like
      mac80211 fast RX path, enabling multiple REO rings for parallel RX
      processing, 802.11 decapsulation offloading. All these features are
      dependent on PN offload which in turn is dependent on handling of
      the received fragments in the driver.
      
      When TKIP security is used, additional handling is required while
      processing the fragments; since MIC is computed on an MSDU in TKIP,
      only the last fragment has the MIC info. In this case, driver has to
      compute the MIC after reassembly and compare it against the MIC
      present in the frame. For this, MICHAEL_MIC kernel crypto library
      APIs are used and the dependencies are appropriately set.
      
      Signed-off-by: default avatarManikanta Pubbisetty <mpubbise@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      243874c6
  2. Mar 16, 2020
  3. Mar 12, 2020