1. 25 6月, 2011 1 次提交
  2. 24 6月, 2011 1 次提交
  3. 23 6月, 2011 3 次提交
    • G
      ath9k: add external_reset callback to ath9k_platfom_data for AR9330 · 7d95847c
      Gabor Juhos 提交于
      The patch adds a callback to ath9k_platform_data. If the
      callback is provided by the platform code, then it can be
      used to hard reset the WMAC device.
      
      The callback is required for doing a hard reset of the AR9330
      chips to get them working again after a hang.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7d95847c
    • G
      ath9k: add MAC revision detection for AR9330 · 3762561a
      Gabor Juhos 提交于
      The AR9330 1.0 and 1.1 are using the same revision,
      thus it is not possible to distinguish the two chips.
      The platform setup code can distinguish the chips based
      on the SoC revision.
      
      Add a callback function to ath9k_platform_data in order
      to allow getting the revision number from the platform code.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3762561a
    • J
      netlink: advertise incomplete dumps · 670dc283
      Johannes Berg 提交于
      Consider the following situation:
       * a dump that would show 8 entries, four in the first
         round, and four in the second
       * between the first and second rounds, 6 entries are
         removed
       * now the second round will not show any entry, and
         even if there is a sequence/generation counter the
         application will not know
      
      To solve this problem, add a new flag NLM_F_DUMP_INTR
      to the netlink header that indicates the dump wasn't
      consistent, this flag can also be set on the MSG_DONE
      message that terminates the dump, and as such above
      situation can be detected.
      
      To achieve this, add a sequence counter to the netlink
      callback struct. Of course, netlink code still needs
      to use this new functionality. The correct way to do
      that is to always set cb->seq when a dumpit callback
      is invoked and call nl_dump_check_consistent() for
      each new message. The core code will also call this
      function for the final MSG_DONE message.
      
      To make it usable with generic netlink, a new function
      genlmsg_nlhdr() is needed to obtain the netlink header
      from the genetlink user header.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      670dc283
  4. 22 6月, 2011 10 次提交
  5. 21 6月, 2011 2 次提交
    • L
      vfs: i_state needs to be 'unsigned long' for now · 79568f5b
      Linus Torvalds 提交于
      Commit 13e12d14 ("vfs: reorganize 'struct inode' layout a bit")
      moved things around a bit changed i_state to be unsigned int instead of
      unsigned long.  That was to help structure layout for the 64-bit case,
      and shrink 'struct inode' a bit (admittedly that only happened when
      spinlock debugging was on and i_flags didn't pack with i_lock).
      
      However, Meelis Roos reports that this results in unaligned exceptions
      on sprc, and it turns out that the bit-locking primitives that we use
      for the I_NEW bit want to use the bitops.  Which want 'unsigned long',
      not 'unsigned int'.
      
      We really should fix the bit locking code to not have that kind of
      requirement, but that's a much bigger change.  So for now, revert that
      field back to 'unsigned long' (but keep the other re-ordering changes
      from the commit that caused this).
      
      Andi points out that we have played games with this in 'struct page', so
      it's solvable with other hacks too, but since right now the struct inode
      size advantage only happens with some rare config options, it's not
      worth fighting.
      
      It _would_ be worth fixing the bitlocking code, though.  Especially
      since there is no type safety in the bitlocking code (this never caused
      any warnings, and worked fine on x86-64, because the bitlocks take a
      'void *' and x86-64 doesn't care that deeply about alignment).  So it's
      currently a very easy problem to trigger by mistake and never notice.
      Reported-by: NMeelis Roos <mroos@linux.ee>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      79568f5b
    • R
      bcma: clean exports of functions · 440ca98f
      Rafał Miłecki 提交于
      Function managing IRQs is needed for external drivers like b43.
      On the other side we do not expect writing any hosts drivers outside of
      bcma, so this is safe to do not export functions related to this.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      440ca98f
  6. 20 6月, 2011 2 次提交
  7. 18 6月, 2011 3 次提交
  8. 17 6月, 2011 17 次提交
  9. 16 6月, 2011 1 次提交