Sponsored by: Citrix Systems R&D
Details
Details
- Reviewers
imp • ian - Group Reviewers
manpages - Commits
- rS330835: at_rtc: check in ACPI FADT boot flags if the RTC is present
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| 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". |
Comment Actions
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. |
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.