From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Allen Chen <allen.chen@ite.com.tw>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block
Date: Tue, 28 Jan 2020 18:15:36 +0200 [thread overview]
Message-ID: <20200128161536.GL13686@intel.com> (raw)
In-Reply-To: <20200128151758.GI43062@phenom.ffwll.local>
On Tue, Jan 28, 2020 at 04:17:58PM +0100, Daniel Vetter wrote:
> On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > CEA-861 says :
> > "d = offset for the byte following the reserved data block.
> > If no data is provided in the reserved data block, then d=4.
> > If no DTDs are provided, then d=0."
> >
> > So let's not look for DTDs when d==0. In fact let's just make that
> > <4 since those values would just mean that he DTDs overlap the block
> > header. And let's also check that d isn't so big as to declare
> > the descriptors to live past the block end, although the code
> > does already survive that case as we'd just end up with a negative
> > number of descriptors and the loop would not do anything.
> >
> > Cc: Allen Chen <allen.chen@ite.com.tw>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Hm I think edid parsing is like the perfect use-case for some in-kernel
> unit tests ... In case anyone feels motivated?
Another idea I've been putting off is simply shoving the parser into
userspace. Kinda looks like with fork_usermode_blob() we could embed
the executable into the kernel/module and thus avoid the problem of
actually shipping the binary somehow.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-01-28 16:15 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 20:02 [Intel-gfx] [PATCH 1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block Ville Syrjala
2020-01-24 20:02 ` [Intel-gfx] [PATCH 2/8] drm/edid: Don't accept any old garbage as a display descriptor Ville Syrjala
2020-01-27 22:35 ` Alex Deucher
2020-02-03 19:44 ` Shankar, Uma
2020-01-24 20:02 ` [Intel-gfx] [PATCH 3/8] drm/edid: Introduce is_detailed_timing_descritor() Ville Syrjala
2020-01-27 22:36 ` Alex Deucher
2020-02-03 19:49 ` Shankar, Uma
2020-01-24 20:02 ` [Intel-gfx] [PATCH 4/8] drm/i915: Clear out spurious whitespace Ville Syrjala
2020-01-27 22:28 ` Alex Deucher
2020-02-03 19:51 ` Shankar, Uma
2020-01-24 20:02 ` [Intel-gfx] [PATCH 5/8] drm/edid: Document why we don't bounds check the DispID CEA block start/end Ville Syrjala
2020-01-27 22:30 ` Alex Deucher
2020-01-28 11:44 ` Ville Syrjälä
2020-02-03 19:58 ` Shankar, Uma
2020-01-24 20:02 ` [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA data block revision Ville Syrjala
2020-01-27 22:32 ` Alex Deucher
2020-02-03 20:15 ` Shankar, Uma
2020-02-04 13:32 ` Ville Syrjälä
2020-02-04 14:57 ` Shankar, Uma
2020-01-24 20:02 ` [Intel-gfx] [PATCH 7/8] drm/edid: Constify lots of things Ville Syrjala
2020-01-27 22:38 ` Alex Deucher
2020-01-28 11:49 ` Ville Syrjälä
2020-02-03 20:34 ` Shankar, Uma
2020-01-24 20:02 ` [Intel-gfx] [PATCH 8/8] drm/edid: Dump bogus 18 byte descriptors Ville Syrjala
2020-01-27 22:38 ` Alex Deucher
2020-02-03 20:38 ` Shankar, Uma
2020-01-24 22:53 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block Patchwork
2020-01-24 23:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-01-27 13:49 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-01-27 22:34 ` [Intel-gfx] [PATCH 1/8] " Alex Deucher
2020-02-03 19:15 ` Shankar, Uma
2020-01-28 15:17 ` Daniel Vetter
2020-01-28 16:15 ` Ville Syrjälä [this message]
2020-01-28 16:18 ` Daniel Vetter
2020-01-28 16:28 ` Ville Syrjälä
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=20200128161536.GL13686@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=allen.chen@ite.com.tw \
--cc=daniel@ffwll.ch \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox