Page MenuHomeFreeBSD

at_rtc: check in ACPI FADT boot flags if the RTC is present
ClosedPublic

Authored by royger on Feb 16 2018, 5:16 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 30 2024, 11:06 PM
Unknown Object (File)
Jan 28 2024, 7:02 PM
Unknown Object (File)
Jan 28 2024, 7:02 PM
Unknown Object (File)
Jan 28 2024, 7:02 PM
Unknown Object (File)
Jan 28 2024, 6:57 PM
Unknown Object (File)
Jan 28 2024, 6:57 PM
Unknown Object (File)
Jan 28 2024, 5:58 PM
Unknown Object (File)
Jan 28 2024, 2:22 AM
Subscribers
None

Details

Summary

Sponsored by: Citrix Systems R&D

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ian requested changes to this revision.Feb 16 2018, 5:28 PM
ian added inline comments.
sys/x86/isa/atrtc.c
283 ↗(On Diff #39389)

If the intention is to not-attach, the return value needs to be an error (typically ENXIO). 0 means basically "I am the One True Driver for this and should take precedence over any other".

This revision now requires changes to proceed.Feb 16 2018, 5:28 PM

Return ENXIO if ACPI reports that the device is not present.

Thanks for the review.

sys/x86/isa/atrtc.c
283 ↗(On Diff #39389)

Sure, got distracted and somehow through this was an identify routine instead of a probe one.

This revision is now accepted and ready to land.Feb 16 2018, 5:58 PM

Does ACPI_FADT_NO_CMOS_RTC also imply that there is no battery-backed nvram (aka "cmos") available? If so, then this same sort of check might need to go into the MOD_LOAD case in nvram(4) (dev/nvram).

Also, when searching for some info on this flag, I see linux bug reports about HP shipping systems with that flag set even when not booted from UEFI, leaving the system with no usable RTC. We may need some sort of tunable override.

I also wonder if the presence of that flag means that we're supposed to use EFI runtime services as an RTC instead of direct hardware access. If so, I think we're going to need some new code to register EFI as an RTC. (I was already wondering if we should do that and avoid direct hardware access, if efi is providing an rtc in runtime services.) That leads to the question of whether we should just use the efi rtc instead of atrtc whenever it's available, regardless of the ACPI_FADT_NO_CMOS_RTC flag.

In D14399#302096, @ian wrote:

Does ACPI_FADT_NO_CMOS_RTC also imply that there is no battery-backed nvram (aka "cmos") available? If so, then this same sort of check might need to go into the MOD_LOAD case in nvram(4) (dev/nvram).

From my reading of the ACPI spec, I would say that this flag only applies to the RTC, but not the whole CMOS:

"If set, indicates that the CMOS RTC is either not implemented, or does not exist at the legacy addresses. OSPM uses the Control Method Time and Alarm Namespace device instead."

Also, when searching for some info on this flag, I see linux bug reports about HP shipping systems with that flag set even when not booted from UEFI, leaving the system with no usable RTC. We may need some sort of tunable override.

Right, I see this has been fixed in newer versions of the firmware, but I agree with adding a tunable. Let me prepare a new version.

I also wonder if the presence of that flag means that we're supposed to use EFI runtime services as an RTC instead of direct hardware access. If so, I think we're going to need some new code to register EFI as an RTC. (I was already wondering if we should do that and avoid direct hardware access, if efi is providing an rtc in runtime services.) That leads to the question of whether we should just use the efi rtc instead of atrtc whenever it's available, regardless of the ACPI_FADT_NO_CMOS_RTC flag.

According to the ACPI spec there's also the "Time and Alarm Device" device (section 9.18) which AFAICT it's independent from UEFI/BIOS, it's just an ACPI object with time related methods.

Thanks, Roger.

This revision now requires review to proceed.Feb 19 2018, 11:47 AM

I'm sorry about taking so long on this, I guess I missed the email that said you had updated the diff. :(

This looks good. As to my comment about using an efi rtc driver on efi systems, I didn't realize there already is an efi rtc driver being attached on efi systems, meaning that we're setting the same hardware rtc twice via two different paths. I think after this gets committed, I'm going to add more logic to the atrtc probe to also avoid attaching if a working efi rtc driver already attached.

This revision is now accepted and ready to land.Mar 3 2018, 5:50 PM
This revision was automatically updated to reflect the committed changes.