Subject: [PATCH RFC] clk: Introduce userspace clock driver

From: [email-masked] (Sebastian Hesselbarth)
Date: Mon, 13 May 2013 20:18:07 +0200

On 05/13/13 19:58, S?ren Brinkmann wrote:
> On Mon, May 13, 2013 at 07:37:23PM +0200, Sebastian Hesselbarth wrote:
>> It is, as it will only expose clocks on Zynq and that's what Mark and
>> Mike are worried about. Expose clocks to user space and you will have
>> people mess with it for sure.
> Well, even if you contain it in that driver you can still mess with
> other clocks. Just give it the "wrong" input clock references in DT and
> you are free to control them. As I said before, there is no protection
> against such misuse.

Put the wrong clock in DT is not "misuse" but "bug" ;) More important,
it is quite static as you cannot change it easily by echo'ing into some
sysfs file. And to inject a DT you need access on boot loader level,
not kernel user space (yet).

>> About the shape of it, I didn't expect that to change at all. Just
>> wondering, if it still requires you to manually end it's endianess
>> mess with the bitfiles. If you go at it, consider reading the magic
>> hidden in the bitfile and swap it when it is required. But that will
>> go OT here.
> It still takes byteswapped, binary images as input, unfortunately.

Please, if you ever mainline any kernel driver for it, make it
auto-swap.

>> If you don't want to merge both drivers, have a Zynq-only clock
>> fabric driver instead?
> That was my original intention. But due to the nature of it, it will
> always be possible to use it with other clocks too. Hence my generic
> approach.

I already tried a generic "expose clocks to user space" and failed for
the very same reasons Mike and Mark are repeating over and over again -
and I agree with them.

> I actually like the idea of making it part of the device config driver.
> The downside of it is, that this driver seems a bit far from mainline.

Have a skeleton driver that exposes Zynq clocks first and implement
device config later? IIRC, device config isn't that complicated to
implement. Unfortunately, interpreting Xilinx datasheets or source code
is.

Sebastian