Searched +full:system +full:- +full:firmware (Results 1 – 25 of 316) sorted by relevance
12345678910>>...13
| /Documentation/driver-api/nvdimm/ |
| D | firmware-activate.rst | 1 .. SPDX-License-Identifier: GPL-2.0 4 NVDIMM Runtime Firmware Activation 7 Some persistent memory devices run a firmware locally on the device / 9 and health monitoring. The process of updating that firmware typically 10 involves a reboot because it has implications for in-flight memory 13 DSM specification [1], has added support for activating firmware at 17 to advertise and control their local runtime firmware activation 20 The libnvdimm bus object, ndbusX, implements an ndbusX/firmware/activate 21 attribute that shows the state of the firmware activation as one of 'idle', 24 - idle: [all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-firmware-opal-powercap | 1 What: /sys/firmware/opal/powercap 3 Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org> 7 power-cappable component. 9 What: /sys/firmware/opal/powercap/system-powercap 10 /sys/firmware/opal/powercap/system-powercap/powercap-min 11 /sys/firmware/opal/powercap/system-powercap/powercap-max 12 /sys/firmware/opal/powercap/system-powercap/powercap-current 14 Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org> 15 Description: System powercap directory and attributes applicable for 21 - powercap-min : This file provides the minimum [all …]
|
| D | sysfs-firmware-gsmi | 1 What: /sys/firmware/gsmi 5 Some servers used internally at Google have firmware 9 historical reasons this different entry-point has been 13 these firmware callbacks. Currently, this functionality 14 is limited to handling the system event log and getting 15 access to EFI-style variables stored in nvram. 19 /sys/firmware/gsmi/vars: 22 underlying implementation as /sys/firmware/efi/vars. 23 See `Documentation/ABI/*/sysfs-firmware-efi-vars` 27 /sys/firmware/gsmi/append_to_eventlog - write-only: [all …]
|
| D | sysfs-firmware-efi | 1 What: /sys/firmware/efi/fw_vendor 4 Description: It shows the physical address of firmware vendor field in the 5 EFI system table. 8 What: /sys/firmware/efi/runtime 12 the EFI system table. 15 What: /sys/firmware/efi/config_table 19 system table. 22 What: /sys/firmware/efi/systab 24 Contact: linux-efi@vger.kernel.org 26 Tables found via the EFI System Table. The order in [all …]
|
| D | sysfs-firmware-dmi-entries | 1 What: /sys/firmware/dmi/entries/ 5 Many machines' firmware (x86 and arm64) export DMI / 6 SMBIOS tables to the operating system. Getting at this 17 length of the entry, as well as a firmware-provided 24 system unless they know for certain what their firmware 29 assigned by the operating system an 'instance', which is 34 entries "T-0" through "T-(N-1)": 38 /sys/firmware/dmi/entries/17-0 39 /sys/firmware/dmi/entries/17-1 40 /sys/firmware/dmi/entries/17-2 [all …]
|
| D | sysfs-firmware-efi-esrt | 1 What: /sys/firmware/efi/esrt/ 4 Description: Provides userland access to read the EFI System Resource Table 5 (ESRT), a catalog of firmware for which can be updated with 8 Users: fwupdate - https://github.com/rhinstaller/fwupdate 10 What: /sys/firmware/efi/esrt/fw_resource_count 15 What: /sys/firmware/efi/esrt/fw_resource_count_max 20 really only useful to the system firmware itself. 22 What: /sys/firmware/efi/esrt/fw_resource_version 25 Description: The version of the ESRT structure provided by the firmware. 27 What: /sys/firmware/efi/esrt/entries/entry<N>/ [all …]
|
| D | sysfs-firmware-sgi_uv | 1 What: /sys/firmware/sgi_uv/ 5 The /sys/firmware/sgi_uv directory contains information 8 Under that directory are a number of read-only attributes:: 18 is used to select arch-dependent addresses and features. 32 of the operating system. Each partition will have a unique 36 A partitioned UV system can have one or more coherence 41 This value can be used to identify the UV system version:: 50 The /sys/firmware/sgi_uv directory also contains two directories:: 57 unique ordinal value (ex. /sys/firmware/sgi_uv/hubs/hub_5) 59 Each hub object directory contains a number of read-only attributes:: [all …]
|
| D | sysfs-firmware-ofw | 1 What: /sys/firmware/devicetree/* 9 It is possible for multiple device-tree directories to exist. 11 have no attachment to the system tree and will appear in a 12 different subdirectory under /sys/firmware/devicetree. 14 Userspace must not use the /sys/firmware/devicetree/base 15 path directly, but instead should follow /proc/device-tree 19 The /proc/device-tree symlink replaces the devicetree /proc 23 The contents of /sys/firmware/devicetree/ is a 30 What: /sys/firmware/fdt 42 /sys/firmware/device-tree is deliberate: FDT is also used [all …]
|
| D | sysfs-devices-platform-stratix10-rsu | 1 Intel Stratix10 Remote System Update (RSU) device attributes 3 What: /sys/devices/platform/stratix10-rsu.0/current_image 10 What: /sys/devices/platform/stratix10-rsu.0/fail_image 17 What: /sys/devices/platform/stratix10-rsu.0/state 22 (RO) the state of RSU system. 30 firmware through the RSU notify command before 42 What: /sys/devices/platform/stratix10-rsu.0/version 47 (RO) the version number of RSU firmware. 19.3 or late 48 version includes information about the firmware which 63 What: /sys/devices/platform/stratix10-rsu.0/error_location [all …]
|
| /Documentation/arch/arm/keystone/ |
| D | knav-qmss.rst | 9 The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of 10 the main hardware sub system which forms the backbone of the Keystone 11 multi-core Navigator. QMSS consist of queue managers, packed-data structure 15 management of the packet queues. Packets are queued/de-queued by writing or 29 Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 31 Accumulator QMSS queues using PDSP firmware 33 The QMSS PDSP firmware support accumulator channel that can monitor a single 37 1 or 32 queues per channel. More description on the firmware is available in 40 git://git.ti.com/keystone-rtos/qmss-lld.git 42 k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator [all …]
|
| /Documentation/ABI/stable/ |
| D | sysfs-driver-firmware-zynqmp | 1 What: /sys/devices/platform/firmware\:zynqmp-firmware/ggs* 9 by system to pass information between masters. 11 The register is reset during system or power-on 17 # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 18 # echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 22 # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 23 # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 27 What: /sys/devices/platform/firmware\:zynqmp-firmware/pggs* 35 can be used by system to pass information between 38 This register is only reset by the power-on reset [all …]
|
| /Documentation/arch/arm64/ |
| D | cpu-hotplug.rst | 1 .. SPDX-License-Identifier: GPL-2.0 9 CPUs online/offline using PSCI. This document is about ACPI firmware allowing 10 CPUs that were not available during boot to be added to the system later. 15 CPU Hotplug on physical systems - CPUs not present at boot 16 ---------------------------------------------------------- 20 in one of the sockets can be replaced while the system is running. 24 In the arm64 world CPUs are not a single device but a slice of the system. 26 while the system is running, and ACPI is not able to sufficiently describe 31 not discoverable, and must be described by firmware. 34 boot to discover the system wide supported features. ACPI's MADT GICC [all …]
|
| /Documentation/driver-api/media/drivers/ |
| D | ipu6.rst | 1 .. SPDX-License-Identifier: GPL-2.0 14 Meteor Lake. IPU6 consists of two major systems: Input System (ISYS) and 15 Processing System (PSYS). IPU6 are visible on the PCI bus as a single device, it 26 The IPU6 is connecting to the system fabric with Buttress which is enabling host 27 driver to control the IPU6, it also allows IPU6 access the system memory to 30 Buttress mainly manages several system functionalities: power management, 31 interrupt handling, firmware authentication and global timer sync. 34 ------------------------ 51 --------- 60 Security and firmware authentication [all …]
|
| /Documentation/devicetree/bindings/remoteproc/ |
| D | ti,omap-remoteproc.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Suman Anna <s-anna@ti.com> 13 The OMAP family of SoCs usually have one or more slave processor sub-systems 14 that are used to offload some of the processor-intensive tasks, or to manage 15 other hardware accelerators, for achieving various system level goals. 17 The processor cores in the sub-system are usually behind an IOMMU, and may 18 contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2 [all …]
|
| /Documentation/networking/device_drivers/atm/ |
| D | fore200e.rst | 1 .. SPDX-License-Identifier: GPL-2.0 4 FORE Systems PCA-200E/SBA-200E ATM NIC driver 7 This driver adds support for the FORE Systems 200E-series ATM adapters 8 to the Linux operating system. It is based on the earlier PCA-200E driver 11 The driver simultaneously supports PCA-200E and SBA-200E adapters on 22 Firmware Copyright Notice 23 ------------------------- 29 Firmware Updates 30 ---------------- 32 The FORE Systems 200E-series driver is shipped with firmware data being [all …]
|
| /Documentation/arch/powerpc/ |
| D | firmware-assisted-dump.rst | 2 Firmware-Assisted Dump 7 The goal of firmware-assisted dump is to enable the dump of 8 a crashed system, and to do so from a fully-reset system, and 9 to minimize the total elapsed time until the system is back 12 - Firmware-Assisted Dump (FADump) infrastructure is intended to replace 14 - Fadump uses the same firmware interfaces and memory reservation model 16 - Unlike phyp dump, FADump exports the memory dump through /proc/vmcore 19 - Unlike phyp dump, userspace tool does not need to refer any sysfs 21 - Unlike phyp dump, FADump allows user to release all the memory reserved 23 - Once enabled through kernel boot parameter, FADump can be [all …]
|
| /Documentation/driver-api/firmware/ |
| D | fallback-mechanisms.rst | 6 filesystem lookup on the root filesystem or when the firmware simply cannot be 8 configuration options related to supporting the firmware fallback mechanism are: 10 * CONFIG_FW_LOADER_USER_HELPER: enables building the firmware fallback 15 enable the kobject uevent fallback mechanism on all firmware API calls 21 manually load the firmware. Read below for more details. 31 Justifying the firmware fallback mechanism 40 * Races upon resume from suspend. This is resolved by the firmware cache, but 41 the firmware cache is only supported if you use uevents, and its not 44 * Firmware is not accessible through typical means: 47 * The firmware provides very unique device specific data tailored for [all …]
|
| D | firmware_cache.rst | 2 Firmware cache 5 When Linux resumes from suspend some device drivers require firmware lookups to 6 re-initialize devices. During resume there may be a period of time during which 7 firmware lookups are not possible, during this short period of time firmware 9 the root filesystem for firmware delays user experience with device 10 functionality. In order to support these requirements the firmware 11 infrastructure implements a firmware cache for device drivers for most API 14 The firmware cache makes using certain firmware API calls safe during a device 16 the firmware by themselves for dealing with firmware loss during system resume. 18 The firmware cache works by requesting for firmware prior to suspend and [all …]
|
| /Documentation/networking/device_drivers/ethernet/netronome/ |
| D | nfp.rst | 1 .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 14 - `Overview`_ 15 - `Acquiring Firmware`_ 16 - `Devlink Info`_ 17 - `Configure Device`_ 18 - `Statistics`_ 25 are also incorporated in the companies' family of Agilio SmartNICs. The SR-IOV 28 Acquiring Firmware 31 The NFP3800, NFP4000 and NFP6000 devices require application specific firmware 32 to function. Application firmware can be located either on the host file system [all …]
|
| /Documentation/arch/x86/ |
| D | microcode.rst | 1 .. SPDX-License-Identifier: GPL-2.0 7 :Authors: - Fenghua Yu <fenghua.yu@intel.com> 8 - Borislav Petkov <bp@suse.de> 9 - Ashok Raj <ashok.raj@intel.com> 13 updating the microcode on platforms beyond the OEM End-Of-Life support, 14 and updating the microcode on long-running systems without rebooting. 39 During BSP (BootStrapping Processor) boot (pre-SMP), the kernel 56 if [ -z "$1" ]; then 66 rm -rf $TMPDIR 70 mkdir -p $DSTDIR [all …]
|
| /Documentation/networking/devlink/ |
| D | sfc.rst | 1 .. SPDX-License-Identifier: GPL-2.0 15 .. list-table:: devlink info versions implemented 18 * - Name 19 - Type 20 - Description 21 * - ``fw.mgmt.suc`` 22 - running 23 - For boards where the management function is split between multiple 24 control units, this is the SUC control unit's firmware version. 25 * - ``fw.mgmt.cmc`` [all …]
|
| /Documentation/devicetree/bindings/mtd/partitions/ |
| D | arm,arm-firmware-suite.yaml | 1 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause 3 --- 4 $id: http://devicetree.org/schemas/mtd/partitions/arm,arm-firmware-suite.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: ARM Firmware Suite (AFS) Partitions 10 - Linus Walleij <linus.walleij@linaro.org> 15 The ARM Firmware Suite is a flash partitioning system found on the 21 const: arm,arm-firmware-suite 26 - | 28 compatible = "arm,arm-firmware-suite";
|
| /Documentation/devicetree/bindings/gpu/host1x/ |
| D | nvidia,tegra234-nvdec.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 15 - Thierry Reding <treding@gmail.com> 16 - Mikko Perttunen <mperttunen@nvidia.com> 20 pattern: "^nvdec@[0-9a-f]*$" 24 - nvidia,tegra234-nvdec 32 clock-names: 34 - const: nvdec [all …]
|
| /Documentation/admin-guide/ |
| D | efi-stub.rst | 6 as a PE/COFF image, thereby convincing EFI firmware loaders to load 8 along with the EFI-specific entry point that the firmware loader 10 arch/x86/boot/header.S and drivers/firmware/efi/libstub/x86-stub.c, 12 arch/arm/boot/compressed/efi-header.S and 13 drivers/firmware/efi/libstub/arm32-stub.c. EFI stub code that is shared 14 between architectures is in drivers/firmware/efi/libstub. 18 kernel. The arm64 EFI stub lives in drivers/firmware/efi/libstub/arm64.c 19 and drivers/firmware/efi/libstub/arm64-stub.c. 30 -------------------------- 33 System Partition (ESP) and renamed with the extension ".efi". Without [all …]
|
| /Documentation/gpu/amdgpu/ |
| D | flashing.rst | 2 dGPU firmware flashing 6 ---- 7 Flashing the dGPU integrated firmware image (IFWI) is supported by GPUs that 14 1. Ensure the IFWI image is intended for the dGPU on the system. 19 USB-C PD F/W 20 ------------ 21 On GPUs that support flashing an updated USB-C PD firmware image, the process 24 * Reading the file will provide the current firmware version. 25 * Writing the name of a firmware payload stored in `/lib/firmware/amdgpu` to the sysfs file will in… 27 The firmware payload stored in `/lib/firmware/amdgpu` can be named any name [all …]
|
12345678910>>...13