linux-kernel - Re: [PATCH 01/36] clk: Introduce clk_try

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]

Message-ID: <20150121151210.GC22884@ulmo.nvidia.com>
Date:	Wed, 21 Jan 2015 16:12:13 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Rob Clark <robdclark@...il.com>
Cc:	Mike Turquette <mturquette@...aro.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Stephen Boyd <sboyd@...eaurora.org>
Subject: Re: [PATCH 01/36] clk: Introduce clk_try_parent()

On Tue, Jan 20, 2015 at 01:16:16PM -0500, Rob Clark wrote:
> On Tue, Jan 20, 2015 at 1:02 PM, Mike Turquette <mturquette@...aro.org> wrote:
> > Quoting Thierry Reding (2015-01-20 02:48:20)
> >> From: Thierry Reding <treding@...dia.com>
> >>
> >> This new function is similar to clk_set_parent(), except that it doesn't
> >> actually change the parent. It merely checks that the given parent clock
> >> can be a parent for the given clock.
> >>
> >> A situation where this is useful is to check that a particular setup is
> >> valid before switching to it. One specific use-case for this is atomic
> >> modesetting in the DRM framework where setting a mode is divided into a
> >> check phase where a given configuration is validated before applying
> >> changes to the hardware.
> >
> > Can you describe why this was needed for your atomic modesetting work?
> > What problem did you hit in the driver that required this new check?
> 
> In particular, for an async atomic update, we need to do everything
> that may potentially fail up front before returning to userspace.
> Additionally there is a 'testonly' flag so that userspace can ask if a
> particular display configuration is possible.

One specific use-case where this is needed is if we want to set a mode
but halfway through the modeset we find out that we can't actually set
it, then we need to somehow rollback the changes, or be stuck with a
mode that doesn't work.

Splitting this into two separate stages allows all the checks to be
performed before making any changes to the hardware. The current mode
will remain active until the changes are committed. Therefore rollback
of a partial modeset is not required.

Thierry

Content of type "application/pgp-signature" skipped