Searched full:safe (Results 1 – 25 of 255) sorted by relevance
1234567891011
| /Documentation/i2c/ |
| D | dma-considerations.rst | 11 Therefore, it is *not* mandatory that the buffer of an I2C message is DMA safe.
13 rarely used. However, it is recommended to use a DMA-safe buffer if your
19 safe buffers always, because USB requires it.
24 For clients, if you use a DMA safe buffer in i2c_msg, set the I2C_M_DMA_SAFE
33 SMBus transactions via I2C, the buffers for block transfers are DMA safe. Users
34 of i2c_master_send() and i2c_master_recv() functions can now use DMA safe
36 know their buffers are DMA safe. Users of i2c_transfer() must set the
42 Bus master drivers wishing to implement safe DMA can use helper functions from
43 the I2C core. One gives you a DMA-safe buffer for a given i2c_msg as long as a
|
| /Documentation/devicetree/bindings/power/supply/ |
| D | qcom,pm8916-lbc.yaml | 63 qcom,fast-charge-safe-voltage:
68 Maximum safe battery voltage in uV; May be pre-set by bootloader,
71 qcom,fast-charge-safe-current:
76 Maximum safe battery charge current in uA; May be pre-set by
86 - qcom,fast-charge-safe-voltage
87 - qcom,fast-charge-safe-current
125 qcom,fast-charge-safe-current = <900000>;
126 qcom,fast-charge-safe-voltage = <4300000>;
|
| D | qcom,pm8941-charger.yaml | 66 qcom,fast-charge-safe-voltage:
71 Maximum safe battery voltage in uV; May be pre-set by bootloader, in which case,
75 qcom,fast-charge-safe-current:
80 Maximum safe battery charge current in uA; May pre-set by bootloader, in which case,
|
| /Documentation/admin-guide/hw-vuln/ |
| D | srso.rst | 58 * 'Vulnerable: Safe RET, no microcode':
60 The "Safe RET" mitigation (see below) has been applied to protect the
64 * 'Vulnerable: Microcode, no safe RET':
85 * 'Mitigation: Safe RET':
91 Selected by default or by spec_rstack_overflow=safe-ret
95 Similar protection as "safe RET" above but employs an IBPB barrier on
115 not affected anymore and thus "safe RET" is not needed.
136 default one is 'Mitigation: safe RET' which should take care of most
145 As one can surmise, 'Mitigation: safe RET' does come at the cost of some
155 Mitigation: Safe RET
[all …]
|
| D | indirect-target-selection.rst | 63 added ITS-safe thunks. These safe thunks consists of indirect branch in the
65 a retpoline site is evaluated to be ITS-safe, it is replaced with an inline
70 From a dynamically allocated pool of safe-thunks, each vulnerable site is
90 safe thunks. Unless user requested the RSB-stuffing mitigation.
158 relocated to safe thunks.
|
| D | cross-thread-rsb.rst | 13 address prediction entries with safe targets when context switching to the idle
69 context switch fills the RAP entries (referred to as the RSB in Linux) with safe
|
| /Documentation/devicetree/bindings/display/tegra/ |
| D | nvidia,tegra124-sor.yaml | 119 - description: safe reference clock for the SOR clock
131 - const: safe
141 - description: safe reference clock for the SOR clock
152 - const: safe
182 clock-names = "sor", "out", "parent", "dp", "safe";
|
| /Documentation/scsi/ |
| D | dc395x.rst | 10 be safe to use. Testing with hard disks has not been done to any
28 safe
31 If safe is set to 1 then the adapter will use conservative
32 ("safe") default settings. This sets:
99 dc395x. (eg "dc395x.safe=1")
|
| /Documentation/devicetree/bindings/dma/ |
| D | ti-dma-crossbar.txt | 16 - ti,dma-safe-map: Safe routing value for unused request lines
52 ti,dma-safe-map = <0>;
|
| /Documentation/devicetree/bindings/arm/omap/ |
| D | crossbar.txt | 27 - ti,irqs-safe-map: integer which maps to a safe configuration to use
|
| /Documentation/locking/ |
| D | spinlocks.rst | 18 The above is always safe. It will disable interrupts _locally_, but the
45 NOTE! The spin-lock is safe only when you **also** use the lock itself
101 are the most safe ones, and the ones that work under all circumstances,
102 but partly **because** they are safe they are also fairly slow. They are slower
|
| D | lockdep-design.rst | 117 A lock is irq-safe means it was ever used in an irq context, while a lock
124 <hardirq-safe> or <hardirq-unsafe>
125 <softirq-safe> or <softirq-unsafe>
127 This is because if a lock can be used in irq context (irq-safe) then it
159 <hardirq-safe> -> <hardirq-unsafe>
160 <softirq-safe> -> <softirq-unsafe>
162 The first rule comes from the fact that a hardirq-safe lock could be
164 thus could result in a lock inversion deadlock. Likewise, a softirq-safe
175 - if a new hardirq-safe lock is discovered, we check whether it
178 - if a new softirq-safe lock is discovered, we check whether it took
[all …]
|
| D | preempt-locking.rst | 2 Proper Locking Under a Preemptible Kernel: Keeping Kernel Code Preempt-Safe
53 Note, some FPU functions are already explicitly preempt safe. For example,
121 This code is not preempt-safe, but see how easily we can fix it by simply
|
| /Documentation/ABI/obsolete/ |
| D | sysfs-firmware-acpi | 8 enabling this knob is not safe and thus unsupported.
|
| /Documentation/userspace-api/ |
| D | no_new_privs.rst | 22 new, generic mechanism to make it safe for a process to modify its
61 several options to ``unshare(2)`` and ``clone(2)`` would be safe when
|
| /Documentation/livepatch/ |
| D | callbacks.rst | 10 - Safe updates to global data
78 safe and to stop the current patching request. (When no pre-patch
79 callback is provided, the transition is assumed to be safe.) If a
|
| D | livepatch.rst | 70 when it is safe to do so, e.g. when the affected locks are released
73 The theory about how to apply functions a safe way is rather complex.
83 Patches are applied on a per-task basis, when the task is deemed safe to
95 safe to patch tasks:
184 klp_update_patch_state() in a safe location. Kthreads are typically
185 in an infinite loop which does some action repeatedly. The safe
194 There the safe location must be carefully selected on a case-by-case
388 Module removal is only safe when there are no users of functions provided
|
| /Documentation/infiniband/ |
| D | core_locking.rst | 39 are therefore safe to call from any context.
46 the midlayer is also safe to call from any context.
|
| /Documentation/arch/arm/ |
| D | cluster-pm-race-avoidance.rst | 29 cluster-level operations are only performed when it is truly safe to do
37 methods of coordination are required in order to guarantee safe
177 When a CPU reaches the CPU_UP state, it is safe for the CPU to
184 CPU is coherent yet, but it does mean that it is safe to resume
225 In order to enable safe coordination in such situations, it is important
507 is needed for safe transitions at the cluster level.
|
| /Documentation/rust/ |
| D | general-information.rst | 82 should provide as-safe-as-possible abstractions as needed.
97 | driver | Safe | | sub- | | sub- | | Unsafe | | |
132 access to the bindings into an as-safe-as-possible API that they expose to their
|
| /Documentation/ABI/testing/ |
| D | sysfs-driver-pciback | 25 and the actual device is assigned to a HVM. It is not safe
|
| /Documentation/sound/cards/ |
| D | hdspm.rst | 85 safe pointer for writing, which is used on this mode inside
203 * Safe Mode oder Auto Input
205 * Name -- "Safe Mode"
225 Choosing the Input, optical or coaxial. If Safe-mode is active,
|
| /Documentation/power/regulator/ |
| D | design.rst | 21 specific knowledge that these changes are safe to perform on this
|
| /Documentation/w1/slaves/ |
| D | w1_ds2406.rst | 24 respectively. Bits 2-7 are ignored, so it's safe to write ASCII data.
|
| /Documentation/networking/ |
| D | sctp.rst | 30 module removal of lksctp is not yet a safe activity.
|
1234567891011