From: sashiko-bot@kernel.org
To: "Chaoyi Chen" <kernel@airkyi.com>
Cc: dri-devel@lists.freedesktop.org, linux-phy@lists.infradead.org,
vkoul@kernel.org, neil.armstrong@linaro.org, olteanv@gmail.com
Subject: Re: [PATCH v8 4/7] drm/bridge: aux: Add drm_aux_bridge_register_from_node()
Date: Tue, 20 Oct 2026 08:35:46 +0000 [thread overview]
Message-ID: <sashiko-outbox-178573@kernel.org> (raw)
In-Reply-To: <20261020072816.180-5-kernel@airkyi.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] drm/bridge: aux: missing of_node_get() in drm_aux_bridge_register_from_node()
- [High] drm/bridge: aux: improper OF node setup in drm_aux_bridge_register_from_node()
--
commit 36532c7bf6a02e3a0e3f70873a369995bccbc3c6
Author: Chaoyi Chen <chaoyi.chen@rock-chips.com>
drm/bridge: aux: Add drm_aux_bridge_register_from_node()
This commit adds drm_aux_bridge_register_from_node() so callers can specify an
explicit device_node for the auxiliary bridge instead of always using the
parent device's of_node.
> diff --git a/drivers/gpu/drm/bridge/aux-bridge.c b/drivers/gpu/drm/bridge/aux-bridge.c
> index 90f76bb529cc2..f1adcdece7b95 100644
> --- a/drivers/gpu/drm/bridge/aux-bridge.c
> +++ b/drivers/gpu/drm/bridge/aux-bridge.c
> @@ -35,8 +35,9 @@ static void drm_aux_bridge_unregister_adev(void *_adev)
> }
>
> /**
> - * drm_aux_bridge_register - Create a simple bridge device to link the chain
> + * drm_aux_bridge_register_from_node - Create a simple bridge device to link the chain
> * @parent: device instance providing this bridge
> + * @np: device node pointer corresponding to this bridge instance
> *
> * Creates a simple DRM bridge that doesn't implement any drm_bridge
> * operations. Such bridges merely fill a place in the bridge chain linking
> @@ -44,7 +45,7 @@ static void drm_aux_bridge_unregister_adev(void *_adev)
> *
> * Return: zero on success, negative error code on failure
> */
> -int drm_aux_bridge_register(struct device *parent)
> +int drm_aux_bridge_register_from_node(struct device *parent, struct device_node *np)
> {
> struct auxiliary_device *adev;
> int ret;
> @@ -64,7 +65,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));
> + else
> + device_set_of_node_from_dev(&adev->dev, parent);
[Severity: High]
Does calling device_set_node() when np is non-NULL underflow the OF node
reference count on cleanup?
In drivers/base/core.c, device_set_of_node_from_dev() increments the reference
count via of_node_get() and marks the node as reused, whereas
device_set_node() only assigns the pointers:
drivers/base/core.c:
void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
{
of_node_put(dev->of_node);
dev->of_node = of_node_get(dev2->of_node);
dev_set_of_node_reused(dev);
}
void device_set_node(struct device *dev, struct fwnode_handle *fwnode)
{
dev->fwnode = fwnode;
dev->of_node = to_of_node(fwnode);
}
However, both the auxiliary_device_init() failure path in
drm_aux_bridge_register_from_node() and the device release callback
drm_aux_bridge_release() (reached if auxiliary_device_add() fails via
auxiliary_device_uninit() -> put_device(), or when the parent unbinds via
drm_aux_bridge_unregister_adev()) unconditionally drop a reference on
dev->of_node:
drivers/gpu/drm/bridge/aux-bridge.c:drm_aux_bridge_release() {
struct auxiliary_device *adev = to_auxiliary_dev(dev);
of_node_put(dev->of_node);
ida_free(&drm_aux_bridge_ida, adev->id);
kfree(adev);
}
When a caller such as rockchip_typec_phy_probe() passes a child node via
for_each_available_child_of_node(np, child_np) without taking an extra
reference for the bridge, won't this drop a reference that
drm_aux_bridge_register_from_node() never acquired?
[Severity: High]
Also, is device_set_node() appropriate here when np is shared with a parent or
subnode device (such as the dp-port PHY subnode in phy-rockchip-typec)?
Unlike device_set_of_node_from_dev(), device_set_node() sets adev->dev.fwnode
and leaves DEV_FLAG_OF_NODE_REUSED unset on &adev->dev.
Because adev->dev.fwnode is set and the node is not marked reused:
1. device_add() assigns np->fwnode.dev = &adev->dev, so fw_devlink treats the
aux_bridge auxiliary device as the supplier for np. If np is a PHY subnode
without an OF graph port (for example, tcphy0_dp / tcphy1_dp referenced via
phys = <&tcphy0_dp>), drm_aux_bridge_probe() returns -ENODEV and leaves the
auxiliary device unbound, which can cause consumers like cdn_dp to defer
probe indefinitely with -EPROBE_DEFER.
2. really_probe() -> pinctrl_bind_pins() only skips pin binding when
of_node_is_reused() is true, which can conflict if np carries pinctrl
properties.
Should the non-NULL np path instead set adev->dev.of_node = of_node_get(np)
and call dev_set_of_node_reused(&adev->dev) to match
device_set_of_node_from_dev()?
[ ... ]
> ret = auxiliary_device_init(adev);
> if (ret) {
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261020072816.180-1-kernel@airkyi.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-10-20 8:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 7:28 [PATCH v8 0/7] drm/bridge: Implement generic USB Type-C DP HPD bridge Chaoyi Chen
2026-10-20 7:28 ` [PATCH v8 1/7] drm/bridge: aux-hpd-bridge: Add drm_dev_has_dp_hpd_bridge() Chaoyi Chen
2026-10-20 7:28 ` [PATCH v8 2/7] drm/bridge: Implement generic USB Type-C DP HPD bridge Chaoyi Chen
2026-10-20 8:17 ` sashiko-bot
2026-10-20 7:28 ` [PATCH v8 3/7] drm/display: Add soft depend for aux-hpd-typec-dp-bridge module Chaoyi Chen
2026-10-20 7:28 ` [PATCH v8 4/7] drm/bridge: aux: Add drm_aux_bridge_register_from_node() Chaoyi Chen
2026-10-20 8:35 ` sashiko-bot [this message]
2026-10-20 7:28 ` [PATCH v8 5/7] phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge Chaoyi Chen
2026-10-20 8:44 ` sashiko-bot
2026-10-20 7:28 ` [PATCH v8 6/7] drm/rockchip: cdn-dp: Support handle lane info without extcon Chaoyi Chen
2026-10-20 8:52 ` sashiko-bot
2026-10-20 7:28 ` [PATCH v8 7/7] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection Chaoyi Chen
2026-10-20 9:19 ` 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=sashiko-outbox-178573@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox