linux.git/drivers/rtc, branch v6.0.14

rtc: cmos: fix build on non-ACPI platforms

2022-12-19T11:41:01+00:00

commit db4e955ae333567dea02822624106c0b96a2f84f upstream.

Now that rtc_wake_setup is called outside of cmos_wake_setup, it also need
to be defined on non-ACPI platforms.

Reported-by: kernel test robot 
Link: https://lore.kernel.org/r/20221018203512.2532407-1-alexandre.belloni@bootlin.com
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

rtc: cmos: Fix wake alarm breakage

2022-12-19T11:41:01+00:00

commit 0782b66ed2fbb035dda76111df0954515e417b24 upstream.

Commit 4919d3eb2ec0 ("rtc: cmos: Fix event handler registration
ordering issue") overlooked the fact that cmos_do_probe() depended
on the preparations carried out by cmos_wake_setup() and the wake
alarm stopped working after the ordering of them had been changed.

Address this by partially reverting commit 4919d3eb2ec0 so that
cmos_wake_setup() is called before cmos_do_probe() again and moving
the rtc_wake_setup() invocation from cmos_wake_setup() directly to the
callers of cmos_do_probe() where it will happen after a successful
completion of the latter.

Fixes: 4919d3eb2ec0 ("rtc: cmos: Fix event handler registration ordering issue")
Reported-by: Zhang Rui 
Reported-by: Todd Brandt 
Signed-off-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/5887691.lOV4Wx5bFT@kreacher
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

rtc: cmos: Fix event handler registration ordering issue

2022-12-19T11:41:00+00:00

commit 4919d3eb2ec0ee364f7e3cf2d99646c1b224fae8 upstream.

Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.

Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().

This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.

To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.

While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).

Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.

Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Bjorn Helgaas 
Tested-by: Mel Gorman 
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

rtc: spear: set range max

2022-08-08T22:56:41+00:00

In the commit f395e1d3b28d7c2c67b73bd467c4fb79523e1c65
("rtc: spear: set range"), the value of
RTC_TIMESTAMP_END_9999 was incorrectly set to range_min.
390	config->rtc->range_min = RTC_TIMESTAMP_BEGIN_0000;
391	config->rtc->range_max = RTC_TIMESTAMP_END_9999;

Fixes: f395e1d3b28d ("rtc: spear: set range")
Signed-off-by: Zeng Jingxiang 
Acked-by: Viresh Kumar 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20220728100101.1906801-1-zengjx95@gmail.com

rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0

2022-08-08T18:36:01+00:00

The ACPI_FADT_LOW_POWER_S0 flag merely means that it is better to
use low-power S0 idle on the given platform than S3 (provided that
the latter is supported) and it doesn't preclude using either of
them (which of them will be used depends on the choices made by user
space).

For this reason, there is no benefit from checking that flag in
use_acpi_alarm_quirks().

First off, it cannot be a bug to do S3 with use_acpi_alarm set,
because S3 can be used on systems with ACPI_FADT_LOW_POWER_S0 and it
must work if really supported, so the ACPI_FADT_LOW_POWER_S0 check is
not needed to protect the S3-capable systems from failing.

Second, suspend-to-idle can be carried out on a system with
ACPI_FADT_LOW_POWER_S0 unset and it is expected to work, so if setting
use_acpi_alarm is needed to handle that case correctly, it should be
set regardless of the ACPI_FADT_LOW_POWER_S0 value.

Accordingly, drop the ACPI_FADT_LOW_POWER_S0 check from
use_acpi_alarm_quirks().

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mario Limonciello 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/12054246.O9o76ZdvQC@kreacher

rtc: zynqmp: initialize fract_tick

2022-08-08T18:35:41+00:00

fract_tick is used uninitialized when fract_offset is 0

Reported-by: kernel test robot 
Signed-off-by: Alexandre Belloni 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Michal Simek 
Link: https://lore.kernel.org/r/20220727100018.3301470-1-alexandre.belloni@bootlin.com

rtc: Add NCT3018Y real time clock driver

2022-07-26T15:07:04+00:00

Add real time clock support for NCT3018Y.

Signed-off-by: Mia Lin 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20220713090647.8028-4-mimi05633@gmail.com

rtc: rx8025: fix 12/24 hour mode detection on RX-8035

2022-07-26T14:49:45+00:00

The 12/24hr flag in the RX-8035 can be found in the hour register,
instead of the CTRL1 on the RX-8025. This was overlooked when
support for the RX-8035 was added, and was causing read errors when
the hour register 'overflowed'.

To deal with the relevant register not always being visible in
the relevant functions, determine the 12/24 mode at startup and
store it in the driver state.

Signed-off-by: Mathew McBride 
Fixes: f120e2e33ac8 ("rtc: rx8025: implement RX-8035 support")
Cc: stable@vger.kernel.org
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20220706074236.24011-1-matt@traverse.com.au

rtc: cros-ec: Only warn once in .remove() about notifier_chain problems

2022-07-26T14:43:46+00:00

When a remove platform device callback returns an error code, the driver
core emits an error message ("remove callback returned a non-zero value.
This will be ignored.\n") and still removes the device. As the driver
already emits a more specific error message, return 0 to suppress the
core's error message.

This is a preparation for making platform remove callbacks return void.

Signed-off-by: Uwe Kleine-König 
Acked-by: Tzung-Bi Shih 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20220707153156.214841-1-u.kleine-koenig@pengutronix.de

rtc: vr41xx: remove driver

2022-07-26T14:34:12+00:00

Commit d3164e2f3b0a ("MIPS: Remove VR41xx support") removed support
for MIPS VR41xx platform, so remove exclusive drivers for this
platform, too.

Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20220715135330.134684-1-tsbogend@alpha.franken.de