This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}_noirq()
for handling suspend/resume of cpufreq governors.

Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found anr issue where
tunables configuration for clusters/sockets with non-boot CPUs was
getting lost after suspend/resume, as we were notifying governors
with CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that
policy and so deallocating memory for tunables. This is fixed by
this patch as we don't allow any operation on governors after
device suspend and before device resume now.
Reported-and-tested-by: NLan Tianyu <tianyu.lan@intel.com>
Reported-by: NJinhyuk Choi <jinchoi@broadcom.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog, minor cleanups]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The init functions are linked statically (no support for
dynamic loading) and have no other users. Hence remove
EXPORT_SYMBOL for these functions.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

d4019f0a "cpufreq: move freq change notifications to cpufreq core"
added code to the cpufreq core to print an error if a cpufreq driver's
.target() function returned an error. This exposed the fact that Tegra's
cpufreq driver returns an error when it is ignoring requests due to the
system being suspended.

Modify Tegra's .target() function not to return an error in this case;
this prevents the error prints. The argument is that since the suspend
hook can't and doesn't inform the cpufreq core when its requests will
be ignored, there's no way for the cpufreq core to squelch them, so it's
not an error for the requests to keep coming. This change make the Tegra
driver consistent with how the Exynos handles the same situation. Note
that s5pv210-cpufreq.c probably suffers from this same issue though.

Fixes: d4019f0a (cpufreq: move freq change notifications to cpufreq core)
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The related code has been changed and the comment is out of date.
So remove it.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

With a recent change "d4019f0a cpufreq: move freq change notifications to cpufreq
core" few variables (r & ret) are removed by mistake and hence these warnings:

drivers/cpufreq/omap-cpufreq.c: In function omap_target:
drivers/cpufreq/omap-cpufreq.c:64:2: error: ret undeclared (first use in this function)
drivers/cpufreq/omap-cpufreq.c:64:2: note: each undeclared identifier is reported only once for each function it appears in
drivers/cpufreq/omap-cpufreq.c:94:3: error: r undeclared (first use in this function)
drivers/cpufreq/omap-cpufreq.c:116:1: warning: control reaches end of non-void function [-Wreturn-type]

Lets fix them by declaring those variables again.

Fixes: d4019f0a (cpufreq: move freq change notifications to cpufreq core)
Reported-by: NSebastian Capella <sebastian.capella@linaro.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When requested_freq is over policy->max, set it to policy->max.
This can help to speed up decreasing frequency.
Signed-off-by: NXiaoguang Chen <chenxg@marvell.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When decreasing frequency, requested_freq may be less than
freq_target, So requested_freq minus freq_target may be negative,
But reqested_freq's unit is unsigned int, then the negative result
will be one larger interger which may be even higher than
requested_freq.

This patch is to fix such issue. when result becomes negative,
set requested_freq as the min value of policy.
Signed-off-by: NXiaoguang Chen <chenxg@marvell.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Do not load the Intel pstate driver if the platform firmware
(ACPI BIOS) supports the power management alternatives.
The ACPI BIOS indicates that the OS control mode can be used
if the _PSS (Performance Supported States) is defined in ACPI
table. For the OS control mode, the Intel pstate driver will be
loaded.

HP BIOS has several power management modes (firmware, OS-control and
so on). For the OS control mode in HP BIOS, the Intel p-state driver
will be loaded. When the customer chooses the firmware power
management in HP BIOS, the Intel p-state driver will be ignored.

I put hw_vendor_info vendor_info in case other vendors (Dell, Lenovo...)
have their firmware power management. Vendors should make sure their
firmware power management works properly, and they can go for adding
their vendor info to the variable.

I have verified the patch on HP ProLiant servers.  The patch worked
correctly.
Signed-off-by: NAdrian Huang <adrianhuang0701@gmail.com>
[rjw: Fixed up !CONFIG_ACPI build]
[Linda Knippers: As Adrian has recently left HP, I retested the
updated patch on an HP ProLiant server and verified that it is
behaving correctly.  When the BIOS is configured for OS control for
power management, the intel_pstate driver loads as expected.  When
the BIOS is configured to provide the power management, the
intel_pstate driver does not load and we get the pcc_cpufreq driver
instead.]
Signed-off-by: NLinda Knippers <linda.knippers@hp.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

After commit dfa5bb62 (cpufreq: ondemand: Change the calculation
of target frequency), this return statement is no longer needed.
Reported-by: NHenrik Nilsson <Karl.Henrik.Nilsson@gmail.com>
Signed-off-by: NStratos Karafotis <stratosk@semaphore.gr>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Most of the drivers do following in their ->target_index() routines:

	struct cpufreq_freqs freqs;
	freqs.old = old freq...
	freqs.new = new freq...

	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);

	/* Change rate here */

	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);

This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.

There are few special cases though, like exynos5440, which doesn't do everything
on the call to ->target_index() routine and call some kind of bottom halves for
doing this work, work/tasklet/etc..

They may continue doing notification from their own code as flag:
CPUFREQ_ASYNC_NOTIFICATION is already set for them.

All drivers are also modified in this patch to avoid breaking 'git bisect', as
double notification would happen otherwise.
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRussell King <linux@arm.linux.org.uk>
Acked-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There are few special cases like exynos5440 which doesn't send POSTCHANGE
notification from their ->target() routine and call some kind of bottom halves
for doing this work, work/tasklet/etc.. From which they finally send POSTCHANGE
notification.

Its better if we distinguish them from other cpufreq drivers in some way so that
core can handle them specially. So this patch introduces another flag:
CPUFREQ_ASYNC_NOTIFICATION, which will be set by such drivers.

This also changes exynos5440-cpufreq.c and powernow-k8 in order to set this
flag.
Acked-by: NAmit Daniel Kachhap <amit.daniel@samsung.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Fixes warnings reported by kbuild test robot

sparse warnings: (new ones prefixed by >>)

drivers/cpufreq/intel_pstate.c:729:6: sparse: symbol 'copy_pid_params' was not declared. Should it be static?
drivers/cpufreq/intel_pstate.c:739:6: sparse: symbol 'copy_cpu_funcs' was not declared. Should it be static?
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The b.L switcher can be turned on/off at run time.  It is therefore
necessary to change the cpufreq driver behavior accordingly.

The driver must be unregistered/registered with the cpufreq core
to reconfigure freq tables for the virtual or actual CPUs. This is
accomplished via the b.L switcher notifier callback.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch adds IKS (In Kernel Switcher) support to cpufreq driver.

This creates a combined freq table for A7-A15 CPU pairs. A7 frequencies
are virtualized and scaled down to half the actual frequencies to
approximate a linear scale across the combined A7+A15 range. When the
requested frequency change crosses the A7-A15 boundary a cluster switch
is invoked.

Based on earlier work from Sudeep KarkadaNagesha.
Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch adds vexpress-spc platform device to enables the vexpress
SPC cpufreq interface driver.
Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Acked-by: NPawel Moll <Pawel.Moll@arm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The TC2(i.e. CA15_A7) Versatile Express has external Cortex M3 based
power controller which is responsible for CPU DVFS and SPC provides
the interface for the same.

This patch adds a tiny interface driver to check if OPPs are
initialised by SPC platform code and register the arm_big_little
cpufreq driver.
Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On TC2, the cpu clocks are controlled by the external M3 microcontroller
and SPC provides the interface between the CPU and the power controller.

The generic cpufreq drivers use the clock APIs to get the cpu clocks.
This patch add virtual spc clocks for all the cpus to control the cpu
operating frequency via the clock framework.
Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NPawel Moll <Pawel.Moll@arm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

SPC(Serial Power Controller) on TC2 also controls the CPU performance
operating points which is essential to provide CPU DVFS. The M3
microcontroller provides two sets of eight performance values, one set
for each cluster (CA15 or CA7). Each of this value contains the
frequency(kHz) and voltage(mV) at that performance level. It expects
these performance level to be passed through the SPC PERF_LVL registers.

This patch adds support to populate these performance levels from M3,
build the mapping to CPU OPPs at the boot and then use it to get and
set the CPU performance level runtime.
Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NPawel Moll <Pawel.Moll@arm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We have per-CPU cpu_policy_rwsem for cpufreq core, but we never use
all of them. We always use rwsem of policy->cpu and so we can
actually make this rwsem per policy instead.

This patch does this change. With this change other tricky situations
are also avoided now, like which lock to take while we are changing
policy->cpu, etc.
Suggested-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add support for the Baytrail processor.
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Non-core processors have a different MSR layout to commumicate P state
information. Refactor the driver to use CPU dependent accessors to
P state information.
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently, the prototype of cpufreq_drivers target routines is:

int target(struct cpufreq_policy *policy, unsigned int target_freq,
		unsigned int relation);

And most of the drivers call cpufreq_frequency_table_target() to get a valid
index of their frequency table which is closest to the target_freq. And they
don't use target_freq and relation after that.

So, it makes sense to just do this work in cpufreq core before calling
cpufreq_frequency_table_target() and simply pass index instead. But this can be
done only with drivers which expose their frequency table with cpufreq core. For
others we need to stick with the old prototype of target() until those drivers
are converted to expose frequency tables.

This patch implements the new light weight prototype for target_index() routine.
It looks like this:

int target_index(struct cpufreq_policy *policy, unsigned int index);

CPUFreq core will call cpufreq_frequency_table_target() before calling this
routine and pass index to it. Because CPUFreq core now requires to call routines
present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.

This also marks target() interface as deprecated. So, that new drivers avoid
using it. And Documentation is updated accordingly.

It also converts existing .target() to newly defined light weight
.target_index() routine for many driver.
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRussell King <linux@arm.linux.org.uk>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rjw@rjwysocki.net>

Conflicts:
	drivers/cpufreq/omap-cpufreq.c

Since Operating Performance Points (OPP) functions are specific
to device specific power management, be specific and rename opp.h
to pm_opp.h
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since Operating Performance Points (OPP) data structures are specific
to device specific power management, be specific and rename opp_* data
structures in OPP library with dev_pm_opp_* equivalent.

Affected structures are:
 struct opp
 enum opp_event

Minor checkpatch warning resulting of this change was fixed as well.
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since Operating Performance Points (OPP) functions are specific to
device specific power management, be specific and rename opp_*
accessors in OPP library with dev_pm_opp_* equivalent.

Affected functions are:
 opp_get_voltage
 opp_get_freq
 opp_get_opp_count
 opp_find_freq_exact
 opp_find_freq_floor
 opp_find_freq_ceil
 opp_add
 opp_enable
 opp_disable
 opp_get_notifier
 opp_init_cpufreq_table
 opp_free_cpufreq_table
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull btrfs fix from Chris Mason:
 "Sage hit a deadlock with ceph on btrfs, and Josef tracked it down to a
  regression in our initial rc1 pull.  When doing nocow writes we were
  sometimes starting a transaction with locks held"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: release path before starting transaction in can_nocow_extent

Pull ACPI and power management fixes from Rafael Wysocki:

 - intel_pstate fix for misbehavior after system resume if sysfs
   attributes are set in a specific way before the corresponding suspend
   from Dirk Brandewie.

 - A recent intel_pstate fix has no effect if unsigned long is 32-bit,
   so fix it up to cover that case as well.

 - The s3c64xx cpufreq driver was not updated when the index field of
   struct cpufreq_frequency_table was replaced with driver_data, so
   update it now.  From Charles Keepax.

 - The Kconfig help text for ACPI_BUTTON still refers to
   /proc/acpi/event that has been dropped recently, so modify it to
   remove that reference.  From Krzysztof Mazur.

 - A Lan Tianyu's change adds a missing mutex unlock to an error code
   path in acpi_resume_power_resources().

 - Some code related to ACPI power resources, whose very purpose is
   questionable to put it lightly, turns out to cause problems to happen
   during testing on real systems, so remove it completely (we may
   revisit that in the future if there's a compelling enough reason).
   From Rafael J Wysocki and Aaron Lu.

* tag 'pm+acpi-3.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / PM: Drop two functions that are not used any more
  ATA / ACPI: remove power dependent device handling
  cpufreq: s3c64xx: Rename index to driver_data
  ACPI / power: Drop automaitc resume of power resource dependent devices
  intel_pstate: Fix type mismatch warning
  cpufreq / intel_pstate: Fix max_perf_pct on resume
  ACPI: remove /proc/acpi/event from ACPI_BUTTON help
  ACPI / power: Release resource_lock after acpi_power_get_state() return error

Pull x86 fixes from Ingo Molnar:
 "Two fixlets:

   - fix a (rare-config) build bug
   - fix a next-gen SGI/UV hw/firmware enumeration bug"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86: Update UV3 hub revision ID
  x86/microcode: Correct Kconfig dependencies

We can't be holding tree locks while we try to start a transaction, we will
deadlock.  Thanks,
Reported-by: NSage Weil <sage@inktank.com>
Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
Signed-off-by: NChris Mason <chris.mason@fusionio.com>

* acpi-fixes:
  ACPI / PM: Drop two functions that are not used any more
  ATA / ACPI: remove power dependent device handling
  ACPI / power: Drop automaitc resume of power resource dependent devices
  ACPI: remove /proc/acpi/event from ACPI_BUTTON help
  ACPI / power: Release resource_lock after acpi_power_get_state() return error

* pm-fixes:
  cpufreq: s3c64xx: Rename index to driver_data
  intel_pstate: Fix type mismatch warning
  cpufreq / intel_pstate: Fix max_perf_pct on resume

Pull CIFS fixes from Steve French:
 "Five small cifs fixes (includes fixes for: unmount hang, 2 security
  related, symlink, large file writes)"

* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: ntstatus_to_dos_map[] is not terminated
  cifs: Allow LANMAN auth method for servers supporting unencapsulated authentication methods
  cifs: Fix inability to write files >2GB to SMB2/3 shares
  cifs: Avoid umount hangs with smb2 when server is unresponsive
  do not treat non-symlink reparse points as valid symlinks

cpufreq_set_policy() has been changed to origin __cpufreq_set_policy()
and policy->lock has been converted to rewrite lock by commit 5a01f2.
So remove the comment.
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Merge tag 'driver-core-3.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core fix from Greg KH:
 "Here is one fix for the hotplug memory path that resolves a regression
  when removing memory that showed up in 3.12-rc1"

* tag 'driver-core-3.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  driver core: Release device_hotplug_lock when store_mem_state returns EINVAL

Pull USB fixes from Greg KH:
 "Here are some USB fixes and new device ids for 3.12-rc6

  The largest change here is a bunch of new device ids for the option
  USB serial driver for new Huawei devices.  Other than that, just some
  small bug fixes for issues that people have reported (run-time and
  build-time), nothing major"

* tag 'usb-3.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  usb: usb_phy_gen: refine conditional declaration of usb_nop_xceiv_register
  usb: misc: usb3503: Fix compile error due to incorrect regmap depedency
  usb/chipidea: fix oops on memory allocation failure
  usb-storage: add quirk for mandatory READ_CAPACITY_16
  usb: serial: option: blacklist Olivetti Olicard200
  USB: quirks: add touchscreen that is dazzeled by remote wakeup
  Revert "usb: musb: gadget: fix otg active status flag"
  USB: quirks.c: add one device that cannot deal with suspension
  USB: serial: option: add support for Inovia SEW858 device
  USB: serial: ti_usb_3410_5052: add Abbott strip port ID to combined table as well.
  USB: support new huawei devices in option.c
  usb: musb: start musb on the udc side, too
  xhci: Fix spurious wakeups after S5 on Haswell
  xhci: fix write to USB3_PSSEN and XUSB2PRM pci config registers
  xhci: quirk for extra long delay for S4
  xhci: Don't enable/disable RWE on bus suspend/resume.

Pull serial driver fixes from Greg KH:
 "Here are two serial driver fixes for your tree.  One is a revert of a
  patch that causes a build error, the other is a fix to provide the
  correct brace placement which resolves a bug where the driver was not
  working properly"

* tag 'tty-3.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  serial: vt8500: add missing braces
  Revert "serial: i.MX: evaluate linux,stdout-path property"

Pull char/misc driver fixes from Greg KH:
 "Here are some small iio and w1 driver fixes for 3.12-rc6.

  There is also a hyper-v fix in here, which turned out to be incorrect,
  so it was reverted.  That will probably have to wait unto 3.13-rc1 to
  get accepted as it's still being discussed"

* tag 'char-misc-3.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  Revert "Drivers: hv: vmbus: Fix a bug in channel rescind code"
  Drivers: hv: vmbus: Fix a bug in channel rescind code
  iio:buffer: Free active scan mask in iio_disable_all_buffers()
  iio: frequency: adf4350: add missing clk_disable_unprepare() on error in adf4350_probe()
  w1 - call request_module with w1 master mutex unlocked
  w1 - fix fops in w1_bus_notify

Pull sound fixes from Takashi Iwai:
 "All reasonably small fixes as rc6: a HD-audio mic fix, a us122l mmap
  regression fix, and kernel memory leak fix in hdsp driver.  Hopefully
  this will be the last pull request for 3.12..."

* tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hdsp - info leak in snd_hdsp_hwdep_ioctl()
  ALSA: us122l: Fix pcm_usb_stream mmapping regression
  ALSA: hda - Fix inverted internal mic not indicated on some machines