Age | Commit message (Collapse) | Author | Files | Lines |
|
From auditing all the mktime() users, there seems to be only a *very*
small window around new years day where we could possibly return
incorrect data to the OS, and even then, there would have to be FSP
reset/reload on FSP machines. I don't *think* there's an opportunity
on other machines.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
While reviewing the Debian packaging, codespell found those.
Most proposed fixes are based on codespell's default dictionnary.
Signed-off-by: Frederic Bonnard <frediz@linux.vnet.ibm.com>
Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Both the FSP RTC and the upcoming IPMI RTC implementation need to
manipulate time in various ways. Rather than re-implementing slightly
different versions of the calculations twice lets implement some
standard library functions (with tests) and use those.
This patch adds mktime and gmtime_r to the libc.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|