Home
last modified time | relevance | path

Searched full:relying (Results 1 – 25 of 282) sorted by relevance

12345678910>>...12

/openbmc/bmcweb/include/
H A Dstr_utility.hpp29 // Converts a character to lower case without relying on std::locale in asciiToLower()
/openbmc/openbmc/poky/meta/recipes-devtools/rpm/files/
H A D0002-rpmio-rpmglob.c-avoid-using-GLOB_BRACE-if-undefined-.patch7 This addresses musl failures; if there is code out there relying on
/openbmc/openbmc/poky/meta/recipes-devtools/perl-cross/files/
H A DREADME.md20 relying solely on compile/link tests and pre-defined hints.
/openbmc/linux/net/hsr/
H A DKconfig38 relying on this code in a safety critical system!
/openbmc/linux/Documentation/tools/rv/
H A Drv.rst22 Instead of relying on a fine-grained model of a system (e.g., a
/openbmc/linux/scripts/
H A DMakefile.clang3 # relying on the target triple.
/openbmc/linux/Documentation/driver-api/
H A Dvfio-pci-device-specific-driver-acceptance.rst9 system IOMMU and relying on the robustness of platform fault
/openbmc/qemu/hw/s390x/
H A Ds390-skeys.c246 * actually relying on this data. in qemu_s390_enable_skeys()
247 * 2) Relying on ram_size and allocating a big array is ugly. We should in qemu_s390_enable_skeys()
250 * 3) We only ever have a single S390SKeysState, so relying on in qemu_s390_enable_skeys()
/openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Dump/
H A DEntry.interface.yaml37 of file in their own context, without relying on additional API calls.
/openbmc/linux/Documentation/powerpc/
H A Dkaslr-booke32.rst11 attempts relying on knowledge of the location of kernel internals.
/openbmc/docs/designs/
H A Dentity-manager-hw-id-vpd-discover-via-device-tree.md33 HPE hardware uses different channels and data formats from the above, relying on
175 potential for non-HPE platform to make easy use of it. Relying on 'model' as
265 suggested relying on xyz.openbmc_project.Inventory.Decorator.Asset (for
/openbmc/linux/include/uapi/linux/
H A Dsecurebits.h26 When unset, to provide compatiblility with old programs relying on
/openbmc/qemu/docs/specs/
H A Dacpi_hw_reduced_hotplug.rst15 single interrupt for the GED device, relying on an IO memory region
/openbmc/linux/drivers/gpu/drm/i915/gt/
H A Dintel_engine_pm.h95 * the usual mutexes and relying on the engine-pm barrier in intel_engine_create_kernel_request()
/openbmc/linux/Documentation/mm/
H A Dovercommit-accounting.rst17 just relying on the virtual memory consisting almost entirely
/openbmc/linux/tools/memory-model/Documentation/
H A Dcontrol-dependencies.txt145 to relying on control dependencies to produce this ordering, you should
163 You must also be careful avoid relying too much on boolean short-circuit
/openbmc/openbmc/meta-openembedded/meta-oe/recipes-kernel/usbip-tools/
H A Dusbip-tools.bb53 # Use local scripts before relying on inherited autotools
/openbmc/linux/include/linux/
H A Dzstd_errors.h33 * note 2 : Prefer relying on the enum than on its value whenever possible
/openbmc/linux/tools/testing/selftests/riscv/hwprobe/
H A Dhwprobe.c6 * Rather than relying on having a new enough libc to define this, just do it
/openbmc/qemu/include/hw/ppc/
H A Dspapr_ovec.h23 * bits using only the documented values. This is done mainly by relying
/openbmc/openbmc/meta-openembedded/meta-oe/recipes-multimedia/libmad/libmad/
H A Dadd-pkgconfig.patch7 developers) have started relying on this support being present, causing
/openbmc/bmcweb/
H A DHEADERS.md13 Boost::beast at the time we ported took the same opinion, relying on header
/openbmc/linux/Documentation/nvme/
H A Dfeature-and-quirk-policy.rst77 should be fixed before it is shipped instead of relying on Linux quirks.
/openbmc/linux/arch/arm64/kernel/
H A Dperf_regs.c52 * how well that works in practice, somebody might be relying on it. in perf_reg_value()
/openbmc/qemu/include/hw/acpi/
H A Dgeneric_event_device.h17 * method. Here, we use a single interrupt for the GED device, relying

12345678910>>...12