linux-kernel - Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)

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, 3 Feb 2014 12:25:00 +0100
From:	David Herrmann <dh.herrmann@...il.com>
To:	Alexandre Courbot <acourbot@...dia.com>
Cc:	Ben Skeggs <bskeggs@...hat.com>, nouveau@...ts.freedesktop.org,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Eric Brower <ebrower@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-tegra@...r.kernel.org,
	Terje Bergstrom <tbergstrom@...dia.com>,
	Ken Adams <KAdams@...dia.com>
Subject: Re: [RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)

Hi

[..snip..]
> Finally, support for probing GK20A is added in the last 2 patches. It should be
> noted that contrary to what Nouveau currently expects, GK20A does not embed any
> display hardware (that part being handled by tegradrm). So this driver should
> really be only used through DRM render-nodes and collaborate with the display
> driver using PRIME. I have not yet figured out how to turn GK20A's instantiation
> of Nouveau into a render-node only driver without breaking support for existing
> desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which we
> should try to get rid of.

You cannot get rid of cardX currently. It is implied by DRIVER_MODESET
and that flag should actually be called NOT_A_LEGACY_DRIVER. So you
cannot remove it. I did try to replace DRIVER_MODESET by an inverted
DRIVER_LEGACY flag some time ago, but I thought it's not worth it.

Anyhow, you can easily add a new flag to make
drm_dev_register()/drm_dev_alloc() not create the drm_minor for
DRM_MINOR_LEGACY, which would prevent the card0 node from showing up.
But people started using the cardX interface as base interface so mesa
might not be able to open render-nodes if the related card-node is not
available (which is a bug in their code, so no reason to support that
by not adding stand-alone render-nodes).

Long story short: If you want to do it properly, just add a flag to
DRM core that prevents DRM_MINOR_LEGACY from showing up. If you just
want it to work, simply keep a dummy card0.

Thanks
David
--
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/