All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: vladimir.oltean@nxp.com
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH 1/3] PCI: cadence: Remove device links to PHY
Date: Sat, 12 Sep 2026 16:24:52 +0000	[thread overview]
Message-ID: <20260912162452.AC66C1F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260912161440.1032188-2-vladimir.oltean@nxp.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The probe function `cdns_plat_pcie_probe` unconditionally returns 0 on failure paths, masking initialization errors from the driver core.
- [High] Shutdown and PM callbacks erroneously cast `struct cdns_plat_pcie *` to `struct cdns_pcie *`, causing severe out-of-bounds memory accesses.
--

commit 93f901fd65f6099ca141c0baa86f19be3649b0d0
Author: Vladimir Oltean <vladimir.oltean@nxp.com>

PCI: cadence: Remove device links to PHY

This patch partially reverts device link pieces from a previous commit
because a PHY consumer driver dereferences fields from struct phy, which
will become impossible. It relies on the PHY core's own device links to
order provider and consumer suspend/resume operations.

> diff --git a/drivers/pci/controller/cadence/pcie-cadence-plat.c b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> index a1ea24fc3b63f..5900d68c6e83a 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-plat.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c
[ ... ]
> @@ -122,9 +121,6 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)
>  	pm_runtime_put_sync(dev);
>  	pm_runtime_disable(dev);
>  	cdns_pcie_disable_phy(cdns_plat_pcie->pcie);
> -	phy_count = cdns_plat_pcie->pcie->phy_count;
> -	while (phy_count--)
> -		device_link_del(cdns_plat_pcie->pcie->link[phy_count]);
>  
>  	return 0;
>  }

[Severity: High]
This is a pre-existing issue, but does this error path intentionally return 0?

If a setup failure occurs during probe (such as cdns_pcie_host_setup()
failing), the code jumps to this error path, performs partial cleanup,
but explicitly returns 0 instead of propagating the error code.

Since the driver core sees a successful probe, it will keep the device
bound. Will subsequent accesses to the device crash the kernel because
the internal structures and resources are partially freed or disabled?

[Severity: High]
This is another pre-existing issue, but could the platform drvdata setup
cause severe out-of-bounds memory accesses during power management?

The cdns_plat_pcie_probe() function allocates an 8-byte struct cdns_plat_pcie
and assigns it as the platform drvdata. However, cdns_plat_pcie_shutdown(),
cdns_pcie_suspend_noirq(), and cdns_pcie_resume_noirq() retrieve the
drvdata and cast it to the much larger struct cdns_pcie *:

cdns_plat_pcie_shutdown() {
    ...
    struct cdns_pcie *pcie = dev_get_drvdata(dev);
    ...
    cdns_pcie_disable_phy(pcie);
}

Does accessing fields at large offsets, like pcie->phy_count inside
cdns_pcie_disable_phy(), read memory completely out of bounds and
potentially cause an immediate kernel panic during suspend, resume,
or shutdown?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912161440.1032188-1-vladimir.oltean@nxp.com?part=1

  reply	other threads:[~2026-09-12 16:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-12 16:14 [PATCH 0/3] PCI: Remove device links to Generic PHY vladimir.oltean
2026-09-12 16:14 ` [PATCH 1/3] PCI: cadence: Remove device links to PHY vladimir.oltean
2026-09-12 16:24   ` sashiko-bot [this message]
2026-09-12 16:27     ` Vladimir Oltean
2026-09-12 16:14 ` [PATCH 2/3] PCI: dra7xx: " vladimir.oltean
2026-09-12 16:25   ` sashiko-bot
2026-09-12 16:14 ` [PATCH 3/3] PCI: keystone: " vladimir.oltean
2026-09-12 16:27   ` sashiko-bot
2026-09-15  6:11 ` [PATCH 0/3] PCI: Remove device links to Generic PHY Aksh Garg
2026-09-17 23:00 ` Bjorn Helgaas

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=20260912162452.AC66C1F00898@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vladimir.oltean@nxp.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.