[PATCH 1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block
Daniel Vetter
daniel at ffwll.ch
Tue Jan 28 16:18:34 UTC 2020
On Tue, Jan 28, 2020 at 5:15 PM Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
>
> 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 at 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 at ite.com.tw>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at 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.
"How to run unit tests without losing hair" is essentially what kunit
tries to solve. I think we should cut over to that (it's merged now,
should be good enough for at least the edid parser, mocking stuff
isn't there there), and then make sure CI runs that stuff for us. Then
we could convert over at least the unit test like selftests eventually
too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel
mailing list