On Tue, 01 Dec, at 11:50:19AM, Ard Biesheuvel wrote:
> The rtc_lock spinlock aims to serialize access to the CMOS RTC between
> the UEFI firmware and the kernel drivers that use it directly. However,
> x86 is the only arch that performs such direct accesses, and that never
> uses the time related UEFI runtime services. Since no other UEFI enlightened
> architectures have a legcay CMOS RTC anyway, we can remove the rtc_lock
> spinlock entirely.
>
> Signed-off-by: Ard Biesheuvel <[email protected]>
> ---
> drivers/firmware/efi/runtime-wrappers.c | 32 +++++---------------
> 1 file changed, 8 insertions(+), 24 deletions(-)
Is this really true? It's not possible, for instance, for 32-bit ARM
systems to use the rtc-cmos driver which would access the same
physical device that UEFI would with the GetTime() service?
With the pending 32-bit ARM UEFI support coming, this needs to be
considered carefully.
On 8 December 2015 at 13:48, Matt Fleming <[email protected]> wrote:
> On Tue, 01 Dec, at 11:50:19AM, Ard Biesheuvel wrote:
>> The rtc_lock spinlock aims to serialize access to the CMOS RTC between
>> the UEFI firmware and the kernel drivers that use it directly. However,
>> x86 is the only arch that performs such direct accesses, and that never
>> uses the time related UEFI runtime services. Since no other UEFI enlightened
>> architectures have a legcay CMOS RTC anyway, we can remove the rtc_lock
>> spinlock entirely.
>>
>> Signed-off-by: Ard Biesheuvel <[email protected]>
>> ---
>> drivers/firmware/efi/runtime-wrappers.c | 32 +++++---------------
>> 1 file changed, 8 insertions(+), 24 deletions(-)
>
> Is this really true? It's not possible, for instance, for 32-bit ARM
> systems to use the rtc-cmos driver which would access the same
> physical device that UEFI would with the GetTime() service?
>
> With the pending 32-bit ARM UEFI support coming, this needs to be
> considered carefully.
That seems highly unlikely. Even if 32-bit UEFI ARM systems existed
with this particular RTC (which is highly doubtful), it should not be
exposed to the OS in the first place, since we don't have the
compatibility concern that the PC has in that regard (where it is a
requirement)