When enabling a device' wakeup capability, a wakeup source
is created for the device automatically. But the wakeup source
is not unregistered when disabling the device' wakeup capability.
This results in zombie wakeup sources, after devices/drivers are unregistered.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
'cma: Remove potential deadlock situation' introduces per cma area mutex
for bitmap management. It is good, but there is one mistake. When we
can't find appropriate area in bitmap, we release cma_mutex global lock
rather than cma->lock and this is a bug. So fix it.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
dev_set_drvdata and dev_get_drvdata are now simple enough again that
we can inline them as they used to be before commit b40284378.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no point in calling dev_get_drvdata without a valid device.
So checking for dev == NULL is pointless. If such a check is ever
needed - which I doubt - the driver should do it before calling
dev_get_drvdata.
We were returning NULL if dev was NULL, which the caller certainly did
not expect anyway, so that was only delaying the crash if the caller
is not paying attention.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dev_set_drvdata can no longer fail, so it could return void.
All callers have hopefully been updated to no longer check for the
return value.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Having to allocate memory as part of dev_set_drvdata() is a problem
because that memory may never get freed if the device itself is not
created. So move driver_data back to struct device.
This is a partial revert of commit b4028437.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We don't have any protection against addition of duplicate OPPs currently and in
case some code tries to add them, it will end up corrupting OPP tables.
We need to handle some duplication cases separately as returning error might not
be the right thing always. The new list of return values for dev_pm_opp_add()
are:
0: On success OR
Duplicate OPPs (both freq and volt are same) and opp->available
-EEXIST: Freq are same and volt are different OR
Duplicate OPPs (both freq and volt are same) and !opp->available
-ENOMEM: Memory allocation failure
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Chander Kashyap <k.chander@samsung.com>
Signed-off-by: Inderpal Singh <inderpal.s@samsung.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 932580409a
"regmap: mmio: Add support for 1/2/8 bytes wide register address."
broke regmap_mmio_write for uneven counts, for example 32-bit register
addresses with no padding and 8-byte values (count = 5).
Fix this by allowing all counts large enough to include some value.
This check was BUG_ON(count < 4) before the last change.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Since we cannot make sure the 'chip->num_regs' will always be none zero
from the users, and then if 'chip->num_regs' equals to zero by mistake
or other reasons, the kzalloc() will return ZERO_SIZE_PTR, which equals
to ((void *)16).
So this patch fix this with just checking the 'chip->num_regs' before
calling kzalloc().
This also sorts the header files in alphabetical order at the same time.
Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
devm_get_free_pages() and devm_free_pages() are the managed counterparts
for __get_free_pages() and free_pages().
Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit 9ec36cafe4
"of/irq: do irq resolution in platform_get_irq" from Rob Herring -
moves resolving of the interrupt resources in platform_get_irq().
But this solution isn't complete because platform_get_irq_byname()
need to be modified the same way.
Hence, fix it by adding interrupt resolution code at the
platform_get_irq_byname() function too.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <robh@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
This resolves the conflicts in the files:
drivers/iio/adc/Kconfig
drivers/staging/rtl8723au/os_dep/usb_ops_linux.c
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dma_declare_coherent_memory() takes two addresses for a region of memory: a
"bus_addr" and a "device_addr". I think the intent is that "bus_addr" is
the physical address a *CPU* would use to access the region, and
"device_addr" is the bus address the *device* would use to address the
region.
Rename "bus_addr" to "phys_addr" and change its type to phys_addr_t.
Most callers already supply a phys_addr_t for this argument. The others
supply a 32-bit integer (a constant, unsigned int, or __u32) and need no
change.
Use "unsigned long", not phys_addr_t, to hold PFNs.
No functional change (this could theoretically fix a truncation in a config
with 32-bit dma_addr_t and 64-bit phys_addr_t, but I don't think there are
any such cases involving this code).
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: James Bottomley <jbottomley@Parallels.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
CMA locking is currently very coarse. The cma_mutex protects both
the bitmap and avoids concurrency with alloc_contig_range. There
are several situations which may result in a deadlock on the CMA
mutex currently, mostly involving AB/BA situations with alloc and
free. Fix this issue by protecting the bitmap with a mutex per CMA
region and use the existing mutex for protecting against concurrency
with alloc_contig_range.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
CPUFreq specific helper functions for OPP (Operating Performance Points)
now use generic OPP functions that allow CPUFreq to be be moved back
into CPUFreq framework. This allows for independent modifications
or future enhancements as needed isolated to just CPUFreq framework
alone.
Here, we just move relevant code and documentation to make this part of
CPUFreq infrastructure.
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CPUFREQ custom functions for OPP (Operating Performance Points)
currently exist inside the OPP library. These custom functions currently
depend on internal data structures to pick up OPP information to create
the cpufreq table. For example, the cpufreq table is created precisely
in the same order of how OPP entries are stored inside the list implementation.
This kind of tight interdependency is purely artificial since the same
functionality can be achieved using the generic OPP functions
meant to do the same. This interdependency also limits the independent
modification of cpufreq and OPP library.
So use the generic dev_pm_opp_find_freq_ceil function that achieves the
table organization as we currently use.
As a result of this, we dont need to use the internal device_opp
structure anymore, and we hence we can switch over to rcu lock instead
of the mutex holding the internal list lock.
This breaking of dependency on internal data structure imposes no change
to usage of these.
NOTE: This change is a precursor to moving this cpufreq specific logic
out of the generic library into cpufreq.
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
drivers/base/regmap/regmap.c: In function ‘_regmap_range_multi_paged_reg_write’:
drivers/base/regmap/regmap.c:1665: warning: ‘this_page’ may be used uninitialized in this function
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Since we cannot make sure the 'len = pair_size * num_regs' will always
be none zero from the users, and then if 'num_regs' equals to zero by
mistake or other reasons, the kzalloc() will return ZERO_SIZE_PTR, which
equals to ((void *)16).
So this patch fix this with just doing the 'len' zero check before calling
kzalloc().
Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Introduce devm_kmemdup, which uses resource managed kmalloc.
There are several request from maintainers to add this instead
of using kmemdup.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.
The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
audio support built as modules and using nfsroot for root filesystem.
The following log fragment shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:
...
[ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
[ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
[ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
[ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
[ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
[ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
[ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
[ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
[ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
[ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
[ 13.346755] davinci_mcasp_driver_init: LEAVE
[ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral
[ 13.592527] platform sound.3: really_probe: probe_count = 0
In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (since 12.615118).
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components (the machine driver still in it's probe
function after it failed to construct the card) and the deferred work is
prepared at 13.099026 (note that this time the machine driver is not in the
lists so it is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to
the deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.
The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.
This way we can avoid drivers stuck in the deferred queue.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Stable <stable@vger.kernel.org> # v3.4+
Support for uevent_helper, aka hotplug, is not required on many systems
these days but it can still be enabled via sysfs or sysctl.
Reported-by: Darren Shepherd <darren.s.shepherd@gmail.com>
Signed-off-by: Michael Marineau <mike@marineau.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:
irq: no irq domain found for /ocp/pinmux@48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically, so
let's fix up the issue by resolving the interrupt resources when
platform_get_irq is called.
And then we also need to accept the fact that some irqdomains do not
exist that early on, and only get initialized later on. So we can
make the current WARN_ON into just into a pr_debug().
We still attempt to populate irq resources when we create the devices.
This allows current drivers which don't use platform_get_irq to continue
to function. Once all drivers are fixed, this code can be removed.
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Some I2C adapters are only compatible with the SMBus protocol and do not
support standard I2C transfers.
Fallback to SMBus transfers if we encounter such kind of adapters.
The transfer type is chosen according to the val_bits field in the regmap
config.
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Some busses do not support sending/receiving multiple registers in one go.
Such kind of busses just unpack the registers that have been previously
packed by the regmap core or pack registers that will be later unpacked by
the core code.
Add reg_write and reg_read callbacks in order to optimize access through
this kind of busses.
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
The topology_##name() macro does not use its argument when CONFIG_SMP is not
set, as it ultimately calls the cpu_data() macro.
So we avoid maintaining a possibly unused `cpu' variable, to avoid the
following compilation warning:
drivers/base/topology.c: In function ‘show_physical_package_id’:
drivers/base/topology.c:103:118: warning: unused variable ‘cpu’ [-Wunused-variable]
define_id_show_func(physical_package_id);
drivers/base/topology.c: In function ‘show_core_id’:
drivers/base/topology.c:106:106: warning: unused variable ‘cpu’ [-Wunused-variable]
define_id_show_func(core_id);
This can be seen with e.g. x86 defconfig and CONFIG_SMP not set.
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org> # 3.10.x
Cc: <stable@vger.kernel.org> # 3.13.x
Cc: <stable@vger.kernel.org> # 3.14.x
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All device_schedule_callback_owner() users are converted to use
device_remove_file_self(). Remove now unused
{sysfs|device}_schedule_callback_owner().
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
'offset = *(u32 *)reg;'
This will be okey for 32/64-bits register device, but for 8/16-bits
register ones, the 'offset' value will overflow, for example:
The IMX2 Watchdog, whose registers and values are all 16-bits:
If the IO base virtual address is ctx->regs = 0x888c0000, and the now
doing the 0x00 register accessing:
Using 'offset = *(u32 *)reg' the offset value will possiblly be 0x77310000,
Using 'offset = *(u16 *)reg' the offset value will be 0x0000.
In the regmap_mmio_gather_write(), ctx->regs + 0x7731000 will be 0xffbd0000,
but actually it should be ctx->regs + 0x0000 = 0x888c0000.
Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Allow busses to request little endianness formatting and
parsing for 16- and 32-bit values. This will be useful to
support regmap-mmio.
For the following the scenarios using the regmap-mmio,
for example:
Index CPU Device Endianess flag for values
----------------------------------------------------------
1 LE LE REGMAP_ENDIAN_DEFAULT/NATIVE
2 LE BE REGMAP_ENDIAN_BIG
3 BE BE REGMAP_ENDIAN_DEFAULT/NATIVE
4 BE LE REGMAP_ENDIAN_LITTLE
For one device driver, which will support all the cases above,
needs two boolean properties in DT node like: 'big-endian'
for case 2 and 'little-endian' for case 4, and for cases 1
and 3 they all will be absent.
Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Pull regmap fix from Mark Brown:
"regmap: Fix for nodev mode
Add mising braces so that the nodev mode actually works (which was a
bit of an oversight)"
Testing schmesting. We don't need not steenking testing. We have
deadlines to beat, and new code to write.
* tag 'regmap-v3.15-nodev' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: adds missing braces in regmap_init()
Pull CPU hotplug notifiers registration fixes from Rafael Wysocki:
"The purpose of this single series of commits from Srivatsa S Bhat
(with a small piece from Gautham R Shenoy) touching multiple
subsystems that use CPU hotplug notifiers is to provide a way to
register them that will not lead to deadlocks with CPU online/offline
operations as described in the changelog of commit 93ae4f978c ("CPU
hotplug: Provide lockless versions of callback registration
functions").
The first three commits in the series introduce the API and document
it and the rest simply goes through the users of CPU hotplug notifiers
and converts them to using the new method"
* tag 'cpu-hotplug-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (52 commits)
net/iucv/iucv.c: Fix CPU hotplug callback registration
net/core/flow.c: Fix CPU hotplug callback registration
mm, zswap: Fix CPU hotplug callback registration
mm, vmstat: Fix CPU hotplug callback registration
profile: Fix CPU hotplug callback registration
trace, ring-buffer: Fix CPU hotplug callback registration
xen, balloon: Fix CPU hotplug callback registration
hwmon, via-cputemp: Fix CPU hotplug callback registration
hwmon, coretemp: Fix CPU hotplug callback registration
thermal, x86-pkg-temp: Fix CPU hotplug callback registration
octeon, watchdog: Fix CPU hotplug callback registration
oprofile, nmi-timer: Fix CPU hotplug callback registration
intel-idle: Fix CPU hotplug callback registration
clocksource, dummy-timer: Fix CPU hotplug callback registration
drivers/base/topology.c: Fix CPU hotplug callback registration
acpi-cpufreq: Fix CPU hotplug callback registration
zsmalloc: Fix CPU hotplug callback registration
scsi, fcoe: Fix CPU hotplug callback registration
scsi, bnx2fc: Fix CPU hotplug callback registration
scsi, bnx2i: Fix CPU hotplug callback registration
...
Keep all power-domains already enabled by bootloader on, even if no
driver has claimed them. This is useful for debug and development, but
should not be needed on a platform with proper driver support.
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull more ACPI and power management updates from Rafael Wysocki:
"These are commits that were not quite ready when I sent the original
pull request for 3.15-rc1 several days ago, but they have spent some
time in linux-next since then and appear to be good to go. All of
them are fixes and cleanups.
Specifics:
- Remaining changes from upstream ACPICA release 20140214 that
introduce code to automatically serialize the execution of methods
creating any named objects which really cannot be executed in
parallel with each other anyway (previously ACPICA attempted to
address that by aborting methods upon conflict detection, but that
wasn't reliable enough and led to other issues). From Bob Moore
and Lv Zheng.
- intel_pstate fix to use del_timer_sync() instead of del_timer() in
the exit path before freeing the timer structure from Dirk
Brandewie (original patch from Thomas Gleixner).
- cpufreq fix related to system resume from Viresh Kumar.
- Serialization of frequency transitions in cpufreq that involve
PRECHANGE and POSTCHANGE notifications to avoid ordering issues
resulting from race conditions. From Srivatsa S Bhat and Viresh
Kumar.
- Revert of an ACPI processor driver change that was based on a
specific interpretation of the ACPI spec which may not be correct
(the relevant part of the spec appears to be incomplete). From
Hanjun Guo.
- Runtime PM core cleanups and documentation updates from Geert
Uytterhoeven.
- PNP core cleanup from Michael Opdenacker"
* tag 'pm+acpi-3.15-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: Make cpufreq_notify_transition & cpufreq_notify_post_transition static
cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}
cpufreq: Make sure frequency transitions are serialized
intel_pstate: Use del_timer_sync in intel_pstate_cpu_stop
cpufreq: resume drivers before enabling governors
PM / Runtime: Spelling s/competing/completing/
PM / Runtime: s/foo_process_requests/foo_process_next_request/
PM / Runtime: GENERIC_SUBSYS_PM_OPS is gone
PM / Runtime: Correct documented return values for generic PM callbacks
PM / Runtime: Split line longer than 80 characters
PM / Runtime: dev_pm_info.runtime_error is signed
Revert "ACPI / processor: Make it possible to get APIC ID via GIC"
ACPICA: Enable auto-serialization as a default kernel behavior.
ACPICA: Ignore sync_level for methods that have been auto-serialized.
ACPICA: Add additional named objects for the auto-serialize method scan.
ACPICA: Add auto-serialization support for ill-behaved control methods.
ACPICA: Remove global option to serialize all control methods.
PNP: remove deprecated IRQF_DISABLED
Pull driver core and sysfs updates from Greg KH:
"Here's the big driver core / sysfs update for 3.15-rc1.
Lots of kernfs updates to make it useful for other subsystems, and a
few other tiny driver core patches.
All have been in linux-next for a while"
* tag 'driver-core-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (42 commits)
Revert "sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()"
kernfs: cache atomic_write_len in kernfs_open_file
numa: fix NULL pointer access and memory leak in unregister_one_node()
Revert "driver core: synchronize device shutdown"
kernfs: fix off by one error.
kernfs: remove duplicate dir.c at the top dir
x86: align x86 arch with generic CPU modalias handling
cpu: add generic support for CPU feature based module autoloading
sysfs: create bin_attributes under the requested group
driver core: unexport static function create_syslog_header
firmware: use power efficient workqueue for unloading and aborting fw load
firmware: give a protection when map page failed
firmware: google memconsole driver fixes
firmware: fix google/gsmi duplicate efivars_sysfs_init()
drivers/base: delete non-required instances of include <linux/init.h>
kernfs: fix kernfs_node_from_dentry()
ACPI / platform: drop redundant ACPI_HANDLE check
kernfs: fix hash calculation in kernfs_rename_ns()
kernfs: add CONFIG_KERNFS
sysfs, kobject: add sysfs wrapper for kernfs_enable_ns()
...
Pull char/misc driver patches from Greg KH:
"Here's the big char/misc driver updates for 3.15-rc1.
Lots of various things here, including the new mcb driver subsystem.
All of these have been in linux-next for a while"
* tag 'char-misc-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (118 commits)
extcon: Move OF helper function to extcon core and change function name
extcon: of: Remove unnecessary function call by using the name of device_node
extcon: gpio: Use SIMPLE_DEV_PM_OPS macro
extcon: palmas: Use SIMPLE_DEV_PM_OPS macro
mei: don't use deprecated DEFINE_PCI_DEVICE_TABLE macro
mei: amthif: fix checkpatch error
mei: client.h fix checkpatch errors
mei: use cl_dbg where appropriate
mei: fix Unnecessary space after function pointer name
mei: report consistently copy_from/to_user failures
mei: drop pr_fmt macros
mei: make me hw headers private to me hw.
mei: fix memory leak of pending write cb objects
mei: me: do not reset when less than expected data is received
drivers: mcb: Fix build error discovered by 0-day bot
cs5535-mfgpt: Simplify dependencies
spmi: pm: drop bus-level PM suspend/resume routines
spmi: pmic_arb: make selectable on ARCH_QCOM
Drivers: hv: vmbus: Increase the limit on the number of pfns we can handle
pch_phub: Report error writing MAC back to user
...
Pull regulator updates from Mark Brown:
"This release has lots and lots of small cleanups and fixes in the
regulator subsystem, mainly cleaning up some bad patterns that got
duplicated in DT code, but otherwise very little of note outside of
the scope of the relevant drivers:
- Support for configuration of the initial state for gpio regulators
with multi-voltage support.
- Support for calling regulator_set_voltage() on fixed regulators.
- New drivers for Broadcom BCM590xx, Freescale pfuze200, Samsung
S2MPA01 & S2MPS11/4, some PWM controlled regulators found on some
ST boards and TI TPS65218"
* tag 'regulator-v3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (154 commits)
regulator: aat2870: Use regulator_map_voltage_ascend
regulator: st-pwm: Convert to get_voltage_sel
regulator: Add new driver for ST's PWM controlled voltage regulators
regulator: bcm590xx: Remove **rdev from struct bcm590xx_reg
regulator: bcm590xx: Make the modalias matches the driver name
regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap
regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2
regulator: s2mps11: Add missing of_node_put
regulator: s2mps11: Use of_get_child_by_name
Documentation: mfd: s2mps11: Document support for S2MPS14
regulator: s2mps11: Add set_suspend_disable for S2MPS14
regulator: s2mps11: Add support for S2MPS14 regulators
regulator: max8660: Fix brace alignment
regulator: dbx500: use seq_puts() instead of seq_printf()
regulator: dbx500-prcmu: Silence checkpatch warnings
regulator: anatop: Remove checking control_reg in [set|get]_voltage_sel
regulator: max8952: Silence checkpatch warning
regulator: max8925: Silence checkpatch warning
regulator: max8660: Silence checkpatch warnings
regulator: arizona-ldo1: Correct default regulator init_data
...
