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, 12 Feb 2015 17:58:40 +0100
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Noralf Trønnes <noralf@...nnes.org>
Cc:	Thomas Niederprüm <niederp@...sik.uni-kl.de>,
	linux-fbdev@...r.kernel.org, plagnioj@...osoft.com,
	tomi.valkeinen@...com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/8] fbdev: ssd1307fb: Unify init code and make
 controller configurable from device tree

On Sat, Feb 07, 2015 at 04:19:37PM +0100, Noralf Trønnes wrote:
> >>and the DT itself should not contain any direct mapping of the
> >>registers.
> >>
> >I think I don't get what you mean here. Is it because I do no sanity
> >checks of the numbers set in DT? I was just looking for a way to hand
> >over the information about the wiring of display to the driver. How
> >would you propose to solve this?
> 
> I have the exact same challenge with the staging/fbtft drivers.
> I have asked about this on the DT list a couple of days ago, but no answer
> yet:
> 
> Can I do register initialization from Device Tree?
> http://www.spinics.net/lists/devicetree/msg68174.html

The DT is just an hardware representation, and should not contain any
logic. Any attempts at doing so have been failures, mostly because
that kind of construct are really fragile.

What would happen if at some point some new controller pops up and
need to poke a GPIO before every write?

Every driver should contain all the needed code to initialise properly
its hardware. The only exception being stuff that are volatile by
essence, like bus addresses, GPIOs, etc.

In your case, using (and maybe extending) the generic panel bindings
look like a better way forward.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ