linux-kernel - Re: [PATCH 0/2] drm: add SimpleDRM driver

Open Source and information security mailing list archives

Message-ID: <20160804171023.GT6232@phenom.ffwll.local>
Date:	Thu, 4 Aug 2016 19:10:24 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Luc Verhaegen <libv@...net.be>
Cc:	David Herrmann <dh.herrmann@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH 0/2] drm: add SimpleDRM driver

On Thu, Aug 04, 2016 at 05:59:42PM +0200, Luc Verhaegen wrote:
> On Thu, Aug 04, 2016 at 05:44:23PM +0200, David Herrmann wrote:
> > On Thu, Aug 4, 2016 at 5:34 PM, Luc Verhaegen <libv@...net.be> wrote:
> > > Do we really want to recreate a 400+ email thread again, or are we
> > > capable of learning from the past?
> > 
> > No we don't. And no-one intends to. I am fully aware of the discussion
> > that introduced the clock-dependencies to simplefb, and I gladly
> > accept patches that add such support to SimpleDRM. Did anyone say
> > otherwise? This series adds initial support for the devices _we_ know
> > and can test (which is x86 and RPi, in my case). If someone wants
> > support for more devices, please send patches. Why does this have to
> > be included (or even discussed) as part of this submission?
> 
> You're right, it does not have to be included until there is a usecase.
> 
> But on the otherhand i have become pretty allergic to this as that other 
> discussion was completely useless and pointless and stemmed only from 
> the fact that people had been kidding themselves all along that simplefb 
> was going to be simple and not would need anything extra.
> 
> If we can avoid fooling ourselves to the same extent as we did before, 
> then putting this off until there is a real usecase is perfectly fine by 
> me.
> 
> If not, just add this trivial generic addition straight from an existing 
> example. 

I stand corrected on this, seems indeed we need this to avoid issues. I
guess on x86 we don't need this since a pci device is a mostly
well-defined entity, and as long as we stop vesa/uefi for simpledrm before
the real driver loads it'll be all fine.

But on arm it's indeed different with clocks (and I guess sooner or later
some power domains too, or whatever else really). I think as long as it
doesn't go beyond "grab resource on load, drop it again on unload" I'm
prefectly fine with adding all that's needed to simpledrmfb. And totally
up to the folks enabling this whether it should be there upfront or only
once needed for a given platform.
-Daniel

> 
> Luc Verhaegen.
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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