1. 12 1月, 2016 1 次提交
  2. 27 11月, 2015 1 次提交
  3. 25 11月, 2015 1 次提交
    • F
      rtc: ds1307: fix kernel splat due to wakeup irq handling · 51c4cfef
      Felipe Balbi 提交于
      Since commit 3fffd128 ("i2c: allow specifying
      separate wakeup interrupt in device tree") we have
      automatic wakeup irq support for i2c devices. That
      commit missed the fact that rtc-1307 had its own
      wakeup irq handling and ended up introducing a
      kernel splat for at least Beagle x15 boards.
      
      Fix that by reverting original commit _and_ passing
      correct interrupt names on DTS so i2c-core can
      choose correct IRQ as wakeup.
      
      Now that we have automatic wakeirq support, we can
      revert the original commit which did it manually.
      
      Fixes the following warning:
      
      [   10.346582] WARNING: CPU: 1 PID: 263 at linux/drivers/base/power/wakeirq.c:43 dev_pm_attach_wake_irq+0xbc/0xd4()
      [   10.359244] rtc-ds1307 2-006f: wake irq already initialized
      
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      51c4cfef
  4. 08 11月, 2015 1 次提交
  5. 05 9月, 2015 6 次提交
  6. 25 6月, 2015 1 次提交
    • N
      rtc: ds1307: Enable the mcp794xx alarm after programming time · e3edd671
      Nishanth Menon 提交于
      Alarm interrupt enable register is at offset 0x7, while the time
      registers for the alarm follow that. When we program Alarm interrupt
      enable prior to programming the time, it is possible that previous
      time value could be close or match at the time of alarm enable
      resulting in interrupt trigger which is unexpected (and does not match
      the time we expect it to trigger).
      
      To prevent this scenario from occuring, program the ALM0_EN bit only
      after the alarm time is appropriately programmed.
      
      Ofcourse, I2C programming is non-atomic, so there are loopholes where
      the interrupt wont trigger if the time requested is in the past at
      the time of programming the ALM0_EN bit. However, we will not have
      unexpected interrupts while the time is programmed after the interrupt
      are enabled.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Reviewed-by: NGrygorii Strashko <grygorii.strashko@linaro.org>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      e3edd671
  7. 11 12月, 2014 1 次提交
  8. 14 10月, 2014 1 次提交
    • M
      rtc: ds1307: add trickle charger device tree binding · 33b04b7b
      Matti Vaittinen 提交于
      Some DS13XX devices have "trickle chargers".  Introduce a device tree
      binding for specifying the trickle charger configuration for ds1339.
      
      Only ds1339 dt binding is supported because this is the only chip I have.
      I _assume_ the code would have worked on other allready supported chips.
      However I cannot check the resistor values for the other chips or test
      them.  For other chips the driver code works as earlier Eg.  it does not
      check the dt bindings at all
      Signed-off-by: NMatti Vaittinen <matti.vaittinen@nsn.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Pavel Machek <pavel@denx.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      33b04b7b
  9. 04 4月, 2014 3 次提交
  10. 13 11月, 2013 3 次提交
  11. 04 7月, 2013 1 次提交
  12. 30 4月, 2013 3 次提交
  13. 22 2月, 2013 1 次提交
  14. 04 1月, 2013 1 次提交
    • G
      Drivers: rtc: remove __dev* attributes. · 5a167f45
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Mike Frysinger <vapier.adi@gmail.com>
      Cc: Wan ZongShun <mcuos.com@gmail.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a167f45
  15. 30 5月, 2012 2 次提交
  16. 26 4月, 2012 1 次提交
    • A
      drivers/rtc/rtc-ds1307.c: fix BUG shown with lock debugging enabled · 3f5ec5e0
      Anatolij Gustschin 提交于
      Add struct bin_attribute initialization to fix the following bug:
      
      rtc-ds1307 3-0068: rtc core: registered ds1307 as rtc0
      BUG: key cfb14fcc not in .data!
      ------------[ cut here ]------------
      WARNING: at kernel/lockdep.c:2986 sysfs_add_file_mode+0x84/0xdc()
      Modules linked in:
      [<c0018d94>] (unwind_backtrace+0x0/0xf8) from [<c0031f7c>] (warn_slowpath_common+0x4c/0x64)
      [<c0031f7c>] (warn_slowpath_common+0x4c/0x64) from [<c0031fb0>] (warn_slowpath_null+0x1c/0x24)
      [<c0031fb0>] (warn_slowpath_null+0x1c/0x24) from [<c012f7ac>] (sysfs_add_file_mode+0x84/0xdc)
      [<c012f7ac>] (sysfs_add_file_mode+0x84/0xdc) from [<c04b11e4>] (ds1307_probe+0x5e4/0x6ac)
      [<c04b11e4>] (ds1307_probe+0x5e4/0x6ac) from [<c036e600>] (i2c_device_probe+0xdc/0x108)
      [<c036e600>] (i2c_device_probe+0xdc/0x108) from [<c02cdf84>] (driver_probe_device+0x90/0x210)
      [<c02cdf84>] (driver_probe_device+0x90/0x210) from [<c02ce198>] (__driver_attach+0x94/0x98)
      [<c02ce198>] (__driver_attach+0x94/0x98) from [<c02cc824>] (bus_for_each_dev+0x50/0x7c)
      [<c02cc824>] (bus_for_each_dev+0x50/0x7c) from [<c02cd780>] (bus_add_driver+0x184/0x244)
      [<c02cd780>] (bus_add_driver+0x184/0x244) from [<c02ce43c>] (driver_register+0x78/0x12c)
      [<c02ce43c>] (driver_register+0x78/0x12c) from [<c03701ac>] (i2c_register_driver+0x2c/0xb4)
      [<c03701ac>] (i2c_register_driver+0x2c/0xb4) from [<c0008798>] (do_one_initcall+0x34/0x178)
      [<c0008798>] (do_one_initcall+0x34/0x178) from [<c0691860>] (kernel_init+0xdc/0x194)
      [<c0691860>] (kernel_init+0xdc/0x194) from [<c0013cf0>] (kernel_thread_exit+0x0/0x8)
      
      Since commit 6992f533 ("sysfs: Use one lockdep class per sysfs
      attribute") this initialization is required.
      Reported-by: NStefano Babic <sbabic@denx.de>
      Tested-by: NStefano Babic <sbabic@denx.de>
      Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Acked-by: NWolfram Sang <w.sang@pengutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3f5ec5e0
  17. 24 3月, 2012 5 次提交
  18. 03 11月, 2011 1 次提交
  19. 28 6月, 2011 1 次提交
  20. 04 2月, 2011 1 次提交
  21. 11 1月, 2011 1 次提交
  22. 30 6月, 2010 1 次提交
  23. 22 5月, 2010 1 次提交
  24. 18 12月, 2009 1 次提交
    • A
      rtc: set wakeup capability for I2C and SPI RTC drivers · 26b3c01f
      Anton Vorontsov 提交于
      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: NAnton 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26b3c01f