On Fri, 2025-06-27 at 18:19 +0300, Imre Deak wrote:
> On Thu, Jun 26, 2025 at 11:31:31AM +0300, Jani Nikula wrote:
> > On Thu, 26 Jun 2025, Imre Deak <imre.d...@intel.com> wrote:
> > > From: Imre Deak <imre.d...@gmail.com>
> > >
> > > The MST link status should be always verified from the same DPCD
> > > registers after link training. Atm, both the legacy (0x202 - 0x205) and
> > > the ESI (0x200C - 0x200F) link status registers are used. Use always the
> > > latter ESI version of link status registers.
> > >
> > > Signed-off-by: Imre Deak <imre.d...@gmail.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 20 ++++++++++++++++++--
> > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 3f911c930a30b..ac7e08f485309 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -5176,6 +5176,23 @@ intel_dp_handle_hdmi_link_status_change(struct
> > > intel_dp *intel_dp)
> > > }
> > > }
> > >
> > > +static bool
> > > +intel_dp_read_link_status(struct intel_dp *intel_dp, u8
> > > link_status[DP_LINK_STATUS_SIZE])
> > > +{
> > > + bool ret;
> > > +
> > > + memset(link_status, 0, DP_LINK_STATUS_SIZE);
> > > +
> > > + if (intel_dp_mst_active_streams(intel_dp) > 0)
> > > + ret = drm_dp_dpcd_read_data(&intel_dp->aux,
> > > DP_LANE0_1_STATUS_ESI,
> > > + link_status, DP_LINK_STATUS_SIZE -
> > > 2) == 0;
> > > + else
> > > + ret = drm_dp_dpcd_read_phy_link_status(&intel_dp->aux,
> > > DP_PHY_DPRX,
> > > + link_status) == 0;
> >
> > Please propagate the int instead of having "== 0" at the end of the
> > assignment.
> >
> > I'm increasingly critical of bool returns for success/failure, because
> > they don't really mix well with 0 for success and negative values for
> > error.
>
> Ok will do that.
>
> Both ways are used all around, but I suppose propagating the error code
> should be the default choice. An exception being adding a new variant
> of an already existing function with a bool success/failure return type
> where the new variant should do the same.
I agree that here it makes sense to propagate the error. There's no
reason to swallow it.
With that change:
Reviewed-by: Luca Coelho <luciano.coe...@intel.com>
--
Cheers,
Luca.
