Messages in this thread | | | Date | Mon, 4 Apr 2022 09:39:33 -0500 | From | Rob Herring <> | Subject | Re: [PATCH v8 6/8] PCI: dwc: Add dw_pcie_host_ops.host_exit() callback |
| |
On Sat, Apr 02, 2022 at 03:03:00AM +0000, Hongxing Zhu wrote: > > -----Original Message----- > > From: Rob Herring <robh@kernel.org> > > Sent: 2022年4月2日 4:44 > > To: Hongxing Zhu <hongxing.zhu@nxp.com> > > Cc: l.stach@pengutronix.de; bhelgaas@google.com; broonie@kernel.org; > > lorenzo.pieralisi@arm.com; jingoohan1@gmail.com; festevam@gmail.com; > > francesco.dolcini@toradex.com; linux-pci@vger.kernel.org; > > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > > kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com> > > Subject: Re: [PATCH v8 6/8] PCI: dwc: Add dw_pcie_host_ops.host_exit() > > callback > > > > On Fri, Feb 25, 2022 at 11:44:25AM +0800, Richard Zhu wrote: > > > When the link never comes up after ->host_init(), some drivers, > > > especially those that don't support hotplug, want to turn off clocks > > > and power supplies. > > > > Isn't supporting hotplug or not a board level decision? And hotplug doesn't > > have to mean physical plug/unplug. For example, you could have a soldered > > down PCIe device which needs regulators, resets, clocks, etc. > > for that device to be initialized before the link comes up. If that device is > > handled by a module loaded some time later, then the link may be down when > > you probe. > > > > I think the way this all needs to work is with runtime PM. If that's all in place, > > then either you shutdown clocks/power on timeout or via sysfs suspend. If > > there's a child device, then that should prevent suspending. > Hi Rob: > Thanks a lot for your review comments. > Understand what you mean. > i.MX PCIe doesn't support hot-plug from chip design view.
The scenario I described is not hotplug.
> The ops.host_exit() callback is invoked only when the iMX PCIe driver hooked > callback ops->start_link return an error. > For the platforms, that support the hot-plug feature, they can just return one > zero from their own ops->start_link.
You cannot have a per board start_link().
> In the current situation, i.MX PCIe does just return one zero when probe failed. > See the discussion and commit issued by Fabio below. > https://patchwork.kernel.org/project/linux-pci/patch/1641368602-20401-6-git-send-email-hongxing.zhu@nxp.com/ > https://patchwork.ozlabs.org/project/linux-pci/patch/20220106103645.2790803-1-festevam@gmail.com/
That's a stable fix and different discussion.
> > > Add a new ->host_exit() callback in dw_pcie_host_ops so these drivers > > > can clean up if ->host_init() fails. > > > > I'm not really a fan of adding more ops nor the ops which aren't too specific > > about what they do. 'init' and 'exit' can be anything. I'd rather see more > > specific ops with the DWC core driver in charge of sequence of operations and > > the state. > Understand.
You don't seem to...
> i.MX PCIe can't handle the error exit properly in this case by itself. So I > add one more ops.host_exit() in this series. > > Best Regards > Richard Zhu > > > > Rob
| |