All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Allen Chen <allen.chen@ite.com.tw>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block
Date: Tue, 28 Jan 2020 17:18:34 +0100	[thread overview]
Message-ID: <CAKMK7uGjtJOU_+Hv=A1LbOoqwO-FSC4iOxbb__r0iN+v5FpgRA@mail.gmail.com> (raw)
In-Reply-To: <20200128161536.GL13686@intel.com>

On Tue, Jan 28, 2020 at 5:15 PM Ville Syrjälä
<ville.syrjala@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@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.

"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
_______________________________________________
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: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Allen Chen <allen.chen@ite.com.tw>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel <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 17:18:34 +0100	[thread overview]
Message-ID: <CAKMK7uGjtJOU_+Hv=A1LbOoqwO-FSC4iOxbb__r0iN+v5FpgRA@mail.gmail.com> (raw)
In-Reply-To: <20200128161536.GL13686@intel.com>

On Tue, Jan 28, 2020 at 5:15 PM Ville Syrjälä
<ville.syrjala@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@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.

"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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-01-28 16:18 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 20:02 [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] " Ville Syrjala
2020-01-24 20:02 ` [PATCH 2/8] drm/edid: Don't accept any old garbage as a display descriptor Ville Syrjala
2020-01-24 20:02   ` [Intel-gfx] " Ville Syrjala
2020-01-27 22:35   ` Alex Deucher
2020-01-27 22:35     ` [Intel-gfx] " Alex Deucher
2020-02-03 19:44     ` Shankar, Uma
2020-02-03 19:44       ` Shankar, Uma
2020-01-24 20:02 ` [PATCH 3/8] drm/edid: Introduce is_detailed_timing_descritor() Ville Syrjala
2020-01-24 20:02   ` [Intel-gfx] " Ville Syrjala
2020-01-27 22:36   ` Alex Deucher
2020-01-27 22:36     ` [Intel-gfx] " Alex Deucher
2020-02-03 19:49     ` Shankar, Uma
2020-02-03 19:49       ` Shankar, Uma
2020-01-24 20:02 ` [PATCH 4/8] drm/i915: Clear out spurious whitespace Ville Syrjala
2020-01-24 20:02   ` [Intel-gfx] " Ville Syrjala
2020-01-27 22:28   ` Alex Deucher
2020-01-27 22:28     ` [Intel-gfx] " Alex Deucher
2020-02-03 19:51     ` Shankar, Uma
2020-02-03 19:51       ` Shankar, Uma
2020-01-24 20:02 ` [PATCH 5/8] drm/edid: Document why we don't bounds check the DispID CEA block start/end Ville Syrjala
2020-01-24 20:02   ` [Intel-gfx] " Ville Syrjala
2020-01-27 22:30   ` Alex Deucher
2020-01-27 22:30     ` [Intel-gfx] " Alex Deucher
2020-01-28 11:44     ` Ville Syrjälä
2020-01-28 11:44       ` [Intel-gfx] " Ville Syrjälä
2020-02-03 19:58       ` Shankar, Uma
2020-02-03 19:58         ` [Intel-gfx] " Shankar, Uma
2020-01-24 20:02 ` [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA data block revision Ville Syrjala
2020-01-24 20:02   ` [Intel-gfx] " Ville Syrjala
2020-01-27 22:32   ` Alex Deucher
2020-01-27 22:32     ` [Intel-gfx] " Alex Deucher
2020-02-03 20:15   ` Shankar, Uma
2020-02-03 20:15     ` Shankar, Uma
2020-02-04 13:32     ` Ville Syrjälä
2020-02-04 13:32       ` Ville Syrjälä
2020-02-04 14:57       ` Shankar, Uma
2020-02-04 14:57         ` Shankar, Uma
2020-01-24 20:02 ` [PATCH 7/8] drm/edid: Constify lots of things Ville Syrjala
2020-01-24 20:02   ` [Intel-gfx] " Ville Syrjala
2020-01-27 22:38   ` Alex Deucher
2020-01-27 22:38     ` [Intel-gfx] " Alex Deucher
2020-01-28 11:49     ` Ville Syrjälä
2020-01-28 11:49       ` [Intel-gfx] " Ville Syrjälä
2020-02-03 20:34       ` Shankar, Uma
2020-02-03 20:34         ` Shankar, Uma
2020-01-24 20:02 ` [PATCH 8/8] drm/edid: Dump bogus 18 byte descriptors Ville Syrjala
2020-01-24 20:02   ` [Intel-gfx] " Ville Syrjala
2020-01-27 22:38   ` Alex Deucher
2020-01-27 22:38     ` [Intel-gfx] " Alex Deucher
2020-02-03 20:38     ` Shankar, Uma
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 ` [PATCH 1/8] " Alex Deucher
2020-01-27 22:34   ` [Intel-gfx] " Alex Deucher
2020-02-03 19:15   ` Shankar, Uma
2020-02-03 19:15     ` [Intel-gfx] " Shankar, Uma
2020-01-28 15:17 ` Daniel Vetter
2020-01-28 15:17   ` [Intel-gfx] " Daniel Vetter
2020-01-28 16:15   ` Ville Syrjälä
2020-01-28 16:15     ` [Intel-gfx] " Ville Syrjälä
2020-01-28 16:18     ` Daniel Vetter [this message]
2020-01-28 16:18       ` Daniel Vetter
2020-01-28 16:28       ` Ville Syrjälä
2020-01-28 16:28         ` [Intel-gfx] " 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='CAKMK7uGjtJOU_+Hv=A1LbOoqwO-FSC4iOxbb__r0iN+v5FpgRA@mail.gmail.com' \
    --to=daniel@ffwll.ch \
    --cc=allen.chen@ite.com.tw \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /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 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.