| /openbmc/openbmc/meta-arm/meta-arm-bsp/recipes-kernel/linux/arm-platforms-kmeta/bsp/arm-platforms/ |
| H A D | juno.scc | 8 kconf hardware juno/juno-board.cfg
9 kconf hardware juno/juno-devfreq.cfg
10 kconf hardware juno/juno-dma.cfg
11 kconf hardware juno/juno-drm.cfg
12 kconf hardware juno/juno-fb.cfg
13 kconf hardware juno/juno-i2c.cfg
14 # kconf hardware juno/juno-mali-midgard.cfg
15 kconf hardware juno/juno-mmc.cfg
16 kconf hardware juno/juno-net.cfg
17 kconf hardware juno/juno-pci.cfg
[all …]
|
| H A D | fvp.scc | 6 kconf hardware fvp/fvp-board.cfg
7 kconf hardware fvp/fvp-net.cfg
8 kconf hardware fvp/fvp-rtc.cfg
9 kconf hardware fvp/fvp-serial.cfg
10 kconf hardware fvp/fvp-cfi.cfg
11 kconf hardware fvp/fvp-drm.cfg
12 kconf hardware fvp/fvp-watchdog.cfg
|
| /openbmc/linux/Documentation/devicetree/bindings/leds/ |
| H A D | leds-bcm6328.yaml | 14 In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
18 Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml), or by hardware
20 Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and
21 exporting the 74x164 as spi-gpio prevents those LEDs to be hardware
25 should be controlled by a hardware signal instead of the MODE register value,
26 with 0 meaning hardware control enabled and 1 hardware control disabled. This
27 is usually 1:1 for hardware to LED signals, but through the activity/link
29 explained later in brcm,link-signal-sources). Even if a LED is hardware
31 but you can't turn it off if the hardware decides to light it up. For this
32 reason, hardware controlled LEDs aren't registered as LED class devices.
[all …]
|
| /openbmc/linux/drivers/hwmon/pmbus/ |
| H A D | Kconfig | 21 If you say yes here you get hardware monitoring support for generic
33 If you say yes here you get hardware monitoring support for the ACBEL
44 If you say yes here you get hardware monitoring support for Analog
53 If you say yes here you get hardware monitoring support for Analog
63 If you say yes here you get hardware monitoring support for BEL
72 If you say yes here you get hardware monitoring support for BluTek
81 If you say yes here you get hardware monitoring support for the Intel
90 If you say yes here you get hardware monitoring support for
100 If you say yes here you get hardware monitoring support for
111 If you say yes here you get hardware monitorin
[all...] |
| /openbmc/u-boot/include/ |
| H A D | hwspinlock.h | 11 * Hardware spinlocks are used to perform hardware protection of
18 * struct hwspinlock - A handle to (allowing control of) a single hardware
21 * @dev: The device which implements the hardware spinlock.
22 * @id: The hardware spinlock ID within the provider.
32 * hwspinlock_get_by_index - Get a hardware spinlock by integer index
34 * This looks up and request a hardware spinlock. The index is relative to the
35 * client device; each device is assumed to have n hardware spinlock associated
39 * @index: The index of the hardware spinlock to request, within the
40 * client's list of hardware spinlock.
41 * @hws: A pointer to a hardware spinlock struct to initialize.
[all …]
|
| /openbmc/linux/tools/testing/selftests/powerpc/pmu/event_code_tests/ |
| H A D | hw_cache_event_type_test.c | 17 * Hardware cache level : PERF_COUNT_HW_CACHE_L1D
18 * Hardware cache event operation type : PERF_COUNT_HW_CACHE_OP_READ
19 * Hardware cache event result type : PERF_COUNT_HW_CACHE_RESULT_MISS
23 * Hardware cache level : PERF_COUNT_HW_CACHE_L1D
24 * Hardware cache event operation type : PERF_COUNT_HW_CACHE_OP_WRITE
25 * Hardware cache event result type : PERF_COUNT_HW_CACHE_RESULT_ACCESS
29 * Hardware cache level : PERF_COUNT_HW_CACHE_DTLB
30 * Hardware cache event operation type : PERF_COUNT_HW_CACHE_OP_WRITE
31 * Hardware cache event result type : PERF_COUNT_HW_CACHE_RESULT_ACCESS
35 * Hardware cache level : PERF_COUNT_HW_CACHE_L1D
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/HardwareIsolation/ |
| H A D | Entry.interface.yaml | 2 Implement to provide the isolated hardware entry attributes.
6 example, isolated hardware inventory path and error log if it caused to
7 isolate hardware. The isolated hardware association of forward and reverse
14 isolated hardware object.
17 xyz.openbmc_project.Time.EpochTime for the isolated hardware creation time.
23 The severity of hardware isolation.
28 The isolated hardware resolution status is used to indicate whether
29 the isolated hardware is repaired or replaced. Setting this to "true"
31 isolated hardware entries may not be deleted and used for further
37 Possible severity for hardware isolation.
[all …]
|
| H A D | Create.interface.yaml | 4 the information of isolated hardware.
10 the hardware, needs to be isolated. This interface can be used if want
11 to isolate hardware without an error log, for example, the user
12 voluntarily tried to isolate hardware.
17 The hardware inventory path which is needs to isolate.
21 The severity of hardware isolation.
38 the hardware, needs to be isolated. This interface can be used if the
39 system wants to isolate hardware with an error log that is caused to
40 isolate hardware. This method is not going to create an error log and
47 The hardware inventory path which is needs to isolate.
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/spi/ |
| H A D | sprd,spi-adi.yaml | 17 framework for its hardware implementation is alike to SPI bus and its timing
21 48 hardware channels to access analog chip. For 2 software read/write channels,
22 users should set ADI registers to access analog chip. For hardware channels,
23 we can configure them to allow other hardware components to use it independently,
24 which means we can just link one analog chip address to one hardware channel,
25 then users can access the mapped analog chip address by this hardware channel
26 triggered by hardware components instead of ADI software channels.
28 Thus we introduce one property named "sprd,hw-channels" to configure hardware
29 channels, the first value specifies the hardware channel id which is used to
30 transfer data triggered by hardware automatically, and the second value specifies
[all …]
|
| /openbmc/docs/designs/ |
| H A D | error-log-handling-for-phal.md | 1 # Error handling for power Hardware Abstraction Layer (pHAL)
12 power Hardware Abstraction Layer(pHAL) library calls to [Platform Event Log][1]
17 OpenBmc Applications use the pHAL layer for hardware access and hardware
18 initialization, any software/hardware error returned by the pHAL layer need to
24 refers to the action of "guarding" faulty hardware from impacting future system
25 operation. Callout points to a specific hardware with in the server that relates
35 3. libekb for hardware procedure execution
36 4. libpdbg for hardware access
44 pHAL: power Hardware Abstraction Layer. pHAL is group of libraries running in
45 BMC. These libraries are used by Open Power specific application for hardware
[all …]
|
| /openbmc/openbmc/meta-ibm/recipes-phosphor/logging/ |
| H A D | phosphor-logging_%.bbappend | 6 SRC_URI:append:p10bmc = " file://com.ibm.Hardware.Chassis.Model.Rainier2U_dev_callouts.json"
7 SRC_URI:append:p10bmc = " file://com.ibm.Hardware.Chassis.Model.Rainier4U_dev_callouts.json"
8 SRC_URI:append:p10bmc = " file://com.ibm.Hardware.Chassis.Model.Everest_dev_callouts.json"
9 SRC_URI:append:p10bmc = " file://com.ibm.Hardware.Chassis.Model.Bonnell_dev_callouts.json"
10 FILES:${PN}:append:p10bmc = " ${datadir}/phosphor-logging/pels/com.ibm.Hardware.Chassis.Model.Raini…
11 FILES:${PN}:append:p10bmc = " ${datadir}/phosphor-logging/pels/com.ibm.Hardware.Chassis.Model.Raini…
12 FILES:${PN}:append:p10bmc = " ${datadir}/phosphor-logging/pels/com.ibm.Hardware.Chassis.Model.Evere…
13 FILES:${PN}:append:p10bmc = " ${datadir}/phosphor-logging/pels/com.ibm.Hardware.Chassis.Model.Bonne…
21 …44 ${UNPACKDIR}/com.ibm.Hardware.Chassis.Model.Rainier2U_dev_callouts.json ${D}/${datadir}/phospho…
22 …44 ${UNPACKDIR}/com.ibm.Hardware.Chassis.Model.Rainier4U_dev_callouts.json ${D}/${datadir}/phospho…
[all …]
|
| /openbmc/linux/drivers/hwspinlock/ |
| H A D | Kconfig | 7 bool "Hardware Spinlock drivers"
12 tristate "OMAP Hardware Spinlock device"
15 Say y here to support the OMAP Hardware Spinlock device (firstly
21 tristate "Qualcomm Hardware Spinlock device"
25 Say y here to support the Qualcomm Hardware Mutex functionality, which
32 tristate "SPRD Hardware Spinlock device"
35 Say y here to support the SPRD Hardware Spinlock device.
40 tristate "STM32 Hardware Spinlock device"
43 Say y here to support the STM32 Hardware Spinlock device.
48 tristate "SUN6I Hardware Spinlock device"
[all …]
|
| /openbmc/linux/drivers/char/hw_random/ |
| H A D | Kconfig | 3 # Hardware Random Number Generator (RNG) configuration
7 tristate "Hardware Random Number Generator Core support"
10 Hardware Random Number Generator Core infrastructure.
15 of possibly several hardware random number generators.
17 These hardware random number generators do feed into the
44 Generator hardware found on Intel i8xx-based motherboards.
58 Generator hardware found on AMD 76x-based motherboards.
71 Generator hardware found on Atmel AT91 devices.
83 Generator hardware based on Silex Insight BA431 IP.
95 Generator hardware found on the Broadcom BCM2835 and BCM63xx SoCs.
[all …]
|
| /openbmc/linux/Documentation/userspace-api/media/ |
| H A D | glossary.rst | 18 media hardware.
29 Part of the Linux Kernel that implements support for a hardware
39 An API designed to control a subset of the :term:`Media Hardware`
58 Hardware Component
59 A subset of the :term:`Media Hardware`. For example an :term:`I²C` or
63 Hardware Peripheral
64 A group of :term:`hardware components <Hardware Component>` that
67 and the external camera sensors together make a camera hardware
76 serial computer bus used to control some hardware components
77 like sub-device hardware components.
[all …]
|
| /openbmc/linux/tools/testing/selftests/net/forwarding/ |
| H A D | fib_offload_lib.sh | 69 check_err $? "Route not in hardware when should"
73 check_err $? "Appended route in hardware when should not"
77 check_err $? "Prepended route not in hardware when should"
80 check_err $? "Route was not replaced in hardware by prepended one"
100 check_err $? "Route not in hardware when should"
104 check_err $? "Highest TOS route not in hardware when should"
107 check_err $? "Lowest TOS route still in hardware when should not"
111 check_err $? "Middle TOS route in hardware when should not"
129 check_err $? "Route not in hardware when should"
133 check_err $? "Lowest metric route not in hardware when should"
[all …]
|
| /openbmc/linux/Documentation/process/ |
| H A D | embargoed-hardware-issues.rst | 3 Embargoed hardware issues
9 Hardware issues which result in security problems are a different category
13 Hardware issues like Meltdown, Spectre, L1TF etc. must be treated
16 hardware vendors and other parties. For some of the issues, software
25 The Linux kernel hardware security team is separate from the regular Linux
28 The team only handles developing fixes for embargoed hardware security
34 The team can be contacted by email at <hardware-security@kernel.org>. This
43 - PGP: https://www.kernel.org/static/files/hardware-security.asc
44 - S/MIME: https://www.kernel.org/static/files/hardware-security.crt
46 While hardware security issues are often handled by the affected hardware
[all …]
|
| /openbmc/u-boot/drivers/hwspinlock/ |
| H A D | Kconfig | 1 menu "Hardware Spinlock Support"
4 bool "Enable U-Boot hardware spinlock support"
6 This option enables U-Boot hardware spinlock support
9 bool "Enable Hardware Spinlock support for Sandbox"
12 Enable hardware spinlock support in Sandbox. This is a dummy device that
17 bool "Enable Hardware Spinlock support for STM32"
20 Enable hardware spinlock support in STM32MP. Hardware spinlocks are
21 hardware mutex which provide a synchronisation mechanism for the
|
| /openbmc/linux/tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/ |
| H A D | cache.json | 45 …"PublicDescription": "This event counts L1D_CACHE_REFILL caused by software or hardware prefetch.",
48 … "BriefDescription": "This event counts L1D_CACHE_REFILL caused by software or hardware prefetch."
51 …"PublicDescription": "This event counts L2D_CACHE_REFILL caused by software or hardware prefetch.",
54 … "BriefDescription": "This event counts L2D_CACHE_REFILL caused by software or hardware prefetch."
63 "PublicDescription": "This event counts L1D_CACHE_REFILL caused by hardware prefetch.",
66 "BriefDescription": "This event counts L1D_CACHE_REFILL caused by hardware prefetch."
87 "PublicDescription": "This event counts L2D_CACHE_REFILL caused by hardware prefetch.",
90 "BriefDescription": "This event counts L2D_CACHE_REFILL caused by hardware prefetch."
105 …ns where demand access hits an L2 cache refill buffer allocated by software or hardware prefetch.",
108 …ons where demand access hits an L2 cache refill buffer allocated by software or hardware prefetch."
[all …]
|
| /openbmc/openbmc/poky/documentation/kernel-dev/ |
| H A D | concepts-appx.rst | 35 needs for targeted hardware.
337 Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase
354 warnings, the system only reports missing "hardware" options as they
355 could result in a boot failure or indicate that important hardware is
358 To determine whether or not a given option is "hardware" or
359 "non-hardware", the kernel Metadata in ``yocto-kernel-cache`` contains
360 files that classify individual or groups of options as either hardware
361 or non-hardware. To better show this, consider a situation where the
364 yocto-kernel-cache/features/drm-psb/hardware.cfg
365 yocto-kernel-cache/features/kgdb/hardware.cfg
[all …]
|
| /openbmc/linux/Documentation/networking/devlink/ |
| H A D | devlink-dpipe.rst | 10 While performing the hardware offloading process, much of the hardware
16 Linux kernel may differ from the hardware implementation. The pipeline debug
20 The hardware offload process is expected to be done in a way that the user
21 should not be able to distinguish between the hardware vs. software
22 implementation. In this process, hardware specifics are neglected. In
28 differences in the hardware and software models some processes cannot be
32 greatly to the hardware implementation. The configuration API is the same,
34 Level Path Compression trie (LPC-trie) in hardware.
38 information about the underlying hardware, this debugging can be made
45 The ``devlink-dpipe`` interface closes this gap. The hardware's pipeline is
[all …]
|
| /openbmc/linux/Documentation/driver-api/usb/ |
| H A D | gadget.rst | 22 they're easy to port to new hardware.
36 - Minimalist, so it's easier to support new device controller hardware.
41 USB ``host`` hardware in a PC, workstation, or server. Linux users with
42 embedded systems are more likely to have USB peripheral hardware. To
43 distinguish drivers running inside such hardware from the more familiar
58 necessarily different (one side is a hardware-neutral master, the other
59 is a hardware-aware slave), the endpoint I/0 API used here should also
69 hardware).
75 to hardware, through registers, fifos, dma, irqs, and the like. The
77 endpoint hardware. That hardware is exposed through endpoint
[all …]
|
| /openbmc/openbmc-test-automation/gui/test/server_health/ |
| H A D | test_obmc_gui_hardware_status.robot | 3 Documentation Test OpenBMC GUI "Hardware status" sub-menu of "Server health".
27 [Documentation] Verify ability to select "Hardware status" sub-menu option
31 Wait Until Page Contains Hardware status
32 Page should contain All hardware in the system
36 [Documentation] Verify ability to export inventory from "Hardware status"
45 [Documentation] Verify search text input allowed from "Hardware status"
57 [Documentation] Verify search text allowed to clear from "Hardware status"
70 ... "Hardware status" sub-menu.
72 [Template] Verify Hardware Inventory Expand
90 Verify Hardware Inventory Expand
[all …]
|
| /openbmc/linux/crypto/ |
| H A D | crypto_engine.c | 3 * Handle async block request by crypto hardware engine.
36 * @engine: the hardware engine
46 * If hardware cannot enqueue more requests in crypto_finalize_request()
66 * @engine: the hardware engine
70 * needs processing and if so call out to the driver to initialize hardware
113 dev_err(engine->dev, "failed to unprepare crypt hardware\n"); in crypto_pump_requests()
128 * If hardware doesn't support the retry mechanism, in crypto_pump_requests()
146 dev_err(engine->dev, "failed to prepare crypt hardware\n"); in crypto_pump_requests()
163 /* Request unsuccessfully executed by hardware */ in crypto_pump_requests()
166 * If hardware queue is full (-ENOSPC), requeue request in crypto_pump_requests()
[all …]
|
| /openbmc/linux/drivers/acpi/apei/ |
| H A D | Kconfig | 21 bool "APEI Generic Hardware Error Source"
27 Generic Hardware Error Source provides a way to report
28 platform hardware errors (such as that from chipset). It
29 works in so called "Firmware First" mode, that is, hardware
31 Linux by firmware. This way, some non-standard hardware
32 error registers or non-standard hardware link can be checked
33 by firmware to produce more valuable hardware error
59 EINJ provides a hardware error injection mechanism, it is
67 ERST is a way provided by APEI to save and retrieve hardware
|
| /openbmc/linux/Documentation/driver-api/media/ |
| H A D | cec-core.rst | 7 hardware. It is designed to handle a multiple types of hardware (receivers,
35 The struct cec_adapter represents the CEC adapter hardware. It is created by
61 capabilities of the hardware and which parts are to be handled
128 hardware. They are all called with the mutex adap->lock held.
131 To enable/disable the hardware::
135 This callback enables or disables the CEC hardware. Enabling the CEC hardware
139 hardware is enabled. CEC drivers should not set CEC_CAP_NEEDS_HPD unless
140 the hardware design requires that as this will make it impossible to wake
152 that are not for us. Not all hardware supports this and this function is only
154 (some hardware may always be in 'monitor all' mode).
[all …]
|