linux-kernel - Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap

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]

Message-ID: <50A128AF.1010803@wwwdotorg.org>
Date:	Mon, 12 Nov 2012 09:49:51 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <robherring2@...il.com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Scott Wood <scottwood@...escale.com>,
	Tony Lindgren <tony@...mide.com>,
	Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>, Russ Dill <Russ.Dill@...com>,
	linux-omap@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices
 to mach-omap2)

On 11/12/2012 04:23 AM, Pantelis Antoniou wrote:
> Hi Grant,
> 
> Sorry for the late comments, travelling...
> 
> On Nov 9, 2012, at 6:28 PM, Grant Likely wrote:
...
>> *with the caveat that not all types of changes are a good idea and we
>> may disallow. For example, is changing properties in existing nodes a
>> good idea?
> 
> Yes, changing properties is something that we need. One such change is
> the change of the bus controller 'status' properties to enabled upon
> insertion of a child device node, and change back to 'on-demand' when
> all the child device nodes are gone.

Do we actually need to do that?

>From the base-board perspective, consider an SoC's I2C channel that is
routed to the child board connector. The routing to the connector is
always present on the base board. Only the presence (or lack thereof) of
devices on that I2C bus is influenced by whether a child board is
connected or not, and the design of the child board. Therefore, wouldn't
it make sense for the base board to always enable the I2C controller?

That would make it easier for someone to hook up a couple wires to the
I2C pins and use utilities such as i2cget/set to communicate with it,
without going through the whole process of creating a DT to represent
the device. This could speed up simple hacking/prototyping and allow it
to proceed in a less structured way.
--
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/