| /openbmc/linux/Documentation/admin-guide/media/ |
| H A D | dvb-usb-dib0700-cardlist.rst | 29 * - DiBcom NIM7090 reference design
31 * - DiBcom NIM8096MD reference design
33 * - DiBcom NIM9090MD reference design
35 * - DiBcom STK7070P reference design
37 * - DiBcom STK7070PD reference design
39 * - DiBcom STK7700D reference design
41 * - DiBcom STK7700P reference design
43 * - DiBcom STK7770P reference design
45 * - DiBcom STK807xP reference design
47 * - DiBcom STK807xPVR reference design
[all …]
|
| /openbmc/docs/designs/ |
| H A D | design-template.md | 7 - Not all new features need a design document. If a feature can be contributed
9 areas, it doesn't need a design discussion and documentation.
17 design proposals compel the reviewers agree with the proposal's conclusions.
23 - You should get your design reviewed and merged before writing your code.
25 may learn of new requirements during the design review process that could
46 "design"
50 # Example design - this is the design title
74 glossary if necessary. Note: this is background; do not write about your design,
87 ## Proposed Design
98 (2 paragraphs) Include alternate design ideas here which you are leaning away
[all …]
|
| H A D | cper-records.md | 33 design, and passes the OpenBMC CI tests currently. This is the proposed branch
54 ## Proposed Design
56 While this design fits into a much more elaborate design alluded to in the
62 might not meet all design goals for all contributors, having a common
65 Future design docs (or amendments to this design) will iterate on implementing
66 more of the design referenced in this [CPER specification][arm_sbmr], for common
68 the quality up to standards is the initial goal of this design.
72 Rewrite libcper decoding from a new design point. While this is certainly
85 - Which repositories are expected to be modified to execute this design?
100 design is complete.
|
| H A D | README.md | 1 This is a directory of design documents.
3 Newly authored design documents are encouraged to follow the
4 [design document template](design-template.md).
|
| H A D | expired-password.md | 61 This design uses meanings 3 and 4 except where indicated.
87 ## Proposed Design
89 This design has three main parts:
122 session. The ipmitool is not being enhanced by this design.
131 - Redfish: This design adds the Redfish PasswordChangeRequired handling to
152 This design is intended to cover any cause of expired password, including both
156 This design is intended to enable the webui-vue web application to implement a
159 Per the above design, when the web app uses either `/login` or
206 Warning. This design may leave the BMC with its default password for an extended
207 period of time if the use case given in the requirements section of this design
[all …]
|
| H A D | uart-mux-support.md | 1 # uart-mux-support design
19 but it has been determined that this feature needs a design document.
24 The background here is that there are some design choices which may affect other
49 ## Design Considerations
94 With these in mind we end up with the following table of design options:
164 concrete design of the platform itself.
292 API, i.e. with the out-of-band command design point (2.1). However, the choice
293 becomes more of an implementation detail if either of design options 2.2 or 2.3
297 ## Pruning the Design Decision Tree
317 eliminates design options A-D inclusive.
[all …]
|
| H A D | vpd-collection.md | 34 This design document aims to define a high level design for VPD collection and
84 design document and are not covered here.
109 ## Proposed Design
111 This document covers the architectural, interface, and design details. It
115 The proposal here is to build upon the existing VPD collection design used by
192 its own design document.
215 - Design would make the application very specific to a given system or a set of
220 - The design does not leverage upon the layered design approach that the chosen
|
| H A D | estoraged.md | 1 # eStoraged Design - Encrypted Secondary Storage Management Daemon
21 This design is intended to manage secondary storage devices and cannot be used
25 This design makes use of the
33 This design is specifically targeted for use with eMMC devices, and we plan to
52 This design should provide an interface for the following capabilities:
72 The users of this design can be any other software component in the BMC. Some
80 ## Proposed Design
162 organizations, it is outside the scope of this design.
|
| H A D | multihost-ipmi-design.md | 1 # Multi-host IPMI design
13 IPMI commands handling. We have a multi-host system and proposing the design to
62 IPMI commands handling. We have a multi-host system and proposing the design to
65 ## Proposed Design
67 To address issue1 and issue2, we propose the following design changes in
166 to respond each host.The changes looks simple and no major design change from
167 the existing design. But many common handlers will be running as duplicate in
180 There may not be an impact in ipmid command handler functions.This design will
185 The proposed design can be tested in a platform in which the multiple hosts are
|
| /openbmc/u-boot/arch/arm/mach-tegra/tegra20/ |
| H A D | Kconfig | 12 bool "Avionic Design Medcom-Wide board"
20 bool "Avionic Design Plutux board"
28 bool "Avionic Design Tamonten Evaluation Carrier"
49 source "board/avionic-design/medcom-wide/Kconfig"
51 source "board/avionic-design/plutux/Kconfig"
53 source "board/avionic-design/tec/Kconfig"
|
| /openbmc/linux/Documentation/devicetree/bindings/power/supply/ |
| H A D | bq27xxx.yaml | 64 - energy-full-design-microwatt-hours
65 - charge-full-design-microamp-hours
66 - voltage-min-design-microvolt
67 Both or neither of the *-full-design-*-hours properties must be set.
80 voltage-min-design-microvolt = <3200000>;
81 energy-full-design-microwatt-hours = <5290000>;
82 charge-full-design-microamp-hours = <1430000>;
|
| H A D | battery.yaml | 54 voltage-min-design-microvolt:
57 voltage-max-design-microvolt:
60 energy-full-design-microwatt-hours:
61 description: battery design energy
63 charge-full-design-microamp-hours:
64 description: battery design capacity
152 voltage-min-design-microvolt = <3200000>;
153 voltage-max-design-microvolt = <4200000>;
154 energy-full-design-microwatt-hours = <5290000>;
155 charge-full-design-microamp-hours = <1430000>;
|
| H A D | ingenic,battery.yaml | 35 - voltage-min-design-microvolt: drained battery voltage,
36 - voltage-max-design-microvolt: fully charged battery voltage.
52 voltage-min-design-microvolt = <3600000>;
53 voltage-max-design-microvolt = <4200000>;
|
| /openbmc/webui-vue/ |
| H A D | CONTRIBUTING.md | 15 - [Design Reviews](#design-reviews)
105 the IBM Design Partner program.
107 ### What is an OpenBMC Design Partner?
112 interviews, participatory design, periodic surveys, or usability testing
120 ## Design Reviews
122 When making changes to an existing design, we create a design review issue in
124 [OpenBMC GUI Design Workgroup](https://github.com/openbmc/openbmc/wiki/GUI-Design-work-group).
|
| /openbmc/docs/designs/mctp/ |
| H A D | mctp.md | 13 This design aims to use the Management Component Transport Protocol (MCTP) to
22 allows us to design these parts separately. Currently, IPMI defines both of
51 This document is focused on the "transport" part of the platform design. While
53 covered in detail much; we will propose those parts in separate design efforts.
54 For example, the PLDM design at [pldm-stack.md].
56 As part of the design, the references to MCTP "messages" and "packets" are
93 Design details for both approaches are covered in their relevant documents, but
125 Design and development needs to involve potential host, management controllers
|
| /openbmc/linux/Documentation/locking/ |
| H A D | index.rst | 11 lockdep-design
14 mutex-design
15 rt-mutex-design
19 ww-mutex-design
|
| /openbmc/entity-manager/configurations/ |
| H A D | VENDORS.md | 7 In some cases a company might design a component (such as a network card),
11 when multiple companies are involved in the chain between design and end-user.
16 1. A company which primarily initiates and oversees the design, manufacture and
29 3. When one company primarily oversees the design but other companies
31 the company that primarily oversaw the design of the component would be the
|
| /openbmc/linux/Documentation/RCU/ |
| H A D | index.rst | 27 Design/Memory-Ordering/Tree-RCU-Memory-Ordering
28 Design/Expedited-Grace-Periods/Expedited-Grace-Periods
29 Design/Requirements/Requirements
30 Design/Data-Structures/Data-Structures
|
| /openbmc/linux/Documentation/translations/zh_CN/locking/ |
| H A D | index.rst | 17 mutex-design
23 * lockdep-design
26 * rt-mutex-design
29 * ww-mutex-design
|
| /openbmc/qemu/include/hw/watchdog/ |
| H A D | cmsdk-apb-watchdog.h | 14 * System Design Kit (CMSDK) and documented in the Cortex-M System
15 * Design Kit Technical Reference Manual (ARM DDI0479C):
16 * https://developer.arm.com/products/system-design/system-design-kits/cortex-m-system-design-kit
|
| /openbmc/qemu/include/hw/timer/ |
| H A D | cmsdk-apb-dualtimer.h | 14 * System Design Kit (CMSDK) and documented in the Cortex-M System
15 * Design Kit Technical Reference Manual (ARM DDI0479C):
16 * https://developer.arm.com/products/system-design/system-design-kits/cortex-m-system-design-kit
|
| /openbmc/webui-vue/.github/ISSUE_TEMPLATE/ |
| H A D | design-review.md | 2 name: Design review
3 about: Create story used to track design proposals and decisions
21 ## Design Review Workflow
23 1. Each design iteration will have a comment section
|
| /openbmc/docs/designs/inventory/ |
| H A D | gpio-based-hardware-inventory.md | 19 gpios. This design focuses on those.
21 Connected entities detectable via other means are out of scope of this design.
25 The existing design for the gpio based cable presence is partially implemented
28 [existing design by Chu Lin](https://github.com/openbmc/docs/blob/879601d92becfa1dbc082f487abfb5e01…
117 ## Proposed Design
119 The proposed design is to create a new daemon in the entity-manager repository,
413 - Comparing to Chu Lin's design, this design is not focused on the IPMI or
417 which was created as part of Chu Lin's design.
419 - Comparing to Chu Lin's design, this design does not directly provide a cable
423 - Comparing to Chu Lin's design, this design is not limited to cables.
[all …]
|
| /openbmc/linux/Documentation/networking/devlink/ |
| H A D | nfp.rst | 35 - Part number identifying the board design
38 - Revision of the board design
41 - Vendor of the board design
44 - Model name of the board design
|
| /openbmc/linux/Documentation/driver-api/driver-model/ |
| H A D | design-patterns.rst | 2 Device Driver Design Patterns
5 This document describes a few common design patterns found in device drivers.
7 conform to these design patterns.
21 The most common way to achieve this is to use the state container design
102 The design pattern is the same for an hrtimer or something similar that will
|