x86-power-control

Vijay Khemka vijaykhemka at fb.com
Fri Oct 18 09:08:59 AEDT 2019



On 10/17/19, 2:57 AM, "openbmc on behalf of Michael Richardson" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of mcr at sandelman.ca> wrote:

    
    Vijay Khemka <vijaykhemka at fb.com> wrote:
        > 1.  Name of GPIO line, this should be configurable and should also
        > support GPIO number if user doesn’t want to define line name in DTS.
    
    Why in a target system wouldn't naming it in DTS be the most reliable and
    most easily accessible mechanism?  I can see that in development being able to define
    things helps, but it is not like the production systems would have wire-wrap
    where the GPIO pin might change.

I am not ruling out DTS definition but keeping that as optional. Many platform doesn't 
want to change kernel and want to keep dts minimal as well common across multiple
platform. So providing this option will help developer.
    
        > 2.  All delay time as it varies for us per platform like
        > powerPulseTimeMs is 1 sec instead of 200 ms and powerPulseTimeMs is 6
        > sec instead of 15 sec and these varies for different FB platforms.
    
        > 3.  GPIO lines to be monitored, not everyone needs SIO_S5 monitoring or NMI_OUT etc.
        > 4.  Enable/disable passthrough
    
        > Please suggest what is the best way to make these changes. I am ready
        > to work on this to make required change. We can have these config
        > option defined in entity manager or we can accept a new json file for
        > this configuration.
    
    I take it that this isn't a configuration that should be visible to
    operators, just to integrators.
Yes, you are right.
    
    --
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        | network architect  [
    ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
    
    



More information about the openbmc mailing list