On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote: > In the future, we'll be needing more of the extended receiver capability > field starting at DPCD address 0x2200. (Specifically, we'll need main > link channel coding cap for DP 2.0.) Start using it now to not miss out > later on. > > Cc: Lyude Paul <ly...@redhat.com> > Signed-off-by: Jani Nikula <jani.nik...@intel.com> > > --- > > I guess this can be merged after the topic branch to drm-misc-next or > so, but I'd prefer to have this fairly early on to catch any potential > issues. > --- > drivers/gpu/drm/drm_dp_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index 1e7c638873c8..3a3c238452df 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8 > dpcd[DP_RECEIVER_CAP_SIZE]) > static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux, > u8 dpcd[DP_RECEIVER_CAP_SIZE]) > { > - u8 dpcd_ext[6]; > + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
Not 100% sure this is right? It's not clear at first glance of the 2.0 spec, but my assumption would be that on < DP2.0 devices that everything but those first 6 bytes are zeroed out in the extended DPRX field. Since we memcpy() dpcd_ext using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the DPCD caps that comes after those 6 bytes. > int ret; > > /* -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel