x86-power-control - slot AC cycle

[Velumani T-ERS,HCLTech]

Thanks for your suggestions. We plan to implement the slot AC cycle for a single chassis system with 4 slots. We will use the compile time flags and implement this feature.

Regards,
Velu

-----Original Message-----
From: Ed Tanous <ed at tanous.net> 
Sent: Wednesday, July 29, 2020 7:56 AM
To: Velumani T-ERS,HCLTech <velumanit at hcl.com>
Cc: openbmc at lists.ozlabs.org; Jason Bills <jason.m.bills at intel.com>; P. Priyatharshan <PriyatharshanP at hcl.com>; James Feist <james.feist at intel.com>; Kuiying Wang <kuiying.wang at intel.com>; Patrick Williams <patrickw3 at fb.com>; Kumar Thangavel <thangavel.k at hcl.com>; Vijay Khemka <vijaykhemka at fb.com>
Subject: Re: x86-power-control - slot AC cycle

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

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.