All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Chen-Yu Tsai" <wenst@chromium.org>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v9 01/15] device property: Add fwnode_graph_get_port_by_id()
Date: Wed, 16 Sep 2026 08:06:33 +0000	[thread overview]
Message-ID: <20260916080633.9BF621F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260916075745.3549953-2-wenst@chromium.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] device property: missing const on fwnode in fwnode_graph_get_port_by_id()
--

commit 926d6f7fd488c33560eef4ae4903250ddf63b081
Author: Chen-Yu Tsai <wenst@chromium.org>

device property: Add fwnode_graph_get_port_by_id()

This commit introduces a helper function to retrieve a port firmware node
matching a given ID. It is designed to support upcoming USB power sequencing
integration where a USB hub port is tied to its corresponding firmware node.

> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index cceaa3240ca48..576488c151810 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]
Could the fwnode parameter be marked const here?

The fwnode pointer is only passed to fwnode_graph_get_endpoint_by_id(), which
already accepts a const struct fwnode_handle pointer. Marking it const here
would improve consistency with the rest of the fwnode graph API and prevent
callers with a const pointer from having to cast it away.

> +{
> +	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);

[ ... ]

> 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]
Would it make sense to update this prototype to accept a const struct 
fwnode_handle if the implementation is adjusted as suggested above?

>  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/20260916075745.3549953-1-wenst@chromium.org?part=1

  reply	other threads:[~2026-09-16  8:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16  7:57 [PATCH v9 00/15] usb: enable M.2 E-key slot USB with pwrseq Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 01/15] device property: Add fwnode_graph_get_port_by_id() Chen-Yu Tsai
2026-09-16  8:06   ` sashiko-bot [this message]
2026-09-16  7:57 ` [PATCH v9 02/15] device property: Add fwnode_graph_get_next_port_endpoint() Chen-Yu Tsai
2026-09-16  8:14   ` sashiko-bot
2026-09-16  7:57 ` [PATCH v9 03/15] power: sequencing: Add pwrseq_get_state() Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 04/15] usb: hub: Use assign_bit() in usb_hub_set_port_power() Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 05/15] usb: hub: Return actual error from hub_configure() in hub_probe() Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 06/15] usb: hub: Associate port@ fwnode with USB port device Chen-Yu Tsai
2026-10-01 10:53   ` Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 07/15] usb: hub: Pass |struct usb_port*| to usb_port_is_power_on() Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 08/15] usb: hub: Use usb_hub_set_port_power() to control port power everywhere Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 09/15] usb: hub: Power on connected M.2 E-key connectors with power sequencing API Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 10/15] dt-bindings: usb: mediatek,mtk-xhci: Switch to ports for USB connections Chen-Yu Tsai
2026-09-16  8:10   ` sashiko-bot
2026-09-16  7:57 ` [PATCH v9 11/15] power: sequencing: pcie-m2: support matching on remote "port" node Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 12/15] power: sequencing: pcie-m2: Add usb and sdio targets for E-key connector Chen-Yu Tsai
2026-09-16  7:57 ` [PATCH v9 13/15] power: sequencing: pcie-m2: Split Bluetooth unit based on interface Chen-Yu Tsai
2026-09-16  8:13   ` sashiko-bot
2026-09-16  7:57 ` [PATCH v9 14/15] arm64: dts: mediatek: mt8195-cherry: Add M.2 E-key slot Chen-Yu Tsai
2026-09-16  8:23   ` sashiko-bot
2026-09-16  7:57 ` [PATCH v9 15/15] arm64: dts: mediatek: mt8188-geralt: Add WiFi/BT as " Chen-Yu Tsai
2026-09-21 10:51 ` [PATCH v9 00/15] usb: enable M.2 E-key slot USB with pwrseq AngeloGioacchino Del Regno

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=20260916080633.9BF621F000FF@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.