Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAFJ_xbq0cxcH-cgpXLU4Mjk30+muWyWm1aUZGK7iG53yaLBaQg@mail.gmail.com>
 <20221021111935.GB28729@wunner.de> <CAFJ_xboDuFiACjECO0UmYz5y9TCz4rTRPmrxeVMup7r9816dTg@mail.gmail.com>
 <CAOs-w0KRYh-=gTb0Ed5iYAMs92AYtV_oEei5OgezgKGfwfiBYg@mail.gmail.com>
In-Reply-To: <CAOs-w0KRYh-=gTb0Ed5iYAMs92AYtV_oEei5OgezgKGfwfiBYg@mail.gmail.com>
From:   =?UTF-8?Q?Rados=C5=82aw_Biernacki?= <rad@semihalf.com>
Date:   Fri, 21 Oct 2022 17:40:31 +0200
Message-ID: <CAOs-w0KNvzfT9tSzXUZeoRthMBt1rgDf-arXY6uvkNJpNBrxBQ@mail.gmail.com>
Subject: Re: [BUG] Intel Apollolake: PCIe bridge "loses" capabilities after
 entering D3Cold state
To:     Lukasz Majczak <lma@semihalf.com>, Vidya Sagar <vidyas@nvidia.com>
Cc:     Lukas Wunner <lukas@wunner.de>, bhelgaas@google.com,
        Rajat Jain <rajatja@google.com>, upstream@semihalf.com,
        linux-pci@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

>> pt., 21 pa=C5=BA 2022 o 13:19 Lukas Wunner <lukas@wunner.de> napisa=C5=
=82(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_Subs=
tates+
>> > >   PortCommonModeRestoreTime=3D40us PortTPowerOnTime=3D10us
>> > > L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
>> > >    T_CommonMode=3D40us LTR1.2_Threshold=3D98304ns
>> > > L1SubCtl2: T_PwrOn=3D60us
>> > >
>> > > 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 spa=
ce.
>> > 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

Lukasz, Vidya, is the change in behaviour in V4 intentional fix for
mentioned problems with missing devices after D3cold or unintentional
side effects.
Or from another angle, can we base on this behaviour as a hotfix for
problems with missing devices?

As far as I understand we probably still should update FW in the fleet
of devices, right?

ps: Sorry for top-posting in the previous email, I forgot to switch my
gmail client.