Re: [PATCH] drm/edid: Refine HDMI VSDB detect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Dec 12, 2021 at 11:33:31PM +0800, Lee Shawn C wrote:
> According to CEA-861-F chapter 7.5.4. It says "The VSDB shall contain the
> 3 bytes of the IEEE OUI as well as any additional payload bytes needed."
> Now DRM driver check HDMI OUI but VSDB payload size at least five bytes.
> That may caused some HDMI monitors' audio feature can't be enabled.
> Because of they only have three bytes payload (OUI only) in VSDB.
> 
> Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> Cc: Adam Jackson <ajax@xxxxxxxxxx>
> Cc: Dave Airlie <airlied@xxxxxxxxxx>
> Signed-off-by: Lee Shawn C <shawn.c.lee@xxxxxxxxx>
> ---
>  drivers/gpu/drm/drm_edid.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 12893e7be89b..5aa4a6bf4a13 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4205,7 +4205,7 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
>  	if (cea_db_tag(db) != VENDOR_BLOCK)
>  		return false;
>  
> -	if (cea_db_payload_len(db) < 5)
> +	if (cea_db_payload_len(db) < 3)
>  		return false;

I was a a bit worried that we are now assuming that we can parse some
stuff without further length checks, but looks like that's just the 
"source physical address" stuff which we do not parse in drm_edid.c,
and the other fields we do parse are actually optional and so already
have the require length checks. So this seems fine.

Closes: https://gitlab.freedesktop.org/drm/misc/-/issues/28
Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>

Note that there is a second edid parser in cec_get_edid_spa_location()
that does parse the source physical address. You may want to double
check that it doesn't make any bad assumptions about the length 
of the vsdb either. I think we should probably get rid of that
second parser and just have drm_edid.c extract the source physical
address and pass that on directly to the cec code instead. But I
guess the cec code still couldn't remove the second parser
since some media drivers need it :( Though it could then perhaps
be moved into the media code instead of having it as a massive
inline function in the cec headers.

-- 
Ville Syrjälä
Intel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux