Re: [PATCH] clk: add DT test clock consumer driver

From: Mike Turquette
Date: Mon Mar 18 2013 - 21:54:35 EST

Quoting Arnd Bergmann (2013-03-16 07:56:54)
> On Saturday 16 March 2013, Sebastian Hesselbarth wrote:
> > This driver adds a DT test clock consumer that exposes debugfs files to
> > enable/disable and set/get rate of the attached programmable clock.
> > During development of a i2c-attached clock generator I found it useful
> > to debug the clock generator's internal pll settings by enforcing clock
> > rates through debugfs.
> >
> > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@xxxxxxxxx>
> It sounds a little clumsy to have a device driver to match a device that
> you create just for matching the driver.
> Would it be possible to separate the debugging logic from the platform
> device logic? I think it may be useful to have a debugfs or sysfs
> inteface for all clocks in the system, even if that is disabled by
> default or only available after manually loading a module implementing
> that functionality.

I agree that a generic approach is needed here. I have been meaning to
break the existing debugfs stuff out into clk-debug.c. I'll do that
soon and maybe you can add a new Kconfig entry for
COMMON_CLK_DEBUG_USERSPACE (or something like that) which implements

On the other hand this sort of stuff really scares me. I know for a
fact that a debug interface to enable/disable clocks and set clock rate
would ship on real devices. Quite likely some android phones out there
would be controlling hardware clocks from some horrible userspace


Sebastian, another small nitpick, can you change the "enable" attribute
to be named "prepare_enable"? This more accurately reflects what is
going on.

I also wonder how simple it would be to add a "parent" attribute here
that allows one to call clk_set_parent from the debugfs interface? To
make it easy on you, the interface could accept an integer as the index
of the clk->parents[] array. This is a bad interface design as it
requires the user to look into the code to know which index corresponds
to which parent clock; however I do not want people to use this
interface for anything other than debug/testing, so I am ok with this
interface being a PITA to use.


> Arnd
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at