Searched +full:device +full:- +full:specific (Results 1 – 25 of 955) sorted by relevance
12345678910>>...39
| /Documentation/driver-api/ |
| D | vfio-pci-device-specific-driver-acceptance.rst | 1 .. SPDX-License-Identifier: GPL-2.0
3 Acceptance criteria for vfio-pci device specific driver variants
7 --------
8 The vfio-pci driver exists as a device agnostic driver using the
10 handling to provide isolated device access to userspace. While the
11 vfio-pci driver does include some device specific support, further
12 extensions for yet more advanced device specific features are not
13 sustainable. The vfio-pci driver has therefore split out
14 vfio-pci-core as a library that may be reused to implement features
15 requiring device specific knowledge, ex. saving and loading device
[all …]
|
| D | sm501.rst | 9 The Silicon Motion SM501 multimedia companion chip is a multifunction device
12 The device may be connected by PCI or local bus with varying functions enabled.
15 ----
18 drivers which manage the specific hardware blocks. These services
23 chips via the platform device and driver system.
25 On detection of a device, the core initialises the chip (which may
27 peripheral set as platform devices for the specific drivers.
29 The core re-uses the platform device system as the platform device
31 need to create a new bus-type and the associated code to go with it.
35 ---------
[all …]
|
| /Documentation/driver-api/driver-model/ |
| D | driver.rst | 2 Device Drivers
10 Device drivers are statically allocated structures. Though there may
13 device instance).
42 model because the bus they belong to has a bus-specific structure with
43 bus-specific fields that cannot be generalized.
45 The most common example of this are device ID structures. A driver
46 typically defines an array of device IDs that it supports. The format
47 of these structures and the semantics for comparing device IDs are
48 completely bus-specific. Defining them as bus-specific entities would
49 sacrifice type-safety, so we keep bus-specific structures around.
[all …]
|
| D | porting.rst | 12 Please refer to `Documentation/driver-api/driver-model/*.rst` for definitions of
21 be embedded in larger, bus-specific objects. Fields in these generic
22 objects can replace fields in the bus-specific objects.
28 # mount -t sysfs sysfs /sys
34 Step 0: Read include/linux/device.h for object and function definitions.
39 - Define a struct bus_type for the bus driver::
46 - Register the bus type.
65 - Export the bus type for others to use.
81 - This will cause the bus to show up in /sys/bus/pci/ with two
84 # tree -d /sys/bus/pci/
[all …]
|
| D | overview.rst | 2 The Linux Kernel Device Model
16 bus-specific drivers for bridges and devices by consolidating a set of data
19 Traditional driver models implemented some sort of tree-like structure
26 of common callbacks, such as device discovery during bus probing, bus
29 The common device and bridge interface reflects the goals of the modern
30 computer: namely the ability to do seamless device "plug and play", power
32 Microsoft (namely ACPI) ensures that almost every device on almost any bus
33 on an x86-compatible system can work within this paradigm. Of course,
43 and sometimes by the device-specific drivers.
51 struct device dev; /* Generic device interface */
[all …]
|
| /Documentation/driver-api/rapidio/ |
| D | rapidio.rst | 5 The RapidIO standard is a packet-based fabric interconnect standard designed for
8 is publicly available for download from the RTA web-site [1].
16 Because the RapidIO subsystem follows the Linux device model it is integrated
17 into the kernel similarly to other buses by defining RapidIO-specific device and
18 bus types and registering them within the device model.
21 architecture-specific interfaces that provide support for common RapidIO
33 ---------------
38 by a rio_mport data structure. This structure contains master port specific
40 host device ID that is valid when a master port is configured as an enumerating
43 RapidIO master ports are serviced by subsystem specific mport device drivers
[all …]
|
| D | mport_cdev.rst | 2 RapidIO subsystem mport character device driver (rio_mport_cdev.c)
8 This device driver is the result of collaboration within the RapidIO.org
17 for user-space applications. Most of RapidIO operations are supported through
20 When loaded this device driver creates filesystem nodes named rio_mportX in /dev
21 directory for each registered RapidIO mport device. 'X' in the node name matches
22 to unique port ID assigned to each local mport device.
24 Using available set of ioctl commands user-space applications can perform
27 - Reads and writes from/to configuration registers of mport devices
29 - Reads and writes from/to configuration registers of remote RapidIO devices.
32 - Set RapidIO Destination ID for mport devices (RIO_MPORT_MAINT_HDID_SET)
[all …]
|
| /Documentation/devicetree/bindings/usb/ |
| D | omap-usb.txt | 1 OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
4 - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
5 - ti,hwmods : must be "usb_otg_hs"
6 - multipoint : Should be "1" indicating the musb controller supports
7 multipoint. This is a MUSB configuration-specific setting.
8 - num-eps : Specifies the number of endpoints. This is also a
9 MUSB configuration-specific setting. Should be set to "16"
10 - ram-bits : Specifies the ram address size. Should be set to "12"
11 - interface-type : This is a board specific setting to describe the type of
14 - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
[all …]
|
| /Documentation/networking/devlink/ |
| D | octeontx2.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 device drivers.
13 The ``octeontx2 PF and VF`` drivers implement the following driver-specific parameters.
15 .. list-table:: Driver-specific parameters implemented
18 * - Name
19 - Type
20 - Mode
21 - Description
22 * - ``mcam_count``
23 - u16
[all …]
|
| D | mlxsw.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 device driver.
13 .. list-table:: Generic parameters implemented
15 * - Name
16 - Mode
17 * - ``fw_load_policy``
18 - driverinit
20 The ``mlxsw`` driver also implements the following driver-specific
23 .. list-table:: Driver-specific parameters implemented
26 * - Name
[all …]
|
| D | devlink-params.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 ``devlink`` provides capability for a driver to expose device parameters for low
8 level device functionality. Since devlink can operate at the device-wide
10 ports on a single device.
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
[all …]
|
| /Documentation/hwmon/ |
| D | pmbus-core.rst | 9 power-management protocol with a fully defined command language that facilitates
11 protocol is implemented over the industry-standard SMBus serial interface and
12 enables programming, control, and real-time monitoring of compliant power
18 promoted by the PMBus Implementers Forum (PMBus-IF), comprising 30+ adopters
22 commands, and manufacturers can add as many non-standard commands as they like.
23 Also, different PMBUs devices act differently if non-supported commands are
27 Despite all those difficulties, a generic PMBus device driver is still useful
29 device specific extensions in addition to the core PMBus driver, since it is
30 simply unknown what new device specific functionality PMBus device developers
33 To make device specific extensions as scalable as possible, and to avoid having
[all …]
|
| /Documentation/driver-api/pldmfw/ |
| D | driver-ops.rst | 1 .. SPDX-License-Identifier: GPL-2.0-only
4 Driver-specific callbacks
7 The ``pldmfw`` module relies on the device driver for implementing device
8 specific behavior using the following operations.
11 -----------------
14 record matches the device being updated. This requires comparing the record
15 descriptors in the record with information from the device. Many record
20 the device.
23 ----------------------
25 The ``.send_package_data`` operation is used to send the device-specific
[all …]
|
| /Documentation/arch/powerpc/ |
| D | bootwrapper.rst | 17 others. U-Boot is typically found on embedded PowerPC hardware, but there
28 U-Boot (for versions that don't understand the device
29 tree). This image embeds a device tree blob inside
30 the image. The boot wrapper, kernel and device tree
31 are all embedded inside the U-Boot uImage file format
33 bd_info structure and loads the data into the device
37 bd_info structure used in the old U-Boot interfaces,
38 cuImages are platform specific. Each specific
39 U-Boot platform has a different platform init file
40 which populates the embedded device tree with data
[all …]
|
| /Documentation/devicetree/bindings/hwlock/ |
| D | hwlock.txt | 4 Generic bindings that are common to all the hwlock platform specific driver
7 Please also look through the individual platform specific hwlock binding
8 documentations for identifying any additional properties specific to that
15 - #hwlock-cells: Specifies the number of cells needed to represent a
16 specific lock.
21 Consumers that require specific hwlock(s) should specify them using the
22 property "hwlocks", and an optional "hwlock-names" property.
25 - hwlocks: List of phandle to a hwlock provider node and an
27 #hwlock-cells. The list can have just a single hwlock
32 - hwlock-names: List of hwlock name strings defined in the same order
[all …]
|
| /Documentation/arch/arm/google/ |
| D | chromebook-boot-flow.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 Most recent Chromebooks that use device tree are using the opensource
9 Image`_ which contains an OS image as well as a collection of device trees. It
10 is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
13 The scheme that depthcharge_ uses to pick the device tree takes into account
16 - Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
17 - Board revision number, determined at runtime (perhaps by reading GPIO
19 - SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
23 - google,$(BOARD)-rev$(REV)-sku$(SKU)
24 - google,$(BOARD)-rev$(REV)
[all …]
|
| /Documentation/firmware-guide/acpi/ |
| D | DSD-properties-rules.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 _DSD Device Properties Usage Rules
10 The _DSD (Device Specific Data) configuration object, introduced in ACPI 5.1,
11 allows any type of device configuration data to be provided via the ACPI
16 packages associated with them and makes those data available to device drivers
17 as "device properties".
19 A device property is a data item consisting of a string key and a value (of a
20 specific type) associated with it.
22 In the ACPI _DSD context it is an element of the sub-package following the
23 generic Device Properties UUID in the _DSD return package as specified in the
[all …]
|
| /Documentation/devicetree/bindings/powerpc/fsl/ |
| D | mpic.txt | 14 - compatible
22 - reg
24 Value type: <prop-encoded-array>
26 offset and length of the device's registers within the
29 - interrupt-controller
35 - #interrupt-cells
39 specifiers do not contain the interrupt-type or type-specific
42 - #address-cells
47 - pic-no-reset
53 configuration registers to a sane state-- masked or
[all …]
|
| /Documentation/staging/ |
| 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
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,
57 without really powering off the device.
74 Find an rproc handle using a device tree phandle. Returns the rproc
112 struct rproc *rproc_alloc(struct device *dev, const char *name,
117 it yet. Required parameters are the underlying device, the
118 name of this remote processor, platform-specific ops handlers,
[all …]
|
| /Documentation/driver-api/xilinx/ |
| D | eemi.rst | 6 -------------------------------------
7 The zynqmp-firmware node describes the interface to platform firmware.
13 ----------------------------------------------
16 device to communicate with a power management controller (PMC) on a
17 device to issue or respond to power management requests.
23 ------
24 IOCTL API is for device control and configuration. It is not a system
26 any device specific configuration. IOCTL definitions can be platform
27 specific. This API also manage shared device configuration.
29 The following IOCTL IDs are valid for device control:
[all …]
|
| /Documentation/driver-api/usb/ |
| D | typec_bus.rst | 2 API for USB Type-C Alternate Mode drivers
6 ------------
9 Messages (VDM) as defined in USB Type-C and USB Power Delivery Specifications.
10 The communication is SVID (Standard or Vendor ID) specific, i.e. specific for
13 USB Type-C bus allows binding a driver to the discovered partner alternate
16 :ref:`USB Type-C Connector Class <typec>` provides a device for every alternate
17 mode a port supports, and separate device for every alternate mode the partner
22 When a new partner alternate mode device is registered, it is linked to the
23 alternate mode device of the port that the partner is attached to, that has
29 specific commands from the alternate mode drivers to the partner, and from the
[all …]
|
| /Documentation/driver-api/virtio/ |
| D | virtio.rst | 1 .. SPDX-License-Identifier: GPL-2.0
13 between drivers and devices of different types, see Chapter 5 ("Device
16 to interface any compliant device (real or emulated) with a driver.
24 Device - Driver communication: virtqueues
29 using a specific transport method -- PCI, MMIO or CCW -- that is
30 orthogonal to the device itself. The virtio spec defines these transport
31 methods in detail, including device discovery, capabilities and
34 The communication between the driver in the guest OS and the device in
38 similar to the ones used in a network device:
40 .. kernel-doc:: include/uapi/linux/virtio_ring.h
[all …]
|
| /Documentation/driver-api/i3c/ |
| D | protocol.rst | 1 .. SPDX-License-Identifier: GPL-2.0
17 https://resources.mipi.org/mipi-i3c-v1-download).
22 The I3C (pronounced 'eye-three-see') is a MIPI standardized protocol designed
25 while remaining power-efficient.
33 An I3C device on the I3C bus can have one of the following roles:
35 * Master: the device is driving the bus. It's the one in charge of initiating
38 * Slave: the device acts as a slave, and is not able to send frames to another
39 slave on the bus. The device can still send events to the master on
42 I3C is a multi-master protocol, so there might be several masters on a bus,
43 though only one device can act as a master at a given time. In order to gain
[all …]
|
| /Documentation/usb/ |
| D | functionfs-desc.rst | 6 described below. Device and configuration descriptors are handled
13 .. kernel-doc:: include/uapi/linux/usb/functionfs.h
17 ---------------------
20 most recent interface descriptor determines what type of class-specific
23 Class-Specific Descriptors
24 --------------------------
26 Class-specific descriptors are accepted only for the class/subclass of the
28 class-specific descriptors that are supported.
36 Device Firmware Upgrade (DFU), version 1.1 as of this writing.
38 .. kernel-doc:: include/uapi/linux/usb/functionfs.h
|
| /Documentation/devicetree/bindings/memory-controllers/ |
| D | mc-peripheral-props.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/memory-controllers/mc-peripheral-props.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: Peripheral-specific properties for a Memory Controller bus.
12 specific like delay in clock or data lines, etc. These properties need
13 to be defined in the peripheral node because they are per-peripheral
15 those properties are listed here. The controller specific properties
20 - Marek Vasut <marex@denx.de>
24 description: Bank number, base address and size of the device.
[all …]
|
12345678910>>...39