| /Documentation/driver-model/ |
| D | device.txt | 5 struct device {
12 struct device * parent;
32 void (*release)(struct device * dev);
37 g_list: Node in the global device list.
39 node: Node in device's parent's children list.
41 bus_list: Node in device's bus's devices list.
43 driver_list: Node in device's driver's devices list.
46 each interface that the device supports.
52 name: ASCII description of device.
55 bus_id: ASCII representation of device's bus position. This
[all …]
|
| D | interface.txt | 7 Device interfaces are the logical interfaces of device classes that correlate
8 directly to userspace interfaces, like device nodes.
10 Each device class may have multiple interfaces through which you can
11 access the same device. An input device may support the mouse interface,
14 device interface.
18 the class. The interface is responsible for determining whether the device
34 int (*add_device)(struct device *);
42 An interface must specify the device class it belongs to. It is added
46 Interfaces can be added to a device class at any time. Whenever it is
47 added, each device in the class is passed to the interface's
[all …]
|
| D | class.txt | 7 A device class describes a type of device, like an audio or network
8 device. The following device classes have been identified:
13 Each device class defines a set of semantics and a programming interface
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 *);
28 typedef void (*devclass_remove)(struct device *);
47 A typical device class definition would look like:
55 Each device class structure should be exported in a header file so it
[all …]
|
| D | binding.txt | 4 Driver binding is the process of associating a device with a device
7 devices and the drivers. With generic device and device driver
15 type in the system. When device_register is called for a device, it is
25 When a new device is added, the bus's list of drivers is iterated over
26 to find one that supports it. In order to determine that, the device
27 ID of the device must match one of the device IDs that the driver
31 a device against the IDs of a driver. The bus returns 1 if a match was
34 int match(struct device * dev, struct device_driver * drv);
36 If a match is found, the device's driver field is set to the driver
44 Upon the successful completion of probe, the device is registered with
[all …]
|
| D | porting.txt | 33 Step 0: Read include/linux/device.h for object and function definitions.
91 struct device represents a single device. It mainly contains metadata
92 describing the relationship the device has to other entities.
95 - Embed a struct device in the bus-specific device type.
100 struct device dev; /* Generic device interface */
104 It is recommended that the generic device not be the first item in
123 - Initialize the device on registration.
126 bus driver should initialize the generic device. The most important
129 The bus_id is an ASCII string that contains the device's address on
133 parent is the physical parent of the device. It is important that
[all …]
|
| D | driver.txt | 14 int (*probe) (struct device * dev);
15 int (*remove) (struct device * dev);
17 int (*suspend) (struct device * dev, pm_message_t state);
18 int (*resume) (struct device * dev);
29 device instance).
61 The most common example of this are device ID structures. A driver
62 typically defines an array of device IDs that it supports. The format
63 of these structures and the semantics for comparing device IDs are
110 used by the device model core or the bus driver.
135 int (*callback)(struct device * dev, void * data));
[all …]
|
| /Documentation/s390/ |
| D | driver-model.txt | 23 In this example, device 0815 is accessed via subchannel 0 in subchannel set 0,
24 device 4711 via subchannel 1 in subchannel set 0, and subchannel 2 is a non-I/O
29 if they are displaced by another ccw device becoming operational on their
33 You should address a ccw device via its bus id (e.g. 0.0.4711); the device can
40 devtype: The device type / model, if applicable.
42 availability: Can be 'good' or 'boxed'; 'no path' or 'no device' for
45 online: An interface to set the device online and offline.
46 In the special case of the device being disconnected (see the
48 the device.
50 The device drivers can add entries to export per-device data and interfaces.
[all …]
|
| D | TAPE | 1 Channel attached Tape device driver
8 The LINUX for zSeries tape device driver manages channel attached tape drives
15 The device driver supports a maximum of 128 tape devices.
16 No official LINUX device major number is assigned to the zSeries tape device
19 Typically it will get major number 254 for both the character device front-end
20 and the block device front-end.
22 The tape device driver needs no kernel parameters. All supported devices
24 The devices detected are ordered by their subchannel numbers. The device with
25 the lowest subchannel number becomes device 0, the next one will be device 1
29 Tape character device front-end
[all …]
|
| D | cds.txt | 13 This document describes the common device support routines for Linux/390.
15 I/O access method. This gives relief to the device drivers as they don't
19 either every single device driver needs to implement the hardware I/O
22 every single device driver would have to provide itself.
28 In order to build common device support for ESA/390 I/O interfaces, a
32 The common device support layer comprises the I/O support routines defined
33 below. Some of them implement common Linux device driver interfaces, while
50 * The channel device layer is gone.
70 terminate the current I/O request processed on the device.
75 routine determines the interrupt status and calls the device specific
[all …]
|
| D | CommonIO | 9 Enable logging of debug information in case of ccw device timeouts.
12 {<device> | <range of devices>} |
13 {!<device> | !<range of devices>}
16 and device sensing will be done on any of those devices. The subchannel to
17 which the device in question is attached will be treated as if no device was
20 An ignored device can be un-ignored later; see the "/proc entries"-section for
24 device numbers (0xabcd or abcd, for 2.4 backward compatibility). If you
25 give a device number 0xabcd, it will be interpreted as 0.0.abcd.
28 The '!' operator will cause the I/O-layer to _not_ ignore a device.
33 will ignore all devices ranging from 0.0.0023 to 0.0.0042 and the device
[all …]
|
| /Documentation/device-mapper/ |
| D | zero.txt | 4 Device-Mapper's "zero" target provides a block-device that always returns
6 /dev/zero, but as a block-device instead of a character-device.
11 conjunction with dm-snapshot. A sparse device reports a device-size larger
12 than the amount of actual storage space available for that device. A user can
13 write data anywhere within the sparse device and read it back like a normal
14 device. Reads to previously unwritten areas will return a zero'd buffer. When
16 device is deactivated. This can be very useful for testing device and
19 To create a sparse device, start by creating a dm-zero device that's the
20 desired size of the sparse device. For this example, we'll assume a 10TB
21 sparse device.
[all …]
|
| D | snapshot.txt | 6 *) To create snapshots of any block device i.e. mountable, saved states of
7 the block device which are also writable without interfering with the
9 *) To create device "forks", i.e. multiple different versions of the
14 uses a separate copy-on-write (COW) block device for storage.
22 Reads will be mapped directly to the backing device. For each write, the
23 original data will be saved in the <COW device> of each snapshot to keep
24 its visible content unchanged, at least until the <COW device> fills up.
27 *) snapshot <origin> <COW device> <persistent?> <chunksize>
29 A snapshot of the <origin> block device is created. Changed chunks of
30 <chunksize> sectors will be stored on the <COW device>. Writes will
[all …]
|
| D | dm-uevent.txt | 1 The device-mapper uevent code adds the capability to device-mapper to create
2 and send kobject uevents (uevents). Previously device-mapper events were only
5 the event avoiding the need to query the state of the device-mapper device after
8 There are two functions currently for device-mapper events. The first function
23 Value: Name of device-mapper target that generated the event.
36 Description: A sequence number for this specific device-mapper device.
42 Description: Major and minor number of the path device pertaining to this
55 Description: Name of the device-mapper device.
61 Description: UUID of the device-mapper device.
|
| /Documentation/thermal/ |
| D | sysfs-api.txt | 23 as cooling device attributes to the user space.
33 1.1 thermal zone device interface
37 This interface function adds a new thermal zone device (sensor) to
43 devdata: device private data
44 ops: thermal zone device call-backs.
45 .bind: bind the thermal zone device with a thermal cooling device.
46 .unbind: unbind the thermal zone device with a thermal cooling device.
59 This interface function removes the thermal zone device.
63 1.2 thermal cooling device interface
67 This interface function adds a new thermal cooling device (fan/processor/...) to
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-bus-usb | 6 Each USB device directory will contain a file named
8 the device must be idle before it will be autosuspended.
9 0 means the device will be autosuspended as soon as
10 possible. Negative values will prevent the device from
12 will resume the device if it is already suspended.
22 Each USB device directory will contain a file named
24 the device, one of "on", "auto", or "suspend".
26 "on" means that the device is not allowed to autosuspend,
28 be honored. "auto" means the device will autosuspend
30 capabilities of its driver. "suspend" means the device
[all …]
|
| D | sysfs-class-pktcdvd | 15 add (0200) Write a block device id (major:minor)
16 to create a new pktcdvd device and map
17 it to the block device.
19 remove (0200) Write the pktcdvd device id (major:minor)
20 to it to remove the pktcdvd device.
22 device_map (0444) Shows the device mapping in format:
38 pktcdvd device statistic values, like
53 device has processed enough bio's
64 # create a new pktcdvd device mapped to /dev/hdc
67 # assuming device pktcdvd0 was created, look at stat's
[all …]
|
| /Documentation/ |
| D | devices.txt | 4 Maintained by Torben Mathiasen <device@lanana.org>
9 device numbers and /dev directory nodes for the Linux operating
13 http://www.lanana.org/docs/device-list/ or
14 ftp://ftp.kernel.org/pub/linux/docs/device-list/. This version may be
47 appropriate device information. Also, if you have additional
54 correct address... <device@lanana.org>. I receive hundreds of email
58 saying just "device number request" in the subject.
60 Second, please include a description of the device *in the same format
63 device and avoid conflicts.
75 device names and numbers in any way public, at least to the point
[all …]
|
| D | sysfs-rules.txt | 40 just simply a "device". Class-, bus-, physical, ... types are just
44 The properties of a device are:
47 at device creation and removal
48 - the unique key to the device at that point in time
49 - the kernel's path to the device directory without the leading
53 target and the target path must be used to access the device.
54 That way the devpath to the device matches the devpath of the
75 driver; copying the driver value in a child device context is a
79 - the files in the device directory or files below subdirectories
80 of the same device directory
[all …]
|
| /Documentation/PCI/ |
| D | MSI-HOWTO.txt | 18 when this text talks about enabling or disabling MSI on a "device
19 function," it is referring to one specific PCI device and function and
20 not to all functions on a PCI device (unless the PCI device has only
29 required feature for PCI Express devices. MSI enables a device function
36 A PCI device that supports MSI must also support pin IRQ assertion
40 the device function's MSI/MSI-X capability structure during device
43 An MSI capable device function indicates MSI support by implementing
45 device function may implement both the MSI capability structure and
52 indicates the MSI capability supported by the device. The Message
55 service, the device function writes the content of the Message Data
[all …]
|
| D | pci.txt | 13 PCI device drivers.
33 a new device, the driver with a matching "description" will be notified.
42 Once the driver knows about a PCI device and takes ownership, the
45 Enable the device
49 Access device configuration space (if needed)
54 When done using the device, and perhaps the module needs to be unloaded,
56 Disable the device from generating IRQs
62 Disable the device
77 PCI device drivers call pci_register_driver() during their
83 id_table Pointer to table of device ID's the driver is
[all …]
|
| /Documentation/i2c/busses/ |
| D | i2c-viapro | 43 device 1106:3050 (VT82C596A function 3)
44 device 1106:3051 (VT82C596B function 3)
45 device 1106:3057 (VT82C686 function 4)
46 device 1106:3074 (VT8233)
47 device 1106:3147 (VT8233A)
48 device 1106:8235 (VT8231 function 4)
49 device 1106:3177 (VT8235)
50 device 1106:3227 (VT8237R)
51 device 1106:3337 (VT8237A)
52 device 1106:3372 (VT8237S)
[all …]
|
| /Documentation/video4linux/ |
| D | v4l2-framework.txt | 12 hardware: most devices have multiple ICs, export multiple device nodes in
23 creating V4L device nodes and video_buf for handling the video buffers
26 This meant that all drivers had to do the setup of device instances and
43 1) A struct for each device instance containing the device state.
47 3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX, /dev/radioX and
48 /dev/vtxX) and keeping track of device-node specific data.
54 device instances
56 +-sub-device instances
58 \-V4L2 device nodes
67 struct for the device instance data, a v4l2_subdev struct to refer to
[all …]
|
| D | README.ivtv | 5 This is a v4l2 device driver for the Conexant cx23415/6 MPEG encoder/decoder.
39 device) (this framebuffer is not yet part of the kernel. In the meantime it
63 support the framebuffer device /dev/fbx for OSD.
65 The radio0 device may or may not be present, depending on whether the
83 /dev/video0 is listed as the 'base' encoding capture device so we have:
85 /dev/video0 is the encoding capture device for the first card (card 0)
86 /dev/video1 is the encoding capture device for the second card (card 1)
87 /dev/video2 is the encoding capture device for the third card (card 2)
91 the card number to the base device number'. If you have other capture
94 whatever). Otherwise the device numbers can get confusing. The ivtv
[all …]
|
| /Documentation/usb/ |
| D | persist.txt | 1 USB device persistence during system suspend
16 If a USB device's power session is interrupted then the system is
17 required to behave as though the device has been unplugged. It's a
20 device is still attached or perhaps it was removed and a different
21 device plugged into the port. The system must assume the worst.
36 devices. The effect is exactly the same as if the device really had
38 filesystem on the device, you're out of luck -- everything in that
40 root filesystem was located on the device, since your system will
60 device before suspending. If the root filesystem is on a USB device,
69 around these issues by allowing the core USB device data structures to
[all …]
|
| D | power-management.txt | 24 device is turned off while the system as a whole remains running, we
40 When a device has been suspended, it generally doesn't resume until
49 device is enabled for remote wakeup and it is suspended, it may resume
52 pressed, or a suspended USB hub resuming when a device is plugged in.
55 When is a USB device idle?
58 A device is idle whenever the kernel thinks it's not busy doing
60 exact definition depends on the device's driver; drivers are allowed
61 to declare that a device isn't idle even when there's no actual
64 In addition, a device isn't considered idle so long as a program keeps
67 If a USB device has no driver, its usbfs file isn't open, and it isn't
[all …]
|