On Tue, Nov 22, 2011 at 11:01 AM, Mike Turquette <mturquette@xxxxxxxxxx> wrote: > On Tue, Nov 22, 2011 at 8:37 AM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: >> >> On Nov 21, 2011 6:43 PM, "Mike Turquette" <mturquette@xxxxxx> 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. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
