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:	Wed, 27 Mar 2013 13:10:23 +0200
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Tony Prisk <linux@...sktech.co.nz>
CC:	<linux-fbdev@...r.kernel.org>, <florianschandinat@....de>,
	<vt8500-wm8505-linux-kernel@...glegroups.com>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 6/6] video: fb: vt8500: Convert framebuffer drivers to
 standardized binding

Hi,

On 2013-03-27 10:47, Tony Prisk wrote:
> Now that a display timing binding is available, convert our almost identical
> binding to use the standard binding.
> 
> This patch converts the vt8500 and wm8505 framebuffer drivers and
> associated dts/dtsi files to use the standard binding as defined in
> bindings/video/display-timing.txt.
> 
> There are two side-effects of making this conversion:
> 
> 1) The fb node should now be in the board file, rather than the soc file as
> the display-timing node is a child of the fb node.
> 
> 2) We still require a bits per pixel property to initialize the framebuffer
> for the different lcd panels. Rather than including this as part of the
> display timing, it is moved into the framebuffer node.
> 
> I have also taken the opportunity to alphabetise the includes of each
> driver to avoid double-ups.

I don't think this is correct. I don't have that much experience with
DT, but I think you should have, for example:

wm8850.dtsi:

	fb: fb@...51700 {
		compatible = "wm,wm8505-fb";
		reg = <0xd8051700 0x200>;
	};

wm8850-w70v2.dts:

&fb {
	bits-per-pixel = <16>;

	display-timings {
		native-mode = <&timing0>;
		timing0: 800x480 {
			clock-frequency = <0>;
			...
		};
	};
};

So, the core fb part should be in the SoC's file, as it's part of the
SoC. And the stuff that tells what kind of display is attached is in the
board dts file.

Also, just a word of warning, I think the videomode series I've sent for
review will cause some breakage with this series if the videomode series
is accepted. Nothing difficult to fix, though, but we'll need some extra
management to avoid compilation failures.

 Tomi



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ