| /linux/include/linux/ |
| H A D | nvme-fc-driver.h | 24 * struct nvmefc_ls_req - Request structure passed from the transport
25 * to the LLDD to perform a NVME-FC LS request and obtain
30 * Used by the nvmet-fc transport (controller) to send
33 * Values set by the requestor prior to calling the LLDD ls_req entrypoint:
40 * @timeout: Maximum amount of time, in seconds, to wait for the LS response.
43 * @private: pointer to memory allocated alongside the ls request structure
44 * that is specifically for the LLDD to use while processing the
45 * request. The length of the buffer corresponds to the
46 * lsrqst_priv_sz value specified in the xxx_template supplied
47 * by the LLDD.
[all …]
|
| /linux/Documentation/scsi/ |
| H A D | st.rst | 4 The SCSI Tape Driver
7 This file contains brief information about the SCSI tape driver.
8 The driver is currently maintained by Kai Mäkisara (email
17 The driver is generic, i.e., it does not contain any code tailored
18 to any specific tape drive. The tape parameters can be specified with
19 one of the following three methods:
21 1. Each user can specify the tape parameters he/she wants to use
24 in a multiuser environment the next user finds the tape parameters in
25 state the previous user left them.
27 2. The system manager (root) can define default values for some tape
[all …]
|
| /linux/Documentation/input/ |
| H A D | multi-touch-protocol.rst | 13 In order to utilize the full power of the new multi-touch and multi-user
15 objects in direct contact with the device surface, is needed. This
16 document describes the multi-touch (MT) protocol which allows kernel
19 The protocol is divided into two types, depending on the capabilities of the
20 hardware. For devices handling anonymous contacts (type A), the protocol
21 describes how to send the raw data for all contacts to the receiver. For
22 devices capable of tracking identifiable contacts (type B), the protocol
33 events. Only the ABS_MT events are recognized as part of a contact
35 applications, the MT protocol can be implemented on top of the ST protocol
39 input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT
[all …]
|
| /linux/Documentation/locking/ |
| H A D | rt-mutex-design.rst | 7 Licensed under the GNU Free Documentation License, Version 1.2
10 This document tries to describe the design of the rtmutex.c implementation.
11 It doesn't describe the reasons why rtmutex.c exists. For that please see
13 that happen without this code, but that is in the concept to understand
14 what the code actually is doing.
16 The goal of this document is to help others understand the priority
17 inheritance (PI) algorithm that is used, as well as reasons for the
18 decisions that were made to implement PI in the manner that was done.
26 most of the time it can't be helped. Anytime a high priority process wants
28 the high priority process must wait until the lower priority process is done
[all …]
|
| /linux/Documentation/admin-guide/ |
| H A D | spkguide.txt | 2 The Speakup User's Guide
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
[all …]
|
| /linux/LICENSES/preferred/ |
| H A D | LGPL-2.1 | 7 To use this license in source code, put one of the following SPDX
8 tag/value pairs into a comment according to the placement
9 guidelines in the licensing rules documentation.
30 [This is the first released version of the Lesser GPL. It also counts as
31 the successor of the GNU Library Public License, version 2, hence the
36 The licenses for most software are designed to take away your freedom to
37 share and change it. By contrast, the GNU General Public Licenses are
39 make sure the software is free for all its users.
41 This license, the Lesser General Public License, applies to some specially
42 designated software packages--typically libraries--of the Free Software
[all …]
|
| H A D | LGPL-2.0 | 5 To use this license in source code, put one of the following SPDX
6 tag/value pairs into a comment according to the placement
7 guidelines in the licensing rules documentation.
24 [This is the first released version of the library GPL. It is numbered 2
25 because it goes with version 2 of the ordinary GPL.]
29 The licenses for most software are designed to take away your freedom to
30 share and change it. By contrast, the GNU General Public Licenses are
32 make sure the software is free for all its users.
34 This license, the Library General Public License, applies to some specially
39 General Public Licenses are designed to make sure that you have the freedom
[all …]
|
| /linux/Documentation/networking/ |
| H A D | ppp_generic.rst | 12 The generic PPP driver in linux-2.4 provides an implementation of the
15 * the network interface unit (ppp0 etc.)
16 * the interface to the networking code
19 * the interface to pppd, via a /dev/ppp character device
25 For sending and receiving PPP frames, the generic PPP driver calls on
26 the services of PPP ``channels``. A PPP channel encapsulates a
29 has a very simple interface with the generic PPP code: it merely has
37 be linked to each ppp network interface unit. The generic layer is
45 See include/linux/ppp_channel.h for the declaration of the types and
46 functions used to communicate between the generic PPP layer and PPP
[all …]
|
| /linux/Documentation/virt/hyperv/ |
| H A D | vpci.rst | 7 that are mapped directly into the VM's physical address space.
8 Guest device drivers can interact directly with the hardware
9 without intermediation by the host hypervisor. This approach
10 provides higher bandwidth access to the device with lower
11 latency, compared with devices that are virtualized by the
12 hypervisor. The device should appear to the guest just as it
14 to the Linux device drivers for the device.
24 and produces the same benefits by allowing a guest device
25 driver to interact directly with the hardware. See Hyper-V
36 it is operating, so the Linux device driver for the device can
[all …]
|
| /linux/tools/perf/pmu-events/arch/x86/silvermont/ |
| H A D | pipeline.json | 3 "BriefDescription": "Counts the number of branch instructions retired...",
8 …the number of any branch instructions retired. Branch prediction predicts the branch target and e…
12 "BriefDescription": "Counts the number of taken branch instructions retired",
17 …the number of all taken branch instructions retired. Branch prediction predicts the branch target…
22 "BriefDescription": "Counts the number of near CALL branch instructions retired",
27 …the number of near CALL branch instructions retired. Branch prediction predicts the branch target…
32 "BriefDescription": "Counts the number of far branch instructions retired",
37 …the number of far branch instructions retired. Branch prediction predicts the branch target and e…
42 "BriefDescription": "Counts the number of near indirect CALL branch instructions retired",
47 …the number of near indirect CALL branch instructions retired. Branch prediction predicts the bran…
[all …]
|
| /linux/Documentation/core-api/ |
| H A D | debug-objects.rst | 2 The object-lifetime debugging infrastructure
10 debugobjects is a generic infrastructure to track the life time of
11 kernel objects and validate the operations on those.
13 debugobjects is useful to check for the following error patterns:
21 debugobjects is not changing the data structure of the real object so it
28 A kernel subsystem needs to provide a data structure which describes the
29 object type and add calls into the debug code at appropriate places. The
30 data structure to describe the object type needs at minimum the name of
31 the object type. Optional functions can and should be provided to fixup
32 detected problems so the kernel can continue to work and the debug
[all …]
|
| /linux/Documentation/admin-guide/device-mapper/ |
| H A D | dm-integrity.rst | 5 The dm-integrity target emulates a block device that has additional
9 writing the sector and the integrity tag must be atomic - i.e. in case of
12 To guarantee write atomicity, the dm-integrity target uses journal, it
13 writes sector data and integrity tags into a journal, commits the journal
14 and then copies the data and integrity tags to their respective location.
16 The dm-integrity target can be used with the dm-crypt target - in this
17 situation the dm-crypt target creates the integrity data and passes them
18 to the dm-integrity target via bio_integrity_payload attached to the bio.
19 In this mode, the dm-crypt and dm-integrity targets provide authenticated
20 disk encryption - if the attacker modifies the encrypted device, an I/O
[all …]
|
| /linux/Documentation/security/keys/ |
| H A D | core.rst | 6 user mappings, and similar to be cached in the kernel for the use of
13 The key service can be configured on by enabling:
17 This document has the following sections:
26 tokens, keyrings, etc.. These are represented in the kernel by struct key.
40 the lifetime of that key. All serial numbers are positive non-zero 32-bit
46 * Each key is of a defined "type". Types must be registered inside the
50 Key types are represented in the kernel by struct key_type. This defines a
53 Should a type be removed from the system, all the keys of that type will
56 * Each key has a description. This should be a printable string. The key
57 type provides an operation to perform a match between the description on a
[all …]
|
| /linux/Documentation/userspace-api/media/v4l/ |
| H A D | dev-encoder.rst | 11 them into a bytestream. It generates complete chunks of the bytestream, including
12 all metadata, headers, etc. The resulting bytestream does not require any
13 further post-processing by the client.
15 Performing software stream processing, header generation etc. in the driver
17 operations are needed, use of the Stateless Video Encoder Interface (in
23 1. The general V4L2 API rules apply if not specified in this document
26 2. The meaning of words "must", "may", "should", etc. is as per `RFC
37 depending on encoder capabilities and following the general V4L2 guidelines.
42 7. Given an ``OUTPUT`` buffer A, then A' represents a buffer on the ``CAPTURE``
88 1. To enumerate the set of coded formats supported by the encoder, the
[all …]
|
| H A D | dev-stateless-decoder.rst | 12 of any previous and future frames, and that the client is responsible for
13 maintaining the decoding state and providing it to the decoder with each
14 decoding request. This is in contrast to the stateful video decoder interface,
15 where the hardware and driver maintain the decoding state and all the client
16 has to do is to provide the raw encoded stream and dequeue decoded frames in
19 This section describes how user-space ("the client") is expected to communicate
21 Compared to stateful codecs, the decoder/client sequence is simpler, but the
22 cost of this simplicity is extra complexity in the client which is responsible
25 Stateless decoders make use of the :ref:`media-request-api`. A stateless
26 decoder must expose the ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability on its
[all …]
|
| /linux/Documentation/admin-guide/mm/ |
| H A D | userfaultfd.rst | 8 Userfaults allow the implementation of on-demand paging from userland
10 memory page faults, something otherwise only the kernel code could do.
13 of the ``PROT_NONE+SIGSEGV`` trick.
19 regions of virtual memory with it. Then, any page faults which occur within the
20 region(s) result in a message being delivered to the userfaultfd, notifying
21 userspace of the fault.
23 The ``userfaultfd`` (aside from registering and unregistering virtual
26 1) ``read/POLLIN`` protocol to notify a userland thread of the faults
29 2) various ``UFFDIO_*`` ioctls that can manage the virtual memory regions
30 registered in the ``userfaultfd`` that allows userland to efficiently
[all …]
|
| /linux/Documentation/timers/ |
| H A D | highres.rst | 5 Further information can be found in the paper of the OLS 2006 talk "hrtimers
6 and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can
7 be found on the OLS website:
10 The slides to this talk are available from:
13 The slides contain five figures (pages 2, 15, 18, 20, 22), which illustrate the
14 changes in the time(r) related Linux subsystems. Figure #1 (p. 2) shows the
15 design of the Linux time(r) system before hrtimers and other building blocks
18 Note: the paper and the slides are talking about "clock event source", while we
19 switched to the name "clock event devices" in meantime.
21 The design contains the following basic building blocks:
[all …]
|
| /linux/Documentation/arch/sparc/oradax/ |
| H A D | dax-hv-api.txt | 13 …The following APIs provide access via the Hypervisor to hardware assisted data processing function…
15 …even on supported platforms. Restrictions on the use of these APIs may be imposed in order to supp…
19 …The Data Analytics Accelerator (DAX) functionality is a collection of hardware coprocessors that p…
20 …high speed processoring of database-centric operations. The coprocessors may support one or more of
21 …the following data query operations: search, extraction, compression, decompression, and translati…
24 …The DAX is a virtual device to sun4v guests, with supported data operations indicated by the virtu…
25 … compatibility property. Functionality is accessed through the submission of Command Control Blocks
26 …(CCBs) via the ccb_submit API function. The operations are processed asynchronously, with the stat…
27 … of the submitted operations reported through a Completion Area linked to each CCB. Each CCB has a
28 …separate Completion Area and, unless execution order is specifically restricted through the use of…
[all …]
|
| /linux/Documentation/admin-guide/media/ |
| H A D | vivid.rst | 3 The Virtual Video Test Driver (vivid)
19 you can test the various features without requiring special hardware.
21 This document describes the features implemented by this driver:
26 - Support for the alpha color component
44 Configuring the driver
47 By default the driver will create a single instance that has a video capture
52 The number of instances, devices, video inputs and outputs and their types are
53 all configurable using the following module options:
63 hexadecimal values, one for each instance. The default is 0xe1d3d.
64 Each value is a bitmask with the following meaning:
[all …]
|
| /linux/drivers/net/ethernet/aquantia/atlantic/macsec/ |
| H A D | macsec_api.h | 48 /*! Read the raw table data from the specified row of the Egress CTL
49 * Filter table, and unpack it into the fields of rec.
50 * rec - [OUT] The raw table row data will be unpacked into the fields of rec.
51 * table_index - The table row to read (max 23).
57 /*! Pack the fields of rec, and write the packed data into the
58 * specified row of the Egress CTL Filter table.
59 * rec - [IN] The bitfield values to write to the table row.
60 * table_index - The table row to write(max 23).
66 /*! Read the raw table data from the specified row of the Egress
67 * Packet Classifier table, and unpack it into the fields of rec.
[all …]
|
| /linux/Documentation/power/ |
| H A D | userland-swsusp.rst | 7 First, the warnings at the beginning of swsusp.txt still apply.
9 Second, you should read the FAQ in swsusp.txt _now_ if you have not
12 Now, to use the userland interface for software suspend you need special
13 utilities that will read/write the system memory snapshot from/to the
18 The interface consists of a character device providing the open(),
20 commands defined in include/linux/suspend_ioctls.h . The major and minor
21 numbers of the device are, respectively, 10 and 231, and they can
24 The device can be open either for reading or for writing. If open for
25 reading, it is considered to be in the suspend mode. Otherwise it is
26 assumed to be in the resume mode. The device cannot be open for simultaneous
[all …]
|
| /linux/Documentation/filesystems/ |
| H A D | idmappings.rst | 14 An idmapping is essentially a translation of a range of ids into another or the
15 same range of ids. The notational convention for idmappings that is widely used
20 ``u`` indicates the first element in the upper idmapset ``U`` and ``k``
21 indicates the first element in the lower idmapset ``K``. The ``r`` parameter
22 indicates the range of the idmapping, i.e. how many ids are mapped. From now
24 we're talking about an id in the upper or lower idmapset.
26 To see what this looks like in practice, let's take the following idmapping::
30 and write down the mappings it will generate::
39 the set of all possible ids usable on a given system.
43 example, we know that the inverse idmapping is an order isomorphism as well::
[all …]
|
| /linux/Documentation/security/tpm/ |
| H A D | tpm-security.rst | 6 The object of this document is to describe how we make the kernel's
7 use of the TPM reasonably robust in the face of external snooping and
9 in the literature). The current security document is for TPM 2.0.
14 The TPM is usually a discrete chip attached to a PC via some type of
15 low bandwidth bus. There are exceptions to this such as the Intel
17 close to the CPU, which are subject to different attacks, but right at
18 the moment, most hardened security environments require a discrete
19 hardware TPM, which is the use case discussed here.
21 Snooping and Alteration Attacks against the bus
24 The current state of the art for snooping the `TPM Genie`_ hardware
[all …]
|
| /linux/Documentation/filesystems/spufs/ |
| H A D | spufs.rst | 10 spufs - the SPU file system
16 The SPU file system is used on PowerPC machines that implement the Cell
20 The file system provides a name space similar to posix shared memory or
21 message queues. Users that have write permissions on the file system
22 can use spu_create(2) to establish SPU contexts in the spufs root.
25 set of files. These files can be used for manipulating the state of the
34 set the user owning the mount point, the default is 0 (root).
37 set the group owning the mount point, the default is 0 (root).
43 The files in spufs mostly follow the standard behavior for regular sys-
45 the operations supported on regular file systems. This list details the
[all …]
|
| /linux/Documentation/driver-api/pm/ |
| H A D | cpuidle.rst | 16 Every time one of the logical CPUs in the system (the entities that appear to
19 there are no tasks to run on it except for the special "idle" task associated
20 with it, there is an opportunity to save energy for the processor that it
21 belongs to. That can be done by making the idle logical CPU stop fetching
22 instructions from memory and putting some of the processor's functional units
26 situation in principle, so it may be necessary to find the most suitable one
27 (from the kernel perspective) and ask the processor to use (or "enter") that
28 particular idle state. That is the role of the CPU idle time management
29 subsystem in the kernel, called ``CPUIdle``.
31 The design of ``CPUIdle`` is modular and based on the code duplication avoidance
[all …]
|