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] [day] [month] [year] [list]

Date:	Tue, 2 Jun 2009 10:48:11 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Holger Schurig <hs4233@...l.mn-solutions.de>
Cc:	linux-arm-kernel@...ts.arm.linux.org.uk,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Grant Likely <grant.likely@...retlab.ca>, timur@...escale.com,
	devicetree-discuss@...abs.org, linux-kernel@...r.kernel.org,
	scottwood@...escale.com, yuan-bo.ye@...orola.com,
	David Miller <davem@...emloft.net>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Tue, Jun 02, 2009 at 09:57:20AM +0200, Holger Schurig wrote:

> > 1. implementers of the clock API which have not been subject
> > to my rigorous review abuse it to the point of making the API
> > essentially useless, and that causes Mark problems.

> If that's a problem, when something needs changes. An API that 
> can only be managed by implementers due to rigorous review lacks 
> something, maybe easy-of-use, maybe documentation. Can it be the 
> case that the current state makes you a single-point of failure?

The problem is more that a lot of platform maintainers have treated the
clock API as being a bit of platform support code not intended to be
used by drivers, causing them to take lots of shortcuts when
implementing it that only work in their specific use cases - at times to
the point where it's not even possible to register new clocks.  Since
this means that the API is essentially unusable in generic driver code
you end up with nobody using it there and no back pressure other than
code review on maintainers to provide a good implementation.

> If yes, I'd at least suggest better docs in linux/Documentation, 
> e.g. describe the big-picture, the implementation and common 
> cave-ats, e.g. why an approach "uniquely name every single 
> clock ... makes the API pointless" doesn't work.

None of which means that better documentation wouldn't help, of course.
--
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/