1. 09 Mar, 2011 2 commits
    • John Stultz's avatar
      RTC: Cleanup rtc_class_ops->irq_set_state · 80d4bb51
      John Stultz authored
      With PIE mode interrupts now emulated in generic code via an hrtimer,
      no one calls rtc_class_ops->irq_set_state(), so this patch removes it
      along with driver implementations.
      
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Alessandro Zummo <a.zummo@towertech.it>
      CC: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
      CC: rtc-linux@googlegroups.com
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      80d4bb51
    • John Stultz's avatar
      RTC: Initialize kernel state from RTC · f44f7f96
      John Stultz authored
      Mark Brown pointed out a corner case: that RTC alarms should
      be allowed to be persistent across reboots if the hardware
      supported it.
      
      The rework of the generic layer to virtualize the RTC alarm
      virtualized much of the alarm handling, and removed the
      code used to read the alarm time from the hardware.
      
      Mark noted if we want the alarm to be persistent across
      reboots, we need to re-read the alarm value into the
      virtualized generic layer at boot up, so that the generic
      layer properly exposes that value.
      
      This patch restores much of the earlier removed
      rtc_read_alarm code and wires it in so that we
      set the kernel's alarm value to what we find in the
      hardware at boot time.
      
      NOTE: Not all hardware supports persistent RTC alarm state across
      system reset. rtc-cmos for example will keep the alarm time, but
      disables the AIE mode irq. Applications should not expect the RTC
      alarm to be valid after a system reset. We will preserve what
      we can, to represent the hardware state at boot, but its not
      guarenteed.
      
      Further, in the future, with multiplexed RTC alarms, the
      soonest alarm to fire may not be the one set via the /dev/rt
      ioctls. So an application may set the alarm with RTC_ALM_SET,
      but after a reset find that RTC_ALM_READ returns an earlier
      time. Again, we preserve what we can, but applications should
      not expect the RTC alarm state to persist across a system reset.
      
      Big thanks to Mark for pointing out the issue!
      Thanks also to Marcelo for helping think through the solution.
      
      CC: Mark Brown <broonie@opensource.wolfsonmicro.com>
      CC: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Alessandro Zummo <a.zummo@towertech.it>
      CC: rtc-linux@googlegroups.com
      Reported-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      f44f7f96
  2. 08 Mar, 2011 5 commits
  3. 07 Mar, 2011 9 commits
  4. 06 Mar, 2011 5 commits
  5. 05 Mar, 2011 17 commits
  6. 04 Mar, 2011 2 commits
    • Sage Weil's avatar
      ceph: no .snap inside of snapped namespace · 455cec0a
      Sage Weil authored
      Otherwise you can do things like
      
      # mkdir .snap/foo
      # cd .snap/foo/.snap
      # ls
      <badness>
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      455cec0a
    • Sage Weil's avatar
      libceph: fix msgr standby handling · e00de341
      Sage Weil authored
      The standby logic used to be pretty dependent on the work requeueing
      behavior that changed when we switched to WQ_NON_REENTRANT.  It was also
      very fragile.
      
      Restructure things so that:
       - We clear WRITE_PENDING when we set STANDBY.  This ensures we will
         requeue work when we wake up later.
       - con_work backs off if STANDBY is set.  There is nothing to do if we are
         in standby.
       - clear_standby() helper is called by both con_send() and con_keepalive(),
         the two actions that can wake us up again.  Move the connect_seq++
         logic here.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      e00de341