On Sun, 2018-03-11 at 23:25 +0200, Konstantin Belousov wrote:
> On Sun, Mar 11, 2018 at 02:20:39PM -0600, Ian Lepore wrote:
> > On Sun, 2018-03-11 at 21:58 +0200, Konstantin Belousov wrote:
> > >
> > > On Sun, Mar 11, 2018 at 07:22:58PM +0000, Ian Lepore wrote:
> > > >
> > > >
> > > > [...]
> > Unfortunately, this reverts one type of wrong locking back to another.
> > The need is to prevent access to the atrtc hardware if efi is
> > accessing it, and the locking I just reverted to that uses a sleepable
> > mutex only protects against inittodr()/resettodr() access, but not
> > against nvram(4) or if the atrtc is being used as an eventtimer (of
> > course nobody uses it for that, but the driver supports it).
> > I have some pending changes that cause the atrtc driver to just not
> > attach at all if the efirtc driver attached, but they're stacked up
> > behind some other changes in phab. And that still doesn't fix the
> > nvram(4) part of it.
> Not attaching atrtc if efirtc is attached sounds reasonable. But then
> you should also disable efirt attach if atrtc is on. One possible issue
> is that efirt is typicall loadable, while atrtc is compiled into the
> kernel, which means that efirt would become virtually unusable.
Even if efirt is loaded (in loader(8)) the efirtc driver will still
attach instead of atrtc, because it's a direct child of nexus and gets
the first opportunity to probe and attach. But you raise a good point,
I should make it handle the case where it gets kldload'd when atrtc is
> For nvram(4), you can take the atrtc_time_lock around accesses in addition
> to the atrtc_lock, instead of providing exclusivity on the level of drivers
It occurs to me that an even better fix for all of this would be to
remove support for atrtc being an eventtimer. That allows removing the
interrupt filter handler, and then there's no need for a spinlock at
all, a sleepable mutex works fine for all accesses.
Does anybody really need an eventtimer that runs only at a fixed
periodic rate of 32khz in 2018?
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"