linux-kernel - Re: [PATCH v13 06/11] PCI: stm32: Add PCIe Endpoint support for STM32MP25

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3a0afc93-a7ae-467e-97ad-f1c8d7d7a693@foss.st.com>
Date: Thu, 28 Aug 2025 20:46:30 +0200
From: Christian Bruel <christian.bruel@...s.st.com>
To: Bjorn Helgaas <helgaas@...nel.org>
CC: <lpieralisi@...nel.org>, <kwilczynski@...nel.org>, <mani@...nel.org>,
        <robh@...nel.org>, <bhelgaas@...gle.com>, <krzk+dt@...nel.org>,
        <conor+dt@...nel.org>, <mcoquelin.stm32@...il.com>,
        <alexandre.torgue@...s.st.com>, <linus.walleij@...aro.org>,
        <corbet@....net>, <p.zabel@...gutronix.de>, <shradha.t@...sung.com>,
        <mayank.rana@....qualcomm.com>, <namcao@...utronix.de>,
        <qiang.yu@....qualcomm.com>, <thippeswamy.havalige@....com>,
        <inochiama@...il.com>, <quic_schintav@...cinc.com>,
        <johan+linaro@...nel.org>, <linux-pci@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <linux-gpio@...r.kernel.org>, <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v13 06/11] PCI: stm32: Add PCIe Endpoint support for
 STM32MP25



On 8/28/25 19:16, Bjorn Helgaas wrote:
> On Thu, Aug 28, 2025 at 02:12:57PM +0200, Christian Bruel wrote:
>> On 8/27/25 20:58, Bjorn Helgaas wrote:
>>> 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?
>>
>> The RCC PHY reset is connected to the Synopsys cold reset logic, which
>> explains why the registers need to be restored. This point has been
>> addressed in the reference manual.
> 
> OK.  I dropped "incorrectly" from the comment because I think future
> readers will wonder about whether or how this could be fixed, and it
> sounds like it's just a feature of the hardware that we need to deal
> with.

OK, thank you. "unexpectedly" would have been appropriate, but just drop 
it is even better.

> 
>>>> +	 */
>>>> +	ret = dw_pcie_ep_init_registers(ep);
>>>> +	if (ret) {
>>>> +		dev_err(dev, "Failed to complete initialization: %d\n", ret);
>>>> +		goto err_disable_resources;
>>>> +	}
>>