1. 30 6月, 2006 2 次提交
  2. 29 6月, 2006 1 次提交
  3. 27 6月, 2006 1 次提交
  4. 23 6月, 2006 1 次提交
  5. 20 6月, 2006 2 次提交
  6. 13 6月, 2006 1 次提交
  7. 18 5月, 2006 1 次提交
    • S
      [PATCH] sbp2: consolidate workarounds · 24d3bf88
      Stefan Richter 提交于
      Grand unification of the three types of workarounds we have so far.
      
      The "skip mode page 8" workaround is now limited to devices which
      pretend to be of TYPE_DISK instead of TYPE_RBC. This workaround is no
      longer enabled for Initio bridges.
      
      Patch update in anticipation of more workarounds:
       - Add module parameter "workarounds".
       - Deprecate parameter "force_inquiry_hack".
       - Compose the blacklist of a compound type for better readability and
         extensibility.
       - Remove a now unused #define.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      24d3bf88
  8. 20 4月, 2006 1 次提交
  9. 11 4月, 2006 1 次提交
  10. 01 4月, 2006 2 次提交
  11. 26 3月, 2006 1 次提交
    • T
      [PATCH] Validate and sanitze itimer timeval from userspace · 7d99b7d6
      Thomas Gleixner 提交于
      According to the specification the timevals must be validated and an
      errorcode -EINVAL returned in case the timevals are not in canonical form.
      This check was never done in Linux.
      
      The pre 2.6.16 code converted invalid timevals silently.  Negative timeouts
      were converted by the timeval_to_jiffies conversion to the maximum timeout.
      
      hrtimers and the ktime_t operations expect timevals in canonical form.
      Otherwise random results might happen on 32 bits machines due to the
      optimized ktime_add/sub operations.  Negative timeouts are treated as
      already expired.  This might break applications which work on pre 2.6.16.
      
      To prevent random behaviour and API breakage the timevals are checked and
      invalid timevals sanitized in a simliar way as the pre 2.6.16 code did.
      
      Invalid timevals are reported with a per boot limited number of kernel
      messages so applications which use this misfeature can be corrected.
      
      After a grace period of one year the sanitizing should be replaced by a
      correct validation check.  This is also documented in
      Documentation/feature-removal-schedule.txt
      
      The validation and sanitizing is done inside do_setitimer so all callers
      (sys_setitimer, compat_sys_setitimer, osf_setitimer) are catched.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7d99b7d6
  12. 24 3月, 2006 3 次提交
  13. 21 3月, 2006 1 次提交
  14. 10 3月, 2006 1 次提交
  15. 23 2月, 2006 1 次提交
    • G
      Revert mount/umount uevent removal · fa675765
      Greg Kroah-Hartman 提交于
      This change reverts the 033b96fd commit
      from Kay Sievers that removed the mount/umount uevents from the kernel.
      Some older versions of HAL still depend on these events to detect when a
      new device has been mounted.  These events are not correctly emitted,
      and are broken by design, and so, should not be relied upon by any
      future program.  Instead, the /proc/mounts file should be polled to
      properly detect this kind of event.
      
      A feature-removal-schedule.txt entry has been added, noting when this
      interface will be removed from the kernel.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fa675765
  16. 07 2月, 2006 2 次提交
    • B
      [netdrvr] schedule eepro100 for removal · c0d3c0c0
      Bunk 提交于
      c0d3c0c0
    • J
      [PATCH] hwmon: Fix reboot on it87 driver load · c5e3fbf2
      Jean Delvare 提交于
      Only scan I2C address 0x2d. This is the default address and no IT87xxF
      chip was ever seen on I2C at a different address. These chips are
      better accessed through their ISA interface anyway.
      
      This fixes bug #5889, although it doesn't address the whole class
      of problems. We'd need the ability to blacklist arbitrary I2C addresses
      on systems known to contain I2C devices which behave badly when probed.
      
      Plan the I2C interface for removal as well. If nobody complains within
      a year, it will confirm my impression that the I2C interface isn't
      actually needed by anyone.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c5e3fbf2
  17. 01 2月, 2006 2 次提交
  18. 15 1月, 2006 1 次提交
  19. 06 1月, 2006 1 次提交
  20. 18 11月, 2005 2 次提交
  21. 16 11月, 2005 1 次提交
  22. 09 11月, 2005 3 次提交
  23. 07 11月, 2005 2 次提交
  24. 13 9月, 2005 1 次提交
  25. 11 9月, 2005 1 次提交
  26. 09 9月, 2005 1 次提交
  27. 08 9月, 2005 2 次提交
  28. 03 9月, 2005 1 次提交