[PATCH v3 02/17] drm/bridge: Verify lane assignment is going to work during atomic_check

[Andy Shevchenko]

On Mon, Aug 19, 2024 at 03:38:16PM -0700, Stephen Boyd wrote:
> Verify during drm_atomic_bridge_check() that the lane assignment set in
> a bridge's atomic_check() callback is going to be satisfied by the
> previous bridge. If the next bridge is requiring something besides the
> default 1:1 lane assignment on its input then there must be an output
> lane assignment on the previous bridge's output. Otherwise the next
> bridge won't get the lanes assigned that it needs.

> Cc: Andrzej Hajda <andrzej.hajda at intel.com>
> Cc: Neil Armstrong <neil.armstrong at linaro.org>
> Cc: Robert Foss <rfoss at kernel.org>
> Cc: Laurent Pinchart <Laurent.pinchart at ideasonboard.com>
> Cc: Jonas Karlman <jonas at kwiboo.se>
> Cc: Jernej Skrabec <jernej.skrabec at gmail.com>
> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> Cc: Maxime Ripard <mripard at kernel.org>
> Cc: Thomas Zimmermann <tzimmermann at suse.de>
> Cc: David Airlie <airlied at gmail.com>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: <dri-devel at lists.freedesktop.org>
> Cc: Pin-yen Lin <treapking at chromium.org>
> Cc: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>

Yeah, I really think that the appearance of this thousandth time in the Git
history has almost no value and just pollutes the commit message makes it not
very well readable. The only outcome is exercising the compression algo used
by Git.

...

> +	int i;

unsigned?

...

> +	/*
> +	 * Ensure this bridge is aware that the next bridge wants to
> +	 * reassign lanes.
> +	 */
> +	for (i = 0; i < num_input_lanes; i++)
> +		if (i != input_lanes[i].logical && !num_output_lanes)
> +			return -ENOTSUPP;

Besides missing {} this code is internal to the Linux kernel. Is it okay?

-- 
With Best Regards,
Andy Shevchenko