| /Documentation/bpf/ |
| D | bpf_prog_run.rst | 45 the packet data that the BPF program will operate on. The kernel will then
46 execute the program and return the results to userspace. Note that programs will
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
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;
74 allocation errors) will halt execution and return an error. If an error occurs
76 execution will continue with the next repetition; these errors can be detected
80 the regular (non-live) mode. The XDP program will be executed as though the
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-class-led-trigger-tty | 13 If set to 0, the LED will not blink on reception.
14 If set to 1 (default), the LED will blink on reception.
21 If set to 0, the LED will not blink on transmission.
22 If set to 1 (default), the LED will blink on transmission.
31 If set to 0 (default), the LED will not evaluate CTS.
32 If set to 1, the LED will evaluate CTS.
41 If set to 0 (default), the LED will not evaluate DSR.
42 If set to 1, the LED will evaluate DSR.
51 If set to 0 (default), the LED will not evaluate CAR (DCD).
52 If set to 1, the LED will evaluate CAR (DCD).
[all …]
|
| D | sysfs-class-regulator | 6 Some regulator directories will contain a field called
10 This will be one of the following strings:
32 Some regulator directories will contain a field called
36 This will be one of the following strings:
72 Each regulator directory will contain a field called
75 This will be one of the following strings:
96 Some regulator directories will contain a field called
111 Some regulator directories will contain a field called
126 Some regulator directories will contain a field called
151 Some regulator directories will contain a field called
[all …]
|
| D | sysfs-class-remoteproc | 17 Reports the state of the remote processor, which will be one of:
44 Writing "start" will attempt to start the processor running the
49 Writing "stop" will attempt to halt the remote processor and
68 which will be one of:
74 "disabled" means no dump will be collected.
77 collected it will be copied to a separate buffer and that
81 collected userspace will directly read from the remote
82 processor's device memory. Extra buffer will not be used to
83 copy the dump. Also recovery process will not proceed until
92 which will be one of:
[all …]
|
| D | sysfs-power | 5 The /sys/power directory will contain files that will
31 supported). The mode that will be used on subsequent attempts
48 the name of the method by which the system will be put to
51 'firmware' - means that the memory image will be saved to disk
53 firmware will handle the system suspend.
55 'platform' - the memory image will be saved by the kernel and
56 the system will be put to sleep by the platform driver (e.g.
59 'shutdown' - the memory image will be saved by the kernel and
60 the system will be powered off.
62 'reboot' - the memory image will be saved by the kernel and
[all …]
|
| D | sysfs-class-rc | 30 Writing "+proto" will add a protocol to the list of enabled
33 Writing "-proto" will remove a protocol from the list of enabled
36 Writing "proto" will enable only "proto".
38 Writing "none" will disable all protocols.
53 the filter will be ignored. Otherwise the write will fail with
70 the filter will be ignored. Otherwise the write will fail with
93 Writing "proto" will use "proto" for wakeup events.
95 Writing "none" will disable wakeup.
113 scancodes which match the filter will wake the system from e.g.
116 Otherwise the write will fail with an error.
[all …]
|
| /Documentation/arch/s390/ |
| D | common_io.rst | 19 The given devices will be ignored by the common I/O-layer; no detection
20 and device sensing will be done on any of those devices. The subchannel to
21 which the device in question is attached will be treated as if no device was
29 give a device number 0xabcd, it will be interpreted as 0.0.abcd.
34 operator). The '!' operator will cause the I/O-layer to _not_ ignore a device.
42 will ignore all devices ranging from 0.0.0023 to 0.0.0042 and the device
49 will ignore all devices but 0.0.4711, 0.0.fd00, 0.0.fd01, 0.0.fd02.
62 "free all" will un-ignore all ignored devices,
63 "free <device range>, <device range>, ..." will un-ignore the specified
69 will un-ignore devices 0.0.0030 to 0.0.0032 and will leave devices 0.0.0023
[all …]
|
| /Documentation/mm/ |
| D | free_page_reporting.rst | 11 it will allocate and initialize a page_reporting_dev_info structure. The
12 field within the structure it will populate is the "report" function
15 call to the function. A call to page_reporting_register will register the
19 Once registered the page reporting API will begin reporting batches of
20 pages to the driver. The API will start reporting pages 2 seconds after
21 the interface is registered and will continue to do so 2 seconds after any
24 Pages reported will be stored in the scatterlist passed to the reporting
26 While pages are being processed by the report function they will not be
28 the pages will be returned to the free area from which they were obtained.
33 reporting removed. Doing this will prevent further reports from being
|
| /Documentation/arch/powerpc/ |
| D | dawr-power9.rst | 37 h_set_mode(DAWR) and h_set_dabr() will now return an error to the
39 they will silently not get the DAWR.
41 kvmppc_set_one_reg() will store the value in the vcpu but won't
46 For xmon, the 'bd' command will return an error on P9.
52 will accept the command. Unfortunately since there is no hardware
53 support for the watchpoint, GDB will software emulate the watchpoint
56 The same will also be true for any guests started on a POWER9
57 host. The watchpoint will fail and GDB will fall back to software
60 If a guest is started on a POWER8 host, GDB will accept the watchpoint
61 and configure the hardware to use the DAWR. This will run at full
[all …]
|
| D | transactional_memory.rst | 48 references will complete in one go if there are no conflicts with other
54 lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
55 updated, or neither will be updated.
58 transaction, the transaction will be aborted by the CPU. Register and memory
59 state will roll back to that at the 'tbegin', and control will continue from
60 'tbegin+4'. The branch to abort_handler will be taken this second time; the
72 - See the ISA for full documentation of everything that will abort transactions.
78 Syscalls made from within an active transaction will not be performed and the
79 transaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL
86 effects will be persistent, independent of transaction success or failure. No
[all …]
|
| /Documentation/filesystems/ |
| D | fiemap.rst | 39 flags, it will return EBADR and the contents of fm_flags will contain
41 with all flags passed, the contents of fm_flags will be unmodified.
49 fm_extents[] array is ignored (no extents will be returned), and the
50 fm_mapped_extents count will hold the number of extents needed in
57 If this flag is set, the kernel will sync the file before mapping extents.
60 If this flag is set, the extents returned will describe the inodes
70 fm_extent_count. The number of extents mapped by kernel will be
74 array will be returned and fm_mapped_extents will be equal to
75 fm_extent_count. In that case, the last extent in the array will not
76 complete the requested range and will not have the FIEMAP_EXTENT_LAST
[all …]
|
| D | ocfs2.rst | 64 atime_quantum=60(*) OCFS2 will not update atime unless this number
76 will be chosen. Invalid values will be ignored.
79 This means that if you lose your power, you will lose
81 filesystem will not be damaged though, thanks to the
83 will hurt performance, but it's good for data-safety.
84 Setting it to 0 will have the same effect as leaving
86 Setting it to very large values will improve
89 large, the fs will silently revert it to the default.
93 will result in inode numbers occupying more than 32
99 resv_level=2 (*) Set how aggressive allocation reservations will be.
[all …]
|
| /Documentation/i2c/ |
| D | gpio-fault-injection.rst | 11 Once the Kconfig option I2C_GPIO_FAULT_INJECTOR is enabled, there will be an
13 mounted at /sys/kernel/debug. There will be a separate subdirectory per GPIO
14 driven I2C bus. Each subdirectory will contain files to trigger the fault
15 injection. They will be described now along with their intended use-cases.
25 "echo 0 > scl" you force SCL low and thus, no communication will be possible
26 because the bus master under test will not be able to clock. It should detect
38 core (see 'struct bus_recovery_info'). However, the bus recovery will not
46 The following fault injectors create situations where SDA will be held low by a
51 and will init a bus recovery on its own. If you want to implement bus recovery
59 client device to it. Then, a read transfer to this device will be started, but
[all …]
|
| /Documentation/userspace-api/ |
| D | seccomp_filter.rst | 53 The BPF program will be executed over struct seccomp_data
64 will contain the filter program. If the program is invalid, the
65 call will return -1 and set errno to ``EINVAL``.
68 processes will be constrained to the same filters and system
73 true, ``-EACCES`` will be returned. This requirement ensures that filter
78 additional filters may be layered on which will increase evaluation
89 call will always use the highest precedent value. (For example,
90 ``SECCOMP_RET_KILL_PROCESS`` will always take precedence.)
97 will be ``SIGSYS``, not ``SIGKILL``.
101 system call. The exit status of the task (``status & 0x7f``) will
[all …]
|
| /Documentation/accel/ |
| D | introduction.rst | 16 Typically, a compute accelerator will belong to one of the following
24 type of device can be stand-alone or an IP inside a SoC or a GPU. It will
29 addition, these devices will usually have some tools, such as profiler and
33 have more computational power and memory b/w (e.g. HBM) and will likely have
38 that are tailored-made to their h/w. In addition, they will also probably
40 engines. Typically, the common layer in user-space will be the DL frameworks,
47 characteristics as those of GPUs, the accel subsystem will use the
48 DRM subsystem's code and functionality. i.e. the accel core code will
49 be part of the DRM subsystem and an accel device will be a new type of DRM
52 This will allow us to leverage the extensive DRM code-base and
[all …]
|
| /Documentation/hwmon/ |
| D | acpi_power_meter.rst | 30 Both `power[1-*]_average_{min,max}` must be set before the trip points will work.
31 When both of them are set, an ACPI event will be broadcast on the ACPI netlink
32 socket and a poll notification will be sent to the appropriate
40 the case, the `power[1-*]_cap` and related sysfs files will appear. When the
41 average power consumption exceeds the cap, an ACPI event will be broadcast on
42 the netlink event socket and a poll notification will be sent to the
44 hardware has taken action to reduce power consumption. Most likely this will
48 all cases the ACPI event will be broadcast on the ACPI netlink event socket as
52 `power[1-*]_cap` will be notified if the firmware changes the power cap.
53 `power[1-*]_interval` will be notified if the firmware changes the averaging
|
| /Documentation/networking/device_drivers/ethernet/toshiba/ |
| D | spider_net.rst | 49 discovers that the current descr is not empty, it will signal an
53 hardware is ahead, the tail pointer will be pointing at a "full"
54 descr. The OS will process this descr, and then mark it "not-in-use",
59 The OS will then note that the current tail is "empty", and halt
63 When traffic is flowing, then the head pointer will be pointing at
64 a "not-in-use" descr. The OS will perform various housekeeping duties
66 dma-mapping it so as to make it visible to the hardware. The OS will
71 pointer, at which point the OS will notice that the head descr is
72 "empty", and it will halt processing.
74 Thus, in an idle system, the GDACTDPA, tail and head pointers will
[all …]
|
| /Documentation/gpu/rfc/ |
| D | i915_small_bar.h | 20 * here, also note that no current region type will ever return -1 here.
30 * Without this (or if this is an older kernel) the value here will
33 * will always equal the @probed_size).
45 * This will be always be <= @probed_size, and the
46 * remainder (if there is any) will not be CPU
49 * On systems without small BAR, the @probed_size will
51 * of it will be CPU accessible.
55 * value here will always equal the @probed_size).
75 * value here will always equal the
79 * accounting. Without this the value here will always
[all …]
|
| /Documentation/admin-guide/laptops/ |
| D | disk-shock-protection.rst | 43 Otherwise, writing an integer value to this file will take the heads
47 normal operation will be resumed. The maximal value accepted for a
48 timeout is 30000 milliseconds. Exceeding this limit will return
49 -EOVERFLOW, but heads will be parked anyway and the timeout will be
58 reading from `/sys/block/*/device/unload_heads` will report the number
59 of milliseconds remaining until normal operation will be resumed;
60 otherwise, reading the unload_heads attribute will return 0.
71 will show you how many milliseconds are left before normal operation
72 will be resumed.
78 that this will typically be within 500 milliseconds apparently has
[all …]
|
| /Documentation/ABI/stable/ |
| D | sysfs-module | 6 module name will always show up if the module is loaded as a
8 will only show up if it has a version or at least one
23 considered stable, only the fact that they will be
31 will contain the current reference count of the module.
35 this file will not be present.
40 If the module source has MODULE_VERSION, this file will contain
46 If the module source has MODULE_VERSION, this file will contain
52 Contact: Will McVicker <willmcvicker@google.com>
53 Description: This read-only file will appear if modpost was supplied with an
|
| /Documentation/userspace-api/media/cec/ |
| D | cec-ioc-g-mode.rst | 47 When a CEC message is received, then the CEC framework will decide how
48 it will be processed. If the message is a reply to an earlier
50 is waiting for it. In addition the CEC framework will process it.
52 If the message is not a reply, then the CEC framework will process it
56 follower who will use :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>` to dequeue
60 The CEC framework will process core messages unless requested otherwise
62 case, the CEC framework will pass on most core messages without
63 processing them and the follower will have to implement those messages.
64 There are some messages that the core will always process, regardless of
104 then an attempt to become one will return the ``EBUSY`` error code
[all …]
|
| /Documentation/virt/kvm/s390/ |
| D | s390-pv-boot.rst | 12 Memory made accessible to the hypervisor will be encrypted. See
19 Based on this data, KVM will make the protected virtual machine known
23 SIE instruction which the UV will intercept and execute on KVM's
56 The PV header contains the keys and hashes, which the UV will use to
62 After the initial import of the encrypted data, all defined pages will
63 contain the guest content. All non-specified pages will start out as
67 When running in protected virtualization mode, some subcodes will result in
71 memory, will result in specification exceptions. This is because the
72 UV will clear all memory when a secure VM is removed, and therefore
75 Subcodes 8, 9, 10 will result in specification exceptions.
[all …]
|
| /Documentation/admin-guide/nfs/ |
| D | nfs-idmapper.rst | 11 NFS will attempt to call /sbin/request-key first. If this succeeds, the
12 result will be cached using the generic request-key cache. This call should
18 configured with the id_resolver key type), then the idmapper will ask the
19 legacy rpc.idmap daemon for the id mapping. This result will be stored
26 The file /etc/request-key.conf will need to be modified so /sbin/request-key can
34 This will direct all id_resolver requests to the program /usr/sbin/nfs.idmap.
35 The last parameter, 600, defines how many seconds into the future the key will
37 is not specified, nfs.idmap will default to 600 seconds.
57 request-key will find the first matching line and corresponding program. In
58 this case, /some/other/program will handle all uid lookups and
[all …]
|
| /Documentation/trace/ |
| D | ftrace-design.rst | 14 Here we will cover the architecture pieces that the common function tracing
37 You will need to implement the mcount and the ftrace_stub functions.
39 The exact mcount symbol name will depend on your toolchain. Some call it
66 mcount(), the arguments mcount() will pass to the tracer are:
68 - "frompc" - the address bar() will use to return to foo()
71 Also keep in mind that this mcount function will be called *a lot*, so
72 optimizing for the default case of no tracer will help the smooth running of
119 Deep breath ... time to do some real work. Here you will need to update the
137 That function will simply call the common ftrace_return_to_handler function and
138 that will return the original return address with which you can return to the
[all …]
|
| /Documentation/core-api/ |
| D | xarray.rst | 22 clustered; hashing the object and using the hash as the index will not
53 the range will return the same entry as looking up any other index in
54 the range. Storing to any index will store to all of them. Multi-index
56 into any entry will cause the XArray to forget about the range.
67 using xa_load(). xa_store will overwrite any entry with the
75 xa_cmpxchg(). Like cmpxchg(), it will only succeed if
91 of indices. If you do this, some of the other operations will behave
98 will not need to allocate memory. The xa_reserve() function
99 will store a reserved entry at the indicated index. Users of the
100 normal API will see this entry as containing ``NULL``. If you do
[all …]
|