From: sashiko-bot@kernel.org
To: "Chaoyi Chen" <kernel@airkyi.com>
Cc: dri-devel@lists.freedesktop.org, olteanv@gmail.com,
linux-phy@lists.infradead.org, vkoul@kernel.org,
neil.armstrong@linaro.org
Subject: Re: [PATCH v4 2/5] drm/bridge: aux: Add drm_aux_bridge_register_from_node()
Date: Mon, 27 Jul 2026 06:53:45 +0000 [thread overview]
Message-ID: <20260727065346.1800B1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260727064408.101-3-kernel@airkyi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing of_node_get() when setting the device node from `np` in `drm_aux_bridge_register_from_node()` leads to a reference count underflow, as cleanup and release paths unconditionally drop the reference.
--
--- Patch [2]: [PATCH v4 2/5] drm/bridge: aux: Add drm_aux_bridge_register_from_node() ---
commit d7b1eb76e37cb91bfdbe4b86349165417e109776
Author: Chaoyi Chen <chaoyi.chen@rock-chips.com>
drm/bridge: aux: Add drm_aux_bridge_register_from_node()
This commit introduces drm_aux_bridge_register_from_node() to allow
specifying the of_node corresponding to the bridge when registering
an auxiliary bridge device.
> diff --git a/drivers/gpu/drm/bridge/aux-bridge.c b/drivers/gpu/drm/bridge/aux-bridge.c
> index 169939d233102..2b48612d6d1ba 100644
> --- a/drivers/gpu/drm/bridge/aux-bridge.c
> +++ b/drivers/gpu/drm/bridge/aux-bridge.c
[ ... ]
> @@ -63,7 +64,10 @@ int drm_aux_bridge_register(struct device *parent)
> adev->dev.parent = parent;
> adev->dev.release = drm_aux_bridge_release;
>
> - device_set_of_node_from_dev(&adev->dev, parent);
> + if (np)
> + device_set_node(&adev->dev, of_fwnode_handle(np));
[Severity: High]
When np is provided, device_set_node() is used. Unlike
device_set_of_node_from_dev(), device_set_node() does not appear to
increment the reference count of the target node.
> + else
> + device_set_of_node_from_dev(&adev->dev, parent);
>
> ret = auxiliary_device_init(adev);
> if (ret) {
Could this lead to a reference count underflow for the provided np?
The error path here unconditionally calls of_node_put(adev->dev.of_node).
Additionally, the drm_aux_bridge_release() callback also unconditionally
drops a reference to the device's of_node when the device is destroyed.
Since device_set_node() doesn't take an initial reference on np, will
these put operations result in a use-after-free for the device tree node?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260727064408.101-1-kernel@airkyi.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-07-27 6:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 6:44 [PATCH v4 0/5] This series is split from the v15 "Add Type-C DP support for RK3399 EVB Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:44 ` [PATCH v4 1/5] drm/bridge: Implement generic USB Type-C DP HPD bridge Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:58 ` sashiko-bot
2026-07-27 6:44 ` [PATCH v4 2/5] drm/bridge: aux: Add drm_aux_bridge_register_from_node() Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:53 ` sashiko-bot [this message]
2026-07-27 6:44 ` [PATCH v4 3/5] phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 7:01 ` sashiko-bot
2026-07-27 6:44 ` [PATCH v4 4/5] drm/rockchip: cdn-dp: Support handle lane info without extcon Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:55 ` sashiko-bot
2026-07-27 6:44 ` [PATCH v4 5/5] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:44 ` Chaoyi Chen
2026-07-27 6:59 ` sashiko-bot
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=20260727065346.1800B1F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel@airkyi.com \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/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.