=3D=3D=3D=3D=3D=3D

But something strange is the logs seems from "x86-power-control" package because it would not appe= ar after I commented out partial code as below in the package.

Cou= ld you or others tell me why, please? I mean did I miss any configurations or code changes or anything when usin= g the "x86-power-control" package?

#if 0 //Added by Chris for testing<= /span>

// Request POWER_BUTTON GP= IO events

if (!powerButtonName= .empty())

{

if (!requestGPIOEve= nts(powerButtonName, powerButtonHandler,

&= nbsp; powerButtonLine, powerButton= Event))

{

return -1;

}

else

{

phosphor::logging= ::log<phosphor::logging::leve= l::ERR>(<= /span>

"powerButton name should be configured from json config= file");

return -1;

}

#endif //= Added by Chris for testing

Another, last time I for= got to say that I have tried to use "devmem 0x1e6e24BC 32 0x0F000000&q= uot; to set passthrough back manually and the power button works fine. This= is why I think the passthrough was gone after the system booting up.

Regards,

Chris Chen

=B1H=A5=F3=AA=CC: Andrew Je= ffery <andrew@aj.id.au>
=B1H=A5=F3=A4=E9=B4=C1: 2021=A6~8=A4=EB16=A4=E9 =A4U=A4=C8 02:30
=A6=AC=A5=F3=AA=CC: Chris Chen (TPI) <Chris.Chen3@flex.com>; B= ills, Jason M <jason.m.bills@linux.intel.com>; openbmc@lists.ozlabs.o= rg <openbmc@lists.ozlabs.org>
=A5D=A6=AE: Re: [x86-power-control]: press the power button for a lo= ng time that can't force turn off system power

Hi Chris,

On Mon, 16 Aug 2021, at 13:22, Chris Chen (TPI) wrote:
> Hi Jason and others,
>
> I think I figured out the problem is the GPIOP0 and GPIOP1 passthrough=
> was not set after system booting up. However, as I mentioned when
> rising the question, I have already set GPIOP0 and P1 passthrough in <= br> > u-boot, it for now looks like was been turned off during Kernel or
> OpenBMC application running up. Can you please give me a clue why the =
> GPIO passthrough would be turned off or where should I need to add
> passthrough setting again?
>

If the kernel is disabling it you might be able to find the cause with
CONFIG_DEBUG_PINCTRL=3Dy and the pinctrl attributes in debugfs. Having
said that, the upstream kernel hasn't been taught about SCU510[28] on
the 2600, so if it is touching it then it's doing so via out-of-tree
patches.

Andrew

Legal Disclaimer :
The information contained in this message may be privileged and confidentia= l.
It is intended to be read only by the individual or entity to whom it is ad= dressed
or by their designee. If the reader of this message is not the intended rec= ipient,
you are on notice that any distribution of this message, in any form,
is strictly prohibited. If you have received this message in error,
please immediately notify the sender and delete or destroy any copy of this= message!

--_000_DM6PR08MB551444C4EAB80473CB576740DCFD9DM6PR08MB5514namp_--