Re: [PATCH 0/3] drm: Basic mode sanity checks

From: Daniel Vetter <daniel@ffwll.ch>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/3] drm: Basic mode sanity checks
Date: Wed, 17 Dec 2014 18:30:12 +0100	[thread overview]
Message-ID: <20141217173012.GY2711@phenom.ffwll.local> (raw)
In-Reply-To: <CADnq5_NxzryO34GFgXYnkAtMFLDr49E+Ve5BLdY3MMi2p_2Knw@mail.gmail.com>

On Wed, Dec 17, 2014 at 12:09:47PM -0500, Alex Deucher wrote:
> On Wed, Dec 17, 2014 at 6:56 AM,  <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > We had a bug in i915 land recently where X passed in a zeroed mode with
> > mode_valid=1 to setcrtc. That didn't go down so well and caused a
> > div-by-zero in i915.
> >
> > For a long time I've been thinking that we need some real checks to
> > validate the modes we feed into the hardware. I started to sketch out
> > something for that but it quickly turned into a bit of a nightmare
> > with the whole panel fitter, stereo 3D, SDVO etc. special cases we
> > have in i915.
> >
> > So I gave up on that for now, and instead cooked up this small series
> > to add some basic sanity checks to the mode validation, and also apply
> > the same sanity checks to user provided modes. This is enough to
> > prevent the div-by-zero in i915 with buggy X.
> >
> > The risk is that we start to reject some modes that more or less worked
> > by accident before. Given how lax we've been in handling the panel fitter
> > on i915 for instance, this could be a real problem if people have been
> > useing custom modes that have been filled out only partially. But I'm
> > hoping the number of users doing that is so small that we can risk it.
> >
> > The other concern is drivers which might also provide funky modes from
> > their .get_modes(). I tried to look at all the drivers a bit, and most
> > produce modes via EDID, CVT, DMT, or drm_display_mode_from_videomode().
> > All of those look safe, except mode->clock might be an issue with
> > drm_display_mode_from_videomode(), but hopefully there's some kind of
> > clock provided in most cases. I didn't dig through all the nooks and
> > crannies in all drivers though, so may have missed something.
> 
> For the series:
> 
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

All pulled into my drm misc branch.

Thanks, 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
http://lists.freedesktop.org/mailman/listinfo/dri-devel