1. 26 Aug, 2015 6 commits
    • Kalle Valo's avatar
      Merge ath-next from ath.git · 0ba3ac03
      Kalle Valo authored
      Major changes in ath10k:
      
      * add spectral scan support for qca99x0
      * add qca6164 support
      0ba3ac03
    • Raja Mani's avatar
      ath10k: fix compilation warnings in wmi phyerr pull function · ee92a209
      Raja Mani authored
      Below compilation warnings are observed in gcc version 4.8.2.
      Even though it's not seen in bit older gcc versions (for ex, 4.7.3),
      It's good to fix it by changing format specifier from %d to
      %zd in wmi pull phyerr functions.
      
      wmi.c: In function 'ath10k_wmi_op_pull_phyerr_ev':
      wmi.c:3567:8: warning: format '%d' expects argument of type 'int',
                    but argument 4 has type 'long unsigned int' [-Wformat=]
                    left_len, sizeof(*phyerr));
                              ^
      wmi.c: In function 'ath10k_wmi_10_4_op_pull_phyerr_ev':
      wmi.c:3612:8: warning: format '%d' expects argument of type 'int',
      	      but argument 4 has type 'long unsigned int' [-Wformat=]
                    left_len, sizeof(*phyerr));
                              ^
      Fixes: 991adf71 ("ath10k: refactor phyerr event handlers")
      Fixes: 2b0a2e0d
      
       ("ath10k: handle 10.4 firmware phyerr event")
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      ee92a209
    • Michal Kazior's avatar
      ath10k: add qca6164 support · 36582e5d
      Michal Kazior authored
      
      
      This adds additional 0x0041 PCI Device ID
      definition to ath10k for QCA6164 which is a 1
      spatial stream sibling of the QCA6174 (which is 2
      spatial stream chip).
      
      The QCA6164 needs a dedicated board.bin file which
      is different than the one used for QCA6174. If the
      board.bin is wrong the device will crash early
      while trying to boot firmware. The register dump
      will look like this:
      
       ath10k_pci 0000:02:00.0: firmware register dump:
       ath10k_pci 0000:02:00.0: [00]: 0x05010000 0x000015B3 0x000A012D 0x00955B31
       ...
      
      Note the value 0x000A012D.
      
      Special credit goes to Alan Liu
      <alanliu@qca.qualcomm.com> for providing support
      help which enabled me to come up with this patch.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      36582e5d
    • Raja Mani's avatar
      ath10k: add spectral scan support for 10.4 fw · 4535edbd
      Raja Mani authored
      
      
      To enable/configure spectral scan parameters in 10.4 firmware, existing
      wmi spectral related functions can be reused. Link those functions in
      10.4 wmi ops table.
      
      In addition, adjust bin size (only when size is 68 bytes) before reporting
      bin samples to user space. The background for this adjustment is that
      qca99x0 reports bin size as 68 bytes (64 bytes + 4 bytes) in report
      mode 2. First 64 bytes carries in-band tones (-32 to +31) and last 4 byte
      carries band edge detection data (+32) mainly used in radar detection
      purpose. Additional last 4 bytes are stripped to make bin size valid one.
      
      This bin size adjustment will happen only for qca99x0, all other chipsets
      will report proper bin sizes (64/128) without extra 4 bytes being added
      at the end. The changes are validated in qca99x0 using 10.4 firmware.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      4535edbd
    • Michal Kazior's avatar
      ath10k: fix dma_mapping_error() handling · 5e55e3cb
      Michal Kazior authored
      The function returns 1 when DMA mapping fails. The
      driver would return bogus values and could
      possibly confuse itself if DMA failed.
      
      Fixes: 767d34fc
      
       ("ath10k: remove DMA mapping wrappers")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      5e55e3cb
    • Michal Kazior's avatar
      ath10k: add missing mutex unlock on failpath · 503422d9
      Michal Kazior authored
      Kernel would complain about leaving a held lock
      after going back to userspace and would
      subsequently deadlock.
      
      Fixes: e04cafbc
      
       ("ath10k: fix peer limit enforcement")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      503422d9
  2. 25 Aug, 2015 12 commits
  3. 24 Aug, 2015 5 commits
  4. 23 Aug, 2015 17 commits
    • David S. Miller's avatar
      Merge tag 'nfc-next-4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next · d9893d13
      David S. Miller authored
      
      
      Samuel Ortiz says:
      
      ====================
      NFC 4.3 pull request
      
      This is the NFC pull request for 4.3.
      With this one we have:
      
      - A new driver for Samsung's S3FWRN5 NFC chipset. In order to
        properly support this driver, a few NCI core routines needed
        to be exported. Future drivers like Intel's Fields Peak will
        benefit from this.
      
      - SPI support as a physical transport for STM st21nfcb.
      
      - An additional netlink API for sending replies back to userspace
        from vendor commands.
      
      - 2 small fixes for TI's trf7970a
      
      - A few st-nci fixes.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9893d13
    • Jiri Benc's avatar
      route: fix breakage after moving lwtunnel state · 751a587a
      Jiri Benc authored
      __recnt and related fields need to be in its own cacheline for performance
      reasons. Commit 61adedf3
      
       ("route: move lwtunnel state to dst_entry")
      broke that on 32bit archs, causing BUILD_BUG_ON in dst_hold to be triggered.
      
      This patch fixes the breakage by moving the lwtunnel state to the end of
      dst_entry on 32bit archs. Unfortunately, this makes it share the cacheline
      with __refcnt and may affect performance, thus further patches may be
      needed.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Fixes: 61adedf3
      
       ("route: move lwtunnel state to dst_entry")
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      751a587a
    • David S. Miller's avatar
      Merge tag 'linux-can-next-for-4.3-20150820' of... · 31fbde99
      David S. Miller authored
      Merge tag 'linux-can-next-for-4.3-20150820' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
      
      
      
      Marc Kleine-Budde says:
      
      ====================
      this is a pull request of a two patches for net-next.
      
      The first patch is by Nik Nyby and fixes a typo in a function name. The
      second patch by Lucas Stach demotes register output to debug level.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31fbde99
    • David S. Miller's avatar
      Merge branch 'tipc-failover-fixes' · c5f98b56
      David S. Miller authored
      
      
      Jon Maloy says:
      
      ====================
      tipc: fix link failover/synch problems
      
      We fix three problems with the new link failover/synch implementation,
      which was introduced earlier in this release cycle. They are all related
      to situations where there is a very short interval between the disabling
      and enabling of interfaces.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5f98b56
    • Jon Paul Maloy's avatar
      tipc: fix stale link problem during synchronization · 2be80c2d
      Jon Paul Maloy authored
      
      
      Recent changes to the link synchronization means that we can now just
      drop packets arriving on the synchronizing link before the synch point
      is reached. This has lead to significant simplifications to the
      implementation, but also turns out to have a flip side that we need
      to consider.
      
      Under unlucky circumstances, the two endpoints may end up
      repeatedly dropping each other's packets, while immediately
      asking for retransmission of the same packets, just to drop
      them once more. This pattern will eventually be broken when
      the synch point is reached on the other link, but before that,
      the endpoints may have arrived at the retransmission limit
      (stale counter) that indicates that the link should be broken.
      We see this happen at rare occasions.
      
      The fix for this is to not ask for retransmissions when a link is in
      state LINK_SYNCHING. The fact that the link has reached this state
      means that it has already received the first SYNCH packet, and that it
      knows the synch point. Hence, it doesn't need any more packets until the
      other link has reached the synch point, whereafter it can go ahead and
      ask for the missing packets.
      
      However, because of the reduced traffic on the synching link that
      follows this change, it may now take longer to discover that the
      synch point has been reached. We compensate for this by letting all
      packets, on any of the links, trig a check for synchronization
      termination. This is possible because the packets themselves don't
      contain any information that is needed for discovering this condition.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2be80c2d
    • Jon Paul Maloy's avatar
      tipc: interrupt link synchronization when a link goes down · 5ae2f8e6
      Jon Paul Maloy authored
      When we introduced the new link failover/synch mechanism
      in commit 6e498158
      
      
      ("tipc: move link synch and failover to link aggregation level"),
      we missed the case when the non-tunnel link goes down during the link
      synchronization period. In this case the tunnel link will remain in
      state LINK_SYNCHING, something leading to unpredictable behavior when
      the failover procedure is initiated.
      
      In this commit, we ensure that the node and remaining link goes
      back to regular communication state (SELF_UP_PEER_UP/LINK_ESTABLISHED)
      when one of the parallel links goes down. We also ensure that we don't
      re-enter synch mode if subsequent SYNCH packets arrive on the remaining
      link.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ae2f8e6
    • Jon Paul Maloy's avatar
      tipc: eliminate risk of premature link setup during failover · 17b20630
      Jon Paul Maloy authored
      
      
      When a link goes down, and there is still a working link towards its
      destination node, a failover is initiated, and the failed link is not
      allowed to re-establish until that procedure is finished. To ensure
      this, the concerned link endpoints are set to state LINK_FAILINGOVER,
      and the node endpoints to NODE_FAILINGOVER during the failover period.
      
      However, if the link reset is due to a disabled bearer, the corres-
      ponding link endpoint is deleted, and only the node endpoint knows
      about the ongoing failover. Now, if the disabled bearer is re-enabled
      during the failover period, the discovery mechanism may create a new
      link endpoint that is ready to be established, despite that this is not
      permitted. This situation may cause both the ongoing failover and any
      subsequent link synchronization to fail.
      
      In this commit, we ensure that a newly created link goes directly to
      state LINK_FAILINGOVER if the corresponding node state is
      NODE_FAILINGOVER. This eliminates the problem described above.
      
      Furthermore, we tighten the criteria for which packets are allowed
      to end a failover state in the function tipc_node_check_state().
      By checking that the receiving link is up and running, instead of just
      checking that it is not in failover mode, we eliminate the risk that
      protocol packets from the re-created link may cause the failover to
      be prematurely terminated.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17b20630
    • David S. Miller's avatar
      Merge branch 'nps_enet_fixes' · 7f629be1
      David S. Miller authored
      
      
      Noam Camus says:
      
      ====================
      *** nps_enet fixups ***
      
      Change v2
      TX done is handled back with NAPI poll.
      
      Change v1
      This patch set is a bunch of fixes to make nps_enet work correctly with
      all platforms, i.e. real device, emulation system, and simulation system.
      The main trigger for this patch set was that in our emulation system
      the TX end interrupt is "edge-sensitive" and therefore we cannot use the
      cause register since it is not sticky.
      Also:
      TX is handled during HW interrupt context and not NAPI job.
      race with TX done was fixed.
      added acknowledge for TX when device is "level sensitive".
      enable drop of control frames which is not needed for regular usage.
      
      So most of this patch set is about TX handling, which is now more complete.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f629be1
    • Noam Camus's avatar
      NET: nps_enet: minor namespace cleanup · 41493795
      Noam Camus authored
      
      
      We define buf_int_enable in the minimal namespace it is used.
      Signed-off-by: default avatarNoam Camus <noamc@ezchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41493795
    • Noam Camus's avatar
      NET: nps_enet: TX done acknowledge. · 3d99b74a
      Noam Camus authored
      
      
      This is needed for when TX done interrupt is in
      "level mode".
      For example it is true for some simulators of this device.
      Signed-off-by: default avatarNoam Camus <noamc@ezchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d99b74a
    • Noam Camus's avatar
      NET: nps_enet: drop control frames · de671567
      Noam Camus authored
      
      
      We set controller to drop control frames and not trying
      to pass them on. This is only needed for debug reasons.
      Signed-off-by: default avatarNoam Camus <noamc@ezchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de671567
    • Noam Camus's avatar
      NET: nps_enet: TX done race condition · 93fcf83e
      Noam Camus authored
      
      
      We need to set tx_skb pointer before send frame.
      If we receive interrupt before we set pointer we will try
      to free SKB with wrong pointer.
      Now we are sure that SKB pointer will never be NULL during
      handling TX done and check is removed.
      Signed-off-by: default avatarNoam Camus <noamc@ezchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93fcf83e
    • Noam Camus's avatar
      NET: nps_enet: replace use of cause register · 0dd20f3c
      Noam Camus authored
      
      
      When interrupt is received we read directly from control
      register for RX/TX instead of reading cause register
      since this register fails to indicate TX done when
      TX interrupt is "edge mode".
      Signed-off-by: default avatarNoam Camus <noamc@ezchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0dd20f3c
    • David S. Miller's avatar
      Merge branch 'gro_tunnels' · 1728369e
      David S. Miller authored
      
      
      Tom Herbert says:
      
      ====================
      gro: Fixes for tunnels and GRO
      
      This patch set addresses some issue related to tunneling and GRO:
      
      - Fix remote checksum offload to properly deal with frag0 in GRO.
      - Add support for GRO at VXLAN tunnel (call gro_cells)
      
      Testing: Ran one netperf TCP_STREAM to highlight impact of different
      configurations:
      
      GUE
        Zero UDP checksum
          4628.42 MBps
        UDP checksums enabled
          6800.51 MBps
        UDP checksums and remote checksum offload
          7663.82 MBps
        UDP checksums and remote checksum offload using no-partial
          7287.25 MBps
      
      VXLAN
        Zero UDP checksum
          4112.02
        UDP checksums enabled
          6785.80 MBps
        UDP checksums and remote checksum offload
          7075.56 MBps
      
      v2:
        - Drop "gro: Pull headers into skb head for 1st skb in gro list"
          from patch set
        - In vxlan_remcsum and gue_remcsum return immediately if remcsum
          processing was already done
        - Add gro callbacks for sit offload
        - Use WARN_ON_ONCE if we get a GUE protocol that does not have
          GRO offload support
      
      v3:
        - Don't restore gro callbacks for sit offload
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1728369e
    • Tom Herbert's avatar
      fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks · 27013661
      Tom Herbert authored
      
      
      Do WARN_ON_ONCE instead of WARN_ON in gue_gro_receive when the offload
      callcaks are bad (either don't exist or gro_receive is not specified).
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27013661
    • Tom Herbert's avatar
      vxlan: GRO support at tunnel layer · 58ce31cc
      Tom Herbert authored
      
      
      Add calls to gro_cells infrastructure to do GRO when receiving on a tunnel.
      
      Testing:
      
      Ran 200 netperf TCP_STREAM instance
      
        - With fix (GRO enabled on VXLAN interface)
      
          Verify GRO is happening.
      
          9084 MBps tput
          3.44% CPU utilization
      
        - Without fix (GRO disabled on VXLAN interface)
      
          Verified no GRO is happening.
      
          9084 MBps tput
          5.54% CPU utilization
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58ce31cc
    • Tom Herbert's avatar
      gro: Fix remcsum offload to deal with frags in GRO · b7fe10e5
      Tom Herbert authored
      
      
      The remote checksum offload GRO did not consider the case that frag0
      might be in use. This patch fixes that by accessing headers using the
      skb_gro functions and not saving offsets relative to skb->head.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7fe10e5