Re: [PATCH RFC 4/7] drm/display: dp-aux-dev: use new DCPD access helpers

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Jan 23, 2025 at 01:05:47PM +0200, Dmitry Baryshkov wrote:
> On Thu, Jan 23, 2025 at 12:05:29PM +0200, Jani Nikula wrote:
> > On Fri, 17 Jan 2025, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> > > Switch drm_dp_aux_dev.c to use new set of DPCD read / write helpers.
> > 
> > This might be one of the few places where the old functions and the old
> > return value was used in a sensible manner.
> 
> Well... Yes and no. What does it mean if we return less bytes? Is that
> still a protocol error?

AFAIK short AUX replies are perfectly legal accoding to the DP
spec, but we've not really seen them happening in any real
use cases I suppose (although I'm not sure we have sufficient
logging to tell whether something failed completely or only
partially), hence why we've never really handled them
correctly.

For aux_dev it might matter more because the common use
case is to just dump the entire DPCD, and some displays
violate the spec by having black holes inside the DPCD.
What I don't rembmer is whether those black holes actually
result in short replies, or whether the entire AUX transfer
gets rejected when it hits one even partially.

The other concern with not handling short replies correctly
is that writes (and even some reads) can have side effects.
So when a short reply arrives we may have already triggered 
some side effects while still claiming that the access
completely failed.

I suppose if someone was sufficiently motivated they could
try to handle short replies more correctly and keep retrying
the remaining bytes (assuming that is the correct way to
handle them). Although with those black holes I guess
you'd eventually have to give up anyway before having
transferred all the bytes.

-- 
Ville Syrjälä
Intel