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@xxxxxxxxxx> 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
