| /Documentation/misc-devices/ |
| D | pci-endpoint-test.txt | 3 This driver should be used as a host side driver if the root complex is
7 The "pci_endpoint_test" driver can be used to perform the following tests.
20 should be used to perform the above tests.
24 PCITEST_BAR: Tests the BAR. The number of the BAR to be tested
25 should be passed as argument.
28 to be tested should be passed as argument.
30 to be tested should be passed as argument.
32 should be passed as argument (0: Legacy, 1:MSI, 2:MSI-X).
34 PCITEST_WRITE: Perform write tests. The size of the buffer should be passed
36 PCITEST_READ: Perform read tests. The size of the buffer should be passed
[all …]
|
| /Documentation/networking/ |
| D | rxrpc.txt | 6 that can be used to perform RxRPC remote operations. This is done over sockets
67 manage security on the client end. The server end must of necessity be
99 endpoint, thus allowing the endpoints to be shared, even to the same
103 to multiple services. A service may be considered the RxRPC equivalent of
106 (*) Client-originating packets are marked, thus a transport endpoint can be
110 (*) Up to a billion connections may be supported concurrently between one
123 billion calls, but only up to four calls may be in progress on a
143 connection lapse before the client, the security will be renegotiated if
152 been received but may yet be discarded and re-requested. The sender may
162 (*) An call may be aborted by either end at any time up to its completion.
[all …]
|
| /Documentation/filesystems/caching/ |
| D | backend-api.txt | 5 The FS-Cache system provides an API by which actual caches can be supplied to
16 To start off, a cache definition must be initialised and registered for each
20 The cache definition (struct fscache_cache) should be initialised by calling:
38 The cache should then be registered with FS-Cache by passing a pointer to the
45 Two extra arguments should also be supplied:
48 master index in this cache. Netfs primary index entries will be created
52 (*) "tagname" which, if given, should be a text string naming this cache. If
53 this is NULL, the identifier will be used instead. For CacheFS, the
54 identifier is set to name the underlying block device and the tag can be
58 is already in use. 0 will be returned on success.
[all …]
|
| D | netfs-api.txt | 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
67 entire in-cache hierarchy for this netfs will be scrapped and begun
70 (3) The cookie representing the primary index will be allocated according to
105 (1) Any index containing non-index objects should be restricted to a single
106 cache. Any such objects created within an index will be created in the
107 first cache only. The cache in which an index is created can be
110 (2) The entry data must be atomically journallable, so it is limited to about
111 400 bytes at present. At least 400 bytes will be available.
113 (3) The depth of the index tree should be judged with care as the search
[all …]
|
| /Documentation/arm64/ |
| D | booting.rst | 20 hypervisor code, or it may just be a handful of instructions for
50 The device tree blob (dtb) must be placed on an 8-byte boundary and must
51 not exceed 2 megabytes in size. Since the dtb will be mapped cacheable
52 using blocks of up to 2 megabytes in size, it must not be placed within
53 any 2M region which must be mapped with any specific attributes.
55 NOTE: versions prior to v4.2 also require that the DTB be placed within
64 therefore requires decompression (gzip etc.) to be performed by the boot
103 little-endian and must be respected. Where image_size is zero,
104 text_offset can be assumed to be 0x80000.
110 Bit 0 Kernel endianness. 1 if BE, 0 if LE.
[all …]
|
| D | acpi_object_usage.rst | 34 Must be supplied if RAS support is provided by the platform. It
35 is recommended this table be supplied.
41 Microsoft only table, will not be supported.
68 License has changed and should be usable. Optional if used instead
75 Microsoft only table, will not be supported.
91 x86 only table, will not be supported.
103 Optional, not currently supported, but could be used on ARM if and
106 need to be modified in the ACPI specification.
114 if it had actually occurred. However, this table should not be
115 shipped with a production system; it should be dynamically loaded
[all …]
|
| /Documentation/arm/ |
| D | setup.rst | 10 kernel loader to the Linux kernel proper, and may be short lived
12 should not be referenced outside of arch/arm/kernel/setup.c:setup_arch().
18 This parameter must be set to the page size of the machine, and
19 will be checked by the kernel.
30 This is now obsolete, and should not be used.
47 or VGA console character size. They should not be used for any other
50 It's generally a good idea to set these to be either standard VGA, or
52 all the bootup messages to be displayed correctly.
56 is otherwise unused. (should not be used for other console types, and
57 should not be used for other purposes).
[all …]
|
| D | porting.rst | 22 virtual or physical addresses here, since the MMU will be off at
25 to be located in RAM, it can be in flash or other read-only or
30 This must be pointing at RAM. The decompressor will zero initialise
31 this for you. Again, the MMU will be off.
34 This is the address where the decompressed kernel will be written,
35 and eventually executed. The following constraint must be valid:
39 The initial part of the kernel is carefully coded to be position
49 must be valid:
66 boot phase, virtual address PAGE_OFFSET will be mapped to physical
68 This should be the same value as TASK_SIZE.
[all …]
|
| /Documentation/driver-api/ |
| D | vme.rst | 12 be provided to the registration function. Along with the maximum number of
16 :c:type:`struct vme_driver <vme_driver>` should be correctly set. The '.name'
19 The '.match' function allows control over which VME devices should be registered
20 with the driver. The match function should return 1 if a device should be
40 driver. The bridge number (or bus number) can be accessed using
44 :c:func:`vme_unregister_driver` and should usually be called from the device
52 be called the number of times specified during the registration. If a match
53 succeeds, a non-zero value should be returned. A zero return value indicates
56 device structure. This pointer should be saved, it will be required for
62 driver to request a specific window or DMA channel (which may be used by a
[all …]
|
| /Documentation/security/keys/ |
| 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:
46 * Each key is of a defined "type". Types must be registered inside the
48 can be added or used. Userspace programs cannot define new types directly.
51 number of operations that can be performed on a key of that type.
53 Should a type be removed from the system, all the keys of that type will
54 be invalidated.
56 * Each key has a description. This should be a printable string. The key
62 whether a kernel service will be able to find the key.
64 * Each key can be set to expire at a specific time by the key type's
[all …]
|
| /Documentation/process/ |
| D | 4.Coding.rst | 6 While there is much to be said for a solid and community-oriented design
8 code. It is the code which will be examined by other developers and merged
34 the standard; many developers will request that the code be reformatted
42 win before the code can be merged. Putting code into the kernel means
53 on it for other reasons, but coding style changes should not be made for
56 The coding style document also should not be read as an absolute law which
57 can never be transgressed. If there is a good reason to go against the
77 But experience has shown that excessive or premature abstraction can be
78 just as harmful as premature optimization. Abstraction should be used to
89 patches to remove unused arguments; they should, in general, not be added
[all …]
|
| D | 5.Posting.rst | 6 Sooner or later, the time comes when your work is ready to be presented to
12 more information can also be found in the files
23 work being done is complex, though, there is a lot to be gained by getting
30 which remains to be done and any known problems. Fewer people will look at
31 patches which are known to be half-baked, but those who do will come in
38 There are a number of things which should be done before you consider
51 summary of the results should be included with the patch.
53 - Be sure that you have the right to post the code. If this work was done
54 for an employer, the employer likely has a right to the work and must be
64 The preparation of patches for posting can be a surprising amount of work,
[all …]
|
| /Documentation/admin-guide/ |
| D | md.rst | 7 Tools that manage md devices can be found at
82 This autodetection may be suppressed with the kernel parameter
84 superblock can be autodetected and run at boot time.
94 ``dirty`` means that the parity cannot be trusted, and the fact that it
96 be reconstructed (due to no parity).
108 arrays to be started.
136 be accessed.
138 An array should be created by a user-space tool. This will write
147 format is to be used. The minor number might be used to tune handling
157 Once started, new devices can be added. They should have an
[all …]
|
| /Documentation/devicetree/bindings/arm/omap/ |
| D | l4.txt | 6 - compatible : Should be "ti,omap2-l4" for OMAP2 family l4 core bus
7 Should be "ti,omap2-l4-wkup" for OMAP2 family l4 wkup bus
8 Should be "ti,omap3-l4-core" for OMAP3 family l4 core bus
9 Should be "ti,omap4-l4-cfg" for OMAP4 family l4 cfg bus
10 Should be "ti,omap4-l4-per" for OMAP4 family l4 per bus
11 Should be "ti,omap4-l4-wkup" for OMAP4 family l4 wkup bus
12 Should be "ti,omap5-l4-cfg" for OMAP5 family l4 cfg bus
13 Should be "ti,omap5-l4-wkup" for OMAP5 family l4 wkup bus
14 Should be "ti,dra7-l4-cfg" for DRA7 family l4 cfg bus
15 Should be "ti,dra7-l4-wkup" for DRA7 family l4 wkup bus
[all …]
|
| /Documentation/ |
| D | padata.txt | 7 Padata is a mechanism by which the kernel can farm work out to be done in
9 developed for use with the IPsec code, which needs to be able to perform
12 sufficiently general fashion that it could be put to other uses as well.
15 overall control of how tasks are to be run::
25 The pcpumask describes which processors will be used to execute work
27 processors are allowed to be used as the serialization callback processor.
28 The workqueue wq is where the work will actually be done; it should be
32 cpumasks this helper function can be used::
56 The list of CPUs to be used can be adjusted with these functions::
66 Changing the CPU masks are expensive operations, though, so it should not be
[all …]
|
| /Documentation/ABI/ |
| D | README | 4 interfaces should be used by userspace programs in different ways.
14 defined to be stable. Userspace programs are free to use these
16 them will be guaranteed for at least 2 years. Most interfaces
17 (like syscalls) are expected to never change and always be
21 This directory documents interfaces that are felt to be stable,
23 The interface can be changed to add new features, but the
26 programs can start to rely on these interfaces, but they must be
28 be marked stable. Programs that use these interfaces are
36 the kernel, but are marked to be removed at some later point in
38 why it is obsolete and when it can be expected to be removed.
[all …]
|
| /Documentation/virt/kvm/ |
| D | review-checklist.txt | 7 2. Patches should be against kvm.git master branch.
10 - the API must be documented in Documentation/virt/kvm/api.txt
11 - the API must be discoverable using KVM_CHECK_EXTENSION
18 6. New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2
20 7. Emulator changes should be accompanied by unit tests for qemu-kvm.git
23 8. Changes should be vendor neutral when possible. Changes to common code
29 10. User/kernel interfaces and guest/host interfaces must be 64-bit clean
33 11. New guest visible features must either be documented in a hardware manual
34 or be accompanied by documentation.
36 12. Features must be robust against reset and kexec - for example, shared
[all …]
|
| /Documentation/core-api/ |
| D | memory-allocation.rst | 15 memory should be allocated. The GFP acronym stands for "get free
27 flags must be used.
33 zones can be used, how hard the allocator should try to find free
34 memory, whether the memory can be accessed by the userspace etc. The
43 direct reclaim may be triggered under memory pressure; the calling
44 context must be allowed to sleep.
49 have a reasonable fallback should be using ``GFP_NOWARN``.
51 will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``.
52 * Untrusted allocations triggered from userspace should be a subject
55 allocations that should be accounted.
[all …]
|
| /Documentation/devicetree/bindings/edac/ |
| D | socfpga-eccmgr.txt | 8 - compatible : Should be "altr,socfpga-ecc-manager"
9 - #address-cells: must be 1
10 - #size-cells: must be 1
17 - compatible : Should be "altr,socfpga-l2-ecc"
19 - interrupts : Should be single bit error interrupt, then double bit error
24 - compatible : Should be "altr,socfpga-ocram-ecc"
27 - interrupts : Should be single bit error interrupt, then double bit error
58 - compatible : Should be "altr,socfpga-a10-ecc-manager"
61 - #address-cells: must be 1
62 - #size-cells: must be 1
[all …]
|
| /Documentation/driver-api/soundwire/ |
| D | error_handling.rst | 6 be very unlikely, and if they happen it should be limited to single bit
7 errors. Examples of this design can be found in the synchronization
11 The errors can be detected with multiple mechanisms:
16 Improvements could be invalidating an entire programming sequence and
20 impact its audibility (most-significant bits will be more impacted in PCM),
21 and after a number of such errors are detected the bus might be reset. Note
24 be distinguished, although a recurring bus clash when audio is enabled is a
27 not be responsible for the errors so resetting them individually is not a
32 that the command was received and will be executed by the end of the
34 be applied. In case of a bad programming (command sent to non-existent
[all …]
|
| /Documentation/powerpc/ |
| D | pmu-ebb.rst | 12 One type of event for which EBBs can be configured is PMU exceptions. This
22 attr.config. All events which can be configured on the hardware PMU are
30 EBBs can only sensibly be used by programs for self-monitoring.
32 It is a feature of the perf_events API that events can be created on other
35 EBBs will ever be delivered.
39 and attach an EBB event to the process, which will then cause EBBs to be
45 events can be configured. This means that EBB events can not be run
49 kernel will in general schedule the EBB event, and perf will be notified that
54 events will be given priority over other events, unless they are also pinned.
56 first will be scheduled and the other will be put in error state. See the
[all …]
|
| /Documentation/infiniband/ |
| D | user_mad.rst | 16 A MAD agent can be created by filling in a struct ib_user_mad_reg_req
19 request succeeds, a 32-bit id will be returned in the structure.
29 Agents can be unregistered with the IB_USER_MAD_UNREGISTER_AGENT
31 be unregistered when the descriptor is closed.
35 fields to be provided during registration.
43 RMPP. The buffer passed to read() must be at least one
77 fields will be filled in with information on the received MAD. For
78 example, the remote LID will be in mad.lid.
80 If a send times out, a receive will be generated with mad.status set
82 mad.status will be 0.
[all …]
|
| /Documentation/PCI/endpoint/function/binding/ |
| D | pci-test.txt | 3 name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
6 vendorid : should be 0x104c
7 deviceid : should be 0xb500 for DRA74x and 0xb501 for DRA72x
11 baseclass_code : should be 0xff
15 interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
16 msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts
18 msix_interrupts : Should be 1 to 2048 depending on the number of MSI-X
|
| /Documentation/driver-api/early-userspace/ |
| D | early_userspace_support.rst | 9 various pieces of functionality that are important enough to be
10 available while a Linux kernel is coming up, but that don't need to be
26 archive to be used as the image or have the kernel build process build
33 Your cpio archive should be specified in CONFIG_INITRAMFS_SOURCE and it
34 will be used directly. Only a single cpio file may be specified in
47 CONFIG_INITRAMFS_SOURCE. Sources can be either directories or files -
51 specified directory name will be mapped to '/'. When packaging a
52 directory, limited user and group ID translation can be performed.
53 INITRAMFS_ROOT_UID can be set to a user ID that needs to be mapped to
54 user root (0). INITRAMFS_ROOT_GID can be set to a group ID that needs
[all …]
|
| /Documentation/device-mapper/ |
| D | dm-bow.txt | 5 data that is overwritten. The changes can then be committed by a simple state
14 free space on the overlying file system that can be safely used. Typically the
19 State 1: All writes to the device cause the underlying data to be backed up to
20 the free (trimmed) area as needed in such a way as they can be restored.
29 becomes a pass-through driver, allowing the device to continue to be used with
36 dm-bow will typically be used in the following way. dm-bow will be loaded with a
37 suitable underlying device and the resultant device will be mounted. A file
38 system trim will be issued via the FITRIM ioctl, then the device will be
39 switched to state 1. The file system will now be used as normal. At some point,
40 the changes can either be committed by switching to state 2, or rolled back by
[all …]
|