| /linux-4.4.14/Documentation/virtual/kvm/arm/ |
| D | vgic-mapped-irqs.txt | 4 The KVM/ARM code implements software support for the ARM Generic
6 allowing software to inject virtual interrupts to a VM, which the guest
7 OS sees as regular interrupts. The code is famously known as the VGIC.
10 interrupts from real physical devices. One example could be the
12 lets a guest OS program the hardware device directly to raise an
13 interrupt at some point in time. When such an interrupt is raised, the
14 host OS initially handles the interrupt and must somehow signal this
15 event as a virtual interrupt to the guest. Another example could be a
16 passthrough device, where the physical interrupts are initially handled
17 by the host, but the device driver for the device lives in the guest OS
[all …]
|
| /linux-4.4.14/Documentation/trace/ |
| D | ring-buffer-design.txt | 7 (dual licensed under the GPL v2)
17 tail - where new writes happen in the ring buffer.
19 head - where new reads happen in the ring buffer.
21 producer - the task that writes into the ring buffer (same as writer)
25 consumer - the task that reads from the buffer (same as reader)
29 reader_page - A page outside the ring buffer used solely (for the most part)
30 by the reader.
32 head_page - a pointer to the page that the reader will use next
34 tail_page - a pointer to the page that will be written to next
36 commit_page - a pointer to the page with the last finished non-nested write.
[all …]
|
| D | ftrace-design.txt | 8 Here we will cover the architecture pieces that the common function tracing
13 want more explanation of a feature in terms of common code, review the common
17 their kernel should make it all the way to dynamic ftrace support.
31 You will need to implement the mcount and the ftrace_stub functions.
38 We'll make the assumption below that the symbol is "mcount" just to keep things
39 nice and simple in the examples.
41 Keep in mind that the ABI that is in effect inside of the mcount function is
45 is a major issue at this point, especially in relation to the location of the
47 how glibc has implemented the mcount function for your architecture. It might
50 The mcount function should check the function pointer ftrace_trace_function
[all …]
|
| /linux-4.4.14/Documentation/locking/ |
| D | rt-mutex-design.txt | 3 # Licensed under the GNU Free Documentation License, Version 1.2
9 This document tries to describe the design of the rtmutex.c implementation.
10 It doesn't describe the reasons why rtmutex.c exists. For that please see
12 that happen without this code, but that is in the concept to understand
13 what the code actually is doing.
15 The goal of this document is to help others understand the priority
16 inheritance (PI) algorithm that is used, as well as reasons for the
17 decisions that were made to implement PI in the manner that was done.
25 most of the time it can't be helped. Anytime a high priority process wants
27 the high priority process must wait until the lower priority process is done
[all …]
|
| /linux-4.4.14/Documentation/input/ |
| D | multi-touch-protocol.txt | 9 In order to utilize the full power of the new multi-touch and multi-user
11 objects in direct contact with the device surface, is needed. This
12 document describes the multi-touch (MT) protocol which allows kernel
15 The protocol is divided into two types, depending on the capabilities of the
16 hardware. For devices handling anonymous contacts (type A), the protocol
17 describes how to send the raw data for all contacts to the receiver. For
18 devices capable of tracking identifiable contacts (type B), the protocol
26 events. Only the ABS_MT events are recognized as part of a contact
28 applications, the MT protocol can be implemented on top of the ST protocol
32 input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT
[all …]
|
| D | atarikbd.txt | 15 The ikbd communicates with the main processor over a high speed bi-directional
17 different applications of the keyboard, joysticks, or mouse. Limited use of
18 the controller is possible in applications in which only a unidirectional
19 communications medium is available by carefully designing the default modes.
25 closure) codes start at 1, and are defined in Appendix A. For example, the
26 ISO key position in the scan code table should exist even if no keyswitch
28 is obtained by ORing 0x80 with the make code.
41 and the RETurn key are also distinct.
51 within the ikbd, or by converting mouse motion into keyboard cursor control
53 The mouse buttons can be treated as part of the mouse or as additional
[all …]
|
| D | joystick.txt | 9 under the terms of the GNU General Public License as published by the Free
10 Software Foundation; either version 2 of the License, or (at your option)
13 This program is distributed in the hope that it will be useful, but
14 WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
15 or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
18 You should have received a copy of the GNU General Public License along
19 with this program; if not, write to the Free Software Foundation, Inc., 59
22 Should you need to contact me, the author, you can do so either by e-mail
26 For your convenience, the GNU General Public License version 2 is included
27 in the package: See the file COPYING.
[all …]
|
| D | userio.txt | 8 This module is intended to try to make the lives of input driver developers
9 easier by allowing them to test various serio devices (mainly the various
10 touchpads found on laptops) without having to have the physical device in front
12 to directly interact with the kernel's serio driver and control a virtual serio
17 In order to interact with the userio kernel module, one simply opens the
18 /dev/userio character device in their applications. Commands are sent to the
19 kernel module by writing to the device, and any data received from the serio
20 driver is read as-is from the /dev/userio device. All of the structures and
21 macros you need to interact with the device are defined in <linux/userio.h> and
33 "type" describes the type of command that is being sent. This can be any one
[all …]
|
| D | gameport-programming.txt | 7 If the gameport doesn't provide more than the inb()/outb() functionality,
8 the code needed to register it with the joystick drivers is simple:
16 gameport generic code will take care of the rest.
19 choose which one to program the hardware to, starting from the more exotic
20 addresses is preferred, because the likelihood of clashing with the standard
24 0x218 would be the address of first choice.
27 space (is above 0x1000), use that one, and don't map the ISA mirror.
29 Also, always request_region() on the whole io space occupied by the
30 gameport. Although only one ioport is really used, the gameport usually
31 occupies from one to sixteen addresses in the io space.
[all …]
|
| /linux-4.4.14/Documentation/scsi/ |
| D | st.txt | 1 This file contains brief information about the SCSI tape driver.
12 one of the following three methods:
14 1. Each user can specify the tape parameters he/she wants to use
17 in a multiuser environment the next user finds the tape parameters in
18 state the previous user left them.
21 parameters, like block size and density using the MTSETDRVBUFFER ioctl.
23 new tape is loaded into the drive or if writing begins at the
24 beginning of the tape. The second method is applicable if the tape
25 drive performs auto-detection of the tape format well (like some
27 continued using existing format, and the default format is used if
[all …]
|
| D | scsi_fc_transport.txt | 13 This file documents the features and components of the SCSI FC Transport.
14 It also provides documents the API between the transport and FC LLDDs.
36 port to appear on as multiple communication ports. Using the N_Port Id
39 separate port to other endpoints on the fabric, even though it shares one
40 physical link to the switch for communication. Each N_Port_ID can have a
41 unique view of the fabric based on fabric zoning and array lun-masking
42 (just like a normal non-NPIV adapter). Using the Virtual Fabric (VF)
43 mechanism, adding a fabric header to each frame allows the port to
44 interact with the Fabric Port to join multiple fabrics. The port will
47 used together with VF so that the port can obtain multiple N_Port_IDs
[all …]
|
| D | 53c700.txt | 4 This driver supports the 53c700 and 53c700-66 chips. It also supports
5 the 53c710 but only in 53c700 emulation mode. It is full featured and
8 Since the 53c700 must be interfaced to a bus, you need to wrapper the
9 card detector around this driver. For an example, see the
12 The comments in the 53c700.[ch] files tell you which parts you need to
13 fill in to get the driver working.
23 define if the chipset must be supported in little endian mode on a big
24 endian architecture (used for the 700 on parisc).
27 Using the Chip Core Driver
30 In order to plumb the 53c700 chip core driver into a working SCSI
[all …]
|
| D | lpfc.txt | 9 Starting in the 8.0.17 release, the driver began to be targeted strictly
10 toward the upstream kernel. As such, we removed #ifdefs for older kernels
11 (pre 2.6.10). The 8.0.16 release should be used if the driver is to be
12 run on one of the older kernels.
14 The proposed modifications to the transport layer for FC remote ports
15 and extended attribute support is now part of the upstream kernel
28 The following information is provided for additional background on the
29 history of the driver as we push for upstream acceptance.
33 In older revisions of the lpfc driver, the driver internally queued i/o
34 received from the midlayer. In the cases where a cable was pulled, link
[all …]
|
| D | cxgb3i.txt | 8 (DDP) where the hardware handles the expensive byte touching operations, such
9 as CRC computation and verification, and direct DMA to the final host memory
14 On transmitting, Chelsio S3 h/w computes and inserts the Header and
15 Data digest into the PDUs.
16 On receiving, Chelsio S3 h/w computes and verifies the Header and
17 Data digest of the PDUs.
21 S3 h/w can directly place the iSCSI Data-In or Data-Out PDU's
23 on the Initiator Task Tag (ITT) in Data-In or Target Task Tag (TTT)
28 On transmitting, S3 h/w accepts the complete PDU (header + data)
29 from the host driver, computes and inserts the digests, decomposes
[all …]
|
| /linux-4.4.14/Documentation/power/ |
| D | userland-swsusp.txt | 4 First, the warnings at the beginning of swsusp.txt still apply.
6 Second, you should read the FAQ in swsusp.txt _now_ if you have not
9 Now, to use the userland interface for software suspend you need special
10 utilities that will read/write the system memory snapshot from/to the
15 The interface consists of a character device providing the open(),
18 numbers of the device are, respectively, 10 and 231, and they can
22 reading, it is considered to be in the suspend mode. Otherwise it is
23 assumed to be in the resume mode. The device cannot be open for simultaneous
24 reading and writing. It is also impossible to have the device open more than
27 Even opening the device has side effects. Data structures are
[all …]
|
| D | pci.txt | 5 An overview of concepts and the Linux kernel's interfaces related to PCI power
9 This document only covers the aspects of power management specific to PCI
10 devices. For general description of the kernel's interfaces related to device
28 devices into states in which they draw less power (low-power states) at the
32 completely inactive. However, when it is necessary to use the device once
33 again, it has to be put back into the "fully functional" state (full-power
34 state). This may happen when there are some data for the device to handle or
35 as a result of an external event requiring the device to be active, which may
36 be signaled by the device itself.
38 PCI devices may be put into low-power states in two ways, by using the device
[all …]
|
| D | swsusp-and-swap-files.txt | 4 The Linux kernel handles swap files almost in the same way as it handles swap
8 (2) the header of a swap file is not in the first block of the partition that
9 holds it. From the swsusp's point of view (1) is not a problem, because it is
10 already taken care of by the swap-handling code, but (2) has to be taken into
13 In principle the location of a swap file's header may be determined with the
14 help of appropriate filesystem driver. Unfortunately, however, it requires the
15 filesystem holding the swap file to be mounted, and if this filesystem is
17 identify a swap file swsusp uses the name of the partition that holds the file
18 and the offset from the beginning of the partition at which the swap file's
24 1) Create the swap file and make it active, eg.
[all …]
|
| D | runtime_pm.txt | 10 at the power management core (PM core) level by means of:
19 * A number of runtime PM fields in the 'power' member of 'struct device' (which
20 is of the type 'struct dev_pm_info', defined in include/linux/pm.h) that can
27 used for carrying out runtime PM operations in such a way that the
28 synchronization between them is taken care of by the PM core. Bus types and
31 The runtime PM callbacks present in 'struct dev_pm_ops', the device runtime PM
32 fields of 'struct dev_pm_info' and the core helper functions provided for
48 are executed by the PM core for the device's subsystem that may be either of
49 the following:
51 1. PM domain of the device, if the device's PM domain object, dev->pm_domain,
[all …]
|
| D | pm_qos_interface.txt | 5 one of the parameters.
10 2. the per-device PM QoS framework provides the API to manage the per-device latency
24 and pm_qos_params.h. This is done because having the available parameters
30 changes to the request list or elements of the list. Typically the
31 aggregated target value is simply the max or min of the request values held
32 in the parameter list elements.
33 Note: the aggregated target value is implemented as an atomic variable so that
34 reading the aggregated value does not require any locking mechanism.
37 From kernel mode the use of this interface is simple:
40 Will insert an element into the list for that identified PM QoS class with the
[all …]
|
| D | basic-pm-debugging.txt | 6 To check if hibernation works, you can try to hibernate in the "reboot" mode:
11 and the system should create a hibernation image, reboot, resume and get back to
12 the command prompt where you have started the transition. If that happens,
13 hibernation is most likely to work correctly. Still, you need to repeat the
16 resuming the system.] Moreover, hibernating in the "reboot" and "shutdown"
17 modes causes the PM core to skip some platform-related callbacks which on ACPI
19 to hibernate or resume in the "reboot" mode, you should try the "platform" mode:
24 which is the default and recommended mode of hibernation.
26 Unfortunately, the "platform" mode of hibernation does not work on some systems
27 with broken BIOSes. In such cases the "shutdown" mode of hibernation might
[all …]
|
| D | suspend-and-cpuhotplug.txt | 1 Interaction of Suspend code (S3) with the CPU hotplug infrastructure
6 I. How does the regular CPU hotplug code differ from how the Suspend-to-RAM
11 [This depicts the current design in the kernel, and focusses only on the
12 interactions involving the freezer and CPU hotplug and also tries to explain
13 the locking involved. It outlines the notifications involved as well.
14 But please note that here, only the call paths are illustrated, with the aim
19 On a high level, the suspend-resume cycle goes like this:
61 Common | before taking down the CPU |
88 Resuming back is likewise, with the counterparts being (in the order of
93 | Call _cpu_up() [for all those cpus in the frozen_cpus mask, in a loop]
[all …]
|
| D | devices.txt | 8 Most of the code in Linux is device drivers, so most of the Linux power
14 power management goals, emphasizing the models and interfaces that are
15 shared by everything that hooks up to the driver model core. Read it as
16 background for the domain-specific work you'd do with any specific driver.
35 Some drivers can manage hardware wakeup events, which make the system
36 leave the low-power state. This feature may be enabled or disabled
37 using the relevant /sys/devices/.../power/wakeup file (for Ethernet
38 drivers the ioctl interface used by ethtool may also be used for this
39 purpose); enabling it may cost some power usage, but let the whole
43 Devices may also be put into low-power states while the system is
[all …]
|
| /linux-4.4.14/Documentation/ |
| D | circular-buffers.txt | 15 (2) Memory barriers for when the producer and the consumer of objects in the
41 (1) A 'head' index - the point at which the producer inserts items into the
44 (2) A 'tail' index - the point at which the consumer finds the next item in
45 the buffer.
47 Typically when the tail pointer is equal to the head pointer, the buffer is
48 empty; and the buffer is full when the head pointer is one less than the tail
51 The head index is incremented when items are added, and the tail index when
52 items are removed. The tail index should never jump the head index, and both
53 indices should be wrapped to 0 when they reach the end of the buffer, thus
54 allowing an infinite amount of data to flow through the buffer.
[all …]
|
| D | IPMI.txt | 10 It provides for dynamic discovery of sensors in the system and the
11 ability to monitor the sensors and be informed when the sensor's
18 management software that can use the IPMI system.
20 This document describes how to use the IPMI driver for Linux. If you
21 are not familiar with IPMI itself, see the web site at
30 these are available in the 'Character Devices' menu then the IPMI
37 Kernel code (like the watchdog) can still use it. If you need access
42 properly provides the SMBIOS info for IPMI, the driver will detect it
45 manual), choose the 'IPMI SI handler' option. A driver also exists
46 for direct I2C access to the IPMI management controller. Some boards
[all …]
|
| D | dell_rbu.txt | 2 Demonstrate the usage of the new open sourced rbu (Remote BIOS Update) driver
6 This document discusses the functionality of the rbu driver only.
7 It does not cover the support needed from applications to enable the BIOS to
8 update itself with the image downloaded in to the memory.
12 the BIOS on Dell servers (starting from servers sold since 1999), desktops
19 Dell_RBU driver supports BIOS update using the monolithic image and packetized
20 image methods. In case of monolithic the driver allocates a contiguous chunk
21 of physical pages having the BIOS image. In case of packetized the app
22 using the driver breaks the image in to packets of fixed sizes and the driver
25 If the dell_rbu driver is unloaded all the allocated memory is freed.
[all …]
|
| D | xillybus.txt | 23 -- Host never reads from the FPGA
24 -- Channels, pipes, and the message channel
41 or even a processor with its peripherals. FPGAs are the LEGO of hardware:
42 Based upon certain building blocks, you make your own toys the way you like
44 available on the market as a chipset, so FPGAs are mostly used when some
45 special functionality is needed, and the production volume is relatively low
46 (hence not justifying the development of an ASIC).
50 focus on their specific project, and not reinvent the wheel over and over
51 again, pre-designed building blocks, IP cores, are often used. These are the
55 building block, with electrical wires dangling on the sides for connection to
[all …]
|
| D | robust-futex-ABI.txt | 15 1) a one time call, per thread, to tell the kernel where its list of
18 by the exiting thread.
23 threads in the kernel. Options on the sys_futex(2) system call support
24 waiting on a particular futex, and waking up the next waiter on a
27 For robust_futexes to work, the user code (typically in a library such
28 as glibc linked with the application) has to manage and place the
29 necessary list elements exactly as the kernel expects them. If it fails
31 probably causing deadlock or other such failure of the other threads
32 waiting on the same locks.
35 issue the system call:
[all …]
|
| D | bus-virt-phys-mapping.txt | 2 superseded by the functionality provided by the PCI DMA interface
7 [ This is a mail message in response to a query on IO mapping, thus the
10 The AHA-1542 is a bus-master device, and your patch makes the driver give the
11 controller the physical address of the buffers, which is correct on x86
12 (because all bus master devices see the physical memory mappings directly).
15 at memory addresses, and in this case we actually want the third, the
18 Essentially, the three ways of addressing memory are (this is "real memory",
21 - CPU untranslated. This is the "physical" address. Physical address
22 0 is what the CPU sees when it drives zeroes on the memory bus.
24 - CPU translated address. This is the "virtual" address, and is
[all …]
|
| D | crc32.txt | 3 A CRC is a long-division remainder. You add the CRC to the message,
4 and the whole thing (message+CRC) is a multiple of the given
5 CRC polynomial. To check the CRC, you can either check that the
6 CRC matches the recomputed value, *or* you can check that the
7 remainder computed on the message+CRC is 0. This latter approach
9 protocols put the end-of-frame flag after the CRC.
11 It's actually the same long division you learned in school, except that
12 - We're working in binary, so the digits are only 0 and 1, and
15 the difference between adding and subtracting.
17 Like all division, the remainder is always smaller than the divisor.
[all …]
|
| D | initrd.txt | 1 Using the initial RAM disk (initrd)
8 initrd provides the capability to load a RAM disk by the boot loader.
9 This RAM disk can then be mounted as the root file system and programs
15 where the kernel comes up with a minimum set of compiled-in drivers, and
18 This document gives a brief overview of the use of initrd. A more detailed
19 discussion of the boot process can be found in [1].
25 When using initrd, the system typically boots as follows:
27 1) the boot loader loads the kernel and the initial RAM disk
28 2) the kernel converts initrd into a "normal" RAM disk and
29 frees the memory used by initrd
[all …]
|
| D | men-chameleon-bus.txt | 8 1.2 Limitations of the current implementation
19 4.3 Initializing the driver
24 This document describes the architecture and implementation of the MEN
29 This document is intended to be a short overview of the current
30 implementation and does by no means describe the complete possibilities of MCB
33 1.2 Limitations of the current implementation
36 that only use a single memory resource and share the PCI legacy IRQ. Not
38 - Multi-resource MCB devices like the VME Controller or M-Module carrier.
49 - the parser for the Chameleon table.
57 FPGA contains a header section describing the content of the FPGA. The
[all …]
|
| D | nommu-mmap.txt | 6 as are used in uClinux environments. From the userspace point of view, memory
7 mapping is made use of in conjunction with the mmap() system call, the shmat()
8 call and the execve() system call. From the kernel's point of view, execve()
9 mapping is actually performed by the binfmt drivers, which call back into the
10 mmap() routines to do the actual work.
12 Memory mapping behaviour also involves the way fork(), vfork(), clone() and
14 the CLONE_VM flag.
16 The behaviour is similar between the MMU and no-MMU cases, but not identical;
17 and it's also much more restricted in the latter case:
21 In the MMU case: VM regions backed by arbitrary pages; copy-on-write
[all …]
|
| D | SM501.txt | 14 The core driver in drivers/mfd provides common services for the
15 drivers which manage the specific hardware blocks. These services
20 chips via the platform device and driver system.
22 On detection of a device, the core initialises the chip (which may
23 be specified by the platform data) and then exports the selected
24 peripheral set as platform devices for the specific drivers.
26 The core re-uses the platform device system as the platform device
27 system provides enough features to support the drivers without the
28 need to create a new bus-type and the associated code to go with it.
34 Each peripheral has a view of the device which is implicitly narrowed to
[all …]
|
| D | kprobes.txt | 26 routine to be invoked when the breakpoint is hit.
27 (*: some parts of the kernel code can not be trapped, see 1.5 Blacklist)
31 on virtually any instruction in the kernel. A jprobe is inserted at
32 the entry to a kernel function, and provides convenient access to the
36 In the typical case, Kprobes-based instrumentation is packaged as
38 one or more probes, and the exit function unregisters them. A
40 the probe is to be inserted and what handler is to be called when
41 the probe is hit.
48 The next four subsections explain how the different types of
50 things that you'll need to know in order to make the best use of
[all …]
|
| D | sysfs-rules.txt | 1 Rules on how to access information in the Linux kernel sysfs
5 by the kernel developers that the Linux kernel does not provide a stable
6 internal API. Therefore, there are aspects of the sysfs interface that
9 To minimize the risk of breaking users of sysfs, which are in most cases
10 low-level userspace applications, with a new kernel release, the users
13 implement this and users are encouraged to plug, if possible, into the
17 the following rules and then your programs should work with future
18 versions of the sysfs interface.
22 offer any abstraction, it exposes all the kernel driver-core
24 reading directories and opening the files yourself.
[all …]
|
| D | dma-buf-sharing.txt | 8 This document serves as a guide to device-driver writers on what is the dma-buf
12 either the 'exporter' of buffers, or the 'user' of buffers.
14 Say a driver A wants to use buffers created by driver B, then we call B as the
18 - implements and manages operations[1] for the buffer
19 - allows other users to share the buffer by using dma_buf sharing APIs,
20 - manages the details of buffer allocation,
21 - decides about the actual backing storage where this allocation happens,
26 - is one of (many) sharing users of the buffer.
27 - doesn't need to worry about how the buffer is allocated, or where.
28 - needs a mechanism to get access to the scatterlist that makes up this buffer
[all …]
|
| D | phy.txt | 4 This document explains the Generic PHY Framework along with the APIs provided,
9 *PHY* is the abbreviation for physical layer. It is used to connect a device
10 to the physical medium e.g., the USB controller has a PHY to provide functions
12 for obtaining the required data transmission rate. Note that some USB
17 The intention of creating this framework is to bring the PHY drivers spread
18 all over the Linux kernel to drivers/phy to increase code re-use and for
22 functionality is not embedded within the controller).
24 2. Registering/Unregistering the PHY provider
27 For the simple case where the PHY provider implements only a single instance of
28 the PHY, the framework provides its own implementation of of_xlate in
[all …]
|
| D | assoc_array.txt | 28 This associative array implementation is an object container with the following
34 [!] NOTE: Pointers to objects _must_ be zero in the least significant bit.
36 (2) Objects do not need to contain linkage blocks for use by the array. This
38 Rather, the array is made up of metadata blocks that point to objects.
40 (3) Objects require index keys to locate them within the array.
42 (4) Index keys must be unique. Inserting an object with the same key as one
43 already in the array will replace the old object.
47 (6) Index keys should encode the length early on, before any variation due to
50 (7) Index keys can include a hash to scatter objects throughout the array.
55 (9) The array can be iterated over whilst it is being modified, provided the
[all …]
|
| D | kobject.txt | 11 Part of the difficulty in understanding the driver model - and the kobject
22 usually, a representation in the sysfs virtual filesystem.
25 usually embedded within some other structure which contains the stuff
26 the code is really interested in.
29 If it does, the reference counting for the object is sure to be messed
32 - A ktype is the type of object that embeds a kobject. Every structure
34 what happens to the kobject when it is created and destroyed.
36 - A kset is a group of kobjects. These kobjects can be of the same ktype
37 or belong to different ktypes. The kset is the basic container type for
39 safely ignore that implementation detail as the kset core code handles
[all …]
|
| D | efi-stub.txt | 4 On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
6 it as an EFI executable. The code that modifies the bzImage header,
7 along with the EFI-specific entry point that the firmware loader
8 jumps to are collectively known as the "EFI boot stub", and live in
10 respectively. For ARM the EFI stub is implemented in
15 For arm64, there is no compressed kernel support, so the Image itself
16 masquerades as a PE/COFF image and the EFI stub is linked into the
20 By using the EFI boot stub it's possible to boot a Linux kernel
21 without the use of a conventional EFI boot loader, such as grub or
22 elilo. Since the EFI boot stub performs the jobs of a boot loader, in
[all …]
|
| D | futex-requeue-pi.txt | 5 special handling in order to ensure the underlying rt_mutex is never
6 left without an owner if it has waiters; doing so would break the PI
7 boosting logic [see rt-mutex-desgin.txt] For the purposes of
15 Without requeue_pi, the glibc implementation of
16 pthread_cond_broadcast() must resort to waking all the tasks waiting
19 implementation would wake the highest-priority waiter, and leave the
20 rest to the natural wakeup inherent in unlocking the mutex
21 associated with the condvar.
23 Consider the simplified glibc calls:
46 Once pthread_cond_broadcast() requeues the tasks, the cond->mutex
[all …]
|
| D | stable_kernel_rules.txt | 3 Rules on what kind of patches are accepted, and which ones are not, into the
20 exists and additional information on the user-visible impact.
22 - No "theoretical race condition" issues, unless an explanation of how the
26 - It must follow the Documentation/SubmittingPatches rules.
30 Procedure for submitting patches to the -stable tree:
32 - If the patch covers files in net/ or drivers/net please follow netdev stable
35 - Security patches should not be handled (solely) by the -stable review
36 process but should follow the procedures in Documentation/SecurityBugs.
38 For all other submissions, choose one of the following procedures:
42 To have the patch automatically included in the stable tree, add the tag
[all …]
|
| D | intel_txt.txt | 6 provide the building blocks for creating trusted platforms.
8 Intel TXT was formerly known by the code name LaGrande Technology (LT).
15 Intel TXT is part of the vPro(TM) brand and is also available some
17 based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
18 Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
22 This site also has a link to the Intel TXT MLE Developers Manual,
23 which has been updated for the new released platforms.
25 Intel TXT has been presented at various events over the past few
55 measure or protect the integrity of a running kernel, they all
56 assume the kernel is "good" to begin with. The Integrity
[all …]
|
| D | vgaarbiter.txt | 7 implemented on PCI will typically have the same "hard-decoded" addresses as
12 The Resource Access Control (RAC) module inside the X server [0] existed for
13 the legacy VGA arbitration task (besides other bus management tasks) when more
14 than one legacy device co-exists on the same machine. But the problem happens
17 ideally, being a userspace application, it is not the role of the X server to
18 control bus resources. Therefore an arbitration scheme outside of the X server
19 is needed to control the sharing of these resources. This document introduces
20 the operation of the VGA arbiter implemented for the Linux kernel.
38 The vgaarb is a module of the Linux Kernel. When it is initially loaded, it
39 scans all PCI devices and adds the VGA ones inside the arbitration. The
[all …]
|
| D | this_cpu_ops.txt | 5 variables associated with the *currently* executing processor. This is
6 done through the use of segment registers (or a dedicated register where
7 the cpu permanently stored the beginning of the per cpu area for a
10 this_cpu operations add a per cpu variable offset to the processor
11 specific per cpu base and encode that operation in the instruction
12 operating on the per cpu variable.
14 This means that there are no atomicity issues between the calculation of
15 the offset and the operation on the data. Therefore it is not
16 necessary to disable preemption or interrupts to ensure that the
17 processor is not changed between the calculation of the address and
[all …]
|
| D | module-signing.txt | 10 - Public keys in the kernel.
15 - Administering/protecting the private key.
23 installation and then checks the signature upon loading the module. This
24 allows increased kernel security by disallowing the loading of unsigned modules
26 making it harder to load a malicious module into the kernel. The module
27 signature checking is done by the kernel so that it is not necessary to have
30 This facility uses X.509 ITU-T standard certificates to encode the public keys
32 type. The facility currently only supports the RSA public key encryption
35 SHA-512 (the algorithm is selected by data in the signature).
42 The module signing facility is enabled by going to the "Enable Loadable Module
[all …]
|
| D | DMA-API.txt | 1 Dynamic DMA mapping using the generic device
6 This document describes the DMA API. For a more gentle introduction
7 of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt.
9 This API is split into two pieces. Part I describes the basic API.
13 should only use the API described in part I.
18 To get the dma_ API, you must #include <linux/dma-mapping.h>. This
19 provides dma_addr_t and the interfaces described below.
21 A dma_addr_t can hold any valid DMA address for the platform. It can be
24 address space and the DMA address space.
33 Consistent memory is memory for which a write by either the device or
[all …]
|
| D | md-cluster.txt | 17 During "normal" functioning we assume the filesystem ensures that only one
20 - set the appropriate bit (if not already set)
21 - commit the write to all mirrors
22 - schedule the bit to be cleared after a timeout.
24 Reads are just handled normally. It is up to the filesystem to
25 ensure one node doesn't read from a location where another node (or the same
31 There are two locks for managing the device:
35 The bm_lockres protects individual node bitmaps. They are named in the
37 joins the cluster, it acquires the lock in PW mode and it stays so
38 during the lifetime the node is part of the cluster. The lock resource
[all …]
|
| D | memory-barriers.txt | 55 (*) The effects of the cpu cache.
63 - And then there's the Alpha.
76 Consider the following abstract model of the system:
101 Each CPU executes a program that generates memory access operations. In the
103 perform the memory operations in any order it likes, provided program causality
104 appears to be maintained. Similarly, the compiler may also arrange the
105 instructions it emits in any order it likes, provided it doesn't affect the
106 apparent operation of the program.
108 So in the above diagram, the effects of the memory operations performed by a
109 CPU are perceived by the rest of the system as the operations cross the
[all …]
|
| /linux-4.4.14/Documentation/watchdog/ |
| D | watchdog-api.txt | 8 Some parts of this document are copied verbatim from the sbc60xxwdt
11 This document describes the state of the Linux 2.4.18 kernel.
15 A Watchdog Timer (WDT) is a hardware circuit that can reset the
19 Usually a userspace daemon will notify the kernel watchdog driver via the
21 regular intervals. When such a notification occurs, the driver will
22 usually tell the hardware watchdog that everything is in order, and
23 that the watchdog should wait for yet another little while to reset
24 the system. If userspace fails (RAM error, kernel bug, whatever), the
25 notifications cease to occur, and the hardware watchdog will reset the
26 system (causing a reboot) after the timeout occurs.
[all …]
|
| D | watchdog-kernel-api.txt | 10 It also does not describe the API which can be used by user space to communicate
11 with a WatchDog Timer. If you want to know this then please read the following
14 So what does this document describe? It describes the API that can be used by
15 WatchDog Timer Drivers that want to use the WatchDog Timer Driver Core
17 the same code does not have to be reproduced each time. This also means that
18 a watchdog timer driver then only needs to provide the different routines
19 (operations) that control the watchdog timer (WDT).
23 Each watchdog timer driver that wants to use the WatchDog Timer Driver Core
36 device. The parameter of this routine is the pointer to the registered
41 the boot process.
[all …]
|
| D | hpwdt.txt | 9 watchdog functionality and the added benefit of NMI sourcing. Both the
10 watchdog functionality and the NMI sourcing capability need to be enabled
11 by the user. Remember that the two modes are not dependent on one another.
12 A user can have the NMI sourcing without the watchdog timer and vice-versa.
15 is, an application needs to be started that kicks off the watchdog timer. A
16 basic application exists in the Documentation/watchdog/src directory called
17 watchdog-test.c. Simply compile the C file and kick it off. If the system
18 gets into a bad state and hangs, the HP ProLiant iLO 2 timer register will
22 The hpwdt driver also has four (4) module parameters. They are the following:
24 soft_margin - allows the user to set the watchdog timer value
[all …]
|
| /linux-4.4.14/Documentation/vm/ |
| D | userfaultfd.txt | 5 Userfaults allow the implementation of on-demand paging from userland
7 memory page faults, something otherwise only the kernel code could do.
10 of the PROT_NONE+SIGSEGV trick.
14 Userfaults are delivered and resolved through the userfaultfd syscall.
19 1) read/POLLIN protocol to notify a userland thread of the faults
22 2) various UFFDIO_* ioctls that can manage the virtual memory regions
23 registered in the userfaultfd that allows userland to efficiently
24 resolve the userfaults it receives via 1) or to manage the virtual
25 memory in the background
28 management of mremap/mprotect is that the userfaults in all their
[all …]
|
| D | numa_memory_policy.txt | 4 In the Linux kernel, "memory policy" determines from which node the kernel will
8 document attempts to describe the concepts and APIs of the 2.6 memory policy
13 which is an administrative mechanism for restricting the nodes from which
16 both cpusets and policies are applied to a task, the restrictions of the cpuset
26 System Default Policy: this policy is "hard coded" into the kernel. It
27 is the policy that governs all page allocations that aren't controlled
28 by one of the more specific policy scopes discussed below. When the
29 system is "up and running", the system default policy will use "local
30 allocation" described below. However, during boot up, the system
32 with "sufficient" memory, so as not to overload the initial boot node
[all …]
|
| D | unevictable-lru.txt | 37 This document describes the Linux memory manager's "Unevictable LRU"
38 infrastructure and the use of this to manage several types of "unevictable"
41 The document attempts to provide the overall rationale behind this mechanism
42 and the rationale for some of the design decisions that drove the
43 implementation. The latter design rationale is discussed in the context of an
44 implementation description. Admittedly, one can obtain the implementation
45 details - the "what does it do?" - by reading the code. One hopes that the
46 descriptions below add value by provide the answer to "why does it do that?".
62 will spend a lot of time scanning the LRU lists looking for the small fraction
64 spending 100% of their time in vmscan for hours or days on end, with the system
[all …]
|
| D | page_migration | 4 Page migration allows the moving of the physical location of pages between
5 nodes in a numa system while the process is running. This means that the
6 virtual addresses that the process sees do not change. However, the
7 system rearranges the physical location of those pages.
9 The main intend of page migration is to reduce the latency of memory access
10 by moving pages near to the processor where the process accessing that memory
13 Page migration allows a process to manually relocate the node on which its
14 pages are located through the MF_MOVE and MF_MOVE_ALL options while setting
16 from another process using the sys_migrate_pages() function call. The
18 process that are located on the from nodes to the destination nodes.
[all …]
|
| D | hugetlbpage.txt | 3 the Linux kernel. This support is built on top of multiple page size support
13 Users can use the huge page support in Linux kernel by either using the mmap
16 First the Linux kernel needs to be built with the CONFIG_HUGETLBFS
21 The /proc/meminfo file provides information about the total number of
22 persistent hugetlb pages in the kernel's huge page pool. It also displays
23 information about the number of free, reserved and surplus huge pages and the
24 default huge page size. The huge page size is needed for generating the
25 proper alignment and size of the arguments to system calls that map huge page
38 HugePages_Total is the size of the pool of huge pages.
39 HugePages_Free is the number of huge pages in the pool that are not yet
[all …]
|
| D | numa | 5 This question can be answered from a couple of perspectives: the
6 hardware view and the Linux software view.
8 From the hardware perspective, a NUMA system is a computer platform that
11 disambiguate the hardware view of these physical components/assemblies
12 from the software abstraction thereof, we'll call the components/assemblies
15 Each of the 'cells' may be viewed as an SMP [symmetric multi-processor] subset
16 of the system--although some components necessary for a stand-alone SMP system
17 may not be populated on any given cell. The cells of the NUMA system are
23 For Linux, the NUMA platforms of interest are primarily what is known as Cache
26 is handled in hardware by the processor caches and/or the system interconnect.
[all …]
|
| /linux-4.4.14/Documentation/security/ |
| D | IMA-templates.txt | 6 The original 'ima' template is fixed length, containing the filedata hash
10 necessary to extend the current version of IMA by defining additional
12 the inode UID/GID or the LSM labels either of the inode and of the process
15 However, the main problem to introduce this feature is that, each time
16 a new template is defined, the functions that generate and display
17 the measurements list would include the code for handling a new format
18 and, thus, would significantly grow over the time.
20 The proposed solution solves this problem by separating the template
21 management from the remaining IMA code. The core of this solution is the
23 which information should be included in the measurement list; a template
[all …]
|
| D | keys.txt | 6 user mappings, and similar to be cached in the kernel for the use of
17 This document has the following sections:
37 tokens, keyrings, etc.. These are represented in the kernel by struct key.
51 the lifetime of that key. All serial numbers are positive non-zero 32-bit
57 (*) Each key is of a defined "type". Types must be registered inside the
61 Key types are represented in the kernel by struct key_type. This defines a
64 Should a type be removed from the system, all the keys of that type will
68 type provides an operation to perform a match between the description on a
73 whether a kernel service will be able to find the key.
75 (*) Each key can be set to expire at a specific time by the key type's
[all …]
|
| /linux-4.4.14/Documentation/serial/ |
| D | tty.txt | 4 Your guide to the ancient and twisted locking policies of the tty layer and
5 the warped logic behind them. Beware all ye who read on.
11 Line disciplines are registered with tty_register_ldisc() passing the
12 discipline number and the ldisc structure. At the point of registration the
14 the call returns success. If the call returns an error then it won't get
15 called. Do not re-use ldisc numbers as they are part of the userspace ABI
17 After the return the ldisc data has been copied so you may free your own
18 copy of the structure. You must not re-register over the top of the line
19 discipline even with the same data or your computer again will be eaten by
23 In ancient times this always worked. In modern times the function will
[all …]
|
| D | rocket.txt | 2 Device Driver for the Linux Operating System
9 This driver provides a loadable kernel driver for the Comtrol RocketPort
13 This file assumes that you are using the RocketPort driver which is
14 integrated into the kernel sources.
16 The driver can also be installed as an external module using the usual
18 from the Comtrol website listed below, is useful for updating the driver
19 or installing it into kernels which do not have the driver configured
20 into them. Installations instructions for the external module
21 are in the included README and HW_INSTALL files.
26 The RocketPort ISA board requires I/O ports to be configured by the DIP
[all …]
|
| /linux-4.4.14/Documentation/filesystems/ |
| D | xfs-delayed-logging-design.txt | 8 such as inodes and dquots, are logged in logical format where the details
9 logged are made up of the changes to in-core structures rather than on-disk
11 logged. The reason for these differences is to reduce the amount of log space
14 than any other object (except maybe the superblock buffer) so keeping the
18 modifications to a single object to be carried in the log at any given time.
19 This allows the log to avoid needing to flush each change to disk before
20 recording a new change to the object. XFS does this via a method called
22 new change to the object is recorded with a *new copy* of all the existing
23 changes in the new transaction that is written to the log.
25 That is, if we have a sequence of changes A through to F, and the object was
[all …]
|
| D | overlayfs.txt | 10 filesystem which is the result over overlaying one filesystem on top
11 of the other.
17 This approach is 'hybrid' because the objects that appear in the
19 cases an object accessed in the union will be indistinguishable
20 from accessing the corresponding object from the original filesystem.
21 This is most obvious from the 'st_dev' field returned by stat(2).
23 While directories will report an st_dev from the overlay-filesystem,
24 all non-directory objects will report an st_dev from the lower or
25 upper filesystem that is providing the object. Similarly st_ino will
27 over the lifetime of a non-directory object. Many applications and
[all …]
|
| D | xfs-self-describing-metadata.txt | 8 scalability, but of verification of the filesystem structure. Scalabilty of the
9 structures and indexes on disk and the algorithms for iterating them are
11 is this very scalability that causes the verification problem.
14 metadata is the allocation group headers (SB, AGF, AGFL and AGI), while all
15 other metadata structures need to be discovered by walking the filesystem
17 validating and repairing the structure, there are limits to what they can
18 verify, and this in turn limits the supportable size of an XFS filesystem.
21 scripting to analyse the structure of a 100TB filesystem when trying to
22 determine the root cause of a corruption problem, but it is still mainly a
24 weren't the ultimate cause of a corruption event. It may take a few hours to a
[all …]
|
| D | autofs4-mount-control.txt | 2 Miscellaneous Device control operations for the autofs4 kernel module
11 During normal operation autofs uses a file descriptor opened on the
14 autofs specific information stored in the super block. The operations
15 are things such as setting an autofs mount catatonic, setting the
23 needs to walk back up the mount tree to construct a path, such as
24 getcwd(2) and the proc file system /proc/<pid>/cwd, no longer works
25 because the point from which the path is constructed has been detached
26 from the mount tree.
29 mounts. Immediately one thinks of just adding the ability to remount
31 because autofs direct mounts and the implementation of "on demand mount
[all …]
|
| D | spufs.txt | 6 spufs - the SPU file system
10 The SPU file system is used on PowerPC machines that implement the Cell
15 message queues. Users that have write permissions on the file system
16 can use spu_create(2) to establish SPU contexts in the spufs root.
19 set of files. These files can be used for manipulating the state of the
26 set the user owning the mount point, the default is 0 (root).
29 set the group owning the mount point, the default is 0 (root).
33 The files in spufs mostly follow the standard behavior for regular sys-
35 the operations supported on regular file systems. This list details the
36 supported operations and the deviations from the behaviour in the
[all …]
|
| D | relay.txt | 5 efficiently log and transfer large quantities of data from the kernel
11 clients write into the channel buffers using efficient write
12 functions; these automatically log into the current cpu's channel
13 buffer. User space applications mmap() or read() from the relay files
14 and retrieve the data as it becomes available. The relay files
16 are associated with the channel buffers using the API described below.
18 The format of the data logged into the channel buffers is completely
19 up to the kernel client; the relay interface does however provide
20 hooks which allow kernel clients to impose some structure on the
22 filtering - this also is left to the kernel client. The purpose is to
[all …]
|
| D | fiemap.txt | 29 fm_start, and fm_length specify the logical range within the file
30 which the process would like mappings for. Extents returned mirror
31 those on disk - that is, the logical offset of the 1st returned extent
32 may start before fm_start, and the range covered by the last returned
35 Certain flags to modify the way in which mappings are looked up can be
36 set in fm_flags. If the kernel doesn't understand some particular
37 flags, it will return EBADR and the contents of fm_flags will contain
38 the set of flags which caused the error. If the kernel is compatible
39 with all flags passed, the contents of fm_flags will be unmodified.
41 flag is fatal to its operation. This scheme is intended to allow the
[all …]
|
| D | fuse.txt | 8 the kernel interface.
12 The process(es) providing the data and metadata of the filesystem.
17 The filesystem daemon is running with the privileges of the mounting
18 user. NOTE: this is not the same as mounts allowed with the "user"
23 A connection between the filesystem daemon and the kernel. The
24 connection exists until either the daemon dies, or the filesystem is
25 umounted. Note that detaching (or lazy umounting) the filesystem
26 does _not_ break the connection, in this case it will exist until
27 the last reference to the filesystem is released.
31 The user who does the mounting.
[all …]
|
| D | ext2.txt | 6 Theodore Ts'o and Stephen Tweedie, it was a major rewrite of the
7 Extended Filesystem. It is currently still (April 2001) the predominant
9 for NetBSD, FreeBSD, the GNU HURD, Windows 95/98/NT, OS/2 and RISC OS.
14 Most defaults are determined by the filesystem superblock, and can be
26 debug Extra debugging information is sent to the
30 errors=remount-ro Remount the filesystem read-only on an error.
31 errors=panic Panic and halt the machine if an error occurs.
33 grpid, bsdgroups Give objects the same group ID as their parent.
34 nogrpid, sysvgroups New objects have the group ID of their creator.
38 oldalloc Enable the old block allocator. Orlov should
[all …]
|
| D | logfs.txt | 11 Two superblocks exist at the beginning and end of the filesystem.
15 Superblock locations may differ for MTD and block devices. On MTD the
16 first non-bad block contains a superblock in the first 4096 Bytes and
17 the last non-bad block contains a superblock in the last 4096 Bytes.
18 On block devices, the first 4096 Bytes of the device contain the first
19 superblock and the last aligned 4096 Byte-block contains the second
22 For the most part, the superblocks can be considered read-only. They
23 are written only to correct errors detected within the superblocks,
24 move the journal and change the filesystem parameters through tunefs.
25 As a result, the superblock does not contain any fields that require
[all …]
|
| D | vfs.txt | 2 Overview of the Linux Virtual File System
11 This file is released under the GPLv2.
17 The Virtual File System (also known as the Virtual Filesystem Switch)
18 is the software layer in the kernel that provides the filesystem
20 within the kernel which allows different filesystem implementations to
25 in the document Documentation/filesystems/Locking.
31 The VFS implements the open(2), stat(2), chmod(2), and similar system
32 calls. The pathname argument that is passed to them is used by the VFS
33 to search through the directory entry cache (also known as the dentry
39 most computers cannot fit all dentries in the RAM at the same time,
[all …]
|
| /linux-4.4.14/Documentation/networking/ |
| D | ppp_generic.txt | 8 The generic PPP driver in linux-2.4 provides an implementation of the
11 * the network interface unit (ppp0 etc.)
12 * the interface to the networking code
15 * the interface to pppd, via a /dev/ppp character device
21 For sending and receiving PPP frames, the generic PPP driver calls on
22 the services of PPP `channels'. A PPP channel encapsulates a
25 has a very simple interface with the generic PPP code: it merely has
41 See include/linux/ppp_channel.h for the declaration of the types and
42 functions used to communicate between the generic PPP layer and PPP
45 Each channel has to provide two functions to the generic PPP layer,
[all …]
|
| D | 6pack.txt | 1 This is the 6pack-mini-HOWTO, written by
10 1. What is 6pack, and what are the advantages to KISS?
12 6pack is a transmission protocol for data exchange between the PC and
13 the TNC over a serial line. It can be used as an alternative to KISS.
16 - The PC is given full control over the radio
17 channel. Special control data is exchanged between the PC and the TNC so
18 that the PC knows at any time if the TNC is receiving data, if a TNC
19 buffer underrun or overrun has occurred, if the PTT is
22 important event. This helps to improve the channel access and timing
23 algorithms as everything is computed in the PC. It would even be possible
[all …]
|
| D | lapb-module.txt | 8 the Linux operating system that require a LAPB service. This document
9 defines the interfaces to, and the services provided by this module. The
10 term module in this context does not imply that the LAPB module is a
14 The interface to the LAPB module consists of functions to the module,
15 callbacks from the module to indicate important state changes, and
16 structures for getting and setting information about the module.
21 Probably the most important structure is the skbuff structure for holding
22 received and transmitted data, however it is beyond the scope of this
25 The two LAPB specific structures are the LAPB initialisation structure and
26 the LAPB parameter structure. These will be defined in a standard header
[all …]
|
| D | iphase.txt | 11 This is the README file for the Interphase PCI ATM (i)Chip IA Linux driver
16 - Supports 4K VCs for the server board (with 512K control memory) and 1K
17 VCs for the client board (with 128K control memory).
20 - Supports setting of PCR on the VCs.
38 1. Installing the adapters in the system
39 To install the ATM adapters in the system, follow the steps below.
41 b. Shut down the system and power off the system.
42 c. Install one or more ATM adapters in the system.
44 LED on the front panel of the adapter will be on if the adapter is
45 connected to the switch properly when the system is powered up.
[all …]
|
| D | dm9000.txt | 11 This file describes how to use the DM9000 platform-device based network driver
12 that is contained in the files drivers/net/dm9000.c and drivers/net/dm9000.h.
14 The driver supports three DM9000 variants, the DM9000E which is the first chip
15 supported as well as the newer DM9000A and DM9000B devices. It is currently
20 Defining the platform device
23 The minimum set of resources attached to the platform device are as follows:
25 1) The physical address of the address register
26 2) The physical address of the data register
27 3) The IRQ line the device's interrupt pin is connected to.
29 These resources should be specified in that order, as the ordering of the
[all …]
|
| D | spider_net.txt | 11 This document sketches the structure of portions of the spidernet
12 device driver in the Linux kernel tree. The spidernet is a gigabit
13 ethernet device built into the Toshiba southbridge commonly used
14 in the SONY Playstation 3 and the IBM QS20 Cell blade.
16 The Structure of the RX Ring.
19 together with three pointers into the ring that are used to manage its
22 The elements of the ring are called "descriptors" or "descrs"; they
23 describe the received data. This includes a pointer to a buffer
24 containing the received data, the buffer size, and various status bits.
28 to receive data from the hardware. A "full" descriptor has data in it,
[all …]
|
| D | switchdev.txt | 8 model for switch devices which offload the forwarding (data) plane from the
11 Figure 1 is a block diagram showing the components of the switchdev model for
74 On switchdev driver initialization, the driver will allocate and register a
76 port, called the port netdev. A port netdev is the software representation of
77 the physical port and provides a conduit for control traffic to/from the
78 controller (the kernel) and the network, as well as an anchor point for higher
80 standard netdev tools (iproute2, ethtool, etc), the port netdev can also
81 provide to the user access to the physical properties of the switch port such
84 There is (currently) no higher-level kernel object for the switch beyond the
85 port netdevs. All of the switchdev driver ops are netdev ops or switchdev ops.
[all …]
|
| D | cs89x0.txt | 9 described below. In general, you should use the driver version which
25 1.2.2 File in the Driver Package
36 4.1 Compiling the Driver as a Loadable Module
37 4.2 Compiling the driver to support memory mode
38 4.3 Compiling the driver to support Rx DMA
42 5.2 Testing the Adapter
45 5.3 Using the Adapter's LEDs
51 6.3 Obtaining the Latest Driver Version
69 CS8920-based adapters are similar to the CS8900-based adapter with additional
71 such, the configuration procedures differ somewhat between the two types of
[all …]
|
| D | bonding.txt | 23 The behavior of the bonded interfaces depends upon the mode; generally
29 the original tools from extreme-linux and beowulf sites will not work
30 with this version of the driver.
32 For new versions of the driver, updated userspace tools, and
33 who to ask for help, please follow the links at the end of this file.
107 Most popular distro kernels ship with the bonding driver
111 the following steps:
113 1.1 Configure and build the kernel with bonding
116 The current version of the bonding driver is available in the
117 drivers/net/bonding subdirectory of the most recent kernel source
[all …]
|
| D | stmmac.txt | 6 This is the driver for the MAC 10/100/1000 on-chip Ethernet controllers
16 This driver supports both the platform bus and PCI.
25 CONFIG_STMMAC_PLATFORM: is to enable the platform driver.
26 CONFIG_STMMAC_PCI: is to enable the pci driver.
30 phyaddr: to manually provide the physical address to the PHY device;
34 tc: control the HW FIFO threshold;
48 The xmit method is invoked when the kernel needs to transmit a packet; it sets
49 the descriptors in the ring and informs the DMA engine that there is a packet
51 By default, the driver sets the NETIF_F_SG bit in the features field of the
52 net_device structure enabling the scatter-gather feature. This is true on
[all …]
|
| D | baycom.txt | 5 !!NEW!! (04/98) The drivers for the baycom modems have been split into
6 separate drivers as they did not share any code, and the driver
9 This document describes the Linux Kernel Drivers for simple Baycom style
15 This driver supports the SER12 modems either full or half duplex.
16 Its baud rate may be changed via the `baud' module parameter,
19 This is the recommended driver for SER12 type modems,
30 This driver supports the par96 and picpar modems.
34 This driver supports the EPP modem.
42 is responsible for regenerating the receiver bit clock, as well as
43 for handling the HDLC protocol. The modem connects to a serial port,
[all …]
|
| D | ipvs-sysctl.txt | 6 It sets the always mode drop rate, which is used in the mode 3
7 of the drop_rate defense.
12 It sets the available memory threshold (in pages), which is
13 used in the automatic modes of defense. When there is no
14 enough available memory, the respective strategy will be
15 enabled and the variable is automatically set to 2, otherwise
16 the strategy is disabled and the variable is set to 1.
22 If set, disable the director function while the server is
29 port reuse. It is a bitmap, with the values being:
32 connection will be delivered to the same real server that was
[all …]
|
| D | fib_trie.txt | 6 An end node with data. This has a copy of the relevant key, along
12 indexed through a subset of the key. See Level Compression.
17 The number of bits in the key segment used for indexing into the
18 child array - the "child index". See Level Compression.
21 The position (in the key) of the key segment used for indexing into
22 the child array. See Path Compression.
25 Any given tnode is linked to from the child array of its parent, using
26 a segment of the key specified by the parent's "pos" and "bits"
28 adjacent to the parent (pos+bits), but there will be some bits
29 in the key skipped over because they represent a single path with no
[all …]
|
| D | scaling.txt | 1 Scaling in the Linux Networking Stack
7 This document describes a set of complementary techniques in the Linux
30 the other scaling techniques is to increase performance uniformly.
32 that is not the focus of these techniques.
34 The filter used in RSS is typically a hash function over the network
39 by masking out the low order seven bits of the computed hash for the
40 packet (usually a Toeplitz hash), taking this number as a key into the
41 indirection table and reading the corresponding value.
51 module parameter for specifying the number of hardware queues to
52 configure. In the bnx2x driver, for instance, this parameter is called
[all …]
|
| D | e100.txt | 1 Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
21 This file describes the Linux* Base Driver for the Intel(R) PRO/100 Family of
24 For questions related to hardware requirements, refer to the documentation
32 Channel Bonding documentation can be found in the Linux kernel source:
39 For more information on how to identify your adapter, go to the Adapter &
44 For the latest Intel network drivers for Linux, refer to the following
45 website. In the search field, enter your adapter name or type, or use the
46 networking link on the left to search for your adapter:
53 The default value for each parameter is generally the recommended setting,
57 structure that describes a receive buffer and its attributes to the network
[all …]
|
| D | rxrpc.txt | 38 reliable virtual connections using UDP over IPv4 (or IPv6) as the transport
39 layer, but implements a real network protocol; and there's the presentation
57 making the session part of it a Linux network protocol (AF_RXRPC).
59 (2) A two-phase protocol. The client transmits a blob (the request) and then
60 receives a blob (the reply), and the server receives the request and then
61 transmits the reply.
63 (3) Retention of the reusable bits of the transport system set up for one call
66 (4) A secure protocol, using the Linux kernel's key retention facility to
67 manage security on the client end. The server end must of necessity be
71 left to the application. AF_RXRPC only deals in blobs. Even the operation ID
[all …]
|
| D | dccp.txt | 23 needs to be enabled in order for the protocol to function properly. In the Linux
24 implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as
25 the TCP-friendly CCID3 (RFC 4342), are optional.
31 DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol
37 The Linux DCCP implementation does not currently support all the features that are
43 For more up-to-date versions of the DCCP implementation, please consider using
44 the experimental DCCP test tree; instructions for checking this out are on:
50 DCCP_SOCKOPT_QPOLICY_ID sets the dequeuing policy for outgoing packets. It takes
51 a policy ID as argument and can only be set before the connection (i.e. changes
53 defined: the "simple" policy (DCCPQ_POLICY_SIMPLE), which does nothing special,
[all …]
|
| D | phy.txt | 9 to a MAC layer, which communicates with the physical connection through a
10 PHY. The PHY concerns itself with negotiating link parameters with the link
11 partner on the other side of the network connection (typically, an ethernet
15 While these devices are distinct from the network devices, and conform to a
16 standard layout for the registers, it has been common practice to integrate
17 the PHY management code with the network driver. This has resulted in large
19 sometimes quite different) ethernet controllers connected to the same
20 management bus, it is difficult to ensure safe use of the bus.
22 Since the PHYs are devices, and the management busses through which they are
23 accessed are, in fact, busses, the PHY Abstraction Layer treats them as such.
[all …]
|
| D | e1000e.txt | 22 the e1000 driver, not the e1000e driver due to the 82546 part being used
25 For more information on how to identify your adapter, go to the Adapter &
30 For the latest Intel network drivers for Linux, refer to the following
31 website. In the search field, enter your adapter name or type, or use the
32 networking link on the left to search for your adapter:
39 The default value for each parameter is generally the recommended setting,
42 NOTES: For more information about the InterruptThrottleRate,
44 parameters, see the application note at:
53 The driver can limit the amount of interrupts per second that the adapter
54 will generate for incoming packets. It does this by writing a value to the
[all …]
|
| /linux-4.4.14/Documentation/cpu-freq/ |
| D | pcc-cpufreq.txt | 11 * it under the terms of the GNU General Public License as published by
12 * the Free Software Foundation; version 2 of the License.
14 * This program is distributed in the hope that it will be useful, but
15 * WITHOUT ANY WARRANTY; without even the implied warranty of
17 * INFRINGEMENT. See the GNU General Public License for more details.
19 * You should have received a copy of the GNU General Public License along
20 * with this program; if not, write to the Free Software Foundation, Inc.,
46 Processor Clocking Control (PCC) is an interface between the platform
48 performance (ie: frequency) between the platform firmware and the OS.
50 The PCC driver (pcc-cpufreq) allows OSPM to take advantage of the PCC
[all …]
|
| D | intel-pstate.txt | 4 This driver provides an interface to control the P state selection for
6 modes based on the processor model, legacy mode and Hardware P state (HWP)
9 In legacy mode, the Intel P-state implements two internal governors,
10 performance and powersave, that differ from the general cpufreq governors of
11 the same name (the general cpufreq governors implement target(), whereas the
13 performance governor sets the max_perf_pct and min_perf_pct to 100; that is,
14 the governor selects the highest available P state to maximize the performance
15 of the core. The internal powersave governor selects the appropriate P state
16 based on the current load on the CPU.
18 In HWP mode P state selection is implemented in the processor
[all …]
|
| D | governors.txt | 1 CPU frequency and voltage scaling code in the Linux(TM) kernel
16 Clock scaling allows you to change the clock speed of the CPUs on the
17 fly. This is a nice method to save battery power, because the lower
18 the clock speed, the less power the CPU consumes.
25 2. Governors In the Linux Kernel
32 3. The Governor Interface in the CPUfreq Core
39 Most cpufreq drivers (except the intel_pstate and longrun) or even most
40 cpu frequency scaling algorithms only offer the CPU to be set to one
41 frequency. In order to offer dynamic frequency scaling, the cpufreq
44 call instead of the existing "->setpolicy" call. For "longrun", all
[all …]
|
| /linux-4.4.14/Documentation/s390/ |
| D | monreader.txt | 12 This item delivers a new Linux API in the form of a misc char device that is
13 usable from user space and allows read access to the z/VM Monitor Records
14 collected by the *MONITOR System Service of z/VM.
20 order to allow IUCV connections to the *MONITOR service, i.e. it needs the
21 IUCV *MONITOR statement in its user entry. If the monitor DCSS to be used is
22 restricted (likely), you also need the NAMESAVE <DCSS NAME> statement.
23 This item will use the IUCV device driver to access the z/VM services, so you
26 There are two options for being able to load the monitor DCSS (examples assume
27 that the monitor DCSS begins at 144 MB and ends at 152 MB). You can query the
28 location of the monitor DCSS with the Class E privileged CP command Q NSS MAP
[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
20 attachment functionality itself, or the operating system provides for a
21 unified method to access the hardware, providing all the functionality that
24 The document does not intend to explain the ESA/390 hardware architecture in
25 every detail.This information can be obtained from the ESA/390 Principles of
30 the hardware.
32 The common device support layer comprises the I/O support routines defined
37 In order to write a driver for S/390, you also need to look into the interface
[all …]
|
| D | 3270.txt | 3 This file describes the driver that supports local channel attachment
17 You may have 3270s in-house and not know it. If you're using the
19 the command "DEF GRAF <hex-address>" This paper presumes you will be
20 defining four 3270s with the CP/CMS commands
29 workstation. With the DEF GRAF command, an application such as xterm,
33 This paper covers installation of the driver and operation of a
39 You install the driver by installing a patch, doing a kernel build, and
40 running the configuration script (config3270.sh, in this directory).
42 WARNING: If you are using 3270 console support, you must rerun the
43 configuration script every time you change the console's address (perhaps
[all …]
|
| /linux-4.4.14/Documentation/acpi/ |
| D | namespace.txt | 10 device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
12 hierarchy there is a corresponding symbolic link in the
14 This document illustrates the structure of the ACPI device tree.
19 Thanks for the help from Zhang Rui <rui.zhang@intel.com> and Rafael J.
25 The ACPI firmware sets up RSDP (Root System Description Pointer) in the
26 system memory address space pointing to the XSDT (Extended System
27 Description Table). The XSDT always points to the FADT (Fixed ACPI
28 Description Table) using its first entry, the data within the FADT
30 of the hardware. The FADT contains a pointer to the DSDT
38 of the DSDT along with the contents of SSDTs represents a hierarchical
[all …]
|
| D | scan_handlers.txt | 6 During system initialization and ACPI-based device hot-add, the ACPI namespace
9 registered with the driver core for every device object in the ACPI namespace
10 and the hierarchy of those struct acpi_device objects reflects the namespace
11 layout (i.e. parent device objects in the namespace are represented by parent
14 should not be confused with struct device_node objects used by the Device Trees
15 parsing code (although their role is analogous to the role of those objects).
22 information from the device objects represented by them and populating them with
24 been registered. For example, if the given device node represents a PCI host
25 bridge, its registration should cause the PCI bus under that bridge to be
26 enumerated and PCI devices on that bus to be registered with the driver core.
[all …]
|
| D | enumeration.txt | 7 In addition we are starting to see peripherals integrated in the
11 In order to support this and re-use the existing drivers as much as
22 resources) this implementation follows the Device Tree way as much as
26 I2C), creates the physical devices and binds them to their ACPI handle in
27 the ACPI namespace.
29 This means that when ACPI_HANDLE(dev) returns non-NULL the device was
37 for the device and add supported ACPI IDs. If this same IP-block is used on
38 some other non-ACPI platform, the driver might work out of the box or needs
42 straightforward. Here is the simplest example:
59 If the driver needs to perform more complex initialization like getting and
[all …]
|
| /linux-4.4.14/Documentation/timers/ |
| D | highres.txt | 4 Further information can be found in the paper of the OLS 2006 talk "hrtimers
5 and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can
6 be found on the OLS website:
12 The slides contain five figures (pages 2, 15, 18, 20, 22), which illustrate the
13 changes in the time(r) related Linux subsystems. Figure #1 (p. 2) shows the
14 design of the Linux time(r) system before hrtimers and other building blocks
17 Note: the paper and the slides are talking about "clock event source", while we
18 switched to the name "clock event devices" in meantime.
20 The design contains the following basic building blocks:
32 The hrtimer base infrastructure was merged into the 2.6.16 kernel. Details of
[all …]
|
| /linux-4.4.14/Documentation/hid/ |
| D | hidraw.txt | 6 received are not parsed by the HID parser, but are sent to and received from
7 the device unmodified.
9 Hidraw should be used if the userspace application knows exactly how to
10 communicate with the hardware device, and is able to construct the HID
11 reports manually. This is often the case when making userspace drivers for
17 through it, checking them against the device's report descriptor, such
19 Hidraw is the only alternative, short of writing a custom kernel driver, for
23 of the underlying hardware type. Currently, Hidraw is implemented for USB
24 and Bluetooth. In the future, as new hardware bus types are developed which
25 use the HID specification, hidraw will be expanded to add support for these
[all …]
|
| D | hiddev.txt | 5 In addition to the normal input type HID devices, USB also uses the
11 To support these disparate requirements, the Linux USB system provides
13 * the input subsystem, which converts HID events into normal input
16 * the hiddev interface, which provides fairly raw HID events
19 the following :
27 events into the input subsystem, but these have no effect on the hid
32 The hiddev interface is a char interface using the normal USB major,
33 with the minor numbers starting at 96 and finishing at 111. Therefore,
34 you need the following commands:
52 So you point your hiddev compliant user-space program at the correct
[all …]
|
| D | uhid.txt | 6 relies heavily on the definitions declared there.
9 device connected to the user-space controlled bus. The UHID API defines the I/O
10 events provided from the kernel to user-space and vice versa.
18 dynamically so you need to rely on udev (or similar) to create the device node.
22 device with the HID subsystem, then you need to open /dev/uhid once for each
37 The "type" field contains the ID of the event. Depending on the ID different
43 The "type" field defines the payload. For each type, there is a
44 payload-structure available in the union "u" (except for empty payloads). This
48 register the device. UHID will respond with an UHID_START event. You can now
49 start sending data to and reading data from UHID. However, unless UHID sends the
[all …]
|
| /linux-4.4.14/Documentation/sound/alsa/ |
| D | HD-Audio.txt | 9 HD-audio is the new standard on-board audio component on modern PCs
11 time ago, there are often problems with new machines. A part of the
12 problem is broken BIOS, and the rest is the driver implementation.
13 This document explains the brief trouble-shooting and debugging
14 methods for the HD-audio hardware.
16 The HD-audio component consists of two parts: the controller chip and
17 the codec chips on the HD-audio bus. Linux provides a single driver
18 for all controllers, snd-hda-intel. Although the driver name contains
20 all controller chips by other companies. Since the HD-audio
21 controllers are supposed to be compatible, the single snd-hda-driver
[all …]
|
| D | HD-Audio-Controls.txt | 1 This file explains the codec-specific mixer controls.
7 This is an enum control to change the surround-channel setup,
8 appears only when the surround channels are available.
9 It gives the number of channels to be used, "2ch", "4ch", "6ch",
10 and "8ch". According to the configuration, this also controls the
14 This is an enum control to change the auto-mute behavior of the
19 "Disabled" and "Enabled" state. When enabled, the speaker is muted
25 mutes the speakers, but not line-outs. When line-out+speaker is
34 This control enables/disables the analog-loopback circuit. This
36 (see HD-Audio.txt). Note that on some codecs the analog-loopback
[all …]
|
| D | OSS-Emulation.txt | 10 ALSA provides a powerful OSS emulation on the kernel.
13 When you need to access the OSS PCM, mixer or sequencer devices, the
16 These modules are loaded automatically when the corresponding service
18 the card number and the minor unit number. Usually you don't have to
21 Only necessary step for auto-loading of OSS modules is to define the
26 As the second card, define sound-slot-1 as well.
27 Note that you can't use the aliased name as the target name (i.e.
28 "alias sound-slot-0 snd-card-0" doesn't work any more like the old
32 /proc/asound/oss/sndstat. This shows in the same syntax of
33 /dev/sndstat, which is available on the commercial OSS driver.
[all …]
|
| D | timestamping.txt | 3 - Trigger_tstamp is the system time snapshot taken when the .trigger
4 callback is invoked. This snapshot is taken by the ALSA core in the
7 estimate with a delay. In the latter two cases, the low-level driver
8 is responsible for updating the trigger_tstamp at the most appropriate
9 and precise moment. Applications should not rely solely on the first
10 trigger_tstamp but update their internal calculations if the driver
13 - tstamp is the current system timestamp updated during the last
15 The difference (tstamp - trigger_tstamp) defines the elapsed time.
18 and delay, which combined with the trigger and current system
19 timestamps allow for applications to keep track of the 'fullness' of
[all …]
|
| /linux-4.4.14/fs/jffs2/ |
| D | README.Locking | 5 This document attempts to describe the existing locking rules for
14 contiguous allocation of space on the medium. It is automatically
17 the garbage collector will obtain this right at the beginning of
18 jffs2_garbage_collect_pass() and release it at the end, thereby
19 preventing any other write activity on the file system during a
22 When writing new nodes, the alloc_sem must be held until the new nodes
23 have been properly linked into the data structures for the inode to
24 which they belong. This is for the benefit of NAND flash - adding new
25 nodes to an inode may obsolete old ones, and by holding the alloc_sem
26 until this happens we ensure that any data in the write-buffer at the
[all …]
|
| /linux-4.4.14/Documentation/mtd/nand/ |
| D | pxa3xx-nand.txt | 6 SoC (aka NFCv1 and NFCv2), with an emphasis on the latter.
16 we'll have this layout in the pages:
22 The driver reads the data and spare portions independently and builds an internal
23 buffer with this layout (in the 4 KiB page case):
29 Also, for the READOOB command the driver disables the ECC and reads a 'spare + ECC'
39 The driver accommodates this data to expose the NAND core a contiguous buffer
48 Note that the actual BCH mode: BCH-4 or BCH-8 will depend on the way
49 the controller is configured to transfer the data.
51 In the BCH mode the ECC code will be calculated for each transferred chunk
52 and expected to be located (when reading/programming) right after the spare
[all …]
|
| /linux-4.4.14/Documentation/video4linux/bttv/ |
| D | README.quirks | 2 Below is what the bt878 data book says about the PCI bug compatibility
3 modes of the bt878 chip.
5 The triton1 insmod option sets the EN_TBFX bit in the control register.
6 The vsfx insmod option does the same for EN_VSFX bit. If you have
11 enabled automagically for known-buggy chipsets (look at the kernel
23 The PCI REQ signal is the logical-or of the incoming function requests.
25 demultiplexed by the audio request signal. Thus the arbiter defaults to
26 the video function at power-up and parks there during no requests for
27 bus access. This is desirable since the video will request the bus more
28 often. However, the audio will have highest bus access priority. Thus
[all …]
|
| /linux-4.4.14/drivers/staging/speakup/ |
| D | Kconfig | 7 This is the Speakup screen reader. Think of it as a
8 video console for blind people. If built in to the
9 kernel, it can speak everything on the text console from
12 There is also a mailing list at the above url that you
25 must answer either y or m to at least one of the
27 the synthesizer drivers below can only be built as
36 requires software to be pre-loaded on to the card before
37 the module can be loaded. See the decpc choice below
41 one of the listed synthesizers, you should say n.
47 This is the Speakup driver for the Accent SA
[all …]
|
| D | spkguide.txt | 11 Copyright (c) 2009, 2010 the Speakup Team
14 under the terms of the GNU Free Documentation License, Version 1.2 or
15 any later version published by the Free Software Foundation; with no
17 copy of the license is included in the section entitled "GNU Free
22 The purpose of this document is to familiarize users with the user
24 for installing or obtaining Speakup, visit the web site at
25 http://linux-speakup.org/. Speakup is a set of patches to the standard
27 a part of a monolithic kernel. These details are beyond the scope of
28 this manual, but the user may need to be aware of the module
30 Speakup. If Speakup is built as a part of a monolithic kernel, and the
[all …]
|
| /linux-4.4.14/Documentation/thermal/ |
| D | power_allocator.txt | 7 The governor works optimally with the following two passive trip points:
9 1. "switch on" trip point: temperature above which the governor
10 control loop starts operating. This is the first passive trip
11 point of the thermal zone.
13 2. "desired temperature" trip point: it should be higher than the
14 "switch on" trip point. This the target temperature the governor
15 is controlling for. This is the last passive trip point of the
23 temperature as the control input and power as the controlled output:
29 err_integral is the sum of previous errors
32 It is similar to the one depicted below:
[all …]
|
| D | cpu-cooling-api.txt | 13 to the caller. The binding of the cooling devices to the trip point is left for
14 the user. The registration APIs returns the cooling device pointer.
22 This interface function registers the cpufreq cooling device with the name
26 clip_cpus: cpumask of cpus where the frequency constraints will happen.
31 This interface function registers the cpufreq cooling device with
32 the name "thermal-cpufreq-%x" linking it with a device tree node, in
33 order to bind it via the thermal DT code. This api can support multiple
36 np: pointer to the cooling device device tree node
37 clip_cpus: cpumask of cpus where the frequency constraints will happen.
44 cooling device. Using this function, the cooling device will
[all …]
|
| /linux-4.4.14/Documentation/arm/ |
| D | Booting | 10 program that runs before the main kernel. The boot loader is expected
11 to initialise various devices, and eventually call the Linux kernel,
12 passing information to the kernel.
14 Essentially, the boot loader should provide (as a minimum) the
17 1. Setup and initialise the RAM.
19 3. Detect the machine type.
20 4. Setup the kernel tagged list.
22 6. Call the kernel image.
31 The boot loader is expected to find and initialise all RAM that the
32 kernel will use for volatile data storage in the system. It performs
[all …]
|
| D | cluster-pm-race-avoidance.txt | 4 This file documents the algorithm which is used to coordinate CPU and
8 The section "Rationale" explains what the algorithm is for and why it is
10 of the system. The other sections explain the actual details of the
17 In a system containing multiple CPUs, it is desirable to have the
18 ability to turn off individual CPUs when the system is idle, reducing
22 to have the ability to turn off entire clusters.
26 of independently running CPUs, while the OS continues to run. This
37 power-down and power-up at the cluster level.
40 based protocol for performing the needed coordination. It aims to be as
41 lightweight as possible, while providing the required safety properties.
[all …]
|
| D | Interrupts | 4 This is the first kernel that contains a major shake up of some of the
7 Firstly, it contains some pretty major changes to the way we handle the
12 allow more flexible TLB handling for the future.
14 Secondly, the IRQ subsystem.
16 The 2.5 kernels will be having major changes to the way IRQs are handled.
17 Unfortunately, this means that machine types that touch the irq_desc[]
21 Lets take an example. On the Assabet with Neponset, we have:
31 exclusive of each other - if you're processing one interrupt from the
33 finish processing before you can service the new interrupt. Eg, an
34 IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and
[all …]
|
| /linux-4.4.14/Documentation/ABI/testing/ |
| D | dev-kmsg | 6 to the kernel's printk buffer.
9 Every write() to the opened device node places a log entry in
10 the kernel's printk buffer.
13 carries the syslog priority and facility. The single decimal
14 prefix number is composed of the 3 lowest bits being the syslog
15 priority and the higher bits the syslog facility number.
17 If no prefix is given, the priority number is the default kernel
18 log priority and the facility number is set to LOG_USER (1). It
19 is not possible to inject messages from userspace with the
20 facility number LOG_KERN (0), to make sure that the origin of
[all …]
|
| D | sysfs-devices-power | 6 allowing the user space to check and modify some power
13 The /sys/devices/.../power/wakeup attribute allows the user
14 space to check if the device is enabled to wake up the system
15 from sleep states, such as the memory sleep state (suspend to
20 used to activate the system from a sleep state. Such devices
21 have one of the following two values for the sysfs power/wakeup
24 + "enabled\n" to issue the events;
27 In that cases the user space can change the setting represented
28 by the contents of this file by writing either "enabled", or
31 For the devices that are not capable of generating system wakeup
[all …]
|
| D | sysfs-firmware-dmi-entries | 6 SMBIOS tables to the operating system. Getting at this
10 The kernel itself does not rely on the majority of the
12 cannot ensure that the data as exported to userland is
16 each entry has a common header indicating the type and
17 length of the entry, as well as a firmware-provided
21 Some entries are required by the specification, but many
27 Multiple entries of the same type are allowed. In order
29 assigned by the operating system an 'instance', which is
31 to say, if there are 'N' multiple entries with the same type
32 'T' in the DMI tables (adjacent or spread apart, it
[all …]
|
| D | sysfs-class-net-statistics | 6 Indicates the number of collisions seen by this network device.
14 Indicates the number of multicast packets received by this
22 Indicates the number of bytes received by this network device.
23 See the network driver for the exact meaning of when this
31 Indicates the number of compressed packets received by this
40 Indicates the number of packets received with a CRC (FCS) error
41 by this network device. Note that the specific meaning might
42 depend on the MAC layer used by the interface.
49 Indicates the number of packets received by the network device
50 but dropped, that are not forwarded to the upper layers for
[all …]
|
| /linux-4.4.14/Documentation/crypto/ |
| D | asymmetric-keys.txt | 19 The "asymmetric" key type is designed to be a container for the keys used in
20 public-key cryptography, without imposing any particular restrictions on the
21 form or mechanism of the cryptography or form of the key.
24 associated with the key and provides operations to describe and destroy it.
25 However, no requirement is made that the key data actually be stored in the
30 a TPM) that might be used to both retain the relevant key and perform
31 operations using that key. In such a case, the asymmetric key would then
32 merely be an interface to the TPM driver.
34 Also provided is the concept of a data parser. Data parsers are responsible
35 for extracting information from the blobs of data passed to the instantiation
[all …]
|
| /linux-4.4.14/Documentation/video4linux/cx2341x/ |
| D | fw-calling.txt | 1 This page describes how to make calls to the firmware api.
6 The preferred calling convention is known as the firmware mailbox. The
7 mailboxes are basically a fixed length array that serves as the call-stack.
9 Firmware mailboxes can be located by searching the encoder and decoder memory
17 reserved for API calls. The second 10 are used by the firmware for event
29 The flags are defined in the following table. The direction is from the
30 perspective of the firmware.
34 2 O Firmware has processed the command.
35 1 I Driver has finished setting the parameters.
39 The command is a 32-bit enumerator. The API specifics may be found in the
[all …]
|
| D | fw-dma.txt | 1 This page describes the structures and procedures used by the cx2341x DMA
8 engine to efficiently transfer large volumes of data between the card and main
15 contiguous buffer, the driver can allocate several smaller buffers.
17 In practice, I've seen the average transfer to be roughly 80K, but transfers
19 important, because that is the largest block that the kernel can normally
20 allocate. Even still, 128K blocks are hard to come by, so the driver writer is
21 urged to choose a smaller block size and learn the scatter-gather technique.
25 Note: the hardware expects little-endian data ('intel format').
30 This section describes, in general, the order of events when handling DMA
33 - The card raises the Encoder interrupt.
[all …]
|
| D | fw-upload.txt | 1 This document describes how to upload the cx2341x firmware to the card.
6 See the web pages of the various projects that uses this chip for information
7 on how to obtain the firmware.
12 - The 1st 32-bit word of the Encoder image is 0x0000da7
13 - The 1st 32-bit word of the Decoder image is 0x00003a7
19 - Issue the FWapi command to stop the encoder if it is running. Wait for the
21 - Issue the FWapi command to stop the decoder if it is running. Wait for the
23 - Issue the I2C command to the digitizer to stop emitting VSYNC events.
24 - Issue the FWapi command to halt the encoder's firmware.
26 - Issue the FWapi command to halt the decoder's firmware.
[all …]
|
| /linux-4.4.14/Documentation/powerpc/ |
| D | cxlflash.txt | 9 memory and generate page faults. As a result, the host interface to
10 an adapter running in CAPI mode does not require the data buffers to
11 be mapped to the device's memory (IOMMU bypass) nor does it require
16 This abstraction simplifies the infrastructure and programming
21 directly talk to a device (network or storage) bypassing the typical
25 The CXL Flash Adapter Driver is a kernel module that sits in the
26 SCSI stack as a low level device driver (below the SCSI disk and
27 protocol drivers) for the IBM CXL Flash Adapter. This driver is
28 responsible for the initialization of the adapter, setting up the
30 communicates directly the Flash Accelerator Functional Unit (AFU)
[all …]
|
| D | cxl.txt | 7 The coherent accelerator interface is designed to allow the
9 POWER system. These devices need to adhere to the Coherent
12 IBM refers to this as the Coherent Accelerator Processor Interface
13 or CAPI. In the kernel it's referred to by the name CXL to avoid
14 confusion with the ISDN CAPI subsystem.
16 Coherent in this context means that the accelerator and CPUs can
17 both access system memory directly and with the same effective
38 unit which is part of the PCIe Host Bridge (PHB). This is managed
39 by Linux by calls into OPAL. Linux doesn't directly program the
43 The POWER Service Layer (PSL) and the Accelerator Function Unit
[all …]
|
| D | hvcs.txt | 8 NOTE:Eight space tabs are the optimum editor setting for reading this file.
33 This is the device driver for the IBM Hypervisor Virtual Console Server,
35 space applications access to the system consoles of logically partitioned
36 operating systems (Linux and AIX) running on the same partitioned Power5
48 though some care was taken to abstract the architecture dependent firmware
49 calls from the driver code.
51 Sysfs must be mounted on the system so that the user can determine which
53 for sysfs mounting are outside the scope of this document.
60 requested by the registering driver. The hvcs driver asks the tty layer
64 If the default number of device entries is adequate then this driver can be
[all …]
|
| D | qe_firmware.txt | 31 the particular license, please see the license text that is distributed with
32 the firmware.
44 In this document, the term 'microcode' refers to the sequence of 32-bit
45 integers that compose the actual QE microcode.
47 The term 'firmware' refers to a binary blob that contains the microcode as
50 1) describes the microcode's purpose
51 2) describes how and where to upload the microcode
52 3) specifies the values of various registers
62 disables the microcode) must be performed first.
64 QE microcode is uploaded using the following procedure:
[all …]
|
| D | bootwrapper.txt | 5 PowerPC image targets compresses and wraps the kernel image (vmlinux) with
6 a boot wrapper to make it usable by the system firmware. There is no
7 standard PowerPC firmware interface, so the boot wrapper is designed to
10 The boot wrapper can be found in the arch/powerpc/boot/ directory. The
11 Makefile in that directory has targets for all the available image types.
12 The different image types are used to support all of the various firmware
13 interfaces found on PowerPC platforms. OpenFirmware is the most commonly
19 The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
20 it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
21 image. The details of the build system is discussed in the next section.
[all …]
|
| D | pci_iov_resource_on_powernv.txt | 6 This document describes the requirement from hardware for PCI MMIO resource
8 requirement. The first two sections describe the concepts of Partitionable
9 Endpoints and the implementation on P8 (IODA2). The next two sections talks
14 A Partitionable Endpoint (PE) is a way to group the various resources
17 to freeze a device that is causing errors in order to limit the possibility
26 captures things like the details of the error that caused the freeze etc., but
29 The interesting part is how the various PCIe transactions (MMIO, DMA, ...)
34 is a completely separate HW entity that replicates the entire logic, so has
44 memory but accessed in HW by the chip) that provides a direct
46 We call this the RTT.
[all …]
|
| D | transactional_memory.txt | 5 its use by user programs. It is not currently used by the kernel itself.
40 /* Retry the transaction if it failed because it conflicted with
45 The 'tbegin' instruction denotes the start point, and 'tend' the end point.
46 Between these points the processor is in 'Transactional' state; any memory
48 transactional or non-transactional accesses within the system. In this
49 example, the transaction completes as though it were normal straight-line code
51 atomic move of money from the current account to the savings account has been
52 performed. Even though the normal ld/std instructions are used (note no
56 If, in the meantime, there is a conflict with the locations accessed by the
57 transaction, the transaction will be aborted by the CPU. Register and memory
[all …]
|
| /linux-4.4.14/Documentation/video4linux/ |
| D | omap3isp.txt | 14 This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP)
19 The driver has been successfully used on the following versions of OMAP 3:
26 Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel
33 The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP
34 having one subdev to represent it. Each of the subdevs provide a V4L2 subdev
46 Each possible link in the ISP is modelled by a link in the Media controller
50 Controlling the OMAP 3 ISP
53 In general, the settings given to the OMAP 3 ISP take effect at the beginning
54 of the following frame. This is done when the module becomes idle during the
55 vertical blanking period on the sensor. In memory-to-memory operation the pipe
[all …]
|
| D | vivid.txt | 17 you can test the various features without requiring special hardware.
19 This document describes the features implemented by this driver:
24 - Support for the alpha color component
44 Section 1: Configuring the driver
80 Section 1: Configuring the driver
83 By default the driver will create a single instance that has a video capture
89 all configurable using the following module options:
96 Each value is a bitmask with the following meaning:
106 So to create four instances, the first two with just one video capture
107 device, the second two with just one video output device you would pass
[all …]
|
| D | videobuf | 1 An introduction to the videobuf layer
6 and user space. It handles the allocation and management of buffers for
7 the storage of video frames. There is a set of functions which can be used
8 to implement many of the standard POSIX I/O system calls, including read(),
10 implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
12 control. Using videobuf imposes a few design decisions on the driver
13 author, but the payback comes in the form of reduced code in the driver and
14 a consistent implementation of the V4L2 user-space API.
18 Not all video devices use the same kind of buffers. In fact, there are (at
21 - Buffers which are scattered in both the physical and (kernel) virtual
[all …]
|
| /linux-4.4.14/Documentation/filesystems/nfs/ |
| D | pnfs-block-server.txt | 3 The Linux NFS server now supports the pNFS block layout extension. In this
4 case the NFS server acts as Metadata Server (MDS) for pNFS, which in addition
5 to handling all the metadata access to the NFS export also hands out layouts
6 to the clients to directly access the underlying block devices that are
7 shared with the client.
9 To use pNFS block layouts with with the Linux NFS server the exported file
10 system needs to support the pNFS block layouts (currently just XFS), and the
12 to the clients in addition to the MDS. As of now the file system needs to
13 sit directly on the exported volume, striping or concatenation of
14 volumes on the MDS and clients is not supported yet.
[all …]
|
| D | fault_injection.txt | 6 can help the developer find and fix bugs before their code is shipped in a
7 production system. Injecting an error on the Linux NFS server will allow us to
8 observe how the client reacts and if it manages to recover its state correctly.
10 NFSD_FAULT_INJECTION must be selected when configuring the kernel to use this
16 On the client, mount the fault injection server through NFS v4.0+ and do some
19 On the server, mount the debugfs filesystem to <debug_dir> and ls
21 injecting faults on the NFS server. As root, write a number n to the file
22 corresponding to the action you want the server to take. The server will then
23 process the first n items it finds. So if you want to forget 5 locks, echo '5'
24 to <debug_dir>/nfsd/forget_locks. A value of 0 will tell the server to forget
[all …]
|
| /linux-4.4.14/Documentation/isdn/ |
| D | README.sc | 1 Welcome to Beta Release 2 of the combination ISDN driver for SpellCaster's
2 ISA ISDN adapters. Please note this release 2 includes support for the
4 guaranteed to fail. If you have a DataCommute/PRI installed in the test
11 through the web site or the mailing list but such support is totally at
13 total risk by using this driver, we encourage you to join the beta
16 To join the Linux beta mailing list, send a message to:
17 majordomo@spellcast.com with the words "subscribe linux-beta" as the only
18 contents of the message. Do not include a signature. If you choose to
20 the same address with the words "unsubscribe linux-beta" as its only
28 1.3 How do I setup my system with the correct software to use
[all …]
|
| D | INTERFACE | 3 Description of the Interface between Linklevel and Hardwarelevel
8 is based on the struct isdn_if (defined in isdnif.h).
10 An HL-driver can register itself at LL by calling the function
12 to preset some of the fields of isdn_if. The LL sets the rest of
13 the fields. All further communication is done via callbacks using
14 the function-pointers defined in isdn_if.
18 During development of the ISDN subsystem, several changes have been
19 made to the interface. Before it went into kernel, the package
21 was 0.7.4. When the subsystem went into kernel, every functional unit
29 c.c is the revision of the common code.
[all …]
|
| D | README.icn | 3 You can get the ICN-ISDN-card from:
6 Versbacher Röthe 159
15 The card communicates with the PC by two interfaces:
17 configured with the switches.
19 over the whole range of 16MB. Isdn4linux only uses a 16k window.
20 The base address of the window can be configured when loading
21 the lowlevel-module (see README). If using more than one card,
22 all cards are mapped to the same window and activated as needed.
24 Setting up the IO-address dipswitches for the ICN-ISDN-card:
29 1. Setting for the card with hook-switches:
[all …]
|
| D | README.act2000 | 3 This document describes the ACT2000 driver for the
7 Version. Currently, only the ISA-Bus version of the card is supported.
11 manually using the DIP switches.
13 Setting up the DIP switches for the IBM Active 2000 ISDN card:
39 The ACT2000 driver may either be built into the kernel or as a module.
40 Initialization depends on how the driver is built:
42 Driver built into the kernel:
44 The ACT2000 driver can be configured using the commandline-feature while
45 loading the kernel with LILO or LOADLIN. It accepts the following syntax:
55 The idstring is an arbitrary string used for referencing the card
[all …]
|
| D | syncPPP.FAQ | 12 Q09: Starting the ipppd, I get only error messages from i4l
14 Q11: I can't connect. How can I check where the problem is.
22 here, the framing is character based. (e.g when
28 to the network layer and all PPP protocol
29 frames to the /dev/ippp* device.
30 So, the ipppd is a simple external network
33 If you login into a remote machine using the
34 /dev/ttyI* devices and then enable PPP on the
35 remote terminal server -> use the 'old' pppd
39 syncPPP machine .. use the network device part
[all …]
|
| D | README.diversion | 2 the isdn4linux and the HiSax module for passive cards.
3 Active cards, TAs and cards using a own or other driver than the HiSax
4 module need to be adapted to the HL<->LL interface described in a separate
6 the HiSax driver.
8 by Werner Cornelius (werner@isdn4linux.de or werner@titro.de) under the
12 it under the terms of the GNU General Public License as published by
13 the Free Software Foundation; either version 2 of the License, or
16 This program is distributed in the hope that it will be useful,
17 but WITHOUT ANY WARRANTY; without even the implied warranty of
18 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
[all …]
|
| D | INTERFACE.CAPI | 6 From the CAPI 2.0 specification:
15 requesting association with a CAPI device. Kernel CAPI then dispatches the
16 application registration to an available device, forwarding it to the
18 directions between the application and the hardware driver.
20 Format and semantics of CAPI messages are specified in the CAPI 2.0 standard.
26 CAPI drivers optionally register themselves with Kernel CAPI by calling the
28 capi_driver. This structure must be filled with the name and revision of the
30 registration can be revoked by calling the function unregister_capi_driver()
31 with a pointer to the same struct capi_driver.
33 CAPI drivers must register each of the ISDN devices they control with Kernel
[all …]
|
| D | README.hfc-pci | 1 The driver for the HFC-PCI and HFC-PCI-A chips from CCD may be used
3 Additionally the driver has a special feature which makes it possible
4 to read the echo-channel of the isdn bus. So all frames in both directions
6 When the echo logging feature is used the number of available B-channels
8 the card, not to the isdn line.
9 To activate the echo mode the following ioctls must be entered:
13 This reduces the available channels to 1. There must not be open connections
14 through this card when entering the command.
19 This enables the echo mode. If Hex logging is activated the isdnctrlx
20 devices show a output with a line beginning of HEX: for the providers
[all …]
|
| /linux-4.4.14/Documentation/m68k/ |
| D | kernel-options.txt | 14 Often I've been asked which command line options the Linux/m68k
15 kernel understands, or how the exact syntax for the ... option is, or
16 ... about the option ... . I hope, this document supplies all the
20 incomplete or missing. Please update the information and send in the
24 1) Overview of the Kernel's Option Processing
34 follows: If the option is known to the kernel itself, i.e. if the name
35 (the part before the '=') or, in some cases, the whole argument string
36 is known to the kernel, it belongs to class 1. Otherwise, if the
37 argument contains an '=', it is of class 2, and the definition is put
41 This document describes the valid kernel options for Linux/m68k in
[all …]
|
| D | README.buddha | 3 Geert Uytterhoeven based on the following specifications:
7 Register map of the Buddha IDE controller and the
8 Buddha-part of the Catweasel Zorro-II version
12 example leaving some address lines out of the equations...).
13 If you want to configure the board yourself (for example let
14 a Linux kernel configure the card), look at the Commodore
15 Docs. Reading the nibbles should give this information:
23 list, Rom-Vektor is valid, no second Autoconfig-board on the
26 Setting the base address should be done in two steps, just
27 as the Amiga Kickstart does: The lower nibble of the 8-Bit
[all …]
|
| /linux-4.4.14/Documentation/usb/ |
| D | persist.txt | 8 What is the problem?
10 According to the USB specification, when a USB bus is suspended the
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
18 conservative approach; in the absence of suspend current the computer
19 has no way to know what has actually happened. Perhaps the same
21 device plugged into the port. The system must assume the worst.
23 By default, Linux behaves according to the spec. If a USB host
24 controller loses power during a system suspend, then when the system
25 wakes up all the devices attached to that controller are treated as
[all …]
|
| D | gadget_serial.txt | 10 modify it under the terms of the GNU General Public License as
11 published by the Free Software Foundation; either version 2 of
12 the License, or (at your option) any later version.
14 This program is distributed in the hope that it will be useful,
15 but WITHOUT ANY WARRANTY; without even the implied warranty of
16 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
19 You should have received a copy of the GNU General Public
20 License along with this program; if not, write to the Free
24 This document and the gadget serial driver itself are
33 Versions of the gadget serial driver are available for the
[all …]
|
| D | power-management.txt | 15 * Changing the default idle-delay time
19 * Other parts of the driver interface
31 Power Management (PM) is the practice of saving energy by suspending
35 "resumed" (returned to a functional full-power state) when the kernel
38 suspended; an example would be reducing the CPU's clock rate. This
41 When the parts being suspended include the CPU and most of the rest of
42 the system, we speak of it as a "system suspend". When a particular
43 device is turned off while the system as a whole remains running, we
46 dynamic PM is implemented in the USB subsystem, although system PM is
50 System PM support is present only if the kernel was built with CONFIG_SUSPEND
[all …]
|
| /linux-4.4.14/Documentation/block/ |
| D | data-integrity.txt | 5 protect against data corruption. However, the detection of the
7 after the data was written. At that point the original data that the
10 The solution is to ensure that the disk is actually storing what the
11 application meant it to. Recent additions to both the SCSI family
17 ensures the individual sectors are written in the right order. And
18 for some protection schemes also that the I/O is written to the right
24 between adjacent nodes in the I/O path. The interesting thing about
25 DIF and the other integrity extensions is that the protection format
26 is well defined and every node in the I/O path can verify the
27 integrity of the I/O and reject it if corruption is detected. This
[all …]
|
| D | writeback_cache_control.txt | 8 Many storage devices, especially in the consumer market, come with volatile
9 write back caches. That means the devices signal I/O completion to the
10 operating system before data actually has hit the non-volatile storage. This
11 behavior obviously speeds up various workloads, but it means the operating
12 system needs to force data out to the non-volatile storage when it performs
16 control the caching behavior of the storage device. These mechanisms are
17 a forced cache flush, and the Force Unit Access (FUA) flag for requests.
23 The REQ_FLUSH flag can be OR ed into the r/w flags of a bio submitted from
24 the filesystem and will make sure the volatile cache of the storage device
25 has been flushed before the actual I/O operation is started. This explicitly
[all …]
|
| /linux-4.4.14/Documentation/x86/ |
| D | boot.txt | 4 On the x86 platform, the Linux kernel uses a rather complicated boot
6 well as the desire in the early days to have the kernel itself be a
7 bootable image, the complicated PC memory model and due to changed
8 expectations in the PC industry caused by the effective demise of
11 Currently, the following versions of the Linux/x86 boot protocol exist.
17 well as a formalized way to communicate between the
18 boot loader and the kernel. setup.S made relocatable,
19 although the traditional setup area still assumed
25 Lower the conventional memory ceiling. No overwrite
26 of the traditional setup area, thus making booting
[all …]
|
| D | kernel-stacks | 4 Most of the text from Keith Owens, hacked by AK
11 zombie. While the thread is in user space the kernel stack is empty
12 except for the thread_info structure at the bottom.
14 In addition to the per thread stacks, there are specialized stacks
15 associated with each CPU. These stacks are only used while the kernel
16 is in control on that CPU; when a CPU returns to user space the
21 Used for external hardware interrupts. If this is the first external
22 hardware interrupt (i.e. not a nested hardware interrupt) then the
23 kernel switches from the current task to the interrupt stack. Like
24 the split thread and interrupt stacks on i386, this gives more room
[all …]
|
| /linux-4.4.14/Documentation/fmc/ |
| D | carrier.txt | 4 Within the Linux bus framework, the FMC device is created and
5 registered by the carrier driver. For example, the PCI driver for the
8 do exactly the same for the VME carrier (actually, it should do it
9 twice, because the SVEC carries two FMC mezzanines). Similarly, an
13 The contents of the EEPROM within the FMC are used for identification
14 purposes, i.e. for matching the device with its own driver. For this
15 reason the device structure includes a complete copy of the EEPROM
16 (actually, the carrier driver may choose whether or not to return it -
17 for example we most likely won't have the whole EEPROM available for
20 The following listing shows the current structure defining a device.
[all …]
|
| D | fmc-write-eeprom.txt | 5 write it to the internal EEPROM of the mezzanine card. This driver uses
6 the `busid' generic parameter.
8 Overwriting the EEPROM is not something you should do daily, and it is
9 expected to only happen during manufacturing. For this reason, the
10 module makes it unlikely for the random user to change a working EEPROM.
12 However, since the EEPROM may include application-specific information
13 other than the identification, later versions of this packages added
14 write-support through sysfs. See *note Accessing the EEPROM::.
16 To avoid damaging the EEPROM content, the module takes the following
23 * If the file name ends with `.bin' it is written verbatim starting
[all …]
|
| /linux-4.4.14/Documentation/driver-model/ |
| D | binding.txt | 4 Driver binding is the process of associating a device with a device
6 because there have been bus-specific structures to represent the
7 devices and the drivers. With generic device and device driver
8 structures, most of the binding can take place using common code.
15 type in the system. When device_register is called for a device, it is
16 inserted into the end of this list. The bus object also contains a
18 for a driver, it is inserted at the end of this list. These are the
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
[all …]
|
| D | porting.txt | 2 Porting Drivers to the New Driver Model
14 Most of the work of porting devices drivers to the new model happens
15 at the bus driver layer. This was intentional, to minimize the
19 In a nutshell, the driver model consists of a set of objects that can
21 objects can replace fields in the bus-specific objects.
23 The generic objects must be registered with the driver model core. By
24 doing so, they will exported via the sysfs filesystem. sysfs can be
35 Step 1: Registering the bus driver.
38 - Define a struct bus_type for the bus driver.
45 - Register the bus type.
[all …]
|
| D | driver.txt | 4 See the kerneldoc for the struct device_driver.
12 device_driver represents the driver as a whole (not a particular
18 The driver must initialize at least the name and bus fields. It should
19 also initialize the devclass field (when it arrives), so it may obtain
20 the proper linkage internally. It should also initialize as many of
21 the callbacks as possible, though each is optional.
27 allocated. Below is an example declaration of the eepro100
28 driver. This declaration is hypothetical only; it relies on the driver
29 being converted completely to the new model.
41 Most drivers will not be able to be converted completely to the new
[all …]
|
| /linux-4.4.14/Documentation/device-mapper/ |
| D | verity.txt | 5 block devices using a cryptographic digest provided by the kernel crypto API.
17 This is the type of the on-disk hash format.
19 0 is the original format used in the Chromium OS.
21 the rest of the block is padded with zeros.
23 1 is the current format that should be used for new devices.
25 padded with zeros to the power of two.
28 This is the device containing data, the integrity of which needs to be
33 This is the device that supplies the hash tree data. It may be
34 specified similarly to the device path and may be the same device. If the
35 same device is used, the hash_start should be outside the configured
[all …]
|
| D | statistics.txt | 4 Device Mapper supports the collection of I/O statistics on user-defined
11 the range specified.
14 in the same format as /sys/block/*/stat or /proc/diskstats (see:
16 provided: total time spent reading and writing. When the histogram
17 argument is used, the 14th parameter is reported that represents the
19 the @stats_print message to the appropriate DM device via dmsetup.
21 The reported times are in milliseconds and the granularity depends on
22 the kernel ticks. When the option precise_timestamps is used, the
26 region_id, that is assigned when the region is created. The region_id
27 must be supplied when querying statistics about the region, deleting the
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/powerpc/nintendo/ |
| D | wii.txt | 7 This node represents the Nintendo Wii video game console.
16 This node represents the multi-function "Hollywood" chip, which packages
17 many of the devices found in the Nintendo Wii.
25 Represents the interface between the graphics processor and a external
31 - reg : should contain the VI registers location and length
32 - interrupts : should contain the VI interrupt
36 Represents the data and control interface between the main processor
42 - reg : should contain the PI registers location and length
46 Represents the "Flipper" interrupt controller within the "Hollywood" chip.
47 The node for the "Flipper" interrupt controller must be placed under
[all …]
|
| /linux-4.4.14/Documentation/i2c/ |
| D | functionality | 4 Because not every I2C or SMBus adapter implements everything in the
6 is implemented when it is given the option to attach to an adapter:
7 the client needs some way to check whether an adapter has the needed
14 For the most up-to-date list of functionality constants, please check
19 I2C_FUNC_10BIT_ADDR Handles the 10-bit address extensions
20 I2C_FUNC_PROTOCOL_MANGLING Knows about the I2C_M_IGNORE_NAK,
22 flags (which modify the I2C protocol!)
24 I2C_FUNC_SMBUS_QUICK Handles the SMBus write_quick command
25 I2C_FUNC_SMBUS_READ_BYTE Handles the SMBus read_byte command
26 I2C_FUNC_SMBUS_WRITE_BYTE Handles the SMBus write_byte command
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/powerpc/fsl/ |
| D | dcsr.txt | 6 to change. Some of the compatible strings that contain only generic names
8 the integration of the block with the rest of the chip.
15 This node defines the base address and range for the
16 defined DCSR Memory Map. Child nodes will describe the individual
25 The DCSR space exists in the memory-mapped bus.
30 Definition: A standard property. Defines the number of cells
36 Definition: A standard property. Defines the number of cells
37 or representing the size of physical addresses in
43 Definition: A standard property. Specifies the physical address
44 range of the DCSR space.
[all …]
|
| /linux-4.4.14/Documentation/frv/ |
| D | gdbstub.txt | 7 port. This permits GDB to single step through the kernel, set breakpoints and
9 permits the NMI interrupt button or serial port events to jump the kernel into
10 the debugger.
12 On the CPUs that have on-chip UARTs (FR400, FR403, FR405, FR555), the
14 generate level 15 interrupts (NMI). The kernel proper cannot see the serial
17 On the MB93091-VDK CPU boards, the GDB stub uses UART1, which would otherwise
18 be /dev/ttyS1. On the MB93093-PDK, the GDB stub uses UART0. Therefore, on the
19 PDK there is no externally accessible serial port and the serial port to
20 which the touch screen is attached becomes /dev/ttyS0.
22 Note that the GDB stub runs entirely within CPU debug mode, and so should not
[all …]
|
| /linux-4.4.14/Documentation/devicetree/ |
| D | dynamic-resolution-notes.txt | 4 This document describes the implementation of the in-kernel
8 How the resolver works
11 The resolver is given as an input an arbitrary tree compiled with the
12 proper dtc option and having a /plugin/ tag. This generates the
15 In sequence the resolver works by the following steps:
17 1. Get the maximum device tree phandle value from the live tree + 1.
18 2. Adjust all the local phandles of the tree to resolve by that amount.
19 3. Using the __local__fixups__ node information adjust all local references
20 by the same amount.
21 4. For each property in the __fixups__ node locate the node it references
[all …]
|
| D | of_unittest.txt | 8 This document explains how the test data required for executing OF unittest
9 is attached to the live tree dynamically, independent of the machine's
12 It is recommended to read the following documents before moving ahead.
17 OF Selftest has been designed to test the interface (include/linux/of.h)
18 provided to device driver developers to fetch the device information..etc.
19 from the unflattened device tree data structure. This interface is used by
20 most of the device drivers in various use cases.
26 the test data required for executing the unit tests automated in
35 When the kernel is build with OF_SELFTEST enabled, then the following make rule
40 is used to compile the DT source file (testcases.dts) into a binary blob
[all …]
|
| /linux-4.4.14/Documentation/development-process/ |
| D | 5.Posting | 3 Sooner or later, the time comes when your work is ready to be presented to
4 the community for review and, eventually, inclusion into the mainline
5 kernel. Unsurprisingly, the kernel development community has evolved a set
6 of conventions and procedures which are used in the posting of patches;
9 more information can also be found in the files SubmittingPatches,
10 SubmittingDrivers, and SubmitChecklist in the kernel documentation
17 completely "ready." For simple patches, that is not a problem. If the
19 feedback from the community before the work is complete. So you should
24 good idea to say so in the posting itself. Also mention any major work
27 with the idea that they can help you drive the work in the right direction.
[all …]
|
| /linux-4.4.14/Documentation/sound/oss/ |
| D | ALS | 4 Support for sound cards based around the Avance Logic
6 chip PnP sound solution which is mostly hardware compatible with the
7 Sound Blaster 16 card, with most differences occurring in the use of
8 the mixer registers. For this reason the ALS code is integrated
9 as part of the Sound Blaster 16 driver (adding only 800 bytes to the
12 To use an ALS sound card under Linux, enable the following options as
13 modules in the sound configuration section of the kernel config:
16 - standalone MPU401 support may be required for some cards; for the
18 Since the ALS-007/100/200 are PnP cards, ISAPnP support should probably be
20 be required to configure the card before the sound modules are loaded.
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/ |
| D | marvell.txt | 5 many of the peripherals needed to implement a complete computer
7 the system controller chip itself and each of the peripherals
9 prefixed with the string "marvell,", for Marvell Technology Group Ltd.
13 This node is used to represent the system-controller and must be
14 present when the system uses a system controller chip. The top-level
16 devices within the system controller chip. The node name begins
17 with "system-controller" followed by the unit address, which is
18 the base address of the memory-mapped register set for the system
23 - ranges : Describes the translation of system controller addresses
25 - clock-frequency: Contains the main clock frequency for the system
[all …]
|
| /linux-4.4.14/arch/x86/math-emu/ |
| D | README | 9 | it under the terms of the GNU General Public License version 2 as |
10 | published by the Free Software Foundation. |
12 | This program is distributed in the hope that it will be useful, |
13 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
14 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
17 | You should have received a copy of the GNU General Public License |
18 | along with this program; if not, write to the Free Software |
28 DJ Delorie for djgpp. The interface to the Linux kernel is based upon
29 the original Linux math emulator by Linus Torvalds.
31 My target FPU for wm-FPU-emu is that described in the Intel486
[all …]
|
| /linux-4.4.14/Documentation/filesystems/caching/ |
| D | cachefiles.txt | 13 (*) Starting the cache.
37 CacheFiles uses a userspace daemon to do some of the cache management - such as
41 The filesystem and data integrity of the cache are only as good as those of the
42 filesystem providing the backing services. Note that CacheFiles does not
43 attempt to journal anything since the journalling interfaces of the various
47 to communication with the daemon. Only one thing may have this open at once,
49 opens this and sends commands down it to control the cache.
54 the filesystem, shrinking the cache by culling the objects it contains to make
55 space if necessary - see the "Cache Culling" section. This means it can be
56 placed on the same medium as a live set of data, and will expand to make use of
[all …]
|
| D | netfs-api.txt | 5 There's an API by which a network filesystem can make use of the FS-Cache
14 may or may not have anything associated with it, but the netfs doesn't
17 (3) Barring the top-level index (one entry per cached netfs), the index
18 hierarchy for each netfs is structured according the whim of the netfs.
22 This document contains the following sections:
32 (9) Setting the data file size
48 FS-Cache needs a description of the network filesystem. This is specified
49 using a record of the following structure:
58 This first two fields should be filled in before registration, and the third
59 will be filled in by the registration function; any other fields should just be
[all …]
|
| /linux-4.4.14/Documentation/filesystems/cifs/ |
| D | README | 3 It was designed to comply with the SNIA CIFS Technical Reference (which
4 supersedes the 1992 X/Open SMB Standard) as well as to perform best practice
6 servers. This code was developed in participation with the Protocol Freedom
21 1) Get the kernel source (e.g.from http://www.kernel.org)
22 and download the cifs vfs source (see the project page
24 and change directory into the top of the kernel directory
25 then patch the kernel (e.g. "patch -p1 < cifs_24.patch")
26 to add the cifs vfs to your kernel configure options if
28 users do not need to apply the cifs_24.patch since the cifs vfs is
29 already in the kernel configure menu) and then
[all …]
|
| /linux-4.4.14/Documentation/fb/ |
| D | framebuffer.txt | 11 The frame buffer device provides an abstraction for the graphics hardware. It
12 represents the frame buffer of some video hardware and allows application
13 software to access the graphics hardware through a well-defined interface, so
14 the software doesn't need to know anything about the low-level (hardware
17 The device is accessed through special device nodes, usually located in the
24 From the user's point of view, the frame buffer device looks just like any
25 other device in /dev. It's a character device using major 29; the minor
26 specifies the frame buffer number.
28 By convention, the following device nodes are used (numbers indicate the device
36 For backwards compatibility, you may want to create the following symbolic
[all …]
|
| /linux-4.4.14/Documentation/mmc/ |
| D | mmc-async-req.txt | 4 How significant is the cache maintenance overhead?
6 pre-fetch makes the cache overhead relatively significant. If the DMA
7 preparations for the next request are done in parallel with the current
8 transfer, the DMA preparation overhead would not affect the MMC performance.
9 The intention of non-blocking (asynchronous) MMC requests is to minimize the
11 Using mmc_wait_for_req(), the MMC controller is idle while dma_map_sg and
13 possible to prepare the caches for next job in parallel with an active
19 The mmc_blk_issue_rw_rq() in the MMC block driver is made non-blocking.
20 The increase in throughput is proportional to the time it takes to
22 a request and how fast the memory is. The faster the MMC/SD is the
[all …]
|
| /linux-4.4.14/Documentation/arm/Samsung-S3C24XX/ |
| D | GPIO.txt | 8 manipulate the state of the GPIO pins, and find out other
11 There are a number of conditions attached to the configuration
12 of the s3c2410 GPIO system, please read the Samsung provided
13 data-sheet/users manual to find out the complete list.
15 See Documentation/arm/Samsung/GPIO.txt for the core implementation.
21 With the event of the GPIOLIB in drivers/gpio, support for some
22 of the GPIO functions such as reading and writing a pin will
25 Once all the extant drivers have been converted, the functions
27 in the near future).
30 or are merged into gpiolib. See the definitions in
[all …]
|
| D | Suspend.txt | 8 The S3C24XX supports a low-power suspend mode, where the SDRAM is kept
9 in Self-Refresh mode, and all but the essential peripheral blocks are
11 at the relevant CPU datasheet from Samsung.
17 1) A bootloader that can support the necessary resume operation
21 3) CONFIG_PM enabled in the kernel
23 4) Any peripherals that are going to be powered down at the same
30 The S3C2410 user manual defines the process of sending the CPU to
31 sleep and how it resumes. The default behaviour of the Linux code
32 is to set the GSTATUS3 register to the physical address of the
35 GSTATUS4 is currently left alone by the sleep code, and is free to
[all …]
|
| /linux-4.4.14/Documentation/filesystems/configfs/ |
| D | configfs.txt | 14 configfs is a ram-based filesystem that provides the converse of
21 appear in sysfs, allowing userspace to read the attributes via
23 write(2). The important point is that the object is created and
24 destroyed in kernel, the kernel controls the lifecycle of the sysfs
30 As with sysfs, readdir(3) queries the list of items and/or attributes.
31 symlink(2) can be used to group items together. Unlike sysfs, the
32 lifetime of the representation is completely driven by userspace. The
33 kernel modules backing the items must respond to this.
35 Both sysfs and configfs can and should exist together on the same
36 system. One is not a replacement for the other.
[all …]
|
| /linux-4.4.14/Documentation/cdrom/ |
| D | cdrom-standard.tex | 34 \linux\ is probably the Unix-like operating system that supports
35 the widest variety of hardware devices. The reasons for this are
39 The large list of hardware devices available for the many platforms
42 The open design of the operating system, such that anybody can write a
47 The openness of \linux, and the many different types of available
49 Unfortunately, the very openness that has allowed \linux\ to support
50 all these different devices has also allowed the behavior of each
53 devices; the way a particular drive reacts to a `standard' $ioctl()$
55 their drivers totally inconsistent, the writers of \linux\ \cdrom\
58 maintain uniform behavior across all the \linux\ \cdrom\ drivers.
[all …]
|
| /linux-4.4.14/Documentation/ia64/ |
| D | mca.txt | 7 the OS is in any state. Including when one of the cpus is already
9 asking for deadlock. Also the state of structures that are protected
19 This is the monarch cpu.
22 to all the other cpus, the slaves.
24 * Slave cpus that receive the MCA interrupt call down into SAL, they
25 end up spinning disabled while the MCA is being serviced.
27 * If any slave cpu was already spinning disabled when the MCA occurred
28 then it cannot service the MCA interrupt. SAL waits ~20 seconds then
29 sends an unmaskable INIT event to the slave cpus that have not
32 * Because MCA/INIT can be delivered at any time, including when the cpu
[all …]
|
| /linux-4.4.14/Documentation/accounting/ |
| D | taskstats.txt | 6 per-process statistics from the kernel to userspace.
8 Taskstats was designed for the following benefits:
17 "pid", "tid" and "task" are used interchangeably and refer to the standard
18 Linux task defined by struct task_struct. per-pid stats are the same as
21 "tgid", "process" and "thread group" are used interchangeably and refer to the
22 tasks that share an mm_struct i.e. the traditional Unix process. Despite the
23 use of tgid, there is no special treatment for the task that is thread group
31 The response contains statistics for a task (if pid is specified) or the sum of
32 statistics for all tasks of the process (if tgid is specified).
34 To obtain statistics for tasks which are exiting, the userspace listener
[all …]
|
| /linux-4.4.14/ |
| D | README | 3 These are the release notes for Linux version 4. Read them carefully,
4 as they tell you what this is all about, explain how to install the
9 Linux is a clone of the operating system Unix, written from scratch by
11 the Net. It aims towards POSIX and Single UNIX Specification compliance.
13 It has all the features you would expect in a modern fully-fledged Unix,
18 It is distributed under the GNU General Public License - see the
24 today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
30 as long as they have a paged memory management unit (PMMU) and a port of the
34 Linux has also been ported to itself. You can now run the kernel as a
40 the Internet and in books, both Linux-specific and pertaining to
[all …]
|
| D | COPYING | 4 of the kernel, and does *not* fall under the heading of "derived work".
5 Also note that the GPL below is copyrighted by the Free Software
6 Foundation, but the instance of code that it refers to (the Linux
9 Also note that the only valid version of the GPL as far as the kernel
10 is concerned is _this_ particular version of the license (ie v2, not
28 freedom to share and change it. By contrast, the GNU General Public
30 software--to make sure the software is free for all its users. This
31 General Public License applies to most of the Free Software
34 the GNU Library General Public License instead.) You can apply it to
39 have the freedom to distribute copies of free software (and charge for
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/arm/msm/ |
| D | qcom,idle-state.txt | 3 ARM provides idle-state node to define the cpuidle states, as defined in [1].
4 cpuidle-qcom is the cpuidle driver for Qualcomm SoCs and uses these idle
6 The idle states supported by the QCOM SoC are defined as -
14 When the WFI instruction is executed the ARM core would gate its internal
15 clocks. In addition to gating the clocks, QCOM cpus use this instruction as a
16 trigger to execute the SPM state machine. The SPM state machine waits for the
17 interrupt to trigger the core back in to active. This triggers the cache
19 the SPM state machine out of its wait, the next step is to ensure that the
20 cache hierarchy is also out of standby, and then the cpu is allowed to resume
21 execution. This state is defined as a generic ARM WFI state by the ARM cpuidle
[all …]
|
| /linux-4.4.14/Documentation/i2c/busses/ |
| D | i2c-ali15x3 | 17 Initialize the base address of the i2c controller
23 The force_addr parameter is useful for boards that don't set the address in
24 the BIOS. Does not do a PCI force; the device must still be present in
25 lspci. Don't use this unless the driver complains that the base address is
37 This is the driver for the SMB Host controller on Acer Labs Inc. (ALI)
42 They are part of the following ALI chipsets:
44 * "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and
46 * "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz
53 Gigabyte GA-5AX (** Generally doesn't work because the BIOS doesn't
54 enable the 7101 device! **)
[all …]
|
| /linux-4.4.14/Documentation/arm64/ |
| D | arm-acpi.txt | 4 the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server
5 Base Boot Requirements) [1] specifications. Please note that the SBBR
6 can be retrieved simply by visiting [1], but the SBSA is currently only
9 The ARMv8 kernel implements the reduced hardware model of ACPI version
10 5.1 or later. Links to the specification and all external documents
11 it refers to are managed by the UEFI Forum. The specification is
13 by the specification can be found via http://www.uefi.org/acpi.
15 If an ARMv8 system does not meet the requirements of the SBSA and SBBR,
16 or cannot be described using the mechanisms defined in the required ACPI
17 specifications, then ACPI may not be a good fit for the hardware.
[all …]
|
| /linux-4.4.14/Documentation/virtual/kvm/ |
| D | api.txt | 10 - System ioctls: These query and set global attributes which affect the
18 Only run VM ioctls from the same process (address space) that was used
19 to create the VM.
21 - vcpu ioctls: These query and set attributes that control the operation
24 Only run vcpu ioctls from the same thread that was used to create the
32 open("/dev/kvm") obtains a handle to the kvm subsystem; this handle
37 fd can be used to control the vcpu, including the important task of
41 of fork() and the SCM_RIGHTS facility of unix domain socket. These
43 not cause harm to the host, their actual behavior is not guaranteed by
44 the API. The only supported use is one virtual machine per process,
[all …]
|
| /linux-4.4.14/tools/perf/Documentation/ |
| D | perf-script-perl.txt | 17 built-in Perl interpreter. It reads and processes the input file and
18 displays the results of the trace analysis implemented in the given
24 You can avoid reading the rest of this document by running 'perf script
25 -g perl' in the same directory as an existing perf.data trace file.
27 the event types in the trace file; it simply prints every available
28 field for each event in the trace file.
30 You can also look at the existing scripts in
33 the check-perf-script.pl script, while not interesting for its results,
34 attempts to exercise all of the main scripting features.
40 'handler function' is called for each event in the trace. If there's
[all …]
|
| /linux-4.4.14/arch/m68k/ifpsp060/ |
| D | isp.doc | 10 To the maximum extent permitted by applicable law,
13 and any warranty against infringement with regard to the SOFTWARE
16 To the maximum extent permitted by applicable law,
21 Motorola assumes no responsibility for the maintenance and support of the SOFTWARE.
23 You are hereby granted a copyright license to use, modify, and distribute the SOFTWARE
32 The file isp.sa contains the 68060 Integer Software Package.
34 integrated into an operating system to handle the "Unimplemented
36 This exception is taken when any of the integer instructions
37 not hardware implemented on the 68060 are encountered. The
51 The file isp.sa is essentially a hexadecimal image of the
[all …]
|
| /linux-4.4.14/drivers/staging/most/Documentation/ |
| D | driver_usage.txt | 5 access a MOST network: The Automotive Information Backbone and the de-facto
8 MOST defines the protocol, hardware and software layers necessary to allow
9 for the efficient and low-cost transport of control, real-time and packet
13 For more information on MOST, visit the MOST Cooperation website:
17 increasing the demand for reliable and simple solutions to support audio,
22 audio/video streaming. Therefore, the driver perfectly fits to the mission
26 The driver consists basically of three layers. The hardware layer, the
27 core layer and the application layer. The core layer consists of the core
28 module only. This module handles the communication flow through all three
29 layers, the configuration of the driver, the configuration interface
[all …]
|
| /linux-4.4.14/Documentation/wimax/ |
| D | README.i2400m | 2 Driver for the Intel Wireless Wimax Connection 2400m
6 This provides a driver for the Intel Wireless WiMAX Connection 2400m
13 * Intel i2400m Echo Peak or Baxter Peak; this includes the Intel
16 + Linux kernel development package for the target kernel; to
18 the kernel development package corresponding to the running
20 linux-VERSION, the development package is called
26 2.1. Compilation of the drivers included in the kernel
28 Configure the kernel; to enable the WiMAX drivers select Drivers >
32 If USB or SDIO are not enabled in the kernel configuration, the options
33 to build the i2400m USB or SDIO drivers will not show. Enable said
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/iommu/ |
| D | iommu.txt | 1 This document describes the generic device tree binding for IOMMUs and their
8 An IOMMU can provide the following services:
15 * Implement scatter-gather at page level granularity so that the device does
19 through the IOMMU and faulting when encountering accesses to unmapped
26 Device nodes compatible with this binding represent hardware with some of the
30 typically have a fixed association to the master device, whereas multiple-
33 The device tree node of the IOMMU device's parent bus must contain a valid
34 "dma-ranges" property that describes how the physical address space of the
43 The meaning of the IOMMU specifier is defined by the device tree binding of
44 the specific IOMMU. Below are a few examples of typical use-cases:
[all …]
|
| /linux-4.4.14/Documentation/console/ |
| D | console.txt | 5 assigned by the kernel to all the virtual consoles during the boot process.
12 any time with each driver sharing the console with other drivers including
13 the system driver. However, modular drivers cannot take over the console
15 call do_take_over_console() will succeed in the takeover regardless of the type
16 of driver occupying the consoles.) They can only take over the console that is
17 occupied by the system driver. In the same token, if the modular driver is
18 released by the console, the system driver will take over.
20 Modular drivers, from the programmer's point of view, has to call:
25 In newer kernels, the following are also available:
30 If sysfs is enabled, the contents of /sys/class/vtconsole can be
[all …]
|
| /linux-4.4.14/Documentation/netlabel/ |
| D | draft-ietf-cipso-ipsecurity-01.txt | 12 This Internet Draft provides the high level specification for a Commercial
13 IP Security Option (CIPSO). This draft reflects the version as approved by
14 the CIPSO IETF Working Group. Distribution of this memo is unlimited.
17 of the Internet Engineering Task Force (IETF), its Areas, and its Working
27 Please check the I-D abstract listing contained in each Internet Draft
28 directory to learn the current status of this or any other Internet Draft.
35 Currently the Internet Protocol includes two security options. One of
36 these options is the DoD Basic Security Option (BSO) (Type 130) which allows
41 is referred to as the DoD Extended Security Option (ESO). The values for
42 the fixed fields within these two options are administered by the Defense
[all …]
|
| /linux-4.4.14/arch/m68k/ |
| D | Kconfig.machine | 10 This option enables support for the Amiga series of computers. If
11 you plan to use this kernel on an Amiga, say Y here and browse the
19 This option enables support for the 68000-based Atari series of
20 computers (including the TT, Falcon and Medusa). If you plan to use
21 this kernel on an Atari, say Y here and browse the material
29 This option enables support for the Apple Macintosh series of
31 of the series).
33 Say N unless you're willing to code the remaining necessary support.
42 Domain workstation such as the DN3500.
61 you select this option you will have to select the appropriate
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/gpio/ |
| D | gpio-pcf857x.txt | 5 the direction and output level into a single bit per line, which can't be read
7 (a) as output and driving the signal low/high, or (b) as input and reporting a
8 low/high value, without knowing the last value written since the chip came out
14 - compatible: should be one of the following.
15 - "maxim,max7328": For the Maxim MAX7378
16 - "maxim,max7329": For the Maxim MAX7329
17 - "nxp,pca8574": For the NXP PCA8574
18 - "nxp,pca8575": For the NXP PCA8575
19 - "nxp,pca9670": For the NXP PCA9670
20 - "nxp,pca9671": For the NXP PCA9671
[all …]
|
| /linux-4.4.14/drivers/net/wireless/libertas/ |
| D | README | 7 This software file (the "File") is distributed by Marvell International
8 Ltd. under the terms of the GNU General Public License Version 2, June 1991
9 (the "License"). You may use, redistribute and/or modify this File in
10 accordance with the terms and conditions of the License, a copy of which
11 is available along with the File in the license.txt file or on the worldwide
24 o. Copy the firmware image (e.g. usb8388.bin) to /lib/firmware/
26 o. Load driver by using the following command:
35 Use the -i option to retrieve version information from the driver.
43 Use the -e option to read the EEPROM contents of the card.
48 -e retrieves and prints an EEPROM dump for the specified ethernet
[all …]
|