From: sashiko-bot@kernel.org
To: "Hans Zhang" <18255117159@163.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v8 3/3] PCI: cadence: Add LGA IP debugfs for LTSSM status
Date: Wed, 01 Jul 2026 07:47:16 +0000 [thread overview]
Message-ID: <20260701074717.292BA1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701073513.1101559-4-18255117159@163.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the `to_pci_epc()` macro is incorrectly applied to the platform device's `dev` object in `cdns_pcie_ep_disable()`, resulting in type confusion and bogus pointer dereference.
--
commit 21d2761732f07216945992f2fa129395035e6bda
Author: Hans Zhang <18255117159@163.com>
PCI: cadence: Add LGA IP debugfs for LTSSM status
This commit extends debugfs support to LGA-based Cadence PCIe controllers.
It makes the ltssm_status file work for both HPA and LGA IPs by selecting
the appropriate register access based on the is_hpa flag.
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> index c0e1194a936b3..370b19f4d38fb 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> @@ -655,6 +655,7 @@ void cdns_pcie_ep_disable(struct cdns_pcie_ep *ep)
> struct device *dev = ep->pcie.dev;
> struct pci_epc *epc = to_pci_epc(dev);
[Severity: High]
This is a pre-existing issue, but does this code pass the correct dev to
to_pci_epc()?
Because ep->pcie.dev represents the parent platform device rather than the
device object embedded inside struct pci_epc, the container_of calculation
inside to_pci_epc() yields an incorrect address.
Will this garbage pointer subsequently passed to pci_epc_mem_free_addr()
and pci_epc_mem_exit() cause an invalid memory access during device
teardown?
>
> + cdns_pcie_debugfs_deinit(&ep->pcie);
> pci_epc_deinit_notify(epc);
> pci_epc_mem_free_addr(epc, ep->irq_phys_addr, ep->irq_cpu_addr,
> SZ_128K);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701073513.1101559-1-18255117159@163.com?part=3
prev parent reply other threads:[~2026-07-01 7:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 7:35 [PATCH v8 0/3] PCI: cadence: Add LTSSM debugfs Hans Zhang
2026-07-01 7:35 ` [PATCH v8 1/3] PCI: cadence: Add HPA architecture flag Hans Zhang
2026-07-01 7:46 ` sashiko-bot
2026-07-01 7:35 ` [PATCH v8 2/3] PCI: cadence: Add HPA IP debugfs for LTSSM status Hans Zhang
2026-07-01 7:48 ` sashiko-bot
2026-07-01 7:35 ` [PATCH v8 3/3] PCI: cadence: Add LGA " Hans Zhang
2026-07-01 7:47 ` 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=20260701074717.292BA1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=18255117159@163.com \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.