1# SPDX-License-Identifier: GPL-2.0-only 2# 3# For a description of the syntax of this configuration file, 4# see Documentation/kbuild/kconfig-language.rst. 5# 6 7menu "Firmware Drivers" 8 9source "drivers/firmware/arm_scmi/Kconfig" 10 11config ARM_SCPI_PROTOCOL 12 tristate "ARM System Control and Power Interface (SCPI) Message Protocol" 13 depends on ARM || ARM64 || COMPILE_TEST 14 depends on MAILBOX 15 help 16 System Control and Power Interface (SCPI) Message Protocol is 17 defined for the purpose of communication between the Application 18 Cores(AP) and the System Control Processor(SCP). The MHU peripheral 19 provides a mechanism for inter-processor communication between SCP 20 and AP. 21 22 SCP controls most of the power management on the Application 23 Processors. It offers control and management of: the core/cluster 24 power states, various power domain DVFS including the core/cluster, 25 certain system clocks configuration, thermal sensors and many 26 others. 27 28 This protocol library provides interface for all the client drivers 29 making use of the features offered by the SCP. 30 31config ARM_SDE_INTERFACE 32 bool "ARM Software Delegated Exception Interface (SDEI)" 33 depends on ARM64 34 help 35 The Software Delegated Exception Interface (SDEI) is an ARM 36 standard for registering callbacks from the platform firmware 37 into the OS. This is typically used to implement RAS notifications. 38 39config ARM_SDEI_NMI 40 bool "SDEI-based cross-CPU NMI service (arm64)" 41 depends on ARM_SDE_INTERFACE 42 help 43 Provides SDEI-based cross-CPU NMI delivery for hooks that need 44 to reach interrupt-masked CPUs on silicon that lacks FEAT_NMI: 45 46 - arch_trigger_cpumask_backtrace() (sysrq-l, RCU stalls, 47 hardlockup_all_cpu_backtrace, soft-lockup secondary dumps, 48 hung-task auxiliary dumps) 49 - smp_send_stop() escalation (reboot/halt and the 50 panic / kdump crash stop) 51 52 The driver registers a handler for the SDEI software-signalled 53 event (event 0) and reaches a target CPU by signalling it with 54 SDEI_EVENT_SIGNAL. Firmware delivers the event out of EL3 55 regardless of the target's PSTATE.DAIF -- forced delivery into a 56 CPU wedged with interrupts locally masked. 57 58 If unsure, say N. 59 60config EDD 61 tristate "BIOS Enhanced Disk Drive calls determine boot disk" 62 depends on X86 63 help 64 Say Y or M here if you want to enable BIOS Enhanced Disk Drive 65 Services real mode BIOS calls to determine which disk 66 BIOS tries boot from. This information is then exported via sysfs. 67 68 This option is experimental and is known to fail to boot on some 69 obscure configurations. Most disk controller BIOS vendors do 70 not yet implement this feature. 71 72config EDD_OFF 73 bool "Sets default behavior for EDD detection to off" 74 depends on EDD 75 default n 76 help 77 Say Y if you want EDD disabled by default, even though it is compiled into the 78 kernel. Say N if you want EDD enabled by default. EDD can be dynamically set 79 using the kernel parameter 'edd={on|skipmbr|off}'. 80 81config FIRMWARE_MEMMAP 82 bool "Add firmware-provided memory map to sysfs" if EXPERT 83 default X86 84 help 85 Add the firmware-provided (unmodified) memory map to /sys/firmware/memmap. 86 That memory map is used for example by kexec to set up parameter area 87 for the next kernel, but can also be used for debugging purposes. 88 89 See also Documentation/ABI/testing/sysfs-firmware-memmap. 90 91config DMIID 92 bool "Export DMI identification via sysfs to userspace" 93 depends on DMI 94 default y 95 help 96 Say Y here if you want to query SMBIOS/DMI system identification 97 information from userspace through /sys/class/dmi/id/ or if you want 98 DMI-based module auto-loading. 99 100config DMI_SYSFS 101 tristate "DMI table support in sysfs" 102 depends on SYSFS && DMI 103 default n 104 help 105 Say Y or M here to enable the exporting of the raw DMI table 106 data via sysfs. This is useful for consuming the data without 107 requiring any access to /dev/mem at all. Tables are found 108 under /sys/firmware/dmi when this option is enabled and 109 loaded. 110 111config DMI_SCAN_MACHINE_NON_EFI_FALLBACK 112 bool 113 114config ISCSI_IBFT_FIND 115 bool "iSCSI Boot Firmware Table Attributes" 116 depends on X86 && ISCSI_IBFT 117 default n 118 help 119 This option enables the kernel to find the region of memory 120 in which the ISCSI Boot Firmware Table (iBFT) resides. This 121 is necessary for iSCSI Boot Firmware Table Attributes module to work 122 properly. 123 124config ISCSI_IBFT 125 tristate "iSCSI Boot Firmware Table Attributes module" 126 select ISCSI_BOOT_SYSFS 127 select ISCSI_IBFT_FIND if X86 128 depends on ACPI && SCSI && SCSI_LOWLEVEL 129 default n 130 help 131 This option enables support for detection and exposing of iSCSI 132 Boot Firmware Table (iBFT) via sysfs to userspace. If you wish to 133 detect iSCSI boot parameters dynamically during system boot, say Y. 134 Otherwise, say N. 135 136config RASPBERRYPI_FIRMWARE 137 tristate "Raspberry Pi Firmware Driver" 138 depends on ARCH_BCM2835 || COMPILE_TEST 139 depends on ARM || ARM64 140 depends on MAILBOX 141 default ARCH_BCM2835 142 help 143 This option enables support for communicating with the firmware on the 144 Raspberry Pi. 145 146config FW_CFG_SYSFS 147 tristate "QEMU fw_cfg device support in sysfs" 148 depends on SYSFS && (ARM || ARM64 || LOONGARCH || PARISC || PPC_PMAC || RISCV || SPARC || X86) 149 depends on HAS_IOPORT_MAP 150 default n 151 help 152 Say Y or M here to enable the exporting of the QEMU firmware 153 configuration (fw_cfg) file entries via sysfs. Entries are 154 found under /sys/firmware/fw_cfg when this option is enabled 155 and loaded. 156 157config FW_CFG_SYSFS_CMDLINE 158 bool "QEMU fw_cfg device parameter parsing" 159 depends on FW_CFG_SYSFS 160 help 161 Allow the qemu_fw_cfg device to be initialized via the kernel 162 command line or using a module parameter. 163 WARNING: Using incorrect parameters (base address in particular) 164 may crash your system. 165 166config INTEL_STRATIX10_SERVICE 167 tristate "Intel Stratix10 Service Layer" 168 depends on ARCH_INTEL_SOCFPGA && ARM64 && HAVE_ARM_SMCCC 169 default n 170 help 171 Intel Stratix10 service layer runs at privileged exception level, 172 interfaces with the service providers (FPGA manager is one of them) 173 and manages secure monitor call to communicate with secure monitor 174 software at secure monitor exception level. 175 176 Say Y here if you want Stratix10 service layer support. 177 178config INTEL_STRATIX10_RSU 179 tristate "Intel Stratix10 Remote System Update" 180 depends on INTEL_STRATIX10_SERVICE 181 help 182 The Intel Remote System Update (RSU) driver exposes interfaces 183 access through the Intel Service Layer to user space via sysfs 184 device attribute nodes. The RSU interfaces report/control some of 185 the optional RSU features of the Stratix 10 SoC FPGA. 186 187 The RSU provides a way for customers to update the boot 188 configuration of a Stratix 10 SoC device with significantly reduced 189 risk of corrupting the bitstream storage and bricking the system. 190 191 Enable RSU support if you are using an Intel SoC FPGA with the RSU 192 feature enabled and you want Linux user space control. 193 194 Say Y here if you want Intel RSU support. 195 196config MTK_ADSP_IPC 197 tristate "MTK ADSP IPC Protocol driver" 198 depends on MTK_ADSP_MBOX 199 help 200 Say yes here to add support for the MediaTek ADSP IPC 201 between host AP (Linux) and the firmware running on ADSP. 202 ADSP exists on some mtk processors. 203 Client might use shared memory to exchange information with ADSP. 204 205config SYSFB 206 bool 207 select BOOT_VESA_SUPPORT 208 select SCREEN_INFO 209 210config SYSFB_SIMPLEFB 211 bool "Mark VGA/VBE/EFI FB as generic system framebuffer (deprecated)" 212 depends on X86 || EFI 213 select SYSFB 214 help 215 Firmware often provides initial graphics framebuffers so the BIOS, 216 bootloader or kernel can show basic video-output during boot for 217 user-guidance and debugging. 218 219 This option, if enabled, marks VBE/EFI framebuffers as system 220 framebuffers so the generic simpledrm driver can be used. 221 222 This option is deprecated and will be removed in the near future. If 223 unsure, say N and select efidrm, vesadrm instead. The dedicated DRM 224 drivers provide the same functionality plus additional features. 225 226config TH1520_AON_PROTOCOL 227 tristate "Always-On firmware protocol" 228 depends on ARCH_THEAD || COMPILE_TEST 229 depends on MAILBOX 230 help 231 Power, clock, and resource management capabilities on the TH1520 SoC are 232 managed by the E902 core. Firmware running on this core communicates with 233 the kernel through the Always-On protocol, using hardware mailbox as a medium. 234 Say yes if you need such capabilities. 235 236config TI_SCI_PROTOCOL 237 tristate "TI System Control Interface (TISCI) Message Protocol" 238 depends on TI_MESSAGE_MANAGER 239 default ARCH_K3 240 help 241 TI System Control Interface (TISCI) Message Protocol is used to manage 242 compute systems such as ARM, DSP etc with the system controller in 243 complex System on Chip(SoC) such as those found on certain keystone 244 generation SoC from TI. 245 246 System controller provides various facilities including power 247 management function support. 248 249 This protocol library is used by client drivers to use the features 250 provided by the system controller. 251 252config TRUSTED_FOUNDATIONS 253 bool "Trusted Foundations secure monitor support" 254 depends on ARM && CPU_V7 255 help 256 Some devices (including most early Tegra-based consumer devices on 257 the market) are booted with the Trusted Foundations secure monitor 258 active, requiring some core operations to be performed by the secure 259 monitor instead of the kernel. 260 261 This option allows the kernel to invoke the secure monitor whenever 262 required on devices using Trusted Foundations. See the functions and 263 comments in linux/firmware/trusted_foundations.h or the device tree 264 bindings for "tlm,trusted-foundations" for details on how to use it. 265 266 Choose N if you don't know what this is about. 267 268config TURRIS_MOX_RWTM 269 tristate "Turris Mox rWTM secure firmware driver" 270 depends on ARCH_MVEBU || COMPILE_TEST 271 depends on HAS_DMA && OF 272 depends on MAILBOX 273 select HW_RANDOM 274 select ARMADA_37XX_RWTM_MBOX 275 help 276 This driver communicates with the firmware on the Cortex-M3 secure 277 processor of the Turris Mox router. Enable if you are building for 278 Turris Mox, and you will be able to read the device serial number and 279 other manufacturing data and also utilize the Entropy Bit Generator 280 for hardware random number generation. 281 282if TURRIS_MOX_RWTM 283 284config TURRIS_MOX_RWTM_KEYCTL 285 bool "Turris Mox rWTM ECDSA message signing" 286 default y 287 depends on KEYS 288 depends on ASYMMETRIC_KEY_TYPE 289 select CZNIC_PLATFORMS 290 select TURRIS_SIGNING_KEY 291 help 292 Say Y here to add support for ECDSA message signing with board private 293 key (each Turris Mox has an ECDSA private key generated in the secure 294 coprocessor when manufactured). This functionality is exposed via the 295 keyctl() syscall. 296 297endif # TURRIS_MOX_RWTM 298 299source "drivers/firmware/arm_ffa/Kconfig" 300source "drivers/firmware/broadcom/Kconfig" 301source "drivers/firmware/cirrus/Kconfig" 302source "drivers/firmware/google/Kconfig" 303source "drivers/firmware/efi/Kconfig" 304source "drivers/firmware/imx/Kconfig" 305source "drivers/firmware/meson/Kconfig" 306source "drivers/firmware/microchip/Kconfig" 307source "drivers/firmware/psci/Kconfig" 308source "drivers/firmware/qcom/Kconfig" 309source "drivers/firmware/samsung/Kconfig" 310source "drivers/firmware/smccc/Kconfig" 311source "drivers/firmware/tegra/Kconfig" 312source "drivers/firmware/xilinx/Kconfig" 313 314endmenu 315