From: sashiko-bot@kernel.org
To: "Peter Chen" <peter.chen@cixtech.com>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org,
krzk+dt@kernel.org
Subject: Re: [PATCH 2/4] usb: cdns3: sky1: Add cdnsp-sky1 glue driver
Date: Mon, 11 May 2026 23:17:34 +0000 [thread overview]
Message-ID: <20260511231734.9BDBCC2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511024244.981941-3-peter.chen@cixtech.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Probe returns success (0) when memory resource retrieval fails, leading to a NULL pointer dereference.
- [High] Probe forcefully overwrites the mode strap configuration for all USB controllers on the SoC.
- [Medium] Resource leak of clocks on early probe error paths.
- [Medium] Unconditional assignment of dev_pm_ops violates Power Management Subsystem rules.
- [Medium] Commit message and implementation mismatch regarding hardware resets.
- [Low] Using of_match_ptr() with a statically allocated array causes compiler warnings.
--
commit a626bc93f86adbca6a4dce0b669265133a32a8cb
Author: Peter Chen <peter.chen@cixtech.com>
usb: cdns3: sky1: Add cdnsp-sky1 glue driver
Add a CIX sky1 platform glue driver with Kconfig and Makefile entry.
It calls APIs exported from cdns3-plat.c for probe/remote/suspend/resume
routines.
> Glue driver for the Cadence USB dual-role controllers on CIX Sky1
> (device tree compatible cix,sky1-usb3). It enables clocks and resets
> from the SoC, then uses the shared cdns3 platform core (cdns.ko).
The commit message mentions it enables clocks and resets from the SoC, but is
there missing code to handle the resets? The implementation includes linux/reset.h
but doesn't appear to request or interact with any reset lines.
> diff --git a/drivers/usb/cdns3/cdnsp-sky1.c b/drivers/usb/cdns3/cdnsp-sky1.c
> new file mode 100644
> index 0000000000000..049044e3d09bd
> --- /dev/null
> +++ b/drivers/usb/cdns3/cdnsp-sky1.c
[ ... ]
> +static int cdnsp_sky1_set_all_controllers_otg(struct regmap *syscon)
> +{
> + int id, ret;
> +
> + for (id = 0; id < SKY1_USB_S5_NUM; id++) {
> + ret = cdnsp_sky1_set_mode_by_id(syscon, id, MODE_STRAP_OTG);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
Does this code unintentionally alter the state of other independent USB
controllers? It appears to iterate through all controllers on the SoC and
updates them to MODE_STRAP_OTG, which might affect concurrent controllers
that are explicitly configured as host-only (like U2_HOST0_ID).
[ ... ]
> +static int cdnsp_sky1_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct cdnsp_sky1 *priv;
> + struct cdns *cdns;
> + struct cdns3_probe_data probe_data;
> + struct resource *res;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = dev;
> + priv->num_clks = ARRAY_SIZE(cdnsp_sky1_cdns_core_clks);
> + priv->clks = devm_kmemdup(dev, cdnsp_sky1_cdns_core_clks,
> + sizeof(cdnsp_sky1_cdns_core_clks), GFP_KERNEL);
> + if (!priv->clks)
> + return -ENOMEM;
> +
> + ret = devm_clk_bulk_get(dev, priv->num_clks, priv->clks);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to get clocks\n");
> +
> + ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to enable clocks\n");
> +
> + priv->usb_syscon = syscon_regmap_lookup_by_phandle(dev->of_node,
> + "cix,syscon-usb");
> + if (IS_ERR(priv->usb_syscon))
> + return dev_err_probe(dev, PTR_ERR(priv->usb_syscon),
> + "failed to get cix,syscon-usb regmap\n");
> +
> + ret = cdnsp_sky1_set_all_controllers_otg(priv->usb_syscon);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "failed to set USB controllers to OTG strap\n");
Can these error paths cause a resource leak? The clocks were previously enabled
via clk_bulk_prepare_enable(), but these direct returns bypass the err_clk
label where clk_bulk_disable_unprepare() is called.
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "glue");
> + if (!res)
> + goto err_clk;
If this resource retrieval fails, does the probe function return success?
The ret variable was previously set to 0 by the successful call to
cdnsp_sky1_set_all_controllers_otg(), so jumping to err_clk without updating
ret to an error code like -ENODEV would result in returning 0.
Could this lead to a NULL pointer dereference during subsequent power
management operations? Since the device would be considered bound without
calling cdns3_core_probe(), dev_get_drvdata() might return NULL in
callbacks like cdnsp_sky1_runtime_suspend().
[ ... ]
> +static const struct of_device_id cdnsp_sky1_of_match[] = {
> + { .compatible = "cix,sky1-usb3" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, cdnsp_sky1_of_match);
> +
> +static struct platform_driver cdnsp_sky1_driver = {
> + .probe = cdnsp_sky1_probe,
> + .remove = cdnsp_sky1_remove,
> + .driver = {
> + .name = "cdnsp-sky1",
> + .of_match_table = of_match_ptr(cdnsp_sky1_of_match),
If the kernel is built with CONFIG_OF disabled, of_match_ptr() evaluates to
NULL. Since the cdnsp_sky1_of_match array is declared statically and without
__maybe_unused annotations, will this result in an unused variable compiler
warning?
> + .pm = &cdnsp_sky1_pm_ops,
Does unconditionally assigning the pm callback structure produce dead code when
CONFIG_PM is disabled? According to the power management subsystem guidelines,
this should likely be wrapped with the pm_ptr() macro so it evaluates to NULL
without PM support.
> + },
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511024244.981941-1-peter.chen@cixtech.com?part=2
next prev parent reply other threads:[~2026-05-11 23:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 2:42 [PATCH 0/4] Add CIX Sky1 Cadence USB3 support Peter Chen
2026-05-11 2:42 ` [PATCH 1/4] usb: cdns3: plat: Expose platform core driver as library Peter Chen
2026-05-11 23:02 ` sashiko-bot
2026-05-12 7:03 ` Peter Chen
2026-05-11 2:42 ` [PATCH 2/4] usb: cdns3: sky1: Add cdnsp-sky1 glue driver Peter Chen
2026-05-11 23:17 ` sashiko-bot [this message]
2026-05-12 7:43 ` Peter Chen
2026-05-11 2:42 ` [PATCH 3/4] dt-bindings: usb: add CIX Sky1 Cadence USB3 controller Peter Chen
2026-05-11 2:42 ` [PATCH 4/4] arm64: dts: cix: add Sky1 USB4 and USB5 controllers Peter Chen
2026-05-11 23:59 ` sashiko-bot
2026-05-12 3:10 ` Peter Chen
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=20260511231734.9BDBCC2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=peter.chen@cixtech.com \
--cc=robh@kernel.org \
--cc=sashiko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox