x86-power-control - slot AC cycle

[Ed Tanous]

On Tue, Jul 28, 2020 at 10:11 AM Velumani T-ERS,HCLTech
<velumanit at hcl.com> wrote:
>
>
> We are using a x86-power-control for host power control in a multi host system. We have the host as FRU and it can be plugged in to a slot. The slot has an option to control slot power and this can be used for a AC cycle.
>
> We propose to add the slot power control in the x86-power-control, The slot power control can be configured in json and the same can be implemented reading the json config. We can ensure the existing functionality remains unchnged and does not affect the other platforms.
>
>
>
> The config file can have a gpio entry with the new key “Slot_Power”. Only if this entry is present then the slot power will be handled, Otherwise the existing functionality remains the same. Please provide your comments/suggestions for this proposed approach.

One amendment, if you're setting this up for a single chassis type,
please make this a compile time structure rather than a config file
read from disk.  It's much easier to manage in the long run, as it
pushes runtime errors to compile time, and means that we're less
likely to break it.  Also, it sends a clear message that we shouldn't
be changing the configuration at runtime.

If you're using something like entity-manager, and you do want to
support more than one chassis, you probably want to define some kind
of "backplane" entity that owns the power configuration, so you can
have multiple slot definitions configured at runtime in the same
build, which might not be a problem for your system, but can be a
problem for systems with multiple Chassis options.

Ideally you would also add a new "node" slot definition type, similar
to how we define M.2 slots and PCIe slots to make debugging easier.


>
> ::DISCLAIMER::
> ________________________________
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.


Sending "this email is confidential" to a public mailing list makes me
think i got it in error.  I'm also not a "named recipient". You might
want to consider removing it in the future, unless you really
considered this to be confidential.