[PATCH] ACPI CMOS region support rev. 5
Ian Smith
smithi at nimnet.asn.au
Thu Mar 19 08:11:05 UTC 2015
On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote:
> > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins <Anthony.B.Jenkins at att.net> wrote:
> >
> > On 03/18/2015 11:29 AM, Warner Losh wrote:
> >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins <Anthony.B.Jenkins at att.net> wrote:
> >>>> \Where else might ATRTC_VERBOSE be set otherwise?
> >>> I'm picturing a (future?) config(5) knob, e.g.
> >>>
> >>> device atrtc
> >>> options ATRTC_VERBOSE=1
> >>>
> >>>
> >>> so it can be set at compile time.
> >> Why not just boot verbose? history has shown too many options like
> >> this is hard to use.
You can blame this on me :) I agree about the option not being needed;
the way it is you can just set sysctl hw.acpi.atrtc_verbose=0 to quell
reports of successful access, if it turns out these are routine on some
machines, especially outside of boot/suspend/resume contexts.
However I'll still argue that, this being a new gadget and that we could
use finding out which vendors want to read or write which locations in
CMOS for whatever reason, at least while it's in head, we should log all
access by default unless setting atrtc_verbose=0, and in _any_ case we
should be logging attempts to R/W out-of-bounds CMOS locations.
> > I think I understand what you're saying... I also prefer fewer config(5)
> > knobs. So you're suggesting I determine (at runtime) the boot verbose
> > setting (kenv(2) or however it's properly done) and dump the
> > compile-time verbosity setting?
>
> if (bootverbose)
> do verbose things;
>
> is how thatÿÿs done.
Sure, and maybe successful access could be limited to bootverbose, and
we could ask people whose boxes fail to boot/suspend/resume/whatever to
boot verbose to reveal such as why Anthony's HP Envy either failed to
suspend or immediately resumed - which isn't entirely clear, even with
the messages - unless its ACPI AML succeeded in reading minute, hour and
weekday, but I have a feeling we may see more of this sort of thing.
cheers, Ian
More information about the freebsd-acpi
mailing list