Re: [PATCH v6 1/9] media: mc-entity: Store parsed V4L2 fwnode endpoint in media_pad

[Sakari Ailus]

Hi Frank,

Thanks for the patch.

On Wed, Jun 24, 2026 at 04:37:48PM -0400, Frank.Li@xxxxxxxxxxx wrote:
> From: Frank Li <Frank.Li@xxxxxxx>
> 
> Each media pad is associated with a firmware node endpoint. Capture the
> parsed V4L2 fwnode endpoint information in struct media_pad so it can be
> reused by consumers.
> 
> This avoids reparsing firmware node endpoint data every time the endpoint
> configuration is needed, reduces duplicate code, and provides a common
> place to store endpoint properties associated with a pad.
> 
> Signed-off-by: Frank Li <Frank.Li@xxxxxxx>
> ---
> Assume 1 to 1 map between dt's endpoint to medie pad.
> Change in v6
> - new patch
> ---
>  include/media/media-entity.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index d9b72cd87d524..4a3785cd9f370 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -20,6 +20,8 @@
>  #include <linux/minmax.h>
>  #include <linux/types.h>
>  
> +#include <media/v4l2-fwnode.h>

We have dependencies from V4L2 to MC but not the other way around as MC is
(or was?) intended for wider use then just V4L2. I'm thus more than a bit
hesitant adding any references to V4L2 in MC.

I wonder what Hans and Laurent think.

> +
>  /* Enums used internally at the media controller to represent graphs */
>  
>  /**
> @@ -230,6 +232,7 @@ enum media_pad_signal_type {
>   * @flags:	Pad flags, as defined in
>   *		:ref:`include/uapi/linux/media.h <media_header>`
>   *		(seek for ``MEDIA_PAD_FL_*``)
> + * @vep:	associated fwnode endpoint information
>   * @pipe:	Pipeline this pad belongs to. Use media_entity_pipeline() to
>   *		access this field.
>   */
> @@ -240,7 +243,7 @@ struct media_pad {
>  	u16 num_links;
>  	enum media_pad_signal_type sig_type;
>  	unsigned long flags;
> -
> +	struct v4l2_fwnode_endpoint vep;
>  	/*
>  	 * The fields below are private, and should only be accessed via
>  	 * appropriate functions.
> 

-- 
Regards,

Sakari Ailus