Skip to content

L
linux
Switch branch/tag
  1. 28 Jul, 2016 5 commits
  3. 27 Jul, 2016 1 commit
  5. 25 Jul, 2016 1 commit
  7. 21 Jul, 2016 2 commits
  9. 19 Jul, 2016 8 commits
  11. 11 Jul, 2016 8 commits
  13. 09 Jul, 2016 3 commits
  15. 08 Jul, 2016 1 commit
  17. 27 Jun, 2016 4 commits
  19. 26 Jun, 2016 3 commits
    • Andrey Smirnov's avatar
      rtc: rtctest: Change no IRQ detection for RTC_IRQP_SET · 0a553cba
      Andrey Smirnov authored 
      A call to ioctl(..., RTC_IRQP_SET, ...) should never result in
ENOTTY. All new style RTC drivers implement it and all of the old style
drivers return EINVAL when they don't support periodic IRQs.
Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      0a553cba
    • Andrey Smirnov's avatar
      rtc: rtctest: Change no IRQ detection for RTC_IRQP_READ · 519efa98
      Andrey Smirnov authored 
      A call to ioctl(..., RTC_IRQP_READ, ...) should never result in
ENOTTY. All new style RTC drivers implement it and all of the old style
drivers return EINVAL when they don't support periodic IRQs.
Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      519efa98
    • Andrey Smirnov's avatar
      rtc: rtctest: Change alarm IRQ support detection · cd26fca2
      Andrey Smirnov authored 
      For old style drivers, call a call to ioctl(..., RTC_ALM_SET, ...):

    - char/ds1302.c will always return -EINVAL
    - char/genrtc.c: will always return -EINVAL
    - char/rtc.c will succeed regardless if IRQs are supported or not
    - char/efirtc.c will always return -EINVAL
    - input/misc/hp_sdc_rtc.c ... that ioctl code is a good lesson about
      ifdefing code out and punting implementation ... and it will
      always return -EINVAL

For new style rtc drivers, a call to ioctl(..., RTC_ALM_SET, ...) never
results in a call to __rtc_set_alarm, since struct rtc_wkalarm passed to
rtc_set_alarm has 'enabled' field set to 0. This means that
rtc->ops->set_alarm driver hook is never called in that ioctl. Since no
driver code interaction happens as a part of that call, using its
results to ascertain properties of the driver is not going to work. To
remedy this - use the result of RTC_AIE_ON to make the judgement.

This patch also changes ENOTTY to EINVAL as an error code value that
would tell us that IRQs are not supported. There are three reason for
this:

 - As mentioned above old style driver never returns ENOTTY for this
   ioctl

 - In it's code __rtc_set_alarm() returns -EINVAL if rtc->ops->set_alarm
   method is not provided by the driver, so one reason for change is to
   be consistent with that code path.

 - A call to ioctl(..., RTC_UIE_ON, ...) will result in a call to
   rtc_update_irq_enable() and then __rtc_set_alarm(), which, if IRQs
   are not supported by the driver, will result in a non-zero error
   code. Returning ENOTTY in that case would:

   	 a) Not be consistent with other codepaths of
   	 rtc_update_irq_enable, for example the check of
   	 rtc->uie_unsupported

	 b) Would break update IRQ emulation code since that codpath
	 expects EINVAL

	 c) Would break test's logic for feature support detection in
	 the case of RTC_UIE_ON ioctl
Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      cd26fca2
  21. 25 Jun, 2016 3 commits
  23. 06 Jun, 2016 1 commit
    • Arnd Bergmann's avatar
      x86: include linux/ratelimit.h in nmi.c · c361db5c
      Arnd Bergmann authored 
      When building random configurations, we now occasionally get a new
build error:

   In file included from include/linux/kernel.h:13:0,
                    from include/linux/list.h:8,
                    from include/linux/preempt.h:10,
                    from include/linux/spinlock.h:50,
                    from arch/x86/kernel/nmi.c:13:
   arch/x86/kernel/nmi.c: In function 'nmi_max_handler':
   include/linux/printk.h:375:9: error: type defaults to 'int' in declaration of 'DEFINE_RATELIMIT_STATE' [-Werror=implicit-int]
     static DEFINE_RATELIMIT_STATE(_rs,    \
            ^
   arch/x86/kernel/nmi.c:110:2: note: in expansion of macro 'printk_ratelimited'
     printk_ratelimited(KERN_INFO
     ^~~~~~~~~~~~~~~~~~

This was working before the rtc rework series because linux/ratelimit.h
was included implictly through asm/mach_traps.h -> asm/mc146818rtc.h
-> linux/mc146818rtc.h -> linux/rtc.h -> linux/device.h.

We clearly shouldn't rely on this indirect inclusion, so this adds
an explicit #include in the file that needs it.
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
Fixes: 5ab788d7 ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h")
Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      c361db5c
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7