Fix 2 checkpatch errors about using assignment in if condition,
1 checkpatch error about a required space after comma
and 3 warnings about line over 80 characters.
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
According to the data provided by HW Team, at least 12 internal platform
clock cycles are required to stabilize a DFS clock switch on FSL e500mc Socs.
This patch replaces the CPUFREQ_ETERNAL with appropriate HW clock transition
latency to make DFS governors work normally on Freescale e500mc boards.
Signed-off-by: Zhuoyu Zhang <Zhuoyu.Zhang@freescale.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Two cpufreq notifiers CPUFREQ_RESUMECHANGE and CPUFREQ_SUSPENDCHANGE have
not been used for some time, so remove them to clean up code a bit.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cpufreq drivers that provide the ->setpolicy() callback are supposed
to have integrated governors, so they don't need to set ->target()
or ->target_index() and may confuse the core if any of these callbacks
is present.
For this reason, add a check preventing ->setpolicy cpufreq drivers
from registering if they have non-NULL ->target or ->target_index.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
We have a per-CPU variable for managing which cluster a CPU belongs to.
Currently, physical_cluster is set for policy->cpu only which leads to
the following on some SoC's:
- There are two clusters:
- Cluster 0 has four ARM Cortex A7 CPUs (slower ones): 0,1,2,3
- Cluster 1 has four ARM Cortex A15 CPUs (faster ones): 4,5,6,7
- CPUs are booted in order 0,1..7 and so initially policy->cpu for A7 cluster
would be 0 and for A15 cluster would be 4.
- Now CPU4 (i.e. A15_0) is hotplugged out and so policy->cpu for A15 cluster
becomes 5 (i.e. A15_1).
- But physical cluster is only set for CPU0 and CPU4 in ARM big LITTLE driver
and isn't updated.
- Now freq change request comes for A15 cluster and we would try to update freq
of physical_cluster of CPU5, i.e. A15_1. And it is currently set to zero
(default value of uninitialized global variables).
- And so we actually try to change freq of A7 cluster instead of A15.
- This also results in kernel crash as sometimes we might request freq above
A7's limit and CPU may behave badly..
Fix this by initializing physical_cluster for all CPUs of a policy.
Based on previous work by Xin Wang.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently vexpress big LITTLE driver selects ARM_BIG_LITTLE_CPUFREQ, so
if CONFIG_BIG_LITTLE isn't enabled and CONFIG_ARM_VEXPRESS_SPC_CPUFREQ
is enabled, we get the following build warnings:
warning: (ARM_VEXPRESS_SPC_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which has
unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && (ARM || ARM64) && ARM
&& BIG_LITTLE && ARM_CPU_TOPOLOGY && HAVE_CLK)
To fix this, make ARM_VEXPRESS_SPC_CPUFREQ depend on ARM_BIG_LITTLE_CPUFREQ
instead of selecting it.
This also moves the entry for ARM_VEXPRESS_SPC_CPUFREQ along with other
big LITTLE config entries.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit da60ce9f2f (cpufreq: call cpufreq_driver->get() after
calling ->init()) __cpufreq_add_dev() sometimes fails for CPUs handled
by intel_pstate, because that driver may return 0 from its ->get()
callback if it has not run long enough to collect enough samples on the
given CPU. That didn't happen before commit da60ce9f2f which added
policy->cur initialization to __cpufreq_add_dev() to help reduce code
duplication in other cpufreq drivers.
However, the code added by commit da60ce9f2f need not be executed
for cpufreq drivers having the ->setpolicy callback defined, because
the subsequent invocation of cpufreq_set_policy() will use that
callback to initialize the policy anyway and it doesn't need
policy->cur to be initialized upfront. The analogous code in
cpufreq_update_policy() is also unnecessary for cpufreq drivers
having ->setpolicy set and may be skipped for them as well.
Since intel_pstate provides ->setpolicy, skipping the upfront
policy->cur initialization for cpufreq drivers with that callback
set will cover intel_pstate and the problem it's been having after
commit da60ce9f2f will be addressed.
Fixes: da60ce9f2f (cpufreq: call cpufreq_driver->get() after calling ->init())
References: https://bugzilla.kernel.org/show_bug.cgi?id=71931
Reported-and-tested-by: Patrik Lundquist <patrik.lundquist@gmail.com>
Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
As multiplatform build is being adopted by more and more
ARM platforms, initcall function should be used very carefully.
For example, when SPEAr cpufreq driver is enabled on a kernel
booted on a non-SPEAr board, we will get following boot time error:
spear_cpufreq: Invalid cpufreq_tbl
To eliminate this undesired the effect, the patch changes SPEAr
driver to have it instantiated as a platform_driver. Then it will
only run on platforms that create the platform_device "spear-cpufreq".
This patch also creates platform node for SPEAr13xx boards.
Reported-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We have used 'frozen' variable/function parameter at many places to
distinguish between CPU offline/online on suspend/resume vs sysfs
removals. We now have another variable cpufreq_suspended which can
be used in these cases, so we can get rid of all those variables or
function parameters.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cpufreq_generic_exit() is empty now and can be deleted.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
freq table is not per CPU but per policy, so it makes more sense to
keep it within struct cpufreq_policy instead of a per-cpu variable.
This patch does it. Over that, there is no need to set policy->freq_table
to NULL in ->exit(), as policy structure is going to be freed soon.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
A collection of fixes for ARM platforms. A little large due to us missing to
do one last week, but there's nothing in particular here that is in itself
large and scary.
Mostly a handful of smaller fixes all over the place. The majority is made
up of fixes for OMAP, but there are a few for others as well. In particular,
there was a decision to rename a binding for the Broadcom pinctrl block that
we need to go in before the final release since we then treat it as ABI.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJTHKFOAAoJEIwa5zzehBx36EoP/0K7ts9qrShYUD2ASy9HuFKj
cUcIHF+c0203bavIZzP5EQW/m7TGSybjO8UwkOaLv5SL6E9fn8rR01mmKpONeZbN
E40ANvOxP3FdWWUFzZSh4oyaX0abaPUtPaYBavakHQI2Ej2m4UmpXAWUkCUGt9Om
sXSAYuOi6tmpy40aimpaI1QBtx/eyxxJgEBKcbFBvhp1P3d56LTtoqmzACxBFU/8
4NJIXuZlXTmXV9qIX+y4yXDhmVb6c/gEbNeLJ2F3yWzEeTgnMeycDb8o27Jl6Ii4
rjsT25qplW5zvUODuhU6QUjuipPh8+WtyF8ruKMakxMNkVoGAC2flWw2TBR09tVj
zIqYP7/vDhCEYcw4g/BqR8tEvojWt2m7Hm5y+oQY3qmCtLewL6TYeXZcXWFLCwSk
m4zSvzZOsRsZWsZcflJKZr3g5vsjbg3vtoc3pOZaN4UcqEhU1HCtMfN3znnXIhtj
xGWqN22S3OpGM0lzLY95lnVeLdrs6eX/ZY23BG1OV4OcDWM4nYwAxEq94QgPvSxR
9E/fFhU2DZIulEA5Z+/PIReUCLuNL709zqnyAG9VTvbeC24sdr0W6bEM08O85xan
kb7sbYRnt4qr4uOhPCi7wIENY4rrS91dcE3XZUhJtLWi/0jj+pHT9VoggyS4QdtS
aWRhg70S5M6quMEoIOzg
=YBim
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from from Olof Johansson:
"A collection of fixes for ARM platforms. A little large due to us
missing to do one last week, but there's nothing in particular here
that is in itself large and scary.
Mostly a handful of smaller fixes all over the place. The majority is
made up of fixes for OMAP, but there are a few for others as well. In
particular, there was a decision to rename a binding for the Broadcom
pinctrl block that we need to go in before the final release since we
then treat it as ABI"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting
ARM: tegra: add LED options back into tegra_defconfig
ARM: dts: omap3-igep: fix boot fail due wrong compatible match
ARM: OMAP3: Fix pinctrl interrupts for core2
pinctrl: Rename Broadcom Capri pinctrl binding
pinctrl: refer to updated dt binding string.
Update dtsi with new pinctrl compatible string
ARM: OMAP: Kill warning in CPUIDLE code with !CONFIG_SMP
ARM: OMAP2+: Add support for thumb mode on DT booted N900
ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
ARM: DRA7: hwmod data: correct the sysc data for spinlock
ARM: OMAP5: PRM: Fix reboot handling
ARM: sunxi: dt: Change the touchscreen compatibles
ARM: sun7i: dt: Fix interrupt trigger types
Highlights include:
- Fix another nfs4_sequence corruptor in RELEASE_LOCKOWNER
- Fix an Oopsable delegation callback race
- Fix another bad stateid infinite loop
- Fail the data server I/O is the stateid represents a lost lock
- Fix an Oopsable sunrpc trace event
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTHJSVAAoJEGcL54qWCgDyVRkP/2t43gjMF6P+Yc7VUW2e5uTv
rHhPGFLuDVs9oS3WUYegzvThZMs//ovTaYgUSDNpOYztEB6P8bDRm41q/VgUIixY
zWFoEplDgAZZE7gP2EJuXJv3bEdhJqXuCG2KUysqMsaIGlahrlQdHmqGTz6Y931o
WROyMWVvnL4IoEtQHVR7DwyqkvSmifPJ8MZZv3Liy82wuw1fCsh8uy8mkYYSbdvN
OK4JmHqdJ+CbAZ0WmE4Xe3Itqy/aIMBL9Jyrq4Zl1QX0p7ez3Xpy4XwmtlZXn2KP
bKMfK2vP9RggagIpjUL+dhCqxlsyjlF6EzTnQRe7jXqlJ/vJ9pQF8X294jwRysfp
80jDqsTSND4JQiZuBISID23N1nL0TzrP2tWqipR9zx5JJMRVzYZWTzEq4w2uAHgg
aW2vTdRNRLZWydlfFNQ8FiuEPIFoQaJFmOCQisec2LtfffLZZBz7JPofjNH9CgU8
mcbPhv75m2imXDOylydiVoD4x/myCGheYw2hpqhb1ZeuQxdN9lnwa0JzjPiP1h38
XIYwzM7TE8WayrdkMDCeIem1dz/VexknfKmXmFXlMfn3GRKxowCSrggxKG92k0eP
L35cJj91a9AoxMz/ej0erv0iI1flLeoYP9aJzIRtZf+SB1BZkKhmWlFRQKqnlIOA
BzjYui4mUoEQEa5Sk7Th
=JfQx
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-3.14-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client bugfixes from Trond Myklebust:
"Highlights include:
- Fix another nfs4_sequence corruptor in RELEASE_LOCKOWNER
- Fix an Oopsable delegation callback race
- Fix another bad stateid infinite loop
- Fail the data server I/O is the stateid represents a lost lock
- Fix an Oopsable sunrpc trace event"
* tag 'nfs-for-3.14-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
SUNRPC: Fix oops when trace sunrpc_task events in nfs client
NFSv4: Fail the truncate() if the lock/open stateid is invalid
NFSv4.1 Fail data server I/O if stateid represents a lost lock
NFSv4: Fix the return value of nfs4_select_rw_stateid
NFSv4: nfs4_stateid_is_current should return 'true' for an invalid stateid
NFS: Fix a delegation callback race
NFSv4: Fix another nfs4_sequence corruptor
Here are 4 USB fixes for your current tree.
Two of them are reverts to hopefully resolve the nasty XHCI regressions
we have been having on some types of devices. The other two are quirks
for some Logitech video devices.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlMbu0sACgkQMUfUDdst+yl/MgCeJbq5Lre/M59O5YVWhS3fghsG
PisAoI7t2LLnhiC/DwZD10vs2hEkZxw2
=R/Qt
-----END PGP SIGNATURE-----
Merge tag 'usb-3.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are 4 USB fixes for your current tree.
Two of them are reverts to hopefully resolve the nasty XHCI
regressions we have been having on some types of devices. The other
two are quirks for some Logitech video devices"
* tag 'usb-3.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma"
Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather."
usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e
Here is a single staging driver fix for your tree.
It resolves an issue with arbritary writes to memory if a specific
driver is loaded.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlMbwF4ACgkQMUfUDdst+ynSIwCZAfb/XkCqRqnzW8nfAOqITRP9
VwUAoMHjGSr6mBbXFzHz5QoxGwylY+dW
=+BBI
-----END PGP SIGNATURE-----
Merge tag 'staging-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver tree fix from Greg KH:
"Here is a single staging driver fix for your tree.
It resolves an issue with arbritary writes to memory if a specific
driver is loaded"
* tag 'staging-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()
This fixes CVE-2014-0102.
The following command sequence produces an oops:
keyctl new_session
i=`keyctl newring _ses @s`
keyctl link @s $i
The problem is that search_nested_keyrings() sees two keyrings that have
matching type and description, so keyring_compare_object() returns true.
s_n_k() then passes the key to the iterator function -
keyring_detect_cycle_iterator() - which *should* check to see whether this is
the keyring of interest, not just one with the same name.
Because assoc_array_find() will return one and only one match, I assumed that
the iterator function would only see an exact match or never be called - but
the iterator isn't only called from assoc_array_find()...
The oops looks something like this:
kernel BUG at /data/fs/linux-2.6-fscache/security/keys/keyring.c:1003!
invalid opcode: 0000 [#1] SMP
...
RIP: keyring_detect_cycle_iterator+0xe/0x1f
...
Call Trace:
search_nested_keyrings+0x76/0x2aa
__key_link_check_live_key+0x50/0x5f
key_link+0x4e/0x85
keyctl_keyring_link+0x60/0x81
SyS_keyctl+0x65/0xe4
tracesys+0xdd/0xe2
The fix is to make keyring_detect_cycle_iterator() check that the key it
has is the key it was actually looking for rather than calling BUG_ON().
A testcase has been included in the keyutils testsuite for this:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=891f3365d07f1996778ade0e3428f01878a1790b
Reported-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull thermal fixes from Zhang Rui:
"Specifics:
- Update the help text of INT3403 Thermal driver, which was not
friendly to users. From Zhang Rui.
- The "type" sysfs attribute of x86_pkg_temp_thermal registered
thermal zones includes an instance number, which makes the
thermal-to-hwmon bridge fails to group them all in a single hwmon
device. Fixed by Jean Delvare.
- The hwmon device registered by x86_pkg_temp_thermal driver is
redundant because the temperature value reported by
x86_pkg_temp_thermal is already reported by the coretemp driver.
Fixed by Jean Delvare.
- Fix a problem that the cooling device can not be updated properly
if it is initialized at max cooling state. From Ni Wade.
- Fix a problem that OF registered thermal zones are running without
thermal governors. From Zhang Rui.
- Commit beeb5a1e0e ("thermal: rcar-thermal: Enable driver
compilation with COMPILE_TEST") broke build on archs wihout io
memory. Thus make it depend on HAS_IOMEM to bypass build failures.
Fixed by Richard Weinberger"
* 'for-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
Thermal: thermal zone governor fix
Thermal: Allow first update of cooling device state
thermal,rcar_thermal: Add dependency on HAS_IOMEM
x86_pkg_temp_thermal: Fix the thermal zone type
x86_pkg_temp_thermal: Do not expose as a hwmon device
Thermal: update INT3404 thermal driver help text
A scattering of driver specific fixes here. The fixes from Axel cover
bitrot in apparently unmaintained drivers, the at79 bug is fixing a
glitch on /CS during initialisation of some devices which could break
some slaves and the remainder are fixes for recently introduced bugs
from the past release cycle or so.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIbBAABAgAGBQJTGVKmAAoJELSic+t+oim9us4P9RSbIcwJWobTy2Px/7yPH2e9
mAjlTVnBQ2EqwPAI+iro1xQfTeeyn3fAkdINrkWe6xGkbXH4n4OezWZzdH0VbPFV
buUPc9EYt8FysG/Xne3nyW3cCDzv0+CzvD5CY/83SDa2YMd+2134dxb/8UOpLE+Q
ptde7EsR11z2XF9PLdm4Wc7ouGEczm3zfbgy1v1uO0UZqeFe8sbzroYLdTZnRYZ5
s9BD3hUgcB9+cV/v4gv988hYhofmvmsYluBmo8Q7OVgMJ90ne281P8X9CqxEEn1w
vsebrQ3xFIybDk1GGp79IMTyNooX48+2eTalsJa4+eWsGYpZjMW7wHx+pYX5pqnI
hxrKU4yXQ8Sa7CMwfGcLgzJpa7DPbTKJZrw7X1x71+Pu8HcBHEKO1xKJ9YNY98Kd
B0zvdPaYmEFX5e4T7Tv2opk3TVYZtrlNmu16DxgktzYEUdArkDZAV0SVHMtGzpGn
/AMtvm5LIH58smyhdsocQtdddjE2oELVuLqtfIZgq8KuARmFYVzDro/q9BXcJMWK
0LJCscr4bxljFEm+NDhPTwtQ1TX3Ahl+sTDkyx1sYjfQXEUsJyP0YesLqbyIP1xY
gzAURogPooS7Gz4ggkyZv0cvcsKcziXvf4MYpIKT58HjfVgGk5Kk7LU6E2eUJMXU
AzmQoeKfWrIUzKYOk8w=
=2e3U
-----END PGP SIGNATURE-----
Merge tag 'spi-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A scattering of driver specific fixes here.
The fixes from Axel cover bitrot in apparently unmaintained drivers,
the at79 bug is fixing a glitch on /CS during initialisation of some
devices which could break some slaves and the remainder are fixes for
recently introduced bugs from the past release cycle or so"
* tag 'spi-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: atmel: add missing spi_master_{resume,suspend} calls to PM callbacks
spi: coldfire-qspi: Fix getting correct address for *mcfqspi
spi: fsl-dspi: Fix getting correct address for master
spi: spi-ath79: fix initial GPIO CS line setup
spi: spi-imx: spi_imx_remove: do not disable disabled clocks
spi-topcliff-pch: Fix probing when DMA mode is used
spi/topcliff-pch: Fix DMA channel
Pull SCSI target fixes from Nicholas Bellinger:
"This series addresses a number of outstanding issues wrt to active I/O
shutdown using iser-target. This includes:
- Fix a long standing tpg_state bug where a tpg could be referenced
during explicit shutdown (v3.1+ stable)
- Use list_del_init for iscsi_cmd->i_conn_node so list_empty checks
work as expected (v3.10+ stable)
- Fix a isert_conn->state related hung task bug + ensure outstanding
I/O completes during session shutdown. (v3.10+ stable)
- Fix isert_conn->post_send_buf_count accounting for RDMA READ/WRITEs
(v3.10+ stable)
- Ignore FRWR completions during active I/O shutdown (v3.12+ stable)
- Fix command leakage for interrupt coalescing during active I/O
shutdown (v3.13+ stable)
Also included is another DIF emulation fix from Sagi specific to
v3.14-rc code"
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
Target/sbc: Fix sbc_copy_prot for offset scatters
iser-target: Fix command leak for tx_desc->comp_llnode_batch
iser-target: Ignore completions for FRWRs in isert_cq_tx_work
iser-target: Fix post_send_buf_count for RDMA READ/WRITE
iscsi/iser-target: Fix isert_conn->state hung shutdown issues
iscsi/iser-target: Use list_del_init for ->i_conn_node
iscsi-target: Fix iscsit_get_tpg_from_np tpg_state bug
Revert commit 3130497f5b ("ACPI / sleep: pm_power_off needs more
sanity checks to be installed") that breaks power ACPI power off on a
lot of systems, because it checks wrong registers.
Fixes: 3130497f5b ("ACPI / sleep: pm_power_off needs more sanity checks to be installed")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
issues booting 3430 based boards.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJTE7TIAAoJEBvUPslcq6VzHvEP/RxCNr6O1sRneB4r+kLScgX1
ccvJtPAN5s4/MmUZnfoW2REzC8SXc6NxqfnaYaTSSMgn+C+xU98tkI8BGz8IiSA6
e3LXSQYu1tTht1pL68OFOI0x0mhAhGTFKUFsoAPVWUlyJegckxAg9XKK/SRq52Ea
ko02mJgdZY6mLaJowsIl940MqW4yGKr3g/z+CDDhYh9E2I0O5hGNjWhhtqcgsjit
C/HlL7MHf186NEURpd9PAh+6H0bJHHWA0p2Ir825sfJgBFG44pJvnTz7YIpBOQeb
twlULgFsSPc5osBzxvMBi4xu0Th6h9rydp1QP0tgoS1eEh1ekcf0/gb7wXHYw6g4
8oKB+K1CJy35UAKgIyObh8VKqNpzQOkQZ6enSBAuS0I944XcNcSxcSUhiY9wo9q4
96j0cvGIAC8nNIfLXKISnhJuzW4Xa20cIZwjDx9zCHgUGxgx1x2I8g/qVu2pHtwv
TEZrK94LhlEHNO2By3/4s647YX0r6PpDaGo1rG2z11sRWu3C/G+/KASADW2VNwyC
bY1HupfLZ6U/zmYu2Y250CyNU+0yTragDKdR8SboT9BQTJ/wWZQckerE/R8y2hN7
lg67ah0jounBm902bW8JxcUYCuSdku4rtIn7EoDRWRQhnXVYEbmnecM8wltomak5
vcCiCZkhqQ/O9j0dFLh9
=J6Y0
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v3.14/fixes-dt-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren:
Two omap3430 vs 3630 device tree regression fixes for
issues booting 3430 based boards.
* tag 'omap-for-v3.14/fixes-dt-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting
ARM: dts: omap3-igep: fix boot fail due wrong compatible match
Signed-off-by: Olof Johansson <olof@lixom.net>
other bcm mobile bindings.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJTDB0VAAoJEPYb7NoJr+nLwGkQALuroLtwGGq0/6Jw4dr9n5UO
tclAvSbuvUoqwu58cD3grWhkavFKQqR4fJdWcrmczROD9r6rX48QDFe2jNlRjgj/
yNKkTsd+Ay9I0tPeyx3Buf+tVeQgqsSuG7FJPKgAxMf3HT+tmaWpdIMsjcLOwzdi
ZMTpIw0cLGMdtr8OSHW/nJuaQV3b+DhnjSLC8QIRg3XgJGjNzJxiKu2Flp0w261P
Ubzs/PDv83Xl5d972e6JoYR5gGzMwIskm64LmEbHiigLJsvo71oHW57Q2g9asx7h
stiBzAWF7/Q1xDQ0hTukIOIbX94juR9zSaje66qZ578CFiRAYefginCfyIak9R6R
Jk0X3krsc0bU9hi4maiYEMVXO3R7K7Rv4BcdoXkg38BXNyINfpdUZlb/5ds6o2FJ
AZaBgt+/3dl649YaX+ft9VW+1oeV4Hj89sn2pH56NV/rC+dzmh3EHExyHFPJ+sO+
KKaoXVPf7+TyStrwSxXPSdpUlmGWRWEn9NF1JIGtGNBU+hbiXw7TEOD6DaC8TAN0
kqAC3ba1YwJalR5rr6UC8ZG2dIZMv3BF7efrM+ewcV7w7F5KF/suJmYIGF+hAFfJ
Ki7YRRUMS2bVroFjQ7haFGkcwS4JzQnR0hO4O4rNu9JbgBWs0Zv5idj1G/EFpT7a
hM4ZETYQQb27LVicK/dN
=2dxs
-----END PGP SIGNATURE-----
Merge tag 'bcm-for-3.14-pinctrl-reduced-rename' of git://github.com/broadcom/bcm11351 into fixes
Merge 'bcm pinctrl rename' From Christin Daudt:
Rename pinctrl dt binding to restore consistency with other bcm mobile
bindings.
* tag 'bcm-for-3.14-pinctrl-reduced-rename' of git://github.com/broadcom/bcm11351:
pinctrl: Rename Broadcom Capri pinctrl binding
pinctrl: refer to updated dt binding string.
Update dtsi with new pinctrl compatible string
+ Linux 3.14-rc4
Signed-off-by: Olof Johansson <olof@lixom.net>
interrupt types of some IPs, the other fixes up a compatible that got
introduced during 3.14
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJTFFXwAAoJEBx+YmzsjxAgXR4P/3Oa9crjF3IFZq4ugO+cJsbg
F3xjKMfuyCjfAYwtzexivRl7PjuGShdevYvNRbY1sqNTAIQbJRWAQC+ZXolXPp/W
gE6z8mAIlLG0OmE8t1glGLhXVyXiRTlm2s96su2q73MWqYMNXE+yr8K+qt+5gA7r
M34lYAGqKyQEgs8TKSGSvqa7yZLWZlii6FKwtOCU6HlFm3Rz9Glj8MyTixQDMY0H
LCONp9csbEgPfrLh+FfJitK2H5kRAU0xJAmP/k+rZtzSKy0kPuCTsKO/ZeUnKhQy
Rq1Li60Ho3nzmVNljtFVPoDZluxlrZwXA8xLzE88CiwjlYx3TauFFxIIbyGwPamX
hBEWDqL0x9Y7FQD4Ft4s8mnCE1bD+7eKnqCyCDVGD5je+1qu70vFQZa7ZR2eM9kg
FS/GSWuG54nIBRwIn7tcdK6iKxkvOIq9ZyQIYw5Uk0d2ZYeiyWNnHl9KtfjwKkXN
Yh2N6yd4tH6gUhH9niHyczumTuya4+QUbd8DxZrbkD9G3XnmQdLbjTifAjvZTzk/
zRF/nx399aEYd2LHoBpozuhF9k8otrleC8sWqIjkwVRVX9KYsgNC2CuIgUQCgSpX
hFcx1xtdNwFyq3AdZmrSV1ORBumEb3lhNAtXWwtFfioamDWDIb2m39wgxiNhZrN7
hdpJ2Rt48dI8iTRKRxQ9
=uxIH
-----END PGP SIGNATURE-----
Merge tag 'sunxi-fixes-for-3.14' of https://github.com/mripard/linux into fixes
Allwinner fixes from Maxime Ripard:
Two fixes for device trees additions that got added in 3.14. One fixes the
interrupt types of some IPs, the other fixes up a compatible that got
introduced during 3.14
* tag 'sunxi-fixes-for-3.14' of https://github.com/mripard/linux:
ARM: sunxi: dt: Change the touchscreen compatibles
ARM: sun7i: dt: Fix interrupt trigger types
Signed-off-by: Olof Johansson <olof@lixom.net>
Pull cgroup fixes from Tejun Heo:
"Two cpuset locking fixes from Li. Both tagged for -stable"
* 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cpuset: fix a race condition in __cpuset_node_allowed_softwall()
cpuset: fix a locking issue in cpuset_migrate_mm()
Pull workqueue fix from Tejun Heo:
"This pull request contains a workqueue usage fix for firewire.
For quite a long time now, workqueue only treats two work items
identical iff both their addresses and callbacks match. This is to
avoid introducing false dependency through the work item being
recycled while being executed. This changes non-reentrancy guarantee
for the users of PREPARE[_DELAYED]_WORK() - if the function changes,
reentrancy isn't guaranteed against the previous instance. Firewire
depended on such nonreentrancy guarantee.
This is fixed by doing the work item multiplexing from firewire proper
while keeping the work function unchanged"
* 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
firewire: don't use PREPARE_DELAYED_WORK
regression since v3.10.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTGuNHAAoJEHnzb7JUXXnQlAIP/Ax3QGivoxC4GnidUMWoDwhV
qYLuq6RQyM2GIT/hkUn5yfcWfJvPw4C4zfVehs5gOER+HrN1gRmQA3Ic00VIIqZm
hpvVCZNzfCJMFK9ipkLvOLEdHZkqTyZYWWQFa8IdWGztkWshrZkGih/xImr8YWQb
oOxoCC/548m/R5pdlXCplb2KUZWdpyamvpPxj24obYd1byS+s2gHxx2tGO1coAHR
BP/L+qzWTRh0oW4TzHYUFfVoUy26wIUuB3WZKn1EuhVp7q+UJ9JXQpbwFp2vYREg
4OC/f0TySTLMFjEBu5TD/Z8tDNZXLyljuO8nniTRkPqujBqJqveub7xEdtMhXx5a
JvlDDhqALthVE4zse72swA3kshzkAveHXRDmHjIlNrz6ei/mkyjFsk1gWnza22YA
1BZjhYAQjrv3MDRPD21e7LtNfOWfniNcSC6KeJc8h3MMXlkUX8wKiGdjDtujOnGE
rQ2QAFQdQv7yYavWcH0nbHFqWH5sbct7LVIPJ64lg3pleVXGmc/XGoXNpPykQRJn
WcUXcbO7dc4e8AHIe3DVlUW/KgiucqiLPhC5jpukrXZc039glpOeDPrTeeXYrBaD
UuZ6w8s7S1MmYBbop5bBW6MJHOQcn0jyej8QnYhoClZ7VcAnUezPz1rxx+hUq+H+
ov4pftNGrTVd/pexsYvN
=F0Ho
-----END PGP SIGNATURE-----
Merge tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire fixes from Stefan Richter:
"Fix a use-after-free regression since v3.4 and an initialization
regression since v3.10"
* tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: fix probe failure with Agere/LSI controllers
firewire: net: fix use after free
CPU frequency cannot be scaled.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJTGoj7AAoJEDqPOy9afJhJm6oQAMEw19Xyz/Of4n4/7sTogL+G
SXSQK9Ava2rbYNaPrU267dpgFausCQZNIN2uCsrvQtIsWq6ScInKgVxjXUHhE2rm
F2UkapBBctPhJYKS1W+6WzZzUNNE1Lo4Ab33GlpWV+DBZlJ/XFVDmgbtEs/H59lC
woedh6q9JZSDa8QSk8t4gG7Fkk15ImgXI2pm9/WiCkh7ZHLgBPTGOpe9rVOiieNf
uzALWBhpgySEJXDjqK2O6cbng11EvUJGmLYxrOwfOBwcnLe4fk6t26KEovT0e/2s
HidGVoiGSMWZfY1xrnHaehJvqO7qu7iBsWfn5KRFoMW7NbjDKFUg5YfEIjuh3R/J
KSEHovNO/PmS2xyQowLplgP2pAuHfZ80oRgsOWZ1fG3CCfXghfr5WVMAL1pqtSQV
HzTqm+Aiaf4rbKOTcGISYBjG+X7/wU0w/tvDgjpoMo08mR+RmmTC0wkauWXmDOZQ
P91lWuUtSbpY2B9JdjVNHKTLWpKD8nDBV+aTXj4OwxVIk6s9FhNw6+++9l46OrT8
02BVhU0Z3rg20o69Nx1vShQFN7vhxsKXC9UePdpt3NnlgUUe1JYiVe44ut/AMr5O
PIAXQQXj+zgFQX8PdKtLAvRO2DnF4OpCH758AXywmarYZYDahmc6XSJTEqsk3Tbt
rQCfsnVwgbyQTHfvgqk7
=UEPE
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux
Pull clk driver fix from Mike Turquette:
"Single fix for a clock driver merged in 3.14-rc1. Without this fix
the CPU frequency cannot be scaled"
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
clk: shmobile: rcar-gen2: Use kick bit to allow Z clock frequency change
- ACPI tables in some BIOSes list device resources with size equal
to 0, which doesn't make sense, so we should ignore them, but
instead we try to use them and mangle things completely. Fix
from Zhang Rui.
- Several models of Samsung laptops accumulate EC events when they
are in sleep states which leads to EC buffer overflows that prevent
new events from being signaled after system resume or reboot. This
has been affecting many users for quite a while and may be addressed
by clearing the EC buffer during system resume and system startup on
those machines. From Kieran Clancy.
- If the ACPI sleep control and status registers are not present
(which happens if the Hardware Reduced ACPI mode bit is set in
the ACPI tables, but also may result from BIOS bugs), we should
not try to use ACPI to power off the system and ACPI S5 should
not be listed as supported. Fix from Aubrey Li.
- There's a race condition in cpufreq_get() that leads to a kernel
crash if that function is called at a wrong time. Fix from
Aaron Plattner.
- cpufreq policy objects have to be initialized entirely before
they are first accessed by their users which isn't the case
currently and that potentially leads to various kinds of
breakage that is difficult to debug. Fix from Viresh Kumar.
- Locking is missing in __cpufreq_add_dev() which leads to a race
condition that may trigger a kernel crash. Fix from Viresh Kumar.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJTGnQlAAoJEILEb/54YlRxc8EP/jK95zPwkMwASjNR1s/Gs7/Y
dx4qOYsWSs0Iutn1syyEg57TgjS/14z0UgOnYRiRHAFP+9610SLjZkZZelYQMgFE
N4NyQJB7rTL+ycGH1oovbWQPQlewx4aX6p6XNg4bQHTHwxiik/gS6G7rW4Edxt+h
BIc0SXDf/ldsDJk42v4ie0lSmIRtFF789cXvESi6KmLyNuwiuvGo25uCODVTZxAz
h/ekjcF3PrbAsTeI+yw4J8pceI/IxXksdHp08jQsS7/QYGnMTGo3PXX3NfgSszbg
WPPgk409AHjgGPgtWjkVXCChJbKJ57CtHVQ+PG8EYZy+yMTRLWEhxfGcg9sjcKaJ
Z5gvCQz/g7vF0zk4ScMb6Re+t53lN3SsPwsROj2p/RD7X8uLWIi0Ocuk+iLhermv
HOEg0Loo6gAN3QiviPjUhtVK1cNu3zuCuTbjhDq6L6S4t1LsnbIWd3QdoUBn1GM+
wIgFK/qu11m6QV3q8dlAxE/iMZQ8KrixlKfETPXK6KlrWBPA4v5H4lu5IjNEsmd0
tPbNPFhR4zzlV3QVzlk1NYCV9TxIX7kMl5CIZERLpzkzg9UkgJuaatQx7UjwCcxL
JTUtMxmHGL7m8ToVJgOcBo+WIjRIEGdQ53ZoB0WndwHYuRIt78WoNP5xTi84JEOk
AE/Od2/YjC/lb8u/gxK4
=57PZ
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
- ACPI tables in some BIOSes list device resources with size equal to
0, which doesn't make sense, so we should ignore them, but instead we
try to use them and mangle things completely. Fix from Zhang Rui.
- Several models of Samsung laptops accumulate EC events when they are
in sleep states which leads to EC buffer overflows that prevent new
events from being signaled after system resume or reboot. This has
been affecting many users for quite a while and may be addressed by
clearing the EC buffer during system resume and system startup on
those machines. From Kieran Clancy.
- If the ACPI sleep control and status registers are not present (which
happens if the Hardware Reduced ACPI mode bit is set in the ACPI
tables, but also may result from BIOS bugs), we should not try to use
ACPI to power off the system and ACPI S5 should not be listed as
supported. Fix from Aubrey Li.
- There's a race condition in cpufreq_get() that leads to a kernel
crash if that function is called at a wrong time. Fix from Aaron
Plattner.
- cpufreq policy objects have to be initialized entirely before they
are first accessed by their users which isn't the case currently and
that potentially leads to various kinds of breakage that is difficult
to debug. Fix from Viresh Kumar.
- Locking is missing in __cpufreq_add_dev() which leads to a race
condition that may trigger a kernel crash. Fix from Viresh Kumar.
* tag 'pm+acpi-3.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / EC: Clear stale EC events on Samsung systems
cpufreq: Initialize governor for a new policy under policy->rwsem
cpufreq: Initialize policy before making it available for others to use
cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions
ACPI / sleep: pm_power_off needs more sanity checks to be installed
ACPI / resources: ignore invalid ACPI device resources
It's an enum, not a #define, you can't use it in asm files.
Introduced in commit 5fa10196bd ("x86: Ignore NMIs that come in during
early boot"), and sadly I didn't compile-test things like I should have
before pushing out.
My weak excuse is that the x86 tree generally doesn't introduce stupid
things like this (and the ARM pull afterwards doesn't cause me to do a
compile-test either, since I don't cross-compile).
Cc: Don Zickus <dzickus@redhat.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull ARM fixes from Russell King:
"A number of ARM updates for -rc, covering mostly ARM specific code,
but with one change to modpost.c to allow Thumb section mismatches to
be detected.
ARM changes include reporting when an attempt is made to boot a LPAE
kernel on hardware which does not support LPAE, rather than just being
silent about it.
A number of other minor fixes are included too"
* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
ARM: 7992/1: boot: compressed: ignore bswapsdi2.S
ARM: 7991/1: sa1100: fix compile problem on Collie
ARM: fix noMMU kallsyms symbol filtering
ARM: 7980/1: kernel: improve error message when LPAE config doesn't match CPU
ARM: 7964/1: Detect section mismatches in thumb relocations
ARM: 7963/1: mm: report both sections from PMD
Pull x86 fixes from Peter Anvin:
"A small collection of minor fixes. The FPU stuff is still pending, I
fear. I haven't heard anything from Suresh so I suspect I'm going to
have to dig into the init specifics myself and fix up the patchset"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Ignore NMIs that come in during early boot
x86, trace: Further robustify CR2 handling vs tracing
x86, trace: Fix CR2 corruption when tracing page faults
x86/efi: Quirk out SGI UV
Pull power fixes from Ben Herrenschmidt:
"Here are a couple of powerpc fixes for 3.14.
One is (another!) nasty TM problem, we can crash the kernel by forking
inside a transaction. The other one is a simple fix for an alignment
issue which can hurt in LE mode"
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc: Align p_dyn, p_rela and p_st symbols
powerpc/tm: Fix crash when forking inside a transaction
Developers would say they put a trace_printk() before and after the trace
event but when they enable it (and the trace event said it was enabled) they
would see the trace_printks but not the trace event.
I was not able to reproduce this, but that's because I wasn't looking at
the right location. Recently, another bug came up that showed the issue.
If your kernel supports signed modules but allows for non-signed modules
to be loaded, then when one is, the kernel will silently set the
MODULE_FORCED taint on the module. Although, this taint happens without
the need for insmod --force or anything of the kind, it labels the
module with that taint anyway.
If this tainted module has tracepoints, the tracepoints will be ignored
because of the MODULE_FORCED taint. But no error message will be
displayed. Worse yet, the event infrastructure will still be created
letting users enable the trace event represented by the tracepoint,
although that event will never actually be enabled. This is because
the tracepoint infrastructure allows for non-existing tracepoints to
be enabled for new modules to arrive and have their tracepoints set.
Although there are several things wrong with the above, this change
only addresses the creation of the trace event files for tracepoints
that are not created when a module is loaded and is tainted. This change
will print an error message about the module being tainted and not the
trace events will not be created, and it does not create the trace event
infrastructure.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTFnMPAAoJEKQekfcNnQGuPPwH/Rtwy/siM+ltvlLnEbRjS4RL
9aF5mfJUazmfCaOBMSaMUo92uCbciIVif6icX843JmCdCOR5Hk5SZryBbt2A/dF9
TcMloKNbIn/ad7yZ0O75BJlPnRJ5RZ42edQfW1lkdeWo644C8Kj399fVPt7KU5SH
1KTWyShT05E2fYjp2lMrb+FOFfKerlzkXtgGwJKXnd/7hrbdmKEH/OO8YkMrlVZp
SURPyzNMMVKoUFY797b6FrFRqV04C210BtNcNrd4S3/V9VE4IPS/8YSLfvVaGkD0
e2kVAvIOkwPnYzMZg70jf2R8NlGS2mwaVC+NenBHz3KlpFdaeRu1hFw7/n8h2/s=
=YbJd
-----END PGP SIGNATURE-----
Merge tag 'trace-fixes-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fix from Steven Rostedt:
"In the past, I've had lots of reports about trace events not working.
Developers would say they put a trace_printk() before and after the
trace event but when they enable it (and the trace event said it was
enabled) they would see the trace_printks but not the trace event.
I was not able to reproduce this, but that's because I wasn't looking
at the right location. Recently, another bug came up that showed the
issue.
If your kernel supports signed modules but allows for non-signed
modules to be loaded, then when one is, the kernel will silently set
the MODULE_FORCED taint on the module. Although, this taint happens
without the need for insmod --force or anything of the kind, it labels
the module with that taint anyway.
If this tainted module has tracepoints, the tracepoints will be
ignored because of the MODULE_FORCED taint. But no error message will
be displayed. Worse yet, the event infrastructure will still be
created letting users enable the trace event represented by the
tracepoint, although that event will never actually be enabled. This
is because the tracepoint infrastructure allows for non-existing
tracepoints to be enabled for new modules to arrive and have their
tracepoints set.
Although there are several things wrong with the above, this change
only addresses the creation of the trace event files for tracepoints
that are not created when a module is loaded and is tainted. This
change will print an error message about the module being tainted and
not the trace events will not be created, and it does not create the
trace event infrastructure"
* tag 'trace-fixes-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Do not add event files for modules that fail tracepoints
Pull irq fixes from Thomas Gleixner:
- a bugfix for a long standing waitqueue race
- a trivial fix for a missing include
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
genirq: Include missing header file in irqdomain.c
genirq: Remove racy waitqueue_active check
* pm-cpufreq:
cpufreq: Initialize governor for a new policy under policy->rwsem
cpufreq: Initialize policy before making it available for others to use
cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions
dm-snapshot metadata corruption fix for bug introduced in 3.14-rc1, an
important refcount < 0 fix for the DM persistent data library's space
map metadata interface which fixes corruption reported by a few dm-thinp
users, and last but not least: more extensive fixes than ideal for
dm-thinp's data resize capability (which has had growing pain much like
we've seen from -ENOSPC handling of filesystems that mature). The end
result is dm-thinp now handles metadata operation failure and no data
space error conditions much better than before.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTGgE3AAoJEMUj8QotnQNas7MIAODA8i3lh5c16lyqrvyIK1ql
AcYll4ZFAob85JLNiirDZdlQQe9UIB8YeGSnlXfQrxHRD+OEe5cWdpE+wc53kQjZ
upHDBd2Ai+rBWkUBJdrkju/OSXfVeCxHJNBaxZyyO9msQ8H1cdtxvwMj19HaYdeQ
AexoUeX7dbmcVfdAuJS1yvknxT1z/3BOg8SHxqtL6Jnmph/jngCWW4ElbtA+vCeK
0K4w19WMb3sdVxzrr1TzEwRxc6C5+jwN5TT3h/RnrU60+EGYK1HUZZ1b0TWMlQ3v
uoQ0a9JYmHb7heUB5XdwM6GB3N9jcu0lAKPNYI5JJKTJS5tU4KgdtP89Sf+tsNI=
=UQtZ
-----END PGP SIGNATURE-----
Merge tag 'dm-3.14-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
- dm-cache memory allocation failure fix
- fix DM's Kconfig identation
- dm-snapshot metadata corruption fix for bug introduced in 3.14-rc1
- important refcount < 0 fix for the DM persistent data library's space
map metadata interface which fixes corruption reported by a few
dm-thinp users
and last but not least:
- more extensive fixes than ideal for dm-thinp's data resize capability
(which has had growing pain much like we've seen from -ENOSPC
handling of filesystems that mature).
The end result is dm-thinp now handles metadata operation failure and
no data space error conditions much better than before.
* tag 'dm-3.14-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm space map metadata: fix refcount decrement below 0 which caused corruption
dm thin: fix Documentation for held metadata root feature
dm thin: fix noflush suspend IO queueing
dm thin: fix deadlock in __requeue_bio_list
dm thin: fix out of data space handling
dm thin: ensure user takes action to validate data and metadata consistency
dm thin: synchronize the pool mode during suspend
dm snapshot: fix metadata corruption
dm: fix Kconfig indentation
dm cache mq: fix memory allocation failure for large cache devices
Don Zickus reports:
A customer generated an external NMI using their iLO to test kdump
worked. Unfortunately, the machine hung. Disabling the nmi_watchdog
made things work.
I speculated the external NMI fired, caused the machine to panic (as
expected) and the perf NMI from the watchdog came in and was latched.
My guess was this somehow caused the hang.
----
It appears that the latched NMI stays latched until the early page
table generation on 64 bits, which causes exceptions to happen which
end in IRET, which re-enable NMI. Therefore, ignore NMIs that come in
during early execution, until we have proper exception handling.
Reported-and-tested-by: Don Zickus <dzickus@redhat.com>
Link: http://lkml.kernel.org/r/1394221143-29713-1-git-send-email-dzickus@redhat.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.5+, older with some backport effort
Commit 017f161a55 (ARM: 7877/1: use built-in byte swap function) added
bswapsdi2.{o,S} to arch/arm/boot/compressed/Makefile, but didn't update
the .gitignore. Thus after a a build git status shows bswapsdi2.S as a
new file, which is a little annoying.
This patch updates arch/arm/boot/compressed/.gitignore to ignore
bswapsdi2.S, as we already do for ashldi3.S and others.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Kim Phillips <kim.phillips@freescale.com>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Due to a problem in the MFD Kconfig it was not possible to
compile the UCB battery driver for the Collie SA1100 system,
in turn making it impossible to compile in the battery driver.
(See patch "mfd: include all drivers in subsystem menu".)
After fixing the MFD Kconfig (separate patch) a compile error
appears in the Collie battery driver due to the <mach/collie.h>
implicitly requiring <mach/hardware.h> through <linux/gpio.h>
via <mach/gpio.h> prior to commit
40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface".
Fix this up by including the required header into
<mach/collie.h>.
Cc: stable@vger.kernel.org
Cc: Andrea Adami <andrea.adami@gmail.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
With noMMU, CONFIG_PAGE_OFFSET was not being set correctly. As there's
no MMU, PAGE_OFFSET should be equal to PHYS_OFFSET in all cases. This
commit makes that explicit.
Since we do this, we don't need to mess around in asm/memory.h with
ifdefs to sort this out, so let's get rid of that, and there's no point
offering the "Memory split" option for noMMU as that's meaningless
there.
Fixes: b9b32bf70f ("ARM: use linker magic for vectors and vector stubs")
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This reverts commit 3804fad454.
This commit, together with commit 247bf55727
"xhci 1.0: Limit arbitrarily-aligned scatter gather." were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.
USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.
The proper soluition is to implement the TD fragment rules for xHCI 1.0 hosts,
but for now, revert this patch until scatter gather can be properly supported.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 247bf55727.
This commit, together with commit 3804fad454
"USBNET: ax88179_178a: enable tso if usb host supports sg dma" were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.
USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.
The proper soluition is to implement the TD fragment rules required, but for now
this patch needs to be reverted to get USB 3.0 mass storage devices working at the
level they used to.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We've encountered a rare issue when enumerating two Logitech webcams
after a reboot that doesn't power cycle the USB ports. They are spewing
random data (possibly some leftover UVC buffers) on the second
(full-sized) Get Configuration request of the enumeration phase. Since
the data is random this can potentially cause all kinds of odd behavior,
and since it occasionally happens multiple times (after the kernel
issues another reset due to the garbled configuration descriptor), it is
not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
around the issue.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
