Created attachment 167301 [details]
Impl. of ACPI RTC/CMOS interface.
FreeBSD base system does not provide an ACPI handler for the PC/AT RTC/CMOS device with PnP ID PNP0B00; on recent HP Envy laptops, the absence of this handler causes suspend/resume and poweroff(8) to hang/fail, emitting e.g.
ACPI Error: No handler for Region [RCM0] (0xfffff80005796480) [SystemCMOS] (20150818/evregion-176)
ACPI Error: Region SystemCMOS (ID=5) has no handler (20150818/exfldio-317)
These HP laptops have BIOSes which attempt to query the RTC date/time registers via ACPI before suspending/powering off.
ACPI-5.0 specification section 9.15 describes the ACPI interface to the RTC/CMOS device (atrtc(4) in FreeBSD).
I have implemented this ACPI handler; adding this allows poweroff and suspend/resume to occur. At a FreeBSD committer's request, I've also implemented the same patch with additional changes to atrtc(4) to separate the bus functionality from the core functionality.
Created attachment 167302 [details]
Impl. of ACPI RTC/CMOS interface with bus/core separation.
This version of the patch was requested by a FreeBSD committer. I personally prefer the previous patch to this one; instead the separation should be performed as a new bug.
Please note the upstream received a CMOS handler implementation and the patch was posted here:
Unfortunately, it is still not resolved.
If possible, please participate in the discussion.
The upstream thread actually mirrors the evolution of my OSPM patch. I first tried adding code to the ACPICA code, then, based on some helpful suggestions from acpi@, moved it to the atrtc(4) driver. I agree with the last thread post (https://lists.acpica.org/pipermail/devel/2016-February/000874.html) - that support for RTC/CMOS devices belongs in the OSPM, not in the ACPICA. If you look closely at the OP's proposed ACPICA patch, the AcpiOs(Read|Write)Cmos() handlers are no-ops (Read returns 0, Write does nothing).
I mean I can toss my $0.02 into the thread, but it'll be little more than "I agree this shouldn't be added to ACPICA"...
(In reply to Anthony Jenkins from comment #3)
> If you look closely at the OP's proposed ACPICA patch, the
> AcpiOs(Read|Write)Cmos() handlers are no-ops (Read returns 0, Write does
Actually, those are stubs for userland tools, i.e., acpiexec. FYI, OSPM must provide AcpiOsReadCmos() and AcpiOsWriteCmos(). See sys/dev/acpica/Osd/OsdMemory.c, for example.
BTW, these functions must be MD. So, it should be placed in sys/x86/acpica (please see OsdEnvironment.c) and/or sys/x86/isa/atrtc.c. If the upstream does not want them as official API, then your patch is good.
FYI, the official ACPICA API is documented here:
(In reply to Anthony Jenkins from comment #1)
FYI, the separation is important because ACPI is not mandatory for i386.
(In reply to Jung-uk Kim from comment #6)
Ahh, okay I think that makes sense; seemed an arbitrary request before.
My bus-separation patch could probably use some work, but it builds and works on my amd64.