24 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version this program is distributed in the
    hope that it will be useful but without any warranty without even
    the implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details you
    should have received a copy of the gnu general public license along
    with this program

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 8 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Richard Fontana
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190523091650.663497195@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

04 Apr, 2019

1 commit


25 Apr, 2018

1 commit

  • The OPAL RTC driver does not sleep in case it gets OPAL_BUSY or
    OPAL_BUSY_EVENT from firmware, which causes large scheduling
    latencies, up to 50 seconds have been observed here when RTC stops
    responding (BMC reboot can do it).

    Fix this by converting it to the standard form OPAL_BUSY loop that
    sleeps.

    Fixes: 628daa8d5abf ("powerpc/powernv: Add RTC and NVRAM support plus RTAS fallbacks")
    Cc: stable@vger.kernel.org # v3.2+
    Signed-off-by: Nicholas Piggin
    Acked-by: Alexandre Belloni
    Signed-off-by: Michael Ellerman

    Nicholas Piggin
     

27 Jan, 2018

1 commit

  • According to the OPAL docs:
    skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt
    skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt

    OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and
    this indicates either a transient or permanent error.

    Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a
    permanent error particularly well, in that you could end up in a busy
    loop.

    This was not too hard to trigger on an AMI BMC based OpenPOWER machine
    doing a continuous "ipmitool mc reset cold" to the BMC, the result of
    that being that we'd get stuck in an infinite loop in
    opal_get_rtc_time().

    We now retry a few times before returning the error higher up the
    stack.

    Fixes: 16b1d26e77b1 ("rtc/tpo: Driver to support rtc and wakeup on PowerNV platform")
    Cc: stable@vger.kernel.org # v3.19+
    Signed-off-by: Stewart Smith
    Signed-off-by: Michael Ellerman

    Stewart Smith
     

24 Jun, 2017

1 commit

  • Provide an implementation of the callback
    rtc_class_ops.alarm_irq_enable for rtc-opal driver. This callback is
    called when the wake alarm is disabled via the command:

    'echo 0 > /sys/class/rtc/rtc0/wakealarm'

    Without this the Timed-Power-On(TPO) config remains set even when its
    disabled by the above command and FSP will still force machine
    boot at previously configured alarm time.

    The callback is implemented as function opal_tpo_alarm_irq_enable()
    which calls opal_set_tpo_time() with alarm.enabled == 0. A branch is
    added to opal_set_tpo_time() to handle this case by passing y_m_d ==
    h_m_s_ms == 0 to opal as arguments for opal_tpo_write() call.

    Signed-off-by: Vaibhav Jain
    Signed-off-by: Alexandre Belloni

    Vaibhav Jain
     

31 May, 2017

1 commit

  • On PowerNV platform when Timed-Power-On(TPO) is disabled, read of
    stored TPO yields value with all date components set to '0' inside
    opal_get_tpo_time(). The function opal_to_tm() then converts it to an
    offset from year 1900 yielding alarm-time == "1900-00-01
    00:00:00". This causes problems with __rtc_read_alarm() that
    expecting an offset from "1970-00-01 00:00:00" and returned alarm-time
    results in a -ve value for time64_t. Which ultimately results in this
    error reported in kernel logs with a seemingly garbage value:

    "rtc rtc0: invalid alarm value: -2-1--1041528741
    2005511117:71582844:32"

    We fix this by explicitly handling the case of all alarm date-time
    components being '0' inside opal_get_tpo_time() and returning -ENOENT
    in such a case. This signals generic rtc that no alarm is set and it
    bails out from the alarm initialization flow without reporting the
    above error.

    Signed-off-by: Vaibhav Jain
    Reported-by: Steve Best
    Signed-off-by: Alexandre Belloni

    Vaibhav Jain
     

29 Jun, 2016

1 commit

  • An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in the
    params[1] struct member. However this isn't intuitive or obvious when
    reading the code and requires that a user look at the skiboot
    documentation or opal-api.h to verify this.

    Add an inline function to get the return code from an opal_msg and update
    call sites accordingly.

    Signed-off-by: Suraj Jitindar Singh
    Signed-off-by: Michael Ellerman

    Suraj Jitindar Singh
     

16 Dec, 2015

1 commit

  • GregorianDay() is supposed to calculate the day of the week
    (tm->tm_wday) for a given day/month/year. In that calcuation it
    indexed into an array called MonthOffset using tm->tm_mon-1. However
    tm_mon is zero-based, not one-based, so this is off-by-one. It also
    means that every January, GregoiranDay() will access element -1 of
    the MonthOffset array.

    It also doesn't appear to be a correct algorithm either: see in
    contrast kernel/time/timeconv.c's time_to_tm function.

    It's been broken forever, which suggests no-one in userland uses
    this. It looks like no-one in the kernel uses tm->tm_wday either
    (see e.g. drivers/rtc/rtc-ds1305.c:319).

    tm->tm_wday is conventionally set to -1 when not available in
    hardware so we can simply set it to -1 and drop the function.
    (There are over a dozen other drivers in drivers/rtc that do
    this.)

    Found using UBSAN.

    Cc: Andrey Ryabinin
    Cc: Andrew Morton # as an example of what UBSan finds.
    Cc: Alessandro Zummo
    Cc: Alexandre Belloni
    Cc: rtc-linux@googlegroups.com
    Signed-off-by: Daniel Axtens
    Acked-by: Alexandre Belloni
    Signed-off-by: Michael Ellerman

    Daniel Axtens
     

08 Nov, 2015

2 commits

  • Though the opal rtc driver should and will continue to support the legacy
    "has-tpo" property to enable RTC as the wakeup source, we need to add
    support for the new standard property "wakeup-source"

    This patch adds support for "wakeup-source" property in addition to the
    existing "has-tpo" property.

    Cc: Alessandro Zummo
    Cc: Alexandre Belloni
    Cc: rtc-linux@googlegroups.com
    Signed-off-by: Sudeep Holla
    Signed-off-by: Alexandre Belloni

    Sudeep Holla
     
  • The variable can take signed values.

    The problem has been detected using proposed semantic patch
    scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

    [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

    Signed-off-by: Andrzej Hajda
    Signed-off-by: Alexandre Belloni

    Andrzej Hajda
     

05 Sep, 2015

2 commits

  • rtc-opal driver provides support for rtc alarms via
    timed-power-on(tpo). However some Power platforms like BML use a fake
    rtc clock and don't support tpo. Such platforms are indicated by the
    missing 'has-tpo' property in the device tree.

    Current implementation however enables callback for
    rtc_class_ops.read/set alarm irrespective of the tpo support from the
    platform. This results in a failed opal call when kernel tries to read
    an existing alarms via opal_get_tpo_time during rtc device registration.

    This patch fixes this issue by setting opal_rtc_ops.read/set_alarm
    callback pointers only when tpo is supported.

    Acked-by: Michael Neuling
    Acked-by: Neelesh Gupta
    Signed-off-by: Vaibhav Jain
    Acked-by: Stewart Smith
    Signed-off-by: Alexandre Belloni

    Vaibhav Jain
     
  • platform_driver does not need to set an owner because
    platform_driver_register() will set it.

    Signed-off-by: Alexandre Belloni

    Krzysztof Kozlowski
     

17 Apr, 2015

1 commit

  • Neaten the logging a bit by adding #define pr_fmt

    Miscellanea:

    o Remove __FILE__/__func__ uses
    o Coalesce formats adding missing spaces
    o Align arguments
    o (rtc-cmos) Integrated 2 consecutive messages

    Signed-off-by: Joe Perches
    Acked-by: Alexandre Belloni
    Cc: Alessandro Zummo
    Cc: Joshua Kinard
    Cc: Chanwoo Choi
    Reviewed-by: Krzysztof Kozlowski
    Tested-by: Krzysztof Kozlowski
    Cc: Aaro Koskinen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joe Perches
     

17 Nov, 2014

1 commit

  • The patch implements the OPAL rtc driver that binds with the rtc
    driver subsystem. The driver uses the platform device infrastructure
    to probe the rtc device and register it to rtc class framework. The
    'wakeup' is supported depending upon the property 'has-tpo' present
    in the OF node. It provides a way to load the generic rtc driver in
    in the absence of an OPAL driver.

    The patch also moves the existing OPAL rtc get/set time interfaces to the
    new driver and exposes the necessary OPAL calls using EXPORT_SYMBOL_GPL.

    Test results:
    -------------
    Host:
    [root@tul169p1 ~]# ls -l /sys/class/rtc/
    total 0
    lrwxrwxrwx 1 root root 0 Oct 14 03:07 rtc0 -> ../../devices/opal-rtc/rtc/rtc0
    [root@tul169p1 ~]# cat /sys/devices/opal-rtc/rtc/rtc0/time
    08:10:07
    [root@tul169p1 ~]# echo `date '+%s' -d '+ 2 minutes'` > /sys/class/rtc/rtc0/wakealarm
    [root@tul169p1 ~]# cat /sys/class/rtc/rtc0/wakealarm
    1413274345
    [root@tul169p1 ~]#

    FSP:
    $ smgr mfgState
    standby
    $ rtim timeofday

    System time is valid: 2014/10/14 08:12:04.225115

    $ smgr mfgState
    ipling
    $

    CC: devicetree@vger.kernel.org
    CC: tglx@linutronix.de
    CC: rtc-linux@googlegroups.com
    CC: a.zummo@towertech.it
    Signed-off-by: Neelesh Gupta
    Signed-off-by: Michael Ellerman

    Neelesh Gupta