/Linux-v6.6/arch/arm/probes/kprobes/ |
D | test-core.c | 1021 static unsigned long test_context_cpsr(int scenario) in test_context_cpsr() argument 1028 cpsr = (scenario & 0xf) << 28; /* N,Z,C,V flags */ in test_context_cpsr() 1029 cpsr |= (scenario & 0xf) << 16; /* GE flags */ in test_context_cpsr() 1030 cpsr |= (scenario & 0x1) << 27; /* Toggle Q flag */ in test_context_cpsr() 1037 if (scenario == 15) in test_context_cpsr() 1047 if (scenario == 15) in test_context_cpsr() 1052 unsigned x = (scenario >> 4); in test_context_cpsr() 1060 if ((scenario & 0xf) == 0xf) in test_context_cpsr() 1075 switch (scenario) { in test_context_cpsr() 1099 int scenario = test_case_run_count>>1; in setup_test_context() local [all …]
|
/Linux-v6.6/tools/testing/selftests/rcutorture/bin/ |
D | kvm-test-1-run-batch.sh | 26 echo Bad scenario name: \"$i\" 1>&2 78 affinity_export="`awk -f $T/cpubatches.awk -v cpu_count="$cpu_count" -v scenario=$i < /dev/null`"
|
D | kvm-test-1-run.sh | 174 echo To run this scenario on bare metal: >> $resdir/bare-metal
|
/Linux-v6.6/Documentation/RCU/ |
D | torture.rst | 195 eight-CPU scenario:: 211 Note that --gdb limits you to one scenario per kvm.sh run and requires 253 directory (2020.01.20-15.54.23 in the example above), while per-scenario 254 files reside in a subdirectory named after the scenario (for example, 255 "TREE04"). If a given scenario ran more than once (as in "--configs 257 subsequent runs of that scenario include a sequence number, for example, 264 The most frequently used files in each per-scenario-run directory are: 270 This contains build output for a specific scenario. 273 This contains the console output for a specific scenario. 357 This will build each default scenario's kernel on the local system, then [all …]
|
D | rcuref.rst | 52 in this scenario as follows:
|
/Linux-v6.6/Documentation/crypto/ |
D | devel-algos.rst | 183 ^ | | at all in this scenario. 189 ^ | | at all in this scenario. 206 .setkey() -> .init() -> .update() -> .export() at all in this scenario. 215 ^ | | at all in this scenario.
|
/Linux-v6.6/Documentation/driver-api/memory-devices/ |
D | ti-gpmc.rst | 35 in time or in cycles, provision to handle this scenario has been 38 in timing structure, in this scenario, try to correlate peripheral
|
/Linux-v6.6/Documentation/driver-api/mmc/ |
D | mmc-async-req.rst | 70 request. The host driver may optimize for this scenario to minimize 75 Pseudocode to handle is_first_req scenario with minimal prepare overhead::
|
/Linux-v6.6/Documentation/admin-guide/hw-vuln/ |
D | srso.rst | 8 known scenario of poisoning CPU functional units - the Branch Target 92 Mitigation addressing the cloud provider scenario - the Guest->Host
|
D | l1tf.rst | 111 deployment scenario. The mitigations, their protection scope and impact 200 workload scenario and the resulting number of VMEXITs. 238 scenario. Disabling SMT might be a viable alternative for particular 280 the impact depends on the hosting scenario and the type of workloads. 522 the scenario still trigger soft interrupts and schedule kernel threads
|
/Linux-v6.6/Documentation/networking/ |
D | ipsec.rst | 45 above scenario. The consequence of doing so is small packet(uncompressed)
|
/Linux-v6.6/Documentation/admin-guide/mm/ |
D | soft-dirty.rst | 34 there is still a scenario when we can lose soft dirty bits -- a task
|
/Linux-v6.6/Documentation/i2c/busses/ |
D | i2c-sis96x.rst | 58 scenario is found where they're needed.
|
/Linux-v6.6/Documentation/locking/ |
D | lockdep-design.rst | 129 deadlock may happen. For example, in the scenario that after this lock 189 could lead to a lock inversion deadlock - even if that lock scenario did 305 every possible hardirq and softirq nesting scenario (which is impossible 327 This problem is solved by checking any given 'locking scenario' (unique 634 waiting scenario and nobody can get progress, therefore a deadlock. 638 Lemma 2 is equivalent to: If there is a deadlock scenario, then there must be a 642 waiting scenario, means there are N CPU/tasks, where CPU/task P1 is waiting for
|
/Linux-v6.6/Documentation/sound/hd-audio/ |
D | dp-mst.rst | 44 - MST must be dyn_pcm_assign, and it is acomp (for Intel scenario);
|
/Linux-v6.6/Documentation/sound/soc/ |
D | codec-to-codec.rst | 41 a speaker and you have a below scenario:
|
/Linux-v6.6/Documentation/kbuild/ |
D | Kconfig.recursion-issue-02 | 41 # For an example real world scenario issue refer to the attempt to remove
|
/Linux-v6.6/Documentation/driver-api/ |
D | ntb.rst | 55 So typical scenario of the first type memory window initialization looks: 73 Typical scenario of the second type interface initialization would be: 93 In accordance with this scenario, the NTB Memory Window API can be used as
|
/Linux-v6.6/Documentation/admin-guide/device-mapper/ |
D | era.rst | 72 The scenario of invalidating a cache when rolling back a vendor
|
/Linux-v6.6/Documentation/userspace-api/media/v4l/ |
D | pixfmt-v4l2-mplane.rst | 30 codec to support the worst-case compression scenario.
|
/Linux-v6.6/Documentation/usb/ |
D | raw-gadget.rst | 51 A typical usage scenario of Raw Gadget:
|
/Linux-v6.6/Documentation/mm/ |
D | mmu_notifier.rst | 31 Consider the following scenario (device use a feature similar to ATS/PASID):
|
/Linux-v6.6/Documentation/driver-api/nvdimm/ |
D | firmware-activate.rst | 37 activation. In that scenario the potential for firmware activation to
|
/Linux-v6.6/Documentation/powerpc/ |
D | eeh-pci-error-recovery.rst | 97 reinitialization of the device driver. In a worst-case scenario, 105 kernel/device driver should assume the worst-case scenario, that the 320 succeed. Both have been only lightly tested in this scenario.
|
/Linux-v6.6/Documentation/ABI/testing/ |
D | sysfs-class-power | 136 This is normally used for the charging scenario where 161 This is normally used for the charging scenario where user-space 279 battery discharging scenario where user-space needs to know the 294 battery discharging scenario where user-space needs to know the
|