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