linux-kernel - Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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: <20121216121603.GA31780@avionic-0098.adnet.avionic-design.de>
Date:	Sun, 16 Dec 2012 13:16:03 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Terje Bergström <tbergstrom@...dia.com>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arto Merilainen <amerilainen@...dia.com>
Subject: Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

On Fri, Dec 14, 2012 at 09:59:11PM +0200, Terje Bergström wrote:
> On 14.12.2012 18:21, Stephen Warren wrote:
> > On 12/13/2012 11:09 PM, Terje Bergström wrote:
> >> They want to get the global data by getting drvdata of their parent.
> > 
> > There's no reason that /has/ to be so; they can get any information from
> > wherever it is, rather than trying to require it to be somewhere it isn't.
> 
> Exactly, this was also my solution.
> 
> >> The dummy device is not their parent - host1x is. There's no
> >> connection between the dummy and the real client devices.
> > 
> > It's quite possible for the client devices to ask their actual parent
> > (host1x) for the tegradrm struct device *, by calling a host1x API, and
> > have host1x implement that API by returning the dummy/virtual device
> > that it created. That should be just 1-2 lines of code to implement in
> > host1x, plus maybe a couple more to correctly return -EPROBE_DEFERRED
> > when appropriate.
> 
> My solution was to just have one global, and an getter for the global.
> Instead of drvdata, the pointer is retrieved with the getter. No need
> for dummy device, or passing points between host1x and tegradrm.

Okay, so we're back on the topic of using globals. I need to assert
again that this is not an option. If we were to use globals, then we
could just as well leave out the dummy device and just do all of that in
the tegra-drm driver's initialization function.

The whole point of all this is to link the host1x and it's particular
tegra-drm instance. I will see if I can find the time to implement this
in the existing driver, so that the host1x code that you want to remove
registers the tegra-drm dummy device and the tegra-drm devices use the
accessors as discussed previously to access host1x and the dummy device.
Once that is implemented, removing the original host1x implementation
should be much easier since you will only have to keep the dummy device
instantiation along with the one or two accessor functions.

Thierry

Content of type "application/pgp-signature" skipped