Re: [PATCH RESEND 0/2] rtc: rv8803 patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/02/2023 16:18:24+0100, Marc Kleine-Budde wrote:
> On 31.01.2023 13:00:12, Alexandre Belloni wrote:
> > On 31/01/2023 09:19:55+0100, Marc Kleine-Budde wrote:
> > > Hello Alexandre,
> > > 
> > > On 23.11.2022 10:55:25, Sascha Hauer wrote:
> > > > This series has the remainder of
> > > > https://lore.kernel.org/all/20220426071056.1187235-1-s.hauer@xxxxxxxxxxxxxx/
> > > > which was partly applied.
> > > > 
> > > > Alexandre,
> > > > 
> > > > Last time this series was send you asked if this series fixes a problem
> > > > we've really seen to which Ahmad answered:
> > > > 
> > > > > The kernel message
> > > > > 
> > > > >   rtc rtc0: invalid alarm value: 2020-3-27 7:82:0
> > > > > 
> > > > > listed in the commit message is something I actually ran into. There
> > > > > was no v2f set then. The customer has also variously observed bit flips
> > > > > independently of v2f: During EMC testing, electrostatic discharge at developer
> > > > > desks and even in the field: Suspected causes were lightning strikes in the
> > > > > vicinity and the switching of larger inductive loads.
> > > > > They're very paranoid of logging invalid timestamps, so we'll keep the patch
> > > > > anyhow at our side, but I think it is generally useful as well: If we can't
> > > > > set an invalid alarm time by normal means, but read back an invalid time,
> > > > > something may have corrupted other memory, so treating it as a v2f is sensible.
> > > > 
> > > > There was no answer to this. I would be glad if you could take this
> > > > series. I would understand though if you say that this problem is too
> > > > esoteric to fix it upstream, we would keep the patches locally then.
> > > > Please just say so, it would help me to get the problem from my desk
> > > > ;)
> > > 
> > > Can someone take this patch series? If not, what can we do to get these
> > > changes upstream?
> > 
> > I'm going to take it but this may silently break existing users with a
> > niche use case.
> > Also, this check will only happen at boot time so I'm not sure there is
> > a huge benefit, unless your customer reboots the platform often.
> 
> Thanks Alexandre, is this patch already on an immutable branch?

It is not, I just pushed it to rtc-next now.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com



[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux