| /openbmc/openbmc/poky/meta/lib/oeqa/files/maturin/guessing-game/src/ |
| H A D | lib.rs | 3 use std::cmp::Ordering;
29 Ordering::Less => println!("Too small!"), in guess_the_number()
30 Ordering::Greater => println!("Too big!"), in guess_the_number()
31 Ordering::Equal => { in guess_the_number()
|
| /openbmc/openbmc/meta-openembedded/meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools/ |
| H A D | 0001-Use-portable-atomics-crate.patch | 17 │ 234 | use std::sync::atomic::{AtomicU64, Ordering};
67 +use portable_atomic::{AtomicU64, Ordering};
72 -use std::sync::atomic::{AtomicU64, Ordering};
80 +use portable_atomic::{AtomicU64, Ordering};
83 -use std::sync::atomic::{AtomicU64, Ordering};
|
| /openbmc/u-boot/arch/riscv/include/asm/ |
| H A D | barrier.h | 21 /* These barriers need to enforce ordering on both devices or memory. */
26 /* These barriers do not need to enforce ordering on devices, just memory. */
60 * way we can take advantage of that here because the ordering is only enforced
|
| /openbmc/openbmc/meta-openembedded/meta-webserver/recipes-httpd/nginx/files/ |
| H A D | 0001-Allow-the-overriding-of-the-endianness-via-the-confi.patch | 19 @@ -13,7 +13,13 @@ checking for system byte ordering
70 - echo "$0: error: cannot detect system byte ordering"
73 + echo "$0: error: cannot detect system byte ordering"
|
| /openbmc/u-boot/arch/arm/dts/ |
| H A D | exynos54xx-pinctrl-uboot.dtsi | 10 * Replicate the ordering of arch/arm/include/asm/arch-exynos/gpio.h
11 * TODO(sjg@chromium.org): This ordering ceases to matter once GPIO
|
| /openbmc/qemu/accel/tcg/ |
| H A D | backend-ldst.h | 20 * memory ordering vs the host memory ordering. A non-zero
|
| /openbmc/u-boot/include/linux/ |
| H A D | compiler.h | 259 * compiler is aware of some particular ordering. One way to make the
260 * compiler aware of ordering is to put the two invocations of READ_ONCE,
272 * mutilate accesses that either do not require ordering or that interact
274 * required ordering.
303 * smp_cond_acquire() - Spin wait for cond with ACQUIRE ordering
514 * but only when the compiler is aware of some particular ordering. One way
515 * to make the compiler aware of ordering is to put the two invocations of
525 * mutilate accesses that either do not require ordering or that interact
527 * required ordering.
|
| /openbmc/qemu/include/tcg/ |
| H A D | tcg-mo.h | 29 /* Used to indicate the type of accesses on which ordering
40 /* Used to indicate the kind of ordering which is to be ensured by the
|
| /openbmc/openbmc/poky/bitbake/lib/toaster/tests/browser/ |
| H A D | test_toastertable_ui.py | 91 # check ordering (default is by -completed_on); so build1 should be
120 # check ordering; build1 should be first
140 # check ordering (should revert to completed_on); build2 should be first
|
| /openbmc/openbmc/poky/meta/lib/oeqa/runtime/cases/ |
| H A D | parselogs.py | 48 'Found ordering cycle on',
49 'Breaking ordering cycle by deleting job',
50 'deleted to break ordering cycle',
51 'Ordering cycle found, skipping',
|
| /openbmc/qemu/target/ppc/translate/ |
| H A D | misc-impl.c.inc | 101 * eieio has complex semanitcs. It provides memory ordering between
119 * The end result is that CI memory ordering requires TCG_MO_ALL
120 * and it is not possible to special-case more relaxed ordering for
|
| /openbmc/bmcweb/redfish-core/schema/dmtf/json-schema/ |
| H A D | Resource.v1_23_0.json | 375 "description": "The orientations for the ordering of the part location ordinal value.",
385 "BackToFront": "The ordering for the LocationOrdinalValue is back to front.",
386 "BottomToTop": "The ordering for `LocationOrdinalValue` is bottom to top.",
387 "FrontToBack": "The ordering for `LocationOrdinalValue` is front to back.",
388 "LeftToRight": "The ordering for the LocationOrdinalValue is left to right.",
389 "RightToLeft": "The ordering for the LocationOrdinalValue is right to left.",
390 "TopToBottom": "The ordering for the LocationOrdinalValue is top to bottom."
393 …"BackToFront": "This value shall indicate the ordering for `LocationOrdinalValue` is back to front…
394 …"BottomToTop": "This value shall indicate the ordering for `LocationOrdinalValue` is bottom to top…
395 …"FrontToBack": "This value shall indicate the ordering for `LocationOrdinalValue` is front to back…
[all …]
|
| /openbmc/bmcweb/redfish-core/schema/dmtf/json-schema-installed/ |
| H A D | Resource.v1_23_0.json | 375 "description": "The orientations for the ordering of the part location ordinal value.",
385 "BackToFront": "The ordering for the LocationOrdinalValue is back to front.",
386 "BottomToTop": "The ordering for `LocationOrdinalValue` is bottom to top.",
387 "FrontToBack": "The ordering for `LocationOrdinalValue` is front to back.",
388 "LeftToRight": "The ordering for the LocationOrdinalValue is left to right.",
389 "RightToLeft": "The ordering for the LocationOrdinalValue is right to left.",
390 "TopToBottom": "The ordering for the LocationOrdinalValue is top to bottom."
393 …"BackToFront": "This value shall indicate the ordering for `LocationOrdinalValue` is back to front…
394 …"BottomToTop": "This value shall indicate the ordering for `LocationOrdinalValue` is bottom to top…
395 …"FrontToBack": "This value shall indicate the ordering for `LocationOrdinalValue` is front to back…
[all …]
|
| /openbmc/qemu/tcg/i386/ |
| H A D | tcg-target-mo.h | 14 * The x86 has a pretty strong memory ordering which only really
|
| /openbmc/openbmc/meta-phosphor/recipes-devtools/btrfs-tools/ |
| H A D | btrfs-tools_%.bbappend | 7 # There is an issue with the upstream `inherit_defer` ordering where a
|
| /openbmc/qemu/host/include/loongarch64/host/ |
| H A D | cpuinfo.h | 17 * We cannot rely on constructor ordering, so other constructors must
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Software/ |
| H A D | ActivationBlocksTransition.interface.yaml | 11 `Activating` state. Causal ordering of dbus operations can prove that no
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Logging/ |
| H A D | ErrorBlocksTransition.interface.yaml | 11 ordering of D-Bus operations can prove that no critical error needs
|
| /openbmc/qemu/docs/system/ |
| H A D | target-ppc.rst | 14 by the title text of each file, which isn't the same ordering
|
| H A D | targets.rst | 14 by the title text of each file, which isn't the same ordering
|
| /openbmc/qemu/include/qemu/ |
| H A D | sys_membarrier.h | 14 * side. The slow side forces processor-level ordering on all other cores
|
| /openbmc/qemu/host/include/aarch64/host/ |
| H A D | cpuinfo.h | 20 * We cannot rely on constructor ordering, so other constructors must
|
| /openbmc/qemu/host/include/riscv/host/ |
| H A D | cpuinfo.h | 21 * We cannot rely on constructor ordering, so other constructors must
|
| /openbmc/qemu/docs/devel/ |
| H A D | multi-thread-tcg.rst | 255 ordered hosts needs to ensure things like store-after-load re-ordering
262 to enforce a particular ordering of memory operations from the point
272 provide explicit memory ordering semantics. However they can be used
279 This would enforce a strong load/store ordering so all loads/stores
284 also implicit memory ordering semantics which comes with each guest
|
| /openbmc/u-boot/arch/x86/include/asm/arch-broadwell/ |
| H A D | me.h | 135 * ME to BIOS Payload Datastructures and definitions. The ordering of the
136 * structures follows the ordering in the ME9 BWG.
|