This patch hooks up the support for device power domain provided by
SCPI using the Linux generic power domain infrastructure.

Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Tested-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Tested-by: NJon Medhurst <tixy@linaro.org>
Reviewed-by: NJon Medhurst <tixy@linaro.org>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Make fw_cfg entries of type "file" available via sysfs. Entries
are listed under /sys/firmware/qemu_fw_cfg/by_key, in folders
named after each entry's selector key. Filename, selector value,
and size read-only attributes are included for each entry. Also,
a "raw" attribute allows retrieval of the full binary content of
each entry.

The fw_cfg device can be instantiated automatically from ACPI or
the Device Tree, or manually by using a kernel module (or command
line) parameter, with a syntax outlined in the documentation file.
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This gives us a function for making mailbox property channel requests
of the firmware, which is most notable in that it will let us get and
set clock rates.
Signed-off-by: NEric Anholt <eric@anholt.net>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>

The ".arch_extension sec" directive is only available on ARMv6 or higher,
so if we enable the SCM driver while building a kernel for an older CPU,
we get a build error:

/tmp/ccUyhMOY.s:130: Error: selected processor does not support ARM mode `smc #0'
/tmp/ccUyhMOY.s:216: Error: selected processor does not support ARM mode `smc #0'
/tmp/ccUyhMOY.s:373: Error: selected processor does not support ARM mode `smc #0'
make[4]: *** [drivers/firmware/qcom_scm-32.o] Error 1

This changes the Makefile so we pass the ARMv7 architecture level both
for the check and for the actual compilation of the scm driver.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAndy Gross <agross@codeaurora.org>

This patch adds support for System Control and Power Interface (SCPI)
Message Protocol used between the Application Cores(AP) and the System
Control Processor(SCP). The MHU peripheral provides a mechanism for
inter-processor communication between SCP's M3 processor and AP.

SCP offers control and management of the core/cluster power states,
various power domain DVFS including the core/cluster, certain system
clocks configuration, thermal sensors and many others.

This protocol driver provides interface for all the client drivers using
SCPI to make use of the features offered by the SCP.
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Reviewed-by: NJon Medhurst (Tixy) <tixy@linaro.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

This patch adds stubs for the SCM functions exposed in the QCOM SCM API.
Signed-off-by: NAndy Gross <agross@codeaurora.org>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>

To enable sharing with arm, move the core PSCI framework code to
drivers/firmware. This results in a minor gain in lines of code, but
this will quickly be amortised by the removal of code currently
duplicated in arch/arm.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

After Broadcom switched from MIPS to ARM for their home routers we need
to have NVRAM driver in some common place (not arch/mips/). As explained
in Kconfig, this driver is responsible for parsing SoC configuration
data that is passed to the kernel in flash from the bootloader firmware
called "CFE".

We were thinking about putting it in bus directory, however there are
two possible buses for MIPS: drivers/ssb/ and drivers/bcma/. So this
won't fit there and this is why I would like to move this driver to the
drivers/firmware/.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Cc: linux-mips@linux-mips.org
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mike Waychison <mikew@google.com>
Cc: Roy Franz <roy.franz@linaro.org>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Patchwork: https://patchwork.linux-mips.org/patch/10544/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Split out the 32-bit SCM implementation into its own file to prep for
supporting a 64-bit/ARM64 implementation as well.  We create a simple shim
to ensure both versions conform to the same interface.
Signed-off-by: NKumar Gala <galak@codeaurora.org>

Architectural changes in the ARM Linux kernel tree mandate the eventual
removal of the mach-* directories. Move the scm driver to
drivers/firmware and the scm header to include/linux to support that
removal.
Signed-off-by: NKumar Gala <galak@codeaurora.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>

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 <seiji.aguchi@hds.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Mike Waychison <mikew@google.com>
Cc: Kay Sievers <kay@vrfy.org>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Chun-Yi Lee <jlee@suse.com>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Tobias Powalowski <tpowa@archlinux.org>
Signed-off-by: NTom Gundersen <teg@jklm.no>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

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: NTom Gundersen <teg@jklm.no>
Tested-by: NTom Gundersen <teg@jklm.no>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Anton Vorontsov <cbouatmailru@gmail.com>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

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: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NDuncan Laurie <dlaurie@google.com>
Signed-off-by: NAaron Durbin <adurbin@google.com>
Signed-off-by: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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 "<type>-<instance>", where:
   <type>	: is the type of the entry, and
   <instance>	: 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: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NMike Christie <mchristi@redhat.com>
Acked-by: NKonrad Rzeszutek Wilk <konrad@kernel.org>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad@kernel.org>
Signed-off-by: NPeter Jones <pjones@redhat.com>

This patch adds /sys/firmware/memmap interface that represents the BIOS
(or Firmware) provided memory map. The tree looks like:

    /sys/firmware/memmap/0/start   (hex number)
                           end     (hex number)
                           type    (string)
    ...                 /1/start
                           end
                           type

With the following shell snippet one can print the memory map in the same form
the kernel prints itself when booting on x86 (the E820 map).

  --------- 8< --------------------------
    #!/bin/sh
    cd /sys/firmware/memmap
    for dir in * ; do
        start=$(cat $dir/start)
        end=$(cat $dir/end)
        type=$(cat $dir/type)
        printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
    done
  --------- >8 --------------------------

That patch only provides the needed interface:

 1. The sysfs interface.
 2. The structure and enumeration definition.
 3. The function firmware_map_add() and firmware_map_add_early()
    that should be called from architecture code (E820/EFI, for
    example) to add the contents to the interface.

If the kernel is compiled without CONFIG_FIRMWARE_MEMMAP, the interface does
nothing without cluttering the architecture-specific code with #ifdef's.

The purpose of the new interface is kexec: While /proc/iomem represents
the *used* memory map (e.g. modified via kernel parameters like 'memmap'
and 'mem'), the /sys/firmware/memmap tree represents the unmodified memory
map provided via the firmware. So kexec can:

 - use the original memory map for rebooting,
 - use the /proc/iomem for setting up the ELF core headers for kdump
   case that should only represent the memory of the system.

The patch has been tested on i386 and x86_64.
Signed-off-by: NBernhard Walle <bwalle@suse.de>
Acked-by: NGreg KH <gregkh@suse.de>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Cc: kexec@lists.infradead.org
Cc: yhlu.kernel@gmail.com
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with
text properties which export the the iSCSI Boot Firmware Table (iBFT)
structure.

What is iSCSI Boot Firmware Table?  It is a mechanism for the iSCSI tools to
extract from the machine NICs the iSCSI connection information so that they
can automagically mount the iSCSI share/target.  Currently the iSCSI
information is hard-coded in the initrd.  The /sysfs entries are read-only
one-name-and-value fields.

The usual set of data exposed is:

# for a in `find /sys/firmware/ibft/ -type f -print`; do  echo -n "$a: ";  cat $a; done
/sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb
/sys/firmware/ibft/target0/nic-assoc: 0
/sys/firmware/ibft/target0/chap-type: 0
/sys/firmware/ibft/target0/lun: 00000000
/sys/firmware/ibft/target0/port: 3260
/sys/firmware/ibft/target0/ip-addr: 192.168.79.116
/sys/firmware/ibft/target0/flags: 3
/sys/firmware/ibft/target0/index: 0
/sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
/sys/firmware/ibft/ethernet0/vlan: 0
/sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
/sys/firmware/ibft/ethernet0/origin: 0
/sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
/sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
/sys/firmware/ibft/ethernet0/flags: 7
/sys/firmware/ibft/ethernet0/index: 0
/sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator
/sys/firmware/ibft/initiator/flags: 3
/sys/firmware/ibft/initiator/index: 0

For full details of the IBFT structure please take a look at:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

[akpm@linux-foundation.org: fix build]
Signed-off-by: NKonrad Rzeszutek <konradr@linux.vnet.ibm.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Peter Jones <pjones@redhat.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The patch below adds DMI/SMBIOS based module autoloading to the Linux
kernel. The idea is to load laptop drivers automatically (and other
drivers which cannot be autoloaded otherwise), based on the DMI system
identification information of the BIOS.

Right now most distros manually try to load all available laptop
drivers on bootup in the hope that at least one of them loads
successfully. This patch does away with all that, and uses udev to
automatically load matching drivers on the right machines.

Basically the patch just exports the DMI information that has been
parsed by the kernel anyway to userspace via a sysfs device
/sys/class/dmi/id and makes sure that proper modalias attributes are
available. Besides adding the "modalias" attribute it also adds
attributes for a few other DMI fields which might be useful for
writing udev rules.

This patch is not an attempt to export the entire DMI/SMBIOS data to
userspace. We already have "dmidecode" which parses the complete DMI
info from userspace. The purpose of this patch is machine model
identification and good udev integration.

To take advantage of DMI based module autoloading, a driver should
export one or more MODULE_ALIAS fields similar to these:

MODULE_ALIAS("dmi:*:svnMICRO-STARINT'LCO.,LTD:pnMS-1013:pvr0131*:cvnMICRO-STARINT'LCO.,LTD:ct10:*");
MODULE_ALIAS("dmi:*:svnMicro-StarInternational:pnMS-1058:pvr0581:rvnMSI:rnMS-1058:*:ct10:*");
MODULE_ALIAS("dmi:*:svnMicro-StarInternational:pnMS-1412:*:rvnMSI:rnMS-1412:*:cvnMICRO-STARINT'LCO.,LTD:ct10:*");
MODULE_ALIAS("dmi:*:svnNOTEBOOK:pnSAM2000:pvr0131*:cvnMICRO-STARINT'LCO.,LTD:ct10:*");

These lines are specific to my msi-laptop.c driver. They are basically
just a concatenation of a few carefully selected DMI fields with all
potentially bad characters stripped.

Besides laptop drivers, modules like "hdaps", the i2c modules
and the hwmon modules are good candidates for "dmi:" MODULE_ALIAS
lines.

Besides merely exporting the DMI data via sysfs the patch adds
support for a few more DMI fields. Especially the CHASSIS fields are
very useful to identify different laptop modules. The patch also adds
working MODULE_ALIAS lines to my msi-laptop.c driver.

I'd like to thank Kay Sievers for helping me to clean up this patch
for posting it on lkml.

Patch is against Linus' current GIT HEAD. Should probably apply to
older kernels as well without modification.
Signed-off-by: NLennart Poettering <mzxreary@0pointer.de>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

dmi_scan.c is arch-independent and is used by i386, x86_64, and ia64.
Currently all three arches compile it from arch/i386, which means that ia64
and x86_64 depend on things in arch/i386 that they wouldn't otherwise care
about.

This is simply "mv arch/i386/kernel/dmi_scan.c drivers/firmware/" (removing
trailing whitespace) and the associated Makefile changes.  All three
architectures already set CONFIG_DMI in their top-level Kconfig files.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Andrey Panin <pazke@orbita1.ru>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds the Dell Systems Management Base Driver with sysfs support.

This driver has been tested with Dell OpenManage.
Signed-off-by: NDoug Warzecha <Douglas_Warzecha@dell.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Remote BIOS Update driver for updating BIOS images on Dell servers and
desktops.  See dell_rbu.txt for details.
Signed-off-by: NAbhay Salunke <Abhay_Salunke@dell.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NJens Axboe <axboe@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!