2009-06-02 07:57:18

by Holger Schurig

[permalink] [raw]
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

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

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.


2009-06-02 09:48:19

by Mark Brown

[permalink] [raw]
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.