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  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]
Date:	Sun, 19 May 2013 20:43:31 +0200
From:	Francesco Lavra <francescolavra.fl@...il.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
CC:	rjw@...k.pl, robin.randhawa@....com, linux-pm@...r.kernel.org,
	patches@...aro.org, Liviu.Dudau@....com,
	linux-kernel@...r.kernel.org, cpufreq@...r.kernel.org,
	linaro-kernel@...ts.linaro.org, Steve.Bannister@....com,
	arvind.chauhan@....com, charles.garcia-tobin@....com
Subject: Re: [PATCH 2/2] cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq
 directory

Hi,

On 05/17/2013 01:26 PM, Viresh Kumar wrote:
> When we don't have any file in cpu/cpufreq directory we shouldn't create it.
> Specially with the introduction of per-policy governor instance patchset, even
> governors are moved to cpu/cpu*/cpufreq/governor-name directory and so this
> directory is just not required.
> 
> Lets have it only when required.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> ---
[...]
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index e3d7112..2e18b3d 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -678,9 +678,6 @@ static struct attribute *default_attrs[] = {
>  	NULL
>  };
>  
> -struct kobject *cpufreq_global_kobject;
> -EXPORT_SYMBOL(cpufreq_global_kobject);
> -
>  #define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
>  #define to_attr(a) container_of(a, struct freq_attr, attr)
>  
> @@ -751,6 +748,49 @@ static struct kobj_type ktype_cpufreq = {
>  	.release	= cpufreq_sysfs_release,
>  };
>  
> +struct kobject *cpufreq_global_kobject;
> +EXPORT_SYMBOL(cpufreq_global_kobject);
> +
> +static int cpufreq_global_kobject_usage;
> +
> +int get_cpufreq_global_kobject(void)
> +{
> +	if (!cpufreq_global_kobject_usage++)
> +		return kobject_add(cpufreq_global_kobject,
> +				&cpu_subsys.dev_root->kobj, "%s", "cpufreq");
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(get_cpufreq_global_kobject);
> +
> +void put_cpufreq_global_kobject(void)
> +{
> +	if (!--cpufreq_global_kobject_usage)
> +		kobject_del(cpufreq_global_kobject);
> +}
> +EXPORT_SYMBOL(put_cpufreq_global_kobject);

Global symbol names should begin with a sensible prefix; in this case,
it looks like cpufreq_get_global_kobject and cpufreq_put_global_kobject
would be more appropriate names.

Regards,
Francesco
--
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/

Powered by blists - more mailing lists