[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-rtc
Subject:    Re: [PATCH V2] rtc: mc146818: Dont test for bit 0-5 in Register D
From:       "Maciej W. Rozycki" <macro () orcam ! me ! uk>
Date:       2021-02-11 23:09:20
Message-ID: alpine.DEB.2.21.2102120001450.35623 () angie ! orcam ! me ! uk
[Download RAW message or body]

On Mon, 1 Feb 2021, Thomas Gleixner wrote:

> >> 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.
> >
> > This looks fine, but it might also be worth it simply just checking
> > for the only really special value: 0xff, and going "ok, that looks
> > like missing hardware".
> >
> > That's what a few other drivers historically do in their probing
> > routines, so it's not unheard of (ie you can find drivers doing that
> > kind of
> >
> >         /* If we read 0xff from the LSR, there is no UART here. */
> >         if (inb(.. port ..) == 0xff)
> >
> > in their init routines.
> >
> > Not a big deal either way, I just think it would be more in like with
> > what other places do in similar situations
> 
> Yeah, we can do that as well. Either way is fine.

 Given that evidently vendors appear to start playing with 146818 clones 
it may be worth it to peek at the D and the C register and checking they 
are not 0xff both at a time for robustness before concluding no RTC is 
present.  The C register is supposed to hold zeros in bits 3:0.  A read of 
the C register will drop interrupt bits, but I guess it does not matter at 
the probe time.

 FWIW,

  Maciej
[prev in list] [next in list] [prev in thread] [next in thread]