Searched +full:on +full:- +full:device (Results 1 – 25 of 1030) sorted by relevance
12345678910>>...42
| /Documentation/driver-api/ |
| D | device_link.rst | 4 Device links
8 that are borne out of a parent/child relationship within the device
10 are ordered based on this relationship, i.e. children are always suspended
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
30 presence on the supplier. The consumer devices are not probed before the
[all …]
|
| D | slimbus.rst | 9 ----------------
12 configuration, and is a 2-wire multi-drop implementation (clock, and data).
15 (System-on-Chip) and peripheral components (typically codec). SLIMbus uses
16 Time-Division-Multiplexing to accommodate multiple data channels, and
21 reading/writing device specific values), or multicast (e.g. data channel
24 A data channel is used for data-transfer between 2 SLIMbus devices. Data
25 channel uses dedicated ports on the device.
28 ---------------------
29 SLIMbus specification has different types of device classifications based on
31 A manager device is responsible for enumeration, configuration, and dynamic
[all …]
|
| D | device-io.rst | 10 Bus-Independent Device Accesses
20 and devices, allowing device drivers to be written independently of bus
26 Getting Access to the Device
27 ----------------------------
31 memory, but as accesses to a device. Some architectures define devices
40 the device will be returned to you.
42 After you've finished using the device (say, in your module's exit
48 Accessing the device
49 --------------------
52 memory-mapped registers on the device. Linux provides interfaces to read
[all …]
|
| D | dpll.rst | 1 .. SPDX-License-Identifier: GPL-2.0
10 PLL - Phase Locked Loop is an electronic circuit which syntonizes clock
11 signal of a device with an external clock signal. Effectively enabling
12 device to run on the same clock signal beat as provided on a PLL input.
14 DPLL - Digital Phase Locked Loop is an integrated circuit which in
16 and may have digital divider in the loop. As a result, the frequency on
29 Device object
32 Single dpll device object means single Digital PLL circuit and bunch of
38 Changing the configuration of dpll device is done with `do` request of
40 A device handle is ``DPLL_A_ID``, it shall be provided to get or set
[all …]
|
| /Documentation/arch/s390/ |
| D | qeth.rst | 9 -------
11 To generate the events the device must be assigned a role of either
13 "z/VM Connectivity, SC24-6174".
15 When run on an OSA or HiperSockets Bridge Capable Port hardware, and the state
16 of some configured Bridge Port device on the channel changes, a udev
17 event with ACTION=CHANGE is emitted on behalf of the corresponding
18 ccwgroup device. The event has the following attributes:
21 indicates that the Bridge Port device changed
30 When run on HiperSockets Bridge Capable Port hardware with host address
32 It is emitted on behalf of the corresponding ccwgroup device when a host
[all …]
|
| /Documentation/driver-api/i3c/ |
| D | protocol.rst | 1 .. SPDX-License-Identifier: GPL-2.0
10 This chapter will focus on aspects that matter to software developers. For
11 everything hardware related (like how things are transmitted on the bus, how
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.
31 well, but let's focus on I3C devices for now.
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
36 transactions or deciding who is allowed to talk on the bus (slave generated
[all …]
|
| /Documentation/hid/ |
| D | hid-transport.rst | 8 Bluetooth, I2C and user-space I/O drivers.
14 devices and register them with the HID bus. HID core then loads generic device
15 drivers on top of it. The transport drivers are responsible for raw data
16 transport and device setup/management. HID core is responsible for
17 report-parsing, report interpretation and the user-space API. Device specifics
18 and quirks are handled by all layers depending on the quirk.
22 +-----------+ +-----------+ +-----------+ +-----------+
23 | Device #1 | | Device #i | | Device #j | | Device #k |
24 +-----------+ +-----------+ +-----------+ +-----------+
26 +------------+ +------------+
[all …]
|
| D | uhid.rst | 2 UHID - User-space I/O driver support for HID subsystem
5 UHID allows user-space to implement HID transport drivers. Please see
6 hid-transport.rst for an introduction into HID transport drivers. This document
7 relies heavily on the definitions declared there.
9 With UHID, a user-space transport driver can create kernel hid-devices for each
10 device connected to the user-space controlled bus. The UHID API defines the I/O
11 events provided from the kernel to user-space and vice versa.
13 There is an example user-space application in ./samples/uhid/uhid-example.c
16 ------------
18 UHID is accessed through a character misc-device. The minor number is allocated
[all …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | verity.rst | 2 dm-verity
5 Device-Mapper's "verity" target provides transparent integrity checking of
7 This target is read-only.
21 This is the type of the on-disk hash format.
32 This is the device containing data, the integrity of which needs to be
33 checked. It may be specified as a path, like /dev/sdaX, or a device number,
37 This is the device that supplies the hash tree data. It may be
38 specified similarly to the device path and may be the same device. If the
39 same device is used, the hash_start should be outside the configured
40 dm-verity device.
[all …]
|
| /Documentation/virt/hyperv/ |
| D | vpci.rst | 1 .. SPDX-License-Identifier: GPL-2.0
3 PCI pass-thru devices
5 In a Hyper-V guest VM, PCI pass-thru devices (also called
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
13 would when running on bare metal, so no changes are required
14 to the Linux device drivers for the device.
16 Hyper-V terminology for vPCI devices is "Discrete Device
17 Assignment" (DDA). Public documentation for Hyper-V DDA is
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-bus-cdx | 5 Writing y/1/on to this file will cause rescan of the bus
6 and devices on the CDX bus. Any new devices are scanned and
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.
[all …]
|
| D | sysfs-driver-w1_therm | 6 Values shall be space separated and in the device range
7 (typical -55 degC to 125 degC), if not values will be trimmed
8 to device min/max capabilities. Values are integer as they are
9 stored in a 8bit register in the device. Lowest value is
11 master level, refer to Documentation/w1/w1-generic.rst for
14 w1_term device
22 device data to its embedded EEPROM, either restore data
23 embedded in device EEPROM. Be aware that devices support
26 * 'save': save device RAM to EEPROM
27 * 'restore': restore EEPROM data in device RAM
[all …]
|
| D | sysfs-platform-chipidea-usb-otg | 6 Set a_bus_req(A-device bus request) input to be 1 if
7 the application running on the A-device wants to use the bus,
11 from the B-device, the A-device should decide to resume the bus.
15 Reading: returns 1 if the application running on the A-device
23 The a_bus_drop(A-device bus drop) input is 1 when the
24 application running on the A-device wants to power down
31 A-device, otherwise 0.
38 The b_bus_req(B-device bus request) input is 1 during the time
39 that the application running on the B-device wants to use the
45 Reading: returns if the application running on the B device
[all …]
|
| D | sysfs-class-rnbd-client | 1 What: /sys/class/rnbd-client
5 Description: Provide information about RNBD-client.
6 All sysfs files that are not read-only provide the usage information on read:
10 # cat /sys/class/rnbd-client/ctl/map_device
13 > [path=<[srcaddr,]dstaddr>] device_path=<full path on remote side>
18 What: /sys/class/rnbd-client/ctl/map_device
26 device_path=<full path on remote side>
33 a given session on the client and on the server.
34 I.e. "clt_hostname-srv_hostname" could be a natural choice.
63 Path to the block device on the server side. Path is specified
[all …]
|
| /Documentation/firmware-guide/acpi/ |
| D | non-d0-probe.rst | 1 .. SPDX-License-Identifier: GPL-2.0
11 entire system bootup if powering on these devices has adverse side effects,
12 beyond just powering on the said device.
17 The _DSC (Device State for Configuration) object that evaluates to an integer
18 may be used to tell Linux the highest allowed D state for a device during
20 bus driver normally sets the device in D0 state for probe.
22 The downside of using _DSC is that as the device is not powered on, even if
23 there's a problem with the device, the driver likely probes just fine but the
24 first user will find out the device doesn't work, instead of a failure at probe
28 ---
[all …]
|
| /Documentation/usb/ |
| D | chipidea.rst | 6 -----------------------------------
12 -------------------------
29 otg-rev = <0x0200>;
30 adp-disable;
33 -------------------
41 The A-device (with micro A plug inserted) should enumerate B-device.
45 On B-device::
49 B-device should take host role and enumerate A-device.
51 4) A-device switch back to host.
53 On B-device::
[all …]
|
| /Documentation/networking/devlink/ |
| 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.
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``
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | dev-subdev.rst | 1 .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
6 Sub-device Interface
13 components as software blocks called sub-devices.
15 V4L2 sub-devices are usually kernel-only objects. If the V4L2 driver
16 implements the media device API, they will automatically inherit from
17 media entities. Applications will be able to enumerate the sub-devices
21 In addition to make sub-devices discoverable, drivers can also choose to
23 sub-device driver and the V4L2 device driver support this, sub-devices
24 will feature a character device node on which ioctls can be called to
26 - query, read and write sub-devices controls
[all …]
|
| /Documentation/i2c/busses/ |
| D | i2c-viapro.rst | 2 Kernel driver i2c-viapro
13 Datasheet: available on request from VIA
16 Datasheet: available on request and under NDA from VIA
19 Datasheet: available on request and under NDA from VIA
22 Datasheet: available on http://linux.via.com.tw
25 Datasheet: available on http://linux.via.com.tw
28 Datasheet: available on http://linux.via.com.tw
31 - Kyösti Mälkki <kmalkki@cc.hut.fi>,
32 - Mark D. Studebaker <mdsxyz123@yahoo.com>,
33 - Jean Delvare <jdelvare@suse.de>
[all …]
|
| /Documentation/admin-guide/ |
| D | thunderbolt.rst | 1 .. SPDX-License-Identifier: GPL-2.0
6 USB4 is the public specification based on Thunderbolt 3 protocol with
8 manager is an entity running on the host router (host controller)
12 and early USB4 capable systems. Apple systems on the other hand use
17 connection manager implementation is to be used. To be on the safe side the
25 -----------------------------------
27 should be a userspace tool that handles all the low-level details, keeps
31 found in ``Documentation/ABI/testing/sysfs-bus-thunderbolt``.
33 Those users who just want to connect any device without any sort of
35 ``/etc/udev/rules.d/99-local.rules``::
[all …]
|
| D | devices.txt | 1 0 Unnamed devices (e.g. non-device mounts)
2 0 = reserved as null device number
7 2 = /dev/kmem OBSOLETE - replaced by /proc/kcore
8 3 = /dev/null Null device
11 6 = /dev/core OBSOLETE - replaced by /proc/kcore
12 7 = /dev/full Returns ENOSPC on write
18 12 = /dev/oldmem OBSOLETE - replaced by /proc/vmcore
31 2 char Pseudo-TTY masters
37 Pseudo-tty's are named as follows:
40 the 1st through 16th series of 16 pseudo-ttys each, and
[all …]
|
| D | serial-console.rst | 7 kernel - by default it is not compiled in. For PC style serial ports
10 :menuselection:`Character devices --> Serial drivers --> 8250/16550 and compatible serial support -…
15 define a new kernel command line option to select which device(s) to
20 console=device,options
22 device: tty0 for the foreground virtual console
26 ttyUSB0 for the first USB serial device
28 options: depend on the driver. For the serial port this
35 You can specify multiple console= options on the kernel command line.
37 The behavior is well defined when each device type is mentioned only once.
38 In this case, the output will appear on all requested consoles. And
[all …]
|
| /Documentation/i2c/ |
| D | instantiating-devices.rst | 6 level. Instead, the software must know which devices are connected on each
9 several ways to achieve this, depending on the context and requirements.
13 --------------------------------------------
16 for many embedded systems. On such systems, each I2C bus has a number which
17 is known in advance. It is thus possible to pre-declare the I2C devices
18 which live on this bus.
20 This information is provided to the kernel in a different way on different
21 architectures: device tree, ACPI or board files.
24 instantiated automatically by i2c-core. The devices will be automatically
25 unbound and destroyed when the I2C bus they sit on goes away (if ever).
[all …]
|
| /Documentation/networking/ |
| D | switchdev.rst | 1 .. SPDX-License-Identifier: GPL-2.0
6 Ethernet switch device driver model (switchdev)
11 Copyright |copy| 2014-2015 Scott Feldman <sfeldma@gmail.com>
14 The Ethernet switch device driver model (switchdev) is an in-kernel driver
19 an example setup using a data-center-class switch ASIC chip. Other setups
20 with SR-IOV or soft switches, such as OVS, are possible.
25 User-space tools
28 +-------------------------------------------------------------------+
31 +--------------+-------------------------------+
35 +----------------------------------------------+
[all …]
|
| /Documentation/PCI/ |
| D | pci-error-recovery.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 :Authors: - Linas Vepstas <linasvepstas@gmail.com>
9 - Richard Lary <rlary@us.ibm.com>
10 - Mike Mason <mmlnx@us.ibm.com>
14 PCI errors on the bus, such as parity errors on the data and address
16 chipsets are able to deal with these errors; these include PCI-E chipsets,
17 and the PCI-host bridges found on IBM Power4, Power5 and Power6-based
18 pSeries boxes. A typical action taken is to disconnect the affected device,
22 offered, so that the affected PCI device(s) are reset and put back
24 between the affected device drivers and the PCI controller chip.
[all …]
|
12345678910>>...42