| /Documentation/arch/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 | 55 Must be supplied if RAS support is provided by the platform. It
56 is recommended this table be supplied.
62 Microsoft only table, will not be supported.
96 License has changed and should be usable. Optional if used instead
103 Microsoft only table, will not be supported.
119 x86 only table, will not be supported.
131 Optional, not currently supported, but could be used on ARM if and
134 need to be modified in the ACPI specification.
142 if it had actually occurred. However, this table should not be
143 shipped with a production system; it should be dynamically loaded
[all …]
|
| /Documentation/devicetree/bindings/regulator/ |
| D | regulator.yaml | 38 description: boolean, regulator should never be disabled
46 This property is intended to only be used for regulators where
55 description: allow the regulator performance level to be configured
60 disabling ramp rate, it should be explicitly initialised to zero (regulator-ramp-delay
102 for the regulator at run-time. Elements may be specified in any order.
128 hardware performs emergency shutdown. Zero can be passed to disable
129 protection and value '1' indicates that protection should be enabled but
130 limit setting can be omitted.
135 Zero can be passed to disable error detection and value '1' indicates
136 that detection should be enabled but limit setting can be omitted.
[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/arch/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/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.
52 will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``.
53 * Untrusted allocations triggered from userspace should be a subject
56 allocations that should be accounted.
62 will be directly accessible by the kernel and implies that the
[all …]
|
| D | folio_queue.rst | 25 that can be used to form an I/O buffer. As such, the list can be iterated over
39 sibling pointers in terminal segments should be NULL.
47 but hese should not be accessed directly as the underlying data structure may
48 change, but rather the access functions outlined below should be used.
50 The facility can be made accessible by::
62 A segment should be initialised by calling::
66 with a pointer to the segment to be initialised. Note that this will not
67 necessarily initialise all the folio pointers, so care must be taken to check
74 Folios can be set in the next unused slot in a segment struct by calling one
86 to check that the capacity wasn't overrun and the list will not be extended
[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
69 Some basic editor settings, such as indentation and line endings, will be
81 But experience has shown that excessive or premature abstraction can be
82 just as harmful as premature optimization. Abstraction should be used to
[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/misc-devices/ |
| D | pci-endpoint-test.rst | 7 This driver should be used as a host side driver if the root complex is
11 The "pci_endpoint_test" driver can be used to perform the following tests.
25 should be used to perform the above tests.
31 Tests the BAR. The number of the BAR to be tested
32 should be passed as argument.
37 to be tested should be passed as argument.
40 to be tested should be passed as argument.
43 should be passed as argument (0: Legacy, 1:MSI, 2:MSI-X).
47 Perform write tests. The size of the buffer should be passed
50 Perform read tests. The size of the buffer should be passed
[all …]
|
| /Documentation/networking/ |
| D | rxrpc.rst | 8 that can be used to perform RxRPC remote operations. This is done over sockets
68 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 …]
|
| D | netdev-features.rst | 25 be changed (enabled or disabled) for a particular device by user's
26 request. This set should be initialized in ndo_init callback and not
30 for a device. This should be changed only by network core or in
41 networking core and should not be referenced in drivers.
48 When current feature set (netdev->features) is to be changed, new set
65 netdev_update_features() while holding rtnl_lock. This should not be done
66 from ndo_*_features callbacks. netdev->features should not be modified by
76 All dependencies between features should be resolved here. The resulting
77 set can be reduced further by networking core imposed limitations (as coded
81 This callback should not modify hardware nor driver state (should be
[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/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/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/crypto/ |
| D | asymmetric-keys.rst | 21 The "asymmetric" key type is designed to be a container for the keys used in
27 However, no requirement is made that the key data actually be stored in the
30 A completely in-kernel key retention and operation subtype can be defined, but
31 it would also be possible to provide access to cryptographic hardware (such as
32 a TPM) that might be used to both retain the relevant key and perform
34 merely be an interface to the TPM driver.
39 subtype of the key and define the operations that can be done on that key.
51 should be given from the content of the key.
53 This can then be used to refer to the key, either by complete match or by
72 only keys of the specified subtype (e.g. tpm) will be matched. For
[all …]
|
| /Documentation/virt/kvm/ |
| D | review-checklist.rst | 10 2. Patches should be against kvm.git master branch.
13 - the API must be documented in Documentation/virt/kvm/api.rst
14 - the API must be discoverable using KVM_CHECK_EXTENSION
21 6. New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2
23 7. Emulator changes should be accompanied by unit tests for qemu-kvm.git
26 8. Changes should be vendor neutral when possible. Changes to common code
32 10. User/kernel interfaces and guest/host interfaces must be 64-bit clean
36 11. New guest visible features must either be documented in a hardware manual
37 or be accompanied by documentation.
39 12. Features must be robust against reset and kexec - for example, shared
[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/bpf/ |
| D | bpf_prog_run.rst | 18 The ``BPF_PROG_RUN`` command can be used through the ``bpf()`` syscall to
20 can be used to unit test BPF programs against user-supplied context objects, and
23 to be defined in the UAPI header, aliased to the same value.
25 The ``BPF_PROG_RUN`` command can be used to execute BPF programs of the
48 will not actually be redirected or dropped, the program return code will just be
56 which can be used to execute XDP programs in a way where packets will actually
57 be processed by the kernel after the execution of the XDP program as if they
68 will not be returned to userspace; instead, the kernel will perform the
71 in the syscall parameters when running in this mode will be rejected. In
72 addition, not all failures will be reported back to userspace directly;
[all …]
|
| /Documentation/arch/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/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/devicetree/bindings/mmc/ |
| D | sdhci-omap.txt | 8 - compatible: Should be "ti,omap2430-sdhci" for omap2430 controllers
9 Should be "ti,omap3-sdhci" for omap3 controllers
10 Should be "ti,omap4-sdhci" for omap4 and ti81 controllers
11 Should be "ti,omap5-sdhci" for omap5 controllers
12 Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers
13 Should be "ti,k2g-sdhci" for K2G
14 Should be "ti,am335-sdhci" for am335x controllers
15 Should be "ti,am437-sdhci" for am437x controllers
16 - ti,hwmods: Must be "mmc<n>", <n> is controller instance starting 1
18 - pinctrl-names: Should be subset of "default", "hs", "sdr12", "sdr25", "sdr50",
[all …]
|