123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339 |
- # SPDX-License-Identifier: GPL-2.0-only
- #
- # For a description of the syntax of this configuration file,
- # see Documentation/kbuild/kconfig-language.rst.
- #
- menu "Firmware Drivers"
- source "drivers/firmware/arm_scmi/Kconfig"
- config ARM_SCPI_PROTOCOL
- tristate "ARM System Control and Power Interface (SCPI) Message Protocol"
- depends on ARM || ARM64 || COMPILE_TEST
- depends on MAILBOX
- help
- System Control and Power Interface (SCPI) Message Protocol is
- defined for the purpose of communication between the Application
- Cores(AP) and the System Control Processor(SCP). The MHU peripheral
- provides a mechanism for inter-processor communication between SCP
- and AP.
- SCP controls most of the power management on the Application
- Processors. It 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 library provides interface for all the client drivers
- making use of the features offered by the SCP.
- config ARM_SCPI_POWER_DOMAIN
- tristate "SCPI power domain driver"
- depends on ARM_SCPI_PROTOCOL || (COMPILE_TEST && OF)
- default y
- select PM_GENERIC_DOMAINS if PM
- help
- This enables support for the SCPI power domains which can be
- enabled or disabled via the SCP firmware
- config ARM_SDE_INTERFACE
- bool "ARM Software Delegated Exception Interface (SDEI)"
- depends on ARM64
- depends on ACPI_APEI_GHES
- help
- The Software Delegated Exception Interface (SDEI) is an ARM
- standard for registering callbacks from the platform firmware
- into the OS. This is typically used to implement RAS notifications.
- config EDD
- tristate "BIOS Enhanced Disk Drive calls determine boot disk"
- depends on X86
- help
- Say Y or M here if you want to enable BIOS Enhanced Disk Drive
- Services real mode BIOS calls to determine which disk
- BIOS tries boot from. This information is then exported via sysfs.
- This option is experimental and is known to fail to boot on some
- obscure configurations. Most disk controller BIOS vendors do
- not yet implement this feature.
- config EDD_OFF
- bool "Sets default behavior for EDD detection to off"
- depends on EDD
- default n
- help
- Say Y if you want EDD disabled by default, even though it is compiled into the
- kernel. Say N if you want EDD enabled by default. EDD can be dynamically set
- using the kernel parameter 'edd={on|skipmbr|off}'.
- config FIRMWARE_MEMMAP
- bool "Add firmware-provided memory map to sysfs" if EXPERT
- default X86
- help
- Add the firmware-provided (unmodified) memory map to /sys/firmware/memmap.
- That memory map is used for example by kexec to set up parameter area
- for the next kernel, but can also be used for debugging purposes.
- See also Documentation/ABI/testing/sysfs-firmware-memmap.
- config EFI_PCDP
- bool "Console device selection via EFI PCDP or HCDP table"
- depends on ACPI && EFI && IA64
- default y if IA64
- help
- If your firmware supplies the PCDP table, and you want to
- automatically use the primary console device it describes
- as the Linux console, say Y here.
- If your firmware supplies the HCDP table, and you want to
- use the first serial port it describes as the Linux console,
- say Y here. If your EFI ConOut path contains only a UART
- device, it will become the console automatically. Otherwise,
- you must specify the "console=hcdp" kernel boot argument.
- Neither the PCDP nor the HCDP affects naming of serial devices,
- so a serial console may be /dev/ttyS0, /dev/ttyS1, etc, depending
- on how the driver discovers devices.
- You must also enable the appropriate drivers (serial, VGA, etc.)
- See DIG64_HCDPv20_042804.pdf available from
- <http://www.dig64.org/specifications/>
- config DMIID
- bool "Export DMI identification via sysfs to userspace"
- depends on DMI
- default y
- help
- Say Y here if you want to query SMBIOS/DMI system identification
- information from userspace through /sys/class/dmi/id/ or if you want
- DMI-based module auto-loading.
- config DMI_SYSFS
- tristate "DMI table support in sysfs"
- depends on SYSFS && DMI
- default n
- help
- Say Y or M here to enable the exporting of the raw DMI table
- data via sysfs. This is useful for consuming the data without
- requiring any access to /dev/mem at all. Tables are found
- under /sys/firmware/dmi when this option is enabled and
- loaded.
- config DMI_SCAN_MACHINE_NON_EFI_FALLBACK
- bool
- config ISCSI_IBFT_FIND
- bool "iSCSI Boot Firmware Table Attributes"
- depends on X86 && ISCSI_IBFT
- default n
- help
- This option enables the kernel to find the region of memory
- in which the ISCSI Boot Firmware Table (iBFT) resides. This
- is necessary for iSCSI Boot Firmware Table Attributes module to work
- properly.
- config ISCSI_IBFT
- tristate "iSCSI Boot Firmware Table Attributes module"
- select ISCSI_BOOT_SYSFS
- select ISCSI_IBFT_FIND if X86
- depends on ACPI && SCSI && SCSI_LOWLEVEL
- default n
- help
- This option enables support for detection and exposing of iSCSI
- Boot Firmware Table (iBFT) via sysfs to userspace. If you wish to
- detect iSCSI boot parameters dynamically during system boot, say Y.
- Otherwise, say N.
- config RASPBERRYPI_FIRMWARE
- tristate "Raspberry Pi Firmware Driver"
- depends on BCM2835_MBOX
- help
- This option enables support for communicating with the firmware on the
- Raspberry Pi.
- config FW_CFG_SYSFS
- tristate "QEMU fw_cfg device support in sysfs"
- depends on SYSFS && (ARM || ARM64 || PARISC || PPC_PMAC || SPARC || X86)
- depends on HAS_IOPORT_MAP
- default n
- help
- Say Y or M here to enable the exporting of the QEMU firmware
- configuration (fw_cfg) file entries via sysfs. Entries are
- found under /sys/firmware/fw_cfg when this option is enabled
- and loaded.
- config FW_CFG_SYSFS_CMDLINE
- bool "QEMU fw_cfg device parameter parsing"
- depends on FW_CFG_SYSFS
- help
- Allow the qemu_fw_cfg device to be initialized via the kernel
- command line or using a module parameter.
- WARNING: Using incorrect parameters (base address in particular)
- may crash your system.
- config INTEL_STRATIX10_SERVICE
- tristate "Intel Stratix10 Service Layer"
- depends on ARCH_INTEL_SOCFPGA && ARM64 && HAVE_ARM_SMCCC
- default n
- help
- Intel Stratix10 service layer runs at privileged exception level,
- interfaces with the service providers (FPGA manager is one of them)
- and manages secure monitor call to communicate with secure monitor
- software at secure monitor exception level.
- Say Y here if you want Stratix10 service layer support.
- config INTEL_STRATIX10_RSU
- tristate "Intel Stratix10 Remote System Update"
- depends on INTEL_STRATIX10_SERVICE
- help
- The Intel Remote System Update (RSU) driver exposes interfaces
- access through the Intel Service Layer to user space via sysfs
- device attribute nodes. The RSU interfaces report/control some of
- the optional RSU features of the Stratix 10 SoC FPGA.
- The RSU provides a way for customers to update the boot
- configuration of a Stratix 10 SoC device with significantly reduced
- risk of corrupting the bitstream storage and bricking the system.
- Enable RSU support if you are using an Intel SoC FPGA with the RSU
- feature enabled and you want Linux user space control.
- Say Y here if you want Intel RSU support.
- config MTK_ADSP_IPC
- tristate "MTK ADSP IPC Protocol driver"
- depends on MTK_ADSP_MBOX
- help
- Say yes here to add support for the MediaTek ADSP IPC
- between host AP (Linux) and the firmware running on ADSP.
- ADSP exists on some mtk processors.
- Client might use shared memory to exchange information with ADSP.
- config QCOM_SCM
- tristate
- config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
- bool "Qualcomm download mode enabled by default"
- depends on QCOM_SCM
- help
- A device with "download mode" enabled will upon an unexpected
- warm-restart enter a special debug mode that allows the user to
- "download" memory content over USB for offline postmortem analysis.
- The feature can be enabled/disabled on the kernel command line.
- Say Y here to enable "download mode" by default.
- config QCOM_SCM_HAB
- tristate "To enable QCOM SCM HAB for QCPE-TZ virtualization"
- depends on QCOM_SCM && MSM_HAB
- help
- QCOM SCM HAB serves the scm with HAB channel with Secure Channel
- Mananger(SCM) support for SoC in virtualized Linux,
- where SCM backend is QCPE (QCOM Protected environment). The SCM
- channel will use QCOM HAB interface for front-end to back-end
- communication.
- config QTEE_SHM_BRIDGE
- bool "QTI TEE shared memory bridge"
- depends on QCOM_SCM
- default y if QCOM_SCM
- help
- QTEE shared memory bridge driver provides kernel APIs to share
- memory between trustzone & other VMs through shared memory bridge.
- It allows kernel clients to create bridge, delete bridge, and do
- memory sub-allocation and free from the default kernel bridge
- created by bridge driver.
- config SYSFB
- bool
- select BOOT_VESA_SUPPORT
- config SYSFB_SIMPLEFB
- bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
- depends on X86 || EFI
- select SYSFB
- help
- Firmwares often provide initial graphics framebuffers so the BIOS,
- bootloader or kernel can show basic video-output during boot for
- user-guidance and debugging. Historically, x86 used the VESA BIOS
- Extensions and EFI-framebuffers for this, which are mostly limited
- to x86 BIOS or EFI systems.
- This option, if enabled, marks VGA/VBE/EFI framebuffers as generic
- framebuffers so the new generic system-framebuffer drivers can be
- used instead. If the framebuffer is not compatible with the generic
- modes, it is advertised as fallback platform framebuffer so legacy
- drivers like efifb, vesafb and uvesafb can pick it up.
- If this option is not selected, all system framebuffers are always
- marked as fallback platform framebuffers as usual.
- Note: Legacy fbdev drivers, including vesafb, efifb, uvesafb, will
- not be able to pick up generic system framebuffers if this option
- is selected. You are highly encouraged to enable simplefb as
- replacement if you select this option. simplefb can correctly deal
- with generic system framebuffers. But you should still keep vesafb
- and others enabled as fallback if a system framebuffer is
- incompatible with simplefb.
- If unsure, say Y.
- config TI_SCI_PROTOCOL
- tristate "TI System Control Interface (TISCI) Message Protocol"
- depends on TI_MESSAGE_MANAGER
- help
- TI System Control Interface (TISCI) Message Protocol is used to manage
- compute systems such as ARM, DSP etc with the system controller in
- complex System on Chip(SoC) such as those found on certain keystone
- generation SoC from TI.
- System controller provides various facilities including power
- management function support.
- This protocol library is used by client drivers to use the features
- provided by the system controller.
- config TRUSTED_FOUNDATIONS
- bool "Trusted Foundations secure monitor support"
- depends on ARM && CPU_V7
- help
- Some devices (including most early Tegra-based consumer devices on
- the market) are booted with the Trusted Foundations secure monitor
- active, requiring some core operations to be performed by the secure
- monitor instead of the kernel.
- This option allows the kernel to invoke the secure monitor whenever
- required on devices using Trusted Foundations. See the functions and
- comments in linux/firmware/trusted_foundations.h or the device tree
- bindings for "tlm,trusted-foundations" for details on how to use it.
- Choose N if you don't know what this is about.
- config TURRIS_MOX_RWTM
- tristate "Turris Mox rWTM secure firmware driver"
- depends on ARCH_MVEBU || COMPILE_TEST
- depends on HAS_DMA && OF
- depends on MAILBOX
- select HW_RANDOM
- select ARMADA_37XX_RWTM_MBOX
- help
- This driver communicates with the firmware on the Cortex-M3 secure
- processor of the Turris Mox router. Enable if you are building for
- Turris Mox, and you will be able to read the device serial number and
- other manufacturing data and also utilize the Entropy Bit Generator
- for hardware random number generation.
- source "drivers/firmware/arm_ffa/Kconfig"
- source "drivers/firmware/broadcom/Kconfig"
- source "drivers/firmware/cirrus/Kconfig"
- source "drivers/firmware/google/Kconfig"
- source "drivers/firmware/efi/Kconfig"
- source "drivers/firmware/imx/Kconfig"
- source "drivers/firmware/meson/Kconfig"
- source "drivers/firmware/psci/Kconfig"
- source "drivers/firmware/smccc/Kconfig"
- source "drivers/firmware/tegra/Kconfig"
- source "drivers/firmware/xilinx/Kconfig"
- endmenu
|