- 19 3月, 2013 9 次提交
-
-
由 Jiri Slaby 提交于
Do not dig struct smd_tty_info out of tty_struct using tty_port_tty_get. It is unnecessarily too complicated, use simple container_of instead. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiri Slaby 提交于
The warning is there since 2.1.69 and we have not seen anybody reporting it in the past decade. Remove the warning now. tty_get_baud_rate can now be inline. This gives us one less EXPORT_SYMBOL. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiri Slaby 提交于
info is obtained by container_of. It can never be NULL. So do not test that. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiri Slaby 提交于
data_len in jsm_input cannot be zero as we would jump out early in the function. It also cannot be negative because it is an int and we do bitwise and with 8192. So remove the check. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Cc: Lucas Tavares <lucaskt@linux.vnet.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
Concurrent access to tty->pgrp must be protected with tty->ctrl_lock. Also, as noted in the comments, reading current->signal->tty is safe because either, 1) current->signal->tty is assigned by current, or 2) current->signal->tty is set to NULL. NB: for reference, tty_check_change() implements a similar POSIX check for the ioctls corresponding to tcflush(), tcdrain(), tcsetattr(), tcsetpgrp(), tcflow() and tcsendbreak(). Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
An ldisc reference is insufficient guarantee the foreground process group is not in the process of being signalled from a hangup. 1) Reads of tty->pgrp must be locked with ctrl_lock 2) The group pid must be referenced for the duration of signalling. Because the driver-side is not process-context, a pid reference must be acquired. Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
As noted in the following comment: /* FIXME: there is a tiny race here if the receive room check runs before the other work executes and empties the buffer (upping the receiving room and unthrottling. We then throttle and get stuck. This has been observed and traced down by Vincent Pillet/ We need to address this when we sort out out the rx path locking */ Use new safe throttle/unthrottle functions to re-evaluate conditions if interrupted by the complement flow control function. Reported-by: NVincent Pillet <vincentx.pillet@intel.com> Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
The tty driver can become stuck throttled due to race conditions between throttle and unthrottle, when the decision to throttle or unthrottle is conditional. The following example helps to illustrate the race: CPU 0 | CPU 1 | if (condition A) | | <processing such that A not true> | if (!condition A) | unthrottle() throttle() | | Note the converse is also possible; ie., CPU 0 | CPU 1 | | if (!condition A) <processing such that A true> | if (condition A) | throttle() | | unthrottle() | Add new throttle/unthrottle functions based on the familiar model of task state and schedule/wake. For example, while (1) { tty_set_flow_change(tty, TTY_THROTTLE_SAFE); if (!condition) break; if (!tty_throttle_safe(tty)) break; } __tty_set_flow_change(tty, 0); In this example, if an unthrottle occurs after the condition is evaluated but before tty_throttle_safe(), then tty_throttle_safe() will return non-zero, looping and forcing the re-evaluation of condition. Reported-by: NVincent Pillet <vincentx.pillet@intel.com> Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
2-line function check_unthrottle() is now only called from n_tty_read(); merge into caller. Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 3月, 2013 12 次提交
-
-
由 zhangwei(Jovi) 提交于
Currently help message of /proc/sysrq-trigger highlight its upper-case characters, like below: SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) ... this would confuse user trigger sysrq by upper-case character, which is inconsistent with the real lower-case character registed key. This inconsistent help message will also lead more confused when 26 upper-case letters put into use in future. This patch fix it. Thanks the comments from Andrew and Randy. Signed-off-by: Nzhangwei(Jovi) <jovi.zhangwei@huawei.com> Cc: Andrew Morton <akpm@linux-foundation.org> Acked-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
An exiting session leader can hang if a foreground process is blocking for line discipline i/o, eg. in n_tty_read(). This happens because the blocking reader is holding an ldisc reference (indicating the line discipline is in-use) which prevents __tty_hangup() from recycling the line discipline. Although waiters are woken before attempting to gain exclusive access for changing the ldisc, the blocking reader in this case will not exit the i/o loop since it has not yet received SIGHUP (because it has not been sent). Instead, perform signalling first, then recycle the line discipline. Fixes: INFO: task init:1 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. init D 00000000001d7180 2688 1 0 0x00000002 ffff8800b9acfba8 0000000000000002 00000000001d7180 ffff8800b9b10048 ffff8800b94cb000 ffff8800b9b10000 00000000001d7180 00000000001d7180 ffff8800b9b10000 ffff8800b9acffd8 00000000001d7180 00000000001d7180 Call Trace: [<ffffffff83db9909>] __schedule+0x2e9/0x3b0 [<ffffffff83db9b35>] schedule+0x55/0x60 [<ffffffff83db74ba>] schedule_timeout+0x3a/0x370 [<ffffffff81182349>] ? mark_held_locks+0xf9/0x130 [<ffffffff83dbab38>] ? down_failed+0x108/0x200 [<ffffffff83dbb7ab>] ? _raw_spin_unlock_irq+0x2b/0x80 [<ffffffff81182608>] ? trace_hardirqs_on_caller+0x128/0x160 [<ffffffff83dbab61>] down_failed+0x131/0x200 [<ffffffff83dbbfad>] ? tty_ldisc_lock_pair_timeout+0xcd/0x120 [<ffffffff83dbae03>] ldsem_down_write+0xd3/0x113 [<ffffffff83dbbfad>] ? tty_ldisc_lock_pair_timeout+0xcd/0x120 [<ffffffff8118264d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff83dbbfad>] tty_ldisc_lock_pair_timeout+0xcd/0x120 [<ffffffff81c3df60>] tty_ldisc_hangup+0xd0/0x220 [<ffffffff81c35bd7>] __tty_hangup+0x137/0x4f0 [<ffffffff81c37c7c>] disassociate_ctty+0x6c/0x230 [<ffffffff8111290c>] do_exit+0x41c/0x590 [<ffffffff8107ad34>] ? syscall_trace_enter+0x24/0x2e0 [<ffffffff81112b4a>] do_group_exit+0x8a/0xc0 [<ffffffff81112b92>] sys_exit_group+0x12/0x20 [<ffffffff83dc49d8>] tracesys+0xe1/0xe6 1 lock held by init/1: #0: (&tty->ldisc_sem){++++++}, at: [<ffffffff83dbbfad>] tty_ldisc_lock_pair_timeout+0xcd/0x120 Reported-by: NSasha Levin <levinsasha928@gmail.com> Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Acked-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
When the session leader is exiting, signal the foreground group processes as part of the hangup sequence, instead of after the hangup is complete. This prepares for hanging up the line discipline _after_ signalling processes which may be blocking on ldisc i/o. Parameterize __tty_hangup() to distinguish between when the session leader is exiting and all other hangups; signal the foreground group after signalling the session leader and its process group, which preserves the original signal order. Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Acked-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
The interrupt state does not need to be saved, disabled and restored here; interrupts are already off because this lock is bracketed by spin_lock_irq/spin_unlock_irq. Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Acked-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
__tty_hangup() and tty_vhangup() cannot be called from atomic context, so locks do not need to preserve the interrupt state (although, still disable interrupts). Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Acked-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
Reduce complexity of __tty_hangup(); separate SIGHUP signalling into tty_signal_session_leader(). Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Acked-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Syam Sidhardhan 提交于
kfree on NULL pointer is a no-op. Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Liang Li 提交于
Implement console poll for pch_uart, this could enable KGDBoC when on pch-uart console. Signed-off-by: NLiang Li <liang.li@windriver.com> Acked-by: NJason Wessel <jason.wessel@windriver.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jingoo Han 提交于
This patch uses module_platform_driver_probe() macro which makes the code smaller and simpler. Signed-off-by: NJingoo Han <jg1.han@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Sachin Kamat 提交于
Use the newly introduced devm_ioremap_resource() instead of devm_request_and_ioremap() which provides more consistent error handling. Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Acked-by: NTony Prisk <linux@prisktech.co.nz> Reviewed-by: NThierry Reding <thierry.reding@avionic-design.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Sachin Kamat 提交于
Use the newly introduced devm_ioremap_resource() instead of devm_request_and_ioremap() which provides more consistent error handling. devm_ioremap_resource() provides its own error messages; so all explicit error messages can be removed from the failure code paths. Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Reviewed-by: NThierry Reding <thierry.reding@avionic-design.de> Cc: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
port->itty has already been reset by release_tty() before pty_cleanup() is called. Call stack: release_tty() tty_kref_put() queue_release_one_tty() release_one_tty() : workqueue tty->ops->cleanup() pty_cleanup() Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 3月, 2013 1 次提交
-
-
由 Linus Torvalds 提交于
There is a more complete atmel patch-series out by Nick Dyer that fixes this and other things, but in the meantime this is the minimal thing to get the touchscreen going on (at least my) Pixel Chromebook. Not that I want my dirty fingers near that beautiful screen, but it seems that a non-initialized touchscreen will also end up being a constant wakeup source, so you have to disable it to go to sleep. And it's easier to just fix the initialization sequence. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 09 3月, 2013 3 次提交
-
-
由 Benson Leung 提交于
Add basic platform data to get the current upstream driver working with the 224s touchpad and 1664s touchscreen. We will be using NULL config so we will use the settings from the devices' NVRAMs. Signed-off-by: NBenson Leung <bleung@chromium.org> Tested-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Daniel Kurtz 提交于
This same driver can be used by atmel based touchscreens and touchpads (buttonpads). Platform data may specify a device is a touchpad using the is_tp flag. This will cause the driver to perform some touchpad specific initializations, such as: * register input device name "Atmel maXTouch Touchpad" instead of Touchscreen. * register BTN_LEFT & BTN_TOOL_* event types. * register axis resolution (as a fixed constant, for now) * register BUTTONPAD property * process GPIO buttons using reportid T19 Input event GPIO mapping is done by the platform data key_map array. key_map[x] should contain the KEY or BTN code to send when processing GPIOx from T19. To specify a GPIO as not an input source, populate with KEY_RESERVED, or 0. Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NBenson Leung <bleung@chromium.org> Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk> Tested-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ben Hutchings 提交于
Commit 9f9c9cbb ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") hoisted the check for "_DMI_" into dmi_scan_machine(), which means that we don't bother to check for "_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also call dmi_present() for an address where we found "_SM_", if it failed further validation. Check for "_DMI_" in smbios_present() before calling dmi_present(). [akpm@linux-foundation.org: fix build] Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Reported-by: NTim McGrath <tmhikaru@gmail.com> Tested-by: NTim Mcgrath <tmhikaru@gmail.com> Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 08 3月, 2013 8 次提交
-
-
由 Paul Bolle 提交于
Commit ac24c220 ("drm/tegra: Use generic HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select statement for that symbol is a nop. Drop it. What was needed to use HDMI functionality was to select HDMI (which this entry already did through depending on DRM) and to include linux/hdmi.h (which this commit also did). Signed-off-by: NPaul Bolle <pebolle@tiscali.nl> Acked-by: NThierry Reding <thierry.reding@avionic-design.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Julia Lemire 提交于
Renesas boards were consistently defaulting to the 1024x768 resolution, regardless of the native resolution of the monitor plugged in. It was determined that the EDID of the monitor was not being read. Since the DAC is a shared line, in order to read from or write to it we must take control of the DAC clock. This can be done by setting the proper register to one. This bug fix sets the register MGA1064_GEN_IO_CTL2 to one. The DAC control line can be used to determine whether or not a new monitor has been plugged in. But since the hotplug feature is not one we will support, it has been decided to simply leave the register set to one. Signed-off-by: NJulia Lemire <jlemire@matrox.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Christopher Harvey 提交于
A monitor or a user could request a resolution greater than the available VRAM for the backing framebuffer. This change checks the required framebuffer size against the max VRAM size and rejects modes if they are too big. This change can also remove a mode request passed in via the video= parameter. Signed-off-by: NChristopher Harvey <charvey@matrox.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Christopher Harvey 提交于
Signed-off-by: NChristopher Harvey <charvey@matrox.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Marek Olšák 提交于
The MIP_ADDRESS state has 2 meanings. If the texture has one sample per pixel, it's a pointer to the mipmap chain. If the texture has multiple samples per pixel, it's a pointer to FMASK, a metadata buffer needed for reading compressed MSAA textures. The mipmap alignment rules do not apply to FMASK. Signed-off-by: NMarek Olšák <maraeo@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
The MC is mostly likely busy (e.g., display requests), not hung so no need to reset it. Doing an MC reset is tricky and not particularly reliable. Fixes hangs in certain cases. Reported-by: NJosh Boyer <jwboyer@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
vbios values are wrong leading to colors that are too bright. Use the default values instead. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Avoids splatter if the interrupt handler is not registered due to acceleration being disabled. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org
-
- 07 3月, 2013 4 次提交
-
-
由 Benjamin Tissoires 提交于
hid_output_raw_report() makes a direct call to usb_control_msg(). However, some USB3 boards have shown that the usb device is not ready during the .probe(). This blocks the entire usb device, and the paired mice, keyboards are not functional. The dmesg output is the following: [ 11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2 [ 11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 [ 11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32 Relying on the scheduled call to usbhid_submit_report() fixes the problem. related bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143 https://bugzilla.redhat.com/show_bug.cgi?id=840391 https://bugzilla.kernel.org/show_bug.cgi?id=49781Reported-and-tested-by: NBob Bowles <bobjohnbowles@gmail.com> Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Dirk Brandewie 提交于
It seems some VMs support the P state MSRs but return zeros. Fail gracefully if we are running in this environment. References: https://bugzilla.redhat.com/show_bug.cgi?id=916833Reported-by: NJosh Boyer <jwboyer@redhat.com> Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Dirk Brandewie 提交于
If cpufreq_register_driver() fails just free memory that has been allocated and return. intel_pstate_exit() function is removed since we are built-in only now there is no reason for a module exit procedure. Reported-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Patrik Jakobsson 提交于
According to PRM we need to disable hsync and vsync even though ADPA is disabled. The previous code did infact do the opposite so we fix it. Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359Tested-by: Nmax <manikulin@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 3月, 2013 3 次提交
-
-
由 Matt Fleming 提交于
Joseph was hitting a failure case when mounting efivarfs which resulted in an incorrect error message, $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory triggered when efivarfs_valid_name() returned -EINVAL. Make sure we pass accurate return values up the stack if efivarfs_fill_super() fails to build inodes for EFI variables. Reported-by: NJoseph Yasi <joe.yasi@gmail.com> Reported-by: NLingzhu Xiang <lxiang@redhat.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: <stable@vger.kernel.org> # v3.8 Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
Stricter validation was introduced with commit da27a243 ("efivarfs: guid part of filenames are case-insensitive") and commit 47f531e8 ("efivarfs: Validate filenames much more aggressively"), which is necessary for the guid portion of efivarfs filenames, but we don't need to be so strict with the first part, the variable name. The UEFI specification doesn't impose any constraints on variable names other than they be a NULL-terminated string. The above commits caused a regression that resulted in users seeing the following message, $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory whenever pstore EFI variables were present in the variable store, since their variable names failed to pass the following check, /* GUID should be right after the first '-' */ if (s - 1 != strchr(str, '-')) as a typical pstore filename is of the form, dump-type0-10-1-<guid>. The fix is trivial since the guid portion of the filename is GUID_LEN bytes, we can use (len - GUID_LEN) to ensure the '-' character is where we expect it to be. (The bogus ENOMEM error value will be fixed in a separate patch.) Reported-by: NJoseph Yasi <joe.yasi@gmail.com> Tested-by: NJoseph Yasi <joe.yasi@gmail.com> Reported-by: NLingzhu Xiang <lxiang@redhat.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: <stable@vger.kernel.org> # v3.8 Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matthew Garrett 提交于
UEFI variables are typically stored in flash. For various reasons, avaiable space is typically not reclaimed immediately upon the deletion of a variable - instead, the system will garbage collect during initialisation after a reboot. Some systems appear to handle this garbage collection extremely poorly, failing if more than 50% of the system flash is in use. This can result in the machine refusing to boot. The safest thing to do for the moment is to forbid writes if they'd end up using more than half of the storage space. We can make this more finegrained later if we come up with a method for identifying the broken machines. Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-