linux-kernel - Re: [PATCH v3 5/5] clk: export tree topology and clk data via sysfs

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACxGe6vK-vHvSbd9N2k3FZY4gGVS_DETx0BbfPgNghTkOncjpg@mail.gmail.com>
Date:	Tue, 22 Nov 2011 12:19:51 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Mike Turquette <mturquette@...aro.org>
Cc:	Mike Turquette <mturquette@...com>,
	broonie@...nsource.wolfsonmicro.com, sboyd@...cinc.com,
	eric.miao@...aro.org, linaro-dev@...ts.linaro.org,
	linux-omap@...r.kernel.org, arnd.bergmann@...aro.org,
	jeremy.kerr@...onical.com, dsaxena@...aro.org,
	shawn.guo@...escale.com, linus.walleij@...ricsson.com,
	skannan@...cinc.com, richard.zhao@...aro.org,
	linux-arm-kernel@...ts.infradead.org, tglx@...utronix.de,
	aul@...an.com, linux@....linux.org.uk, magnus.damm@...il.com,
	linux-kernel@...r.kernel.org, amit.kucheria@...aro.org,
	patches@...aro.org
Subject: Re: [PATCH v3 5/5] clk: export tree topology and clk data via sysfs

On Tue, Nov 22, 2011 at 11:01 AM, Mike Turquette <mturquette@...aro.org> wrote:
> On Tue, Nov 22, 2011 at 8:37 AM, Grant Likely <grant.likely@...retlab.ca> wrote:
>>
>> On Nov 21, 2011 6:43 PM, "Mike Turquette" <mturquette@...com> 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-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/