1. 02 5月, 2011 1 次提交
  2. 29 4月, 2011 2 次提交
  3. 28 4月, 2011 2 次提交
  4. 26 4月, 2011 2 次提交
  5. 25 4月, 2011 2 次提交
  6. 24 4月, 2011 3 次提交
    • T
      libata: Implement ATA_FLAG_NO_DIPM and apply it to mcp65 · ae01b249
      Tejun Heo 提交于
      NVIDIA mcp65 familiy of controllers cause command timeouts when DIPM
      is used.  Implement ATA_FLAG_NO_DIPM and apply it.
      
      This problem was reported by Stefan Bader in the following thread.
      
       http://thread.gmane.org/gmane.linux.ide/48841
      
      stable: applicable to 2.6.37 and 38.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NStefan Bader <stefan.bader@canonical.com>
      Cc: stable@kernel.org
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      ae01b249
    • T
      libata: Kill unused ATA_DFLAG_{H|D}IPM flags · 3f7ac1d6
      Tejun Heo 提交于
      ATA_DFLAG_{H|D}IPM flags are no longer used.  Kill them.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      3f7ac1d6
    • L
      vfs: get rid of insane dentry hashing rules · dea3667b
      Linus Torvalds 提交于
      The dentry hashing rules have been really quite complicated for a long
      while, in odd ways.  That made functions like __d_drop() very fragile
      and non-obvious.
      
      In particular, whether a dentry was hashed or not was indicated with an
      explicit DCACHE_UNHASHED bit.  That's despite the fact that the hash
      abstraction that the dentries use actually have a 'is this entry hashed
      or not' model (which is a simple test of the 'pprev' pointer).
      
      The reason that was done is because we used the normal 'is this entry
      unhashed' model to mark whether the dentry had _ever_ been hashed in the
      dentry hash tables, and that logic goes back many years (commit
      b3423415: "dcache: avoid RCU for never-hashed dentries").
      
      That, in turn, meant that __d_drop had totally different unhashing logic
      for the dentry hash table case and for the anonymous dcache case,
      because in order to use the "is this dentry hashed" logic as a flag for
      whether it had ever been on the RCU hash table, we had to unhash such a
      dentry differently so that we'd never think that it wasn't 'unhashed'
      and wouldn't be free'd correctly.
      
      That's just insane.  It made the logic really hard to follow, when there
      were two different kinds of "unhashed" states, and one of them (the one
      that used "list_bl_unhashed()") really had nothing at all to do with
      being unhashed per se, but with a very subtle lifetime rule instead.
      
      So turn all of it around, and make it logical.
      
      Instead of having a DENTRY_UNHASHED bit in d_flags to indicate whether
      the dentry is on the hash chains or not, use the hash chain unhashed
      logic for that.  Suddenly "d_unhashed()" just uses "list_bl_unhashed()",
      and everything makes sense.
      
      And for the lifetime rule, just use an explicit DENTRY_RCUACCEES bit.
      If we ever insert the dentry into the dentry hash table so that it is
      visible to RCU lookup, we mark it DENTRY_RCUACCESS to show that it now
      needs the RCU lifetime rules.  Now suddently that test at dentry free
      time makes sense too.
      
      And because unhashing now is sane and doesn't depend on where the dentry
      got unhashed from (because the dentry hash chain details doesn't have
      some subtle side effects), we can re-unify the __d_drop() logic and use
      common code for the unhashing.
      
      Also fix one more open-coded hash chain bit_spin_lock() that I missed in
      the previous chain locking cleanup commit.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dea3667b
  7. 23 4月, 2011 1 次提交
  8. 19 4月, 2011 6 次提交
  9. 18 4月, 2011 5 次提交
  10. 16 4月, 2011 1 次提交
    • J
      block: let io_schedule() flush the plug inline · a237c1c5
      Jens Axboe 提交于
      Linus correctly observes that the most important dispatch cases
      are now done from kblockd, this isn't ideal for latency reasons.
      The original reason for switching dispatches out-of-line was to
      avoid too deep a stack, so by _only_ letting the "accidental"
      flush directly in schedule() be guarded by offload to kblockd,
      we should be able to get the best of both worlds.
      
      So add a blk_schedule_flush_plug() that offloads to kblockd,
      and only use that from the schedule() path.
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      a237c1c5
  11. 15 4月, 2011 7 次提交
  12. 14 4月, 2011 1 次提交
  13. 13 4月, 2011 4 次提交
    • J
      Input: evdev - indicate buffer overrun with SYN_DROPPED · 9fb0f14e
      Jeff Brown 提交于
      Add a new EV_SYN code, SYN_DROPPED, to inform the client when input
      events have been dropped from the evdev input buffer due to a
      buffer overrun.  The client should use this event as a hint to
      reset its state or ignore all following events until the next
      packet begins.
      Signed-off-by: NJeff Brown <jeffbrown@android.com>
      [dtor@mail.ru: Implement Henrik's suggestion and drop old events in
       case of overflow.]
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      9fb0f14e
    • J
      Input: add KEY_IMAGES specifically for AL Image Browser · ba6a078b
      Jarod Wilson 提交于
      Many media center remotes have buttons intended for jumping straight to
      one type of media browser or another -- commonly, images/photos/pictures,
      audio/music, television, and movies. At present, remotes with an images
      or photos or pictures button use any number of different keycodes which
      sort of maybe fit. I've seen at least KEY_MEDIA, KEY_CAMERA,
      KEY_GRAPHICSEDITOR and KEY_PRESENTATION. None of those seem quite right.
      In my mind, KEY_MEDIA should be something more like a media center
      application launcher (and I'd like to standardize on that for things
      like the windows media center button on the mce remotes). KEY_CAMERA is
      used in a lot of webcams, and typically means "take a picture now".
      KEY_GRAPHICSEDITOR implies an editor, not a browser. KEY_PRESENTATION
      might be the closest fit here, if you think "photo slide show", but it
      may well be more intended for "run application in full-screen
      presentation mode" or to launch something like magicpoint, I dunno.
      And thus, I'd like to have a KEY_IMAGES, which matches the HID Usage AL
      Image Browser, the meaning of which I think is crystal-clear. I believe
      AL Audio Browser is already covered by KEY_AUDIO, and AL Movie Browser
      by KEY_VIDEO, so I'm also adding appropriate comments next to those
      keys.
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      ba6a078b
    • L
      vfs: Re-introduce s_uuid in the superblock · 0bba0169
      Linus Torvalds 提交于
      Gaah.  When commit be85bcca reverted the export of file system uuid
      via /proc/<pid>/mountinfo, it also unintentionally removed the s_uuid
      field in struct super_block.
      
      I didn't mean to do that, since filesystems have been taught to fill it
      in (and we want to keep it for future re-introduction in the mountinfo
      file).
      
      Stupid of me. This adds it back in.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0bba0169
    • L
      Revert "vfs: Export file system uuid via /proc/<pid>/mountinfo" · be85bcca
      Linus Torvalds 提交于
      This reverts commit 93f1c20b.
      
      It turns out that libmount misparses it because it adds a '-' character
      in the uuid string, which libmount then incorrectly confuses with the
      separator string (" - ") at the end of all the optional arguments.
      
      Upstream libmount (in the util-linux tree) has been fixed, but until
      that fix actually percolates up to users, we'd better not expose this
      change in the kernel.
      
      Let's revisit this later (possibly by exposing the UUID without any '-'
      characters in it, avoiding the user-space bug).
      Reported-by: NDave Jones <davej@redhat.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Karel Zak <kzak@redhat.com>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Miklos Szeredi <mszeredi@suse.cz>
      Cc: Eric Sandeen <sandeen@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      be85bcca
  14. 12 4月, 2011 3 次提交
    • S
      mfd: Fetch cell pointer from platform_device->mfd_cell · e710d7d5
      Samuel Ortiz 提交于
      In order for MFD drivers to fetch their cell pointer but also their
      platform data one, an mfd cell pointer is added to the platform_device
      structure.
      That allows all MFD sub devices drivers to be MFD agnostic, unless
      they really need to access their MFD cell data. Most of them don't,
      especially the ones for IPs used by both MFD and non MFD SoCs.
      
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Acked-by: NGreg KH <gregkh@suse.de>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      e710d7d5
    • J
      block: add callback function for unplug notification · f7566457
      Jens Axboe 提交于
      MD would like to know when a queue is unplugged, so it can flush
      it's bitmap writes. Add such a callback.
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      f7566457
    • R
      PM / Hibernate: Introduce CONFIG_HIBERNATE_CALLBACKS · 1f112cee
      Rafael J. Wysocki 提交于
      Xen save/restore is going to use hibernate device callbacks for
      quiescing devices and putting them back to normal operations and it
      would need to select CONFIG_HIBERNATION for this purpose.  However,
      that also would cause the hibernate interfaces for user space to be
      enabled, which might confuse user space, because the Xen kernels
      don't support hibernation.  Moreover, it would be wasteful, as it
      would make the Xen kernels include a substantial amount of code that
      they would never use.
      
      To address this issue introduce new power management Kconfig option
      CONFIG_HIBERNATE_CALLBACKS, such that it will only select the code
      that is necessary for the hibernate device callbacks to work and make
      CONFIG_HIBERNATION select it.  Then, Xen save/restore will be able to
      select CONFIG_HIBERNATE_CALLBACKS without dragging the entire
      hibernate code along with it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Tested-by: NShriram Rajagopalan <rshriram@cs.ubc.ca>
      1f112cee
新手
引导
客服 返回
顶部