Searched full:device (Results 1 – 25 of 3118) sorted by relevance
12345678910>>...125
| /Documentation/ABI/testing/ |
| D | sysfs-driver-habanalabs | 1 What: /sys/class/accel/accel<n>/device/armcp_kernel_ver
5 Description: Version of the Linux kernel running on the device's CPU.
9 What: /sys/class/accel/accel<n>/device/armcp_ver
13 Description: Version of the application running on the device's CPU
17 What: /sys/class/accel/accel<n>/device/clk_max_freq_mhz
22 The device clock might be set to lower value than the maximum.
24 frequency value of the device clock. This property is valid
27 What: /sys/class/accel/accel<n>/device/clk_cur_freq_mhz
31 Description: Displays the current frequency, in MHz, of the device clock.
34 What: /sys/class/accel/accel<n>/device/cpld_ver
[all …]
|
| D | sysfs-bus-cdx | 18 Vendor ID for this CDX device, in hexadecimal. Vendor ID is
19 16 bit identifier which is specific to the device manufacturer.
20 Combination of Vendor ID and Device ID identifies a device.
22 What: /sys/bus/cdx/devices/.../device
26 Device ID for this CDX device, in hexadecimal. Device ID is
27 16 bit identifier to identify a device type within the range
28 of a device manufacturer.
29 Combination of Vendor ID and Device ID identifies a device.
35 Subsystem Vendor ID for this CDX device, in hexadecimal.
43 Subsystem Device ID for this CDX device, in hexadecimal
[all …]
|
| 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
52 device of that type. Userspace application should check
54 creating mediated device of this type.
[all …]
|
| D | sysfs-class-devlink | 5 Provide a place in sysfs for the device link objects in the
6 kernel at any given time. The name of a device link directory,
8 where <supplier> is the supplier bus:device name and <consumer>
9 is the consumer bus:device name.
15 This file indicates if the device link will ever be
25 'consumer unbind' means the device link will be removed when
26 the consumer's driver is unbound from the consumer device.
28 'supplier unbind' means the device link will be removed when
29 the supplier's driver is unbound from the supplier device.
31 'never' means the device link will not be automatically removed
[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-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/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/networking/devlink/ |
| D | devlink-params.rst | 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.
34 - written to the device's non-volatile memory. A hard reset is required
42 request a reload of the device driver.
60 - Enable Single Root I/O Virtualization (SRIOV) in the device.
65 platform has support enabled. The device will create the same number
69 - Provides the maximum number of MSI-X interrupts that a device can
71 device.
75 device to initialize. Value is the same across all physical functions
[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 * The per-device PM QoS framework provides the API to manage the
12 per-device latency constraints and PM QoS flags.
65 The infrastructure exposes one device node, /dev/cpu_dma_latency, for the CPU
75 As long as the device node is held open that process has a registered
79 the open device node. Alternatively, it can write a hex string for the value
83 To remove the user mode request for a target value simply close the device
87 2. PM QoS per-device latency and flags framework
90 For each device, there are three lists of PM QoS requests. Two of them are
98 values. One device PM QoS flag is defined currently: PM_QOS_FLAG_NO_POWER_OFF.
106 int dev_pm_qos_add_request(device, handle, type, value):
[all …]
|
| D | pci.rst | 12 devices. For general description of the kernel's interfaces related to device
19 2. PCI Subsystem and Device Power Management
20 3. PCI Device Drivers and Power Management
34 Usually, a device is put into a low-power state when it is underutilized or
35 completely inactive. However, when it is necessary to use the device once
37 state). This may happen when there are some data for the device to handle or
38 as a result of an external event requiring the device to be active, which may
39 be signaled by the device itself.
41 PCI devices may be put into low-power states in two ways, by using the device
45 in what follows, the device power state is changed as a result of writing a
[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 | 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
10 Device drivers are statically allocated structures. Though there may
13 device instance).
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
96 used by the device model core or the bus driver.
121 int (*callback)(struct device *dev, void *data));
126 node access, and does proper reference counting on each device as it
149 int (*probe) (struct device *dev);
[all …]
|
| /Documentation/arch/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/net/ |
| D | microchip,lan95xx.yaml | 13 Device tree properties for hard wired SMSC95xx compatible USB Ethernet
23 - usb424,9500 # SMSC9500 USB Ethernet Device
24 - usb424,9505 # SMSC9505 USB Ethernet Device
25 - usb424,9530 # SMSC LAN9530 USB Ethernet Device
26 - usb424,9730 # SMSC LAN9730 USB Ethernet Device
27 - usb424,9900 # SMSC9500 USB Ethernet Device (SAL10)
28 - usb424,9901 # SMSC9505 USB Ethernet Device (SAL10)
29 - usb424,9902 # SMSC9500A USB Ethernet Device (SAL10)
30 - usb424,9903 # SMSC9505A USB Ethernet Device (SAL10)
31 - usb424,9904 # SMSC9512/9514 USB Hub & Ethernet Device (SAL10)
[all …]
|
| /Documentation/PCI/endpoint/ |
| D | pci-endpoint-cfs.rst | 26 functions. Every EPC device present in the system will have an entry in
35 Creating EPF Device
44 ... <EPF Device 11>/
45 ... <EPF Device 21>/
46 ... <EPF Device 31>/
48 ... <EPF Device 12>/
49 ... <EPF Device 22>/
51 In order to create a <EPF device> of the type probed by <EPF Driver>, the
54 Every <EPF device> directory consists of the following entries that can be
56 (These entries are created by the framework when any new <EPF Device> is
[all …]
|
| /Documentation/driver-api/ |
| D | device_link.rst | 4 Device links
8 that are borne out of a parent/child relationship within the device
13 Sometimes there is a need to represent device dependencies beyond the
18 dependencies, i.e. that one device must be bound to a driver before
21 Often these two dependency types come together, so a device depends on
25 Device links allow representation of such dependencies in the driver core.
27 In its standard or *managed* form, a device link combines *both* dependency
29 "supplier" device and its "consumer" devices, and it guarantees driver
35 suspend/resume and shutdown ordering is needed, the device link may
40 ``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/mm/ |
| D | hmm.rst | 5 Provide infrastructure and helpers to integrate non-conventional memory (device
11 allowing a device to transparently access program addresses coherently with
13 for the device. This is becoming mandatory to simplify the use of advanced
18 related to using device specific memory allocators. In the second section, I
22 fifth section deals with how device memory is represented inside the kernel.
24 leveraging the device DMA engine.
28 Problems of using a device specific memory allocator
33 This creates a disconnect between memory allocated and managed by a device
37 i.e., one in which any application memory region can be used by a device
41 through a device specific API. This implies that all memory objects in a program
[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/virt/hyperv/ |
| D | vpci.rst | 8 Guest device drivers can interact directly with the hardware
10 provides higher bandwidth access to the device with lower
12 hypervisor. The device should appear to the guest just as it
14 to the Linux device drivers for the device.
16 Hyper-V terminology for vPCI devices is "Discrete Device
20 …dows-server/virtualization/hyper-v/plan/plan-for-deploying-devices-using-discrete-device-assignment
24 and produces the same benefits by allowing a guest device
33 Device Presentation
35 Hyper-V provides full PCI functionality for a vPCI device when
36 it is operating, so the Linux device driver for the device can
[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 for
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>>...125