On Wed, Aug 20, 2025 at 09:54:06AM +0200, Christian Bruel wrote:
> Add driver to configure the STM32MP25 SoC PCIe Gen1 2.5GT/s or Gen2 5GT/s
> controller based on the DesignWare PCIe core in endpoint mode.
> +static void stm32_pcie_perst_deassert(struct dw_pcie *pci)
> +{
> + struct stm32_pcie *stm32_pcie = to_stm32_pcie(pci);
> + struct device *dev = pci->dev;
> + struct dw_pcie_ep *ep = &pci->ep;
> + int ret;
> +
> + dev_dbg(dev, "PERST de-asserted by host\n");
> +
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret < 0) {
> + dev_err(dev, "Failed to resume runtime PM: %d\n", ret);
> + return;
> + }
> +
> + ret = stm32_pcie_enable_resources(stm32_pcie);
> + if (ret) {
> + dev_err(dev, "Failed to enable resources: %d\n", ret);
> + goto err_pm_put_sync;
> + }
> +
> + /*
> + * Need to reprogram the configuration space registers here because the
> + * DBI registers were incorrectly reset by the PHY RCC during phy_init().
Is this incorrect reset of DBI registers a software issue or some kind
of hardware erratum that might be fixed someday? Or maybe it's just a
characteristic of the hardware and thus not really "incorrect"?
I do see that qcom_pcie_perst_deassert() in pcie-qcom-ep.c also calls
dw_pcie_ep_init_registers() in the qcom_pcie_ep_perst_irq_thread()
path.
So does pex_ep_event_pex_rst_deassert() (pcie-tegra194.c) in the
tegra_pcie_ep_pex_rst_irq() path.
But as far as I can tell, none of the other dwc drivers need this, so
maybe it's something to do with the glue around the DWC core?
> + */
> + ret = dw_pcie_ep_init_registers(ep);
> + if (ret) {
> + dev_err(dev, "Failed to complete initialization: %d\n", ret);
> + goto err_disable_resources;
> + }
