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

[Anthony Jenkins]

On 07/16/2014 19:39, Daniele Mazzotti wrote:
> Hi guys,
>
> @Anthony: actually I am a "he" and not a "she" and I never thought about
> changing my nature below the waist :-).

Oops!  Sorry about that...

> By the way I will try to apply the patch as soon as I will be back home as
> I left my personal PC at home and I won't be back until Monday. I will let
> you know if that will fix my suspend/resume issue.

Yeah just try stripping the apparent Ctrl-M line termination characters in the patch, or I can compress/encode it or something for transport.  ...or try the '--ignore-whitespace' option to FreeBSD patch(1).

Thanks,
Anthony

> Regarding the battery issue I hope that I will try to follow the
> recommendations from Ian in another email and see what happen.
>
> Cheers,
> Daniele.
>
> Il 16/lug/2014 23:08 "Anthony Jenkins" <Anthony.B.Jenkins at att.net> ha
> scritto:
>
>> On 07/16/2014 13:16, Ian Smith wrote:
>>> On Wed, 16 Jul 2014 09:26:08 -0400, Anthony Jenkins wrote:
>>>  > On 07/16/2014 01:32, Daniele Mazzotti wrote:
>>>  >> Hi guys, thanks again for the support, but I am leaving for a
>>>  >> businesses trip and I will be forced to put this debug thing on hold
>>>  >> for a while. I will be back on track next week.
>>>  >
>>>  > Bah... really wanted to figure out the patch problem.  I suspect the
>>>  > file picked up some corruption somewhere between the email and your
>>>  > FreeBSD filesystem.  Your OS version has the same revision of that
>>>  > source file as mine, so it should apply cleanly.  If you feel like
>>>  > tinkering with it in your free time, I've posted the patch here:
>>>  > http://pastebin.com/P0B44u0c
>>>  >
>>>  > Good luck,
>>>  > Anthony
>>>
>>> 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.
>>> 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.
>>> 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.
>>> Have you found exactly which CMOS bytes your box needs to meddle with?
>> I do have printf()s in my code (don't think I added it to the patch) that
>> says what's read/written, I'll have to look again.
>>> 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?
>>
>>> Don't mind me, just thinking aloud, and I've no idea how this might
>>> relate to Daniele's issue with stale battery data?
>> Agreed... I'm pretty much just blindly tossing the patch over to her. :-)
>>  She did complain about suspend issues, and my patch fixes suspend issues
>> on my HP and another guinea pig from the mailing list (with an HP).  Next I
>> need to figure out why acpi_hp doesn't work on my laptop, as I see SystemIO
>> calls to 0x72/0x73 when I try to adjust the brightness.
>>
>> Thanks,
>> Anthony
>>> cheers, Ian
>>>
>>> PS Daniele: no, never tempted by Sonys; rusted-on Thinkpad kinda guy :)
>>> _______________________________________________
>>> freebsd-acpi at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
>>>
>>
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
>