Disable the PL031 RTC DT node unconditionally rather than only when
the DT will be exposed to the OS. This allows us to defer the decision
whether to expose it to the OS to a later time without creating an
additional dependency on the FDT client code by the RTC driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This implements a library ArmVirtPL031FdtClientLib which is intended to
be incorporated into RealTimeClockRuntimeDxe via NULL library class
resolution. This allows us to make RealTimeClockRuntimeDxe depend on the
FDT client protocol, and discover the PL031 base address from the device tree
directly rather than relying on VirtFdtDxe to set the dynamic PCDs.
The NULL library class resolution approach to strictly order production and
consumption of dynamic PCDs is not generally safe in cases such as this one,
where the producer and the consumer of the PCD are both libraries. However,
since the PCD is produced in this library's constructor, and the consumer
library's constructor 'LibRtcInitialize' is not a 'true' constructor (it is
invoked explicitly by RealTimeClockRuntimeDxe), this case is guaranteed to
be safe after all.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ard Biesheuvel
Laszlo Ersek