linux-stable.git/drivers/rtc/rtc-cmos.c, branch linux-5.11.y

rtc: mc146818: Dont test for bit 0-5 in Register D

2021-02-02T19:35:02+00:00

The recent change to validate the RTC turned out to be overly tight.

While it cures the problem on the reporters machine it breaks machines
with Intel chipsets which use bit 0-5 of the D register. So check only
for bit 6 being 0 which is the case on these Intel machines as well.

Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Reported-by: Serge Belyshev 
Reported-by: Dirk Gouders 
Reported-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Tested-by: Dirk Gouders 
Tested-by: Len Brown 
Tested-by: Borislav Petkov 
Acked-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/87zh0nbnha.fsf@nanos.tec.linutronix.de

rtc: mc146818: Detect and handle broken RTCs

2021-01-27T08:36:22+00:00

The recent fix for handling the UIP bit unearthed another issue in the RTC
code. If the RTC is advertised but the readout is straight 0xFF because
it's not available, the old code just proceeded with crappy values, but the
new code hangs because it waits for the UIP bit to become low.

Add a sanity check in the RTC CMOS probe function which reads the RTC_VALID
register (Register D) which should have bit 0-6 cleared. If that's not the
case then fail to register the CMOS.

Add the same check to mc146818_get_time(), warn once when the condition
is true and invalidate the rtc_time data.

Reported-by: Mickaël Salaün 
Signed-off-by: Thomas Gleixner 
Tested-by: Mickaël Salaün 
Acked-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/87tur3fx7w.fsf@nanos.tec.linutronix.de

Merge tag 'rtc-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux

2020-12-20T18:12:06+00:00

Pull RTC updates from Alexandre Belloni:
 "Subsystem:

   - Remove nvram ABI. There was no complaints about the deprecation for
     the last 3 years.

   - Improve RTC device allocation and registration

   - Now available for ARCH=um

  Drivers:

   - at91rm9200: correction and sam9x60 support

   - ds1307: improve ACPI support

   - mxc: now DT only

   - pcf2127: watchdog support now needs the reset-source property

   - pcf8523: set range

   - rx6110: i2c support"

* tag 'rtc-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (43 commits)
  rtc: pcf2127: only use watchdog when explicitly available
  dt-bindings: rtc: add reset-source property
  rtc: fix RTC removal
  rtc: s3c: Remove dead code related to periodic tick handling
  rtc: s3c: Disable all enable (RTC, tick) bits in the probe
  rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time
  rtc: test: remove debug message
  rtc: mxc{,_v2}: enable COMPILE_TEST
  rtc: enable RTC framework on ARCH=um
  rtc: pcf8523: use BIT
  rtc: pcf8523: set range
  rtc: pcf8523: switch to devm_rtc_allocate_device
  rtc: destroy mutex when releasing the device
  rtc: shrink devm_rtc_allocate_device()
  rtc: rework rtc_register_device() resource management
  rtc: nvmem: emit an error message when nvmem registration fails
  rtc: add devm_ prefix to rtc_nvmem_register()
  rtc: nvmem: remove nvram ABI
  Documentation: list RTC devres helpers in devres.rst
  rtc: omap: use devm_pinctrl_register()
  ...

ntp: Make the RTC sync offset less obscure

2020-12-11T09:40:53+00:00

The current RTC set_offset_nsec value is not really intuitive to
understand. 

  tsched       twrite(t2.tv_sec - 1) 	 t2 (seconds increment)

The offset is calculated from twrite based on the assumption that t2 -
twrite == 1s. That means for the MC146818 RTC the offset needs to be
negative so that the write happens 500ms before t2.

It's easier to understand when the whole calculation is based on t2. That
avoids negative offsets and the meaning is obvious:

 t2 - twrite:     The time defined by the chip when seconds increment
      		  after the write.

 twrite - tsched: The time for the transport to the point where the chip
 	  	  is updated. 

==> set_offset_nsec =  t2 - tsched
    ttransport      =  twrite - tsched
    tRTCinc         =  t2 - twrite
==> set_offset_nsec =  ttransport + tRTCinc

tRTCinc is a chip property and can be obtained from the data sheet.

ttransport depends on how the RTC is connected. It is close to 0 for
directly accessible RTCs. For RTCs behind a slow bus, e.g. i2c, it's the
time required to send the update over the bus. This can be estimated or
even calibrated, but that's a different problem.

Adjust the implementation and update comments accordingly.

Signed-off-by: Thomas Gleixner 
Acked-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20201206220542.263204937@linutronix.de

rtc: cmos: Make rtc_cmos sync offset correct

2020-12-11T09:40:52+00:00

The offset for rtc_cmos must be -500ms to work correctly with the current
implementation of rtc_set_ntp_time() due to the following:

  tsched       twrite(t2.tv_sec - 1) 	 t2 (seconds increment)

twrite - tsched is the transport time for the write to hit the device,
which is negligible for this chip because it's accessed directly.

t2 - twrite = 500ms according to the datasheet.

But rtc_set_ntp_time() calculation of tsched is:

    tsched = t2 - 1sec - (t2 - twrite)

The default for the sync offset is 500ms which means that the write happens
at t2 - 1.5 seconds which is obviously off by a second for this device.

Make the offset -500ms so it works correct.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Jason Gunthorpe 
Acked-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20201206220541.830517160@linutronix.de

rtc: rework rtc_register_device() resource management

2020-11-19T11:50:12+00:00

rtc_register_device() is a managed interface but it doesn't use devres
by itself - instead it marks an rtc_device as "registered" and the devres
callback for devm_rtc_allocate_device() takes care of resource release.

This doesn't correspond with the design behind devres where managed
structures should not be aware of being managed. The correct solution
here is to register a separate devres callback for unregistering the
device.

While at it: rename rtc_register_device() to devm_rtc_register_device()
and add it to the list of managed interfaces in devres.rst. This way we
can avoid any potential confusion of driver developers who may expect
there to exist a corresponding unregister function.

Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl

rtc: nvmem: emit an error message when nvmem registration fails

2020-11-19T11:50:12+00:00

Some users check the return value of devm_rtc_nvmem_register() only in
order to emit an error message and then continue probing. This is fine
as an rtc can function without exposing nvmem but let's generalize it:
let's make the registration function emit the error message so that
users don't have to.

Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20201109163409.24301-7-brgl@bgdev.pl

rtc: add devm_ prefix to rtc_nvmem_register()

2020-11-19T11:50:11+00:00

rtc_nvmem_register() is a managed interface. It doesn't require any
release function to be called at driver detach. To avoid confusing
driver authors, let's rename it to devm_rtc_nvmem_register() and add it
to the list of managed interfaces in Documentation/.

Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20201109163409.24301-6-brgl@bgdev.pl

rtc: nvmem: remove nvram ABI

2020-11-19T11:50:11+00:00

The nvram sysfs attributes have been deprecated at least since v4.13, more
than 3 years ago and nobody ever complained about the deprecation warning.

Remove the sysfs attributes now.

[Bartosz: remove the declaration of rtc_nvmem_unregister()]

Signed-off-by: Alexandre Belloni 
Signed-off-by: Bartosz Golaszewski 
Link: https://lore.kernel.org/r/20201109163409.24301-5-brgl@bgdev.pl

rtc: cmos: zero-init wkalrm when reading from CMOS

2020-08-20T22:10:33+00:00

cmos_read_alarm() may leave certain fields of a struct rtc_wkalrm
untouched; therefore, these fields contain garbage if not properly
initialized, leading to inconsistent values when converting into
time64_t. This patch to zero initialize the struct before calling
cmos_read_alarm().

Note that this patch is not intended to produce a correct time64_t, it
is only to produce a consistent value. In the case of suspend/resume, a
correct time64_t is not necessary; a consistent value is sufficient to
correctly perform an equality test for t_current_expires and
t_saved_expires. Logic to deduce a correct time64_t is expensive and
hence should be avoided.

Signed-off-by: Victor Ding 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20200814191654.v2.1.Iaf7638a2f2a87ff68d85fcb8dec615e41340c97f@changeid