[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250120152829.7wrnwdji2bnfqrhw@thinkpad>
Date: Mon, 20 Jan 2025 20:58:29 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Johan Hovold <johan@...nel.org>
Cc: Bjorn Helgaas <helgaas@...nel.org>,
Krishna Chaitanya Chundru <quic_krichai@...cinc.com>,
rafael@...nel.org, ulf.hansson@...aro.org,
Kevin Xie <kevin.xie@...rfivetech.com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczyński <kw@...ux.com>,
Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
Markus.Elfring@....de, quic_mrana@...cinc.com,
m.szyprowski@...sung.com, linux-pm@...r.kernel.org,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
regressions@...ts.linux.dev
Subject: Re: [PATCH v7 2/2] PCI: Enable runtime pm of the host bridge
On Mon, Jan 20, 2025 at 11:29:41AM +0100, Johan Hovold wrote:
> On Sun, Jan 19, 2025 at 08:59:40PM +0530, Manivannan Sadhasivam wrote:
> > On Tue, Jan 14, 2025 at 03:16:53PM -0600, Bjorn Helgaas wrote:
> > > On Mon, Jan 13, 2025 at 09:55:49PM +0530, Manivannan Sadhasivam wrote:
> > > > On Tue, Jan 07, 2025 at 03:27:59PM +0100, Johan Hovold wrote:
>
> > > > > > > I just noticed that this change in 6.13-rc1 is causing the
> > > > > > > following warning on resume from suspend on machines like the
> > > > > > > Lenovo ThinkPad X13s:
>
> > > > > > > pci0004:00: pcie4: Enabling runtime PM for inactive device with active children
>
> > > > > > > which may have unpopulated ports (this laptop SKU does not
> > > > > > > have a modem).
>
> > > What's the plan for this? Does anybody have a proposal?
> > >
> >
> > TBH, I don't know how to fix this issue in a proper way. I need inputs from
> > Rafael/Ulf.
> >
> > > IIUC there is no functional issue, but the new warning must be fixed,
> > > and it would sure be nice to do it before v6.13. If there *is* a
> > > functional problem, we need to consider a revert ASAP.
> > >
> >
> > There is no functional problem that I'm aware of, so revert is not warranted.
>
> I'd argue for reverting the offending commit as that is the only way to
> make sure that the new warning is ever addressed.
>
How come reverting becomes the *only* way to address the issue? There seems to
be nothing wrong with the commit in question and the same pattern in being used
in other drivers as well. The issue looks to be in the PM core.
Moreover, the warning is not causing any functional issue as far as I know. So
just reverting the commit that took so much effort to get merged for the sake of
hiding a warning doesn't feel right to me.
> Vendors unfortunately do not a have a good track record of following up
> and fixing issues like this.
>
I'm not relying on vendors here. I am looking into this issue and would like to
fix the warning/issue on my own. That's why I shared my observation with
Ulf/Rafael.
> Judging from a quick look at the code (and the commit message of the
> patch in question), no host controller driver depends on the commit in
> question as the ones that do enable runtime PM just resume
> unconditionally at probe() currently (i.e. effectively ignores the state
> of their children).
>
Right. There are a couple of pieces that needs to be fixed to have the runtime
PM working from top to bottom in the PCIe hierarchy. This is also one more
reason why I believe that the commit wouldn't have caused any functional issue.
- Mani
--
மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists