[PATCH] clk: define and export __clk_get_debug for providers

Define and export a new function __clk_get_debug which returns the debugfs
directory entry pointer. This can be used by clock providers to add debugfs
entries which are not related to a specific clock type. Examples include the
ability to measure the rate of a clock. It can also be used by modules to
create new debugfs entries. This is useful if you want to expose features
for testing which can potentially cause system instability such as allowing
to change a clock's rate from userspace.

Signed-off-by: Peter De Schrijver <redacted>
---
 drivers/clk/clk.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8b73ede..5fe7942 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c

@@ -652,6 +652,15 @@ unsigned long __clk_get_flags(struct clk *clk)
 }
 EXPORT_SYMBOL_GPL(__clk_get_flags);
 
+struct dentry *__clk_get_dentry(struct clk *clk)
+{
+	if (!clk)
+		return NULL;
+
+	return clk->dentry;
+}
+EXPORT_SYMBOL_GPL(__clk_get_dentry);
+
 bool __clk_is_prepared(struct clk *clk)
 {
 	int ret;

-- 
1.7.7.rc0.72.g4b5ea.dirty

On Wednesday 25 June 2014 19:26:31 Peter De Schrijver wrote:

Define and export a new function __clk_get_debug which returns the debugfs
directory entry pointer. This can be used by clock providers to add debugfs
entries which are not related to a specific clock type. Examples include the
ability to measure the rate of a clock. It can also be used by modules to
create new debugfs entries. This is useful if you want to expose features
for testing which can potentially cause system instability such as allowing
to change a clock's rate from userspace.

Signed-off-by: Peter De Schrijver <redacted>

Just an idea, but would it be better to add a pair of functions to add/remove
debugfs files rather than exposing the dentry itself?

	Arnd

Quoting Arnd Bergmann (2014-06-25 11:07:37)

On Wednesday 25 June 2014 19:26:31 Peter De Schrijver wrote:

quoted

Define and export a new function __clk_get_debug which returns the debugfs
directory entry pointer. This can be used by clock providers to add debugfs
entries which are not related to a specific clock type. Examples include the
ability to measure the rate of a clock. It can also be used by modules to
create new debugfs entries. This is useful if you want to expose features
for testing which can potentially cause system instability such as allowing
to change a clock's rate from userspace.

Signed-off-by: Peter De Schrijver <redacted>

Just an idea, but would it be better to add a pair of functions to add/remove
debugfs files rather than exposing the dentry itself?

Arnd,

Yes, accessor functions are much better than exposing struct clk
internals.

Peter,

Just FYI, I'm trying to reverse the trend of prepending double
underscores for functions that are used by clock providers. That stuff
started out small and sort of grew out of control ;-)

Regards,
Mike

        Arnd

On 25 June 2014 20:23, Mike Turquette [off-list ref] wrote:

Peter,

Just FYI, I'm trying to reverse the trend of prepending double
underscores for functions that are used by clock providers. That stuff
started out small and sort of grew out of control ;-)

I'm looking at rebasing Rabin's patches for per-user clks, and I have
had to add a few variants for providers, so they can be called with
clk_core instead. Have been prepending underscores for those internal
variants, but in some cases I had to also append a _internal suffix
because there were already variants without locking.

What convention were you thinking of for distinguishing provider-only
variants for e.g. clk_set_rate?

Regards,

Tomeu

On Wed, Jun 25, 2014 at 08:23:49PM +0200, Mike Turquette wrote:

Quoting Arnd Bergmann (2014-06-25 11:07:37)

quoted

On Wednesday 25 June 2014 19:26:31 Peter De Schrijver wrote:

quoted

Define and export a new function __clk_get_debug which returns the debugfs
directory entry pointer. This can be used by clock providers to add debugfs
entries which are not related to a specific clock type. Examples include the
ability to measure the rate of a clock. It can also be used by modules to
create new debugfs entries. This is useful if you want to expose features
for testing which can potentially cause system instability such as allowing
to change a clock's rate from userspace.

Signed-off-by: Peter De Schrijver <redacted>

Just an idea, but would it be better to add a pair of functions to add/remove
debugfs files rather than exposing the dentry itself?

Arnd,

Yes, accessor functions are much better than exposing struct clk
internals.

Peter,

Just FYI, I'm trying to reverse the trend of prepending double
underscores for functions that are used by clock providers. That stuff
started out small and sort of grew out of control ;-)

Ah. I was just following the existing pattern here :)

Cheers,

Peter.

On Wed, Jun 25, 2014 at 08:07:37PM +0200, Arnd Bergmann wrote:

On Wednesday 25 June 2014 19:26:31 Peter De Schrijver wrote:

quoted

Define and export a new function __clk_get_debug which returns the debugfs
directory entry pointer. This can be used by clock providers to add debugfs
entries which are not related to a specific clock type. Examples include the
ability to measure the rate of a clock. It can also be used by modules to
create new debugfs entries. This is useful if you want to expose features
for testing which can potentially cause system instability such as allowing
to change a clock's rate from userspace.

Signed-off-by: Peter De Schrijver <redacted>

Just an idea, but would it be better to add a pair of functions to add/remove
debugfs files rather than exposing the dentry itself?

Ok. Will do that.

Cheers,

Peter.

On Thu, Jun 26, 2014 at 12:37 AM, Tomeu Vizoso
[off-list ref] wrote:

On 25 June 2014 20:23, Mike Turquette [off-list ref] wrote:

quoted

Peter,

Just FYI, I'm trying to reverse the trend of prepending double
underscores for functions that are used by clock providers. That stuff
started out small and sort of grew out of control ;-)

I'm looking at rebasing Rabin's patches for per-user clks, and I have
had to add a few variants for providers, so they can be called with
clk_core instead. Have been prepending underscores for those internal
variants, but in some cases I had to also append a _internal suffix
because there were already variants without locking.

What convention were you thinking of for distinguishing provider-only
variants for e.g. clk_set_rate?

Hmm. Now we need a convention. Damn. ;-)

I'm open to suggestions. I think prepending a single underscore makes
great sense for a lock-free inner function. And some number of
underscores (1 or 2) makes sense for static functions not exposed to
clock providers. I kind of like using 2 underscores for the static
functions so that it is easier to differentiate them.

For any new functions you create with unique names that are exposed to
clock providers, do not prepend any underscore at all. It's just
another public function in clk-provider.h.

If any taste makers out there have suggestions I am happy to listen.

Regards,
Mike

Regards,

Tomeu