Searched full:firmware (Results 1 – 25 of 717) sorted by relevance
12345678910>>...29
| /Documentation/ABI/stable/ |
| D | sysfs-driver-firmware-zynqmp | 1 What: /sys/devices/platform/firmware\:zynqmp-firmware/ggs* 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* 46 # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 47 # echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 51 # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 52 # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 [all …]
|
| /Documentation/driver-api/firmware/ |
| D | firmware_cache.rst | 2 Firmware cache 5 When Linux resumes from suspend some device drivers require firmware lookups to 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 19 caching it in memory. Upon resume device drivers using the firmware API will [all …]
|
| D | built-in-fw.rst | 2 Built-in firmware 5 Firmware can be built-in to the kernel, this means building the firmware 6 into vmlinux directly, to enable avoiding having to look for firmware from 7 the filesystem. Instead, firmware can be looked for inside the kernel 8 directly. You can enable built-in firmware using the kernel configuration 14 There are a few reasons why you might want to consider building your firmware 18 * Firmware is needed for accessing the boot device, and the user doesn't 19 want to stuff the firmware into the boot initramfs. 22 able to make use of built-in firmware: 24 * Legalese - firmware is non-GPL compatible [all …]
|
| D | firmware-usage-guidelines.rst | 2 Firmware Guidelines 6 firmware files to keep their hardware working. At the same time updated 7 firmware files must not cause any regressions for users of older kernel 10 Drivers that use firmware from linux-firmware should follow the rules in 11 this guide. (Where there is limited control of the firmware, 15 * Firmware files shall be designed in a way that it allows checking for 16 firmware ABI version changes. It is recommended that firmware files be 18 the firmware files in linux-firmware be named with some device 19 specific name, and just the major version. The firmware version should 20 be stored in the firmware header, or as an exception, as part of the [all …]
|
| 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 | lookup-order.rst | 2 Firmware lookup order 5 Different functionality is available to enable firmware to be found. 6 Below is chronological order of how firmware will be looked for once 7 a driver issues a firmware API call. 9 * The ''Built-in firmware'' is checked first, if the firmware is present we 11 * The ''Firmware cache'' is looked at next. If the firmware is found we 15 * The ''Platform firmware fallback'' is performed next, but only when 17 * If no firmware has been found and the fallback mechanism was enabled 19 is issued or the custom firmware loading is relied upon for firmware
|
| D | fw_upload.rst | 4 Firmware Upload API 7 A device driver that registers with the firmware loader will expose 8 persistent sysfs nodes to enable users to initiate firmware updates for 10 device itself to perform any validation on the data received. Firmware 12 documentation for firmware fallback. It also adds additional sysfs files 13 to provide status on the transfer of the firmware image to the device. 15 Register for firmware upload 18 A device driver registers for firmware upload by calling 20 identify the device under /sys/class/firmware. A user may initiate a 21 firmware upload by echoing a 1 to the *loading* sysfs file for the target [all …]
|
| D | request_firmware.rst | 5 You would typically load firmware and then load it into your device somehow. 6 The typical firmware work flow is reflected below:: 8 if(request_firmware(&fw_entry, $FIRMWARE, device) == 0) 12 Synchronous firmware requests 15 Synchronous firmware requests will wait until the firmware is found or until 43 Asynchronous firmware requests 46 Asynchronous firmware requests allow driver code to not have to wait 47 until the firmware or an error is returned. Function callbacks are 48 provided so that when the firmware or an error is found the driver is 60 Some devices have an optimization in place to enable the firmware to be [all …]
|
| /Documentation/driver-api/nvdimm/ |
| D | firmware-activate.rst | 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 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', 25 No devices are set / armed to activate firmware 37 activation. In that scenario the potential for firmware activation to 40 The 'ndbusX/firmware/activate' property can be written with a value of [all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-class-firmware | 1 What: /sys/class/firmware/.../data 5 Description: The data sysfs file is used for firmware-fallback and for 6 firmware uploads. Cat a firmware image to this sysfs file 7 after you echo 1 to the loading sysfs file. When the firmware 9 sequence will signal the completion of the firmware write and 10 signal the lower-level driver that the firmware data is 13 What: /sys/class/firmware/.../cancel 17 Description: Write-only. For firmware uploads, write a "1" to this file to 18 request that the transfer of firmware data to the lower-level 21 progress) or (ENODEV) if there is no firmware update in progress. [all …]
|
| D | sysfs-firmware-efi-esrt | 1 What: /sys/firmware/efi/esrt/ 5 (ESRT), a catalog of firmware for which can be updated with 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>/ 32 example: /sys/firmware/efi/esrt/entries/entry0/ 34 What: /sys/firmware/efi/esrt/entries/entry<N>/fw_type [all …]
|
| D | sysfs-firmware-gsmi | 1 What: /sys/firmware/gsmi 5 Some servers used internally at Google have firmware 13 these firmware callbacks. Currently, this functionality 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: 30 the firmware to be timestamped and appended to 32 interpreted by the firmware and may change from 36 firmware call. [all …]
|
| D | sysfs-firmware-memmap | 1 What: /sys/firmware/memmap/ 5 On all platforms, the firmware provides a memory map which the 10 However, on most architectures that firmware-provided memory 16 kexec needs the raw firmware-provided memory map to setup the 19 that reason, /sys/firmware/memmap is an interface that provides 22 The structure is as follows: Under /sys/firmware/memmap there 25 /sys/firmware/memmap/0 26 /sys/firmware/memmap/1 27 /sys/firmware/memmap/2 28 /sys/firmware/memmap/3 [all …]
|
| D | sysfs-ibft | 1 What: /sys/firmware/ibft/initiator 4 Description: The /sys/firmware/ibft/initiator directory will contain 5 files that expose the iSCSI Boot Firmware Table initiator data. 8 What: /sys/firmware/ibft/targetX 11 Description: The /sys/firmware/ibft/targetX directory will contain 12 files that expose the iSCSI Boot Firmware Table target data. 18 What: /sys/firmware/ibft/ethernetX 21 Description: The /sys/firmware/ibft/ethernetX directory will contain 22 files that expose the iSCSI Boot Firmware Table NIC data. 25 What: /sys/firmware/ibft/acpi_header [all …]
|
| D | sysfs-secvar | 1 What: /sys/firmware/secvar 4 Description: This directory is created if the POWER firmware supports OS 8 What: /sys/firmware/secvar/vars 12 by the firmware. 14 What: /sys/firmware/secvar/format 17 Description: A string indicating which backend is in use by the firmware. 21 On powernv/OPAL, this value is provided by the OPAL firmware 29 What: /sys/firmware/secvar/vars/<variable name> 37 What: /sys/firmware/secvar/vars/<variable_name>/size 43 What: /sys/firmware/secvar/vars/<variable_name>/data [all …]
|
| /Documentation/devicetree/bindings/soc/fsl/cpm_qe/ |
| D | fsl,qe-firmware.yaml | 4 $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe-firmware.yaml# 7 title: Freescale QUICC Engine module Firmware Node 13 This node defines a firmware binary that is embedded in the device tree, for 14 the purpose of passing the firmware from bootloader to the kernel, or from 17 The firmware node itself contains the firmware binary contents, a compatible 18 property, and any firmware-specific properties. The node should be placed 20 fsl,firmware-phandle property. Other QE nodes that need the same firmware 21 should define an fsl,firmware-phandle property that points to the firmware node 24 The fsl,firmware property can be specified in the DTS (possibly using incbin) 30 - fsl,qe-firmware [all …]
|
| /Documentation/networking/device_drivers/ethernet/meta/ |
| D | fbnic.rst | 7 Firmware Versions 13 1. fw - The control firmware used to view and modify firmware settings, request 14 firmware actions, and retrieve firmware counters outside of the data path. 15 This is the firmware which fbnic_fw.c interacts with. 16 2. bootloader - The firmware which validate firmware security and control basic 17 operations including loading and updating the firmware. This is also known 18 as the cmrt firmware. 22 to fall back to an older version of firmware automatically in case firmware
|
| /Documentation/devicetree/bindings/arm/bcm/ |
| D | raspberrypi,bcm2835-firmware.yaml | 4 $id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml# 7 title: Raspberry Pi VideoCore firmware driver 17 const: raspberrypi,bcm2835-firmware 25 - const: raspberrypi,bcm2835-firmware 37 const: raspberrypi,firmware-clocks 43 firmware messages. 55 const: raspberrypi,firmware-gpio 79 const: raspberrypi,firmware-reset 84 The argument is the ID of the firmware reset line to affect. 96 const: raspberrypi,firmware-poe-pwm [all …]
|
| /Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/ |
| D | firmware.txt | 1 * Uploaded QE firmware 3 If a new firmware has been uploaded to the QE (usually by the 4 boot loader), then a 'firmware' child node should be added to the QE 5 node. This node provides information on the uploaded firmware that 9 - id: The string name of the firmware. This is taken from the 'id' 10 member of the qe_firmware structure of the uploaded firmware. 12 firmware they want is already present. 14 firmware binary. It is a 64-bit number represented 16 - virtual-traps: The virtual traps, taken from the firmware binary. 20 firmware {
|
| /Documentation/networking/devlink/ |
| D | devlink-flash.rst | 9 The ``devlink-flash`` API allows updating device firmware. It replaces the 15 Note that the file name is a path relative to the firmware loading path 16 (usually ``/lib/firmware/``). Drivers may send status updates to inform 41 are provided, it is expected that the device only update firmware binaries 47 Firmware Loading 50 Devices which require firmware to operate usually store it in non-volatile 51 memory on the board, e.g. flash. Some devices store only basic firmware on 53 ``devlink-info`` allows users to query firmware information (loaded 61 On-disk firmware files are usually stored in ``/lib/firmware/``. 63 Firmware Version Management [all …]
|
| /Documentation/networking/device_drivers/ethernet/netronome/ |
| D | nfp.rst | 15 - `Acquiring Firmware`_ 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 33 or in the device flash (if supported by management firmware). 35 Firmware files on the host filesystem contain card type (`AMDA-*` string), media 36 config etc. They should be placed in `/lib/firmware/netronome` directory to 37 load firmware from the host file system. 39 Firmware for basic NIC operation is available in the upstream 40 `linux-firmware.git` repository. [all …]
|
| /Documentation/hwmon/ |
| D | nct6683.rst | 36 Limit register locations on Intel boards with EC firmware version 1.0 38 datasheet. Nuvoton confirms that Intel uses a special firmware version 40 firmware is held under NDA by Nuvoton and Intel and not available 45 considered too risky with this firmware and has been disabled. All limits 48 The driver has only been tested with the Intel firmware, and by default 52 Tested Boards and Firmware Versions 56 firmware versions. 59 Board Firmware version 61 Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13 62 Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13 [all …]
|
| /Documentation/devicetree/bindings/input/touchscreen/ |
| D | raspberrypi,firmware-ts.txt | 1 Raspberry Pi firmware based 7" touchscreen 5 - compatible: "raspberrypi,firmware-ts" 8 - firmware: Reference to RPi's firmware device node 17 firmware: firmware-rpi { 18 compatible = "raspberrypi,bcm2835-firmware"; 22 compatible = "raspberrypi,firmware-ts";
|
| /Documentation/devicetree/bindings/firmware/xilinx/ |
| D | xlnx,zynqmp-firmware.yaml | 4 $id: http://devicetree.org/schemas/firmware/xilinx/xlnx,zynqmp-firmware.yaml# 7 title: Xilinx firmware driver 12 description: The zynqmp-firmware node describes the interface to platform 13 firmware. ZynqMP has an interface to communicate with secure firmware. 14 Firmware driver provides an interface to firmware APIs. Interface APIs 24 const: xlnx,zynqmp-firmware 27 const: xlnx,versal-firmware 32 - xlnx,versal-net-firmware 33 - const: xlnx,versal-firmware 37 The method of calling the PM-API firmware layer. [all …]
|
| /Documentation/networking/device_drivers/atm/ |
| D | fore200e.rst | 22 Firmware Copyright Notice 29 Firmware Updates 32 The FORE Systems 200E-series driver is shipped with firmware data being 34 The supplied firmware images should work with all adapters. 36 However, if you encounter problems (the firmware doesn't start or the driver 37 is unable to read the PROM data), you may consider trying another firmware 38 version. Alternative binary firmware images can be found somewhere on the 41 You can also get the latest firmware images from FORE Systems at 43 the 'software updates' pages. The firmware binaries are part of 46 Notice that different versions of the PCA-200E firmware exist, depending [all …]
|
12345678910>>...29