Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jia Wang" <wangjia@ultrarisc.com>
Cc: linux-pci@vger.kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v2 2/3] PCI: ultrarisc: get and enable DP1000 PCIe clocks
Date: Mon, 06 Jul 2026 10:11:13 +0000	[thread overview]
Message-ID: <20260706101114.129681F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706-ultrarisc-pci-clk-v2-2-2f3fb6fba66b@ultrarisc.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional register access in suspend after a prior resume failure causes kernel panic.
--

commit 91b0a79d0e5b5b1e0d3c9731fd011273f668f0a9
Author: Jia Wang <wangjia@ultrarisc.com>

PCI: ultrarisc: get and enable DP1000 PCIe clocks

Add the required core, dbi, and aux clocks for the DP1000 PCIe
controller and enable them before initializing the DesignWare host.
Also manage the clocks across system suspend and resume.

> diff --git a/drivers/pci/controller/dwc/pcie-ultrarisc.c b/drivers/pci/controller/dwc/pcie-ultrarisc.c
> index 6ee661ceff67a..6ed244770d538 100644
> --- a/drivers/pci/controller/dwc/pcie-ultrarisc.c
> +++ b/drivers/pci/controller/dwc/pcie-ultrarisc.c
[ ... ]
> @@ -135,14 +174,31 @@ static int ultrarisc_pcie_probe(struct platform_device *pdev)
>  
>  static int ultrarisc_pcie_suspend_noirq(struct device *dev)
>  {
> -	struct dw_pcie *pci = dev_get_drvdata(dev);
> +	struct ultrarisc_pcie *ultra = dev_get_drvdata(dev);
> +	struct dw_pcie *pci = &ultra->pci;
> +	int ret;
> +
> +	ret = dw_pcie_suspend_noirq(pci);

[Severity: High]
What happens here if a previous resume attempt failed to enable the clocks?

Looking at ultrarisc_pcie_resume_noirq() below, if clk_bulk_prepare_enable()
fails, the function returns an error while the clocks remain disabled and
pci->suspended remains true.

If the system then undergoes another suspend cycle, this function will call
dw_pcie_suspend_noirq(), which accesses hardware registers via
dw_pcie_link_up().

Since the clocks are disabled, could this register access cause a bus error
and subsequent kernel panic?

Should we check if the device is already suspended (or if the clocks are
already off) before calling dw_pcie_suspend_noirq()?

> +	if (ret)
> +		return ret;
> +
> +	if (pci->suspended)
> +		clk_bulk_disable_unprepare(ARRAY_SIZE(ultra->clks), ultra->clks);
>  
> -	return dw_pcie_suspend_noirq(pci);
> +	return 0;
>  }
>  
>  static int ultrarisc_pcie_resume_noirq(struct device *dev)
>  {
> -	struct dw_pcie *pci = dev_get_drvdata(dev);
> +	struct ultrarisc_pcie *ultra = dev_get_drvdata(dev);
> +	struct dw_pcie *pci = &ultra->pci;
> +	int ret;
> +
> +	if (pci->suspended) {
> +		ret = clk_bulk_prepare_enable(ARRAY_SIZE(ultra->clks), ultra->clks);
> +		if (ret)
> +			return ret;
> +	}
>  
>  	return dw_pcie_resume_noirq(pci);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706-ultrarisc-pci-clk-v2-0-2f3fb6fba66b@ultrarisc.com?part=2

  reply	other threads:[~2026-07-06 10:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06  9:58 [PATCH v2 0/3] PCI: ultrarisc: Add DP1000 PCIe clock support Jia Wang via B4 Relay
2026-07-06  9:58 ` [PATCH v2 1/3] dt-bindings: pci: ultrarisc: add required DP1000 PCIe clocks Jia Wang via B4 Relay
2026-07-06 10:05   ` sashiko-bot
2026-07-06  9:58 ` [PATCH v2 2/3] PCI: ultrarisc: get and enable " Jia Wang via B4 Relay
2026-07-06 10:11   ` sashiko-bot [this message]
2026-07-06  9:58 ` [PATCH v2 3/3] PCI: ultrarisc: allow DP1000 driver to build as module Jia Wang via B4 Relay
2026-07-06 10:07   ` sashiko-bot
2026-07-07  2:48     ` Jia Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260706101114.129681F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wangjia@ultrarisc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox