1. 06 10月, 2010 6 次提交
  2. 30 9月, 2010 1 次提交
  3. 28 9月, 2010 2 次提交
    • J
      mac80211: move packet flags into packet · 554891e6
      Johannes Berg 提交于
      commit 8c0c709e
      Author: Johannes Berg <johannes@sipsolutions.net>
      Date:   Wed Nov 25 17:46:15 2009 +0100
      
          mac80211: move cmntr flag out of rx flags
      
      moved the CMNTR flag into the skb RX flags for
      some aggregation cleanups, but this was wrong
      since the optimisation this flag tried to make
      requires that it is kept across the processing
      of multiple interfaces -- which isn't true for
      flags in the skb. The patch not only broke the
      optimisation, it also introduced a bug: under
      some (common!) circumstances the flag will be
      set on an already freed skb!
      
      However, investigating this in more detail, I
      found that most of the flags that we set should
      be per packet, _except_ for this one, due to
      a-MPDU processing. Additionally, the flags used
      for processing (currently just this one) need
      to be reset before processing a new packet.
      
      Since we haven't actually seen bugs reported as
      a result of the wrong flags handling (which is
      not too surprising -- the only real bug case I
      can come up with is an a-MSDU contained in an
      a-MPDU), I'll make a different fix for rc.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      554891e6
    • B
      mac80211/ath9k: Support AMPDU with multiple VIFs. · 686b9cb9
      Ben Greear 提交于
      The old ieee80211_find_sta_by_hw method didn't properly
      find VIFS when there was more than one per AP.  This caused
      AMPDU logic in ath9k to get the wrong VIF when trying to
      account for transmitted SKBs.
      
      This patch changes ieee80211_find_sta_by_hw to take a
      localaddr argument to distinguish between VIFs with the
      same AP but different local addresses.  The method name
      is changed to ieee80211_find_sta_by_ifaddr.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      686b9cb9
  4. 25 9月, 2010 1 次提交
  5. 21 9月, 2010 3 次提交
  6. 17 9月, 2010 3 次提交
  7. 15 9月, 2010 1 次提交
  8. 28 8月, 2010 3 次提交
  9. 26 8月, 2010 2 次提交
  10. 25 8月, 2010 6 次提交
  11. 17 8月, 2010 5 次提交
  12. 10 8月, 2010 2 次提交
    • M
      Bluetooth: Use 3-DH5 payload size for default ERTM max PDU size · db12d647
      Mat Martineau 提交于
      The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on
      the default L2CAP MTU.  That default MTU is calculated from the size
      of two DH5 packets, minus ACL and L2CAP b-frame header overhead.
      
      ERTM is used with newer basebands that typically support larger 3-DH5
      packets, and i-frames and s-frames have more header overhead.  With
      clean RF conditions, basebands will typically attempt to use 1021-byte
      3-DH5 packets for maximum throughput.  Adjusting for 2 bytes of ACL
      headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes
      of payload.
      
      This PDU size imposes less overhead for header bytes and gives the
      baseband the option to choose 3-DH5 packets, but is small enough for
      ERTM traffic to interleave well with other L2CAP or SCO data.
      672-byte payloads do not allow the most efficient over-the-air
      packet choice, and cannot achieve maximum throughput over BR/EDR.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      db12d647
    • M
      Bluetooth: Change default L2CAP ERTM retransmit timeout · fa235562
      Mat Martineau 提交于
      The L2CAP specification requires that the ERTM retransmit timeout be at
      least 2 seconds for BR/EDR connections.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      fa235562
  13. 05 8月, 2010 2 次提交
  14. 04 8月, 2010 2 次提交
    • T
      [CPUFREQ] x86 cpufreq: Make trace_power_frequency cpufreq driver independent · 6f4f2723
      Thomas Renninger 提交于
      and fix the broken case if a core's frequency depends on others.
      
      trace_power_frequency was only implemented in a rather ungeneric way
      in acpi-cpufreq driver's target() function only.
      -> Move the call to trace_power_frequency to
         cpufreq.c:cpufreq_notify_transition() where CPUFREQ_POSTCHANGE
         notifier is triggered.
         This will support power frequency tracing by all cpufreq drivers
      
      trace_power_frequency did not trace frequency changes correctly when
      the userspace governor was used or when CPU cores' frequency depend
      on each other.
      -> Moving this into the CPUFREQ_POSTCHANGE notifier and pass the cpu
         which gets switched automatically fixes this.
      
      Robert Schoene provided some important fixes on top of my initial
      quick shot version which are integrated in this patch:
      - Forgot some changes in power_end trace (TP_printk/variable names)
      - Variable dummy in power_end must now be cpu_id
      - Use static 64 bit variable instead of unsigned int for cpu_id
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      CC: davej@redhat.com
      CC: arjan@infradead.org
      CC: linux-kernel@vger.kernel.org
      CC: robert.schoene@tu-dresden.de
      Tested-by: robert.schoene@tu-dresden.de
      Signed-off-by: NDave Jones <davej@redhat.com>
      6f4f2723
    • A
      [CPUFREQ] unexport (un)lock_policy_rwsem* functions · 226528c6
      Amerigo Wang 提交于
      lock_policy_rwsem_* and unlock_policy_rwsem_* functions are scheduled
      to be unexported when 2.6.33. Now there are no other callers of them
      out of cpufreq.c, unexport them and make them static.
      Signed-off-by: NWANG Cong <amwang@redhat.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      226528c6
  15. 03 8月, 2010 1 次提交
    • A
      gpio: Add PMIC GPIO block support · 89507787
      Alek Du 提交于
      Moorestown has PMIC chip which contains GPIO blocks. The PMIC chip is
      connected to Langwell by SPI interface. So this GPIO driver will be regarded
      as SPI GPIO expander though the actual GPIO access is through IPC and SRAM.
      The SPI master contoller will probe this device driver by parsing SPIB table.
      
      Cleaned up for new IPC, GPE removed and some printk and other tidying by
      Alan Cox. Fixes for points noted by Matthew Garrett
      Signed-off-by: NAlek Du <alek.du@intel.com>
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      89507787