| /openbmc/phosphor-fan-presence/presence/ |
| H A D | psensor.hpp | 16 * Provide concrete implementations of PresenceSensor to realize
19 * Note that implementations drive the inventory update process via
39 * Implementations should peform any preparation
40 * for detecting presence. Typical implementations
51 * Implementations should stop issuing presence
52 * state change notifications. Typical implementations
61 * Implementations should perform an offline (the start
72 * Implementations should log an an event if the
|
| H A D | rpolicy.hpp | 19 * Provide concrete implementations of RedundancyPolicy to realize
50 * a change of presence. Implementations should update
61 * Implementations should start monitoring the sensors
|
| /openbmc/linux/lib/crypto/ |
| H A D | Kconfig | 33 This symbol can be depended upon by arch implementations of the
35 fallback, e.g., for SIMD implementations. If no arch specific
50 This symbol can be depended upon by arch implementations of the
52 fallback, e.g., for SIMD implementations. If no arch specific
75 This symbol can be depended upon by arch implementations of the
77 fallback, e.g., for SIMD implementations. If no arch specific
111 This symbol can be depended upon by arch implementations of the
113 fallback, e.g., for SIMD implementations. If no arch specific
|
| /openbmc/linux/fs/crypto/ |
| H A D | Kconfig | 25 # Also note that this option only pulls in the generic implementations of the
26 # algorithms, not any per-architecture optimized implementations. It is
27 # strongly recommended to enable optimized implementations too. It is safe to
28 # disable these generic implementations if corresponding optimized
29 # implementations will always be available too; for this reason, these are soft
31 # implementations if you're sure they will never be needed, though.
|
| /openbmc/linux/Documentation/admin-guide/device-mapper/ |
| H A D | dm-log.rst | 15 implementations use to perform logging operations (see
17 logging implementations are available and provide different
43 so log implementations can be done there. This is done by forwarding most
53 There are currently two userspace log implementations that leverage this
54 framework - "clustered-disk" and "clustered-core". These implementations
56 can be used in a shared-storage environment when the cluster log implementations
|
| /openbmc/u-boot/drivers/crypto/ |
| H A D | Kconfig | 20 requiring the SHA software implementations, saving code size.
33 SHA software implementations, saving code size.
43 software implementations, saving code size.
|
| /openbmc/qemu/scripts/ |
| H A D | compare-machine-types.py | 84 def set_implementations(self, implementations: List['Driver']) -> None:
85 self.implementations = implementations
92 def set_implementations(self, implementations: List[Driver]) -> None:
93 self.implementations = implementations
99 for impl in implementations:
189 # only implementations inherit property getter
205 return [impl.name for impl in self.drivers[driver].implementations]
211 implementations)
220 # values from abstract class to all implementations
298 x86_64-cpu) this script will compare all implementations of this class.
|
| /openbmc/linux/Documentation/devicetree/bindings/mfd/ |
| H A D | google,cros-ec.yaml | 23 For implementations of the EC connected through I2C.
26 For implementations of the EC connected through SPI.
29 For implementations of the FPMCU connected through SPI.
34 For implementations of the EC connected through RPMSG.
37 For implementations of the EC connected through UART.
57 Some implementations of the EC include a small nvram space used to
|
| /openbmc/linux/Documentation/bpf/ |
| H A D | bpf_licensing.rst | 26 Implementations of eBPF
35 The reference implementations of the eBPF interpreter and various just-in-time
43 There are also implementations of eBPF runtime (interpreter, JITs, helper
58 Other kernels or user space implementations of eBPF instruction set and runtime
|
| /openbmc/linux/drivers/net/wireless/intel/iwlwifi/ |
| H A D | iwl-drv.h | 36 * This component is also in charge of managing the several implementations of
38 * different implementations will differ in the way they implement mac80211's
62 * specific system flows implementations. For example, the bus specific probe
74 * implementations. For example, the bus specific remove function should first
|
| /openbmc/linux/Documentation/crypto/ |
| H A D | architecture.rst | 23 The kernel crypto API provides implementations of single block ciphers
101 The kernel crypto API may provide multiple implementations of a template
103 the following implementations: AES-NI, assembler implementation, or
109 implementations providing an implementation with that name and selects
243 existing cipher implementations. The first section addresses the most
258 generic C implementations (gcm.c, aes-generic.c, ctr.c, ghash-generic.c,
262 It is possible that some streamlined cipher implementations (like
263 AES-NI) provide implementations merging aspects which in the view of the
374 Keyed message digest implementations again follow the same concept as
|
| H A D | intro.rst | 27 - data transformation implementations (typically ciphers) that can be
33 implementations (i.e. implementations of ciphers and other
|
| /openbmc/linux/drivers/net/ethernet/ibm/emac/ |
| H A D | emac.h | 28 /* Common registers across all EMAC implementations. */
42 /* Registers unique to EMAC4 implementations */
53 /* Registers unique to EMAC4SYNC implementations */
62 /* Common registers across all EMAC implementations. */
72 /* Registers unique to EMAC4 implementations */
76 /* Registers unique to EMAC4SYNC implementations */
|
| /openbmc/linux/mm/ |
| H A D | zpool.c | 7 * This is a common frontend for memory storage pool implementations.
141 * Implementations must guarantee this to be thread-safe.
192 * Implementations must guarantee this to be thread-safe,
214 * Implementations must guarantee this to be thread-safe.
230 * Implementations must guarantee this to be thread-safe.
251 * Implementations must guarantee this to be thread-safe.
270 * Implementations must guarantee this to be thread-safe,
|
| /openbmc/linux/Documentation/netlabel/ |
| H A D | draft-ietf-cipso-ipsecurity-01.txt | 117 not appear as the DOI identifier in any CIPSO option. Implementations
150 identifier field in the CIPSO header, implementations should assume that
160 types, implementations will require the DOI identifier as well as the tag
163 interoperability with other networks will not be an issue. Implementations
237 speed many implementations including router implementations.
334 speed many implementations including router implementations.
386 speed many implementations including router implementations.
447 parameters are required for CIPSO implementations:
543 CIPSO implementations that support only one label are not required to
544 support the parameters described above. These limited implementations are
|
| /openbmc/linux/Documentation/core-api/ |
| H A D | genericirq.rst | 67 Analysing a couple of architecture's IRQ subsystem implementations
75 which is normally one of the generic implementations. (This high-level
86 of existing implementations, the __do_IRQ() super-handler is still
177 Default flow implementations
184 default flow implementations. The following helper functions are
219 Default flow handler implementations
349 implementations.
392 To avoid copies of identical implementations of IRQ chips the core
|
| /openbmc/docs/designs/mctp/ |
| H A D | mctp.md | 69 implementations in host firmware, which have widely varying runtime
75 - Be usable over simple hardware implementations, but have a facility for higher
110 firmware), this is may not be feasible for all host firmware implementations
126 and managed device implementations.
|
| /openbmc/openbmc/meta-openembedded/meta-python/recipes-devtools/python/ |
| H A D | tftpy_0.8.2.bb | 1 …e Python programming language. It includes client and server classes, with sample implementations."
3 includes client and server classes, with sample implementations. Hooks are \
|
| /openbmc/linux/Documentation/nvme/ |
| H A D | feature-and-quirk-policy.rst | 62 Sometimes implementations of open standards fail to correctly implement parts
66 Typically these implementations are not or only superficially tested with Linux
69 The Linux NVMe maintainers decide ad hoc whether to quirk implementations
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-benchmark/libc-bench/ |
| H A D | libc-bench_git.bb | 1 SUMMARY = "Tests to compare standard functions of different libc implementations"
3 implementations of various C/POSIX standard library functions."
|
| /openbmc/linux/drivers/crypto/caam/ |
| H A D | Kconfig | 97 bool "Register algorithm implementations with the Crypto API"
128 bool "Register hash algorithm implementations with Crypto API"
137 bool "Register public key cryptography implementations with Crypto API"
|
| /openbmc/qemu/target/sparc/ |
| H A D | cpu-param.h | 35 * implemented in some non-Sun SPARC V9 implementations, but is not
36 * directly supported in Oracle SPARC Architecture 2015 implementations.
|
| /openbmc/phosphor-dbus-monitor/src/ |
| H A D | watch.hpp | 17 * or initialization. Typical implementations might register dbus
22 * their setup. Typical implementations will forward the call
|
| /openbmc/linux/Documentation/admin-guide/ |
| H A D | ufs.rst | 13 The problem are differences among implementations. Features of
14 some implementations are undocumented, so its hard to recognize
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Control/ |
| H A D | VoltageRegulatorMode.interface.yaml | 5 where the VR has a well defined default, implementations should place the
12 if the VR itself defines the interfaces. Implementations may implement this
|