[PATCH] ACPI CMOS region support rev. 5

[Ian Smith]

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