1. 16 7月, 2012 4 次提交
  2. 10 7月, 2012 2 次提交
  3. 09 7月, 2012 18 次提交
  4. 07 7月, 2012 1 次提交
  5. 05 7月, 2012 1 次提交
  6. 03 7月, 2012 1 次提交
  7. 01 7月, 2012 2 次提交
    • N
      sctp: be more restrictive in transport selection on bundled sacks · 4244854d
      Neil Horman 提交于
      It was noticed recently that when we send data on a transport, its possible that
      we might bundle a sack that arrived on a different transport.  While this isn't
      a major problem, it does go against the SHOULD requirement in section 6.4 of RFC
      2960:
      
       An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
         etc.) to the same destination transport address from which it
         received the DATA or control chunk to which it is replying.  This
         rule should also be followed if the endpoint is bundling DATA chunks
         together with the reply chunk.
      
      This patch seeks to correct that.  It restricts the bundling of sack operations
      to only those transports which have moved the ctsn of the association forward
      since the last sack.  By doing this we guarantee that we only bundle outbound
      saks on a transport that has received a chunk since the last sack.  This brings
      us into stricter compliance with the RFC.
      
      Vlad had initially suggested that we strictly allow only sack bundling on the
      transport that last moved the ctsn forward.  While this makes sense, I was
      concerned that doing so prevented us from bundling in the case where we had
      received chunks that moved the ctsn on multiple transports.  In those cases, the
      RFC allows us to select any of the transports having received chunks to bundle
      the sack on.  so I've modified the approach to allow for that, by adding a state
      variable to each transport that tracks weather it has moved the ctsn since the
      last sack.  This I think keeps our behavior (and performance), close enough to
      our current profile that I think we can do this without a sysctl knob to
      enable/disable it.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Vlad Yaseivch <vyasevich@gmail.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: linux-sctp@vger.kernel.org
      Reported-by: NMichele Baldessari <michele@redhat.com>
      Reported-by: Nsorin serban <sserban@redhat.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4244854d
    • R
      linux/irq.h: fix kernel-doc warning · 87fac288
      Randy Dunlap 提交于
      Fix kernel-doc warning.  This struct member was removed in commit
      87568264 ("irq: Remove irq_chip->release()") so remove its
      associated kernel-doc entry also.
      
        Warning(include/linux/irq.h:338): Excess struct/union/enum/typedef member 'release' description in 'irq_chip'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      87fac288
  8. 26 6月, 2012 1 次提交
    • P
      bug.h: Fix up CONFIG_BUG=n implicit function declarations. · 09682c1d
      Paul Mundt 提交于
      Commit 2603efa3 ("bug.h: Fix up powerpc build regression") corrected
      the powerpc build case and extended the __ASSEMBLY__ guards, but it also
      got caught in pre-processor hell accidentally matching the else case of
      CONFIG_BUG resulting in the BUG disabled case tripping up on
      -Werror=implicit-function-declaration.
      
      It's not possible to __ASSEMBLY__ guard the entire file as architecture
      code needs to get at the BUGFLAG_WARNING definition in the GENERIC_BUG
      case, but the rest of the CONFIG_BUG=y/n case needs to be guarded.
      
      Rather than littering endless __ASSEMBLY__ checks in each of the if/else
      cases we just move the BUGFLAG definitions up under their own
      GENERIC_BUG test and then shove everything else under one big
      __ASSEMBLY__ guard.
      
      Build tested on all of x86 CONFIG_BUG=y, CONFIG_BUG=n, powerpc (due to
      it's dependence on BUGFLAG definitions in assembly code), and sh (due to
      not bringing in linux/kernel.h to satisfy the taint flag definitions used
      by the generic bug code).
      
      Hopefully that's the end of the corner cases and I can abstain from ever
      having to touch this infernal header ever again.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Tested-by: NFengguang Wu <wfg@linux.intel.com>
      Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09682c1d
  9. 23 6月, 2012 3 次提交
    • M
      mfd: arizona: Core driver · 3cc72986
      Mark Brown 提交于
      Several forthcoming Wolfson devices are based on a common platform
      known as Arizona allowing a great deal of reuse of driver code. This
      patch adds core support for these devices.
      
      In order to handle systems which do not use the generic clock API a
      simple wrapper for the 32kHz clock domain in the devices is provided.
      Once the generic clock API is widely available this code will be moved
      over to use that.
      
      For simplicity some WM5102 specific code is included in the core driver,
      the effort involved in splitting the device out isn't worth it.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      3cc72986
    • M
      mfd: arizona: Register definitions · c46a019a
      Mark Brown 提交于
      Several forthcoming Wolfson devices are based on a common platform
      known as Arizona allowing a great deal of reuse of driver code. This
      patch adds register definitions for these devices.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      c46a019a
    • A
      SCSI & usb-storage: add try_rc_10_first flag · 6a0bdffa
      Alan Stern 提交于
      Several bug reports have been received recently for USB mass-storage
      devices that don't handle READ CAPACITY(16) commands properly.  They
      report bogus sizes, in some cases becoming unusable as a result.
      
      The bugs were triggered by commit
      09b6b51b (SCSI & usb-storage: add
      flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
      overriding the SCSI level reported by devices.  By default, the sd
      driver will try READ CAPACITY(16) first for any device whose level is
      above SCSI_SPC_2.
      
      It seems likely that any device large enough to require the use of
      READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
      CAPACITY(10) commands properly.  Indeed, I don't know of any devices
      that don't handle READ CAPACITY(10) properly.
      
      Therefore this patch (as1559) adds a new flag telling the sd driver
      to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
      for every USB mass-storage device.  If a device really is larger than
      2 TB, sd will fall back to READ CAPACITY(16) just as it used to.
      
      This fixes Bugzilla #43391.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      CC: "James E.J. Bottomley" <JBottomley@parallels.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a0bdffa
  10. 22 6月, 2012 1 次提交
  11. 21 6月, 2012 4 次提交
  12. 19 6月, 2012 2 次提交