Quoting Andy Shevchenko (2024-08-20 03:09:29)
> 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@xxxxxxxxx>
> > Cc: Neil Armstrong <neil.armstrong@xxxxxxxxxx>
> > Cc: Robert Foss <rfoss@xxxxxxxxxx>
> > Cc: Laurent Pinchart <Laurent.pinchart@xxxxxxxxxxxxxxxx>
> > Cc: Jonas Karlman <jonas@xxxxxxxxx>
> > Cc: Jernej Skrabec <jernej.skrabec@xxxxxxxxx>
> > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
> > Cc: Maxime Ripard <mripard@xxxxxxxxxx>
> > Cc: Thomas Zimmermann <tzimmermann@xxxxxxx>
> > Cc: David Airlie <airlied@xxxxxxxxx>
> > Cc: Daniel Vetter <daniel@xxxxxxxx>
> > Cc: <dri-devel@xxxxxxxxxxxxxxxxxxxxx>
> > Cc: Pin-yen Lin <treapking@xxxxxxxxxxxx>
> > Cc: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
>
> 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.
I'll leave the decision up to the maintainers.
>
> ...
>
> > + /*
> > + * 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?
>
ENOTSUPP is used by select_bus_fmt_recursive() so I simply followed that
style.
