Lines Matching +full:entity +full:- +full:manager
11 …om/openbmc/docs/blob/46902afd6ebd20d1148379df99fe2c0c591f56ba/designs/gpio-based-cable-presence.md)
26 and focuses on IPMI use-case.
28 …om/openbmc/docs/blob/879601d92becfa1dbc082f487abfb5e0151a5091/designs/gpio-based-cable-presence.md)
31 phosphor-multi-gpio-presence and phosphor-inventory-manager.
34 by phosphor-inventory-manager.
39 Additional item-specific properties are statically declared in the
40 phosphor-inventory-manager configuration.
44 …277cdb37e8062ae298402e9685882acb/meta-ibm/meta-sbp1/recipes-phosphor/gpio/phosphor-gpio-monitor/ph…
46 …-inventory-manager config](https://github.com/openbmc/openbmc/blob/1d438f68277cdb37e8062ae298402e9…
49 phosphor-multi-gpio-presence configuration:
61 and phosphor-inventory-manager configuration:
64 - name: Add DIMMs
69 - name: createObjects
96 - Support the gpio based detection of inventory items without static
99 - Allow configuration of the detectable inventory items through entity-manager
101 - e.g. cable
102 - e.g. fan board
103 - e.g. daughter board
104 - entity-manager should expose all required Inventory interfaces
105 - the properties for these inventory interfaces can be obtained through the
108 - When a device is detected as present using the GPIO configuration published by
109 entity-manager, its probe match data is published to D-Bus, which triggers
110 entity-manager to publish the associated configuration.
112 - Support for re-use of presence information in PROBE statements
113 - detecting one entity as 'Present' should enable detecting other entities
118 The proposed design is to create a new daemon in the entity-manager repository,
119 which is 'gpio-presence-sensor'.
122 [NVIDIA gpio presence sensor implementation](https://github.com/NVIDIA/dbus-sensors/blob/889abc1c9b…
138 EM ->> EM: PROBE true on <br> xyz.openbmc_project.FruDevice <br> PRODUCT_PRODUCT_NAME=Yosemite V4
139 EM ->> PresenceDaemon: expose Configuration <br> xyz.openbmc_project.Configuration.GPIODeviceDetect…
142 PresenceDaemon ->> PresenceDaemon: create dbus matcher <br> in case our configuration is removed
146 PresenceDaemon ->> PresenceDaemon: detect Device present <br> via GPIO Event
147 PresenceDaemon ->> EM: expose <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com…
150 EM ->> EM: PROBE true on <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.meta…
151 EM ->> AnyService: expose new Configuration <br> Example: Voltage Sensor
155 AnyService ->> AnyService: Example: <br> expose new Voltage Sensor
156 AnyService ->> AnyService: produce Sensor readings
162 PresenceDaemon ->> PresenceDaemon: detect Device absent <br> via GPIO Event
163 PresenceDaemon ->> EM: remove <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com…
167 EM ->> EM: PROBE false on <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.met…
168 EM ->> AnyService: remove new Configuration <br> Example: Voltage Sensor
170 AnyService ->> AnyService: remove Sensor
176 - EM exposes configuration for 'gpio-presence-sensor'
177 - 'gpio-presence-sensor' creates a dbus matcher to watch for removal of it's
179 - 'gpio-presence-sensor' uses gpios to detect hardware
180 - 'gpio-presence-sensor' creates a dbus interface when it detects hardware
181 - EM can probe new configuration files based on that dbus interface, via PROBE
183 - EM exposes the new configuration for the detected hardware
187 - 'gpio-presence-sensor' detects that the hardware is gone
188 - 'gpio-presence-sensor' takes down the respective dbus interface
189 - EM detects that via dbus matcher
190 - EM removes the configuration for that hardware from dbus
194 - EM exposes configuration for 'gpio-presence-sensor'
195 - 'gpio-presence-sensor' creates a dbus matcher to watch for removal of it's
197 - 'gpio-presence-sensor' uses gpios to detect hardware
198 - 'gpio-presence-sensor' creates a dbus interface when it detects hardware
199 - EM removes the config for 'gpio-presence-sensor'
200 - 'gpio-presence-sensor' takes down any dbus interfaces it created for detecting
202 - EM detects that via dbus matcher
203 - EM removes the configuration for that hardware from dbus
207 'gpio-presence-sensor' should consume configuration via dbus interface
211 entity-manager already creates the needed dbus interfaces here. So there is no
220 - name: Name
223 Used by entity-manager to identify which hardware was detected. For
224 internal use by entity-manager.
225 - name: PresencePinNames
229 - name: PresencePinValues
237 'gpio-presence-sensor' then exposes
246 - name: Name
249 Used by entity-manager to identify which hw was detected. For internal use
250 by entity-manager.
253 entity-manager can then consider the hardware as present and expose the
258 In case the gpio state changes, 'gpio-presence-sensor' can remove the
260 entity-manager can have a dbus matcher for that, to then remove the respective
263 ### Proposed changes in entity-manager
265 entity-manager needs to be extended to handle a new type 'GPIODeviceDetect'
273 "$schema": "http://json-schema.org/draft-07/schema#",
316 "PresencePinNames": ["presence-cable0"],
322 "PresencePinNames": ["presence-slot0a", "presence-slot0b"],
328 "PresencePinNames": ["presence-slot0a", "presence-slot0b"],
334 "PresencePinNames": ["presence-slot0a", "presence-slot0b"],
340 "PresencePinNames": ["presence-fanboard0"],
387 - The existing approach with phosphor-inventory-manager and static configuration
391 - Presence detection integrated into entity-manager. There already exists a
392 presence daemon, and it's an explicit non-goal of EM to implement any presence
396 - Another daemon which would expose inventory items based on EM configuration.
397 This would mean EM does not need to expose the item-specific inventory
400 - Exposing the item-specific interfaces and properties in a generic way. This
402 become more like phosphor-inventory-manager
404 - Preventing duplication in case of multiple instances of e.g. fan
406 could then be used in the the configuration file of the entity. This is
412 - Comparing to Chu Lin's design, this design is not focused on the IPMI or
413 redfish use-case. It is separate from the external interface. It is assumed
415 …[cable dbus interface](https://github.com/openbmc/phosphor-dbus-interfaces/commit/3c5b76491afb8401…
418 - Comparing to Chu Lin's design, this design does not directly provide a cable
422 - Comparing to Chu Lin's design, this design is not limited to cables.
428 - Does this repository require a new repository? No
429 - Who will be the initial maintainer(s) of this repository?
430 - Which repositories are expected to be modified to execute this design?
431 - entity-manager
432 - Make a list, and add listed repository maintainers to the gerrit review.
438 The feature can be tested in the entity-manager repository. We can use
439 dbus-run-session to run an actual entity-manager to provide the configuration or
440 simply provide a hardcoded configuration for 'gpio-presence-sensor'. For the