linux-kernel - Re: [RFC] [PATCH] Device Tree on ARM platform

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 May 2009 23:47:21 +0400
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	Scott Wood <scottwood@...escale.com>,
	Peter Korsgaard <jacmet@...site.dk>,
	Robert Schwebel <r.schwebel@...gutronix.de>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	Timur Tabi <timur@...escale.com>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

Hello.

Russell King wrote:

>>>smc91x is a prime example of the kind of information drivers need - base
>>>address and irq are very much insufficient to describe how this device is
>>>connected.  There's much more information required to specify this device
>>>fully, and throwing it into the driver doesn't work.  We've been there
>>>and proven that point.

>>The device tree is quite capable of expressing information beyond  
>>addresses and interrupts.

> Bus width?  Register offset spacing?  SMC LED configuration?  Whether
> to use the hardware wait signal from the SMC?

    Yes, it's perefectly capable of all that. In fact, the first two items 
have already been defined for MTD and serial devices (though I wasn't happy 
about how the 2nd item was done IIRC).

> If you're going to say yes to all that, I'm going to start asking how
> you cope with verifying that the data for ethernet driver A doesn't
> get accidentally used for ethernet driver B.

    It's incorporated into the device node corresponding to Ethernet device 
A, which driver B doesn't drive.

> I assume you have some kind of compiler, which needs a set of specification
> files to tell it what's required for each driver which is OF compatible.

    The compiler is called (surprise :-) 'dtc'.

> If not, I can see no way for OF trees to ever be safe and correct.

WBR, Sergei
--
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/