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" 212 depends on X86 || EFI 213 select SYSFB 214 help 215 Firmwares often provide initial graphics framebuffers so the BIOS, 216 bootloader or kernel can show basic video-output during boot for 217 user-guidance and debugging. Historically, x86 used the VESA BIOS 218 Extensions and EFI-framebuffers for this, which are mostly limited 219 to x86 BIOS or EFI systems. 220 This option, if enabled, marks VGA/VBE/EFI framebuffers as generic 221 framebuffers so the new generic system-framebuffer drivers can be 222 used instead. If the framebuffer is not compatible with the generic 223 modes, it is advertised as fallback platform framebuffer so legacy 224 drivers like efifb, vesafb and uvesafb can pick it up. 225 If this option is not selected, all system framebuffers are always 226 marked as fallback platform framebuffers as usual. 227 228 Note: Legacy fbdev drivers, including vesafb, efifb, uvesafb, will 229 not be able to pick up generic system framebuffers if this option 230 is selected. You are highly encouraged to enable simplefb as 231 replacement if you select this option. simplefb can correctly deal 232 with generic system framebuffers. But you should still keep vesafb 233 and others enabled as fallback if a system framebuffer is 234 incompatible with simplefb. 235 236 If unsure, say Y. 237 238config TH1520_AON_PROTOCOL 239 tristate "Always-On firmware protocol" 240 depends on ARCH_THEAD || COMPILE_TEST 241 depends on MAILBOX 242 help 243 Power, clock, and resource management capabilities on the TH1520 SoC are 244 managed by the E902 core. Firmware running on this core communicates with 245 the kernel through the Always-On protocol, using hardware mailbox as a medium. 246 Say yes if you need such capabilities. 247 248config TI_SCI_PROTOCOL 249 tristate "TI System Control Interface (TISCI) Message Protocol" 250 depends on TI_MESSAGE_MANAGER 251 default ARCH_K3 252 help 253 TI System Control Interface (TISCI) Message Protocol is used to manage 254 compute systems such as ARM, DSP etc with the system controller in 255 complex System on Chip(SoC) such as those found on certain keystone 256 generation SoC from TI. 257 258 System controller provides various facilities including power 259 management function support. 260 261 This protocol library is used by client drivers to use the features 262 provided by the system controller. 263 264config TRUSTED_FOUNDATIONS 265 bool "Trusted Foundations secure monitor support" 266 depends on ARM && CPU_V7 267 help 268 Some devices (including most early Tegra-based consumer devices on 269 the market) are booted with the Trusted Foundations secure monitor 270 active, requiring some core operations to be performed by the secure 271 monitor instead of the kernel. 272 273 This option allows the kernel to invoke the secure monitor whenever 274 required on devices using Trusted Foundations. See the functions and 275 comments in linux/firmware/trusted_foundations.h or the device tree 276 bindings for "tlm,trusted-foundations" for details on how to use it. 277 278 Choose N if you don't know what this is about. 279 280config TURRIS_MOX_RWTM 281 tristate "Turris Mox rWTM secure firmware driver" 282 depends on ARCH_MVEBU || COMPILE_TEST 283 depends on HAS_DMA && OF 284 depends on MAILBOX 285 select HW_RANDOM 286 select ARMADA_37XX_RWTM_MBOX 287 help 288 This driver communicates with the firmware on the Cortex-M3 secure 289 processor of the Turris Mox router. Enable if you are building for 290 Turris Mox, and you will be able to read the device serial number and 291 other manufacturing data and also utilize the Entropy Bit Generator 292 for hardware random number generation. 293 294if TURRIS_MOX_RWTM 295 296config TURRIS_MOX_RWTM_KEYCTL 297 bool "Turris Mox rWTM ECDSA message signing" 298 default y 299 depends on KEYS 300 depends on ASYMMETRIC_KEY_TYPE 301 select CZNIC_PLATFORMS 302 select TURRIS_SIGNING_KEY 303 help 304 Say Y here to add support for ECDSA message signing with board private 305 key (each Turris Mox has an ECDSA private key generated in the secure 306 coprocessor when manufactured). This functionality is exposed via the 307 keyctl() syscall. 308 309endif # TURRIS_MOX_RWTM 310 311source "drivers/firmware/arm_ffa/Kconfig" 312source "drivers/firmware/broadcom/Kconfig" 313source "drivers/firmware/cirrus/Kconfig" 314source "drivers/firmware/google/Kconfig" 315source "drivers/firmware/efi/Kconfig" 316source "drivers/firmware/imx/Kconfig" 317source "drivers/firmware/meson/Kconfig" 318source "drivers/firmware/microchip/Kconfig" 319source "drivers/firmware/psci/Kconfig" 320source "drivers/firmware/qcom/Kconfig" 321source "drivers/firmware/samsung/Kconfig" 322source "drivers/firmware/smccc/Kconfig" 323source "drivers/firmware/tegra/Kconfig" 324source "drivers/firmware/xilinx/Kconfig" 325 326endmenu 327