Ian Kent [Tue, 6 May 2014 19:50:06 +0000 (12:50 -0700)]
autofs: fix lockref lookup
commit
6b6751f7feba68d8f5c72b72cc69a1c5a625529c upstream.
autofs needs to be able to see private data dentry flags for its dentrys
that are being created but not yet hashed and for its dentrys that have
been rmdir()ed but not yet freed. It needs to do this so it can block
processes in these states until a status has been returned to indicate
the given operation is complete.
It does this by keeping two lists, active and expring, of dentrys in
this state and uses ->d_release() to keep them stable while it checks
the reference count to determine if they should be used.
But with the recent lockref changes dentrys being freed sometimes don't
transition to a reference count of 0 before being freed so autofs can
occassionally use a dentry that is invalid which can lead to a panic.
Signed-off-by: Ian Kent <raven@themaw.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Mon, 14 Apr 2014 05:13:02 +0000 (13:13 +0800)]
ceph: clear directory's completeness when creating file
commit
0a8a70f96fe1bd3e07c15bb86fd247e76102398a upstream.
When creating a file, ceph_set_dentry_offset() puts the new dentry
at the end of directory's d_subdirs, then set the dentry's offset
based on directory's max offset. The offset does not reflect the
real postion of the dentry in directory. Later readdir reply from
MDS may change the dentry's position/offset. This inconsistency
can cause missing/duplicate entries in readdir result if readdir
is partly satisfied by dcache_readdir().
The fix is clear directory's completeness after creating/renaming
file. It prevents later readdir from using dcache_readdir().
Fixes: http://tracker.ceph.com/issues/8025
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Ertman [Tue, 25 Mar 2014 04:27:55 +0000 (04:27 +0000)]
e1000e: Fix no connectivity when driver loaded with cable out
commit
b20a774495671f037e7160ea2ce8789af6b61533 upstream.
In commit
da1e2046e5, the flow for enabling/disabling an Si errata
workaround (e1000_lv_jumbo_workaround_ich8lan) was changed to fix a problem
with iAMT connections dropping on interface down with jumbo frames set.
Part of this change was to move the function call disabling the workaround
to e1000e_down() from the e1000_setup_rctl() function. The mechanic for
disabling of this workaround involves writing several MAC and PHY registers
back to hardware defaults.
After this commit, when the driver is loaded with the cable out, the PHY
registers are not programmed with the correct default values. This causes
the device to be capable of transmitting packets, but is unable to recieve
them until this workaround is called.
The flow of e1000e's open code relies upon calling the above workaround to
expicitly program these registers either with jumbo frame appropriate settings
or h/w defaults on 82579 and newer hardware.
Fix this issue by adding logic to e1000_setup_rctl() that not only calls
e1000_lv_jumbo_workaround_ich8lan() when jumbo frames are set, to enable the
workaround, but also calls this function to explicitly disable the workaround
in the case that jumbo frames are not set.
Signed-off-by: Dave Ertman <davidx.m.ertman@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Sun, 20 Apr 2014 05:26:41 +0000 (22:26 -0700)]
Input: synaptics - report INPUT_PROP_TOPBUTTONPAD property
commit
43e19888b1fe2a3e8a5543030c5b286cde38b3f5 upstream.
Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD
property for for touchpads with top button areas.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Sun, 20 Apr 2014 05:25:45 +0000 (22:25 -0700)]
Input: Add INPUT_PROP_TOPBUTTONPAD device property
commit
f37c013409bb78ebb958821aa10d069e707cabac upstream.
On some newer laptops with a trackpoint the physical buttons for the
trackpoint have been removed to allow for a larger touchpad. On these
laptops the buttonpad has clearly marked areas on the top which are to be
used as trackpad buttons.
Users of the event device-node need to know about this, so that they can
properly interpret BTN_LEFT events as being a left / right / middle click
depending on where on the button pad the clicking finger is.
This commits adds a INPUT_PROP_TOPBUTTONPAD device property which drivers
for such buttonpads will use to signal to the user that this buttonpad not
only has the normal bottom button area, but also a top button area.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Sun, 20 Apr 2014 03:47:35 +0000 (20:47 -0700)]
Input: i8042 - add firmware_id support
commit
a7c5868c3482127cb308c779b8a6460a3353c17f upstream.
Fill in the new serio firmware_id sysfs attribute for pnp instantiated
8042 serio ports.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Sun, 20 Apr 2014 03:39:35 +0000 (20:39 -0700)]
Input: serio - add firmware_id sysfs attribute
commit
0456c66f4e905e1ca839318219c770988b47975c upstream.
serio devices exposed via platform firmware interfaces such as ACPI may
provide additional identifying information of use to userspace.
We don't associate the serio devices with the firmware device (we don't
set it as parent), so there's no way for userspace to make use of this
information.
We cannot change the parent for serio devices instantiated though a
firmware interface as that would break suspend / resume ordering.
Therefore this patch adds a new firmware_id sysfs attribute so that
userspace can get a string from there with any additional identifying
information the firmware interface may provide.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chew, Kean ho [Fri, 28 Feb 2014 16:03:56 +0000 (00:03 +0800)]
i2c: i801: enable Intel BayTrail SMBUS
commit
1b31e9b76ef8c62291e698dfdb973499986a7f68 upstream.
Add Device ID of Intel BayTrail SMBus Controller.
Signed-off-by: Chew, Kean ho <kean.ho.chew@intel.com>
Signed-off-by: Chew, Chiau Ee <chiau.ee.chew@intel.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: "Chang, Rebecca Swee Fun" <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Salva Peiró [Wed, 30 Apr 2014 17:48:02 +0000 (19:48 +0200)]
media: media-device: fix infoleak in ioctl media_enum_entities()
commit
e6a623460e5fc960ac3ee9f946d3106233fd28d8 upstream.
This fixes CVE-2014-1739.
Signed-off-by: Salva Peiró <speiro@ai2.upv.es>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 7 Nov 2013 08:08:44 +0000 (08:08 +0000)]
clk: vexpress: NULL dereference on error path
commit
6b4ed8b00e93bd31f24a25f59ed8d1b808d0cc00 upstream.
If the allocation fails then we dereference the NULL in the error path.
Just return directly.
Fixes:
ed27ff1db869 ('clk: Versatile Express clock generators ("osc") driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Chen [Mon, 17 Mar 2014 23:52:26 +0000 (16:52 -0700)]
crypto: crypto_wq - Fix late crypto work queue initialization
commit
130fa5bc81b44b6cc1fbdea3abf6db0da22964e0 upstream.
The crypto algorithm modules utilizing the crypto daemon could
be used early when the system start up. Using module_init
does not guarantee that the daemon's work queue is initialized
when the cypto alorithm depending on crypto_wq starts. It is necessary
to initialize the crypto work queue earlier at the subsystem
init time to make sure that it is initialized
when used.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aristeu Rozanski [Mon, 5 May 2014 15:18:59 +0000 (11:18 -0400)]
device_cgroup: check if exception removal is allowed
commit
d2c2b11cfa134f4fbdcc34088824da26a084d8de upstream.
[PATCH v3 1/2] device_cgroup: check if exception removal is allowed
When the device cgroup hierarchy was introduced in
bd2953ebbb53 - devcg: propagate local changes down the hierarchy
a specific case was overlooked. Consider the hierarchy bellow:
A default policy: ALLOW, exceptions will deny access
\
B default policy: ALLOW, exceptions will deny access
There's no need to verify when an new exception is added to B because
in this case exceptions will deny access to further devices, which is
always fine. Hierarchy in device cgroup only makes sure B won't have
more access than A.
But when an exception is removed (by writing devices.allow), it isn't
checked if the user is in fact removing an inherited exception from A,
thus giving more access to B.
Example:
# echo 'a' >A/devices.allow
# echo 'c 1:3 rw' >A/devices.deny
# echo $$ >A/B/tasks
# echo >/dev/null
-bash: /dev/null: Operation not permitted
# echo 'c 1:3 w' >A/B/devices.allow
# echo >/dev/null
#
This shouldn't be allowed and this patch fixes it by making sure to never allow
exceptions in this case to be removed if the exception is partially or fully
present on the parent.
v3: missing '*' in function description
v2: improved log message and formatting fixes
Cc: cgroups@vger.kernel.org
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aristeu Rozanski [Mon, 21 Apr 2014 16:13:03 +0000 (12:13 -0400)]
device_cgroup: rework device access check and exception checking
commit
79d719749d23234e9b725098aa49133f3ef7299d upstream.
Whenever a device file is opened and checked against current device
cgroup rules, it uses the same function (may_access()) as when a new
exception rule is added by writing devices.{allow,deny}. And in both
cases, the algorithm is the same, doesn't matter the behavior.
First problem is having device access to be considered the same as rule
checking. Consider the following structure:
A (default behavior: allow, exceptions disallow access)
\
B (default behavior: allow, exceptions disallow access)
A new exception is added to B by writing devices.deny:
c 12:34 rw
When checking if that exception is allowed in may_access():
if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) {
if (behavior == DEVCG_DEFAULT_ALLOW) {
/* the exception will deny access to certain devices */
return true;
Which is ok, since B is not getting more privileges than A, it doesn't
matter and the rule is accepted
Now, consider it's a device file open check and the process belongs to
cgroup B. The access will be generated as:
behavior: allow
exception: c 12:34 rw
The very same chunk of code will allow it, even if there's an explicit
exception telling to do otherwise.
A simple test case:
# mkdir new_group
# cd new_group
# echo $$ >tasks
# echo "c 1:3 w" >devices.deny
# echo >/dev/null
# echo $?
0
This is a serious bug and was introduced on
c39a2a3018f8 devcg: prepare may_access() for hierarchy support
To solve this problem, the device file open function was split from the
new exception check.
Second problem is how exceptions are processed by may_access(). The
first part of the said function tries to match fully with an existing
exception:
list_for_each_entry_rcu(ex, &dev_cgroup->exceptions, list) {
if ((refex->type & DEV_BLOCK) && !(ex->type & DEV_BLOCK))
continue;
if ((refex->type & DEV_CHAR) && !(ex->type & DEV_CHAR))
continue;
if (ex->major != ~0 && ex->major != refex->major)
continue;
if (ex->minor != ~0 && ex->minor != refex->minor)
continue;
if (refex->access & (~ex->access))
continue;
match = true;
break;
}
That means the new exception should be contained into an existing one to
be considered a match:
New exception Existing match? notes
b 12:34 rwm b 12:34 rwm yes
b 12:34 r b *:34 rw yes
b 12:34 rw b 12:34 w no extra "r"
b *:34 rw b 12:34 rw no too broad "*"
b *:34 rw b *:34 rwm yes
Which is fine in some cases. Consider:
A (default behavior: deny, exceptions allow access)
\
B (default behavior: deny, exceptions allow access)
In this case the full match makes sense, the new exception cannot add
more access than the parent allows
But this doesn't always work, consider:
A (default behavior: allow, exceptions disallow access)
\
B (default behavior: deny, exceptions allow access)
In this case, a new exception in B shouldn't match any of the exceptions
in A, after all you can't allow something that was forbidden by A. But
consider this scenario:
New exception Existing in A match? outcome
b 12:34 rw b 12:34 r no exception is accepted
Because the new exception has "w" as extra, it doesn't match, so it'll
be added to B's exception list.
The same problem can happen during a file access check. Consider a
cgroup with allow as default behavior:
Access Exception match?
b 12:34 rw b 12:34 r no
In this case, the access didn't match any of the exceptions in the
cgroup, which is required since exceptions will disallow access.
To solve this problem, two new functions were created to match an
exception either fully or partially. In the example above, a partial
check will be performed and it'll produce a match since at least
"b 12:34 r" from "b 12:34 rw" access matches.
Cc: cgroups@vger.kernel.org
Cc: Tejun Heo <tj@kernel.org>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Mon, 14 Apr 2014 16:52:14 +0000 (18:52 +0200)]
Documentation: Update stable address in Chinese and Japanese translations
commit
98b0f811aade1b7c6e7806c86aa0befd5919d65f upstream.
The English and Korean translations were updated, the Chinese and Japanese
weren't.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emil Goode [Sun, 9 Mar 2014 20:06:51 +0000 (21:06 +0100)]
brcmsmac: fix deadlock on missing firmware
commit
8fc1e8c240aab968db658b2d8d079b4391207a36 upstream.
When brcm80211 firmware is not installed networking hangs.
A deadlock happens because we call ieee80211_unregister_hw()
from the .start callback of struct ieee80211_ops. When .start
is called we are under rtnl lock and ieee80211_unregister_hw()
tries to take it again.
Function call stack:
dev_change_flags()
__dev_change_flags()
__dev_open()
ASSERT_RTNL() <-- Assert rtnl lock
ops->ndo_open()
.ndo_open = ieee80211_open,
ieee80211_open()
ieee80211_do_open()
drv_start()
local->ops->start()
.start = brcms_ops_start,
brcms_ops_start()
brcms_remove()
ieee80211_unregister_hw()
rtnl_lock() <-- Here we deadlock
Introduced by:
commit
25b5632fb35ca61b8ae3eee235edcdc2883f7a5e
("brcmsmac: request firmware in .start() callback")
This patch fixes the bug by removing the call to brcms_remove()
and moves the brcms_request_fw() call to the top of the .start
callback to not initiate anything unless firmware is installed.
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Sun, 6 Apr 2014 22:20:03 +0000 (15:20 -0700)]
leds: leds-pwm: properly clean up after probe failure
commit
392369019eb96e914234ea21eda806cb51a1073e upstream.
When probing with DT, we add each LED one at a time. If we find a LED
without a PWM device (because it is not available yet) we fail the
initialisation, unregister previous LEDs, and then by way of managed
resources, we free the structure.
The problem with this is we may have a scheduled and active work_struct
in this structure, and this results in a nasty kernel oops.
We need to cancel this work_struct properly upon cleanup - and the
cleanup we require is the same cleanup as we do when the LED platform
device is removed. Rather than writing this same code three times,
move it into a separate function and use it in all three places.
Fixes:
c971ff185f64 ("leds: leds-pwm: Defer led_pwm_set() if PWM can sleep")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Peres [Thu, 13 Mar 2014 23:26:52 +0000 (00:26 +0100)]
drm/nouveau/pm/fan: drop the fan lock in fan_update() before rescheduling
commit
61679fe153b2b9ea5b5e2ab93305419e85e99a9d upstream.
This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would have been taken
before calling fan_update(), leading to a deadlock.
We should Cc: <stable@vger.kernel.org> # 3.9+
Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Tested-by: Timothée Ravier <tim@siosm.fr>
Tested-by: Boris Fersing (IRC nick fersingb, no public email address)
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christoph Paasch [Fri, 21 Mar 2014 11:02:09 +0000 (04:02 -0700)]
igb: Unset IGB_FLAG_HAS_MSIX-flag when falling back to msi-only
commit
b709323d2477614823a38c2f2a9a206e087e28fc upstream.
Prior to
cd14ef54d25 (igb: Change to use statically allocated array for
MSIx entries), having msix_entries different from NULL was an indicator
that MSIX is enabled.
In igb_set_interrupt_capabiliy we may fall back to MSI-only. Prior to
the above patch msix_entries was set to NULL by
igb_reset_interrupt_capability.
However, now we are checking the flag for IGB_FLAG_HAS_MSIX and so the
stack gets completly confused:
[ 42.659791] ------------[ cut here ]------------
[ 42.715032] WARNING: CPU: 7 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x15c/0x1fb()
[ 42.848263] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out
[ 42.923253] Modules linked in:
[ 42.959875] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.14.0-rc2-mptcp #437
[ 43.043184] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011
[ 43.119215]
0000000000000108 ffff88023fdc3da8 ffffffff81487847 0000000000000108
[ 43.208165]
ffff88023fdc3df8 ffff88023fdc3de8 ffffffff81034e7d ffff88023fdc3dd8
[ 43.297120]
ffffffff813fff10 ffff880236018000 ffff880236b178c0 0000000000000008
[ 43.386071] Call Trace:
[ 43.415303] <IRQ> [<
ffffffff81487847>] dump_stack+0x49/0x62
[ 43.484174] [<
ffffffff81034e7d>] warn_slowpath_common+0x77/0x91
[ 43.556049] [<
ffffffff813fff10>] ? dev_watchdog+0x15c/0x1fb
[ 43.623759] [<
ffffffff81034f2b>] warn_slowpath_fmt+0x41/0x43
[ 43.692511] [<
ffffffff813fff10>] dev_watchdog+0x15c/0x1fb
[ 43.758141] [<
ffffffff813ffdb4>] ? __netdev_watchdog_up+0x64/0x64
[ 43.832091] [<
ffffffff8103cd04>] call_timer_fn+0x17/0x6f
[ 43.896682] [<
ffffffff8103cebe>] run_timer_softirq+0x162/0x1a2
[ 43.967511] [<
ffffffff81038520>] __do_softirq+0xcd/0x1cc
[ 44.032104] [<
ffffffff81038689>] irq_exit+0x3a/0x48
[ 44.091492] [<
ffffffff81026d43>] smp_apic_timer_interrupt+0x43/0x50
[ 44.167525] [<
ffffffff8148c24a>] apic_timer_interrupt+0x6a/0x70
[ 44.239392] <EOI> [<
ffffffff8100992c>] ? default_idle+0x6/0x8
[ 44.310343] [<
ffffffff81009b31>] arch_cpu_idle+0x13/0x18
[ 44.374934] [<
ffffffff81066126>] cpu_startup_entry+0xa7/0x101
[ 44.444724] [<
ffffffff81025660>] start_secondary+0x1b2/0x1b7
[ 44.513472] ---[ end trace
a5a075fd4e7f854f ]---
[ 44.568753] igb 0000:04:00.0 eth0: Reset adapter
[ 46.206945] random: nonblocking pool is initialized
[ 46.465670] irq 44: nobody cared (try booting with the "irqpoll" option)
[ 46.545862] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G W 3.14.0-rc2-mptcp #437
[ 46.640610] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011
[ 46.716641]
ffff8802363f8c84 ffff88023fdc3e38 ffffffff81487847 00000000a03cdb6d
[ 46.805598]
ffff8802363f8c00 ffff88023fdc3e68 ffffffff81068489 0000007f81825400
[ 46.894539]
ffff8802363f8c00 0000000000000000 0000000000000000 ffff88023fdc3ea8
[ 46.983484] Call Trace:
[ 47.012714] <IRQ> [<
ffffffff81487847>] dump_stack+0x49/0x62
[ 47.081585] [<
ffffffff81068489>] __report_bad_irq+0x35/0xc1
[ 47.149295] [<
ffffffff81068683>] note_interrupt+0x16e/0x1ea
[ 47.217006] [<
ffffffff8106679e>] handle_irq_event_percpu+0x116/0x12e
[ 47.294075] [<
ffffffff810667e9>] handle_irq_event+0x33/0x4f
[ 47.361787] [<
ffffffff81068c95>] handle_fasteoi_irq+0x83/0xd1
[ 47.431577] [<
ffffffff81003d5b>] handle_irq+0x1f/0x28
[ 47.493047] [<
ffffffff81003567>] do_IRQ+0x4e/0xd4
[ 47.550358] [<
ffffffff8148b06a>] common_interrupt+0x6a/0x6a
[ 47.618066] <EOI> [<
ffffffff8100992c>] ? default_idle+0x6/0x8
[ 47.689016] [<
ffffffff81009b31>] arch_cpu_idle+0x13/0x18
[ 47.753605] [<
ffffffff81066126>] cpu_startup_entry+0xa7/0x101
[ 47.823397] [<
ffffffff81025660>] start_secondary+0x1b2/0x1b7
[ 47.892146] handlers:
[ 47.919301] [<
ffffffff812fbd7d>] igb_intr
So, this patch unsets the flag to indicate that we are not using MSIX.
This patch does exactly this: Unsetting the flag when falling back to MSI.
Fixes:
cd14ef54d25b (igb: Change to use statically allocated array for MSIx entries)
Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christoph Paasch [Fri, 21 Mar 2014 10:48:19 +0000 (03:48 -0700)]
igb: Fix Null-pointer dereference in igb_reset_q_vector
commit
cb06d102327eadcd1bdc480bfd9f8876251d1007 upstream.
When igb_set_interrupt_capability() calls
igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset),
num_q_vectors has been set but no vector has yet been allocated.
igb_reset_interrupt_capability() will then call igb_reset_q_vector,
which assumes that the vector is allocated. As this is not the case, we
are accessing a NULL-pointer.
This patch fixes it by checking that q_vector is indeed different from
NULL.
Fixes:
02ef6e1d0b0023 (igb: Fix queue allocation method to accommodate changing during runtime)
Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 15 Jan 2014 06:43:39 +0000 (06:43 +0000)]
i40e: potential array underflow in i40e_vc_process_vf_msg()
commit
c243e96335c56e56dcf6a00593104554fb06b689 upstream.
If "vf_id" is smaller than hw->func_caps.vf_base_id then it leads to
an array underflow of the pf->vf[] array. This is unlikely to happen
unless the hardware is bad, but it's a small change and it silences a
static checker warning.
Fixes:
7efa84b7abc1 ('i40e: support VFs on PFs other than 0')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aaron Lu [Mon, 12 May 2014 08:55:45 +0000 (16:55 +0800)]
drm/i915: restore backlight precision when converting from ACPI
commit
721e82c08c1afd6b47367b0e0c4a62140b0667f3 upstream.
When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit
22505b82a2 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it also caused a problem that the converted hardware
level doesn't quite represent the intended value: say user wants maximum
backlight level(255 in opregion's range), then we will calculate the
actual hardware level to be: level = freq / max * level, where freq is
the hardware's max backlight level(937 on an user's box), and max and
level are all 255. The converted value should be 937 but the above
calculation will yield 765.
To fix this issue, just use 64 bits to do the calculation to keep the
precision and avoid overflow at the same time.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491
Reported-by: Nico Schottelius <nico-bugzilla.kernel.org@schottelius.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jani Nikula [Fri, 9 May 2014 11:52:34 +0000 (14:52 +0300)]
drm/i915/vlv: reset VLV media force wake request register
commit
05adaf1f101f25f40f12c29403e6488f0e45f6b6 upstream.
Media force wake get hangs the machine when the system is booted without
displays attached. The assumption is that (at least some versions of)
the firmware has skipped some initialization in that case.
Empirical evidence suggests we need to reset the media force wake
request register in addition to the render one to avoid hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895
Reported-by: Imre Deak <imre.deak@intel.com>
Reported-by: Darren Hart <dvhart@linux.intel.com>
Tested-by: Darren Hart <dvhart@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maarten Lankhorst [Thu, 1 May 2014 11:58:05 +0000 (13:58 +0200)]
drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flip
commit
806cbc5026933a781b66adecf6d1658fde9138e6 upstream.
Fixes a regression introduced by
060810d7abaabca "drm/nouveau: fix locking
issues in page flipping paths". chan->cli->mutex is unlocked a second time
in the fail_unreserve path, fix this by moving mutex_unlock down.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilia Mirkin [Wed, 26 Mar 2014 23:37:21 +0000 (19:37 -0400)]
drm/nouveau/acpi: allow non-optimus setups to load vbios from acpi
commit
a3d0b1218d351c6e6f3cea36abe22236a08cb246 upstream.
There appear to be a crop of new hardware where the vbios is not
available from PROM/PRAMIN, but there is a valid _ROM method in ACPI.
The data read from PCIROM almost invariably contains invalid
instructions (still has the x86 opcodes), which makes this a low-risk
way to try to obtain a valid vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Sat, 26 Apr 2014 20:59:04 +0000 (21:59 +0100)]
rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()
commit
3234f5b06fc3094176a86772cc64baf3decc98fc upstream.
Fixes:
a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liu Hua [Thu, 27 Mar 2014 05:56:18 +0000 (06:56 +0100)]
ARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr
commit
8fad87bca7ac9737e413ba5f1656f1114a8c314d upstream.
When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will
overflow if pfn >= 0x100000 in copy_oldmem_page.
So use __pfn_to_phys for converting.
Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leif Lindholm [Thu, 17 Apr 2014 17:41:59 +0000 (18:41 +0100)]
arm: dts: Fix missing device_type="memory" for ste-ccu8540
commit
bfaed5abad998bfc88a66e6e71c7b08dcf82f04e upstream.
The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
its memory node, relying on an old ppc quirk in order to discover its
memory. Fix the data so that all parsing code can handle it correctly.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Petazzoni [Mon, 14 Apr 2014 15:29:21 +0000 (17:29 +0200)]
ARM: mvebu: fix NOR bus-width in Armada XP OpenBlocks AX3 Device Tree
commit
6e20bae8a39c40d4e03698e4160bad2d2629062b upstream.
The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.
This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP OpenBlocks AX3 Device Tree: a 8 bits bus width was
declared, even though the hardware actually has a 16 bits bus width
connection with the NOR flash.
Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.
This bug was introduced in commit
a7d4f81821f7eec3175f8e23dd6949c71ab2da43 ('ARM: mvebu: Add support for
NOR flash device on Openblocks AX3 board') which was merged in v3.10.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com
Fixes:
a7d4f81821f7 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board')
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Petazzoni [Mon, 14 Apr 2014 15:29:20 +0000 (17:29 +0200)]
ARM: mvebu: fix NOR bus-width in Armada XP DB Device Tree
commit
f3aec8f3f05025e7b450102dae0759375346706e upstream.
The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.
This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP DB Device Tree: a 8 bits bus width was declared, even
though the hardware actually has a 16 bits bus width connection with
the NOR flash.
Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.
This bug was introduced in commit
b484ff42df475c5087d614c4d477273e1906bcb9 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-DB board') which was merged in v3.11.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397489361-5833-4-git-send-email-thomas.petazzoni@free-electrons.com
Fixes:
b484ff42df47 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board')
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Petazzoni [Mon, 14 Apr 2014 15:29:19 +0000 (17:29 +0200)]
ARM: mvebu: fix NOR bus-width in Armada XP GP Device Tree
commit
1a88f809ccb5db1509a7514b187c00b3a995fc82 upstream.
The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.
This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP GP Device Tree: a 8 bits bus width was declared, even
though the hardware actually has a 16 bits bus width connection with
the NOR flash.
Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.
This bug was introduced in commit
da8d1b38356853c37116f9afa29f15648d7fb159 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-GP board') which was merged in v3.10.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com
Fixes:
da8d1b383568 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board')
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Sun, 13 Apr 2014 18:44:46 +0000 (20:44 +0200)]
ARM: common: edma: Fix xbar mapping
commit
cf7eb979116c2568e8bc3b6a7269c7a359864ace upstream.
This is another great example of trainwreck engineering:
commit
2646a0e529 (ARM: edma: Add EDMA crossbar event mux support)
added support for using EDMA on peripherals which have no direct EDMA
event mapping.
The code compiles and does not explode in your face, but that's it.
1) Reading an u16 array from an u32 device tree array simply does not
work. Even if the function is named "edma_of_read_u32_to_s16_array".
It merily calls of_property_read_u16_array. So the resulting 16bit
array will have every other entry = 0.
2) The DT entry for the xbar registers related to xbar has length 0x10
instead of the real length: 0xfd0 - 0xf90 = 0x40.
Not a real problem as it does not cross a page boundary, but
wrong nevertheless.
3) But none of this matters as the mapping never happens:
After reading nonsense edma_of_read_u32_to_s16_array() invalidates
the first array entry pair, so nobody can ever notice the
braindamage by immediate explosion.
Seems the QA criteria for this code was solely not to explode when
someone adds edma-xbar-event-map entries to the DT. Goal achieved,
congratulations!
Not really helpful if someone wants to use edma on a device which
requires a xbar mapping.
Fix the issues by:
- annotating the device tree entry with "/bits/ 16" as documented in
the of_property_read_u16_array kernel doc
- make the size of the xbar register mapping correct
- invalidating the end of the array and not the start
This convoluted mess wants to be completely rewritten as there is no
point to keep the xbar_chan array memory and the iomapping of the xbar
regs around forever. Marking the xbar mapped channels as used should
be done right there.
But that's a different issue and this patch is small enough to make it
work and allows a simple backport for stable.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sascha Hauer [Tue, 6 May 2014 11:01:34 +0000 (13:01 +0200)]
ARM: dts: i.MX53: Fix ipu register space size
commit
6d66da89bf4422c0a0693627fb3e25f74af50f92 upstream.
The IPU register space is 128MB, not 2GB.
Fixes:
abed9a6bf2bb 'ARM i.MX53: Add IPU support'
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Hesselbarth [Wed, 30 Apr 2014 12:56:28 +0000 (14:56 +0200)]
ARM: dts: kirkwood: fix mislocated pcie-controller nodes
commit
788296b2d19d16ec33aba0a5ad1544d50bb58601 upstream.
Commit
54397d85349f
("ARM: kirkwood: Relocate PCIe device tree nodes")
moved the pcie-controller nodes for the Kirkwood SoCs to the mbus
bus node. For some reason, two boards were not properly converted
and have their pci-controller nodes still in the ocp bus node.
As the corresponding SoC pcie-controller does not exist anymore,
it is likely that pcie is broken on those boards since above commit.
Fix it by moving the pcie related nodes to the correct location.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Fixes:
54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes")
Acked-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lkml.kernel.org/r/1398862602-29595-2-git-send-email-sebastian.hesselbarth@gmail.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Petazzoni [Sun, 13 Apr 2014 14:39:38 +0000 (16:39 +0200)]
ARM: orion5x: fix target ID for crypto SRAM window
commit
1cc9d48145b81e307fab94a5cf6ee66ec2f0de60 upstream.
In commit
4ca2c04085a1caa903e92a5fc0da25362150aac2 ('ARM: orion5x:
Move to ID based window creation'), the mach-orion5x code was changed
to use the new mvebu-mbus API. However, in the process, a mistake was
made on the crypto SRAM window target ID: it should have been 0x9
(verified in the datasheet) and not 0x0.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Link: https://lkml.kernel.org/r/1397400006-4315-2-git-send-email-thomas.petazzoni@free-electrons.com
Fixes:
4ca2c04085a1 ('ARM: orion5x: Move to ID based window creation')
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Weiner [Tue, 6 May 2014 19:50:07 +0000 (12:50 -0700)]
revert "mm: vmscan: do not swap anon pages just because free+file is low"
commit
623762517e2370be3b3f95f4fe08d6c063a49b06 upstream.
This reverts commit
0bf1457f0cfc ("mm: vmscan: do not swap anon pages
just because free+file is low") because it introduced a regression in
mostly-anonymous workloads, where reclaim would become ineffective and
trap every allocating task in direct reclaim.
The problem is that there is a runaway feedback loop in the scan balance
between file and anon, where the balance tips heavily towards a tiny
thrashing file LRU and anonymous pages are no longer being looked at.
The commit in question removed the safe guard that would detect such
situations and respond with forced anonymous reclaim.
This commit was part of a series to fix premature swapping in loads with
relatively little cache, and while it made a small difference, the cure
is obviously worse than the disease. Revert it.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Rafael Aquini <aquini@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vlastimil Babka [Tue, 6 May 2014 19:50:03 +0000 (12:50 -0700)]
mm/compaction: make isolate_freepages start at pageblock boundary
commit
49e068f0b73dd042c186ffa9b420a9943e90389a upstream.
The compaction freepage scanner implementation in isolate_freepages()
starts by taking the current cc->free_pfn value as the first pfn. In a
for loop, it scans from this first pfn to the end of the pageblock, and
then subtracts pageblock_nr_pages from the first pfn to obtain the first
pfn for the next for loop iteration.
This means that when cc->free_pfn starts at offset X rather than being
aligned on pageblock boundary, the scanner will start at offset X in all
scanned pageblock, ignoring potentially many free pages. Currently this
can happen when
a) zone's end pfn is not pageblock aligned, or
b) through zone->compact_cached_free_pfn with CONFIG_HOLES_IN_ZONE
enabled and a hole spanning the beginning of a pageblock
This patch fixes the problem by aligning the initial pfn in
isolate_freepages() to pageblock boundary. This also permits replacing
the end-of-pageblock alignment within the for loop with a simple
pageblock_nr_pages increment.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Heesub Shin <heesub.shin@samsung.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Christoph Lameter <cl@linux.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Dongjun Shin <d.j.shin@samsung.com>
Cc: Sunghwan Yun <sunghwan.yun@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rik van Riel [Tue, 6 May 2014 19:50:01 +0000 (12:50 -0700)]
mm/page-writeback.c: fix divide by zero in pos_ratio_polynom
commit
d5c9fde3dae750889168807038243ff36431d276 upstream.
It is possible for "limit - setpoint + 1" to equal zero, after getting
truncated to a 32 bit variable, and resulting in a divide by zero error.
Using the fully 64 bit divide functions avoids this problem. It also
will cause pos_ratio_polynom() to return the correct value when
(setpoint - limit) exceeds 2^32.
Also uninline pos_ratio_polynom, at Andrew's request.
Signed-off-by: Rik van Riel <riel@redhat.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fabian Frederick [Tue, 6 May 2014 19:50:11 +0000 (12:50 -0700)]
fs/affs/super.c: bugfix / double free
commit
d353efd02357a74753cd45f367a2d3d357fd6904 upstream.
Commit
842a859db26b ("affs: use ->kill_sb() to simplify ->put_super()
and failure exits of ->mount()") adds .kill_sb which frees sbi but
doesn't remove sbi free in case of parse_options error causing double
free+random crash.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christoph Hellwig [Sun, 4 May 2014 11:03:32 +0000 (13:03 +0200)]
posix_acl: handle NULL ACL in posix_acl_equiv_mode
commit
50c6e282bdf5e8dabf8d7cf7b162545a55645fd9 upstream.
Various filesystems don't bother checking for a NULL ACL in
posix_acl_equiv_mode, and thus can dereference a NULL pointer when it
gets passed one. This usually happens from the NFS server, as the ACL tools
never pass a NULL ACL, but instead of one representing the mode bits.
Instead of adding boilerplat to all filesystems put this check into one place,
which will allow us to remove the check from other filesystems as well later
on.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Ben Greear <greearb@candelatech.com>
Reported-by: Marco Munderloh <munderl@tnt.uni-hannover.de>,
Cc: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marcel Holtmann [Tue, 22 Apr 2014 21:04:16 +0000 (14:04 -0700)]
Revert "Bluetooth: Enable autosuspend for Intel Bluetooth device"
commit
3c49aa852e00978ba2f1a4d1e4598a0c669a5347 upstream.
This reverts commit
d2bee8fb6e18f6116aada39851918473761f7ab1.
Enabling autosuspend for Intel Bluetooth devices has been shown to not
work reliable. It does work for some people with certain combinations
of USB host controllers, but for others it puts the device to sleep and
it will not wake up for any event.
These events can be important ones like HCI Inquiry Complete or HCI
Connection Request. The events will arrive as soon as you poke the
device with a new command, but that is not something we can do in
these cases.
Initially there were patches to the xHCI USB controller that fixed
this for some people, but not for all. This could be well a problem
somewhere in the USB subsystem or in the USB host controllers or
just plain a hardware issue somewhere. At this moment we just do
not know and the only safe action is to revert this patch.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mohammed Habibulla [Thu, 17 Apr 2014 18:37:13 +0000 (11:37 -0700)]
Bluetooth: Add support for Lite-on [04ca:3007]
commit
1fb4e09a7e780b915dbd172592ae7e2a4c071065 upstream.
Add support for the AR9462 chip
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=3007 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hedberg [Fri, 11 Apr 2014 19:02:32 +0000 (12:02 -0700)]
Bluetooth: Fix redundant encryption request for reauthentication
commit
09da1f3463eb81d59685df723b1c5950b7570340 upstream.
When we're performing reauthentication (in order to elevate the
security level from an unauthenticated key to an authenticated one) we
do not need to issue any encryption command once authentication
completes. Since the trigger for the encryption HCI command is the
ENCRYPT_PEND flag this flag should not be set in this scenario.
Instead, the REAUTH_PEND flag takes care of all necessary steps for
reauthentication.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hedberg [Fri, 11 Apr 2014 19:02:31 +0000 (12:02 -0700)]
Bluetooth: Fix triggering BR/EDR L2CAP Connect too early
commit
9eb1fbfa0a737fd4d3a6d12d71c5ea9af622b887 upstream.
Commit
1c2e004183178 introduced an event handler for the encryption key
refresh complete event with the intent of fixing some LE/SMP cases.
However, this event is shared with BR/EDR and there we actually want to
act only on the auth_complete event (which comes after the key refresh).
If we do not do this we may trigger an L2CAP Connect Request too early
and cause the remote side to return a security block error.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clemens Ladisch [Thu, 1 May 2014 10:20:22 +0000 (12:20 +0200)]
ALSA: usb-audio: work around corrupted TEAC UD-H01 feedback data
commit
7040b6d1febfdbd9c1595efb751d492cd2503f96 upstream.
The TEAC UD-H01 firmware sends wrong feedback frequency values, thus
causing the PC to send the samples at a wrong rate, which results in
clicks and crackles in the output.
Add a workaround to detect and fix the corruption.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
[mick37@gmx.de: use sender->udh01_fb_quirk rather than
ep->udh01_fb_quirk in snd_usb_handle_sync_urb()]
Reported-and-tested-by: Mick <mick37@gmx.de>
Reported-and-tested-by: Andrea Messa <andr.messa@tiscali.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Thu, 17 Apr 2014 09:08:47 +0000 (11:08 +0200)]
rt2x00: fix beaconing on USB
commit
8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream.
When disable beaconing we clear register with beacon and newer set it
back, what make we stop send beacons infinitely.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniele Forsi [Mon, 28 Apr 2014 15:09:11 +0000 (17:09 +0200)]
USB: Nokia 5300 should be treated as unusual dev
commit
6ed07d45d09bc2aa60e27b845543db9972e22a38 upstream.
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Victor A. Santos [Sun, 27 Apr 2014 02:20:14 +0000 (23:20 -0300)]
USB: Nokia 305 should be treated as unusual dev
commit
f0ef5d41792a46a1085dead9dfb0bdb2c574638e upstream.
Signed-off-by: Victor A. Santos <victoraur.santos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniele Forsi [Tue, 29 Apr 2014 09:44:03 +0000 (11:44 +0200)]
usb: storage: shuttle_usbat: fix discs being detected twice
commit
df602c2d2358f02c6e49cffc5b49b9daa16db033 upstream.
Even if the USB-to-ATAPI converter supported multiple LUNs, this
driver would always detect the same physical device or media because
it doesn't use srb->device->lun in any way.
Tested with an Hewlett-Packard CD-Writer Plus 8200e.
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Sun, 27 Apr 2014 14:47:42 +0000 (16:47 +0200)]
usb: qcserial: add a number of Dell devices
commit
4d7c0136a54f62501f8a34c4d08a5e0258d3d3ca upstream.
Dan writes:
"The Dell drivers use the same configuration for PIDs:
81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card
81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card
81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card
81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card
81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card
These devices are all clearly Sierra devices, but are also definitely
Gobi-based. The A8 might be the MC7700/7710 and A9 is likely a MC7750.
>From DellGobi5kSetup.exe from the Dell drivers:
usbif0: serial/firmware loader?
usbif2: nmea
usbif3: modem/ppp
usbif8: net/QMI"
Reported-by: AceLan Kao <acelan.kao@canonical.com>
Reported-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Thu, 1 May 2014 19:21:42 +0000 (15:21 -0400)]
USB: OHCI: fix problem with global suspend on ATI controllers
commit
c1db30a2a79eb59997b13b8cabf2a50bea9f04e1 upstream.
Some OHCI controllers from ATI/AMD seem to have difficulty with
"global" USB suspend, that is, suspending an entire USB bus without
setting the suspend feature for each port connected to a device. When
we try to resume the child devices, the controller gives timeout
errors on the unsuspended ports, requiring resets, and can even cause
ohci-hcd to hang; see
http://marc.info/?l=linux-usb&m=
139514332820398&w=2
and the following messages.
This patch fixes the problem by adding a new quirk flag to ohci-hcd.
The flag causes the ohci_rh_suspend() routine to suspend each
unsuspended, enabled port before suspending the root hub. This
effectively converts the "global" suspend to an ordinary root-hub
suspend. There is no need to unsuspend these ports when the root hub
is resumed, because the child devices will be resumed anyway in the
course of a normal system resume ("global" suspend is never used for
runtime PM).
This patch should be applied to all stable kernels which include
commit
0aa2832dd0d9 (USB: use "global suspend" for system sleep on
USB-2 buses) or a backported version thereof.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Peter Münster <pmlists@free.fr>
Tested-by: Peter Münster <pmlists@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jean-Jacques Hiblot [Wed, 12 Mar 2014 16:30:08 +0000 (17:30 +0100)]
usb: gadget: at91-udc: fix irq and iomem resource retrieval
commit
886c7c426d465732ec9d1b2bbdda5642fc2e7e05 upstream.
When using dt resources retrieval (interrupts and reg properties) there is
no predefined order for these resources in the platform dev resource
table. Also don't expect the number of resource to be always 2.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nikita Yushchenko [Mon, 28 Apr 2014 15:23:44 +0000 (19:23 +0400)]
fsl-usb: do not test for PHY_CLK_VALID bit on controller version 1.6
commit
d183c81929beeba842b74422f754446ef2b8b49c upstream.
Per reference manuals of Freescale P1020 and P2020 SoCs, USB controller
present in these SoCs has bit 17 of USBx_CONTROL register marked as
Reserved - there is no PHY_CLK_VALID bit there.
Testing for this bit in ehci_fsl_setup_phy() behaves differently on two
P1020RDB boards available here - on one board test passes and fsl-usb
init succeeds, but on other board test fails, causing fsl-usb init to
fail.
This patch changes ehci_fsl_setup_phy() not to test PHY_CLK_VALID on
controller version 1.6 that (per manual) does not have this bit.
Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Atilla Filiz [Fri, 11 Apr 2014 14:51:23 +0000 (16:51 +0200)]
iio:imu:mpu6050: Fixed segfault in Invensens MPU driver due to null dereference
commit
b9b3a41893c3f1be67b5aacfa525969914bea0e9 upstream.
The driver segfaults when the kernel boots with device tree as the
platform data is then not present and the pointer is deferenced without
checking it is not null. This patch introduces such a check avoiding the
crash.
Signed-off-by: Atilla Filiz <atilla.filiz@essensium.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tuomas Tynkkynen [Fri, 16 May 2014 13:50:20 +0000 (16:50 +0300)]
clk: tegra: Fix wrong value written to PLLE_AUX
commit
d2c834abe2b39a2d5a6c38ef44de87c97cbb34b4 upstream.
The value written to PLLE_AUX was incorrect due to a wrong variable
being used. Without this fix SATA does not work.
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Tested-by: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
[mturquette@linaro.org: improved changelog]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thierry Reding [Wed, 9 Apr 2014 12:26:59 +0000 (14:26 +0200)]
drm/tegra: Remove gratuitous pad field
commit
cbfbbabb89b37f6bad05f478d906a385149f288d upstream.
The version of the drm_tegra_submit structure that was merged all the
way back in 3.10 contains a pad field that was originally intended to
properly pad the following __u64 field. Unfortunately it seems like a
different field was dropped during review that caused this padding to
become unnecessary, but the pad field wasn't removed at that time.
One possible side-effect of this is that since the __u64 following the
pad is now no longer properly aligned, the compiler may (or may not)
introduce padding itself, which results in no predictable ABI.
Rectify this by removing the pad field so that all fields are again
naturally aligned. Technically this is breaking existing userspace ABI,
but given that there aren't any (released) userspace drivers that make
use of this yet, the fallout should be minimal.
Fixes:
d43f81cbaf43 ("drm/tegra: Add gr2d device")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leo Liu [Mon, 28 Apr 2014 13:40:22 +0000 (09:40 -0400)]
drm/radeon: check buffer relocation offset
commit
695daf1a8e731a4b5b89de89a61f32a4d7ad7094 upstream.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Wed, 23 Apr 2014 18:46:06 +0000 (20:46 +0200)]
drm/radeon: use pflip irq on R600+ v2
commit
f5d636d2a74b755879feec35e14a259de52ccc07 upstream.
Testing the update pending bit directly after issuing an
update is nonsense cause depending on the pixel clock the
CRTC needs a bit of time to execute the flip even when we
are in the VBLANK period.
This is just a non invasive patch to solve the problem at
hand, a more complete and cleaner solution should follow
in the next merge window.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76564
v2: fix source IDs for CRTC2-6
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Thu, 10 Apr 2014 14:11:36 +0000 (16:11 +0200)]
drm/radeon/uvd: use lower clocks on old UVD to boot v2
commit
e45187620f9fc103edf68fa5ea78e73033e1668c upstream.
Some RV7xx generation hardware crashes after you
raise the UVD clocks for the first time. Try to
avoid this by using the lower clocks to boot these.
Workaround for: https://bugzilla.kernel.org/show_bug.cgi?id=71891
v2: lower clocks on IB test as well
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 22 Apr 2014 12:17:18 +0000 (08:17 -0400)]
drm/radeon: fix count in cik_sdma_ring_test()
commit
7e95cfb0b797678cd3493ca0322ef2675547a0bc upstream.
Should be 5 rather than 4.
Noticed-by: Mathias Fröhlich <Mathias.Froehlich@gmx.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 18 Apr 2014 13:08:11 +0000 (09:08 -0400)]
drm/radeon: disable dpm on rv770 by default
commit
76e6dcece841faebbee78895780e8209ff40d922 upstream.
There seem to be stability issues on a number of cards.
bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=76286
https://bugzilla.redhat.com/show_bug.cgi?id=1085785
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: matthias.graf@st.ovqu.de
Cc: bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 15 Apr 2014 16:44:35 +0000 (12:44 -0400)]
drm/radeon: don't allow runpm=1 on systems with out ATPX
commit
73acacc7397fe854ed2ab75f1c940fa00faaf15e upstream.
vgaswitcheroo and the ATPX ACPI methods are required to
power down the dGPU.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73901
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 15 Apr 2014 16:44:33 +0000 (12:44 -0400)]
drm/radeon/pm: don't walk the crtc list before it has been initialized (v2)
commit
3ed9a335cfc64b2c83545f341cdddf2347b12b97 upstream.
Avoids a crash in certain cases when thermal irqs are generated
before the display structures have been initialized.
v2: fix the vblank and vrefresh helpers as well
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73931
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 15 Apr 2014 16:44:34 +0000 (12:44 -0400)]
drm/radeon: fix ATPX detection on non-VGA GPUs
commit
e9a4099a59cc598a44006059dd775c25e422b772 upstream.
Some newer PX laptops have the pci device class
set to DISPLAY_OTHER rather than DISPLAY_VGA. This
properly detects ATPX on those laptops.
Based on a patch from: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: airlied@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 15 Apr 2014 16:44:32 +0000 (12:44 -0400)]
drm/radeon: properly unregister hwmon interface (v2)
commit
cb3e4e7c59e4b43ac378631f6101f5c8de3a27a5 upstream.
Need to properly unregister the hwmon device on driver
unload.
v2: minor clean up
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73931
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Wed, 16 Apr 2014 13:42:23 +0000 (09:42 -0400)]
drm/radeon/ci: make sure mc ucode is loaded before checking the size
commit
bcddee29b0b87af3aeda953840f97b356b24dc5e upstream.
Avoid a possible segfault.
Noticed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Wed, 16 Apr 2014 13:42:22 +0000 (09:42 -0400)]
drm/radeon/si: make sure mc ucode is loaded before checking the size
commit
8c79bae6a30f606b7a4e17c994bc5f72f8fdaf11 upstream.
Avoid a possible segfault.
Noticed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 11 Apr 2014 15:21:51 +0000 (11:21 -0400)]
drm/radeon: re-enable mclk dpm on R7 260X asics
commit
7e1858f9aff7d608b3d0abad4bda0130de887b89 upstream.
If the new mc ucode is available.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 11 Apr 2014 15:21:50 +0000 (11:21 -0400)]
drm/radeon: add support for newer mc ucode on CI (v2)
commit
277babc374f6ecab6af182554f5d9f35a7768755 upstream.
Fixes mclk stability on certain asics.
v2: print out mc firmware version used and size
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=75992
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 11 Apr 2014 15:21:49 +0000 (11:21 -0400)]
drm/radeon: add support for newer mc ucode on SI (v2)
commit
1ebe92802eaf0569784dce843bc28a78842d236c upstream.
May fix stability issues with some newer cards.
v2: print out mc firmware version used and size
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 11 Apr 2014 02:29:03 +0000 (22:29 -0400)]
drm/radeon: disable mclk dpm on R7 260X
commit
57700ad1f2f21d5d7ab7ee0e58d11b5954852434 upstream.
Setting higher mclks seems to cause stability issues
on some R7 260X boards. Disable it for now for stability
until we find a proper fix.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=75992
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 11 Apr 2014 02:29:01 +0000 (22:29 -0400)]
drm/radeon: fix runpm handling on APUs (v4)
commit
90c4cde9d5a2bb6239cb3e253bb3832ed89dc75c upstream.
Don't try and runtime suspend the APU in PX systems. We
only want to power down the dGPU.
v2: fix harder
v3: fix stupid typo
v4: consolidate runpm enablement to a single flag
bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=75127
https://bugzilla.kernel.org/show_bug.cgi?id=72701
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 8 Apr 2014 15:28:54 +0000 (11:28 -0400)]
drm/radeon: fix audio pin counts for DCE6+ (v2)
commit
be0949f5eb9c8133a05cf25f108f09e85e79cd32 upstream.
There is actually quite a bit of variance based on
the asic.
v2: fix typo noticed by Jerome.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Egbert Eich [Fri, 25 Apr 2014 08:56:22 +0000 (10:56 +0200)]
drm/i915: Break encoder->crtc link separately in intel_sanitize_crtc()
commit
7f1950fbb989e8fc5463b307e062b4529d51c862 upstream.
Depending on the SDVO output_flags SDVO may have multiple connectors
linking to the same encoder (in intel_connector->encoder->base).
Only one of those connectors should be active (ie link to the encoder
thru drm_connector->encoder).
If intel_connector_break_all_links() is called from intel_sanitize_crtc()
we may break the crtc connection of an encoder thru an inactive connector
in which case intel_connector_break_all_links() will not be called again
for the active connector if this happens to come later in the list due to:
if (connector->encoder->base.crtc != &crtc->base)
continue;
in intel_sanitize_crtc().
This will however leave the drm_connector->encoder linkage for this
active connector in place. Subsequently this will cause multiple
warnings in intel_connector_check_state() to trigger and the driver
will eventually die in drm_encoder_crtc_ok() (because of crtc == NULL).
To avoid this remove intel_connector_break_all_links() and move its
code to its two calling functions: intel_sanitize_crtc() and
intel_sanitize_encoder().
This allows to implement the link breaking more flexibly matching
the surrounding code: ie. in intel_sanitize_crtc() we can break the
crtc link separatly after the links to the encoders have been
broken which avoids above problem.
This regression has been introduced in:
commit
24929352481f085c5f85d4d4cbc919ddf106d381
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Jul 2 20:28:59 2012 +0200
drm/i915: read out the modeset hw state at load and resume time
so goes back to the very beginning of the modeset rework.
v2: This patch takes care of the concernes voiced by Chris Wilson
and Daniel Vetter that only breaking links if the drm_connector
is linked to an encoder may miss some links.
v3: move all encoder handling to encoder loop as suggested by
Daniel Vetter.
Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Thu, 24 Apr 2014 10:03:17 +0000 (12:03 +0200)]
drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms
commit
3ff04a160a891e56cdcee5c198d4c764d1c8c78b upstream.
The status bits are unconditionally set, the control bits only enable
the actual interrupt generation. Which means if we get some random
other interrupts we'll bogusly complain about them.
So restrict the WARN to platforms with a sane hotplug interrupt
handling scheme. And even more important also don't attempt to process
the hpd bit since we've detected a storm already. Instead just clear
the bit silently.
This WARN has been introduced in
commit
b8f102e8bf71cacf33326360fdf9dcfd1a63925b
Author: Egbert Eich <eich@suse.de>
Date: Fri Jul 26 14:14:24 2013 +0200
drm/i915: Add messages useful for HPD storm detection debugging (v2)
before that we silently handled the hpd event and so partially
defeated the storm detection.
v2: Pimp commit message (Jani)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: bitlord <bitlord0xff@gmail.com>
Reported-by: bitlord <bitlord0xff@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Sun, 13 Apr 2014 10:00:33 +0000 (12:00 +0200)]
drm/i915: Don't check gmch state on inherited configs
commit
9953599bc02dbc1d3330e6a0bfc6c50e9dffcac6 upstream.
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the gmch_pfit state to
it.
3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.
-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Tested-by: max <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Thu, 27 Mar 2014 09:08:45 +0000 (11:08 +0200)]
drm/i915: Allow user modes to exceed DVI 165MHz limit
commit
40478455fefdc0bde24ae872c3f88d58a1b0e435 upstream.
In commit
commit
6375b768a9850b6154478993e5fb566fa4614a9c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Mar 3 11:33:36 2014 +0200
drm/i915: Reject >165MHz modes w/ DVI monitors
the driver started to filter out display modes which exceed the
single-link DVI 165Mz dotclock limits when the monitor doesn't report
itself as being HDMI compliant. The intent was to filter out all
EDID derived modes that require dual-link DVI to operate since we
don't support dual-link.
However the patch went a bit too far and also causes the driver to reject
such modes even when specified by the user. Normally we don't check the
sink limitations when setting a mode from the user. This allows the user
to specify any mode whether the sink reports to support it or not. This
can be useful since often the sinks support more modes than they report
in the EDID.
So relax the checks a bit, and apply the single-link DVI dotclock limit
only when filtering the mode list, and ignore the limit when setting
a user specified mode.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72961
Tested-by: Nicholas Vinson <nvinson@comcast.net>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neil Greatorex [Fri, 18 Apr 2014 12:19:49 +0000 (14:19 +0200)]
irqchip: armada-370-xp: Fix releasing of MSIs
commit
ff3c664505bf8a8334bca5045e87b85cfe4d2277 upstream.
Store the value of d->hwirq in a local variable as the real value is wiped out
by calling irq_dispose_mapping. Without this patch, the armada_370_xp_free_msi
function would always free MSI#0, no matter what was passed to it.
Fixes:
31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support')
Signed-off-by: Neil Greatorex <neil@fatboyfat.co.uk>
Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Petazzoni [Fri, 18 Apr 2014 12:19:48 +0000 (14:19 +0200)]
irqchip: armada-370-xp: implement the ->check_device() msi_chip operation
commit
830cbe4b7a918613276aa3d3b28d24410623f92c upstream.
Until now, we were leaving the ->check_device() msi_chip operation
empty, which leads the PCI core to believe that we support both MSI
and MSI-X. In fact, we do not support MSI-X, so we have to tell this
to the PCI core by providing an implementation of this operation.
Fixes:
31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support')
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397823593-1932-3-git-send-email-thomas.petazzoni@free-electrons.com
Tested-by: Neil Greatorex <neil@fatboyfat.co.uk>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Petazzoni [Fri, 18 Apr 2014 12:19:47 +0000 (14:19 +0200)]
irqchip: armada-370-xp: fix invalid cast of signed value into unsigned variable
commit
da343fc776e0bcb238b65d9d24610819b95d0ef4 upstream.
The armada_370_xp_alloc_msi() function returns a signed int, which is
negative on error. However, we store the return value into an
irq_hw_number_t, which is unsigned. Therefore, we actually never test
if armada_370_xp_alloc_msi() returns an error or not, which may lead
us to use hwirq numbers of as 0xffffffe4 (when
armada_370_xp_alloc_msi() returns -ENOSPC).
This commit fixes that by storing the return value of
armada_370_xp_alloc_msi() in a signed variable.
Fixes:
31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support')
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397823593-1932-2-git-send-email-thomas.petazzoni@free-electrons.com
Tested-by: Neil Greatorex <neil@fatboyfat.co.uk>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kieran Clancy [Tue, 29 Apr 2014 14:51:20 +0000 (00:21 +0930)]
ACPI / EC: Process rather than discard events in acpi_ec_clear
commit
3eba563e280101209bad27d40bfc83ddf1489234 upstream.
Address a regression caused by commit
ad332c8a4533:
(ACPI / EC: Clear stale EC events on Samsung systems)
After the earlier patch, there was found to be a race condition on some
earlier Samsung systems (N150/N210/N220). The function acpi_ec_clear was
sometimes discarding a new EC event before its GPE was triggered by the
system. In the case of these systems, this meant that the "lid open"
event was not registered on resume if that was the cause of the wake,
leading to problems when attempting to close the lid to suspend again.
After testing on a number of Samsung systems, both those affected by the
previous EC bug and those affected by the race condition, it seemed that
the best course of action was to process rather than discard the events.
On Samsung systems which accumulate stale EC events, there does not seem
to be any adverse side-effects of running the associated _Q methods.
This patch adds an argument to the static function acpi_ec_sync_query so
that it may be used within the acpi_ec_clear loop in place of
acpi_ec_query_unlocked which was used previously.
With thanks to Stefan Biereigel for reporting the issue, and for all the
people who helped test the new patch on affected systems.
Fixes:
ad332c8a4533 (ACPI / EC: Clear stale EC events on Samsung systems)
References: https://lkml.kernel.org/r/
532FE3B2.9060808@biereigel-wb.de
References: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173
Reported-by: Stefan Biereigel <stefan@biereigel.de>
Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com>
Tested-by: Stefan Biereigel <stefan@biereigel.de>
Tested-by: Dennis Jansen <dennis.jansen@web.de>
Tested-by: Nicolas Porcel <nicolasporcel06@gmail.com>
Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com>
Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com>
Tested-by: Giannis Koutsou <giannis.koutsou@gmail.com>
Tested-by: Kieran Clancy <clancy.kieran@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Wed, 30 Apr 2014 20:36:33 +0000 (22:36 +0200)]
PNP / ACPI: Do not return errors if _DIS or _SRS are not present
commit
a8d22396302b7e4e5f0a594c1c1594388c29edaf upstream.
The ACPI PNP subsystem returns errors from pnpacpi_set_resources()
and pnpacpi_disable_resources() if the _SRS or _DIS methods are not
present, respectively, but it should not do that, because those
methods are optional. For this reason, modify pnpacpi_set_resources()
and pnpacpi_disable_resources(), respectively, to ignore missing _SRS
or _DIS.
This problem has been uncovered by commit
202317a573b2 (ACPI / scan:
Add acpi_device objects for all device nodes in the namespace) and
manifested itself by causing serial port suspend to fail on some
systems.
Fixes:
202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
References: https://bugzilla.kernel.org/show_bug.cgi?id=74371
Reported-by: wxg4net <wxg4net@gmail.com>
Reported-and-tested-by: <nonproffessional@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Mon, 5 May 2014 23:36:08 +0000 (09:36 +1000)]
md: avoid possible spinning md thread at shutdown.
commit
0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 upstream.
If an md array with externally managed metadata (e.g. DDF or IMSM)
is in use, then we should not set safemode==2 at shutdown because:
1/ this is ineffective: user-space need to be involved in any 'safemode' handling,
2/ The safemode management code doesn't cope with safemode==2 on external metadata
and md_check_recover enters an infinite loop.
Even at shutdown, an infinite-looping process can be problematic, so this
could cause shutdown to hang.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Mon, 5 May 2014 03:34:37 +0000 (13:34 +1000)]
md/raid10: call wait_barrier() for each request submitted.
commit
cc13b1d1500656a20e41960668f3392dda9fa6e2 upstream.
wait_barrier() includes a counter, so we must call it precisely once
(unless balanced by allow_barrier()) for each request submitted.
Since
commit
20d0189b1012a37d2533a87fb451f7852f2418d1
block: Introduce new bio_split()
in 3.14-rc1, we don't call it for the extra requests generated when
we need to split a bio.
When this happens the counter goes negative, any resync/recovery will
never start, and "mdadm --stop" will hang.
Reported-by: Chris Murphy <lists@colorremedies.com>
Fixes:
20d0189b1012a37d2533a87fb451f7852f2418d1
Cc: Kent Overstreet <kmo@daterainc.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mike Snitzer [Thu, 1 May 2014 20:14:24 +0000 (16:14 -0400)]
dm cache: fix writethrough mode quiescing in cache_map
commit
131cd131a9ff63d4b84f3fe15073a2984ac30066 upstream.
Commit
2ee57d58735 ("dm cache: add passthrough mode") inadvertently
removed the deferred set reference that was taken in cache_map()'s
writethrough mode support. Restore taking this reference.
This issue was found with code inspection.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Milan Broz [Mon, 14 Apr 2014 20:02:30 +0000 (22:02 +0200)]
dm verity: fix biovecs hash calculation regression
commit
3a7745215e7f73a5c7d9bcdc50661a55b39052a3 upstream.
Commit
003b5c5719f159f4f4bf97511c4702a0638313dd ("block: Convert drivers
to immutable biovecs") incorrectly converted biovec iteration in
dm-verity to always calculate the hash from a full biovec, but the
function only needs to calculate the hash from part of the biovec (up to
the calculated "todo" value).
Fix this issue by limiting hash input to only the requested data size.
This problem was identified using the cryptsetup regression test for
veritysetup (verity-compat-test).
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Acked-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Viresh Kumar [Mon, 12 May 2014 08:12:29 +0000 (13:42 +0530)]
hrtimer: Set expiry time before switch_hrtimer_base()
commit
84ea7fe37908254c3bd90910921f6e1045c1747a upstream.
switch_hrtimer_base() calls hrtimer_check_target() which ensures that
we do not migrate a timer to a remote cpu if the timer expires before
the current programmed expiry time on that remote cpu.
But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the
new expiry time is set. So the sanity check in hrtimer_check_target()
is operating on stale or even uninitialized data.
Update expiry time before calling switch_hrtimer_base().
[ tglx: Rewrote changelog once again ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linaro-kernel@lists.linaro.org
Cc: linaro-networking@linaro.org
Cc: fweisbec@gmail.com
Cc: arvind.chauhan@arm.com
Link: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.1399882253.git.viresh.kumar@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leon Ma [Wed, 30 Apr 2014 08:43:10 +0000 (16:43 +0800)]
hrtimer: Prevent remote enqueue of leftmost timers
commit
012a45e3f4af68e86d85cce060c6c2fed56498b2 upstream.
If a cpu is idle and starts an hrtimer which is not pinned on that
same cpu, the nohz code might target the timer to a different cpu.
In the case that we switch the cpu base of the timer we already have a
sanity check in place, which determines whether the timer is earlier
than the current leftmost timer on the target cpu. In that case we
enqueue the timer on the current cpu because we cannot reprogram the
clock event device on the target.
If the timers base is already the target CPU we do not have this
sanity check in place so we enqueue the timer as the leftmost timer in
the target cpus rb tree, but we cannot reprogram the clock event
device on the target cpu. So the timer expires late and subsequently
prevents the reprogramming of the target cpu clock event device until
the previously programmed event fires or a timer with an earlier
expiry time gets enqueued on the target cpu itself.
Add the same target check as we have for the switch base case and
start the timer on the current cpu if it would become the leftmost
timer on the target.
[ tglx: Rewrote subject and changelog ]
Signed-off-by: Leon Ma <xindong.ma@intel.com>
Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stuart Hayes [Tue, 29 Apr 2014 22:55:02 +0000 (17:55 -0500)]
hrtimer: Prevent all reprogramming if hang detected
commit
6c6c0d5a1c949d2e084706f9e5fb1fccc175b265 upstream.
If the last hrtimer interrupt detected a hang it sets hang_detected=1
and programs the clock event device with a delay to let the system
make progress.
If hang_detected == 1, we prevent reprogramming of the clock event
device in hrtimer_reprogram() but not in hrtimer_force_reprogram().
This can lead to the following situation:
hrtimer_interrupt()
hang_detected = 1;
program ce device to Xms from now (hang delay)
We have two timers pending:
T1 expires 50ms from now
T2 expires 5s from now
Now T1 gets canceled, which causes hrtimer_force_reprogram() to be
invoked, which in turn programs the clock event device to T2 (5
seconds from now).
Any hrtimer_start after that will not reprogram the hardware due to
hang_detected still being set. So we effectivly block all timers until
the T2 event fires and cleans up the hang situation.
Add a check for hang_detected to hrtimer_force_reprogram() which
prevents the reprogramming of the hang delay in the hardware
timer. The subsequent hrtimer_interrupt will resolve all outstanding
issues.
[ tglx: Rewrote subject and changelog and fixed up the comment in
hrtimer_force_reprogram() ]
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Link: http://lkml.kernel.org/r/53602DC6.2060101@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grant Likely [Tue, 29 Apr 2014 11:05:22 +0000 (12:05 +0100)]
drivercore: deferral race condition fix
commit
58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 upstream.
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Gajdusek [Mon, 12 May 2014 11:48:26 +0000 (13:48 +0200)]
hwmon: (emc1403) Support full range of known chip revision numbers
commit
3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 upstream.
The datasheet for EMC1413/EMC1414, which is fully compatible to
EMC1403/1404 and uses the same chip identification, references revision
numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers
from 0x01 to 0x04 to make sure none are missed.
Signed-off-by: Josef Gajdusek <atx@atx.name>
[Guenter Roeck: Updated headline and description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jean Delvare [Mon, 12 May 2014 09:44:51 +0000 (11:44 +0200)]
hwmon: (emc1403) Fix resource leak on module unload
commit
8759f9046550f463098148bf577ccd32cdb895e3 upstream.
Commit
454aee17f claims to convert driver emc1403 to use
devm_hwmon_device_register_with_groups, however the patch itself makes
use of hwmon_device_register_with_groups instead. As the driver remove
function was still dropped, the hwmon device is no longer unregistered
on driver removal, leading to a resource leak.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes:
454aee17f hwmon: (emc1403) Convert to use devm_hwmon_device_register_with_groups
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Gajdusek [Sun, 11 May 2014 12:40:44 +0000 (14:40 +0200)]
hwmon: (emc1403) fix inverted store_hyst()
commit
17c048fc4bd95efea208a1920f169547d8588f1f upstream.
Attempts to set the hysteresis value to a temperature below the target
limit fails with "write error: Numerical result out of range" due to
an inverted comparison.
Signed-off-by: Josef Gajdusek <atx@atx.name>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
[Guenter Roeck: Updated headline and description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Wed, 30 Apr 2014 21:08:14 +0000 (14:08 -0700)]
Revert "hwmon: (coretemp) Refine TjMax detection"
commit
c0940e95f7a78be0525c8d31df0b1f71e149e57e upstream.
This reverts commit
9fb6c9c73b11bef65ba80a362547fd116c1e1c9d.
Tjmax on some Intel CPUs is below 85 degrees C. One known example is
L5630 with Tjmax of 71 degrees C. There are other Xeon processors with
Tjmax of 70 or 80 degrees C. Also, the Intel IA32 System Programming
document states that the temperature target is in bits 23:16 of MSR 0x1a2
(MSR_TEMPERATURE_TARGET), which is 8 bits, not 7.
So even if turbostat uses similar checks to validate Tjmax, there is no
evidence that the checks are actually required. On the contrary, the
checks are known to cause problems and therefore need to be removed.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75071.
Fixes: 9fb6c9c hwmon: (coretemp) Refine TjMax detection
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rusty Russell [Mon, 28 Apr 2014 01:35:43 +0000 (11:05 +0930)]
module: remove warning about waiting module removal.
commit
79465d2fd48e68940c2bdecddbdecd45bbba06fe upstream.
We remove the waiting module removal in commit
3f2b9c9cdf38 (September
2013), but it turns out that modprobe in kmod (< version 16) was
asking for waiting module removal. No one noticed since modprobe would
check for 0 usage immediately before trying to remove the module, and
the race is unlikely.
However, it means that anyone running old (but not ancient) kmod
versions is hitting the printk designed to see if anyone was running
"rmmod -w". All reports so far have been false positives, so remove
the warning.
Fixes:
3f2b9c9cdf389e303b2273679af08aab5f153517
Reported-by: Valerio Vanni <valerio.vanni@inwind.it>
Cc: Elliott, Robert (Server Storage) <Elliott@hp.com>
Acked-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leon Yu [Thu, 1 May 2014 03:31:28 +0000 (03:31 +0000)]
aio: fix potential leak in aio_run_iocb().
commit
754320d6e166d3a12cb4810a452bde00afbd4e9a upstream.
iovec should be reclaimed whenever caller of rw_copy_check_uvector() returns,
but it doesn't hold when failure happens right after aio_setup_vectored_rw().
Fix that in a such way to avoid hairy goto.
Signed-off-by: Leon Yu <chianglungyu@gmail.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Wed, 19 Mar 2014 17:36:39 +0000 (18:36 +0100)]
iwlwifi: mvm: delay enabling smart FIFO until after beacon RX
commit
0229cdafb6f67064a217591d48b0f6abf14e8385 upstream.
If we have no beacon data before association, delay smart FIFO
enablement until after we have this data.
Not doing so can cause association failures in extremely silent
environments (usually only a shielded box/room) as beacon RX is
not sent to the host immediately, and then the association time
event ends without the host receiving any beacon even though it
was on the air - it's just stuck on the FIFO.
Fixes:
1f3b0ff8ecce ("iwlwifi: mvm: Add Smart FIFO support")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chen Yucong [Thu, 22 May 2014 18:54:15 +0000 (11:54 -0700)]
hwpoison, hugetlb: lock_page/unlock_page does not match for handling a free hugepage
commit
b985194c8c0a130ed155b71662e39f7eaea4876f upstream.
For handling a free hugepage in memory failure, the race will happen if
another thread hwpoisoned this hugepage concurrently. So we need to
check PageHWPoison instead of !PageHWPoison.
If hwpoison_filter(p) returns true or a race happens, then we need to
unlock_page(hpage).
Signed-off-by: Chen Yucong <slaoub@gmail.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Tested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Salter [Thu, 15 May 2014 14:19:22 +0000 (15:19 +0100)]
arm64: fix pud_huge() for 2-level pagetables
commit
4797ec2dc83a43be35bad56037d1b53db9e2b5d5 upstream.
The following happens when trying to run a kvm guest on a kernel
configured for 64k pages. This doesn't happen with 4k pages:
BUG: failure at include/linux/mm.h:297/put_page_testzero()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF 3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1
Call trace:
[<
fffffe0000096034>] dump_backtrace+0x0/0x16c
[<
fffffe00000961b4>] show_stack+0x14/0x1c
[<
fffffe000066e648>] dump_stack+0x84/0xb0
[<
fffffe0000668678>] panic+0xf4/0x220
[<
fffffe000018ec78>] free_reserved_area+0x0/0x110
[<
fffffe000018edd8>] free_pages+0x50/0x88
[<
fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40
[<
fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44
[<
fffffe00000a1854>] kvm_put_kvm+0xf0/0x184
[<
fffffe00000a1938>] kvm_vm_release+0x10/0x1c
[<
fffffe00001edc1c>] __fput+0xb0/0x288
[<
fffffe00001ede4c>] ____fput+0xc/0x14
[<
fffffe00000d5a2c>] task_work_run+0xa8/0x11c
[<
fffffe0000095c14>] do_notify_resume+0x54/0x58
In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page()
on the stage2 pgd which leads to the BUG in put_page_testzero(). This
happens because a pud_huge() test in unmap_range() returns true when it
should always be false with 2-level pages tables used by 64k pages.
This patch removes support for huge puds if 2-level pagetables are
being used.
Signed-off-by: Mark Salter <msalter@redhat.com>
[catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anthony Iliopoulos [Wed, 14 May 2014 09:29:48 +0000 (11:29 +0200)]
x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()
commit
9844f5462392b53824e8b86726e7c33b5ecbb676 upstream.
The invalidation is required in order to maintain proper semantics
under CoW conditions. In scenarios where a process clones several
threads, a thread operating on a core whose DTLB entry for a
particular hugepage has not been invalidated, will be reading from
the hugepage that belongs to the forked child process, even after
hugetlb_cow().
The thread will not see the updated page as long as the stale DTLB
entry remains cached, the thread attempts to write into the page,
the child process exits, or the thread gets migrated to a different
processor.
Signed-off-by: Anthony Iliopoulos <anthony.iliopoulos@huawei.com>
Link: http://lkml.kernel.org/r/20140514092948.GA17391@server-36.huawei.corp
Suggested-by: Shay Goikhman <shay.goikhman@huawei.com>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Stuebner [Fri, 9 May 2014 22:36:57 +0000 (15:36 -0700)]
drivers/rtc/rtc-hym8563.c: set uie_unsupported
commit
282cba6b00a95f0277ed71551e3f6b0477e8836b upstream.
The alarm of the hym8563 only supports a minute accuracy, while the uie
wants an alarm one second in the future. Therefore things like the
select() syscall will fail with a timeout, because the next alarm will
happen in a worst case of 60 seconds.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>