1. 05 Jun, 2013 5 commits
  2. 04 Jun, 2013 7 commits
  3. 03 Jun, 2013 5 commits
  4. 01 Jun, 2013 6 commits
  5. 31 May, 2013 6 commits
    • Jay Vosburgh's avatar
      net/core: dev_mc_sync_multiple calls wrong helper · b190a508
      Jay Vosburgh authored
      The dev_mc_sync_multiple function is currently calling
      __hw_addr_sync, and not __hw_addr_sync_multiple.  This will result in
      addresses only being synced to the first device from the set.
      
      	Corrected by calling the _multiple variant.
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Reviewed-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Tested-by: default avatarShawn Bohrer <sbohrer@rgmadvisors.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b190a508
    • Jay Vosburgh's avatar
      net/core: __hw_addr_sync_one / _multiple broken · 29ca2f8f
      Jay Vosburgh authored
      Currently, __hw_addr_sync_one is called in a loop by
      __hw_addr_sync_multiple to sync each of a "from" device's hw addresses
      to a "to" device.  __hw_addr_sync_one calls __hw_addr_add_ex to attempt
      to add each address.  __hw_addr_add_ex is called with global=false, and
      sync=true.
      
      	__hw_addr_add_ex checks to see if the new address matches an
      address already on the list.  If so, it tests global and sync.  In this
      case, sync=true, and it then checks if the address is already synced,
      and if so, returns 0.
      
      	This 0 return causes __hw_addr_sync_one to increment the sync_cnt
      and refcount for the "from" list's address entry, even though the address
      is already synced and has a reference and sync_cnt.  This will cause
      the sync_cnt and refcount to increment without bound every time an
      addresses is added to the "from" device and synced to the "to" device.
      
      	The fix here has two parts:
      
      	First, when __hw_addr_add_ex finds the address already exists
      and is synced, return -EEXIST instead of 0.
      
      	Second, __hw_addr_sync_one checks the error return for -EEXIST,
      and if so, it (a) does not add a refcount/sync_cnt, and (b) returns 0
      itself so that __hw_addr_sync_multiple will not return an error.
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Reviewed-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Tested-by: default avatarShawn Bohrer <sbohrer@rgmadvisors.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29ca2f8f
    • Jay Vosburgh's avatar
      net/core: __hw_addr_unsync_one "from" address not marked synced · 60ba834c
      Jay Vosburgh authored
      When an address is added to a subordinate interface (the "to"
      list), the address entry in the "from" list is not marked "synced" as
      the entry added to the "to" list is.
      
      	When performing the unsync operation (e.g., dev_mc_unsync),
      __hw_addr_unsync_one calls __hw_addr_del_entry with the "synced"
      parameter set to true for the case when the address reference is being
      released from the "from" list.  This causes a test inside to fail,
      with the result being that the reference count on the "from" address
      is not properly decremeted and the address on the "from" list will
      never be freed.
      
      	Correct this by having __hw_addr_unsync_one call the
      __hw_addr_del_entry function with the "sync" flag set to false for the
      "remove from the from list" case.
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Reviewed-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Tested-by: default avatarShawn Bohrer <sbohrer@rgmadvisors.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60ba834c
    • Jay Vosburgh's avatar
      net/core: __hw_addr_create_ex does not initialize sync_cnt · 9747ba66
      Jay Vosburgh authored
      The sync_cnt field is not being initialized, which can result
      in arbitrary values in the field.  Fixed by initializing it to zero.
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Reviewed-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Tested-by: default avatarShawn Bohrer <sbohrer@rgmadvisors.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9747ba66
    • Nicolas Dichtel's avatar
      snmp6: remove IPSTATS_MIB_CSUMERRORS · fda3f402
      Nicolas Dichtel authored
      This stat is not relevant in IPv6, there is no checksum in IPv6 header.
      Just leave a comment to explain the hole.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fda3f402
    • David S. Miller's avatar
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · fb68e2f4
      David S. Miller authored
      John W. Linville says:
      
      ====================
      Please pull this batch of fixes intended for the 3.10 stream...
      
      Regarding the NFC bits, Samuel says:
      
      "This is the first batch of NFC fixes for 3.10, and it contains:
      
      - 3 fixes for the NFC MEI support:
              * We now depend on the correct Kconfig symbol.
              * We register an MEI event callback whenever we enable an NFC device,
                otherwise we fail to read anything after an enable/disable cycle.
              * We only disable an MEI device from its disable mey_phy_ops,
                preventing useless consecutive disable calls.
      
      - An NFC Makefile cleanup, as I forgot to remove a commented out line when
        moving the LLCP code to the NFC top level directory."
      
      As for the mac80211 bits, Johannes says:
      
      "This time I have a fix from Stanislaw for a stupid mistake I made in the
      auth/assoc timeout changes, a fix from Felix for 64-bit traffic counters
      and one from Helmut for address mask handling in mac80211. I also have a
      few fixes myself for four different crashes reported by a few people."
      
      And Johannes says this about the iwlwifi bit:
      
      "This fixes a brown paper-bag bug that we really should've caught in
      review. More details in the changelog for the fix."
      
      On top of that...
      
      Arend van Spriel and Hante Meuleman cooperate to send a series of AP
      and P2P mode fixes for brcmfmac.
      
      Gabor Juhos corrects a register offset for AR9550, avoiding a bus
      error.
      
      Dan Carpenter provides a fixup to some dmesg output in the atmel
      driver.
      
      And, finally...
      
      Felix Fietkau not only gives us a trio of small AR934x fixes, but
      also refactors the ath9k aggregation session start/stop handling
      (using the generic mac80211 support) in order to avoid a deadlock.
      
      Please let me know if there are problems!
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb68e2f4
  6. 30 May, 2013 3 commits
  7. 29 May, 2013 6 commits
  8. 28 May, 2013 2 commits
    • Gabor Juhos's avatar
      ath9k: use correct OTP register offsets for AR9550 · add295a4
      Gabor Juhos authored
      Accessing the OTP memory on AR9950 causes a data bus
      like this:
      
        Data bus error, epc == 801f7774, ra == 801f7774
        Oops[#1]:
        CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-rc3 #592
        task: 87c28000 ti: 87c22000 task.ti: 87c22000
        $ 0   : 00000000 00000061 deadc0de 00000000
        $ 4   : b8115f18 00015f18 00000007 00000004
        $ 8   : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c
        $12   : 7c7c3c7c 80320a68 00000000 7c7c7c3c
        $16   : 87cd8010 00015f18 00000007 00000000
        $20   : 00000064 00000004 87c23c7c 8035210c
        $24   : 00000000 801f3674
        $28   : 87c22000 87c23b48 00000001 801f7774
        Hi    : 00000000
        Lo    : 00000064
        epc   : 801f7774 ath9k_hw_wait+0x58/0xb0
            Not tainted
        ra    : 801f7774 ath9k_hw_wait+0x58/0xb0
        Status: 1000cc03 KERNEL EXL IE
        Cause : 4080801c
        PrId  : 00019750 (MIPS 74Kc)
        Modules linked in:
        Process swapper (pid: 1, threadinfo=87c22000, task=87c28000, ts=00000000)
        Stack : 0000000f 00000061 00002710 8006240c 00000001 87cd8010 87c23bb0 87cd8010
                00000000 00000004 00000003 80210c7c 000000b3 67fa8000 0000032a 000006fe
                000003e8 00000002 00000028 87c23bf0 000003ff 80210d24 803e5630 80210e28
                00000000 00000007 87cd8010 00007044 00000004 00000061 000003ff 000001ff
                87c26000 87cd8010 00000220 87cd8bb8 80210000 8020fcf4 87c22000 87c23c08
                ...
        Call Trace:
        [<801f7774>] ath9k_hw_wait+0x58/0xb0
        [<80210c7c>] ar9300_otp_read_word+0x80/0xd4
        [<80210d24>] ar9300_read_otp+0x54/0xb0
        [<8020fcf4>] ar9300_check_eeprom_header+0x1c/0x40
        [<80210fe4>] ath9k_hw_ar9300_fill_eeprom+0x118/0x39c
        [<80206650>] ath9k_hw_eeprom_init+0x74/0xb4
        [<801f96d0>] ath9k_hw_init+0x7ec/0x96c
        [<801e65ec>] ath9k_init_device+0x340/0x758
        [<801f35d0>] ath_ahb_probe+0x21c/0x2c0
        [<801c041c>] driver_probe_device+0xc0/0x1e4
        [<801c05ac>] __driver_attach+0x6c/0xa4
        [<801bea08>] bus_for_each_dev+0x64/0xa8
        [<801bfa40>] bus_add_driver+0xcc/0x24c
        [<801c0954>] driver_register+0xbc/0x17c
        [<803f8fc0>] ath9k_init+0x5c/0x88
        [<800608fc>] do_one_initcall+0xec/0x1a0
        [<803e6a68>] kernel_init_freeable+0x13c/0x200
        [<80309cdc>] kernel_init+0x1c/0xe4
        [<80062450>] ret_from_kernel_thread+0x10/0x18
      
      On the AR9550, the OTP registers are located at
      the same address as on the AR9340. Use the correct
      values to avoid the error.
      
      Cc: stable@vger.kernel.org  # 3.6+
      Signed-off-by: default avatarGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      add295a4
    • Hante Meuleman's avatar
      brcmfmac: Disable powersave mode for P2P link. · 102fd0d6
      Hante Meuleman authored
      For p2p client mode powersave mode should be kept disabled. It is
      working but inefficient. In general p2p links do no benefit from this
      mode, because these links are setup temporarily to transfer data.
      Reviewed-by: default avatarArend Van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarHante Meuleman <meuleman@broadcom.com>
      Signed-off-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      102fd0d6