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

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:	Thu, 4 Aug 2016 17:34:08 +0200
From:	Luc Verhaegen <libv@...net.be>
To:	Noralf Trønnes <noralf@...nnes.org>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 0/2] drm: add SimpleDRM driver

On Thu, Aug 04, 2016 at 05:08:43PM +0200, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 04:15:25PM +0200, Luc Verhaegen wrote:
> > On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
> > > 
> > > I have tested simpledrm on a Raspberry Pi B+ with U-boot setting up the
> > > framebuffer and producing this node:
> > > 
> > >         framebuffer@...87000 {
> > >                 compatible = "simple-framebuffer";
> > >                 reg = <0x1e887000 0x36c600>;
> > >                 format = "r5g6b5";
> > >                 width = <1824>;
> > >                 height = <984>;
> > >                 stride = <3648>;
> > >                 status = "okay";
> > >         };
> > > 
> > > I have only tested with fbcon and modetest (XR24,RG16).
> > 
> > Please do not make the same mistake as simplefb in making this purely a 
> > rpifb. Know that you will need some power and clock management for 
> > properly free devices that do not depend on a binary only RTOS which 
> > does _everything_ behind our backs.
> > 
> > Cfr this useless, endless and ridiculous discussion: 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279071.html
> 
> simpledrm isn't a real driver, but only meant to be used to drive the
> firmware framebuffer in early boot until a real driver takes over. It's a
> replacement really for all the various uefi/vesa/whatever fbdev drivers.
> Full reliance on the firmware very much intended.
> -Daniel

In the sunxi case, that firmware was u-boot, and the clocks were 
properly declared and then also properly disabled, which meant the 
display block got disabled.

Is simpledrm only an intermediate solution until the real driver is 
loaded? What stops it from providing a rudimentary display driver for 
the whole uptime of the machine? What stops the kernel from disabling 
the clocks while the supposed real driver is not fully loaded yet?

Do we really want to recreate a 400+ email thread again, or are we 
capable of learning from the past?

Luc Verhaegen.