xref: /openbmc/docs/designs/inventory/gpio-based-hardware-inventory.md (revision abbf7355231fbd9d5231e136780c167f2a89494e)
1*abbf7355SAlexander Hansen# GPIO based hardware inventory
2*abbf7355SAlexander Hansen
3*abbf7355SAlexander HansenAuthor: Alexander Hansen <alexander.hansen@9elements.com>
4*abbf7355SAlexander Hansen
5*abbf7355SAlexander HansenOther contributors: Chu Lin <linchuyuan@google.com> (through their previous
6*abbf7355SAlexander Hansenworks), Amithash Prasad <amithash@meta.com>
7*abbf7355SAlexander Hansen
8*abbf7355SAlexander HansenCreated: August 26, 2024
9*abbf7355SAlexander Hansen
10*abbf7355SAlexander HansenReference:
11*abbf7355SAlexander Hansen[Chu Lin's gpio based cable presence detection](https://github.com/openbmc/docs/blob/46902afd6ebd20d1148379df99fe2c0c591f56ba/designs/gpio-based-cable-presence.md)
12*abbf7355SAlexander Hansen
13*abbf7355SAlexander Hansen## Problem Description
14*abbf7355SAlexander Hansen
15*abbf7355SAlexander HansenDue to increasing complexity of server designs and different configurations of
16*abbf7355SAlexander Hansenthe same system being possible, there is a need for a simple way to detect the
17*abbf7355SAlexander Hansenpresence of cards, cables and other connected entities which may or may not be
18*abbf7355SAlexander Hansenplugged into a system. A subset of these entities support presence detection via
19*abbf7355SAlexander Hansengpios. This design focuses on those.
20*abbf7355SAlexander Hansen
21*abbf7355SAlexander HansenConnected entities detectable via other means are out of scope of this design.
22*abbf7355SAlexander Hansen
23*abbf7355SAlexander Hansen## Background and References
24*abbf7355SAlexander Hansen
25*abbf7355SAlexander HansenThe existing design for the gpio based cable presence is partially implemented
26*abbf7355SAlexander Hansenand focuses on IPMI use-case.
27*abbf7355SAlexander Hansen
28*abbf7355SAlexander Hansen[existing design by Chu Lin](https://github.com/openbmc/docs/blob/879601d92becfa1dbc082f487abfb5e0151a5091/designs/gpio-based-cable-presence.md)
29*abbf7355SAlexander Hansen
30*abbf7355SAlexander HansenCurrently the way to do gpio based presence detection is via
31*abbf7355SAlexander Hansenphosphor-multi-gpio-presence and phosphor-inventory-manager.
32*abbf7355SAlexander Hansen
33*abbf7355SAlexander HansenThe static inventory is declared and the inventory items are exposed at runtime
34*abbf7355SAlexander Hansenby phosphor-inventory-manager.
35*abbf7355SAlexander Hansen
36*abbf7355SAlexander HansenThe presence daemon then toggles the 'Present' property on dbus interface
37*abbf7355SAlexander Hansenxyz.openbmc_project.Inventory.Item.
38*abbf7355SAlexander Hansen
39*abbf7355SAlexander HansenAdditional item-specific properties are statically declared in the
40*abbf7355SAlexander Hansenphosphor-inventory-manager configuration.
41*abbf7355SAlexander Hansen
42*abbf7355SAlexander HansenAn example of how this is currently done:
43*abbf7355SAlexander Hansen
44*abbf7355SAlexander Hansen[presence daemon config](https://github.com/openbmc/openbmc/blob/1d438f68277cdb37e8062ae298402e9685882acb/meta-ibm/meta-sbp1/recipes-phosphor/gpio/phosphor-gpio-monitor/phosphor-multi-gpio-presence.json)
45*abbf7355SAlexander Hansen
46*abbf7355SAlexander Hansen[phosphor-inventory-manager config](https://github.com/openbmc/openbmc/blob/1d438f68277cdb37e8062ae298402e9685882acb/meta-ibm/meta-sbp1/recipes-phosphor/inventory/static-inventory/static-inventory.yaml)
47*abbf7355SAlexander Hansen
48*abbf7355SAlexander HansenIn the example we have inventory item **dimm_c0a1** which has following
49*abbf7355SAlexander Hansenphosphor-multi-gpio-presence configuration:
50*abbf7355SAlexander Hansen
51*abbf7355SAlexander Hansen```json
52*abbf7355SAlexander Hansen{
53*abbf7355SAlexander Hansen  "Name": "DIMM_C0A1",
54*abbf7355SAlexander Hansen  "LineName": "PLUG_DETECT_DIMM_C0A1",
55*abbf7355SAlexander Hansen  "ActiveLow": true,
56*abbf7355SAlexander Hansen  "Bias": "PULL_UP",
57*abbf7355SAlexander Hansen  "Inventory": "/system/chassis/motherboard/dimm_c0a1"
58*abbf7355SAlexander Hansen}
59*abbf7355SAlexander Hansen```
60*abbf7355SAlexander Hansen
61*abbf7355SAlexander Hansenand phosphor-inventory-manager configuration:
62*abbf7355SAlexander Hansen
63*abbf7355SAlexander Hansen```yaml
64*abbf7355SAlexander Hansen- name: Add DIMMs
65*abbf7355SAlexander Hansen  description: >
66*abbf7355SAlexander Hansen    Add the DIMM inventory path.
67*abbf7355SAlexander Hansen  type: startup
68*abbf7355SAlexander Hansen  actions:
69*abbf7355SAlexander Hansen    - name: createObjects
70*abbf7355SAlexander Hansen      objs:
71*abbf7355SAlexander Hansen        /system/chassis/motherboard/dimm_c0a1:
72*abbf7355SAlexander Hansen          xyz.openbmc_project.Inventory.Decorator.Replaceable:
73*abbf7355SAlexander Hansen            FieldReplaceable:
74*abbf7355SAlexander Hansen              value: true
75*abbf7355SAlexander Hansen              type: boolean
76*abbf7355SAlexander Hansen          xyz.openbmc_project.State.Decorator.OperationalStatus:
77*abbf7355SAlexander Hansen            Functional:
78*abbf7355SAlexander Hansen              value: true
79*abbf7355SAlexander Hansen              type: boolean
80*abbf7355SAlexander Hansen          xyz.openbmc_project.Inventory.Item:
81*abbf7355SAlexander Hansen            PrettyName:
82*abbf7355SAlexander Hansen              value: "DIMM C0A1"
83*abbf7355SAlexander Hansen              type: string
84*abbf7355SAlexander Hansen            Present:
85*abbf7355SAlexander Hansen              value: false
86*abbf7355SAlexander Hansen              type: boolean
87*abbf7355SAlexander Hansen          xyz.openbmc_project.Inventory.Item.Dimm:
88*abbf7355SAlexander Hansen          xyz.openbmc_project.Inventory.Decorator.LocationCode:
89*abbf7355SAlexander Hansen            LocationCode:
90*abbf7355SAlexander Hansen              value: "CPU0_DIMM_A1"
91*abbf7355SAlexander Hansen              type: string
92*abbf7355SAlexander Hansen```
93*abbf7355SAlexander Hansen
94*abbf7355SAlexander Hansen## Requirements
95*abbf7355SAlexander Hansen
96*abbf7355SAlexander Hansen- Support the gpio based detection of inventory items without static
97*abbf7355SAlexander Hansen  configuration
98*abbf7355SAlexander Hansen
99*abbf7355SAlexander Hansen- Allow configuration of the detectable inventory items through entity-manager
100*abbf7355SAlexander Hansen  configuration
101*abbf7355SAlexander Hansen
102*abbf7355SAlexander Hansen  - e.g. cable
103*abbf7355SAlexander Hansen  - e.g. fan board
104*abbf7355SAlexander Hansen  - e.g. daughter board
105*abbf7355SAlexander Hansen  - entity-manager should expose all required Inventory interfaces
106*abbf7355SAlexander Hansen  - the properties for these inventory interfaces can be obtained through the
107*abbf7355SAlexander Hansen    exposes record in the json configuration
108*abbf7355SAlexander Hansen
109*abbf7355SAlexander Hansen- When a device is detected as present using the GPIO configuration published by
110*abbf7355SAlexander Hansen  entity-manager, its probe match data is published to D-Bus, which triggers
111*abbf7355SAlexander Hansen  entity-manager to publish the associated configuration.
112*abbf7355SAlexander Hansen
113*abbf7355SAlexander Hansen- Support for re-use of presence information in PROBE statements
114*abbf7355SAlexander Hansen  - detecting one entity as 'Present' should enable detecting other entities
115*abbf7355SAlexander Hansen    based on that info
116*abbf7355SAlexander Hansen
117*abbf7355SAlexander Hansen## Proposed Design
118*abbf7355SAlexander Hansen
119*abbf7355SAlexander HansenThe proposed design is to create a new daemon in the entity-manager repository,
120*abbf7355SAlexander Hansenwhich is 'gpio-presence-sensor'.
121*abbf7355SAlexander Hansen
122*abbf7355SAlexander HansenIt can be inspired by implementations found in downstream forks such as the
123*abbf7355SAlexander Hansen[NVIDIA gpio presence sensor implementation](https://github.com/NVIDIA/dbus-sensors/blob/889abc1c9bfae9395690d1562f3e08453dfa12ba/src/GPIOPresenceSensorMain.cpp)
124*abbf7355SAlexander Hansen
125*abbf7355SAlexander Hansen### Diagram
126*abbf7355SAlexander Hansen
127*abbf7355SAlexander Hansen```mermaid
128*abbf7355SAlexander HansensequenceDiagram
129*abbf7355SAlexander Hansen
130*abbf7355SAlexander Hansenparticipant PresenceDaemon
131*abbf7355SAlexander Hansenparticipant EM
132*abbf7355SAlexander Hansenparticipant AnyService
133*abbf7355SAlexander Hansen
134*abbf7355SAlexander Hansennote over PresenceDaemon: cable0 plug
135*abbf7355SAlexander Hansen
136*abbf7355SAlexander Hansen%% initial base configuration
137*abbf7355SAlexander Hansen
138*abbf7355SAlexander Hansenactivate EM
139*abbf7355SAlexander HansenEM ->> EM: PROBE true on <br> xyz.openbmc_project.FruDevice <br> PRODUCT_PRODUCT_NAME=Yosemite V4
140*abbf7355SAlexander HansenEM ->> PresenceDaemon: expose Configuration <br> xyz.openbmc_project.Configuration.GPIODeviceDetect <br> Name=com.meta.Hardware.Yv4.cable0
141*abbf7355SAlexander Hansendeactivate EM
142*abbf7355SAlexander Hansenactivate PresenceDaemon
143*abbf7355SAlexander HansenPresenceDaemon ->> PresenceDaemon: create dbus matcher <br> in case our configuration is removed
144*abbf7355SAlexander Hansen
145*abbf7355SAlexander Hansen%% start forward flow
146*abbf7355SAlexander Hansen
147*abbf7355SAlexander HansenPresenceDaemon ->> PresenceDaemon: detect Device present <br> via GPIO Event
148*abbf7355SAlexander HansenPresenceDaemon ->> EM: expose <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.meta.Hardware.Yv4.cable0
149*abbf7355SAlexander Hansenactivate EM
150*abbf7355SAlexander Hansendeactivate PresenceDaemon
151*abbf7355SAlexander HansenEM ->> EM: PROBE true on <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.meta.Hardware.Yv4.cable0
152*abbf7355SAlexander HansenEM ->> AnyService: expose new Configuration <br> Example: Voltage Sensor
153*abbf7355SAlexander Hansendeactivate EM
154*abbf7355SAlexander Hansen
155*abbf7355SAlexander Hansenactivate AnyService
156*abbf7355SAlexander HansenAnyService ->> AnyService: Example: <br> expose new Voltage Sensor
157*abbf7355SAlexander HansenAnyService ->> AnyService: produce Sensor readings
158*abbf7355SAlexander Hansen
159*abbf7355SAlexander Hansen%% start reverse flow
160*abbf7355SAlexander Hansennote over PresenceDaemon: cable0 unplug
161*abbf7355SAlexander Hansen
162*abbf7355SAlexander Hansenactivate PresenceDaemon
163*abbf7355SAlexander HansenPresenceDaemon ->> PresenceDaemon: detect Device absent <br> via GPIO Event
164*abbf7355SAlexander HansenPresenceDaemon ->> EM: remove <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.meta.Hardware.Yv4.cable0
165*abbf7355SAlexander Hansendeactivate PresenceDaemon
166*abbf7355SAlexander Hansen
167*abbf7355SAlexander Hansenactivate EM
168*abbf7355SAlexander HansenEM ->> EM: PROBE false on <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.meta.Hardware.Yv4.cable0
169*abbf7355SAlexander HansenEM ->> AnyService: remove new Configuration <br> Example: Voltage Sensor
170*abbf7355SAlexander Hansendeactivate EM
171*abbf7355SAlexander HansenAnyService ->> AnyService: remove Sensor
172*abbf7355SAlexander Hansendeactivate AnyService
173*abbf7355SAlexander Hansen```
174*abbf7355SAlexander Hansen
175*abbf7355SAlexander Hansen### Forward flow summary
176*abbf7355SAlexander Hansen
177*abbf7355SAlexander Hansen- EM exposes configuration for 'gpio-presence-sensor'
178*abbf7355SAlexander Hansen- 'gpio-presence-sensor' creates a dbus matcher to watch for removal of it's
179*abbf7355SAlexander Hansen  configuration
180*abbf7355SAlexander Hansen- 'gpio-presence-sensor' uses gpios to detect hardware
181*abbf7355SAlexander Hansen- 'gpio-presence-sensor' creates a dbus interface when it detects hardware
182*abbf7355SAlexander Hansen- EM can probe new configuration files based on that dbus interface, via PROBE
183*abbf7355SAlexander Hansen  statement
184*abbf7355SAlexander Hansen- EM exposes the new configuration for the detected hardware
185*abbf7355SAlexander Hansen
186*abbf7355SAlexander Hansen### Reverse flow summary
187*abbf7355SAlexander Hansen
188*abbf7355SAlexander Hansen- 'gpio-presence-sensor' detects that the hardware is gone
189*abbf7355SAlexander Hansen- 'gpio-presence-sensor' takes down the respective dbus interface
190*abbf7355SAlexander Hansen- EM detects that via dbus matcher
191*abbf7355SAlexander Hansen- EM removes the configuration for that hardware from dbus
192*abbf7355SAlexander Hansen
193*abbf7355SAlexander Hansen### Reverse flow summary (removal of configuration)
194*abbf7355SAlexander Hansen
195*abbf7355SAlexander Hansen- EM exposes configuration for 'gpio-presence-sensor'
196*abbf7355SAlexander Hansen- 'gpio-presence-sensor' creates a dbus matcher to watch for removal of it's
197*abbf7355SAlexander Hansen  configuration
198*abbf7355SAlexander Hansen- 'gpio-presence-sensor' uses gpios to detect hardware
199*abbf7355SAlexander Hansen- 'gpio-presence-sensor' creates a dbus interface when it detects hardware
200*abbf7355SAlexander Hansen- EM removes the config for 'gpio-presence-sensor'
201*abbf7355SAlexander Hansen- 'gpio-presence-sensor' takes down any dbus interfaces it created for detecting
202*abbf7355SAlexander Hansen  hardware
203*abbf7355SAlexander Hansen- EM detects that via dbus matcher
204*abbf7355SAlexander Hansen- EM removes the configuration for that hardware from dbus
205*abbf7355SAlexander Hansen
206*abbf7355SAlexander Hansen### Proposed DBus Interfaces
207*abbf7355SAlexander Hansen
208*abbf7355SAlexander Hansen'gpio-presence-sensor' should consume configuration via dbus interface
209*abbf7355SAlexander Hansen
210*abbf7355SAlexander Hansen`xyz.openbmc_project.Configuration.GPIODeviceDetect`
211*abbf7355SAlexander Hansen
212*abbf7355SAlexander Hansenentity-manager already creates the needed dbus interfaces here. So there is no
213*abbf7355SAlexander Hansenneed to make something new.
214*abbf7355SAlexander Hansen
215*abbf7355SAlexander HansenBelow is a PDI yaml file to describe the proposed configuration interface:
216*abbf7355SAlexander Hansen
217*abbf7355SAlexander Hansen```yaml
218*abbf7355SAlexander Hansendescription: >
219*abbf7355SAlexander Hansen  Information to enable a daemon to probe hardware based on gpio values
220*abbf7355SAlexander Hansenproperties:
221*abbf7355SAlexander Hansen  - name: Name
222*abbf7355SAlexander Hansen    type: string
223*abbf7355SAlexander Hansen    description: >
224*abbf7355SAlexander Hansen      Used by entity-manager to identify which hardware was detected. For
225*abbf7355SAlexander Hansen      internal use by entity-manager.
226*abbf7355SAlexander Hansen  - name: PresencePinNames
227*abbf7355SAlexander Hansen    type: array[string]
228*abbf7355SAlexander Hansen    description: >
229*abbf7355SAlexander Hansen      Names of the gpio lines.
230*abbf7355SAlexander Hansen  - name: PresencePinValues
231*abbf7355SAlexander Hansen    type: array[uint64]
232*abbf7355SAlexander Hansen    description: >
233*abbf7355SAlexander Hansen      Values of the gpio lines for which the device is considered present.
234*abbf7355SAlexander Hansen      Choosing 'uint64' instead of 'bool' here for compatibility with how EM
235*abbf7355SAlexander Hansen      exposes configuration on dbus.
236*abbf7355SAlexander Hansen```
237*abbf7355SAlexander Hansen
238*abbf7355SAlexander Hansen'gpio-presence-sensor' then exposes
239*abbf7355SAlexander Hansen`xyz.openbmc_project.Inventory.Source.DevicePresence` dbus interface of its own
240*abbf7355SAlexander Hansenif it detects the hardware:
241*abbf7355SAlexander Hansen
242*abbf7355SAlexander Hansen```yaml
243*abbf7355SAlexander Hansendescription: >
244*abbf7355SAlexander Hansen  Information for a daemon to expose if hardware has been detected based on
245*abbf7355SAlexander Hansen  xyz.openbmc_project.Configuration.GPIODeviceDetect interface
246*abbf7355SAlexander Hansenproperties:
247*abbf7355SAlexander Hansen  - name: Name
248*abbf7355SAlexander Hansen    type: string
249*abbf7355SAlexander Hansen    description: >
250*abbf7355SAlexander Hansen      Used by entity-manager to identify which hw was detected. For internal use
251*abbf7355SAlexander Hansen      by entity-manager.
252*abbf7355SAlexander Hansen```
253*abbf7355SAlexander Hansen
254*abbf7355SAlexander Hansenentity-manager can then consider the hardware as present and expose the
255*abbf7355SAlexander Hanseninventory interfaces for it.
256*abbf7355SAlexander Hansen
257*abbf7355SAlexander Hansen### Handling removal of the device
258*abbf7355SAlexander Hansen
259*abbf7355SAlexander HansenIn case the gpio state changes, 'gpio-presence-sensor' can remove the
260*abbf7355SAlexander Hansen`xyz.openbmc_project.Inventory.Source.DevicePresence` interface and
261*abbf7355SAlexander Hansenentity-manager can have a dbus matcher for that, to then remove the respective
262*abbf7355SAlexander Hanseninventory items and any inventory items detected below it aswell.
263*abbf7355SAlexander Hansen
264*abbf7355SAlexander Hansen### Proposed changes in entity-manager
265*abbf7355SAlexander Hansen
266*abbf7355SAlexander Hansenentity-manager needs to be extended to handle a new type 'GPIODeviceDetect'
267*abbf7355SAlexander HansenExposes record. It needs to then create the
268*abbf7355SAlexander Hansen`xyz.openbmc_project.Configuration.GPIODeviceDetect` dbus interface.
269*abbf7355SAlexander Hansen
270*abbf7355SAlexander Hansen#### Proposed EM Configuration Schema
271*abbf7355SAlexander Hansen
272*abbf7355SAlexander Hansen```json
273*abbf7355SAlexander Hansen{
274*abbf7355SAlexander Hansen  "$schema": "http://json-schema.org/draft-07/schema#",
275*abbf7355SAlexander Hansen  "$defs": {
276*abbf7355SAlexander Hansen    "GPIODeviceDetect": {
277*abbf7355SAlexander Hansen      "type": "object",
278*abbf7355SAlexander Hansen      "properties": {
279*abbf7355SAlexander Hansen        "Name": {
280*abbf7355SAlexander Hansen          "type": "string"
281*abbf7355SAlexander Hansen        },
282*abbf7355SAlexander Hansen        "Type": {
283*abbf7355SAlexander Hansen          "type": "string"
284*abbf7355SAlexander Hansen        },
285*abbf7355SAlexander Hansen        "PresencePinNames": {
286*abbf7355SAlexander Hansen          "type": "array",
287*abbf7355SAlexander Hansen          "items": {
288*abbf7355SAlexander Hansen            "type": "string"
289*abbf7355SAlexander Hansen          }
290*abbf7355SAlexander Hansen        },
291*abbf7355SAlexander Hansen        "PresencePinValues": {
292*abbf7355SAlexander Hansen          "type": "array",
293*abbf7355SAlexander Hansen          "items": {
294*abbf7355SAlexander Hansen            "type": "number"
295*abbf7355SAlexander Hansen          }
296*abbf7355SAlexander Hansen        }
297*abbf7355SAlexander Hansen      },
298*abbf7355SAlexander Hansen      "required": ["Name", "Type", "PresencePinNames", "PresencePinValues"]
299*abbf7355SAlexander Hansen    }
300*abbf7355SAlexander Hansen  }
301*abbf7355SAlexander Hansen}
302*abbf7355SAlexander Hansen```
303*abbf7355SAlexander Hansen
304*abbf7355SAlexander Hansen### Example EM Config Fragments
305*abbf7355SAlexander Hansen
306*abbf7355SAlexander HansenBelow is an incomplete example of how such a config could look like.
307*abbf7355SAlexander Hansen
308*abbf7355SAlexander HansenThe new part is the `"Type": "GPIODeviceDetect"` which is conveniently named the
309*abbf7355SAlexander Hansensame as the Dbus interface.
310*abbf7355SAlexander Hansen
311*abbf7355SAlexander Hansen```json
312*abbf7355SAlexander Hansen{
313*abbf7355SAlexander Hansen  Exposes:
314*abbf7355SAlexander Hansen  [
315*abbf7355SAlexander Hansen    {
316*abbf7355SAlexander Hansen      "Name": "com.meta.Hardware.Yv4.cable0",
317*abbf7355SAlexander Hansen      "PresencePinNames": ["presence-cable0"],
318*abbf7355SAlexander Hansen      "PresencePinValues": [1],
319*abbf7355SAlexander Hansen      "Type": "GPIODeviceDetect"
320*abbf7355SAlexander Hansen    },
321*abbf7355SAlexander Hansen    {
322*abbf7355SAlexander Hansen      "Name": "com.meta.Hardware.Yv4.ComputeCard",
323*abbf7355SAlexander Hansen      "PresencePinNames": ["presence-slot0a", "presence-slot0b"],
324*abbf7355SAlexander Hansen      "PresencePinValues": [0, 1],
325*abbf7355SAlexander Hansen      "Type": "GPIODeviceDetect"
326*abbf7355SAlexander Hansen    },
327*abbf7355SAlexander Hansen    {
328*abbf7355SAlexander Hansen      "Name": "com.meta.Hardware.Yv4.SidecarExpansion",
329*abbf7355SAlexander Hansen      "PresencePinNames": ["presence-slot0a", "presence-slot0b"],
330*abbf7355SAlexander Hansen      "PresencePinValues": [1, 0],
331*abbf7355SAlexander Hansen      "Type": "GPIODeviceDetect"
332*abbf7355SAlexander Hansen    },
333*abbf7355SAlexander Hansen    {
334*abbf7355SAlexander Hansen      "Name": "com.meta.Hardware.Yv4.AirBlocker",
335*abbf7355SAlexander Hansen      "PresencePinNames": ["presence-slot0a", "presence-slot0b"],
336*abbf7355SAlexander Hansen      "PresencePinValues": [1, 1],
337*abbf7355SAlexander Hansen      "Type": "GPIODeviceDetect"
338*abbf7355SAlexander Hansen    },
339*abbf7355SAlexander Hansen    {
340*abbf7355SAlexander Hansen      "Name": "com.meta.Hardware.Yv4.fanboard0",
341*abbf7355SAlexander Hansen      "PresencePinNames": ["presence-fanboard0"],
342*abbf7355SAlexander Hansen      "PresencePinValues": [0],
343*abbf7355SAlexander Hansen      "Type": "GPIODeviceDetect"
344*abbf7355SAlexander Hansen    },
345*abbf7355SAlexander Hansen    ...
346*abbf7355SAlexander Hansen  ],
347*abbf7355SAlexander Hansen  ...
348*abbf7355SAlexander Hansen  "Name": "Chassis",
349*abbf7355SAlexander Hansen  "Probe": "xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME': 'MYBOARDPRODUCT*'})",
350*abbf7355SAlexander Hansen  "Type": "Board",
351*abbf7355SAlexander Hansen}
352*abbf7355SAlexander Hansen```
353*abbf7355SAlexander Hansen
354*abbf7355SAlexander HansenAnother configuration can then contain additional records for the newly detected
355*abbf7355SAlexander Hansene.g. fan board.
356*abbf7355SAlexander Hansen
357*abbf7355SAlexander Hansen```json
358*abbf7355SAlexander Hansen{
359*abbf7355SAlexander Hansen  Exposes:
360*abbf7355SAlexander Hansen  [
361*abbf7355SAlexander Hansen      {
362*abbf7355SAlexander Hansen        "Address": "0x28",
363*abbf7355SAlexander Hansen        "Bus": 5,
364*abbf7355SAlexander Hansen        "EntityId": 7,
365*abbf7355SAlexander Hansen        "EntityInstance": 0,
366*abbf7355SAlexander Hansen        "Name": "fanboard_air_inlet",
367*abbf7355SAlexander Hansen        "Name1": "fanboard_air_outlet",
368*abbf7355SAlexander Hansen        "Type": "NCT7802"
369*abbf7355SAlexander Hansen    },
370*abbf7355SAlexander Hansen    ...
371*abbf7355SAlexander Hansen  ],
372*abbf7355SAlexander Hansen  ...
373*abbf7355SAlexander Hansen  "Name": "My Fan Board 0",
374*abbf7355SAlexander Hansen  "Probe": "xyz.openbmc_project.Inventory.Source.DevicePresence({'Name': 'com.meta.Hardware.Yv4.fanboard0'})",
375*abbf7355SAlexander Hansen  "Type": "Board",
376*abbf7355SAlexander Hansen}
377*abbf7355SAlexander Hansen```
378*abbf7355SAlexander Hansen
379*abbf7355SAlexander Hansen### Uniqueness of the "Name" property
380*abbf7355SAlexander Hansen
381*abbf7355SAlexander HansenThere is a need to namespace configuration for devices probed via gpios,
382*abbf7355SAlexander Hansenaccording to their vendor or location in the system. "Name" is just a string but
383*abbf7355SAlexander Hansenit can be used to create namespacing with dots. This will prevent accidental
384*abbf7355SAlexander Hansenprobing of unrelated configuration.
385*abbf7355SAlexander Hansen
386*abbf7355SAlexander Hansen## Alternatives Considered
387*abbf7355SAlexander Hansen
388*abbf7355SAlexander Hansen- The existing approach with phosphor-inventory-manager and static configuration
389*abbf7355SAlexander Hansen  Leaning away from that because it cannot support multiple different chassis
390*abbf7355SAlexander Hansen  configurations in one fw image.
391*abbf7355SAlexander Hansen
392*abbf7355SAlexander Hansen- Presence detection integrated into entity-manager. There already exists a
393*abbf7355SAlexander Hansen  presence daemon, and it's an explicit non-goal of EM to implement any presence
394*abbf7355SAlexander Hansen  detection. Maintainers have confirmed that EM should not implement this
395*abbf7355SAlexander Hansen  feature internally.
396*abbf7355SAlexander Hansen
397*abbf7355SAlexander Hansen- Another daemon which would expose inventory items based on EM configuration.
398*abbf7355SAlexander Hansen  This would mean EM does not need to expose the item-specific inventory
399*abbf7355SAlexander Hansen  interfaces and properties.
400*abbf7355SAlexander Hansen
401*abbf7355SAlexander Hansen- Exposing the item-specific interfaces and properties in a generic way. This
402*abbf7355SAlexander Hansen  means EM would lose any semantic knowledge of the entities it exposes and
403*abbf7355SAlexander Hansen  become more like phosphor-inventory-manager
404*abbf7355SAlexander Hansen
405*abbf7355SAlexander Hansen- Preventing duplication in case of multiple instances of e.g. fan
406*abbf7355SAlexander Hansen  board/daughter board/cable through an additional variable besides "Name" that
407*abbf7355SAlexander Hansen  could then be used in the the configuration file of the entity. This is
408*abbf7355SAlexander Hansen  already covered partially by `$index` but `$index` is not stable and depends
409*abbf7355SAlexander Hansen  on order and count of the devices probed successfully. But this feature is
410*abbf7355SAlexander Hansen  left out intentionally here to limit the scope. So multiple instances of a
411*abbf7355SAlexander Hansen  daughter board may need multiple slightly different configuration files.
412*abbf7355SAlexander Hansen
413*abbf7355SAlexander Hansen- Comparing to Chu Lin's design, this design is not focused on the IPMI or
414*abbf7355SAlexander Hansen  redfish use-case. It is separate from the external interface. It is assumed
415*abbf7355SAlexander Hansen  the external interfaces can expose a cable inventory based on the
416*abbf7355SAlexander Hansen  [cable dbus interface](https://github.com/openbmc/phosphor-dbus-interfaces/commit/3c5b76491afb8401627fc343077fe420f8a5e7f9)
417*abbf7355SAlexander Hansen  which was created as part of Chu Lin's design.
418*abbf7355SAlexander Hansen
419*abbf7355SAlexander Hansen- Comparing to Chu Lin's design, this design does not directly provide a cable
420*abbf7355SAlexander Hansen  inventory. So there is another daemon or configuration decorator needed to
421*abbf7355SAlexander Hansen  expose a cable inventory item.
422*abbf7355SAlexander Hansen
423*abbf7355SAlexander Hansen- Comparing to Chu Lin's design, this design is not limited to cables.
424*abbf7355SAlexander Hansen
425*abbf7355SAlexander Hansen## Impacts
426*abbf7355SAlexander Hansen
427*abbf7355SAlexander Hansen### Organizational
428*abbf7355SAlexander Hansen
429*abbf7355SAlexander Hansen- Does this repository require a new repository? No
430*abbf7355SAlexander Hansen- Who will be the initial maintainer(s) of this repository?
431*abbf7355SAlexander Hansen- Which repositories are expected to be modified to execute this design?
432*abbf7355SAlexander Hansen  - entity-manager
433*abbf7355SAlexander Hansen- Make a list, and add listed repository maintainers to the gerrit review.
434*abbf7355SAlexander Hansen
435*abbf7355SAlexander Hansen## Testing
436*abbf7355SAlexander Hansen
437*abbf7355SAlexander HansenHow will this be tested? How will this feature impact CI testing?
438*abbf7355SAlexander Hansen
439*abbf7355SAlexander HansenThe feature can be tested in the entity-manager repository. We can use
440*abbf7355SAlexander Hansendbus-run-session to run an actual entity-manager to provide the configuration or
441*abbf7355SAlexander Hansensimply provide a hardcoded configuration for 'gpio-presence-sensor'. For the
442*abbf7355SAlexander Hansengpio interactions, we can use `CONFIG_GPIO_SIM` or alternatively abstract the
443*abbf7355SAlexander Hansengpio interactions into a separate class which can then be stubbed.
444