1. 13 Nov, 2009 1 commit
  2. 11 Nov, 2009 1 commit
  3. 14 Oct, 2009 1 commit
  4. 11 Nov, 2009 1 commit
  5. 10 Nov, 2009 2 commits
  6. 25 Sep, 2009 1 commit
  7. 21 Nov, 2008 1 commit
    • Warren Turkal's avatar
      This is a patchset to change the way that the HFS+ filesystem detects · fced310a
      Warren Turkal authored
      whether a volume has a journal or not.
      
      The code currently mounts an HFS+ volume read-only by default when a
      journal is detected.  One can force a read/write mount by giving the
      "force" mount option.  The current code has this behavior since there is
      no support for the HFS+ journal.
      
      My problem is that the detection of the journal could be better.  The
      current code tests the attribute bit in the volume header that indicates
      there is a journal.  If that bit is set, the code assumes that there is a
      journal.
      
      Unfortunately, this is not enough to really determine if there is a
      journal or not.  When that bit is set, one must also examine the journal
      info block field of the volume header.  If this field is 0, there is no
      journal, and the volume can be mounted read/write.
      
      
      This patch:
      
      The HFS+ support in the kernel currently will mount an HFS+ volume
      read-only if the volume header has the attribute bit set that indicates
      there is a journal.  The kernel does this because there is no support for
      a journalled HFS+ volume.
      
      The problem is that this is only half of what needs to be checked to see
      if there really is a journal.  There is also an entry in the volume header
      that tells you where to find the journal info block.  In the kernel
      version of the kernel, this 4 byte block is labeled reserved.  This patch
      identifies the journal info block in the header.
      Signed-off-by: default avatarWarren Turkal <wt@penguintechs.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      fced310a
  8. 03 Nov, 2009 2 commits
  9. 16 Oct, 2009 1 commit
  10. 17 Sep, 2009 1 commit
  11. 13 Nov, 2009 1 commit
  12. 10 Nov, 2009 1 commit
  13. 16 Nov, 2009 1 commit
  14. 11 Nov, 2009 1 commit
  15. 03 Nov, 2009 5 commits
  16. 14 Oct, 2009 1 commit
  17. 24 Sep, 2009 2 commits
  18. 14 Oct, 2009 1 commit
  19. 24 Sep, 2009 1 commit
  20. 25 Sep, 2009 1 commit
  21. 17 Nov, 2009 1 commit
  22. 10 Nov, 2009 1 commit
  23. 14 Oct, 2009 1 commit
  24. 26 Oct, 2009 1 commit
  25. 11 Nov, 2009 1 commit
    • Anton Vorontsov's avatar
      RTC core won't allow wakeup alarms to be set if RTC devices' parent (i.e. · e3a8f086
      Anton Vorontsov authored
      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>
      e3a8f086
  26. 10 Nov, 2009 1 commit
  27. 04 Nov, 2009 1 commit
  28. 16 Oct, 2009 2 commits
    • Atsushi Nemoto's avatar
      The to_platform_device macro itself uses container_of macro. Nested use · 2bc3fb6c
      Atsushi Nemoto authored
      of container_of macro causes following sparse warnings:
      
      rtc-ds1553.c:259:3: warning: symbol '__mptr' shadows an earlier one
      rtc-ds1553.c:259:3: originally declared here
      Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Andrew Sharp <andy.sharp@lsi.com>
      Cc: Thomas Hommel <thomas.hommel@gefanuc.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      2bc3fb6c
    • Atsushi Nemoto's avatar
      - Call dev_set_drvdata before rtc device creation. · d9318a9d
      Atsushi Nemoto authored
      - Use its own spinlock instead of rtc->irq_lock.  Because pdata->rtc
        must be initialized to use the irq_lock (pdata->rtc->irq_lock).  There
        is a small window which rtc methods can be called before pdata->rtc is
        initialized.
      
        And there is no need use the irq_lock to protect hardware registers.
        The driver's own spinlock shoule be enough.
      
      - Check pdata->rtc before calling rtc_update_irq.
      
      - Use alarm_irq_enable and remove ioctl routine.
      
      - Use devres APIs and simplify error/remove path.
      
      These fixes are ported from ds1553 driver and just compile-tested only.
      Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
      Cc: Thomas Hommel <thomas.hommel@gefanuc.com>
      Cc: David Brownell <david-b@pacbell.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      d9318a9d
  29. 12 Oct, 2009 4 commits