Messages in this thread | | | Date | Mon, 13 May 2013 20:18:07 +0200 | From | Sebastian Hesselbarth <> | Subject | Re: [PATCH RFC] clk: Introduce userspace clock driver |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |