linux-kernel - Re: [PATCH 1/2] UIO: add device clock support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aec7e5c30906260128q7c39648dg8b549bb322cf7d57@mail.gmail.com>
Date:	Fri, 26 Jun 2009 17:28:22 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	Paul Mundt <lethal@...ux-sh.org>,
	Magnus Damm <magnus.damm@...il.com>, Greg KH <gregkh@...e.de>,
	Daniel Mack <daniel@...aq.de>, linux-kernel@...r.kernel.org,
	hjk@...utronix.de
Subject: Re: [PATCH 1/2] UIO: add device clock support

On Fri, Jun 26, 2009 at 2:47 AM, Paul Mundt<lethal@...ux-sh.org> wrote:
> On Fri, Jun 26, 2009 at 12:17:03AM +0900, Magnus Damm wrote:
>> On Thu, Jun 25, 2009 at 3:41 AM, Paul Mundt<lethal@...ux-sh.org> wrote:
>> > On Wed, Jun 24, 2009 at 09:34:14AM -0700, Greg KH wrote:
>> >> On Wed, Jun 24, 2009 at 05:30:24PM +0200, Daniel Mack wrote:
>> >> > Add a pointer to a 'struct clk' to uio_info. Drivers can set
>> >> > this pointer if a clock is needed, and the UIO core will care
>> >> > to enable and disable it upon device open and release.
>> >>
>> >> Do you have a UIO driver that needs this?
>> >>
>> >> If so, please submit it at the same time, otherwise adding
>> >> infrastructure for no driver that needs it, is pretty pointless.
>> >>
>> > We can use this for the uio_pdrv_genirq case on sh, but open/release is a
>> > bit coarse grained. Presently we default-enable clocks for devices that
>> > are handled through uio, so doing it at open/release is at least better
>> > than that. The other thing to consider is if we really want to add a
>> > HAVE_CLK depdendency outright, or just ifdef around it..
>>
>> Yeah, we export quite a few UIO devices on SuperH, and
>> stopping/starting clocks is on my TODO list.
>>
>> Like Paul says, open/release only is a bit coarse grained. I'd like to
>> be able to keep the device open in user space, having a bunch of
>> memory windows mmap()ed but still being able to power down the
>> hardware block somehow.
>>
>> The patch seems to be about enabling and disabling clocks, the actual
>> clock frequency is not really exposed to user space what I can tell. I
>> was more thinking along the lines of having an array of clocks per uio
>> device - pretty much like the memory windows - and just expose the
>> clocks and their frequencies to user space and letting user space
>> enable and disable using sysfs.
>>
> This is longer term work that still needs to be discussed and agreed
> upon, which is totally out of scope for this patch. Doing it at
> open/close time is already better than what we have today, so I am
> inclined to roll this patch in to a topic branch and convert the existing
> sh users over to it. Any improvement with regards to making it more fine
> grained, or deciding what to expose to userspace, is something to look at
> much later, particularly as the runtime pm code is going to be a
> prerequisite for a lot of it (ie, 2.6.33).

Performing clk_enable()/clk_disable() at open()/close() time sounds
good, but we probably also want to extend the uio_pdrv_genirq driver
to do clk_get()/clk_put() at probe()/remove() time well.

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/