/openbmc/u-boot/arch/mips/mach-bmips/ |
H A D | Kconfig | 136 Between its different peripherals there's an integrated switch with 4 147 Between its different peripherals there's an integrated switch with 4 158 Between its different peripherals there's an integrated switch with 4 169 Between its different peripherals there's a BCM5325 switch with 4 180 Between its different peripherals there's an integrated switch with 4 191 Between its different peripherals there's a BCM53115 switch with 5 202 Between its different peripherals there's a BCM5325 switch with 4 213 Between its different peripherals there's a BCM53115 switch with 4 224 Between its different peripherals there's a BCM53125 switch with 5 235 Between its different peripherals there's a BCM5325 switch with 4 [all …]
|
/openbmc/u-boot/doc/ |
H A D | README.sched | 16 - There are NO primitives for thread synchronization (locking, 27 - There are NO priorities, and the scheduling policy is round-robin 30 - There are NO capabilities to collect thread CPU usage, scheduler 47 - There NOT enough safety checks as are probably in the other 50 - There is no parent-child relationship between threads. Only one
|
H A D | README.mpc74xx | 10 There is a framework in place to enable the L2 cache, and to program 11 the BATs. Currently, there are still problems with the code which 13 anyway). Additionally, there is support for enabling the MMU, which
|
H A D | README.generic-board | 42 1. There is a lot of repeated code in the board.c files. Any change to 46 2. Since there are 10 separate files, adding a new feature which requires 50 3. As time goes by the architectures naturally diverge since there is limited 59 achievable. There is no requirement that all code be common, only that 107 There was dicussion on the list about passing gd_t around as a parameter 123 ARM, PPC and x86 boards. There are a few failures due to errors in
|
/openbmc/u-boot/include/dm/ |
H A D | uclass.h | 24 * There may be drivers for on-chip SoC GPIO banks, I2C GPIO expanders and 122 * @ucp: Returns pointer to uclass (there is only one per ID) 150 * @devp: Returns pointer to device (there is only one per for each ID) 173 * If an active device has this sequence it will be returned. If there is no 181 * @devp: Returns pointer to device (there is only one for each seq) 196 * @devp: Returns pointer to device (there is only one for each node) 212 * @devp: Returns pointer to device (there is only one for each node) 227 * @devp: Returns pointer to device (there is only one for each node) 228 * @return 0 if OK, -ENODEV if there is no device match the phandle, other 244 * @devp: Returns pointer to device (there is only one for each node) [all …]
|
/openbmc/phosphor-logging/extensions/openpower-pels/registry/tools/ |
H A D | validate_registry.py | 16 Check that there aren't any message registry entries with the same 17 'Name' field. There may be a use case for this in the future, but there 33 Check that there aren't any message registry entries with the same 83 Check that if the Message field uses the '%' style placeholders that there 85 the MessageArgSources field is present but only if there are placeholders.
|
/openbmc/openbmc/poky/meta/conf/distro/include/ |
H A D | cve-extra-exclusions.inc | 2 # or there is no reasonable action the Yocto Project can take to resolve the issue. 25 There has been much discussion amongst the epiphany and webkit developers and \ 26 whilst there are improvements about how domains are handled and displayed to the user \ 27 there is unlikely ever to be a single fix to webkit or epiphany which addresses this \ 28 problem. There isn't any mitigation or fix or way to progress this further." 70 There was a proposed patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06098.html \ 76 There was a proposed patch but rejected by upstream qemu. It is unclear if the issue can \ 83 wouldn't expose an assembler. The upstream is inactive and there is little to be \
|
/openbmc/sdbusplus/include/sdbusplus/async/stdexec/__detail/ |
H A D | __manual_lifetime.hpp | 50 //! There are no safeties guarding against the case that there's already one 51 //! there. 63 //! There are no safeties guarding against the case that there's already one 64 //! there.
|
/openbmc/u-boot/doc/driver-model/ |
H A D | serial-howto.txt | 11 forward to convert these, at some point there may come a patch to remove them! 19 - Your board should then build, but will not boot since there will be no serial 40 - update the Makefile there 41 - Add stdout-path to your /chosen device tree node if it is not already there
|
H A D | i2c-howto.txt | 21 forward to convert these, at some point there may come a patch to remove them! 29 - Your board should then build, but will not work fully since there will be 50 - update the Makefile there 51 - Add stdout-path to your /chosen device tree node if it is not already there
|
/openbmc/u-boot/board/google/ |
H A D | Kconfig | 19 solid state drive. There is a Chrome OS EC connected on LPC, 40 video output and a 16GB SATA solid state drive. There is no Chrome 51 There is a solid state drive, either 32GB or 64GB. There is a
|
/openbmc/sdbusplus/src/async/ |
H A D | match.cpp | 47 // Set ourselves as the awaiting Receiver and see if there is a message in arm() 73 // Insert the message into the queue and see if there is a pair ready for in handle_match() 84 // If there is no match_completion, there is no awaiting Receiver. in handle_completion() 85 // If the queue is empty, there is no message waiting, so the waiting in handle_completion()
|
/openbmc/u-boot/include/ |
H A D | pch.h | 37 * @return 0 if OK, -ve on error (e.g. there is no SPI base) 56 * @return 0 if OK, -ve on error (e.g. there is no GPIO base) 65 * @return 0 if OK, -ve on error (e.g. there is no IO base) 94 * @return 0 if OK, -ve on error (e.g. there is no SPI base) 113 * @return 0 if OK, -ve on error (e.g. there is no GPIO base) 122 * @return 0 if OK, -ve on error (e.g. there is no IO base)
|
/openbmc/openbmc/meta-openembedded/meta-oe/licenses/ |
H A D | GPL-2.0-with-lmbench-restriction | 39 We have a lot of history with benchmarking and feel strongly that there 43 There has been a lot of discussion about this, with people not liking this 48 It would be a different matter if there were 3 other competing 49 benchmarking systems out there that did what LMbench does and didn't have 50 the same reporting rules. There aren't and as long as that is the case, 61 instructions (CISC), but in either case there is usually a cost to
|
/openbmc/docs/ |
H A D | kernel-development.md | 9 contains the set of patches that we carry. Ideally there would be no patches 33 The first step should be to check that there is no existing driver for the 35 if you do not find support there ask on the mailing list. 50 be one of the subsystem maintainers. From there the OpenBMC kernel team can 55 There are cases where waiting for upstream acceptance will delay the bring-up of 74 The OpenBMC kernel is currently based on the 4.7 series. If there is upstream
|
/openbmc/u-boot/tools/binman/etype/ |
H A D | u_boot_ucode.py | 25 microcode is supplied before there is any SRAM available to use (i.e. 35 There are two cases to handle. If there is only one microcode blob in 37 entry (u-boot-ucode) is empty. If there is more than one update, then 64 # If the section does not need microcode, there is nothing to do
|
/openbmc/qemu/docs/ |
H A D | bypass-iommu.txt | 6 Traditionally, there is a global switch to enable/disable vIOMMU. All 15 virtual iommu. The bypass_iommu property is valid only when there is a 66 There might be potential security risk when devices bypass iommu, because 67 devices might send malicious dma request to virtual machine if there is no 88 so that the devices will by default go through iommu if there exist one.
|
/openbmc/u-boot/drivers/bootcount/ |
H A D | bootcount-uclass.c | 40 * If there's a preferred bootcount device selected by the user (by in bootcount_store() 48 /* If there was no user-selected device, use the first available one */ in bootcount_store() 68 * If there's a preferred bootcount device selected by the user (by in bootcount_load() 76 /* If there was no user-selected device, use the first available one */ in bootcount_load()
|
/openbmc/openbmc/poky/meta/recipes-sato/matchbox-keyboard/files/ |
H A D | 0001-desktop-file-Hide-the-keyboard-from-app-list.patch | 6 matchbox-keyboard is not a normal app and there's no need to start 8 * when there's no hardware keyboard, the panel applet can be used to 10 * when there is a hardware keyboard, matchbox-keyboard can still be
|
/openbmc/bmcweb/docs/ |
H A D | DBUS_USAGE.md | 22 - There are interfaces for which there is an expectation that there will only
|
/openbmc/phosphor-ipmi-blobs/test/ |
H A D | ipmi_getcount_unittest.cpp | 15 // the request here is only the subcommand byte and therefore there's no invalid 20 // Calling BmcBlobGetCount if there are no handlers registered should just in TEST() 21 // return that there are 0 blobs. in TEST()
|
/openbmc/openbmc/meta-yadro/recipes-phosphor/ipmi/phosphor-ipmi-host/ |
H A D | 0001-Add-support-for-persistent-only-settings.patch | 40 + // If there are no objects implementing the requested interface, 48 + // On the contrary, if there is just one object, that may mean 52 + // If there's just one object, that's the only kind of setting 59 + // Something must be wrong if there are more objects than expected 66 + // We are here because there were exactly two objects implementing the
|
/openbmc/openbmc-test-automation/ffdc/docs/ |
H A D | plugin.md | 172 plugin response if there is any will be written to named file, if 190 - exit_on_error : If there was an error in a plugin stacked, the subsequent 192 - continue_on_error : If there was an error and user declare this directive, 206 This error directive would come into force only if there is an error detected by 210 To go further, there is another directive for plugin to check if the plugin
|
/openbmc/docs/designs/ |
H A D | psu-firmware-update.md | 14 There is no support in OpenBMC to update the firmware for PSUs. 18 In OpenBMC, there is an existing interface for [software update][1]. 43 2. After BMC code update and if there is a newer PSU image in the BMC's 49 5. There are cases that a system could use different models of PSUs, and thus 67 As described in the above requirements, there are different cases where the PSU 90 3. There will be a new service that implements the [Activation][5] interface to 130 2. There could be two places containing the PSU images: 170 otherwise, there is no way to tell if the image is for PSU, or CPLD, or other 189 service that implements existing [Activation][5] interface. There will be new
|
/openbmc/openbmc/meta-openembedded/meta-python/recipes-devtools/python/python3-gunicorn/ |
H A D | run-ptest | 3 # there needs to be something in /etc/resolv.conf for the gunicorn 4 # ptests to work, so make sure there's at least one nameserver line
|