1. 12 Feb, 2019 2 commits
  2. 11 Feb, 2019 9 commits
    • Rakesh Pillai's avatar
      ath10k: fix shadow register implementation for WCN3990 · 18630083
      Rakesh Pillai authored
      WCN3990 supports shadow registers write operation support
      for copy engine for regular operation in powersave mode.
      
      Since WCN3990 is a 64-bit target, the shadow register
      implementation needs to be done in the copy engine handlers
      for 64-bit target. Currently the shadow register implementation
      is present in the 32-bit target handlers of copy engine.
      
      Fix the shadow register copy engine write operation
      implementation for 64-bit target(WCN3990).
      
      Tested HW: WCN3990
      Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
      
      Fixes: b7ba83f7 ("ath10k: add support for shadow register for WNC3990")
      Signed-off-by: default avatarRakesh Pillai <pillair@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      18630083
    • Rakesh Pillai's avatar
      ath10k: enable Factory Test Mode for WCN3990 · 3c545a25
      Rakesh Pillai authored
      The support to put WCN3990 firmware into Factory
      test mode is not present currently. The WCN3990
      firmware can operate in Factory test mode based
      on the mode it receives in the wlan enable message
      from the host driver.
      
      When the host driver is started in testmode send
      the operating mode as UTF mode, to the WCN3990
      firmware, in the wlan enable message to start the
      firmware in Factory test mode.
      
      Tested on: WCN3990
      Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
      Signed-off-by: default avatarRakesh Pillai <pillair@codeaurora.org>
      Reviewed-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      3c545a25
    • Brian Norris's avatar
      ath10k: pci: use mutex for diagnostic window CE polling · 25733c4e
      Brian Norris authored
      The DIAG copy engine is only used via polling, but it holds a spinlock
      with softirqs disabled. Each iteration of our read/write loops can
      theoretically take 20ms (two 10ms timeout loops), and this loop can be
      run an unbounded number of times while holding the spinlock -- dependent
      on the request size given by the caller.
      
      As of commit 39501ea6 ("ath10k: download firmware via diag Copy
      Engine for QCA6174 and QCA9377."), we transfer large chunks of firmware
      memory using this mechanism. With large enough firmware segments, this
      becomes an exceedingly long period for disabling soft IRQs. For example,
      with a 500KiB firmware segment, in testing QCA6174A, I see 200 loop
      iterations of about 50-100us each, which can total about 10-20ms.
      
      In reality, we don't really need to block softirqs for this duration.
      The DIAG CE is only used in polling mode, and we only need to hold
      ce_lock to make sure any CE bookkeeping is done without screwing up
      another CE. Otherwise, we only need to ensure exclusion between
      ath10k_pci_diag_{read,write}_mem() contexts.
      
      This patch moves to use fine-grained locking for the shared ce_lock,
      while adding a new mutex just to ensure mutual exclusion of diag
      read/write operations.
      
      Tested on QCA6174A, firmware version WLAN.RM.4.4.1-00132-QCARMSWPZ-1.
      
      Fixes: 39501ea6 ("ath10k: download firmware via diag Copy Engine for QCA6174 and QCA9377.")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      25733c4e
    • Govind Singh's avatar
      ath10k: request credit report if flow control enabled on ep · c40e448e
      Govind Singh authored
      FW credit flow control is enabled for only WMI ctrl
      service(CE3) but credit update is requested unconditionally
      on all HTC services as part of HTC tx in CE3/CE0/CE4.
      
      This is causing WOW failure as FW is not expecting credit
      report request on other end-points(CE0/CE4).
      
      Request credit report only on those endpoints where
      credit flow control is enabled.
      
      Testing:
          Tested on WCN3990 HW.
          Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
      Signed-off-by: default avatarGovind Singh <govinds@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      c40e448e
    • Govind Singh's avatar
      ath10k: disable interface pause wow config for integrated chipset · de8781d7
      Govind Singh authored
      wow pause iface config controls the PCI D0/D3-WOW cases for pcie
      bus state. Firmware does not expects WOW_IFACE_PAUSE_ENABLED config
      for bus/link that cannot be suspended ex:snoc and does not trigger
      common subsystem shutdown.
      Disable interface pause wow config for integrated chipset(WCN3990)
      for correct WOW configuration in the firmware.
      
      Testing:
          Tested on WCN3990 HW.
          Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
      Signed-off-by: default avatarGovind Singh <govinds@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      de8781d7
    • Govind Singh's avatar
      ath10k: enable bus layer suspend/resume for WCN3990 · 185be1c6
      Govind Singh authored
      Register snoc bus layer suspend/resume PM ops and configure
      the wakeup source(CE2) for the device.
      
      Testing:
          Tested on WCN3990 HW.
          Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
      Signed-off-by: default avatarGovind Singh <govinds@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      185be1c6
    • Christian Lamparter's avatar
      ath10k: implement set_base_macaddr to fix rx-bssid mask in multiple APs conf · 05e7ba24
      Christian Lamparter authored
      Many integrated QCA9984 WiFis in various IPQ806x platform routers
      from various vendors (Netgear R7800, ZyXEL NBG6817, TP-LINK C2600,
      etc.) have either blank, bogus or non-unique MAC-addresses in
      their calibration data.
      
      As a result, OpenWrt utilizes a discouraged binary calibration data
      patching method that allows to modify the device's MAC-addresses right
      at the source. This is because the ath10k' firmware extracts the MAC
      address from the supplied radio/calibration data and issues a response
      to the ath10k linux driver. Which was designed to take the main MAC in
      ath10k_wmi_event_ready().
      
      Part of the "setting an alternate MAC" issue was already tackled by a
      patch from Brian Norris:
      commit 9d580466
      ("ath10k: retrieve MAC address from system firmware if provided")
      by allowing the option to specify an alternate MAC-address with the
      established device_get_mac_address() function which extracts the right
      address from DeviceTree/fwnode mac-address or local-mac-address
      properties and saves it for later.
      
      However, Ben Greear noted that the Qualcomm's ath10k firmware is liable
      to not properly calculate its rx-bssid mask in this case. This can cause
      issues in the popluar "multiple AP with a single ath10k instance"
      configurations.
      
      To improve MAC address handling, Felix Fietkau suggested to call
      pdev_set_base_macaddr_cmdid before bringing up the first vif and
      use the first vif MAC address there. Which is in ath10k_core_start().
      
      This patch implement Felix Fietkau's request to
      "call pdev_set_base_macaddr_cmdid before bringing up the first vif".
      The pdev_set_base_macaddr_cmdid is already declared for all devices
      and version. The driver just needed the support code for this
      function.
      
      Tested on:
      QCA9880/CUS223, firmwares: 10.2.4.13-2, 10.2.4.70.44, 10.2.4-1.0-00041
      QCA9887/MR33 firmware:10.2.4-1.0-00033
      QCA4019/RT-AC58U firmware: 10.4-3.4-00104, 10.4-3.5.3-00057
      QCA9984/R7800 firmware: Candela Technologies (CT) Firmware
      
      BugLink: https://lists.openwrt.org/pipermail/openwrt-devel/2018-November/014595.html
      Fixes: 9d580466 ("ath10k: retrieve MAC address from system firmware if provided")
      Cc: Brian Norris <briannorris@chromium.org>
      Cc: Ben Greear <greearb@candelatech.com>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Mathias Kresin <dev@kresin.me>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Tested-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      05e7ba24
    • Abhishek Ambure's avatar
      ath10k: update GCMP & GCMP-256 cipher suite number for WCN3990 · 7d94f862
      Abhishek Ambure authored
      TLV based firmware ex. QCA6174, WCN3990 expects key cipher value
      set to 9 while non-TLV firmware expects key cipher value set to 8
      for enabling GCMP and GCMP-256 cipher suites.
      
      To fix this problem, attach the key cipher suite values based on
      wmi version.
      
      Tested HW: WCN3990
      Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
      Signed-off-by: default avatarAbhishek Ambure <aambure@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      7d94f862
    • Abhishek Ambure's avatar
      ath10k: assign 'n_cipher_suites = 11' for WCN3990 to enable WPA3 · 7ba31e6e
      Abhishek Ambure authored
      Hostapd uses CCMP, GCMP & GCMP-256 as 'wpa_pairwise' option to run WPA3.
      In WCN3990 firmware cipher suite numbers 9 to 11 are for CCMP,
      GCMP & GCMP-256.
      
      To enable CCMP, GCMP & GCMP-256 cipher suites in WCN3990 firmware,
      host sets 'n_cipher_suites = 11' while initializing hardware parameters.
      
      Tested HW: WCN3990
      Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
      Signed-off-by: default avatarAbhishek Ambure <aambure@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      7ba31e6e
  3. 08 Feb, 2019 2 commits
  4. 07 Feb, 2019 23 commits
  5. 06 Feb, 2019 4 commits
    • David S. Miller's avatar
      Merge branch 'mlxsw-blackhole-routes' · 907bea9c
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Offload blackhole routes
      
      Blackhole routes are routes that cause matching packets to be silently
      dropped. This is in contrast to unreachable routes that generate an ICMP
      host unreachable packet in response.
      
      The driver currently programs both route types with a trap action and
      lets the kernel drop matching packets. This is sub-optimal as packets
      routed using a blackhole route can be directly dropped by the ASIC.
      
      Patch #1 alters mlxsw to program blackhole routes with a discard action.
      
      Patch #2 adds a matching test.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      907bea9c
    • Ido Schimmel's avatar
      selftests: mlxsw: Add a test for blackhole routes · a98232a1
      Ido Schimmel authored
      Use a simple topology consisting of two hosts directly connected to a
      router. Make sure IPv4/IPv6 ping works and then add blackhole routes.
      Test that ping fails and that the routes are marked as offloaded. Use a
      simple tc filter to test that packets were dropped by the ASIC and not
      trapped to the CPU.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a98232a1
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Offload blackhole routes · 2810c3b2
      Ido Schimmel authored
      Create a new FIB entry type for blackhole routes and set it in case the
      type of the notified route is 'RTN_BLACKHOLE'.
      
      Program such routes with a discard action and mark them as offloaded
      since the device is dropping the packets instead of the kernel.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2810c3b2
    • David S. Miller's avatar
      Merge branch 'net-Introduce-ndo_get_port_parent_id' · 554c88ac
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      net: Introduce ndo_get_port_parent_id()
      
      Based on discussion with Ido and feedback from Jakub there are clearly
      two classes of users that implement SWITCHDEV_ATTR_ID_PORT_PARENT_ID:
      
      - PF/VF drivers which typically only implement return the port's parent
        ID, yet have to implement switchdev_port_attr_get() just for that
      
      - Ethernet switch drivers: mlxsw, ocelot, DSA, etc. which implement more
        attributes which we want to be able to eventually veto in the context
        of the caller, thus making them candidates for using a blocking notifier
        chain
      
      Changes in v4:
      
      - remove superfluous net/switchdev.h inclusions in a few files
      - added Jiri's Acked-by where given
      - removed err = -EOPNOTSUPP initializations
      - changed according to Jiri's suggestion in net/ipv4/ipmr.c
      
      Changes in v3:
      
      - keep ethsw's switchdev_ops assignment
      - remove inclusion of net/switchdev.h in netdevsim which is no longer
        necesary
      
      Changes in v2:
      
      - resolved build failures spotted by kbuild test robot
      - added helpers functions into the core network device layer:
        dev_get_port_parent_id() and netdev_port_same_parent_id();
      - added support for recursion to lower devices
      
      Changes from RFC:
      
      - introduce a ndo_get_port_parent_id() and convert all relevant drivers
        to use it
      
      - get rid of SWITCHDEV_ATTR_ID_PORT_PARENT_ID
      
      A subsequent set of patches will convert switchdev_port_attr_set() to
      use a blocking notifier call, and still get rid of
      switchdev_port_attr_get() altogether.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      554c88ac