[lkml]   [2011]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 5/5] clk: export tree topology and clk data via sysfs
On Tue, Nov 22, 2011 at 11:01 AM, Mike Turquette <> wrote:
> On Tue, Nov 22, 2011 at 8:37 AM, Grant Likely <> wrote:
>> On Nov 21, 2011 6:43 PM, "Mike Turquette" <> wrote:
>>> Introduces kobject support for the common struct clk, exports per-clk
>>> data via read-only callbacks and models the clk tree topology in sysfs.
>>> Also adds support for generating the clk tree in clk_init and migrating
>>> nodes when input sources are switches in clk_set_parent.
>> I'm not convinced this is a good idea. What is the use case for exporting
>> the clock tree? If it is debug, then I suggest using debugfs to avoid abi
>> issues.
> Each clk exports clk_rate, clk_flags, clk_enable_count &
> clk_prepare_count as Read-Only.  I think this is very reasonable to
> have in sysfs, which maps the topology of the system with key details.
> Others have requested to have knobs made available for actually
> performing clk_enable/clk_disable and even clk_set_rate from
> userspace.  I hate this idea and won't implement it.  I encourage
> anyone that needs this to do it in debugfs.
> Does that work-split make sense to you, or do you still not like the
> idea of having topology and read-only info in sysfs?

Unless there is a solid real-world use case for exporting this data to
userspace, I do not think sysfs is a good idea. As long as the usage
(beyond debug) is theoretical I think the whole thing should be in
debugfs. It can always be moved at a later date If a real use case
does become important.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-11-22 20:31    [W:0.213 / U:6.544 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site