Searched full:device (Results 1 – 25 of 3029) sorted by relevance
12345678910>>...122
| /Documentation/admin-guide/device-mapper/ |
| D | zero.rst | 5 Device-Mapper's "zero" target provides a block-device that always returns
7 /dev/zero, but as a block-device instead of a character-device.
12 conjunction with dm-snapshot. A sparse device reports a device-size larger
13 than the amount of actual storage space available for that device. A user can
14 write data anywhere within the sparse device and read it back like a normal
15 device. Reads to previously unwritten areas will return a zero'd buffer. When
17 device is deactivated. This can be very useful for testing device and
20 To create a sparse device, start by creating a dm-zero device that's the
21 desired size of the sparse device. For this example, we'll assume a 10TB
22 sparse device::
[all …]
|
| D | dm-clone.rst | 10 dm-clone is a device mapper target which produces a one-to-one copy of an
11 existing, read-only source device into a writable destination device: It
12 presents a virtual block device which makes all data appear immediately, and
16 read-only, archival-type block device into a writable, fast, primary-type device
17 for fast, low-latency I/O. The cloned device is visible/mountable immediately
18 and the copy of the source device to the destination device happens in the
23 etc.), into a local SSD or NVMe device, and start using the device immediately,
27 replaced, e.g., by a linear table, mapping directly to the destination device.
36 The process of filling a region of the destination device with data from
37 the same region of the source device, i.e., copying the region from the
[all …]
|
| /Documentation/power/ |
| D | runtime_pm.rst | 17 * The power management workqueue pm_wq in which bus types and device drivers can
24 * A number of runtime PM fields in the 'power' member of 'struct device' (which
28 * Three device runtime PM callbacks in 'struct dev_pm_ops' (defined in
34 device drivers are encouraged to use these functions.
36 The runtime PM callbacks present in 'struct dev_pm_ops', the device runtime PM
40 2. Device Runtime PM Callbacks
43 There are three device runtime PM callbacks defined in 'struct dev_pm_ops'::
47 int (*runtime_suspend)(struct device *dev);
48 int (*runtime_resume)(struct device *dev);
49 int (*runtime_idle)(struct device *dev);
[all …]
|
| D | pm_qos_interface.rst | 11 2. the per-device PM QoS framework provides the API to manage the per-device latency
25 The infrastructure exposes multiple misc device nodes one per implemented
83 As long as the device node is held open that process has a registered
87 the open device node. Alternatively the user mode program could write a hex
91 To remove the user mode request for a target value simply close the device
95 2. PM QoS per-device latency and flags framework
98 For each device, there are three lists of PM QoS requests. Two of them are
106 values. One device PM QoS flag is defined currently: PM_QOS_FLAG_NO_POWER_OFF.
114 int dev_pm_qos_add_request(device, handle, type, value):
115 Will insert an element into the list for that identified device with the
[all …]
|
| /Documentation/driver-api/driver-model/ |
| D | device.rst | 2 The Basic Device Structure
5 See the kerneldoc for the struct device.
10 The bus driver that discovers the device uses this to register the
11 device with the core::
13 int device_register(struct device * dev);
22 A device is removed from the core when its reference count goes to
25 struct device * get_device(struct device * dev);
26 void put_device(struct device * dev);
28 get_device() will return a pointer to the struct device passed to it
32 A driver can access the lock in the device structure using::
[all …]
|
| D | class.rst | 2 Device Classes
7 A device class describes a type of device, like an audio or network
8 device. The following device classes have been identified:
10 <Insert List of Device Classes Here>
13 Each device class defines a set of semantics and a programming interface
14 that devices of that class adhere to. Device drivers are the
15 implementation of that programming interface for a particular device on
18 Device classes are agnostic with respect to what bus a device resides
24 The device class structure looks like::
27 typedef int (*devclass_add)(struct device *);
[all …]
|
| D | binding.rst | 5 Driver binding is the process of associating a device with a device
8 devices and the drivers. With generic device and device driver
16 type in the system. When device_register is called for a device, it is
26 When a new device is added, the bus's list of drivers is iterated over
27 to find one that supports it. In order to determine that, the device
28 ID of the device must match one of the device IDs that the driver
32 a device against the IDs of a driver. The bus returns 1 if a match was
35 int match(struct device * dev, struct device_driver * drv);
37 If a match is found, the device's driver field is set to the driver
42 Device Class
[all …]
|
| D | driver.rst | 2 Device Drivers
11 Device drivers are statically allocated structures. Though there may
14 device instance).
46 The most common example of this are device ID structures. A driver
47 typically defines an array of device IDs that it supports. The format
48 of these structures and the semantics for comparing device IDs are
97 used by the device model core or the bus driver.
122 int (*callback)(struct device *dev, void *data));
127 node access, and does proper reference counting on each device as it
150 int (*probe) (struct device *dev);
[all …]
|
| /Documentation/devicetree/bindings/timer/ |
| D | renesas,cmt.txt | 15 - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4.
16 - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4.
17 - "renesas,r8a7740-cmt0" for the 32-bit CMT0 device included in r8a7740.
18 - "renesas,r8a7740-cmt1" for the 48-bit CMT1 device included in r8a7740.
19 - "renesas,r8a7740-cmt2" for the 32-bit CMT2 device included in r8a7740.
20 - "renesas,r8a7740-cmt3" for the 32-bit CMT3 device included in r8a7740.
21 - "renesas,r8a7740-cmt4" for the 32-bit CMT4 device included in r8a7740.
22 - "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743.
23 - "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743.
24 - "renesas,r8a7744-cmt0" for the 32-bit CMT0 device included in r8a7744.
[all …]
|
| /Documentation/s390/ |
| D | driver-model.rst | 24 In this example, device 0815 is accessed via subchannel 0 in subchannel set 0,
25 device 4711 via subchannel 1 in subchannel set 0, and subchannel 2 is a non-I/O
26 subchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1.
30 if they are displaced by another ccw device becoming operational on their
34 You should address a ccw device via its bus id (e.g. 0.0.4711); the device can
43 The device type / model, if applicable.
46 Can be 'good' or 'boxed'; 'no path' or 'no device' for
50 An interface to set the device online and offline.
51 In the special case of the device being disconnected (see the
53 the device.
[all …]
|
| /Documentation/devicetree/bindings/i2c/ |
| D | renesas,i2c.txt | 5 "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC.
6 "renesas,i2c-r8a7744" if the device is a part of a R8A7744 SoC.
7 "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC.
8 "renesas,i2c-r8a77470" if the device is a part of a R8A77470 SoC.
9 "renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC.
10 "renesas,i2c-r8a774c0" if the device is a part of a R8A774C0 SoC.
11 "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
12 "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
13 "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
14 "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
[all …]
|
| /Documentation/devicetree/bindings/serial/ |
| D | slave-device.txt | 1 Serial Slave Device DT binding
7 Serial attached devices shall be a child node of the host UART device the
8 slave device is attached to. It is expected that the attached device is
9 the only child node of the UART device. The slave device node name shall
10 reflect the generic type of device for the node.
14 - compatible : A string reflecting the vendor and specific device the node
19 - max-speed : The maximum baud rate the device operates at. This should
20 only be present if the maximum is less than the slave device
24 - current-speed : The current baud rate the device operates at. This should
26 the baud rate of the slave device.
[all …]
|
| /Documentation/driver-api/ |
| D | device_link.rst | 8 Device links
12 that are borne out of a parent/child relationship within the device
17 Sometimes there is a need to represent device dependencies beyond the
22 dependencies, i.e. that one device must be bound to a driver before
25 Often these two dependency types come together, so a device depends on
29 Device links allow representation of such dependencies in the driver core.
31 In its standard or *managed* form, a device link combines *both* dependency
33 "supplier" device and its "consumer" devices, and it guarantees driver
39 suspend/resume and shutdown ordering is needed, the device link may
44 ``DL_FLAG_PM_RUNTIME`` flag on addition of the device link, the PM core
[all …]
|
| D | slimbus.rst | 21 reading/writing device specific values), or multicast (e.g. data channel
25 channel uses dedicated ports on the device.
29 SLIMbus specification has different types of device classifications based on
31 A manager device is responsible for enumeration, configuration, and dynamic
34 A generic device is a device providing application functionality (e.g. codec).
36 Framer device is responsible for clocking the bus, and transmitting frame-sync
39 Each SLIMbus component has an interface device for monitoring physical layer.
41 Typically each SoC contains SLIMbus component having 1 manager, 1 framer device,
42 1 generic device (for data channel support), and 1 interface device.
43 External peripheral SLIMbus component usually has 1 generic device (for
[all …]
|
| /Documentation/networking/ |
| D | devlink-params.txt | 4 Each parameter can be generic or driver specific and are device level
14 permanent - written to device's non-volatile memory, hard reset
19 enable_sriov [DEVICE, GENERIC]
21 the device.
24 ignore_ari [DEVICE, GENERIC]
32 msix_vec_per_pf_max [DEVICE, GENERIC]
34 a device can create. Value is same across all
35 physical functions (PFs) in the device.
38 msix_vec_per_pf_min [DEVICE, GENERIC]
40 for the device initialization. Value is same across all
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-bus-vfio-mdev | 1 What: /sys/.../<device>/mdev_supported_types/
6 supported mediated device types and their details for
7 <device>. Supported type attributes are defined by the
8 vendor driver who registers with Mediated device framework.
10 by adding the device driver string as a prefix to the
13 What: /sys/.../<device>/mdev_supported_types/<type-id>/
28 Writing UUID to this file will create mediated device of
29 type <type-id> for parent device <device>. This is a
51 device of that type. Userspace application should check
53 creating mediated device of this type.
[all …]
|
| D | sysfs-fs-nilfs2 | 16 What: /sys/fs/nilfs2/<device>/revision
24 What: /sys/fs/nilfs2/<device>/blocksize
30 What: /sys/fs/nilfs2/<device>/device_size
36 What: /sys/fs/nilfs2/<device>/free_blocks
42 What: /sys/fs/nilfs2/<device>/uuid
48 What: /sys/fs/nilfs2/<device>/volume_name
54 What: /sys/fs/nilfs2/<device>/README
58 Describe attributes of /sys/fs/nilfs2/<device> group.
60 What: /sys/fs/nilfs2/<device>/superblock/sb_write_time
67 What: /sys/fs/nilfs2/<device>/superblock/sb_write_time_secs
[all …]
|
| D | sysfs-bus-acpi | 6 object associated with the device object. For example,
8 This file is not present for device objects representing
16 This attribute indicates the PNP IDs of the device object.
18 CCCCCCCC contains device object's PNPID (_HID or _CID).
25 device object. For example, PNP0103.
26 This file is present for device objects having the _HID
33 This attribute contains the output of the device object's
40 This attribute contains the output of the device object's
41 _ADR control method, which is present for ACPI device
49 This attribute contains the output of the device object's
[all …]
|
| D | sysfs-bus-pci | 5 Writing a device location to this file will cause
6 the driver to attempt to bind to the device found at
9 That is Domain:Bus:Device.Function and is the same as
18 Writing a device location to this file will cause the
19 driver to attempt to unbind from the device found at
22 That is Domain:Bus:Device.Function and is the same as
31 Writing a device ID to this file will attempt to
32 dynamically add a new device ID to a PCI device driver.
34 was included in the driver's static device ID support
35 table at compile time. The format for the device ID is:
[all …]
|
| D | sysfs-devices-power | 7 management related properties of given device.
14 space to check if the device is enabled to wake up the system
32 events this file is not present. In that case the device cannot
40 space to control the run-time power management of the device.
45 + "auto\n" to allow the device to be power managed at run time;
46 + "on\n" to prevent the device from being power managed;
51 from power managing the device at run time. Doing that while
52 the device is suspended causes it to be woken up.
59 enable or diasble the device's suspend and resume callbacks to
74 of a device unless it is certain that all of the PM dependencies
[all …]
|
| /Documentation/driver-api/acpi/ |
| D | scan_handlers.rst | 12 During system initialization and ACPI-based device hot-add, the ACPI namespace
13 is scanned in search of device objects that generally represent various pieces
15 registered with the driver core for every device object in the ACPI namespace
17 layout (i.e. parent device objects in the namespace are represented by parent
19 acpi_device objects are referred to as "device nodes" in what follows, but they
20 should not be confused with struct device_node objects used by the Device Trees
23 During ACPI-based device hot-remove device nodes representing pieces of hardware
27 initialization of device nodes, such as retrieving common configuration
28 information from the device objects represented by them and populating them with
30 been registered. For example, if the given device node represents a PCI host
[all …]
|
| /Documentation/devicetree/bindings/usb/ |
| D | renesas,usbhs.txt | 6 - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device
7 - "renesas,usbhs-r8a7744" for r8a7744 (RZ/G1N) compatible device
8 - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device
9 - "renesas,usbhs-r8a77470" for r8a77470 (RZ/G1C) compatible device
10 - "renesas,usbhs-r8a774a1" for r8a774a1 (RZ/G2M) compatible device
11 - "renesas,usbhs-r8a774c0" for r8a774c0 (RZ/G2E) compatible device
12 - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
13 - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
14 - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
15 - "renesas,usbhs-r8a7793" for r8a7793 (R-Car M2-N) compatible device
[all …]
|
| /Documentation/vm/ |
| D | hmm.rst | 7 Provide infrastructure and helpers to integrate non-conventional memory (device
13 allowing a device to transparently access program addresses coherently with
15 for the device. This is becoming mandatory to simplify the use of advanced
20 related to using device specific memory allocators. In the second section, I
24 fifth section deals with how device memory is represented inside the kernel.
26 leveraging the device DMA engine.
30 Problems of using a device specific memory allocator
35 This creates a disconnect between memory allocated and managed by a device
39 i.e., one in which any application memory region can be used by a device
43 through a device specific API. This implies that all memory objects in a program
[all …]
|
| /Documentation/admin-guide/ |
| D | sysfs-rules.rst | 41 just simply a "device". Class-, bus-, physical, ... types are just
45 The properties of a device are:
50 at device creation and removal
51 - the unique key to the device at that point in time
52 - the kernel's path to the device directory without the leading
56 target and the target path must be used to access the device.
57 That way the devpath to the device matches the devpath of the
81 driver; copying the driver value in a child device context is a
86 - the files in the device directory or files below subdirectories
87 of the same device directory
[all …]
|
| /Documentation/hid/ |
| D | hid-transport.rst | 14 devices and register them with the HID bus. HID core then loads generic device
16 transport and device setup/management. HID core is responsible of
17 report-parsing, report interpretation and the user-space API. Device specifics
23 | Device #1 | | Device #i | | Device #j | | Device #k |
53 interest to HID device drivers. Transport drivers do not need to know the
56 1.1) Device Setup
59 I/O drivers normally provide hotplug detection or device enumeration APIs to the
60 transport drivers. Transport drivers use this to find any suitable HID device.
61 They allocate HID device objects and register them with HID core. Transport
67 device. Once a device is registered with HID core, the callbacks provided via
[all …]
|
12345678910>>...122