linux-kernel - Re: [PATCH 5/6] clk: Support multiple instances of the same clock provider

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: <20110711093439.GB3239@n2100.arm.linux.org.uk>
Date:	Mon, 11 Jul 2011 10:34:39 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Grant Likely <grant@...retlab.ca>, linux-sh@...r.kernel.org,
	patches@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 5/6] clk: Support multiple instances of the same clock
	provider

On Mon, Jul 11, 2011 at 11:53:56AM +0900, Mark Brown wrote:
> Currently the generic clk API identifies clocks internally using the name
> of the clock. This is OK for on-SoC clocks where we have enough control to
> disambiguate but doesn't work well for clocks provided on external chips
> where a system design may include more than one instance of the same chip
> (the Wolfson Speyside system is an example of this) or may have namespace
> collisions.
> 
> Address this by allowing the clock provider to supply a struct device for
> the clock for use in disambiguation. As a first pass if it is provided we
> prefix the clock name with the dev_name() of the device. With a device
> tree binding for clocks it should be possible to remove this mangling and
> instead use the struct device to provide access to the binding information.
> 
> In order to avoid needless noise in names and memory usage it is strongly
> recommended that on-SoC clocks do not provide a struct device until the
> implementation is improved.
> 
> Signed-off-by: Mark Brown <broonie@...nsource.wolfsonmicro.com>
> ---
>  drivers/clk/clk.c   |   36 ++++++++++++++++++++++++++++++++----
>  include/linux/clk.h |   14 ++++++++++----
>  2 files changed, 42 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 1df6e23..f36f637 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -13,6 +13,7 @@
>  #include <linux/mutex.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
> +#include <linux/device.h>
>  
>  struct clk {
>  	const char		*name;
> @@ -252,20 +253,44 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>  }
>  EXPORT_SYMBOL_GPL(clk_set_parent);
>  
> -struct clk *clk_register(const struct clk_hw_ops *ops, struct clk_hw *hw,
> -		const char *name)
> +struct clk *clk_register(struct device *dev, const struct clk_hw_ops *ops,
> +			 struct clk_hw *hw, const char *name)
>  {
>  	struct clk *clk;
> +	char *new_name;
> +	size_t name_len;
>  
>  	clk = kzalloc(sizeof(*clk), GFP_KERNEL);
>  	if (!clk)
>  		return NULL;
>  
> -	clk->name = name;
>  	clk->ops = ops;
>  	clk->hw = hw;
>  	hw->clk = clk;
>  
> +	/* Since we currently match clock providers on a purely string
> +	 * based method add a prefix based on the device name if a
> +	 * device is provided.  When we have support for device tree
> +	 * based clock matching it should be possible to avoid this
> +	 * mangling and instead use the struct device to hook into
> +	 * the bindings.
> +	 *
> +	 * As we don't currently support unregistering clocks we don't
> +	 * need to worry about cleanup as yet.
> +	 */
> +	if (dev) {
> +		name_len = strlen(name) + strlen(dev_name(dev)) + 2;
> +		new_name = kzalloc(name_len, GFP_KERNEL);
> +		if (!new_name)
> +			goto err;
> +
> +		snprintf(new_name, name_len, "%s-%s", dev_name(dev), name);
> +
> +		clk->name = new_name;
> +	} else {
> +		clk->name = name;
> +	}

This "clk consolidation" is really idiotic.  The clk matching mechanism
should have _nothing_ to do with the rest of the clk API, especially the
consolidation effort.

It should not matter whether clkdev is used, or an alternative method
to specify this stuff via DT.  Keep the clk_get()/clk_put() _separate_
from the consolidation of the rest.
--
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/