All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yadu M G" <yadu.mg@oss.qualcomm.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2] PCI: dwc: Initialize pp->lock before MSI domain registration
Date: Thu, 14 May 2026 21:26:20 +0000	[thread overview]
Message-ID: <20260514212621.55873C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260514181901.315647-1-yadu.mg@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional double initialization of `pp->lock` in `dw_pcie_allocate_domains()` destroys lock state and corrupts lockdep tracking for standard platforms.
--

commit 34c5622cf23f408a8b7191136ff7caf71c5a0456
Author: Yadu M G <yadu.mg@oss.qualcomm.com>

PCI: dwc: Initialize pp->lock before MSI domain registration

This commit adds an initialization of pp->lock in dw_pcie_allocate_domains()
to fix a lockdep warning on Qcom platforms. These platforms allocate the MSI
domain from a custom .msi_init callback, bypassing the standard
dw_pcie_host_init() flow.

> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index c9517a3488368..de316f103c73b 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -215,6 +215,13 @@ int dw_pcie_allocate_domains(struct dw_pcie_rp *pp)
>  		.host_data	= pp,
>  	};
>  
> +	/*
> +	 * Initialize pp->lock here to cover direct callers from custom
> +	 * .msi_init() paths (e.g. firmware-managed platforms) that
> +	 * bypass dw_pcie_host_init().
> +	 */
> +	raw_spin_lock_init(&pp->lock);
> +

Does this unconditionally re-initialize the lock for standard platforms?

In the standard DesignWare host initialization flow, dw_pcie_host_init()
initializes pp->lock at the beginning of the function. It then calls the
platform-specific pp->ops->init() callback, which on some platforms like
Uniphier configures and enables INTx interrupts.

If an INTx interrupt fires asynchronously and its handler legitimately
acquires pp->lock, would this second raw_spin_lock_init() call in
dw_pcie_allocate_domains() destroy the lock state while it is in use?

Re-initializing the spinlock forcibly resets its internal state to
unlocked and assigns a new lockdep key, which could introduce a data
race or corrupt lock dependency tracking for platforms using the
standard initialization flow.

>  	pp->irq_domain = msi_create_parent_irq_domain(&info, &dw_pcie_msi_parent_ops);
>  	if (!pp->irq_domain) {
>  		dev_err(pci->dev, "Failed to create IRQ domain\n");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514181901.315647-1-yadu.mg@oss.qualcomm.com?part=1

      reply	other threads:[~2026-05-14 21:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14 18:19 [PATCH v2] PCI: dwc: Initialize pp->lock before MSI domain registration Yadu M G
2026-05-14 21:26 ` sashiko-bot [this message]

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=20260514212621.55873C2BCB3@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yadu.mg@oss.qualcomm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.