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

[Sebastian Hesselbarth]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/