thermal: cpu_cooling: Pass variable instead of its type to sizeof()

Just following coding guidelines here.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: no need to set cpufreq_state to zero

Its already zero, we allocated cpufreq_dev with kzalloc.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: no need to set cpufreq_dev to NULL

It will be overwritten soon with return value of kzalloc().

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: no need to initialze 'ret'

ret is initialized before it is used, so no need to set it to 0 in its declaration.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: propagate error returned by idr_alloc()

We aren't supposed to return our own error type here. Return what we got.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: Don't match min/max frequencies for all CPUs on cooling register

In __cpufreq_cooling_register() we try to match min/max frequencies for all CPUs
passed in 'clip_cpus' mask. This mask is the cpumask of cpus where the frequency
constraints will be applied.

Same frequency constraint can be applied only to the CPUs belonging to the same
cluster (i.e. CPUs sharing clock line). For all such CPUs we have a single
'struct cpufreq_policy' structure managing them and so getting policies for all
CPUs wouldn't make any sense as they will all return the same pointer.

So, remove this useless check of checking min/max for all CPUs. Also update doc
comment to make this more obvious that clip_cpus should be same as
policy->related_cpus.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: don't iterate over all allowed_cpus to update cpufreq policy

All CPUs present in 'allowed_cpus' share the same 'struct cpufreq_policy'
structure and so calling cpufreq_update_policy() for each of them doesn't make
sense.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: Don't check is_cpufreq_valid()

Because get_cpu_frequency() has returned a valid frequency, it means that the
cpufreq policy is surely valid and so no point checking that again with
is_cpufreq_valid(). Get rid of the routine as well as there are no more users.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: do error handling at the bottom in __cpufreq_cooling_register()

This makes life easy and bug free. And is scalable for future resource
allocations.

Acked-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: initialize 'cpufreq_val' on registration

There is no point checking for validity of 'cpufreq_val' from
cpufreq_thermal_notifier() every time the routine is called. Its guaranteed to
be 0 on the first call but will be valid otherwise.

Lets update it once while the device registers.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Merge branch 'brcm/stb-smp-uart' into next/drivers

This resolves a nonobvious merge conflict that I got wrong the
first time.

* brcm/stb-smp-uart:
  bus: brcmstb_gisb: save and restore GISB timeout
  bus: brcmstb_gisb: register the fault code hook
  ARM: brcmstb: Kconfig: drop unneeded symbol selections
  ARM: brcmstb: reintroduce SMP support
  ARM: brcmstb: add debug UART for earlyprintk support

Conflicts:
	drivers/bus/brcmstb_gisb.c

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Merge branch 'for-linus' into next
Merge branch 'at91/cleanup5' into next/drivers

The at91 cleanups changed a lot of files, this merges in the
latest cleanups to resolve the conflicts

Conflicts:
	arch/arm/mach-at91/at91sam9260.c
	arch/arm/mach-at91/at91sam9261.c
	arch/arm/mach-at91/at91sam9263.c
	arch/arm/mach-at91/clock.c
	arch/arm/mach-at91/clock.h
	drivers/rtc/Kconfig

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
workqueue: invert the order between pool->lock and wq_mayday_lock

Currently, pool->lock nests inside pool->lock.  There's no inherent
reason for this order.  The only place where the two locks are held
together is pool_mayday_timeout() and it just got decided that way.

This nesting order turns out to complicate things with the planned
rescuer_thread() update.  Let's invert them.  This doesn't cause any
behavior differences.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Dongsu Park <dongsu.park@profitbricks.com>
workqueue: allow rescuer thread to do more work.

When there is serious memory pressure, all workers in a pool could be
blocked, and a new thread cannot be created because it requires memory
allocation.

In this situation a WQ_MEM_RECLAIM workqueue will wake up the
rescuer thread to do some work.

The rescuer will only handle requests that are already on ->worklist.
If max_requests is 1, that means it will handle a single request.

The rescuer will be woken again in 100ms to handle another max_requests
requests.

I've seen a machine (running a 3.0 based "enterprise" kernel) with
thousands of requests queued for xfslogd, which has a max_requests of
1, and is needed for retiring all 'xfs' write requests.  When one of
the worker pools gets into this state, it progresses extremely slowly
and possibly never recovers (only waited an hour or two).

With this patch we leave a pool_workqueue on mayday list
until it is clearly no longer in need of assistance.  This allows
all requests to be handled in a timely fashion.

We keep each pool_workqueue on the mayday list until
need_to_create_worker() is false, and no work for this workqueue is
found in the pool.

I have tested this in combination with a (hackish) patch which forces
all work items to be handled by the rescuer thread.  In that context
it significantly improves performance.  A similar patch for a 3.0
kernel significantly improved performance on a heavy work load.

Thanks to Jan Kara for some design ideas, and to Dongsu Park for
some comments and testing.

tj: Inverted the lock order between wq_mayday_lock and pool->lock with
    a preceding patch and simplified this patch.  Added comment and
    updated changelog accordingly.  Dongsu spotted missing get_pwq()
    in the simplified code.

Cc: Dongsu Park <dongsu.park@profitbricks.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
thermal: cpu_cooling: Merge cpufreq_apply_cooling() into cpufreq_set_cur_state()

cpufreq_apply_cooling() has a single caller, cpufreq_set_cur_state() and
cpufreq_set_cur_state() is an unnecessary wrapper over cpufreq_apply_cooling().

Get rid of it by merging both routines.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: remove unnecessary wrapper get_cpu_frequency()

get_cpu_frequency() isn't doing much by itself, just calling get_property(). And
so this wrapper isn't required at all. Get rid of it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: find max level during device registration

CPU frequency tables don't update after the driver is registered and so we don't
need to iterate over them to find total number of states every time
cpufreq_get_max_state() is called. Do it once at boot time.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: get_property() doesn't need to support GET_MAXL anymore

We don't use get_property() to find max levels anymore as it is done at boot
now. So, don't support GET_MAXL in get_property().

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal: cpu_cooling: use cpufreq_dev_list instead of cpufreq_dev_count

As we already have a list of cpufreq_cooling_devices now, lets use it instead of
a local counter.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>