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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 May 2009 22:55:58 +1000
From:	David Gibson <david@...son.dropbear.id.au>
To:	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	devicetree-discuss@...abs.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Thu, May 28, 2009 at 10:48:17PM +1000, David Gibson wrote:
> On Thu, May 28, 2009 at 12:17:32PM +0000, Dmitry Eremin-Solenikov wrote:
> > David Miller wrote:
> > 
> > > From: Russell King - ARM Linux
> > > <linux@....linux.org.uk> Date: Thu, 28 May 2009
> > > 10:15:13 +0100
> > > 
> > >> For example, how would an IrDA transceiver be expressed in OF?
> > > 
> > > As a child device node of the IRDA device, with associated properties.
> > > 
> > > You can express _ANYTHING_ using the OF device tree.  It is not even
> > > something to discuss, it's flexible enough.
> > 
> > Hmmm. How to express the following situation:
> > On one of my platforms (sharp tosa) the backlight controller
> > is separated into two parts: one sitting on SPI, one on the I2C.
> > The tricky part is that the I2C part is only available when some
> > of registers of SPI part are programmed in a specific way.
> 
> Put nodes under both the SPI and I2C busses, they have properties with
> phandles to refer to each other (could be one way or both depending on
> needs).  Sprinkle with any additional information properties as
> necessary.  Your driver (in the broad sense, rather than the "struct
> device_driver" sense) binds both devices and does what it needs to do.
> 
> The I2C part should possibly have a status property with value
> "disabled" to indicate that it's not usable, until something activates
> it (in this case the other part of the driver frobbing the SPI side).

I should add, that's only one way, though it is the most obvious to me
from the information you've given.  Depending on the details of the
device other possibilities might be appropriate.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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/