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]
Message-ID: <20090528125558.GC4565@yookeroo.seuss>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ