linux-kernel - Re: [BUG] Intel Apollolake: PCIe bridge "loses" capabilities after entering D3Cold state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 Oct 2022 14:33:56 +0200
From:   Lukasz Majczak <lma@...ihalf.com>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     bhelgaas@...gle.com, Rajat Jain <rajatja@...gle.com>,
        Vidya Sagar <vidyas@...dia.com>, upstream@...ihalf.com,
        linux-pci@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] Intel Apollolake: PCIe bridge "loses" capabilities after
 entering D3Cold state

pt., 21 paź 2022 o 13:19 Lukas Wunner <lukas@...ner.de> napisał(a):
>
> On Fri, Oct 21, 2022 at 12:17:35PM +0200, Lukasz Majczak wrote:
> > While working with Vidya???s patch I have noticed that after
> > suspend/resume cycle on my Chromebook (Apollolake) PCIe bridge loses
> > its capabilities - the missing part is:
> >
> > Capabilities: [200 v1] L1 PM Substates
> > L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
> >   PortCommonModeRestoreTime=40us PortTPowerOnTime=10us
> > L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
> >    T_CommonMode=40us LTR1.2_Threshold=98304ns
> > L1SubCtl2: T_PwrOn=60us
> >
> > Digging more I???ve found out that entering D3Cold state causes this
>
> You mean the capability is gone from lspci after D3cold?
>
> My understanding is that BIOS is responsible for populating config space.
> So this sounds like a BIOS bug.  What's the BIOS vendor and version?
> (dmesg | grep DMI)
>
> Thanks,
>
> Lukas

Hi Lukasz

here is the DMI

localhost ~ # dmesg | grep DMI
[    0.000000] DMI: Google Coral/Coral, BIOS Google_Coral.10068.81.0 11/27/2018
[    0.155420] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    0.447820] [drm] DMI info: DMI_BIOS_VENDOR coreboot
[    0.447828] [drm] DMI info: DMI_BIOS_VERSION Google_Coral.10068.81.0
[    0.447832] [drm] DMI info: DMI_BIOS_DATE 11/27/2018
[    0.447835] [drm] DMI info: DMI_BIOS_RELEASE 4.0
[    0.447838] [drm] DMI info: DMI_SYS_VENDOR Google
[    0.447841] [drm] DMI info: DMI_PRODUCT_NAME Coral
[    0.447844] [drm] DMI info: DMI_PRODUCT_VERSION rev3
[    0.447848] [drm] DMI info: DMI_PRODUCT_FAMILY Google_Coral

Yes, you are right and in our internal discussion the vendor (Intel)
has proposed a firmware patch, although I couldn't verified that the
issue is limited only to the given firmware/bios, so decided to send
this email.

Best regards,
Lukasz