1. 21 Sep, 2011 7 commits
    • Mathieu J. Poirier's avatar
      hwspinlock/u8500: add hwspinlock driver · f84a8ecf
      Mathieu J. Poirier authored
      Add hwspinlock driver for U8500's Hsem hardware.
      
      At this point only HSem's protocol 1 is used (i.e. no interrupts).
      Signed-off-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [ohad@wizery.com: adopt recent hwspin_lock_{un}register API changes]
      [ohad@wizery.com: set the owner member of the driver]
      [ohad@wizery.com: mark ->remove() function as __devexit]
      [ohad@wizery.com: write commit log]
      [ohad@wizery.com: small cleanups]
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      f84a8ecf
    • Ohad Ben-Cohen's avatar
      hwspinlock/core: register a bank of hwspinlocks in a single API call · 300bab97
      Ohad Ben-Cohen authored
      Hardware Spinlock devices usually contain numerous locks (known
      devices today support between 32 to 256 locks).
      
      Originally hwspinlock core required drivers to register (and later,
      when needed, unregister) each lock separately.
      
      That worked, but required hwspinlocks drivers to do a bit extra work
      when they were probed/removed.
      
      This patch changes hwspin_lock_{un}register() to allow a bank of
      hwspinlocks to be {un}registered in a single invocation.
      
      A new 'struct hwspinlock_device', which contains an array of 'struct
      hwspinlock's is now being passed to the core upon registration (so
      instead of wrapping each struct hwspinlock, a priv member has been added
      to allow drivers to piggyback their private data with each hwspinlock).
      
      While at it, several per-lock members were moved to be per-device:
      1. struct device *dev
      2. struct hwspinlock_ops *ops
      
      In addition, now that the array of locks is handled by the core,
      there's no reason to maintain a per-lock 'int id' member: the id of the
      lock anyway equals to its index in the bank's array plus the bank's
      base_id.
      Remove this per-lock id member too, and instead use a simple pointers
      arithmetic to derive it.
      
      As a result of this change, hwspinlocks drivers are now simpler and smaller
      (about %20 code reduction) and the memory footprint of the hwspinlock
      framework is reduced.
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      300bab97
    • Juan Gutierrez's avatar
      hwspinlock/core: use a mutex to protect the radix tree · 93b465c2
      Juan Gutierrez authored
      Since we're using non-atomic radix tree allocations, we
      should be protecting the tree using a mutex and not a
      spinlock.
      
      Non-atomic allocations and process context locking is good enough,
      as the tree is manipulated only when locks are registered/
      unregistered/requested/freed.
      
      The locks themselves are still protected by spinlocks of course,
      and mutexes are not involved in the locking/unlocking paths.
      
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarJuan Gutierrez <jgutierrez@ti.com>
      [ohad@wizery.com: rewrite the commit log, #include mutex.h, add minor
      commentary]
      [ohad@wizery.com: update register/unregister parts in hwspinlock.txt]
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      93b465c2
    • Ohad Ben-Cohen's avatar
      hwspinlock/core/omap: fix id issues on multiple hwspinlock devices · c3c1250e
      Ohad Ben-Cohen authored
      hwspinlock devices provide system-wide hardware locks that are used
      by remote processors that have no other way to achieve synchronization.
      
      To achieve that, each physical lock must have a system-wide id number
      that is agreed upon, otherwise remote processors can't possibly assume
      they're using the same hardware lock.
      
      Usually boards have a single hwspinlock device, which provides several
      hwspinlocks, and in this case, they can be trivially numbered 0 to
      (num-of-locks - 1).
      
      In case boards have several hwspinlocks devices, a different base id
      should be used for each hwspinlock device (they can't all use 0 as
      a starting id!).
      
      While this is certainly not common, it's just plain wrong to just
      silently use 0 as a base id whenever the hwspinlock driver is probed.
      
      This patch provides a hwspinlock_pdata structure, that boards can use
      to set a different base id for each of the hwspinlock devices they may
      have, and demonstrates how to use it with the omap hwspinlock driver.
      
      While we're at it, make sure the hwspinlock core prints an explicit
      error message in case an hwspinlock is registered with an id number
      that already exists; this will help users catch such base id issues.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      c3c1250e
    • Ohad Ben-Cohen's avatar
      hwspinlock/omap: simplify allocation scheme · c97f6dd0
      Ohad Ben-Cohen authored
      Instead of allocating every hwspinlock separately, allocate
      them all in one shot.
      
      This both simplifies the driver and helps achieving better
      slab utilization.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      c97f6dd0
    • Ohad Ben-Cohen's avatar
      hwspinlock/core: simplify 'owner' handling · e467b642
      Ohad Ben-Cohen authored
      Use struct device_driver's owner member instead of asking drivers to
      explicitly pass the owner again.
      
      This simplifies drivers and also save some memory, since there's no
      point now in maintaining a separate owner pointer per hwspinlock.
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      e467b642
    • Ohad Ben-Cohen's avatar
      hwspinlock/core: simplify Kconfig · 315d8f5c
      Ohad Ben-Cohen authored
      Simplify hwspinlock's Kconfig by making the global CONFIG_HWSPINLOCK
      entry invisible; users will just select it when needed.
      
      This also prepares the ground for adding hwspinlock support for other
      platforms (the 'depends on ARCH_OMAP4' was rather hideous, and while
      we're at it, a dedicated menu is added).
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      315d8f5c
  2. 11 Sep, 2011 7 commits
  3. 10 Sep, 2011 5 commits
    • Randy Dunlap's avatar
      scsi: qla4xxx driver depends on NET · d7a210f3
      Randy Dunlap authored
      When CONFIG_NET is disabled, SCSI_QLA_ISCSI selects SCSI_ISCSI_ATTRS,
      which uses network interfaces, so the build fails with multiple errors:
      
        warning: (ISCSI_TCP && SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_QLA_ISCSI && INFINIBAND_ISER) selects SCSI_ISCSI_ATTRS which has unmet direct dependencies (SCSI && NET)
      
        ERROR: "skb_trim" [drivers/scsi/scsi_transport_iscsi.ko] undefined!
        ERROR: "netlink_kernel_create" [drivers/scsi/scsi_transport_iscsi.ko] undefined!
        ERROR: "netlink_kernel_release" [drivers/scsi/scsi_transport_iscsi.ko] undefined!
        ...
      
      so make SCSI_QLA_ISCSI also depend on NET to prevent the build errors.
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Cc:	Ravi Anand <ravi.anand@qlogic.com>
      Cc:	Vikas Chaudhary <vikas.chaudhary@qlogic.com>
      Cc:	iscsi-driver@qlogic.com
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d7a210f3
    • Bart Van Assche's avatar
      backlight: Declare backlight_types[] const · c338bfb5
      Bart Van Assche authored
      Since backlight_types[] isn't modified, let's declare it const.  That
      was probably the intention of the author of commit bb7ca747
      ("backlight: add backlight type"), via which the "const char const *"
      construct was introduced.  The duplicate const was detected by sparse.
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c338bfb5
    • NeilBrown's avatar
      md: Fix handling for devices from 2TB to 4TB in 0.90 metadata. · 27a7b260
      NeilBrown authored
      0.90 metadata uses an unsigned 32bit number to count the number of
      kilobytes used from each device.
      This should allow up to 4TB per device.
      However we multiply this by 2 (to get sectors) before casting to a
      larger type, so sizes above 2TB get truncated.
      
      Also we allow rdev->sectors to be larger than 4TB, so it is possible
      for the array to be resized larger than the metadata can handle.
      So make sure rdev->sectors never exceeds 4TB when 0.90 metadata is in
      used.
      
      Also the sanity check at the end of super_90_load should include level
      1 as it used ->size too. (RAID0 and Linear don't use ->size at all).
      Reported-by: default avatarPim Zandbergen <P.Zandbergen@macroscoop.nl>
      Cc: stable@kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      27a7b260
    • NeilBrown's avatar
      md/raid1,10: Remove use-after-free bug in make_request. · 079fa166
      NeilBrown authored
      A single request to RAID1 or RAID10 might result in multiple
      requests if there are known bad blocks that need to be avoided.
      
      To detect if we need to submit another write request we test:
       	if (sectors_handled < (bio->bi_size >> 9)) {
      
      However this is after we call **_write_done() so the 'bio' no longer
      belongs to us - the writes could have completed and the bio freed.
      
      So move the **_write_done call until after the test against
      bio->bi_size.
      
      This addresses https://bugzilla.kernel.org/show_bug.cgi?id=41862Reported-by: default avatarBruno Wolff III <bruno@wolff.to>
      Tested-by: default avatarBruno Wolff III <bruno@wolff.to>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      079fa166
    • NeilBrown's avatar
      md/raid10: unify handling of write completion. · 19d5f834
      NeilBrown authored
      A write can complete at two different places:
      1/ when the last member-device write completes, through
         raid10_end_write_request
      2/ in make_request() when we remove the initial bias from ->remaining.
      
      These two should do exactly the same thing and the comment says they
      do, but they don't.
      
      So factor the correct code out into a function and call it in both
      places.  This makes the code much more similar to RAID1.
      
      The difference is only significant if there is an error, and they
      usually take a while, so it is unlikely that there will be an error
      already when make_request is completing, so this is unlikely to cause
      real problems.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      19d5f834
  4. 09 Sep, 2011 8 commits
  5. 07 Sep, 2011 2 commits
  6. 06 Sep, 2011 7 commits
  7. 05 Sep, 2011 4 commits