All of lore.kernel.org
 help / color / mirror / Atom feed
From: Francesco Lavra <francescolavra.fl@gmail.com>
To: grub-devel@gnu.org
Subject: Re: [PATCH 7/7] Add support for ARM UEFI ("EFI") platforms
Date: Mon, 01 Apr 2013 12:41:10 +0200	[thread overview]
Message-ID: <51596446.3030709@gmail.com> (raw)
In-Reply-To: <5158F171.6030702@gmail.com>

On 04/01/2013 04:31 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> +static grub_uint64_t
> 
>> +grub_efi_get_time_ms(void)
>> +{
>> +  grub_efi_time_t now;
>> +  grub_uint64_t retval;
>> +  grub_efi_status_t status;
>> +
>> +  status = efi_call_2 (grub_efi_system_table->runtime_services->get_time,
>> +		       &now, NULL);
>> +  if (status != GRUB_EFI_SUCCESS)
>> +    {
>> +      grub_printf("No time!\n");
>> +      return 0;
> 
> This is about the worse thing you can do. It will make any timeout go wrong.

How would you handle such a case? I guess a machine which can't provide
this runtime service would need some more work in its EFI firmware
before being ready for GRUB, so perhaps this is a moot point.

> 
>> +    }
>> +  retval = now.year * 365 * 24 * 60 * 60 * 1000;
>> +  retval += now.month * 30 * 24 * 60 * 60 * 1000;
>> +  retval += now.day * 24 * 60 * 60 * 1000;
>> +  retval += now.hour * 60 * 60 * 1000;
>> +  retval += now.minute * 60 * 1000;
>> +  retval += now.second * 1000;
>> +  retval += now.nanosecond / 1000;
>> + 
>> +  grub_dprintf("timer", "timestamp: 0x%llx\n", retval);
>> +
>> +  return retval;
> 
> This is almost a verbatim copy of what we had for i386 efi before but it
> went haywire in many ways. Like jumps forward or backward around end of
> month or when one sets datetime. Or around the summer/winter timezone
> transition.

I propose to re-use the existing function grub_datetime2unixtime()
(which handles correctly the number of days of each month, as well as
leap years), instead of doing the calculations here. And take into
account the time_zone member of grub_efi_time_t as well.
Here is how I would write it:

grub_uint64_t
grub_efi_get_time_ms (void)
{
  grub_efi_time_t efi_time;
  struct grub_datetime datetime;
  grub_int32_t unixtime;
  grub_uint64_t retval;

  if (efi_call_2 (grub_efi_system_table->runtime_services->get_time,
                  &efi_time, 0) != GRUB_EFI_SUCCESS)
    {
      grub_printf("No time!\n");
      return 0;
    }
  datetime.year = efi_time.year;
  datetime.month = efi_time.month;
  datetime.day = efi_time.day;
  datetime.hour = efi_time.hour;
  datetime.minute = efi_time.minute;
  datetime.second = efi_time.second;
  if (!grub_datetime2unixtime (&datetime, &unixtime))
	return 0;
  unixtime += 60 * efi_time.time_zone;
  retval = (grub_uint64_t)unixtime * 1000
           + efi_time.nanosecond / 1000000;
  grub_dprintf("timer", "timestamp: 0x%llx\n", retval);
  return retval;
}

Also, there is nothing ARM-specific in this function, so I would put it
in a generic EFI file like kern/efi/efi.c.

> Does ARM have anything like TSC?

ARMv7 does not have an architecturally-defined mechanism of retrieving
the timestamp, it's up to the system peripherals to provide time-keeping
capabilities.

--
Francesco


  reply	other threads:[~2013-04-01 10:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-24 17:01 [PATCH 7/7] Add support for ARM UEFI ("EFI") platforms Leif Lindholm
2013-04-01  2:31 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-04-01 10:41   ` Francesco Lavra [this message]
2013-04-01 11:23     ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-04-01 14:10       ` Francesco Lavra
2013-04-01 14:16         ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-04-01 14:49           ` Francesco Lavra
2013-04-03 17:50   ` Leif Lindholm
2013-04-01 16:24 ` Francesco Lavra
2013-04-03 18:07   ` Leif Lindholm
2013-04-03 20:01     ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-04-04 12:54       ` Leif Lindholm
2013-04-09 17:30         ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-05-09 18:08           ` Leif Lindholm
2013-05-11  8:42             ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-05-11 18:00             ` Francesco Lavra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51596446.3030709@gmail.com \
    --to=francescolavra.fl@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.