1. 25 May, 2010 3 commits
  2. 21 May, 2010 2 commits
  3. 19 May, 2010 1 commit
  4. 16 May, 2010 1 commit
  5. 06 May, 2010 2 commits
  6. 14 Apr, 2010 2 commits
  7. 07 Apr, 2010 1 commit
  8. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      The script does the followings.
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      * When the script inserts a new include, it looks at the include
  9. 24 Mar, 2010 1 commit
  10. 14 Mar, 2010 1 commit
    • Wolfram Sang's avatar
      init dynamic bin_attribute structures · f937331b
      Wolfram Sang authored
      Commit 6992f533
       ("sysfs: Use one lockdep
      class per sysfs attribute.") introduced this requirement.  First, at25
      was fixed manually.  Then, other occurences were found with coccinelle
      and the following semantic patch.  Results were reviewed and fixed up:
          @ init @
          identifier struct_name, bin;
          	struct struct_name {
          		struct bin_attribute bin;
          @ main extends init @
          expression E;
          statement S;
          identifier name, err;
          	struct struct_name *name;
          -	struct struct_name *name = NULL;
          +	struct struct_name *name;
          +	sysfs_bin_attr_init(&name->bin);
          	if (sysfs_create_bin_file(E, &name->bin))
          +	sysfs_bin_attr_init(&name->bin);
          	err = sysfs_create_bin_file(E, &name->bin);
      Signed-off-by: default avatarWolfram Sang <w.sang@pengutronix.de>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  11. 12 Mar, 2010 1 commit
  12. 07 Mar, 2010 3 commits
  13. 06 Mar, 2010 10 commits
  14. 16 Feb, 2010 1 commit
  15. 04 Feb, 2010 1 commit
  16. 02 Feb, 2010 1 commit
  17. 11 Jan, 2010 1 commit
  18. 17 Dec, 2009 1 commit
    • Anton Vorontsov's avatar
      rtc: set wakeup capability for I2C and SPI RTC drivers · 26b3c01f
      Anton Vorontsov authored
      RTC core won't allow wakeup alarms to be set if RTC devices' parent (i.e.
      i2c_client or spi_device) isn't wakeup capable.
      For I2C devices there is I2C_CLIENT_WAKE flag exists that we can pass via
      board info, and if set, I2C core will initialize wakeup capability.  For
      SPI devices there is no such flag at all.
      I believe that it's not platform code responsibility to allow or disallow
      wakeups, instead, drivers themselves should set the capability if a device
      can trigger wakeups.
      That's what drivers/base/power/sysfs.c says:
       * It is the responsibility of device drivers to enable (or disable)
       * wakeup signaling as part of changing device power states, respecting
       * the policy choices provided through the driver model.
      I2C and SPI RTC devices send wakeup events via interrupt lines, so we
      should set the wakeup capability if IRQ is routed.
      Ideally we should also check irq for wakeup capability before setting
      device's capability, i.e.
      	if (can_irq_wake(irq))
      		device_set_wakeup_capable(&client->dev, 1);
      But there is no can_irq_wake() call exist, and it is not that trivial to
      implement it for all interrupts controllers and complex/cascaded setups.
      drivers/base/power/sysfs.c also covers these cases:
       * Devices may not be able to generate wakeup events from all power
       * states.  Also, the events may be ignored in some configurations;
       * for example, they might need help from other devices that aren't
       * active
      So there is no guarantee that wakeup will actually work, and so I think
      there is no point in being pedantic wrt checking IRQ wakeup capability.
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  19. 16 Dec, 2009 6 commits