linux-kernel - Re: [PATCH] nvme-pci: Use NVME_QUIRK_SIMPLE_SUSPEND for Qualcomm Snapdragon 8cx Gen 3 platforms

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] [day] [month] [year] [list]

Message-ID: <20250207180622.dugcctzfbef7sshw@thinkpad>
Date: Fri, 7 Feb 2025 23:36:22 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: kbusch@...nel.org, axboe@...nel.dk, hch@....de, sagi@...mberg.me,
	linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org,
	andersson@...nel.org, konradybcio@...nel.org, rafael@...nel.org,
	helgaas@...nel.org
Subject: Re: [PATCH] nvme-pci: Use NVME_QUIRK_SIMPLE_SUSPEND for Qualcomm
 Snapdragon 8cx Gen 3 platforms

On Tue, Feb 04, 2025 at 05:03:33PM +0100, Ulf Hansson wrote:
> On Sun, 26 Jan 2025 at 06:03, Manivannan Sadhasivam
> <manivannan.sadhasivam@...aro.org> wrote:
> >
> > On these platforms, power to the PCIe bus is not retained if the SoC enters
> > its own deep low power state called, CX power collapse state during system
> > suspend. Once the SoC resumes after going through CX power collapse, all
> > the PCIe bus state will be lost. So the NVMe devices on these platforms
> > won't resume properly, rendering the machines useless until forcefully
> > restarted by the users.
> >
> > To workaround this issue, the PCIe controller driver is keeping a minimal
> > vote on the PCIe-MEM interconnect path in its system suspend callback
> > current currently. While this gives a working system suspend, it also
> > results in increased power consumption during suspend as the SoC never
> > enters its low power state. So with this change, the workaround can finally
> > be removed.
> >
> > Also it should be noted that the actual fix to this issue lies in the
> > PCI/PM core. But currently there is no such fix exist as of now and the
> > consensus to reach it is also taking a lot of time.
> >
> > So use this quirk to allow users to save battery life on these platforms
> > until the PCI/PM core comes up with an API that tells the PCI client
> > drivers when to turn off the devices.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> 
> FWIW, feel free to add:
> 
> Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>

Thanks!

> 
> > ---
> >
> > Hi,
> >
> > I'm sending this patch as there seems to be no consensus so far (as been
> > discussed in this thread [1]) in coming up with a PCI/PM API that tells the
> > client drivers when to safely turn off the devices. Since coming up with these
> > kind of generic APIs are bound to take time (I do intend to pursue), it makes
> > sense to allow these platforms to make use of the existing
> 
> In whatever form you intend to continue to try to move this forward,
> feel free to keep me in the loop. I am interested and will try to
> provide as much feedback as I possibly can.
> 

Sure, will keep you in the loop.

> I can also keep an eye for a conference where we can bring this up
> again, last time we discussed this was in LPC in Richmond 2023, I
> think. It looks like we have some more data for discussion now, but
> let's see how far we can get on LKML.
> 

Ack.

- Mani

-- 
மணிவண்ணன் சதாசிவம்