Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp165993imn; Fri, 29 Jul 2022 03:22:02 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sRW4R9hfV0fCrTl5ncP8ww2pgTf/IKLamoGRWb2dRl8jxb+Dp2wtx7ii76Vl+h4sSYTGmu X-Received: by 2002:a17:907:6d26:b0:72b:3a72:a117 with SMTP id sa38-20020a1709076d2600b0072b3a72a117mr2343764ejc.280.1659090122317; Fri, 29 Jul 2022 03:22:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659090122; cv=none; d=google.com; s=arc-20160816; b=Ja7py1PnMWp1Gq/1Fj5fPXNBNXGyFQoaTZOB32xukb0wZhmccNYqtzJrGYzuRIffVq /92MgEQR9AUgRLEIqwOBLNP0cpOfBqfGMd8RnkbBhL0P3kxsV/IPjCf4pDnOtQe1W//v fUL9Z7hPq6VbNgHpRCOD850OcafW6JJUfemBciMo31mOiUI+3dQBOnB2dBfvvahltpqQ i85mR9rzbpv++7wG0Oi7kfLPO2ujb0ekUuaGzWUeiw7rs1OHDb2WcfDr8wkxHRFhg9Qu wM3ASO8cekzGVzRL0qgPirXfs0j1zmIlm7vO0p+deAQrusV/tvoUO5Jbjocwi3Fem5ka SLig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=CwH/d/sIqHDYK5xsWZYd5yGSd6KgMnTUiTsIbTqcNwY=; b=MwvIPR7bnPcCeBbKi9tFhjrf81ltMHcrvg3E+oNyWoQzo1obyzDkd/enFpxxlVEpJV wZugcDGzpdBx7gee2EFPDL1FotzG0l3wcI1Zrg976uQWLzv6VQOnF0sBP/0kLLpyF7x3 80/mWucdTHjMNQZvnPv0v4Mznfc1evFadfWOLG1+OUZOX4as0eq1Ol45WWFf3i7hAcWC j+UPW+EWnBIHewb06WoiqPJF2D7PFKsrka6lnM3iaBC3Kw+SLWr+UMgxGIDqASVKJYrL kwnhPdO0QgMf+616zot2uLfGNpAechpi48A1FhpHqR9goZkXXtIHrmfk/aEazuEWfplU mLeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@semihalf.com header.s=google header.b=DJBeadA9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=semihalf.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v20-20020a17090690d400b00728ef889ae7si2580351ejw.829.2022.07.29.03.21.35; Fri, 29 Jul 2022 03:22:02 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@semihalf.com header.s=google header.b=DJBeadA9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=semihalf.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235669AbiG2Jjj (ORCPT + 99 others); Fri, 29 Jul 2022 05:39:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235683AbiG2Jjd (ORCPT ); Fri, 29 Jul 2022 05:39:33 -0400 Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9102B85FA2 for ; Fri, 29 Jul 2022 02:39:30 -0700 (PDT) Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-324293f1414so10743847b3.0 for ; Fri, 29 Jul 2022 02:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CwH/d/sIqHDYK5xsWZYd5yGSd6KgMnTUiTsIbTqcNwY=; b=DJBeadA9lQb88BmBHiwZ0rLr/ECqbKiAIoVpPNp8/4KO8eARYXroYH/Sv8p6budTa4 LmFiD8jNxsAFneGBLYVxjYZYUPHJu9+Wb+LM3JEdX2iKSm+JDWxCgwwSMIHWN5rGBIxQ DIhAQ0j1idrcR8M2aVU9hfeYUvxn6jaYsA/pct20LeIX1JbNLpSAGUdwVRRvBhhAzAPK kq8SHCiOl5yzIdC81ky9WckcI4cOccXNazKoMK8jxQAI6OKo216TjrxmKaamXubfz29F iwBy10QB0Z3OSRWl55mSAQ2zlLlhYQRyZAgzBw3En9nO1pRhKVdgTK5fm/RkpJxkJzsY xlcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CwH/d/sIqHDYK5xsWZYd5yGSd6KgMnTUiTsIbTqcNwY=; b=p0fPw0FylUG1x4oZ7Eswhk1OKYB/lb983JuO9FGCcRpzWYENJa8ie8+t5fqASCk/ox XCeX8gunxinqMLoZanpPtaFf1F0POzXENEGtSLAsN90GW36wiYZ6sTxF9a253GguCX1I /Dh465iEqwcjeIzVVmz/idt0qov2sfVi8MOXQGa5rlnOuMka9tDt7QyIlomXO7tY69VM iwpN9JsjztMGgBya8MB+Gps/v2bTSTbO03NEDxj9OKLJ+xaKpbncMVPb3KG91CYJLRBH YLqqauSEB9hVECFzrEmHH8MH0PXKydHv9JzsNcNzbSrhS8BtXZRuKykK7OweLF0M1VfY YtfQ== X-Gm-Message-State: ACgBeo0PcHvexY/LE+BO2UsWg+Xz+Bxsg3pXIjHEa87Tfyu4XD6RBkt5 /jB7pbxR/9QBV+2WBTnu7XR0g/tR6Bah6+NqlBs2hA== X-Received: by 2002:a0d:d085:0:b0:31e:dc35:ef9a with SMTP id s127-20020a0dd085000000b0031edc35ef9amr2427200ywd.453.1659087569643; Fri, 29 Jul 2022 02:39:29 -0700 (PDT) MIME-Version: 1.0 References: <20220722174212.GA1911979@bhelgaas> <86522aa5-2855-0f73-ddb2-a2b50b2fd1b7@nvidia.com> In-Reply-To: From: Lukasz Majczak Date: Fri, 29 Jul 2022 11:39:18 +0200 Message-ID: Subject: Re: [PATCH V2] PCI/ASPM: Save/restore L1SS Capability for suspend/resume To: Rajat Jain Cc: Vidya Sagar , Bjorn Helgaas , Kai-Heng Feng , Ben Chuang , bhelgaas@google.com, lorenzo.pieralisi@arm.com, refactormyself@gmail.com, kw@linux.com, kenny@panix.com, treding@nvidia.com, jonathanh@nvidia.com, abhsahu@nvidia.com, sagupta@nvidia.com, linux-pci@vger.kernel.org, Linux Kernel Mailing List , kthota@nvidia.com, mmaddireddy@nvidia.com, sagar.tv@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org wt., 26 lip 2022 o 09:20 Lukasz Majczak napisa=C5=82(a): > > wt., 26 lip 2022 o 00:51 Rajat Jain napisa=C5=82(a): > > > > Hello, > > > > On Sat, Jul 23, 2022 at 10:03 AM Vidya Sagar wrote: > > > > > > Agree with Bjorn's observations. > > > The fact that the L1SS capability registers themselves disappeared in > > > the root port post resume indicates that there seems to be something > > > wrong with the BIOS itself. > > > Could you please check from that perspective? > > > > ChromeOS Intel platforms use S0ix (suspend-to-idle) for suspend. This > > is a shallower sleep state that preserves more state than, for e.g. S3 > > (suspend-to-RAM). When we use S0ix, then BIOS does not come in picture > > at all. i.e. after the kernel runs its suspend routines, it just puts > > the CPU into S0ix state. So I do not think there is a BIOS angle to > > this. > > > > > > > > > > Thanks, > > > Vidya Sagar > > > > > > > > > On 7/22/2022 11:12 PM, Bjorn Helgaas wrote: > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > On Fri, Jul 22, 2022 at 11:41:14AM +0200, Lukasz Majczak wrote: > > > >> pt., 22 lip 2022 o 09:31 Kai-Heng Feng napisa=C5=82(a): > > > >>> On Fri, Jul 15, 2022 at 6:38 PM Ben Chuang wrote: > > > >>>> On Tue, Jul 5, 2022 at 2:00 PM Vidya Sagar w= rote: > > > >>>>> > > > >>>>> Previously ASPM L1 Substates control registers (CTL1 and CTL2) = weren't > > > >>>>> saved and restored during suspend/resume leading to L1 Substate= s > > > >>>>> configuration being lost post-resume. > > > >>>>> > > > >>>>> Save the L1 Substates control registers so that the configurati= on is > > > >>>>> retained post-resume. > > > >>>>> > > > >>>>> Signed-off-by: Vidya Sagar > > > >>>>> Tested-by: Abhishek Sahu > > > >>>> > > > >>>> Hi Vidya, > > > >>>> > > > >>>> I tested this patch on kernel v5.19-rc6. > > > >>>> The test device is GL9755 card reader controller on Intel i5-102= 10U RVP. > > > >>>> This patch can restore L1SS after suspend/resume. > > > >>>> > > > >>>> The test results are as follows: > > > >>>> > > > >>>> After Boot: > > > >>>> #lspci -d 17a0:9755 -vvv | grep -A5 "L1 PM Substates" > > > >>>> Capabilities: [110 v1] L1 PM Substates > > > >>>> L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ > > > >>>> ASPM_L1.1+ L1_PM_Substates+ > > > >>>> PortCommonModeRestoreTime=3D255us > > > >>>> PortTPowerOnTime=3D3100us > > > >>>> L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+= ASPM_L1.1+ > > > >>>> T_CommonMode=3D0us LTR1.2_Threshold= =3D3145728ns > > > >>>> L1SubCtl2: T_PwrOn=3D3100us > > > >>>> > > > >>>> > > > >>>> After suspend/resume without this patch. > > > >>>> #lspci -d 17a0:9755 -vvv | grep -A5 "L1 PM Substates" > > > >>>> Capabilities: [110 v1] L1 PM Substates > > > >>>> L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ > > > >>>> ASPM_L1.1+ L1_PM_Substates+ > > > >>>> PortCommonModeRestoreTime=3D255us > > > >>>> PortTPowerOnTime=3D3100us > > > >>>> L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2-= ASPM_L1.1- > > > >>>> T_CommonMode=3D0us LTR1.2_Threshold= =3D0ns > > > >>>> L1SubCtl2: T_PwrOn=3D10us > > > >>>> > > > >>>> > > > >>>> After suspend/resume with this patch. > > > >>>> #lspci -d 17a0:9755 -vvv | grep -A5 "L1 PM Substates" > > > >>>> Capabilities: [110 v1] L1 PM Substates > > > >>>> L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ > > > >>>> ASPM_L1.1+ L1_PM_Substates+ > > > >>>> PortCommonModeRestoreTime=3D255us > > > >>>> PortTPowerOnTime=3D3100us > > > >>>> L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+= ASPM_L1.1+ > > > >>>> T_CommonMode=3D0us LTR1.2_Threshold= =3D3145728ns > > > >>>> L1SubCtl2: T_PwrOn=3D3100us > > > >>>> > > > >>>> > > > >>>> Tested-by: Ben Chuang > > > >>> > > > >>> Forgot to add mine: > > > >>> Tested-by: Kai-Heng Feng > > > >>> > > > >>>> > > > >>>> Best regards, > > > >>>> Ben Chuang > > > >>>> > > > >>>> > > > >>>>> --- > > > >>>>> Hi, > > > >>>>> Kenneth R. Crudup , Could you please verify th= is patch > > > >>>>> on your laptop (Dell XPS 13) one last time? > > > >>>>> IMHO, the regression observed on your laptop with an old versio= n of the patch > > > >>>>> could be due to a buggy old version BIOS in the laptop. > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Vidya Sagar > > > >>>>> > > > >>>>> drivers/pci/pci.c | 7 +++++++ > > > >>>>> drivers/pci/pci.h | 4 ++++ > > > >>>>> drivers/pci/pcie/aspm.c | 44 ++++++++++++++++++++++++++++++++= +++++++++ > > > >>>>> 3 files changed, 55 insertions(+) > > > >>>>> > > > >>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > > > >>>>> index cfaf40a540a8..aca05880aaa3 100644 > > > >>>>> --- a/drivers/pci/pci.c > > > >>>>> +++ b/drivers/pci/pci.c > > > >>>>> @@ -1667,6 +1667,7 @@ int pci_save_state(struct pci_dev *dev) > > > >>>>> return i; > > > >>>>> > > > >>>>> pci_save_ltr_state(dev); > > > >>>>> + pci_save_aspm_l1ss_state(dev); > > > >>>>> pci_save_dpc_state(dev); > > > >>>>> pci_save_aer_state(dev); > > > >>>>> pci_save_ptm_state(dev); > > > >>>>> @@ -1773,6 +1774,7 @@ void pci_restore_state(struct pci_dev *de= v) > > > >>>>> * LTR itself (in the PCIe capability). > > > >>>>> */ > > > >>>>> pci_restore_ltr_state(dev); > > > >>>>> + pci_restore_aspm_l1ss_state(dev); > > > >>>>> > > > >>>>> pci_restore_pcie_state(dev); > > > >>>>> pci_restore_pasid_state(dev); > > > >>>>> @@ -3489,6 +3491,11 @@ void pci_allocate_cap_save_buffers(struc= t pci_dev *dev) > > > >>>>> if (error) > > > >>>>> pci_err(dev, "unable to allocate suspend buffe= r for LTR\n"); > > > >>>>> > > > >>>>> + error =3D pci_add_ext_cap_save_buffer(dev, PCI_EXT_CAP_= ID_L1SS, > > > >>>>> + 2 * sizeof(u32)); > > > >>>>> + if (error) > > > >>>>> + pci_err(dev, "unable to allocate suspend buffer= for ASPM-L1SS\n"); > > > >>>>> + > > > >>>>> pci_allocate_vc_save_buffers(dev); > > > >>>>> } > > > >>>>> > > > >>>>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h > > > >>>>> index e10cdec6c56e..92d8c92662a4 100644 > > > >>>>> --- a/drivers/pci/pci.h > > > >>>>> +++ b/drivers/pci/pci.h > > > >>>>> @@ -562,11 +562,15 @@ void pcie_aspm_init_link_state(struct pci= _dev *pdev); > > > >>>>> void pcie_aspm_exit_link_state(struct pci_dev *pdev); > > > >>>>> void pcie_aspm_pm_state_change(struct pci_dev *pdev); > > > >>>>> void pcie_aspm_powersave_config_link(struct pci_dev *pdev); > > > >>>>> +void pci_save_aspm_l1ss_state(struct pci_dev *dev); > > > >>>>> +void pci_restore_aspm_l1ss_state(struct pci_dev *dev); > > > >>>>> #else > > > >>>>> static inline void pcie_aspm_init_link_state(struct pci_dev *= pdev) { } > > > >>>>> static inline void pcie_aspm_exit_link_state(struct pci_dev *= pdev) { } > > > >>>>> static inline void pcie_aspm_pm_state_change(struct pci_dev *= pdev) { } > > > >>>>> static inline void pcie_aspm_powersave_config_link(struct pci= _dev *pdev) { } > > > >>>>> +static inline void pci_save_aspm_l1ss_state(struct pci_dev *de= v) { } > > > >>>>> +static inline void pci_restore_aspm_l1ss_state(struct pci_dev = *dev) { } > > > >>>>> #endif > > > >>>>> > > > >>>>> #ifdef CONFIG_PCIE_ECRC > > > >>>>> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c > > > >>>>> index a96b7424c9bc..2c29fdd20059 100644 > > > >>>>> --- a/drivers/pci/pcie/aspm.c > > > >>>>> +++ b/drivers/pci/pcie/aspm.c > > > >>>>> @@ -726,6 +726,50 @@ static void pcie_config_aspm_l1ss(struct p= cie_link_state *link, u32 state) > > > >>>>> PCI_L1SS_CTL1_L1SS_MASK, val); > > > >>>>> } > > > >>>>> > > > >>>>> +void pci_save_aspm_l1ss_state(struct pci_dev *dev) > > > >>>>> +{ > > > >>>>> + int aspm_l1ss; > > > >>>>> + struct pci_cap_saved_state *save_state; > > > >>>>> + u32 *cap; > > > >>>>> + > > > >>>>> + if (!pci_is_pcie(dev)) > > > >>>>> + return; > > > >>>>> + > > > >>>>> + aspm_l1ss =3D pci_find_ext_capability(dev, PCI_EXT_CAP_= ID_L1SS); > > > >>>>> + if (!aspm_l1ss) > > > >>>>> + return; > > > >>>>> + > > > >>>>> + save_state =3D pci_find_saved_ext_cap(dev, PCI_EXT_CAP_= ID_L1SS); > > > >>>>> + if (!save_state) > > > >>>>> + return; > > > >>>>> + > > > >>>>> + cap =3D (u32 *)&save_state->cap.data[0]; > > > >>>>> + pci_read_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL2, c= ap++); > > > >>>>> + pci_read_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL1, c= ap++); > > > >>>>> +} > > > >>>>> + > > > >>>>> +void pci_restore_aspm_l1ss_state(struct pci_dev *dev) > > > >>>>> +{ > > > >>>>> + int aspm_l1ss; > > > >>>>> + struct pci_cap_saved_state *save_state; > > > >>>>> + u32 *cap; > > > >>>>> + > > > >>>>> + if (!pci_is_pcie(dev)) > > > >>>>> + return; > > > >>>>> + > > > >>>>> + aspm_l1ss =3D pci_find_ext_capability(dev, PCI_EXT_CAP_= ID_L1SS); > > > >>>>> + if (!aspm_l1ss) > > > >>>>> + return; > > > >>>>> + > > > >>>>> + save_state =3D pci_find_saved_ext_cap(dev, PCI_EXT_CAP_= ID_L1SS); > > > >>>>> + if (!save_state) > > > >>>>> + return; > > > >>>>> + > > > >>>>> + cap =3D (u32 *)&save_state->cap.data[0]; > > > >>>>> + pci_write_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL2, = *cap++); > > > >>>>> + pci_write_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL1, = *cap++); > > > >>>>> +} > > > >>>>> + > > > >>>>> static void pcie_config_aspm_dev(struct pci_dev *pdev, u32 va= l) > > > >>>>> { > > > >>>>> pcie_capability_clear_and_set_word(pdev, PCI_EXP_LNKCT= L, > > > >>>>> -- > > > >>>>> 2.17.1 > > > >>>>> > > > >> > > > >> Hi, > > > >> > > > >> With this patch (and also mentioned > > > >> https://lore.kernel.org/all/20220509073639.2048236-1-kai.heng.feng= @canonical.com/) > > > >> applied on 5.10 (chromeos-5.10) I am observing problems after > > > >> suspend/resume with my WiFi card - it looks like whole communicati= on > > > >> via PCI fails. Attaching logs (dmesg, lspci -vvv before suspend/re= sume > > > >> and after) https://gist.github.com/semihalf-majczak-lukasz/fb36dfa= 2eff22911109dfb91ab0fc0e3 > > > >> > > > >> I played a little bit with this code and it looks like the > > > >> pci_write_config_dword() to the PCI_L1SS_CTL1 breaks it (don't kno= w > > > >> why, not a PCI expert). > > > > > > > > Thanks a lot for testing this! I'm not quite sure what to make of = the > > > > results since v5.10 is fairly old (Dec 2020) and I don't know what > > > > other changes are in chromeos-5.10. > > > > Lukasz: I assume you are running this on Atlas and are seeing this bug > > when uprev'ving it to 5.10 kernel. Can you please try it on a newer > > Intel platform that have the latest upstream kernel running already > > and see if this can be reproduced there too? > > Note that the wifi PCI device is different on newer Intel platforms, > > but platform design is similar enough that I suspect we should see > > similar bug on those too. The other option is to try the latest > > ustream kernel on Atlas. Perhaps if we just care about wifi (and > > ignore bringing up the graphics stack and GUI), it may come up > > sufficiently enough to try this patch? > > > > Thanks, > > > > Rajat > > > > > > > > > > > > Random observations, no analysis below. This from your dmesg > > > > certainly looks like PCI reads failing and returning ~0: > > > > > > > > Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff) > > > > iwlwifi 0000:01:00.0: 00000000: ffffffff ffffffff ffffffff fffff= fff ffffffff ffffffff ffffffff ffffffff > > > > iwlwifi 0000:01:00.0: Device gone - attempting removal > > > > Hardware became unavailable upon resume. This could be a softwar= e issue prior to suspend or a hardware issue. > > > > > > > > And then we re-enumerate 01:00.0 and it looks like it may have been > > > > reset (BAR is 0): > > > > > > > > pci 0000:01:00.0: [8086:095a] type 00 class 0x028000 > > > > pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00001fff 64bit] > > > > > > > > lspci diffs from before/after suspend: > > > > > > > > 00:14.0 PCI bridge: Intel Corporation Celeron N3350/Pentium N42= 00/Atom E3900 Series PCI Express Port B #1 (rev fb) (prog-if 00 [Normal dec= ode]) > > > > Bus: primary=3D00, secondary=3D01, subordinate=3D01, sec-late= ncy=3D64 > > > > - DevSta: CorrErr- NonFatalErr+ FatalErr- UnsupReq= + AuxPwr+ TransPend- > > > > + DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq= - AuxPwr+ TransPend- > > > > - LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled-= CommClk+ > > > > + LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- C= ommClk+ > > > > - LnkSta2: Current De-emphasis Level: -6dB, Equali= zationComplete- EqualizationPhase1- > > > > + LnkSta2: Current De-emphasis Level: -3.5dB, Equa= lizationComplete- EqualizationPhase1- > > > > - Capabilities: [150 v0] Null > > > > - Capabilities: [200 v1] L1 PM Substates > > > > - L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ A= SPM_L1.1+ L1_PM_Substates+ > > > > - PortCommonModeRestoreTime=3D40us PortT= PowerOnTime=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 > > > > > > > > The DevSta differences might be BIOS bugs, probably not relevant. > > > > Interesting that ASPM is disabled, maybe didn't get enabled after > > > > re-enumerating 01:00.0? Strange that the L1 PM Substates capabilit= y > > > > disappeared. > > > > > > > > 01:00.0 Network controller: Intel Corporation Wireless 7265 (re= v 59) > > > > LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled-= CommClk+ > > > > - ExtSynch- ClockPM+ AutWidDis- BWInt- Aut= BWInt- > > > > + ExtSynch- ClockPM- AutWidDis- BWInt- Aut= BWInt- > > > > Capabilities: [154 v1] L1 PM Substates > > > > L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ A= SPM_L1.1+ L1_PM_Substates+ > > > > PortCommonModeRestoreTime=3D30us PortT= PowerOnTime=3D60us > > > > - L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ = ASPM_L1.1+ > > > > - T_CommonMode=3D0us LTR1.2_Threshold= =3D98304ns > > > > + L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- = ASPM_L1.1- > > > > + T_CommonMode=3D0us LTR1.2_Threshold= =3D0ns > > > > > > > > Dmesg claimed we reconfigured common clock config. Maybe ASPM didn= 't > > > > get reinitialized after re-enumeration? Looks like we didn't resto= re > > > > L1SubCtl1. > > > > > > > > Bjorn > > > > > > Hi, > > Thank you all for the response and input! As Rajat mentioned I'm using > chromebook - but not Atlas (Amberlake) - in this case it is Babymega > (Apollolake) - I will try to load most recent kernel and give it a > try once again. > > Best regards, > Lukasz Hi, I have applied this patch on top of v5.19-rc7 (chromeos) and I'm still getting same results: https://gist.github.com/semihalf-majczak-lukasz/4b716704c21a3758d6711b2030e= a34b9 Best regards, Lukasz