From: Ville Syrjala <ville.syrjala@linux.intel.com> To: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Subject: [PATCH 6/9] drm/edid: Don't parse garbage as DispID blocks Date: Fri, 13 Mar 2020 18:20:51 +0200 [thread overview] Message-ID: <20200313162054.16009-7-ville.syrjala@linux.intel.com> (raw) In-Reply-To: <20200313162054.16009-1-ville.syrjala@linux.intel.com> From: Ville Syrjälä <ville.syrjala@linux.intel.com> Currently the code assumes that the entire EDID extesion block can be taken up by the DispID blocks. That is not true. There is at least always the DispID checksum, and potentially fill bytes if the extension block uses the interior fill scheme to pad out to fill EDID block size. So let's not parse the checksum or the fill bytes as DispID blocks by having drm_find_displayid_extension() return the actual length of the DispID data to the caller. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/drm_edid.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index dbd2e8474c2a..3067be710e5b 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3216,6 +3216,7 @@ static u8 *drm_find_displayid_extension(const struct edid *edid, int *length, int *idx) { u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT); + struct displayid_hdr *base; int ret; if (!displayid) @@ -3228,6 +3229,9 @@ static u8 *drm_find_displayid_extension(const struct edid *edid, if (ret) return NULL; + base = (struct displayid_hdr *)&displayid[*idx]; + *length = *idx + sizeof(*base) + base->bytes; + return displayid; } -- 2.24.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Ville Syrjala <ville.syrjala@linux.intel.com> To: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH 6/9] drm/edid: Don't parse garbage as DispID blocks Date: Fri, 13 Mar 2020 18:20:51 +0200 [thread overview] Message-ID: <20200313162054.16009-7-ville.syrjala@linux.intel.com> (raw) In-Reply-To: <20200313162054.16009-1-ville.syrjala@linux.intel.com> From: Ville Syrjälä <ville.syrjala@linux.intel.com> Currently the code assumes that the entire EDID extesion block can be taken up by the DispID blocks. That is not true. There is at least always the DispID checksum, and potentially fill bytes if the extension block uses the interior fill scheme to pad out to fill EDID block size. So let's not parse the checksum or the fill bytes as DispID blocks by having drm_find_displayid_extension() return the actual length of the DispID data to the caller. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/drm_edid.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index dbd2e8474c2a..3067be710e5b 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3216,6 +3216,7 @@ static u8 *drm_find_displayid_extension(const struct edid *edid, int *length, int *idx) { u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT); + struct displayid_hdr *base; int ret; if (!displayid) @@ -3228,6 +3229,9 @@ static u8 *drm_find_displayid_extension(const struct edid *edid, if (ret) return NULL; + base = (struct displayid_hdr *)&displayid[*idx]; + *length = *idx + sizeof(*base) + base->bytes; + return displayid; } -- 2.24.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-03-13 16:21 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-13 16:20 [PATCH 0/9] drm/edid: DisplayID parser fixes Ville Syrjala 2020-03-13 16:20 ` [Intel-gfx] " Ville Syrjala 2020-03-13 16:20 ` [PATCH 1/9] drm: Constify topology id Ville Syrjala 2020-03-13 16:20 ` [Intel-gfx] " Ville Syrjala 2020-03-13 20:05 ` Alex Deucher 2020-03-13 20:05 ` [Intel-gfx] " Alex Deucher 2020-03-18 15:56 ` Ville Syrjälä 2020-03-18 15:56 ` [Intel-gfx] " Ville Syrjälä 2020-03-13 16:20 ` [PATCH 2/9] drm/edid: Swap some operands in for_each_displayid_db() Ville Syrjala 2020-03-13 16:20 ` [Intel-gfx] " Ville Syrjala 2020-03-13 16:20 ` [PATCH 3/9] drm/edid: Remove idx==1 assumptions from all over the DispID parsing Ville Syrjala 2020-03-13 16:20 ` [Intel-gfx] " Ville Syrjala 2020-03-13 16:20 ` [PATCH 4/9] drm/edid: Return DispID length from drm_find_displayid_extension() Ville Syrjala 2020-03-13 16:20 ` [Intel-gfx] " Ville Syrjala 2020-03-13 16:20 ` [PATCH 5/9] drm/edid: Move validate_displayid() drm_find_displayid_extension() Ville Syrjala 2020-03-13 16:20 ` [Intel-gfx] " Ville Syrjala 2020-03-13 16:20 ` Ville Syrjala [this message] 2020-03-13 16:20 ` [Intel-gfx] [PATCH 6/9] drm/edid: Don't parse garbage as DispID blocks Ville Syrjala 2020-03-13 16:20 ` [PATCH 7/9] drm/edid: Don't include ext block csum in DispID size Ville Syrjala 2020-03-13 16:20 ` [Intel-gfx] " Ville Syrjala 2020-03-13 16:20 ` [PATCH 8/9] drm/edid: Clarify validate_displayid() Ville Syrjala 2020-03-13 16:20 ` [Intel-gfx] " Ville Syrjala 2020-03-13 16:20 ` [PATCH 9/9] drm/edid: Fix DispID tile parsing for override EDID Ville Syrjala 2020-03-13 16:20 ` [Intel-gfx] " Ville Syrjala 2020-03-16 14:44 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: DisplayID parser fixes Patchwork 2020-03-16 21:44 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200313162054.16009-7-ville.syrjala@linux.intel.com \ --to=ville.syrjala@linux.intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.