Use EFI RTC capablities info when registering, add bootverbose diagnostics.

[• ian]

Summary

Make some small improvements to the efirtc driver by obtaining the clock capabilities (resolution and whether the sub-second counters are reset) and using the info when registering the clock. When the hardware zeroes out the subsecond info on clock-set, schedule clock updates to happen just before top-of-second, so that the RTC time is closely in-sync with kernel time.

Also, in the identify() routine, always add the driver if EFI runtime services are available, then decide in probe() whether to attach the driver or not. If not attaching and bootverbose is on, say why. All of this is basically to avoid "silent failure" -- if someone thinks there should be an efi rtc and it's not attaching, at least they can set bootverbose and maybe get a clue from the output.

[andrew]

sys/dev/efidev/efirtc.c

56

By not checking efi_get_time we are claiming the interface exists so a driver could attach, however this may be incorrect when booting from U-Boot. By moving the check to the probe function another driver could potentially try attaching.

81

This was 0 to stop probing at this driver. We know this is the correct driver to use because of the identify function adding it.

107

Why is this global, and not in the softc?

[• ian]

sys/dev/efidev/efirtc.c

56

If runtime services exist, it's a fair presumption that rtc support exists. If it doesn't, that probably merits a mention. So if runtime services exist it adds the driver, and then the probe routine can probe check whether the support the driver needs is available and log things appropriately.

IMO, all of this reflects the way newbus should work. identify() adds drivers that may be needed on the current hardware / system, but it is probe() that decides whether the driver should attach to the hardware or not.

81

IMO, that's completely inappropriate. This is the default driver for an efi rtc, not the the and only driver that can possibly exist for it. In fact, it's hard to make a case that ANY driver in the base system should ever return 0.

It's completely reasonable that somebody else might have a local custom driver for the efi rtc that they want to use instead of the default system driver. It's also possible that someone has a crappier driver that bids at a lower priority (maybe all it does is something like panic in attach() to ensure the system doesn't run without a good rtc driver). The point is, the design of newbus is to add all the drivers that might be able to handle the hardware, then let them bid for it in probe().

107

There is no softc, and no possibility that more than one instance can attach, so a static var works fine. If you know of a way that multiple instances can be attached, I can add a softc to hold this value.