linux-kernel - Re: [PATCH] drm/panel: Remove the get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Jul 2016 14:37:37 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Eric Anholt <eric@...olt.net>
Cc:	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	David Airlie <airlied@...ux.ie>
Subject: Re: [PATCH] drm/panel: Remove the get_timings() function.

On Wed, Jun 01, 2016 at 12:18:01PM -0700, Eric Anholt wrote:
> It appears to have no callers.
> 
> Signed-off-by: Eric Anholt <eric@...olt.net>
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 18 ------------------
>  include/drm/drm_panel.h              |  4 ----
>  2 files changed, 22 deletions(-)

Looks like I never replied to this, though I remember at least making up
the reply in my head.

The reason why I'd like to keep this is that it's technically the right
interface for display drivers to use. It was introduced in order to fix
some of the short-comings of ->get_modes(), though it seems like there
simply hasn't been a need so far for drivers to do this.

The problem with ->get_modes() is that it gives you a fixed mode for
most panels. However, a mode that works on one display controller does
not necessarily work on another (typical reasons could be extra limits
imposed on porches by the display controller).

Timings are supposed to solve this by allowing the video timings to be
specified in triplets of (minimum, maximum, typical) values for each of
the parameters (much like the tables you see in panel datasheets) and
make it possible for drivers to make up a valid mode from those ranges.
This makes the panel more widely useful.

At least that's the theory, but, like I said, in practice nobody seems
to be needing this currently.

Bottom line, I think we'll be needing this down the road eventually, so
keeping it around will avoid unnecessary churn.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)