[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250821143641.GA672933@bhelgaas>
Date: Thu, 21 Aug 2025 09:36:41 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Hongxing Zhu <hongxing.zhu@....com>
Cc: Frank Li <frank.li@....com>,
"jingoohan1@...il.com" <jingoohan1@...il.com>,
"l.stach@...gutronix.de" <l.stach@...gutronix.de>,
"lpieralisi@...nel.org" <lpieralisi@...nel.org>,
"kwilczynski@...nel.org" <kwilczynski@...nel.org>,
"mani@...nel.org" <mani@...nel.org>,
"robh@...nel.org" <robh@...nel.org>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"festevam@...il.com" <festevam@...il.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND v3 4/5] PCI: dwc: Skip PME_Turn_Off message if there is
no endpoint connected
On Thu, Aug 21, 2025 at 05:44:00AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@...nel.org>
> > Sent: 2025年8月20日 3:07
> > To: Hongxing Zhu <hongxing.zhu@....com>
> > Cc: Frank Li <frank.li@....com>; jingoohan1@...il.com;
> > l.stach@...gutronix.de; lpieralisi@...nel.org; kwilczynski@...nel.org;
> > mani@...nel.org; robh@...nel.org; bhelgaas@...gle.com;
> > shawnguo@...nel.org; s.hauer@...gutronix.de; kernel@...gutronix.de;
> > festevam@...il.com; linux-pci@...r.kernel.org;
> > linux-arm-kernel@...ts.infradead.org; imx@...ts.linux.dev;
> > linux-kernel@...r.kernel.org
> > Subject: Re: [RESEND v3 4/5] PCI: dwc: Skip PME_Turn_Off message if there is
> > no endpoint connected
> >
> > On Mon, Aug 18, 2025 at 03:32:04PM +0800, Richard Zhu wrote:
> > > Skip PME_Turn_Off message if there is no endpoint connected.
> >
> > What's the value of doing this? Is this to make something faster? If so,
> > what and by how much?
> >
> > Or does it fix something that's currently broken?
> >
> > Seems like the discussion at
> > https://lore.kern/
> > el.org%2Flinux-pci%2F20241107084455.3623576-1-hongxing.zhu%40nxp.com%
> > 2Ft%2F%23u&data=05%7C02%7Chongxing.zhu%40nxp.com%7Ced46fe10aeb74
> > 21c88a508dddf53a24f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> > C638912272493755203%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> > 3D%3D%7C0%7C%7C%7C&sdata=lIE7%2FlS5jiGxGPGVm5Hr5efpMbT19CLqrwu
> > YNvAEdLY%3D&reserved=0
> > might be relevant.
> >
> > This commit log only restates what the code does. In my opinion we need
> > actual justification for making this change.
> Hi Bjorn:
> Thanks for your comments.
> This commit is mainly used to fix suspend/resume broken on i.MX7D PCIe.
> A chip freeze is observed on i.MX7D when PCIe RC kicks off the PM_PME message
> and no any devices are connected on the port.
>
> Because i.MX7D is a very old design, and out of IP design technical support.
> I don't know what's going on inside the PCIe IP design when kick off the
> PM_PME message.
>
> From SW perspective view, what I can do is to find out a quirk method to
> workaround this broken. Hope this can clear up your confusions.
OK, will look for some of this background in the commit log of the
next version.
Powered by blists - more mailing lists