Home
last modified time | relevance | path

Searched +full:firmware +full:- +full:name (Results 1 – 25 of 269) sorted by relevance

1234567891011

/Documentation/ABI/testing/
Dsysfs-firmware-qemu_fw_cfg1 What: /sys/firmware/qemu_fw_cfg/
6 sun4*, ppc/mac) are provisioned with a firmware configuration
8 provide configuration data to the guest firmware. Starting
11 useful as an out-of-band, asynchronous mechanism for providing
14 The authoritative guest-side hardware interface documentation
17 https://qemu-project.gitlab.io/qemu/specs/fw_cfg.html
29 /sys/firmware/qemu_fw_cfg/
33 /sys/firmware/qemu_fw_cfg/rev
41 /sys/firmware/qemu_fw_cfg/by_key/32
42 /sys/firmware/qemu_fw_cfg/by_key/33
[all …]
Dsysfs-firmware-sgi_uv1 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.
50 The /sys/firmware/sgi_uv directory also contains two directories::
56 a UV Hub visible to the BIOS. Each hub object's name is appended by a
57 unique ordinal value (ex. /sys/firmware/sgi_uv/hubs/hub_5)
59 Each hub object directory contains a number of read-only attributes::
63 name
69 If a cnode value is not applicable, the value returned will be -1.
[all …]
Dsysfs-class-remoteproc1 What: /sys/class/remoteproc/.../firmware
4 Description: Remote processor firmware
6 Reports the name of the firmware currently loaded to the
9 To change the running firmware, ensure the remote processor is
19 - "offline"
20 - "suspended"
21 - "running"
22 - "crashed"
23 - "invalid"
41 - "start"
[all …]
Dsysfs-firmware-ofw1 What: /sys/firmware/devicetree/*
9 It is possible for multiple device-tree directories to exist.
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
25 directory name is the resolved path component name (node
26 name plus address). Properties are represented as files
30 What: /sys/firmware/fdt
[all …]
Dsysfs-class-fpga-manager1 What: /sys/class/fpga_manager/<fpga>/name
5 Description: Name of low level fpga manager driver.
14 fix) then userspace can know, i.e. if the firmware request
15 fails, that could be due to not being able to find the firmware
28 * firmware request = firmware class request in progress
29 * firmware request error = firmware request failed
49 * reconfig operation error - invalid operations detected by
53 * reconfig CRC error - CRC error detected by
55 * reconfig incompatible image - reconfiguration image is
57 * reconfig IP protocol error - protocol errors detected by
[all …]
/Documentation/networking/devlink/
Dnfp.rst1 .. SPDX-License-Identifier: GPL-2.0
13 .. list-table:: Generic parameters implemented
15 * - Name
16 - Mode
17 * - ``fw_load_policy``
18 - permanent
19 * - ``reset_dev_on_drv_probe``
20 - permanent
27 .. list-table:: devlink info versions implemented
30 * - Name
[all …]
Dbnxt.rst1 .. SPDX-License-Identifier: GPL-2.0
13 .. list-table:: Generic parameters implemented
15 * - Name
16 - Mode
17 * - ``enable_sriov``
18 - Permanent
19 * - ``ignore_ari``
20 - Permanent
21 * - ``msix_vec_per_pf_max``
22 - Permanent
[all …]
Ddevlink-info.rst1 .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
7 The ``devlink-info`` mechanism enables device drivers to report device
8 (hardware and firmware) information in a standard, extensible fashion.
10 The original motivation for the ``devlink-info`` API was twofold:
12 - making it possible to automate device and firmware management in a fleet
13 of machines in a vendor-independent fashion (see also
14 :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`);
15 - name the per component FW versions (as opposed to the crowded ethtool
18 ``devlink-info`` supports reporting multiple types of objects. Reporting driver
19 versions is generally discouraged - here, and via any other Linux API.
[all …]
Dmlx4.rst1 .. SPDX-License-Identifier: GPL-2.0
13 .. list-table:: Generic parameters implemented
15 * - Name
16 - Mode
17 * - ``internal_err_reset``
18 - driverinit, runtime
19 * - ``max_macs``
20 - driverinit
21 * - ``region_snapshot_enable``
22 - driverinit, runtime
[all …]
Ddevlink-flash.rst1 .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
9 The ``devlink-flash`` API allows updating device firmware. It replaces the
10 older ``ethtool-flash`` mechanism, and doesn't require taking any
13 $ devlink dev flash pci/0000:05:00.0 file flash-boot.bin
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
22 The ``devlink-flash`` command allows optionally specifying a mask indicating
26 .. list-table:: List of overwrite mask bits
29 * - Name
30 - Description
[all …]
Ddevlink-reload.rst1 .. SPDX-License-Identifier: GPL-2.0
7 ``devlink-reload`` provides mechanism to reinit driver entities, applying
8 ``devlink-params`` and ``devlink-resources`` new values. It also provides
9 mechanism to activate firmware.
17 .. list-table:: Possible reload actions
20 * - Name
21 - Description
22 * - ``driver-reinit``
23 - Devlink driver entities re-initialization, including applying
27 * ``devlink-params`` in configuration mode ``driverinit``
[all …]
/Documentation/admin-guide/acpi/
Dssdt-overlays.rst1 .. SPDX-License-Identifier: GPL-2.0
7 In order to support ACPI open-ended hardware configurations (e.g. development
8 boards) we need a way to augment the ACPI configuration provided by the firmware
13 recompiling the firmware image with updated ACPI tables, neither is practical:
15 access to firmware tools which are often not publicly available.
18 way to augment firmware ACPI configuration is by dynamically loading
33 Name (_HID, "BMA222E")
34 Name (RBUF, ResourceTemplate ()
59 ASL Optimizing Compiler version 20140214-64 [Mar 29 2014]
60 Copyright (c) 2000 - 2014 Intel Corporation
[all …]
/Documentation/driver-api/firmware/
Dfirmware-usage-guidelines.rst2 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 …]
Dfallback-mechanisms.rst6 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 …]
/Documentation/gpu/amdgpu/
Dflashing.rst2 dGPU firmware flashing
6 ----
7 Flashing the dGPU integrated firmware image (IFWI) is supported by GPUs that
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
32 -----------
[all …]
/Documentation/devicetree/bindings/net/
Dmarvell,aquantia.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Christian Marangi <ansuelsmth@gmail.com>
13 Marvell Aquantia Ethernet PHY require a firmware to be loaded to actually
17 - Attached SPI flash directly to the PHY with the firmware. The PHY
18 will self load the firmware in the presence of this configuration.
19 - Read from a dedicated partition on system NAND declared in an
21 - Manually provided firmware loaded from a file in the filesystem.
24 - $ref: ethernet-phy.yaml#
[all …]
/Documentation/devicetree/bindings/remoteproc/
Dti,pru-rproc.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/remoteproc/ti,pru-rproc.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Suman Anna <s-anna@ti.com>
13 Each Programmable Real-Time Unit and Industrial Communication Subsystem
14 (PRU-ICSS or PRUSS) has two 32-bit load/store RISC CPU cores called
15 Programmable Real-Time Units (PRUs), each represented by a node. Each PRU
17 use the Data RAMs present within the PRU-ICSS for code execution.
27 corresponding PRU-ICSS node. Each node can optionally be rendered inactive by
[all …]
Dti,k3-m4f-rproc.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Hari Nagalla <hnagalla@ti.com>
11 - Mathieu Poirier <mathieu.poirier@linaro.org>
20 $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
25 - ti,am64-m4fss
27 power-domains:
30 "#address-cells":
[all …]
Dwkup_m3_rproc.txt4 The TI AM33xx and AM43xx family of devices use a small Cortex M3 co-processor
6 that cannot be controlled from the MPU. This CM3 processor requires a firmware
8 the firmware and booting of the CM3.
17 --------------------
18 - compatible: Should be one of,
19 "ti,am3352-wkup-m3" for AM33xx SoCs
20 "ti,am4372-wkup-m3" for AM43xx SoCs
21 - reg: Should contain the address ranges for the two internal
25 - reg-names: Contains the corresponding names for the two memory
27 - ti,hwmods: Name of the hwmod associated with the wkupm3 device.
[all …]
Dmtk,scp.yaml1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Tinghan Shen <tinghan.shen@mediatek.com>
13 This binding provides support for ARM Cortex M4 Co-processor found on some
19 - mediatek,mt8183-scp
20 - mediatek,mt8186-scp
21 - mediatek,mt8188-scp
22 - mediatek,mt8188-scp-dual
23 - mediatek,mt8192-scp
[all …]
/Documentation/devicetree/bindings/net/bluetooth/
Damlogic,w155s2-bt.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
4 ---
5 $id: http://devicetree.org/schemas/net/bluetooth/amlogic,w155s2-bt.yaml#
6 $schema: http://devicetree.org/meta-schemas/core.yaml#
11 The W155S2 is an Amlogic Bluetooth and Wi-Fi combo chip. It works on
12 the standard H4 protocol via a 4-wire UART interface, with baud rates
16 - Yang Li <yang.li@amlogic.com>
21 - items:
22 - enum:
23 - amlogic,w265s1-bt
[all …]
/Documentation/networking/device_drivers/atm/
Dfore200e.rst1 .. 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/devicetree/bindings/soc/fsl/cpm_qe/qe/
Dfirmware.txt1 * 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.
13 - extended-modes: The Extended Modes bitfield, taken from the
14 firmware binary. It is a 64-bit number represented
15 as an array of two 32-bit numbers.
[all …]
/Documentation/devicetree/bindings/i2c/
Di2c-opal.txt1 Device-tree bindings for I2C OPAL driver
2 ----------------------------------------
4 Most of the device node and properties layout is specific to the firmware and
5 used by the firmware itself for configuring the port. From the linux
6 perspective, the properties of use are "ibm,port-name" and "ibm,opal-id".
10 - reg: Port-id within a given master
11 - compatible: must be "ibm,opal-i2c"
12 - ibm,opal-id: Refers to a specific bus and used to identify it when calling
14 - bus-frequency: Operating frequency of the i2c bus (in HZ). Informational for
18 - ibm,port-name: Firmware provides this name that uniquely identifies the i2c
[all …]
/Documentation/leds/
Dleds-lp5562.rst17 For the details, please refer to 'firmware' section in leds-lp55xx.txt
28 This attribute is used for programming LED data with the firmware interface.
45 the engine selection and loading the firmware.
53 echo 1 > /sys/class/firmware/lp5562/loading
54 echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
55 echo 0 > /sys/class/firmware/lp5562/loading
62 echo 1 > /sys/class/firmware/lp5562/loading
63 echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
64 echo 0 > /sys/class/firmware/lp5562/loading
70 Please refer to 'leds-lp55xx.txt"
[all …]

1234567891011