1. 05 May, 2014 5 commits
    • Jack Morgenstein's avatar
      net/mlx4_core: Adjust port number in qp_attach wrapper when detaching · 531d9014
      Jack Morgenstein authored
      When using single ported VFs and the VF is using port 2, we need
      to adjust the port accordingly (change it from 1 to 2).
      
      Fixes: 449fc488 ('net/mlx4: Adapt code for N-Port VF')
      Signed-off-by: default avatarMatan Barak <matanb@mellanox.com>
      Signed-off-by: default avatarJack Morgenstein <jackm@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      531d9014
    • Bjørn Mork's avatar
      net: cdc_ncm: fix buffer overflow · 9becd707
      Bjørn Mork authored
      Commit 4d619f62 ("net: cdc_ncm: no point in filling up the NTBs
      if we send ZLPs") changed the padding logic for devices with the ZLP
      flag set.  This meant that frames of any size will be sent without
      additional padding, except for the single byte added if the size is
      a multiple of the USB packet size. But if the unpadded size is
      identical to the maximum frame size, and the maximum size is a
      multiplum of the USB packet size, then this one-byte padding will
      overflow the buffer.
      
      Prevent padding if already at maximum frame size, letting usbnet
      transmit a ZLP instead in this case.
      
      Fixes: 4d619f62 ("net: cdc_ncm: no point in filling up the NTBs if we send ZLPs")
      Reported by: Yu-an Shih <yshih@nvidia.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9becd707
    • Geert Uytterhoeven's avatar
      Altera TSE: ALTERA_TSE should depend on HAS_DMA · 9d4619c4
      Geert Uytterhoeven authored
      If NO_DMA=y:
      
      drivers/built-in.o: In function `altera_tse_probe':
      altera_tse_main.c:(.text+0x25ec2e): undefined reference to `dma_set_mask'
      altera_tse_main.c:(.text+0x25ec78): undefined reference to `dma_supported'
      altera_tse_main.c:(.text+0x25ecb6): undefined reference to `dma_supported'
      drivers/built-in.o: In function `sgdma_async_read':
      altera_sgdma.c:(.text+0x25f620): undefined reference to `dma_sync_single_for_cpu'
      drivers/built-in.o: In function `sgdma_uninitialize':
      (.text+0x25f678): undefined reference to `dma_unmap_single'
      drivers/built-in.o: In function `sgdma_uninitialize':
      (.text+0x25f696): undefined reference to `dma_unmap_single'
      drivers/built-in.o: In function `sgdma_initialize':
      (.text+0x25f6f0): undefined reference to `dma_map_single'
      drivers/built-in.o: In function `sgdma_initialize':
      (.text+0x25f702): undefined reference to `dma_mapping_error'
      drivers/built-in.o: In function `sgdma_tx_buffer':
      (.text+0x25f92a): undefined reference to `dma_sync_single_for_cpu'
      drivers/built-in.o: In function `sgdma_rx_status':
      (.text+0x25fa24): undefined reference to `dma_sync_single_for_cpu'
      make[3]: *** [vmlinux] Error 1
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarVince Bridgers <vbridgers2013@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d4619c4
    • Andy King's avatar
      vsock: Make transport the proto owner · 2c4a336e
      Andy King authored
      Right now the core vsock module is the owner of the proto family. This
      means there's nothing preventing the transport module from unloading if
      there are open sockets, which results in a panic. Fix that by allowing
      the transport to be the owner, which will refcount it properly.
      
      Includes version bump to 1.0.1.0-k
      
      Passes checkpatch this time, I swear...
      Acked-by: default avatarDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: default avatarAndy King <acking@vmware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2c4a336e
    • David S. Miller's avatar
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · b8dff4e6
      David S. Miller authored
      John W. Linville says:
      
      ====================
      pull request: wireless 2014-05-01
      
      Please pull the following batch of fixes intended for the 3.15 stream!
      
      For the Bluetooth bits, Gustavo says:
      
      "Some fixes for 3.15. There is a revert for the intel driver, a new
      device id, and two important SSP fixes from Johan."
      
      On top of that...
      
      Ben Hutchings gives us a fix for an unbalanced irq enable in an
      rtl8192cu error path.
      
      Colin Ian King provides an rtlwifi fix for an uninitialized variable.
      
      Felix Fietkau brings a pair of ath9k fixes, one that corrects a
      hardware initialization value and another that removes an (unnecessary)
      flag that was being used in a way that led to a software tx queue
      hang in ath9k.
      
      Gertjan van Wingerde pushes a MAINTAINERS change to remove himself
      from the rt2x00 maintainer team.
      
      Hans de Goede fixes a brcmfmac firmware load hang.
      
      Larry Finger changes rtlwifi to use the correct queue for V0 traffic
      on rtl8192se.
      
      Rajkumar Manoharan corrects a race in ath9k driver initialization.
      
      Stanislaw Gruszka fixes an rt2x00 bug in which disabling beaconing
      once on USB devices led to permanently disabling beaconing for those
      devices.
      
      Tim Harvey provides fixes for a pair of ath9k issues that can lead
      to soft lockups in that driver.
      
      Please let me know if there are problems!
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8dff4e6
  2. 04 May, 2014 1 commit
  3. 02 May, 2014 2 commits
  4. 01 May, 2014 1 commit
  5. 30 Apr, 2014 17 commits
  6. 28 Apr, 2014 12 commits
  7. 27 Apr, 2014 2 commits
    • Xufeng Zhang's avatar
      sctp: reset flowi4_oif parameter on route lookup · 85350871
      Xufeng Zhang authored
      commit 813b3b5d (ipv4: Use caller's on-stack flowi as-is
      in output route lookups.) introduces another regression which
      is very similar to the problem of commit e6b45241 (ipv4: reset
      flowi parameters on route connect) wants to fix:
      Before we call ip_route_output_key() in sctp_v4_get_dst() to
      get a dst that matches a bind address as the source address,
      we have already called this function previously and the flowi
      parameters have been initialized including flowi4_oif, so when
      we call this function again, the process in __ip_route_output_key()
      will be different because of the setting of flowi4_oif, and we'll
      get a networking device which corresponds to the inputted flowi4_oif
      as the output device, this is wrong because we'll never hit this
      place if the previously returned source address of dst match one
      of the bound addresses.
      
      To reproduce this problem, a vlan setting is enough:
        # ifconfig eth0 up
        # route del default
        # vconfig add eth0 2
        # vconfig add eth0 3
        # ifconfig eth0.2 10.0.1.14 netmask 255.255.255.0
        # route add default gw 10.0.1.254 dev eth0.2
        # ifconfig eth0.3 10.0.0.14 netmask 255.255.255.0
        # ip rule add from 10.0.0.14 table 4
        # ip route add table 4 default via 10.0.0.254 src 10.0.0.14 dev eth0.3
        # sctp_darn -H 10.0.0.14 -P 36422 -h 10.1.4.134 -p 36422 -s -I
      You'll detect that all the flow are routed to eth0.2(10.0.1.254).
      Signed-off-by: default avatarXufeng Zhang <xufeng.zhang@windriver.com>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      85350871
    • Heiko Stübner's avatar
      arc_emac: add clock handling · 88154c96
      Heiko Stübner authored
      This adds ability for the arc_emac to really handle its supplying clock.
      To get the needed clock-frequency either a real clock or the previous
      clock-frequency property must be provided.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarMax Schwarz <max.schwarz@online.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88154c96