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: <50D34775.5010606@wwwdotorg.org>
Date:	Thu, 20 Dec 2012 10:14:29 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Terje Bergström <tbergstrom@...dia.com>
CC:	Thierry Reding <thierry.reding@...onic-design.de>,
	"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 12/20/2012 02:17 AM, Terje Bergström wrote:
> On 16.12.2012 14:16, Thierry Reding wrote:
>> 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.
> 
> I found a way of dropping the global in a straightforward way, and
> introduce dummy device for drm_platform_init().
> 
> I added dummy device and driver, and moved the tegradrm global
> (previously called struct host1x *host1x) allocation to happen in the
> probe. In addition, probe calls device tree node traversal to do the
> tegra_drm_add_client() calls. The dummy device is owner for this global.
> 
> I changed the device tree node traversal so that it goes actually
> through each host1x child, checks if it's supported by tegradrm, and if
> so, sets its drvdata to point to the tegradrm data.

I'm not sure that sounds right. drvdata is something that a driver
should manage itself.

What's wrong with just having each device ask the host1x (its parent)
for a pointer to the (dummy) tegradrm device. That seems extremely
simple, and doesn't require abusing existing stuff like drvdata for
non-standard purposes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/