<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2026 at 3:50 AM Eric Yang <<a href="mailto:eric.yang.wiwynn@gmail.com">eric.yang.wiwynn@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I've been looking into how OpenBMC currently handles component-level<br>
power control for storage drives, and would appreciate some input on<br>
possible directions.<br>
<br>
On storage servers or compute servers with NVMe/SSD drive bays, there<br>
is a practical need to monitor drive power state and perform controlled<br>
power cycling or reset of individual drives.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The State.Drive interface added in change 43155 [1] defines<br>
RequestedDriveTransition and CurrentDriveState, but I could not find<br>
any upstream consumer for the transition/state properties. Please<br>
correct me if I'm missing an existing implementation.<br></blockquote><div><br></div><div>How is this managed externally into the BMC? Is there a Redfish API?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If a platform wanted to support drive power control through<br>
phosphor-state-manager today, the options would be:<br>
- Map drives as additional chassis/host instances, which carries<br>
incorrect semantics and breaks the Redfish model.<br>
- Write a platform-specific daemon outside of the state-manager<br>
framework.<br>
<br>
phosphor-state-manager already has a well-established per-instance<br>
daemon pattern with systemd target orchestration. Following this<br>
pattern for drives seems like a natural fit.<br></blockquote><div><br></div><div>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)?
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'd appreciate any thoughts on the following:<br>
- Is there interest in drive power control as a first-class feature<br>
in phosphor-state-manager?<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Should it follow the existing host/chassis daemon pattern, or<br>
should it be designed as a more generic component state manager<br>
that could cover other device types in the future?<br></blockquote><div><br></div><div>My preference is keep it targeted on the use case we know unless someone has other use cases.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Drive instances may benefit from string identifiers (e.g. nvme0)<br>
instead of numeric IDs to align with Redfish DriveId. Any concerns<br>
with this approach?<br></blockquote><div><br></div><div>Seems fine.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Should a drive's power state optionally be tied to a specific<br>
host's power state (e.g. power off drives when the associated<br>
host shuts down), or should drive power be fully independent?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1] <a href="https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/43155" rel="noreferrer" target="_blank">https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/43155</a><br>
<br>
Best Regards,<br>
Eric Yang<br>
<br>
</blockquote></div></div>