| /linux/Documentation/arch/powerpc/ |
| H A D | bootwrapper.rst | 8 a boot wrapper to make it usable by the system firmware. There is no
9 standard PowerPC firmware interface, so the boot wrapper is designed to
14 The different image types are used to support all of the various firmware
16 used firmware type on general purpose PowerPC systems from Apple, IBM and
17 others. U-Boot is typically found on embedded PowerPC hardware, but there
18 are a handful of other firmware implementations which are also popular. Each
19 firmware interface requires a different image format.
28 U-Boot (for versions that don't understand the device
31 are all embedded inside the U-Boot uImage file format
37 bd_info structure used in the old U-Boot interfaces,
[all …]
|
| /linux/Documentation/leds/ |
| H A D | leds-lp55xx.rst | 8 -----------
14 Device attributes for user-space interface
47 To support device specific configurations, special structure
50 - Maximum number of channels
51 - Reset command, chip enable command
52 - Chip specific initialization
53 - Brightness control register access
54 - Setting LED output current
55 - Program memory address access for running patterns
56 - Additional device specific attributes
[all …]
|
| /linux/Documentation/staging/ |
| H A D | remoteproc.rst | 10 of operating system, whether it's Linux or any other flavor of real-time OS.
12 OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP.
13 In a typical configuration, the dual cortex-A9 is running Linux in a SMP
18 control (power on, load firmware, power off) those remote processors while
22 platform-specific remoteproc drivers only need to provide a few low-level
24 (for more information about the virtio-based rpmsg bus and its drivers,
39 Boot a remote processor (i.e. load its firmware, power it on, ...).
114 const char *firmware, int len)
118 name of this remote processor, platform-specific ops handlers,
119 the name of the firmware to boot this rproc with, and the
[all …]
|
| /linux/Documentation/driver-api/pldmfw/ |
| H A D | index.rst | 1 .. SPDX-License-Identifier: GPL-2.0-only
4 PLDM Firmware Flash Update Library
8 the PLDM for Firmware Update standard
9 <https://www.dmtf.org/documents/pmci/pldm-firmware-update-specification-100>.
14 file-format
15 driver-ops
22 implementing device flash update based on firmware files following the PLDM
23 firmware file format.
26 the underlying device specific functionality.
29 firmware file into data structures, and then uses the provided function
[all …]
|
| H A D | driver-ops.rst | 1 .. SPDX-License-Identifier: GPL-2.0-only
4 Driver-specific callbacks
8 specific behavior using the following operations.
11 -----------------
23 ----------------------
25 The ``.send_package_data`` operation is used to send the device-specific
26 package data in a record to the device firmware. If the matching record
29 length. The device driver should send this data to firmware.
32 -------------------------
37 device driver should send the component information to the device firmware,
[all …]
|
| /linux/Documentation/driver-api/xilinx/ |
| H A D | eemi.rst | 5 Xilinx Zynq MPSoC Firmware Interface
6 -------------------------------------
7 The zynqmp-firmware node describes the interface to platform firmware.
8 ZynqMP has an interface to communicate with secure firmware. Firmware
9 driver provides an interface to firmware APIs. Interface APIs can be
13 ----------------------------------------------
23 ------
26 any device specific configuration. IOCTL definitions can be platform
27 specific. This API also manage shared device configuration.
30 - IOCTL_SET_PLL_FRAC_MODE 8
[all …]
|
| /linux/include/sound/ |
| H A D | soc-topology.h | 1 /* SPDX-License-Identifier: GPL-2.0
3 * linux/sound/soc-topology.h -- ALSA SoC Firmware Controls and DAPM
18 struct firmware;
60 /* generic dynamic object - all dynamic objects belong to this struct */
74 * Kcontrol operations - used to map handlers onto firmware based controls.
96 * DAPM widget event handlers - used to map handlers onto widgets.
105 * Public API - Used by component drivers to load and unload dynamic objects
110 /* external kcontrol init - used for any driver specific init */
122 /* external widget init - used for any driver specific init */
132 /* FE DAI - used for any driver specific init */
[all …]
|
| /linux/drivers/scsi/snic/ |
| H A D | snic_fwint.h | 1 /* SPDX-License-Identifier: GPL-2.0-only */
44 * Header status codes from firmware
81 * snic_io_hdr : host <--> firmware
83 * for any other message that will be queued to firmware should
92 u8 protocol; /* Protocol specific, may needed for RoCE*/
103 hdr->type = typ; in snic_io_hdr_enc()
104 hdr->status = status; in snic_io_hdr_enc()
105 hdr->protocol = 0; in snic_io_hdr_enc()
106 hdr->hid = cpu_to_le32(hid); in snic_io_hdr_enc()
107 hdr->cmnd_id = cpu_to_le32(id); in snic_io_hdr_enc()
[all …]
|
| /linux/include/linux/ |
| H A D | remoteproc.h | 20 * from this software without specific prior written permission.
47 * struct resource_table - firmware resource table header
55 * If needed, the remote processor firmware should contain this table
59 * of specific remoteproc configuration. Other entries require the host to
61 * is expected, where the firmware requests a resource, and once allocated,
81 * struct fw_rsc_hdr - firmware resource entry header
95 * enum fw_resource_type - types of resource entries
99 * @RSC_DEVMEM: request to iommu_map a memory-based peripheral.
105 * @RSC_VENDOR_START: start of the vendor specific resource types range
106 * @RSC_VENDOR_END: end of the vendor specific resource types range
[all …]
|
| /linux/include/uapi/linux/ |
| H A D | nl80211-vnd-intel.h | 1 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
3 * Copyright (C) 2012-2014, 2018-2021 Intel Corporation
4 * Copyright (C) 2013-2015 Intel Mobile Communications GmbH
5 * Copyright (C) 2016-2017 Intel Deutschland GmbH
13 * enum iwl_mvm_vendor_cmd - supported vendor commands
16 * This is useful when the CSME firmware owns the device and the kernel
17 * wants to use it. In case the CSME firmware has no connection active the
19 * When the CSME firmware has an active connection, the user space
23 * to the very same AP the CSME firmware is currently connected to:
27 * 2) The user space asks the kernel what AP the CSME firmware is
[all …]
|
| H A D | pfrut.h | 1 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
3 * Platform Firmware Runtime Update header
16 * PFRU_IOC_SET_REV - _IOW(PFRUT_IOCTL_MAGIC, 0x01, unsigned int)
19 * * 0 - success
20 * * -EFAULT - fail to read the revision id
21 * * -EINVAL - user provides an invalid revision id
23 * Set the Revision ID for Platform Firmware Runtime Update.
28 * PFRU_IOC_STAGE - _IOW(PFRUT_IOCTL_MAGIC, 0x02, unsigned int)
31 * * 0 - success
32 * * -EINVAL - stage phase returns invalid result
[all …]
|
| /linux/Documentation/firmware-guide/acpi/ |
| H A D | chromeos-acpi-device.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 Hardware functionality specific to Chrome OS is exposed through a Chrome OS ACPI device.
11 .. flat-table:: Supported ACPI Objects
13 :header-rows: 1
15 * - Object
16 - Description
18 * - CHSW
19 - Chrome OS switch positions
21 * - HWID
22 - Chrome OS hardware ID
[all …]
|
| /linux/net/ethtool/ |
| H A D | module_fw.h | 1 /* SPDX-License-Identifier: GPL-2.0-only */
7 * struct ethnl_module_fw_flash_ntf_params - module firmware flashing
20 * struct ethtool_module_fw_flash_params - module firmware flashing parameters
30 * struct ethtool_cmis_fw_update_params - CMIS firmware update specific
33 * @params: Module firmware flashing parameters.
34 * @ntf_params: Module firmware flashing notification parameters.
35 * @fw: Firmware to flash.
41 const struct firmware *fw;
45 * struct ethtool_module_fw_flash - module firmware flashing
48 * @work: The flashing firmware work.
[all …]
|
| /linux/drivers/leds/ |
| H A D | leds-lp55xx-common.h | 1 /* SPDX-License-Identifier: GPL-2.0-only */
9 * Derived from leds-lp5521.c, leds-lp5523.c
15 #include <linux/led-class-multicolor.h>
116 * @reg_op_mode : Chip specific OP MODE reg addr
117 * @engine_busy : Chip specific engine busy
119 * @reset : Chip specific reset command
120 * @enable : Chip specific enable command
121 * @prog_mem_base : Chip specific base reg address for chip SMEM programming
122 * @reg_led_pwm_base : Chip specific base reg address for LED PWM conf
123 * @reg_led_current_base : Chip specific base reg address for LED current conf
[all …]
|
| /linux/Documentation/networking/device_drivers/ethernet/pensando/ |
| H A D | ionic.rst | 1 .. SPDX-License-Identifier: GPL-2.0+
13 - Identifying the Adapter
14 - Enabling the driver
15 - Configuring the driver
16 - Statistics
17 - Support
25 $ lspci -d 1dd8:
36 ionic 0000:b5:00.0 enp181s0: Link up - 100 Gbps
39 ionic 0000:b6:00.0 enp182s0: Link up - 100 Gbps
41 Driver and firmware version information can be gathered with either of
[all …]
|
| /linux/Documentation/networking/devlink/ |
| H A D | devlink-info.rst | 1 .. 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 …]
|
| H A D | bnxt.rst | 1 .. 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 …]
|
| H A D | mlx4.rst | 1 .. 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 …]
|
| H A D | devlink-params.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 level device functionality. Since devlink can operate at the device-wide
14 parameters. Each driver must document the specific parameters they support,
22 .. list-table:: Possible configuration modes
25 * - Name
26 - Description
27 * - ``runtime``
28 - set while the driver is running, and takes effect immediately. No
30 * - ``driverinit``
31 - applied while the driver initializes. Requires the user to restart
[all …]
|
| H A D | devlink-reload.rst | 1 .. 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 …]
|
| /linux/Documentation/arch/arm/ |
| H A D | firmware.rst | 2 Interface for registering and calling firmware-specific operations for ARM
7 Some boards are running with secure firmware running in TrustZone secure
9 a need to provide an interface for such platforms to specify available firmware
12 Firmware operations can be specified by filling in a struct firmware_ops
18 The ops pointer must be non-NULL. More information about struct firmware_ops
19 and its members can be found in arch/arm/include/asm/firmware.h header.
22 set anything if platform does not require firmware operations.
24 To call a firmware operation, a helper macro is provided::
27 ((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
30 -ENOSYS to signal that given operation is not available (for example, to allow
[all …]
|
| /linux/Documentation/driver-api/ |
| H A D | switchtec.rst | 11 * Firmware Upgrades
14 * Custom user firmware commands
22 The primary means of communicating with the Switchtec management firmware is
23 through the Memory-mapped Remote Procedure Call (MRPC) interface.
24 Commands are submitted to the interface with a 4-byte command
25 identifier and up to 1KB of command specific data. The firmware will
26 respond with a 4-byte return code and up to 1KB of command-specific
41 command to the firmware to begin processing.
47 * A read will block until the firmware completes the command and return
48 the 4-byte Command Return Value plus up to 1024 bytes of output
[all …]
|
| /linux/drivers/net/wireless/broadcom/brcm80211/brcmfmac/ |
| H A D | fweh.h | 1 // SPDX-License-Identifier: ISC
24 /* list of firmware events */
102 /* firmware event codes sent by the dongle */
203 * struct brcm_ethhdr - broadcom specific ether header.
234 * struct brcmf_event - contents of broadcom event packet.
237 * @hdr: broadcom specific ether header.
247 * struct brcmf_event_msg - firmware event message.
251 * @event_code: firmware event code.
288 * struct brcmf_fweh_event_map_item - fweh event and firmware event pair.
291 * @fwevt_code: firmware event code as used by firmware.
[all …]
|
| /linux/drivers/gpu/drm/imagination/ |
| H A D | pvr_fw.h | 1 /* SPDX-License-Identifier: GPL-2.0-only OR MIT */
27 * struct pvr_fw_object - container for firmware memory allocations
37 * @fw_mm_node: Node representing mapping in FW address space. @pvr_obj->lock must
43 * @fw_addr_offset: Virtual address offset of firmware mapping. Only
58 /** @node: Node for firmware object list. */
63 * struct pvr_fw_defs - FW processor function table and static definitions
69 * FW processor specific initialisation.
72 * This function must call pvr_fw_heap_calculate() to initialise the firmware heap for this
86 * FW processor specific finalisation.
96 * Load and process firmware image.
[all …]
|
| /linux/drivers/staging/greybus/ |
| H A D | firmware.h | 1 /* SPDX-License-Identifier: GPL-2.0 */
3 * Greybus Firmware Management Header
22 /* Firmware Management Protocol specific functions */
30 /* Firmware Download Protocol specific functions */
35 /* CAP Protocol specific functions */
|