Re: [DISCUSSION] Drive-level power control support in phosphor-state-manager

Hi Andrew,

Thanks for the feedback, responses inline.

On Fri, Apr 10, 2026 at 9:29 PM Andrew Geissler <[email protected]> wrote:
>
> Curious what the protocol looks like to monitor and perform the power
> cycling to these drives from the BMC? Is it something simple like
> GPIO's or is there something like MCTP to them?

The hardware I expect to support initially uses GPIO (toggling a drive
enable pin through an I2C IO expander). That said, the PSM drive
daemon itself would have zero knowledge of the hardware protocol. It
only starts systemd targets. The platform attaches its own services to
those targets via .wants/, so the actual protocol is entirely up to
the platform.

>
> How is this managed externally into the BMC? Is there a Redfish API?

Yes. DMTF already defines a Drive.Reset action in the Drive schema[1].

On the bmcweb side, I plan to submit a patch that adds a Drive.Reset
POST route, mapping the relevant ResetType values to the
State.Drive.Transition enum already defined in
phosphor-dbus-interfaces master (Reboot, HardReboot, Powercycle).

[1] https://github.com/openbmc/bmcweb/blob/33d7d41c71bb9a22725d77d97e41114c50b502c0/redfish-core/schema/dmtf/csdl/Drive_v1.xml#L152

>
> PSM is a wrapper to systemd which starts/stops/monitors specific
> systemd targets associated with the function. So would there still
> be a separate application with the business logic on how to monitor
> and power cycle the drives (like phosphor-power)?

Yes, completely separate. The drive state manager daemon in PSM would only:

1. Expose the xyz.openbmc_project.State.Drive D-Bus interface
   (already defined in phosphor-dbus-interfaces master, change 43155)
2. Map Transition values to systemd targets
3. Monitor JobRemoved signals to update CurrentDriveState

The actual hardware operations would live in platform-provided systemd
services attached to the drive targets.

>
> I don't see a use case for my company for this function currently
> but I'm not opposed to it in PSM if it makes sense. There would
> need to be some synergy though. Does the general idea of monitoring
> and starting systemd targets work for the use cases here?

Yes, drive transitions are discrete start/complete operations, same
semantics as chassis transitions. The systemd target model fits.

Regarding synergy, the drive state manager would directly reuse:
- PSM's D-Bus to transition table to systemd target to JobRemoved to
  state update pattern
- PSM's utils library (subscribeToSystemdSignals, etc.)
- PSM's systemd target naming conventions and dependency mechanism

The State.Drive interface is already defined in
phosphor-dbus-interfaces master. A small follow-up patch to
phosphor-dbus-interfaces would be needed to add the paths metadata [2]
so the daemon can follow the same object path construction pattern as
Host and Chassis.

[2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/a93f3ea1a80a4d02983572f0ceb8b4692e2bd057/yaml/xyz/openbmc_project/State/Chassis.interface.yaml#L95

>
> My preference is keep it targeted on the use case we know unless
> someone has other use cases.

Agreed, I intend to keep it drive-specific. I plan to name the daemon
phosphor-drive-state-manager.

>
> Seems fine.

Thanks.

>
> Feels dependent on your system design. If powering off a chassis
> also powers off the drives, then you can just put the systemd target
> responsible for powering the drives off in the chassis-poweroff
> systemd target.

Agreed, the systemd target dependency mechanism handles this cleanly
at the platform level.

If this direction looks reasonable to you, I would like to start
submitting initial patches to Gerrit for review. I would appreciate
any further guidance.

Best Regards,
Eric Yang