x86-power-control - slot AC cycle

x86-power-control - slot AC cycle

[Velumani T-ERS,HCLTech]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

Hi team,

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.

Regards,
Velu

::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.
________________________________

[-- Attachment #2: Type: text/html, Size: 3924 bytes --]

Re: x86-power-control - slot AC cycle

[Ed Tanous]

On Tue, Jul 28, 2020 at 10:11 AM Velumani T-ERS,HCLTech
<velumanit@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.

RE: 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@tanous.net> 
Sent: Wednesday, July 29, 2020 7:56 AM
To: Velumani T-ERS,HCLTech <velumanit@hcl.com>
Cc: openbmc@lists.ozlabs.org; Jason Bills <jason.m.bills@intel.com>; P. Priyatharshan <PriyatharshanP@hcl.com>; James Feist <james.feist@intel.com>; Kuiying Wang <kuiying.wang@intel.com>; Patrick Williams <patrickw3@fb.com>; Kumar Thangavel <thangavel.k@hcl.com>; Vijay Khemka <vijaykhemka@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@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.

Re: x86-power-control - slot AC cycle

[Bills, Jason M]

On 8/3/2020 9:45 AM, Velumani T-ERS,HCLTech wrote:
> 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.
x86-power-control complies with the Host and Chassis State 
dbus-interfaces, so my main request would be to make sure that this new 
slot AC cycle complies with the dbus-interfaces.

Thanks!
-Jason

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