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 lyude@redhat.com Signed-off-by: Jani Nikula jani.nikula@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;
/*