lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 29 Apr 2014 12:21:02 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Leif Lindholm <leif.lindholm@...aro.org>
Cc:	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, matt.fleming@...el.com,
	catalin.marinas@....com, msalter@...hat.com,
	grant.likely@...aro.org, roy.franz@...aro.org,
	ard.biesheuvel@...aro.org, mark.rutland@....com,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH v2 03/10] efi: add helper function to get UEFI params
 from FDT

On Fri, 25 Apr, at 05:09:07PM, Leif Lindholm wrote:
> From: Mark Salter <msalter@...hat.com>
> 
> ARM and ARM64 architectures use the device tree to pass UEFI parameters
> from stub to kernel. These parameters are things known to the stub but
> not discoverable by the kernel after the stub calls ExitBootSerives().
> There is a helper function in:
> 
>    drivers/firmware/efi/fdt.c
> 
> which the stub uses to add the UEFI parameters to the device tree.
> This patch adds a complimentary helper function which UEFI runtime
> support may use to retrieve the parameters from the device tree.
> If an architecture wants to use this helper, it should select
> CONFIG_UEFI_PARAMS_FROM_FDT.
> 
> Signed-off-by: Mark Salter <msalter@...hat.com>
> Signed-off-by: Leif Lindholm <leif.lindholm@...aro.org>
> ---
>  drivers/firmware/efi/Kconfig |    7 ++++
>  drivers/firmware/efi/efi.c   |   79 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/efi.h          |    9 +++++
>  3 files changed, 95 insertions(+)

Looks OK, but is there any chance we could swap CONFIG_UEFI_* for
CONFIG_EFI_* when someone picks this up? We've generally done pretty
well to keep the naming consistent and I'd like to hold on to that
consistency for as long as possible (especially since the function names
begin efi_*).

And yes, I realise that no one (apart from perhaps Apple) ships with EFI
anymore and it's all UEFI, but we've kinda developed our own naming
scheme at this point.

Otherwise, 

Acked-by: Matt Fleming <matt.fleming@...el.com>

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ