Re: [PATCH V2] rtc: mc146818: Detect and handle broken RTCs

2021-02-01 Thread Serge Belyshev
Hi! "Me too": > --- a/drivers/rtc/rtc-mc146818-lib.c > +++ b/drivers/rtc/rtc-mc146818-lib.c > @@ -21,6 +21,13 @@ unsigned int mc146818_get_time(struct rt > > again: > spin_lock_irqsave(_lock, flags); > + /* Ensure that the RTC is accessible. Bit 0-6 must be 0! */ > + if

Re: [PATCH V2] rtc: mc146818: Detect and handle broken RTCs

2021-01-31 Thread Dirk Gouders
Thomas Gleixner writes: > 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

[PATCH V2] rtc: mc146818: Detect and handle broken RTCs

2021-01-26 Thread Thomas Gleixner
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

Re: [PATCH V2] rtc: mc146818: Detect and handle broken RTCs

2021-01-26 Thread Alexandre Belloni
On 26/01/2021 18:02:11+0100, Thomas Gleixner wrote: > 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