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:	Sat, 30 May 2009 19:52:46 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	timur@...escale.com, devicetree-discuss@...abs.org,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, scottwood@...escale.com,
	yuan-bo.ye@...orola.com, David Miller <davem@...emloft.net>,
	rmk@....linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

> Sure.  My only big concern with it is that it compeltely sidesteps
> clocking decisions so there's a lot of codecs it's not going to be
> immediately useful with and I don't have a clear idea how it could be
> extended to be so.  Most other things look like they can be added on
> fairly easily when required.

Regarding clocks ...

Paulus and I had a discussion the other day and he mentioned a very good
idea to represent the clock net in the device-tree.

Basically, do it just like the interrupts.

IE. A device would have a "clocks" property that contain a certain
amount of cells representing a clock source in a clock provider, itself
identified by a "clock-parent" property (default to the actual node
parent). Clock providers would have a #clock-cells to provide the number
of cells a in the "clocks" property for each clock source.

Actually, we could be a little bit smarter since clocks are more messy
than interrupts, and define "clocks" to be a serie of clock-parent
phandle and clock id within that parent. The clock id size is still
represented by the #clock-cells of the clock parent, but we avoid the
pitfall of the interrupt routing that makes it hard to connect to
multiple different PICs.

That would provide the routing, without actual values or capabilities of
each clock, that's orthogonal. But that would allow driver to easily
find their clock "provider" and we could thus provide some simple
infrastructure to register drivers or handlers to perform actions on
those clocks, such as refcounting users, etc...

It may also be useful to define properties in the clock controllers
themselves mapping clock IDs to actual frequencies or things like that
but I'm only half convinced here. IE. Let's start by defining the
-wiring- and leave the -values- (on,off, slewing, freq adjustement,
spreading) to an API between drivers and clock providers for now.

Maybe later with experience with can find good ways to extend the
device-tree representiation to provide actual clock settings and/or
tables.

Cheers,
Ben.

--
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/