We're currently passing the file handle for the root file system to
efi_file_read() and efi_file_close(), instead of the file handle for the
file we wish to read/close.

While this has worked up until now, it seems that it has only been by
pure luck. Olivier explains,

 "The issue is the UEFI Fat driver might return the same function for
  'fh->read()' and 'h->read()'. While in our case it does not work with
  a different implementation of EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. In our
  case, we return a different pointer when reading a directory and
  reading a file."

Fixing this actually clears up the two functions because we can drop one
of the arguments, and instead only pass a file 'handle' argument.
Reported-by: NOlivier Martin <olivier.martin@arm.com>
Reviewed-by: NOlivier Martin <olivier.martin@arm.com>
Reviewed-by: NMark Rutland <mark.rutland@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

The ARM EFI boot stub doesn't need to care about the efi_early
infrastructure that x86 requires in order to do mixed mode thunking. So
wrap everything up in an efi_call_early() macro.

This allows x86 to do the necessary indirection jumps to call whatever
firmware interface is necessary (native or mixed mode), but also allows
the ARM folks to mask the fact that they don't support relocation in the
boot stub and need to pass 'sys_table_arg' to every function.

[ hpa: there are no object code changes from this patch ]
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/20140326091011.GB2958@console-pimps.org
Cc: Roy Franz <roy.franz@linaro.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

It's not possible to dereference the EFI System table directly when
booting a 64-bit kernel on a 32-bit EFI firmware because the size of
pointers don't match.

In preparation for supporting the above use case, build a list of
function pointers on boot so that callers don't have to worry about
converting pointer sizes through multiple levels of indirection.
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Fix following sparse warnings:

drivers/firmware/efi/efivars.c:230:66: warning:
 Using plain integer as NULL pointer
drivers/firmware/efi/efi.c:236:27: warning:
 Using plain integer as NULL pointer
Signed-off-by: NDaeseok Youn <daeseok.youn@gmail.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

It makes more sense to set the feature flag in the success path of the
detection function than it does to rely on the caller doing it. Apart
from it being more logical to group the code and data together, it sets
a much better example for new EFI architectures.
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

The GOOGLE_SMI Kconfig symbol depends on DMI and selects EFI.  This
causes problems on other archs when introducing DMI support that depends
on EFI, as it results in a recursive dependency:

  arch/arm/Kconfig:1845:error: recursive dependency detected!
  arch/arm/Kconfig:1845:	symbol DMI depends on EFI

Fix by changing the 'select EFI' to a 'depends on EFI'.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch makes a couple of changes to the SMBIOS/DMI scanning
code so it can be used on other archs (such as ARM and arm64):
(a) wrap the calls to ioremap()/iounmap(), this allows the use of a
    flavor of ioremap() more suitable for random unaligned access;
(b) allow the non-EFI fallback probe into hardcoded physical address
    0xF0000 to be disabled.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: NGrant Likely <grant.likely@linaro.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Switch to memblock interfaces for early memory allocator instead of
bootmem allocator.  No functional change in beahvior than what it is in
current code from bootmem users points of view.

Archs already converted to NO_BOOTMEM now directly use memblock
interfaces instead of bootmem wrappers build on top of memblock.  And
the archs which still uses bootmem, these new apis just fallback to
exiting bootmem APIs.
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

kexec kernel will need exactly same mapping for EFI runtime memory
ranges. Thus here export the runtime ranges mapping to sysfs,
kexec-tools will assemble them and pass to 2nd kernel via setup_data.

Introducing a new directory /sys/firmware/efi/runtime-map just like
/sys/firmware/memmap. Containing below attribute in each file of that
directory:

attribute  num_pages  phys_addr  type  virt_addr
Signed-off-by: NDave Young <dyoung@redhat.com>
Tested-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Export fw_vendor, runtime and config table physical addresses to
/sys/firmware/efi/{fw_vendor,runtime,config_table} because kexec kernels
need them.

From EFI spec these 3 variables will be updated to virtual address after
entering virtual mode. But kernel startup code will need the physical
address.
Signed-off-by: NDave Young <dyoung@redhat.com>
Tested-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Some pstore backing devices use on board flash as persistent
storage. These have limited numbers of write cycles so it
is a poor idea to use them from high frequency operations.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 7ea6c6c1 ("Move cper.c from drivers/acpi/apei to
drivers/firmware/efi") results in CONFIG_EFI being enabled even
when the user doesn't want this. Since ACPI APEI used to build
fine without UEFI (and as far as I know also has no functional
depency on it), at least in that case using a reverse dependency
is wrong (and a straight one isn't needed).

Whether the same is true for ACPI_EXTLOG I don't know - if there
is a functional dependency, it should depend on EFI rather than
selecting it. It certainly has (currently) no build dependency.

Adjust Kconfig and build logic so that the bad dependency gets
avoided.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Acked-by: NTony Luck <tony.luck@intel.com>
Cc: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/52AF1EBC020000780010DBF9@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

With CONFIG_DEBUG_KOBJECT_RELEASE=y, removing and immediately reloading the
dmi-sysfs module causes the following warning:

  sysfs: cannot create duplicate filename '/firmware/dmi'
  kobject_add_internal failed for dmi with -EEXIST, don't try to register things with the same name in the same directory.

The "dmi" directory stays in sysfs until the dmi_kobj is released, and
DEBUG_KOBJECT_RELEASE delays that.

I don't think we can hit this problem in normal usage because dmi_kobj is
static and nothing outside dmi-sysfs can get a reference to it, so the
only way to delay the "dmi" release is with DEBUG_KOBJECT_RELEASE.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Removing the dmi-sysfs module causes the following warning:

  # modprobe -r dmi_sysfs
  WARNING: CPU: 11 PID: 6785 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
  sysfs: can not remove 'raw', no directory

This is because putting the entry kobject, e.g., for
"/sys/firmware/dmi/entries/19-0", removes the directory and all its
contents.  By the time dmi_sysfs_entry_release() runs, the "raw" file
inside ".../19-0/" has already been removed.

Therefore, we don't need to remove the "raw" bin file at all in
dmi_sysfs_entry_release().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

To avoid build problems and breaking dependencies between ACPI header
files, <acpi/acpi.h> should not be included directly by code outside
of the ACPI core subsystem, but this is done by the ACPI iSCSI
Boot Firmware code.

The iBFT specification doesn't mention whether or not it can appear
on a non-ACPI platform, but is says that ACPI 3.0b defines the
mechanism.  The current CONFIG_ISCSI_IBFT_FIND code doesn't use the
ACPI tables API to locate the table, so it doesn't rely on CONFIG_ACPI
directly.

However, since iBFT is is an ACPI-based mechanism (please refer to
the documentation link below for more information), it should be
correct to make CONFIG_ISCSI_IBFT_FIND depend on CONFIG_ACPI (even
though the table location can be implemented without using ACPI
tables API).

After that change, include/linux/iscsi_ibft.h can be modified to
include <linux/acpi.h> instead of <acpi/acpi.h> as appropriate.

References: http://www.microsoft.com/whdc/system/platform/firmware/ibft.mspx
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
[rjw: Subject and changelog]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Pstore fs expects that backends provide a unique id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed-off-by: NMadper Xie <cxie@redhat.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Currently, when mounting pstore file system, a read callback of
efi_pstore driver runs mutiple times as below.

- In the first read callback, scan efivar_sysfs_list from head and pass
  a kmsg buffer of a entry to an upper pstore layer.
- In the second read callback, rescan efivar_sysfs_list from the entry
  and pass another kmsg buffer to it.
- Repeat the scan and pass until the end of efivar_sysfs_list.

In this process, an entry is read across the multiple read function
calls. To avoid race between the read and erasion, the whole process
above is protected by a spinlock, holding in open() and releasing in
close().

At the same time, kmemdup() is called to pass the buffer to pstore
filesystem during it. And then, it causes a following lockdep warning.

To make the dynamic memory allocation runnable without taking spinlock,
holding off a deletion of sysfs entry if it happens while scanning it
via efi_pstore, and deleting it after the scan is completed.

To implement it, this patch introduces two flags, scanning and deleting,
to efivar_entry.

On the code basis, it seems that all the scanning and deleting logic is
not needed because __efivars->lock are not dropped when reading from the
EFI variable store.

But, the scanning and deleting logic is still needed because an
efi-pstore and a pstore filesystem works as follows.

In case an entry(A) is found, the pointer is saved to psi->data.  And
efi_pstore_read() passes the entry(A) to a pstore filesystem by
releasing  __efivars->lock.

And then, the pstore filesystem calls efi_pstore_read() again and the
same entry(A), which is saved to psi->data, is used for resuming to scan
a sysfs-list.

So, to protect the entry(A), the logic is needed.

[    1.143710] ------------[ cut here ]------------
[    1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740 lockdep_trace_alloc+0x104/0x110()
[    1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[    1.144058] Modules linked in:
[    1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2
[    1.144058]  0000000000000009 ffff8800797e9ae0 ffffffff816614a5 ffff8800797e9b28
[    1.144058]  ffff8800797e9b18 ffffffff8105510d 0000000000000080 0000000000000046
[    1.144058]  00000000000000d0 00000000000003af ffffffff81ccd0c0 ffff8800797e9b78
[    1.144058] Call Trace:
[    1.144058]  [<ffffffff816614a5>] dump_stack+0x54/0x74
[    1.144058]  [<ffffffff8105510d>] warn_slowpath_common+0x7d/0xa0
[    1.144058]  [<ffffffff8105517c>] warn_slowpath_fmt+0x4c/0x50
[    1.144058]  [<ffffffff8131290f>] ? vsscanf+0x57f/0x7b0
[    1.144058]  [<ffffffff810bbd74>] lockdep_trace_alloc+0x104/0x110
[    1.144058]  [<ffffffff81192da0>] __kmalloc_track_caller+0x50/0x280
[    1.144058]  [<ffffffff815147bb>] ? efi_pstore_read_func.part.1+0x12b/0x170
[    1.144058]  [<ffffffff8115b260>] kmemdup+0x20/0x50
[    1.144058]  [<ffffffff815147bb>] efi_pstore_read_func.part.1+0x12b/0x170
[    1.144058]  [<ffffffff81514800>] ? efi_pstore_read_func.part.1+0x170/0x170
[    1.144058]  [<ffffffff815148b4>] efi_pstore_read_func+0xb4/0xe0
[    1.144058]  [<ffffffff81512b7b>] __efivar_entry_iter+0xfb/0x120
[    1.144058]  [<ffffffff8151428f>] efi_pstore_read+0x3f/0x50
[    1.144058]  [<ffffffff8128d7ba>] pstore_get_records+0x9a/0x150
[    1.158207]  [<ffffffff812af25c>] ? selinux_d_instantiate+0x1c/0x20
[    1.158207]  [<ffffffff8128ce30>] ? parse_options+0x80/0x80
[    1.158207]  [<ffffffff8128ced5>] pstore_fill_super+0xa5/0xc0
[    1.158207]  [<ffffffff811ae7d2>] mount_single+0xa2/0xd0
[    1.158207]  [<ffffffff8128ccf8>] pstore_mount+0x18/0x20
[    1.158207]  [<ffffffff811ae8b9>] mount_fs+0x39/0x1b0
[    1.158207]  [<ffffffff81160550>] ? __alloc_percpu+0x10/0x20
[    1.158207]  [<ffffffff811c9493>] vfs_kern_mount+0x63/0xf0
[    1.158207]  [<ffffffff811cbb0e>] do_mount+0x23e/0xa20
[    1.158207]  [<ffffffff8115b51b>] ? strndup_user+0x4b/0xf0
[    1.158207]  [<ffffffff811cc373>] SyS_mount+0x83/0xc0
[    1.158207]  [<ffffffff81673cc2>] system_call_fastpath+0x16/0x1b
[    1.158207] ---[ end trace 61981bc62de9f6f4 ]---
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Tested-by: NMadper Xie <cxie@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Firmware is not required to maintain alignment of SMBIOS
entries, so we should take care accessing fields within these
structures. Use "get_unaligned()" to avoid problems.

[ Found on ia64 (which grumbles about unaligned access) ]
Signed-off-by: NTony Luck <tony.luck@intel.com>
Cc: Chen Gong <gong.chen@linux.intel.com>
Link: http://lkml.kernel.org/r/27d82dbff5be1025bf18ab88498632d36c2fcf3c.1383331440.git.tony.luck@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

cper.c contains code to decode and print "Common Platform Error Records".
Originally added under drivers/acpi/apei because the only user was in that
same directory - but now we have another consumer, and we shouldn't have
to force CONFIG_ACPI_APEI get access to this code.

Since CPER is defined in the UEFI specification - the logical home for
this code is under drivers/firmware/efi/
Acked-by: NMatt Fleming <matt.fleming@intel.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This driver doesn't need to directly access DMA masks if it uses the
platform_device_register_full() API rather than
platform_device_register_simple() - the former function can initialize
the DMA mask appropriately.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

dcdbas was explicitly initializing DMA masks thusly:
	dcdbas_pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
	dcdbas_pdev->dev.dma_mask = &dcdbas_pdev->dev.coherent_dma_mask;
which bypasses the architecture check.  Moreover, it is creating the
dcdbas_pdev device itself, and using the platform_device_register_full()
avoids some of this explicit initialization.

Convert the driver to use platform_device_register_full(), and as it
makes use of coherent DMA, also call dma_set_coherent_mask() to ensure
that the architecture gets to check the mask.
Tested-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch adds a new interface to decode memory device (type 17)
to help error reporting on DIMMs.

Original-author: Tony Luck <tony.luck@intel.com>
Signed-off-by: NChen, Gong <gong.chen@linux.intel.com>
Acked-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Remove a redundant memset() call from efi_relocate_kernel() that
was clearing memory that would be used by BSS in non-compressed
images loaded with this function.  This clear was redundant with
the clearing done in the image itself, and also implemented incorrectly
with a 0 length.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Acked-by: NMark Salter <msalter@redhat.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

warnings from gcc:
warning: label 'free_pool' defined but not used [-Wunused-label]
warning: value computed is not used [-Wunused-value]
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

EFI calls can made directly on ARM, so the function pointers
are directly invoked.  This allows types to be checked at
compile time, so here we ensure that the parameters match
the function signature. The wrappers used by x86 prevent
any type checking.
Correct the type of chunksize to be based on native
width as specified by the EFI_FILE_PROTOCOL read()
function.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Rename variables to be not initrd specific, as now the function
loads arbitrary files.  This change is exclusively renames
and comment changes to reflect the generalization.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Acked-by: NMark Salter <msalter@redhat.com>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

The handle_cmdline_files now takes the option to handle as a string,
and returns the loaded data through parameters, rather than taking
an x86 specific setup_header structure.  For ARM, this will be used
to load a device tree blob in addition to initrd images.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Acked-by: NMark Salter <msalter@redhat.com>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Make efi_free() safely callable with size of 0, similar to free() being
callable with NULL pointers, and do nothing in that case.
Remove size checks that this makes redundant.  This also avoids some
size checks in the ARM EFI stub code that will be added as well.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Add arguments for returning the descriptor version and also
the memory map key.  The key is required for calling
exit_boot_services().
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Rename function in preparation for making it more flexible
and sharing it.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Move the open-coded conversion to a shared function for
use by all architectures.  Change the allocation to prefer
a high address for ARM, as this is required to avoid conflicts
with reserved regions in low memory.  We don't know the specifics
of these regions until after we process the command line and
device tree.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Rename relocate_kernel() to efi_relocate_kernel(), and take
parameters rather than x86 specific structure.  Add max_addr
argument as for ARM we have some address constraints that we
need to enforce when relocating the kernel.  Add alloc_size
parameter for use by ARM64 which uses an uncompressed kernel,
and needs to allocate space for BSS.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

The relocate_kernel() function will be generalized and used
by all architectures, as they all have similar requirements.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

The efi_high_alloc() and efi_low_alloc() functions
use the EFI_ALLOCATE_ADDRESS option to the EFI
function allocate_pages(), which requires a minimum
of page alignment, and rejects all other requests.
The existing code could fail to allocate depending
on allocation size, as although repeated allocation
attempts were made, none were guaranteed to be page
aligned.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Acked-by: NMark Salter <msalter@redhat.com>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Rename them to be more similar, as low_free() could be used to free
memory allocated by both high_alloc() and low_alloc().
high_alloc() -> efi_high_alloc()
low_alloc()  -> efi_low_alloc()
low_free()   -> efi_free()
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Acked-by: NMark Salter <msalter@redhat.com>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Add system table pointer argument to shared EFI stub related functions
so they no longer use a global system table pointer as they did when part
of eboot.c.  For the ARM EFI stub this allows us to avoid global
variables completely and thereby not have to deal with GOT fixups.
Not having the EFI stub fixup its GOT, which is shared with the
decompressor, simplifies the relocating of the zImage to a
bootable address.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

No code changes made, just moving functions and #define from x86 arch
directory to common location.  Code is shared using #include, similar
to how decompression code is shared among architectures.
Signed-off-by: NRoy Franz <roy.franz@linaro.org>
Acked-by: NMark Salter <msalter@redhat.com>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

As reported by Joe Perches: OOM messages generally aren't useful.
dmi_alloc is either a trivial front-end to kzalloc, and kzalloc already
does a dump_stack() when OOM, or for x86, dmi_alloc uses extend_brk
which BUGs when unsuccessful.

So we can remove all 6 such log messages in the dmi_scan driver, to
shrink the binary size (by 528 bytes on x86_64.)
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Reported-by: NJoe Perches <joe@perches.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add const to all DMI string pointers where this is possible.  This fixes a
checkpatch warning.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Joe Perches <joe@perches.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix all errors and trivial warnings reported by checkpatch for file
drivers/firmware/dmi_scan.c.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Joe Perches <joe@perches.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>