All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Chen-Yu Tsai" <wenst@chromium.org>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v8 01/16] device property: Add fwnode_graph_get_port_by_id()
Date: Fri, 04 Sep 2026 08:54:18 +0000	[thread overview]
Message-ID: <20260904085419.2F7DD1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904084158.1341550-2-wenst@chromium.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The newly added `fwnode_graph_get_port_by_id()` API takes a non-const `struct fwnode_handle *fwnode` parameter, which is inconsistent with similar API functions.
--

commit 5894c0b778c62e34e52132ac30ee27b4741eb588
Author: Chen-Yu Tsai <wenst@chromium.org>

device property: Add fwnode_graph_get_port_by_id()

This commit adds the fwnode_graph_get_port_by_id() helper to obtain a
reference to a specific port firmware node by ID. This helper is intended for
cases such as USB power sequencing integration where a USB hub port is tied to
its corresponding port firmware node.

> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index b136c339ddae7..68108805482de 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c

[ ... ]

> @@ -1353,6 +1353,37 @@ int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
>  }
>  EXPORT_SYMBOL(fwnode_graph_parse_endpoint);
>  
> +/**
> + * fwnode_graph_get_port_by_id - get the port matching a given id
> + * @fwnode: parent fwnode_handle containing the graph
> + * @id: id of the port
> + * @flags: fwnode lookup flags
> + *
> + * The caller is responsible for calling fwnode_handle_put() on the returned
> + * fwnode pointer.
> + *
> + * Does not return ports that belong to disabled devices or endpoints that
> + * are unconnected, unless FWNODE_GRAPH_DEVICE_DISABLED is passed in @flags.
> + *
> + * Does not return ports that have no endpoints.
> + *
> + * Return: A 'port' firmware node pointer with refcount incremented.
> + */
> +struct fwnode_handle *fwnode_graph_get_port_by_id(struct fwnode_handle *fwnode,
> +						  u32 id,
> +						  unsigned long flags)

[Severity: Low]
Does this function signature intentionally drop the const qualifier for the
fwnode parameter? 

This is inconsistent with similar API functions like
fwnode_graph_get_endpoint_by_id() which take a const struct fwnode_handle *.
Callers holding a const struct fwnode_handle * cannot use this helper without
an explicit cast that discards the const qualifier, which reduces API
ergonomics.

> +{
> +	struct fwnode_handle *ep;
> +
> +	ep = fwnode_graph_get_endpoint_by_id(fwnode, id, 0,
> +					     flags | FWNODE_GRAPH_ENDPOINT_NEXT);
> +	if (!ep)
> +		return NULL;
> +
> +	return fwnode_get_next_parent(ep);
> +}
> +EXPORT_SYMBOL_GPL(fwnode_graph_get_port_by_id);
> +
>  const void *device_get_match_data(const struct device *dev)
>  {
>  	return fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data, dev);

> diff --git a/include/linux/property.h b/include/linux/property.h
> index 907c790a3f013..3dbbd01a52d09 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h

[ ... ]

> @@ -507,6 +507,8 @@ int fwnode_get_phy_mode(const struct fwnode_handle *fwnode);
>  
>  void __iomem *fwnode_iomap(struct fwnode_handle *fwnode, int index);
>  
> +struct fwnode_handle *fwnode_graph_get_port_by_id(struct fwnode_handle *fwnode, u32 id,
> +						  unsigned long flags);

[Severity: Low]
Should this declaration also use const struct fwnode_handle * for the fwnode
parameter to match the suggested change above and maintain consistency with
other fwnode_graph_* functions?

>  struct fwnode_handle *fwnode_graph_get_next_endpoint(
>  	const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
>  struct fwnode_handle *

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904084158.1341550-1-wenst@chromium.org?part=1

  reply	other threads:[~2026-09-04  8:54 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04  8:41 [PATCH v8 00/16] arm64: mediatek: Add M.2 E-key slot on Chromebooks Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 01/16] device property: Add fwnode_graph_get_port_by_id() Chen-Yu Tsai
2026-09-04  8:54   ` sashiko-bot [this message]
2026-09-04 20:18   ` Sakari Ailus
2026-09-04  8:41 ` [PATCH v8 02/16] device property: Add fwnode_graph_get_next_port_endpoint() Chen-Yu Tsai
2026-09-04 20:22   ` Sakari Ailus
2026-09-04  8:41 ` [PATCH v8 03/16] power: sequencing: Add pwrseq_get_state() Chen-Yu Tsai
2026-09-04  8:57   ` sashiko-bot
2026-09-04  8:41 ` [PATCH v8 04/16] usb: hub: Use assign_bit() in usb_hub_set_port_power() Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 05/16] usb: hub: Return actual error from hub_configure() in hub_probe() Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 06/16] usb: hub: Associate port@ fwnode with USB port device Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 07/16] usb: core: Move struct usb_port and related APIs to port.h Chen-Yu Tsai
2026-09-04 16:40   ` Alan Stern
2026-09-04 16:44   ` Greg Kroah-Hartman
2026-09-04 17:24     ` Chen-Yu Tsai
2026-09-04 17:52       ` Greg Kroah-Hartman
2026-09-05  8:19         ` Andy Shevchenko
2026-09-05 11:30           ` Greg Kroah-Hartman
2026-09-07  9:11             ` Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 08/16] usb: hub: Pass |struct usb_port*| to usb_port_is_power_on() Chen-Yu Tsai
2026-09-04 16:44   ` Alan Stern
2026-09-04  8:41 ` [PATCH v8 09/16] usb: hub: Use usb_hub_set_port_power() to control port power everywhere Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 10/16] usb: hub: Power on connected M.2 E-key connectors with power sequencing API Chen-Yu Tsai
2026-09-04  9:10   ` sashiko-bot
2026-09-04  8:41 ` [PATCH v8 11/16] dt-bindings: usb: mediatek,mtk-xhci: Switch to ports for USB connections Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 12/16] power: sequencing: pcie-m2: support matching on remote "port" node Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 13/16] power: sequencing: pcie-m2: Add usb and sdio targets for E-key connector Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 14/16] power: sequencing: pcie-m2: Split Bluetooth unit based on interface Chen-Yu Tsai
2026-09-04  9:08   ` sashiko-bot
2026-09-04  8:41 ` [PATCH v8 15/16] arm64: dts: mediatek: mt8195-cherry: Add M.2 E-key slot Chen-Yu Tsai
2026-09-04  8:41 ` [PATCH v8 16/16] arm64: dts: mediatek: mt8188-geralt: Add WiFi/BT as " Chen-Yu Tsai

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=20260904085419.2F7DD1F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wenst@chromium.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.