linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC] clk: Introduce userspace clock driver
Date: Mon, 13 May 2013 20:18:07 +0200	[thread overview]
Message-ID: <51912E5F.9090401@gmail.com> (raw)
In-Reply-To: <af51c63e-7ff1-4e73-9305-08309217ab38@TX2EHSMHS037.ehs.local>

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

  reply	other threads:[~2013-05-13 18:18 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-10 17:31 [PATCH RFC] User space clock driver Soren Brinkmann
2013-05-10 17:31 ` [PATCH RFC] clk: Introduce userspace " Soren Brinkmann
2013-05-10 17:44   ` Emilio López
2013-05-10 18:15     ` Sören Brinkmann
2013-05-10 18:49       ` Emilio López
2013-05-10 22:18         ` Mike Turquette
2013-05-10 23:01           ` Saravana Kannan
2013-05-10 23:06             ` Sören Brinkmann
2013-05-10 23:25               ` Saravana Kannan
2013-05-10 23:36                 ` Sören Brinkmann
2013-05-11 14:21             ` Mark Brown
2013-05-16  4:23               ` Saravana Kannan
2013-05-16 18:21                 ` Mark Brown
2013-05-10 23:08           ` Sören Brinkmann
2013-05-13  8:31           ` Peter De Schrijver
     [not found]   ` <CAHp75Vcr10d=XesGQvrC_v+ijdp3nK+m=w5E7d6GCo1Z9ogWnw@mail.gmail.com>
2013-05-10 18:03     ` Sören Brinkmann
2013-05-10 21:24   ` Mark Brown
2013-05-11 16:54     ` Sören Brinkmann
2013-05-12 14:33       ` Mark Brown
2013-05-12 19:05         ` Sören Brinkmann
2013-05-13  5:21           ` Mark Brown
2013-05-13 16:09             ` Sören Brinkmann
2013-05-13 16:21               ` Sebastian Hesselbarth
2013-05-13 17:24                 ` Sören Brinkmann
2013-05-13 17:37                   ` Sebastian Hesselbarth
2013-05-13 17:58                     ` Sören Brinkmann
2013-05-13 18:18                       ` Sebastian Hesselbarth [this message]
2013-05-14 16:46                       ` Mike Turquette
2013-05-14 18:09                         ` Philip Balister
2013-05-15  4:46                           ` Mark Brown
2013-05-16  4:28                             ` Saravana Kannan
2013-05-16 14:44                               ` Philip Balister
2013-05-16 17:26                                 ` Mark Brown
2013-05-16 18:55                                   ` Sören Brinkmann
2013-05-17 11:02                                     ` Mark Brown
2013-05-13 18:16                 ` Mark Brown
2013-05-13 18:20                   ` Sebastian Hesselbarth
2013-05-13 18:44                     ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51912E5F.9090401@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).