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
