atrtc.c patch for ACPI CMOS region (was Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E)

[Ian Smith]

On Wed, 16 Jul 2014 17:08:03 -0400, Anthony Jenkins wrote:
 > On 07/16/2014 13:16, Ian Smith wrote:
[..]
 > >  > http://pastebin.com/P0B44u0c
 > >
 > > Either by show raw and save, or by download, the patch has ^M lineends.

 > Bah!  Well that'd explain it... I'm generating the file on a pure 
 > FreeBSD box, opened in gvim, select all, copy, paste to pastebin.com.

Must be pastebin .. a sh script I grabbed from there came like that too.

 > > Interesting, but I can't see atrtc.c being the right sort of place for 
 > > this, seems way out of scope.  Couldn't you include its headers and use 
 > > functions rtcin() and writertc() from elsewhere in kernel, perhaps a 
 > > module living in the same hierarchy as acpi_ibm, acpi_asus and such, 
 > > that one could build and kldload if useful on a certain machine/s?

 > This is in support of the PNP0800 device, for which atrtc.c is the 
 > driver.  The ACPI spec (5.0 is what I'm reading) says that device 
 > should implement a handler to read offset 0x00-0x7F.

Fair enough.  I've since explored PNP0800 a bit, had a look at what 
Linux does in (apparently recent) acpi_cmos_rtc.c, asm-generic/rtc.h etc 
from mit.edu - much more complex and quirk-handling than ours - and soon 
realised how out of date my knowledge of any of this is; ACPI was at 3.0 
last time I read much of the spec ..

 > > If so, you haven't to do battle with Time Lords :) with something people 
 > > could add and load at own risk without messing with core kernel stuff.
 > >
 > > acpi_ibm should be a useful template, as it includes code to read CMOS 
 > > bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether 
 > > opaquely or somehow via AML code I don't know.  It uses rtcin() so has 
 > > that scope in place.
 > >
 > > I'd still like to see your patch reject attempts to read or write to at 
 > > least below 0x10.  Even reading status register/s resets interrupts, and 
 > > why would anyone need to mess with clock and/or timer regs via ACPI?

 > I assume it'd be the BIOS AML which would use my CMOS region handler; 
 > it'd be a BIOS bug that reads/writes the clock regs.

Fair enough again.  My earlier impression was of a fix for a specific 
quirk for your HP, not realising you were implementing what is for 
FreeBSD a new handler for a new(er) ACPI feature, so ignore my musings.

 > > Maybe you could add a sysctl to limit access to some specific range?
 > I dunno... I really think what I have is the Right Thing To Do... 
 > Someone else from freebsd-acpi@ suggested this approach.  Maybe 
 > someone versed in ACPI could clarify from the spec?

I'd be happy to see more on-list information, but everyone's busy .. 

cheers, Ian