Re: [PATCH] gpiolib: acpi: Add a ignore wakeup quirk for Clevo NH5xAx

[Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>]

On Mon, Feb 13, 2023 at 11:20:40AM -0700, Raul Rangel wrote:
> On Mon, Feb 13, 2023 at 11:01 AM Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Feb 13, 2023 at 07:59:53PM +0200, Andy Shevchenko wrote:
> > > On Mon, Feb 13, 2023 at 07:57:55PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Feb 13, 2023 at 07:50:02PM +0200, Andy Shevchenko wrote:
> > > > > On Mon, Feb 13, 2023 at 10:20:41AM -0700, Raul Rangel wrote:
> > > > > > On Mon, Feb 13, 2023 at 7:47 AM Werner Sembach <wse@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > > > > Am 13.02.23 um 15:37 schrieb Andy Shevchenko:

...

> > > > > > > Schematics for the NH5xAx can also be found on this unofficial clevo mirror
> > > > > > > (service manuals, scroll to end for schematics):
> > > > > > >
> > > > > > > http://repo.palkeo.com/clevo-mirror/NH5xACx_AFx_ADx/NH50AC.zip
> > > > > > >
> > > > > > > http://repo.palkeo.com/clevo-mirror/NH5xACx_AFx_ADx/NH50AF1.zip
> > > > > > >
> > > > > > > User: repo
> > > > > > >
> > > > > > > PW: repo
> > > > > > >
> > > > > > > >> The schematics were shared by the reporter for the original issue which is
> > > > > > > >> how we reached the conclusion there was a mistake.
> > > > > > > >>
> > > > > > > >> As they're both Clevo designs it's certainly possible they have the same
> > > > > > > >> mistake in two systems.
> > > > > >
> > > > > > > > Thank you!
> > > > > > > > I have looked at the schematics and read discussion.
> > > > > > > >
> > > > > > > > So, the conclusion that this is a BIOS bug is incorrect in my opinion.
> > > > > > > > The problem is either in the PMIC/EC firmware that shouldn't shut down 3.3VS
> > > > > > > > signal for a while or on the PCB level, so that pull up should be connected
> > > > > > > > to another power source that stays on.
> > > > > > > >
> > > > > > > > This means the description on the initial patch with the same issue is
> > > > > > > > incorrect.
> > > > > > > >
> > > > > > > > Do we know the power sequence on the suspend to see which and how on the
> > > > > > > > time line the power sources are off/on?
> > > > > >
> > > > > > If you look at the load switch for 3.3VS, its EN2 pin is connected to
> > > > > > SUSB#_EN which is connected to SUSB# which is connected to
> > > > > > AND(SUSB#_PCH -> SLP_S3_L, PM_SLP_S0 -> S0A3_GPIO). So there is no
> > > > > > PMIC/EC firmware that is incharge of this. I guess I'm not quite sure
> > > > > > how they have S0A3_GPIO configured, so maybe I have an invert wrong.
> > > > > >
> > > > > > The EC does control DD_ON which controls the 3.3V and 5V rails.
> > > > >
> > > > > On page 6 of the schematics I see the U7 that forms SUSB# from SUSB#_APU
> > > > > (which corresponds to what you said) _and_ EC_EN, which is GPIO from IT5570,
> > > > > which is EC.
> > > > >
> > > > > Are you using different schematics? I'm using the one from FDO bug report.
> > > >
> > > > Just checked this one:
> > > > http://repo.palkeo.com/clevo-mirror/NH5xACx_AFx_ADx/NH50AC.zip
> > > >
> > > > Also uses EC (SUSB_EC#).
> >
> > Sorry, this has to be read as SUSBC_EC#.
> 
> It looks like SUSBC_EC# has to stay high during S3/S0i3 otherwise it's
> going to shut down the S5 power domain. So I'm guessing U7 is there to
> prevent the S3 domain from being powered on while the S5 domain is
> powered off.
> 
> Sheet 59 of 73 VDDCR_SOC_S5, VDDCR_ALW seems to have a helpful table
> that describes all the power states. I'm confused where SLP_SUS# comes
> from though. I'm also not sure about S5_MUX_CTRL since that seems to
> be connected to a testpoint.

I see, thanks for looking into this.

So, if EC has no business with this, whose responsibility to assert that
signal? I'm trying to get if it's PCB issue (wrong power rail for pull up)
or something else.

Btw, is anybody can actually boot Windows and check the signals of the pin on a
time line in comparison to Linux to see if the behaviour of them is the same?
(If Windows and Linux got the same timeline of the signals it would mean that
 the issue in the Linux kernel.)

> > > So this all makes me thing that either EC firmware is buggy or we have ACPI EC
> > > code in the kernel to fix.

-- 
With Best Regards,
Andy Shevchenko