[{"id":3686594,"web_url":"http://patchwork.ozlabs.org/comment/3686594/","msgid":"<20260505162629.GA734488@bhelgaas>","list_archive_url":null,"date":"2026-05-05T16:26:29","subject":"Re: [PATCH v8 phy-next 01/31] PCI: cadence: Preserve all error codes\n in cdns_plat_pcie_probe()","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"[+cc Tom, author of bd22885aa188 in case there's something subtle here]\n\nOn Tue, May 05, 2026 at 01:04:53PM +0300, Vladimir Oltean wrote:\n> The blamed commit functionally changed the error path of\n> cdns_pcie_host_probe(), now cdns_plat_pcie_probe().\n> \n> When the old code path executed \"goto err_get_sync\", the PCIe controller\n> probe function propagated the pm_runtime_get_sync() error code. The new\n> code doesn't, and returns 0.\n> \n> Similarly for the \"goto err_init\" previously triggered by\n> cdns_pcie_host_init() errors, and now triggered by\n> cdns_pcie_host_setup() and cdns_pcie_ep_setup() errors. These are not\n> propagated and will result in probing success, which is incorrect.\n> \n> Fixes: bd22885aa188 (\"PCI: cadence: Refactor driver to use as a core library\")\n> Signed-off-by: Vladimir Oltean \n> ---\n> Cc: Bjorn Helgaas \n> Cc: \"Krzysztof Wilczyński\" \n> Cc: Lorenzo Pieralisi \n> Cc: Manikandan K Pillai \n> Cc: Manivannan Sadhasivam \n> Cc: Rob Herring \n\nI guess this driver is orphaned.\n\nAcked-by: Bjorn Helgaas \n\n> v7->v8: patch is new, issue was flagged by Sashiko\n> https://sashiko.dev/#/patchset/20260430110652.558622-1-vladimir.oltean@nxp.com\n> ---\n> drivers/pci/controller/cadence/pcie-cadence-plat.c | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/drivers/pci/controller/cadence/pcie-cadence-plat.c b/drivers/pci/controller/cadence/pcie-cadence-plat.c\n> index b067a3296dd3..8b12a46b5601 100644\n> --- a/drivers/pci/controller/cadence/pcie-cadence-plat.c\n> +++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c\n> @@ -126,7 +126,7 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)\n> \twhile (phy_count--)\n> \t\tdevice_link_del(cdns_plat_pcie->pcie->link[phy_count]);\n> \n> -\treturn 0;\n> +\treturn ret;\n\nThis affects cases where pm_runtime_get_sync(),\ncdns_pcie_host_setup(), or cdns_pcie_ep_setup() return failure.\n\nSeems right to me to fail the probe when these fail.\n\nNot all users of pm_runtime_get_sync() check for failure, but I think\nall the other controller drivers that do check return failures from\nthe .probe().\n\n> }\n> \n> static void cdns_plat_pcie_shutdown(struct platform_device *pdev)\n> -- \n> 2.34.1\n>","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=P3c57A43;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=104.64.211.4; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-53755-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"P3c57A43\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g93mr2SNvz1yJV\n\tfor ; Wed, 06 May 2026 02:26:36 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 430913006994\n\tfor ; Tue, 5 May 2026 16:26:33 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CAABA3F7A94;\n\tTue, 5 May 2026 16:26:31 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id A3B0F3EE1C4;\n\tTue, 5 May 2026 16:26:31 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 0D7D5C2BCB4;\n\tTue, 5 May 2026 16:26:31 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777998391; cv=none;\n b=b2XqrhMSx9cgqNL5aIJy/EEMCa4y7XwGuepE7hurErLXRA/YP+qllxrFRA6frgYh6ik4XxdbRKMG3XxjzkJ5CpIYcU/98fjbb+v02TWZrWiYpLGc2cW3qHOoHeERPPSI7gFQjYbtQab9wwxkU+/yVJgo2bijO+gucVg7GiOaj/g=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777998391; c=relaxed/simple;\n\tbh=d9oRhAaRGwydDiDuK7BhCRvRWDp8pOBlU9+d0qcoLXY=;\n\th=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:\n\t Content-Disposition:In-Reply-To;\n b=YjO8IVpMtSzCXGDC2g79qdmSNbTcXozg1SPKqgVjg/MPfo+j/eJYcAoIiSrMv0yC2XUaaLSE6CFwkfpe0i40Hb0Ukrk+jajW6M67+pxCmfcbur3xRzWfG3w1C/EKjxUMVnc8yjw1nBI3bv2L42x3uN9ljDkWbOiEsxuHHHZEPM0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=P3c57A43; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777998391;\n\tbh=d9oRhAaRGwydDiDuK7BhCRvRWDp8pOBlU9+d0qcoLXY=;\n\th=Date:From:To:Cc:Subject:In-Reply-To:From;\n\tb=P3c57A43Ly9U95oakv1tzSfsBDMAQvbGX3L5fDur0PPxN8g/BkGWOrF0IQ1vnb8kn\n\t q5FpFULXXt5CFm8Sy/qdB+pGfZ+595OPQ/+H2h/dpiAmaAvc14vlTx4Z7a774smhAG\n\t mRi8mWrUgi+n3TQ7klBwMiCHYz3eCKtTXeoo5Vugwd9W8wFUQWC/qxp4tUJmAVvLgS\n\t jHSgvFYD9WkXPVvCXJZvfwe/RjozMVbFHi4OoCu3mLeSQZDLHCSt79QQSlDeG2UmtL\n\t GPSyoqLckepvJjFkRnrQa3yfyKh+iIz18B0bEQzeLYkJERNnopW8hE0+mQWVZV5SLC\n\t bwYA1sJR8mQqw==","Date":"Tue, 5 May 2026 11:26:29 -0500","From":"Bjorn Helgaas ","To":"Vladimir Oltean ","Cc":"linux-phy@lists.infradead.org, Vinod Koul ,\n Neil Armstrong , dri-devel@lists.freedesktop.org,\n freedreno@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org,\n linux-arm-msm@vger.kernel.org, linux-can@vger.kernel.org,\n linux-gpio@vger.kernel.org, linux-ide@vger.kernel.org,\n linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,\n linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,\n linux-riscv@lists.infradead.org, linux-rockchip@lists.infradead.org,\n linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,\n linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org,\n linux-usb@vger.kernel.org, netdev@vger.kernel.org, spacemit@lists.linux.dev,\n UNGLinuxDriver@microchip.com, Bjorn Helgaas , Krzysztof\n\t=?utf-8?q?Wilczy=C5=84ski?= ,\n Lorenzo Pieralisi ,\n Manikandan K Pillai ,\n Manivannan Sadhasivam , Rob Herring ,\n Tom Joseph ","Subject":"Re: [PATCH v8 phy-next 01/31] PCI: cadence: Preserve all error codes\n in cdns_plat_pcie_probe()","Message-ID":"<20260505162629.GA734488@bhelgaas>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260505100523.1922388-2-vladimir.oltean@nxp.com>"}},{"id":3687565,"web_url":"http://patchwork.ozlabs.org/comment/3687565/","msgid":"<20260507075957.B787EC2BCB8@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-07T07:59:57","subject":"Re: [PATCH v8 phy-next 01/31] PCI: cadence: Preserve all error\n codes in cdns_plat_pcie_probe()","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:\n- [High] Type confusion in `cdns_plat_pcie_shutdown()` and PM callbacks causes an out-of-bounds read and kernel crash during system shutdown or suspend.\n- [High] Missing driver `.remove` callback causes severe Use-After-Free and resource leaks upon driver unbind.\n--\n\ncommit 0bab3a01514eb340ef73b1b934e9dc310bdbfcda\nAuthor: Vladimir Oltean \n\nPCI: cadence: Preserve all error codes in cdns_plat_pcie_probe()\n\nThis commit updates the error path in cdns_plat_pcie_probe() to ensure that\nerrors from functions like pm_runtime_get_sync() and cdns_pcie_host_setup()\nare properly propagated instead of incorrectly returning success.\n\n> --- a/drivers/pci/controller/cadence/pcie-cadence-plat.c\n> +++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c\n> @@ -126,7 +126,7 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)\n> \twhile (phy_count--)\n> \t\tdevice_link_del(cdns_plat_pcie->pcie->link[phy_count]);\n> \n> -\treturn 0;\n> +\treturn ret;\n> }\n\nI noticed a potential issue here that predates this patch.\n\nThis driver does not appear to have a .remove callback, nor does it set\n.suppress_bind_attrs = true. If the driver is unbound via sysfs, devres will\nclean up managed allocations like the host bridge, EPC structs, and\nstruct cdns_pcie memory.\n\nHowever, without a remove callback to call cdns_pcie_host_disable(), does the\nPCI core subsystem remain unaware that the host bridge was removed?\n\nCould this lead to a use-after-free if the PCI core continues to access the\nfreed bridge structure and memory-mapped I/O regions?\n\nA related leak of PHY device links was noted as fixed by a later commit in\nthis series (PCI: Remove device links to PHY), but it appears the missing\nroot bus teardown remains unfixed.\n\n> \n> static void cdns_plat_pcie_shutdown(struct platform_device *pdev)\n\nI also noticed another pre-existing issue related to this function.\n\nIn cdns_plat_pcie_probe(), the platform device's driver data is set to a\nstruct cdns_plat_pcie pointer:\n\ncdns_plat_pcie_probe()\n cdns_plat_pcie = devm_kzalloc(dev, sizeof(*cdns_plat_pcie), GFP_KERNEL);\n ...\n platform_set_drvdata(pdev, cdns_plat_pcie);\n\nHowever, cdns_plat_pcie_shutdown() retrieves this and casts it directly to a\nstruct cdns_pcie pointer:\n\ncdns_plat_pcie_shutdown()\n struct cdns_pcie *pcie = dev_get_drvdata(dev);\n ...\n cdns_pcie_disable_phy(pcie);\n\nSince struct cdns_plat_pcie is just a wrapper containing a pointer to the\nactual struct cdns_pcie, does this incorrect cast cause an out-of-bounds\nread when cdns_pcie_disable_phy() attempts to access pcie->phy_count and\niterate over the PHY pointers?","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=sJuMg55B;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-54047-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"sJuMg55B\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gB4RS3JtDz1yKd\n\tfor ; Thu, 07 May 2026 18:00:04 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id C08D1302710D\n\tfor ; Thu, 7 May 2026 08:00:02 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 8342F37B025;\n\tThu, 7 May 2026 08:00:01 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C6083382F0\n\tfor ; Thu, 7 May 2026 07:59:58 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id B787EC2BCB8;\n\tThu, 7 May 2026 07:59:57 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778140799; cv=none;\n b=VBEKBDZ0UFDNUtAtnAU8bCm/QJzuCOGjvEySFccx3KdSopkKgsym0WwcVAdTHUX1Q5MUhZ7BveSOOqRrGIaDde5JirxZZWxkoOi1QdEQSJUWDvYxEKK16BX1mlumJJyXKb0On0YcHi55+G3PYJ9xwlLKRSKz38YUBao+vWwDE5s=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778140799; c=relaxed/simple;\n\tbh=PAqjXxV0tM+tkJZe+pIS5Ky/Or2uQagGCWjUiJWr/EM=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=UrTGmIjq/OSfbuQp4wh/H5lxZ+gNM5I1yAiH4TXITfH1sYOolzyHYcvqyE43aaYOcvWW8EuGwUprqQLyulTWuc/GRkA7VENPEJmQZKqxvAmWnhscEh4itv/K1Z0kBUYsRI3C1WxKmjQU9QM1kdgR5tZD+RSUB5JK3Fm8mCyGAJM=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=sJuMg55B; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778140797;\n\tbh=PAqjXxV0tM+tkJZe+pIS5Ky/Or2uQagGCWjUiJWr/EM=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=sJuMg55BNEcpWXmaclOJ9iw1FdhU7QAEhGEuvQTco97Efm060tyJx8hAzc4YblWuN\n\t z5YyVnQLyjILrAT8S73/UzzTrWQRG/pHRn4NBYp1UUF6KdZgBWTO/vcXZsNrRgbS2p\n\t o2BJYDE0nfjD6btE4hxz5XnehB6OZMpGgzYU8+2f9beSp79FYZTdWrZVI5UjOo4Bz8\n\t 1ai/iGCBR17/ijvngv0WwfdtMasRauJJs01NsUKz+mGNOMLLJLVLa/OTbox/v1NnOo\n\t AmRrLvZorAuY4P3/8/lOZ3xn/U50fnav2KR07quPIQ2uM6I4NMq+vhHd2yNKZW1G2d\n\t /j+V5dQZWcVfQ==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v8 phy-next 01/31] PCI: cadence: Preserve all error\n codes in cdns_plat_pcie_probe()","Reply-To":"sashiko@lists.linux.dev","To":"\"Vladimir Oltean\" ","Cc":"linux-pci@vger.kernel.org, wsa+renesas@sang-engineering.com","In-Reply-To":"<20260505100523.1922388-2-vladimir.oltean@nxp.com>","References":"<20260505100523.1922388-2-vladimir.oltean@nxp.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Thu, 07 May 2026 07:59:57 +0000","Message-Id":"<20260507075957.B787EC2BCB8@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""}},{"id":3687898,"web_url":"http://patchwork.ozlabs.org/comment/3687898/","msgid":"<20260507155021.GA972248@bhelgaas>","list_archive_url":null,"date":"2026-05-07T15:50:21","subject":"Re: [PATCH v8 phy-next 01/31] PCI: cadence: Preserve all error codes\n in cdns_plat_pcie_probe()","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"[+to Manikandan, Hans]\n\nOn Thu, May 07, 2026 at 07:59:57AM +0000, sashiko-bot@kernel.org wrote:\n> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:\n> - [High] Type confusion in `cdns_plat_pcie_shutdown()` and PM callbacks causes an out-of-bounds read and kernel crash during system shutdown or suspend.\n> - [High] Missing driver `.remove` callback causes severe Use-After-Free and resource leaks upon driver unbind.\n\nUnrelated to Vladimir's patch, but please take a look and see if\nwe need other changes.\n\n> --\n> \n> commit 0bab3a01514eb340ef73b1b934e9dc310bdbfcda\n> Author: Vladimir Oltean \n> \n> PCI: cadence: Preserve all error codes in cdns_plat_pcie_probe()\n> \n> This commit updates the error path in cdns_plat_pcie_probe() to ensure that\n> errors from functions like pm_runtime_get_sync() and cdns_pcie_host_setup()\n> are properly propagated instead of incorrectly returning success.\n> \n> > --- a/drivers/pci/controller/cadence/pcie-cadence-plat.c\n> > +++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c\n> > @@ -126,7 +126,7 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)\n> > \twhile (phy_count--)\n> > \t\tdevice_link_del(cdns_plat_pcie->pcie->link[phy_count]);\n> > \n> > -\treturn 0;\n> > +\treturn ret;\n> > }\n> \n> I noticed a potential issue here that predates this patch.\n> \n> This driver does not appear to have a .remove callback, nor does it set\n> .suppress_bind_attrs = true. If the driver is unbound via sysfs, devres will\n> clean up managed allocations like the host bridge, EPC structs, and\n> struct cdns_pcie memory.\n> \n> However, without a remove callback to call cdns_pcie_host_disable(), does the\n> PCI core subsystem remain unaware that the host bridge was removed?\n> \n> Could this lead to a use-after-free if the PCI core continues to access the\n> freed bridge structure and memory-mapped I/O regions?\n> \n> A related leak of PHY device links was noted as fixed by a later commit in\n> this series (PCI: Remove device links to PHY), but it appears the missing\n> root bus teardown remains unfixed.\n> \n> > \n> > static void cdns_plat_pcie_shutdown(struct platform_device *pdev)\n> \n> I also noticed another pre-existing issue related to this function.\n> \n> In cdns_plat_pcie_probe(), the platform device's driver data is set to a\n> struct cdns_plat_pcie pointer:\n> \n> cdns_plat_pcie_probe()\n> cdns_plat_pcie = devm_kzalloc(dev, sizeof(*cdns_plat_pcie), GFP_KERNEL);\n> ...\n> platform_set_drvdata(pdev, cdns_plat_pcie);\n> \n> However, cdns_plat_pcie_shutdown() retrieves this and casts it directly to a\n> struct cdns_pcie pointer:\n> \n> cdns_plat_pcie_shutdown()\n> struct cdns_pcie *pcie = dev_get_drvdata(dev);\n> ...\n> cdns_pcie_disable_phy(pcie);\n> \n> Since struct cdns_plat_pcie is just a wrapper containing a pointer to the\n> actual struct cdns_pcie, does this incorrect cast cause an out-of-bounds\n> read when cdns_pcie_disable_phy() attempts to access pcie->phy_count and\n> iterate over the PHY pointers?\n> \n> -- \n> Sashiko AI review · https://sashiko.dev/#/patchset/20260505100523.1922388-1-vladimir.oltean@nxp.com?part=1","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=sTGw8R6f;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-54094-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"sTGw8R6f\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gBGyy2YVMz1yKd\n\tfor ; Fri, 08 May 2026 01:54:34 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 1E3C73067B1D\n\tfor ; Thu, 7 May 2026 15:50:27 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id DF4BD44BC9F;\n\tThu, 7 May 2026 15:50:22 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id BD4A844A713\n\tfor ; Thu, 7 May 2026 15:50:22 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 39450C2BCB2;\n\tThu, 7 May 2026 15:50:22 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778169022; cv=none;\n b=YfkTsSNREHZzyhx81CH+RfZJ3w0iCEFn5vxVUYo+HYpfcpcoJzFATpAxRa01DtQ6rJmdqM/yn4KC98oalBUiwRJuqgTqr3B0ZfrUevwGjykd7W828vqemvCnOAZWFTsKdjhIQA/NXZYpUgfezlz9iMApqLY9+TId9bqw4mgJN8I=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778169022; c=relaxed/simple;\n\tbh=cui2tLvF7Ivcas9vbvzP8+1b/LA3bYCTQeeA1JNC8UA=;\n\th=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:\n\t Content-Disposition:In-Reply-To;\n b=CYpNrjfWIwm3TXxUo4iRkEHWR204wB9v9H0NJV2kmHO16gfLiMmodldXj4iFSu5pSs0tkTeh4pQeE/qY9+64947RCRddPah+Kn0N4FPDekNgIZWcL3rOLHE7Pltz8amKRnOQ6VIzD5OWG7cF4b7/4E9uNCvQWfHY2JI0yZbvGz8=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=sTGw8R6f; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778169022;\n\tbh=cui2tLvF7Ivcas9vbvzP8+1b/LA3bYCTQeeA1JNC8UA=;\n\th=Date:From:To:Cc:Subject:In-Reply-To:From;\n\tb=sTGw8R6fkmWpFx/YozYv4CWcfHAwVTdunyID+wTg2W4KsKFpNOBeRcRWTiBx/oZGB\n\t j1KJ+Dh6j7oyuR1zHrud+25X1qzAtXZVNEmCqc2xVGi8hwkZnuU5YeCO4LdLALhsGY\n\t N8Laxkt/0jEF0u+AfODbNA5AkQo2cThlN8e4XrB+UYxW23g09wHm14LQ6x+EqrpUAv\n\t HziDIdGzYQ/Hjf4RtZ7YFrDFSsm0rgHL/ZFeuGBWBX7BePxFYprEXY6JiyexmB8PJu\n\t /mICHZlN7wNdA79Wug22HaSzSUhLL3LahIrdx/k/hpX//MUkw9/YNGdWsya0wCQAS4\n\t NVJEVHiMRekow==","Date":"Thu, 7 May 2026 10:50:21 -0500","From":"Bjorn Helgaas ","To":"Manikandan K Pillai ,\n\tHans Zhang ","Cc":"Vladimir Oltean , linux-pci@vger.kernel.org,\n\twsa+renesas@sang-engineering.com","Subject":"Re: [PATCH v8 phy-next 01/31] PCI: cadence: Preserve all error codes\n in cdns_plat_pcie_probe()","Message-ID":"<20260507155021.GA972248@bhelgaas>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260507075957.B787EC2BCB8@smtp.kernel.org>"}}]