linux-stable.git/drivers/firmware/Makefile, branch linux-3.19.y

x86/efi: Don't select EFI from certain special ACPI drivers

2013-12-19T20:32:46+00:00

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: Jan Beulich 
Acked-by: Tony Luck 
Cc: Matt Fleming 
Link: http://lkml.kernel.org/r/52AF1EBC020000780010DBF9@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar

efi: split efisubsystem from efivars

2013-04-17T12:27:06+00:00

This registers /sys/firmware/efi/{,systab,efivars/} whenever EFI is enabled
and the system is booted with EFI.

This allows
 *) userspace to check for the existence of /sys/firmware/efi as a way
    to determine whether or it is running on an EFI system.
 *) 'mount -t efivarfs none /sys/firmware/efi/efivars' without manually
    loading any modules.

[ Also, move the efivar API into vars.c and unconditionally compile it.
  This allows us to move efivars.c, which now only contains the sysfs
  variable code, into the firmware/efi directory. Note that the efivars.c
  filename is kept to maintain backwards compatability with the old
  efivars.ko module. With this patch it is now possible for efivarfs
  to be built without CONFIG_EFI_VARS - Matt ]

Cc: Seiji Aguchi 
Cc: Tony Luck 
Cc: Mike Waychison 
Cc: Kay Sievers 
Cc: Jeremy Kerr 
Cc: Matthew Garrett 
Cc: Chun-Yi Lee 
Cc: Andy Whitcroft 
Cc: Tobias Powalowski 
Signed-off-by: Tom Gundersen 
Signed-off-by: Matt Fleming

efivars: Move pstore code into the new EFI directory

2013-04-17T12:24:01+00:00

efivars.c has grown far too large and needs to be divided up. Create a
new directory and move the persistence storage code to efi-pstore.c now
that it uses the new efivar API. This helps us to greatly reduce the
size of efivars.c and paves the way for moving other code out of
efivars.c.

Note that because CONFIG_EFI_VARS can be built as a module efi-pstore
must also include support for building as a module.

Reviewed-by: Tom Gundersen 
Tested-by: Tom Gundersen 
Cc: Seiji Aguchi 
Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Matthew Garrett 
Cc: Tony Luck 
Signed-off-by: Matt Fleming

ASoC: Move SigmaDSP firmware loader to ASoC

2011-11-29T12:01:10+00:00

It has been pointed out previously, that the firmware subsystem is not the right
place for the SigmaDSP firmware loader. Furthermore the SigmaDSP is currently
only used in audio products and we are aiming for better integration into the
ASoC framework in the future, with support for ALSA controls for firmware
parameters and support dynamic power management as well. So the natural choice
for the SigmaDSP firmware loader is the ASoC subsystem.

Signed-off-by: Lars-Peter Clausen 
Acked-by: Mike Frysinger 
Signed-off-by: Mark Brown

Introduce CONFIG_GOOGLE_FIRMWARE

2011-04-30T01:09:35+00:00

In order to keep Google's firmware drivers organized amongst themselves,
all Google firmware drivers are gated on CONFIG_GOOGLE_FIRMWARE=y, which
defaults to 'n' in the kernel build.

Signed-off-by: Mike Waychison 
Signed-off-by: Greg Kroah-Hartman

driver: Google EFI SMI

2011-04-30T01:09:34+00:00

The "gsmi" driver bridges userland with firmware specific routines for
accessing hardware.

Currently, this driver only supports NVRAM and eventlog information.
Deprecated functions have been removed from the driver, though their
op-codes are left in place so that they are not re-used.

This driver works by trampolining into the firmware via the smi_command
outlined in the FADT table.  Three protocols are used due to various
limitations over time, but all are included herein.

This driver should only ever load on Google boards, identified by either
a "Google, Inc." board vendor string in DMI, or "GOOGLE" in the OEM
strings of the FADT ACPI table.  This logic happens in
gsmi_system_valid().

Signed-off-by: Duncan Laurie 
Signed-off-by: Aaron Durbin 
Signed-off-by: Mike Waychison 
Signed-off-by: Greg Kroah-Hartman

sigma-firmware: loader for Analog Devices' SigmaStudio

2011-03-23T00:44:15+00:00

Analog Devices' SigmaStudio can produce firmware blobs for devices with
these DSPs embedded (like some audio codecs).  Allow these device drivers
to easily parse and load them.

Signed-off-by: Mike Frysinger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

firmware: Basic dmi-sysfs support

2011-02-25T20:01:19+00:00

Introduce a new module "dmi-sysfs" that exports the broken out entries
of the DMI table through sysfs.

Entries are enumerated via dmi_walk() on module load, and are populated
as kobjects rooted at /sys/firmware/dmi/entries.

Entries are named "-", where:
   	: is the type of the entry, and
   	: is the ordinal count within the DMI table of that
		  entry type.  This instance is used in lieu the DMI
		  entry's handle as no assurances are made by the kernel
		  that handles are unique.

All entries export the following attributes:
   length	: The length of the formatted portion of the entry
   handle	: The handle given to this entry by the firmware
   raw		: The raw bytes of the entire entry, including the
		  formatted portion, the unformatted (strings) portion,
		  and the two terminating nul characters.
   type		: The DMI entry type
   instance	: The ordinal instance of this entry given its type.
   position	: The position ordinal of the entry within the table in
		  its entirety.

Entries in dmi-sysfs are kobject backed members called "struct
dmi_sysfs_entry" and belong to dmi_kset.  They are threaded through
entry_list (protected by entry_list_lock) so that we can find them at
cleanup time.

Signed-off-by: Mike Waychison 
Signed-off-by: Greg Kroah-Hartman

[SCSI] iscsi boot: mv iscsi_boot_sysfs to drivers/scsi

2010-08-06T15:45:07+00:00

iscsi_boot_sysfs does not depend on firmware. Any iscsi driver
can use it. This patch moves iscsi_boot_sysfs to the scsi
dir, so that it can be used on any arch with any driver.

Signed-off-by: Mike Christie 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: James Bottomley

ibft: separate ibft parsing from sysfs interface

2010-05-11T17:02:38+00:00

Not all iscsi drivers support ibft. For drivers like be2iscsi
that do not but are bootable through a vendor firmware specific
format/process this patch moves the sysfs interface from the ibft code
to a lib module. This then allows userspace tools to search for iscsi boot
info in a common place and in a common format.

ibft iscsi boot info is exported in the same place as it was
before: /sys/firmware/ibft.

vendor/fw boot info gets export in /sys/firmware/iscsi_bootX, where X is the
scsi host number of the HBA. Underneath these parent dirs, the
target, ethernet, and initiator dirs are the same as they were before.

Signed-off-by: Mike Christie 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Peter Jones