~kmously/ubuntu/+source/linux/+git/bionic:ml
- Get this branch:
-
git clone
-b ml
https://git.launchpad.net/~kmously/ubuntu/+source/linux/+git/bionic
Branch merges
Related source package recipes
Branch information
- Name:
- ml
- Repository:
- lp:~kmously/ubuntu/+source/linux/+git/bionic
Recent commits
- 6c742af... by Lyude <email address hidden>
-
drm/nouveau: Fix deadlock in nv50_mstm_
register_ connector( ) BugLink: http://
bugs.launchpad. net/bugs/ 1763189 Currently; we're grabbing all of the modesetting locks before adding MST
connectors to fbdev. This isn't actually necessary, and causes a
deadlock as well:=======
======= ======= ======= ======= ======= ======= =====
WARNING: possible circular locking dependency detected
4.17.0-rc3Lyude- Test+ #1 Tainted: G O
-------------- ------- ------- ------- ------- ------- -----
kworker/1:0/18 is trying to acquire lock:
00000000c832f62d (&helper->lock){ +.+.}, at: drm_fb_ helper_ add_one_ connector+ 0x2a/0x60 [drm_kms_helper] but task is already holding lock:
00000000942e28e2 (crtc_ww_class_mutex) {+.+.}, at: drm_modeset_ backoff+ 0x8e/0x1c0 [drm] which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (crtc_ww_
class_mutex) {+.+.}:
ww_mutex_ lock+0x43/ 0x80
drm_modeset_ lock+0x71/ 0x130 [drm]
drm_helper_ probe_single_ connector_ modes+0x7d/ 0x6b0 [drm_kms_helper]
drm_setup_ crtcs+0x15e/ 0xc90 [drm_kms_helper]
__drm_fb_ helper_ initial_ config_ and_unlock+ 0x29/0x480 [drm_kms_helper]
nouveau_ fbcon_init+ 0x138/0x1a0 [nouveau]
nouveau_ drm_load+ 0x173/0x7e0 [nouveau]
drm_dev_ register+ 0x134/0x1c0 [drm]
drm_get_ pci_dev+ 0x8e/0x160 [drm]
nouveau_ drm_probe+ 0x1a9/0x230 [nouveau]
pci_device_ probe+0xcd/ 0x150
driver_ probe_device+ 0x30b/0x480
__driver_ attach+ 0xbc/0xe0
bus_for_ each_dev+ 0x67/0x90
bus_add_ driver+ 0x164/0x260
driver_ register+ 0x57/0xc0
do_one_ initcall+ 0x4d/0x323
do_init_ module+ 0x5b/0x1f8
load_module+ 0x20e5/ 0x2ac0
__do_sys_ finit_module+ 0xb7/0xd0
do_syscall_ 64+0x60/ 0x1b0
entry_SYSCALL_ 64_after_ hwframe+ 0x49/0xbe -> #2 (crtc_ww_
class_acquire) {+.+.}:
drm_helper_ probe_single_ connector_ modes+0x58/ 0x6b0 [drm_kms_helper]
drm_setup_ crtcs+0x15e/ 0xc90 [drm_kms_helper]
__drm_fb_ helper_ initial_ config_ and_unlock+ 0x29/0x480 [drm_kms_helper]
nouveau_ fbcon_init+ 0x138/0x1a0 [nouveau]
nouveau_ drm_load+ 0x173/0x7e0 [nouveau]
drm_dev_ register+ 0x134/0x1c0 [drm]
drm_get_ pci_dev+ 0x8e/0x160 [drm]
nouveau_ drm_probe+ 0x1a9/0x230 [nouveau]
pci_device_ probe+0xcd/ 0x150
driver_ probe_device+ 0x30b/0x480
__driver_ attach+ 0xbc/0xe0
bus_for_ each_dev+ 0x67/0x90
bus_add_ driver+ 0x164/0x260
driver_ register+ 0x57/0xc0
do_one_ initcall+ 0x4d/0x323
do_init_ module+ 0x5b/0x1f8
load_module+ 0x20e5/ 0x2ac0
__do_sys_ finit_module+ 0xb7/0xd0
do_syscall_ 64+0x60/ 0x1b0
entry_SYSCALL_ 64_after_ hwframe+ 0x49/0xbe -> #1 (&dev->
mode_config. mutex){ +.+.}:
drm_setup_ crtcs+0x10c/ 0xc90 [drm_kms_helper]
__drm_fb_ helper_ initial_ config_ and_unlock+ 0x29/0x480 [drm_kms_helper]
nouveau_ fbcon_init+ 0x138/0x1a0 [nouveau]
nouveau_ drm_load+ 0x173/0x7e0 [nouveau]
drm_dev_ register+ 0x134/0x1c0 [drm]
drm_get_ pci_dev+ 0x8e/0x160 [drm]
nouveau_ drm_probe+ 0x1a9/0x230 [nouveau]
pci_device_ probe+0xcd/ 0x150
driver_ probe_device+ 0x30b/0x480
__driver_ attach+ 0xbc/0xe0
bus_for_ each_dev+ 0x67/0x90
bus_add_ driver+ 0x164/0x260
driver_ register+ 0x57/0xc0
do_one_ initcall+ 0x4d/0x323
do_init_ module+ 0x5b/0x1f8
load_module+ 0x20e5/ 0x2ac0
__do_sys_ finit_module+ 0xb7/0xd0
do_syscall_ 64+0x60/ 0x1b0
entry_SYSCALL_ 64_after_ hwframe+ 0x49/0xbe -> #0 (&helper-
>lock){ +.+.}:
__mutex_ lock+0x70/ 0x9d0
drm_fb_ helper_ add_one_ connector+ 0x2a/0x60 [drm_kms_helper]
nv50_mstm_ register_ connector+ 0x2c/0x50 [nouveau]
drm_dp_ add_port+ 0x2f5/0x420 [drm_kms_helper]
drm_dp_ send_link_ address+ 0x155/0x1e0 [drm_kms_helper]
drm_dp_ add_port+ 0x33f/0x420 [drm_kms_helper]
drm_dp_ send_link_ address+ 0x155/0x1e0 [drm_kms_helper]
drm_dp_ check_and_ send_link_ address+ 0x87/0xd0 [drm_kms_helper]
drm_dp_ mst_link_ probe_work+ 0x4d/0x80 [drm_kms_helper]
process_ one_work+ 0x20d/0x650
worker_ thread+ 0x3a/0x390
kthread+ 0x11e/0x140
ret_from_ fork+0x3a/ 0x50 other info that might help us debug this:
Chain exists of:
&helper->lock --> crtc_ww_class_acquire --> crtc_ww_class_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(crtc_ww_ class_mutex) ;
lock( crtc_ww_ class_acquire) ;
lock( crtc_ww_ class_mutex) ;
lock(&helper- >lock); *** DEADLOCK ***
5 locks held by kworker/1:0/18:
#0: 000000004a05cd50 ((wq_completion)"events_ long"){ +.+.}, at: process_ one_work+ 0x187/0x650
#1: 00000000601c11d1 ((work_completion) (&mgr-> work)){ +.+.}, at: process_ one_work+ 0x187/0x650
#2: 00000000586ca0df (&dev->mode_config. mutex){ +.+.}, at: drm_modeset_ lock_all+ 0x3a/0x1b0 [drm]
#3: 00000000d3ca0ffa (crtc_ww_class_acquire) {+.+.}, at: drm_modeset_ lock_all+ 0x44/0x1b0 [drm]
#4: 00000000942e28e2 (crtc_ww_class_mutex) {+.+.}, at: drm_modeset_ backoff+ 0x8e/0x1c0 [drm] stack backtrace:
CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G O 4.17.0-rc3Lyude- Test+ #1
Hardware name: Gateway FX6840/FX6840, BIOS P01-A3 05/17/2010
Workqueue: events_long drm_dp_mst_link_ probe_work [drm_kms_helper]
Call Trace:
dump_stack+0x85/0xcb
print_circular_ bug.isra. 38+0x1ce/ 0x1db
__lock_acquire+ 0x128f/ 0x1350
? lock_acquire+0x9f/0x200
? lock_acquire+0x9f/0x200
? __ww_mutex_lock.constprop. 13+0x8f/ 0x1000
lock_acquire+0x9f/0x200
? drm_fb_helper_ add_one_ connector+ 0x2a/0x60 [drm_kms_helper]
? drm_fb_helper_ add_one_ connector+ 0x2a/0x60 [drm_kms_helper]
__mutex_lock+0x70/ 0x9d0
? drm_fb_helper_ add_one_ connector+ 0x2a/0x60 [drm_kms_helper]
? ww_mutex_lock+0x43/ 0x80
? _cond_resched+0x15/0x30
? ww_mutex_lock+0x43/ 0x80
? drm_modeset_lock+0xb2/ 0x130 [drm]
? drm_fb_helper_ add_one_ connector+ 0x2a/0x60 [drm_kms_helper]
drm_fb_helper_ add_one_ connector+ 0x2a/0x60 [drm_kms_helper]
nv50_mstm_register_ connector+ 0x2c/0x50 [nouveau]
drm_dp_add_port+ 0x2f5/0x420 [drm_kms_helper]
? mark_held_locks+0x50/ 0x80
? kfree+0xcf/0x2a0
? drm_dp_check_mstb_ guid+0xd6/ 0x120 [drm_kms_helper]
? trace_hardirqs_on_caller+ 0xed/0x180
? drm_dp_check_mstb_ guid+0xd6/ 0x120 [drm_kms_helper]
drm_dp_send_link_ address+ 0x155/0x1e0 [drm_kms_helper]
drm_dp_add_port+ 0x33f/0x420 [drm_kms_helper]
? nouveau_connector_ aux_xfer+ 0x7c/0xb0 [nouveau]
? find_held_lock+0x2d/ 0x90
? drm_dp_dpcd_access+ 0xd9/0xf0 [drm_kms_helper]
? __mutex_unlock_ slowpath+ 0x3b/0x280
? drm_dp_dpcd_access+ 0xd9/0xf0 [drm_kms_helper]
drm_dp_send_link_ address+ 0x155/0x1e0 [drm_kms_helper]
drm_dp_check_and_ send_link_ address+ 0x87/0xd0 [drm_kms_helper]
drm_dp_mst_link_ probe_work+ 0x4d/0x80 [drm_kms_helper]
process_one_work+ 0x20d/0x650
worker_thread+ 0x3a/0x390
? process_one_work+ 0x650/0x650
kthread+0x11e/0x140
? kthread_create_ worker_ on_cpu+ 0x50/0x50
ret_from_fork+0x3a/ 0x50 Taking example from i915, the only time we need to hold any modesetting
locks is when changing the port on the mstc, and in that case we only
need to hold the connection mutex.Signed-off-by: Lyude Paul <email address hidden>
Cc: Karol Herbst <email address hidden>
Cc: <email address hidden>Signed-off-by: Lyude Paul <email address hidden>
Signed-off-by: Ben Skeggs <email address hidden>
(cherry-picked from 352672db857290ab5b0e2b6a99c414 f92bee024c)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - 1fc4098... by Joseph Salisbury
-
Revert "UBUNTU: SAUCE: (no-up) i915: Remove MODULE_FIRMWARE statements for unreleased firmware"
BugLink: http://
bugs.launchpad. net/bugs/ 1728238 This reverts commit dc0f16f9b5084e6
be2b8c79f8c6cd4 99a3451791. This firmware was optional when the MODULE_FIRMWARE statements were
removed. The firmware is now available, so these statements need to be
added back.Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - 3e59701... by "Rafael J. Wysocki" <email address hidden>
-
PCI / PM: Check device_may_wakeup() in pci_enable_wake()
BugLink: http://
bugs.launchpad. net/bugs/ 1745646 Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
went too far and dropped the device_may_wakeup() check from
pci_enable_wake() which causes wakeup to be enabled during system
suspend, hibernation or shutdown for some PCI devices that are not
allowed by user space to wake up the system from sleep (or power off).As a result of this excessive power is drawn by some of the affected
systems while in sleep states or off.Restore the device_may_wakeup() check in pci_enable_wake(), but make
sure that the PCI bus type's runtime suspend callback will not call
device_may_wakeup() which is about system wakeup from sleep and not
about device wakeup from runtime suspend.Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
Reported-by: Joseph Salisbury <email address hidden>
Cc: 4.13+ <email address hidden> # 4.13+
Signed-off-by: Rafael J. Wysocki <email address hidden>
Acked-by: Bjorn Helgaas <email address hidden>
(cherry-picked from cfcadfaad7251d8b640713724b3881 64d75465b2)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - c06ed45... by Jani Nikula <email address hidden>
-
drm/i915/bios: filter out invalid DDC pins from VBT child devices
BugLink: http://
bugs.launchpad. net/bugs/ 1764194 The VBT contains the DDC pin to use for specific ports. Alas, sometimes
the field appears to contain bogus data, and while we check for it later
on in intel_gmbus_get_adapter( ) we fail to check the returned NULL on
errors. Oops results.The simplest approach seems to be to catch and ignore the bogus DDC pins
already at the VBT parsing phase, reverting to fixed per port default
pins. This doesn't guarantee display working, but at least it prevents
the oops. And we continue to be fuzzed by VBT.One affected machine is Dell Latitude 5590 where a BIOS upgrade added
invalid DDC pins.Typical backtrace:
[ 35.461411] WARN_ON(
!intel_ gmbus_is_ valid_pin( dev_priv, pin))
[ 35.461432] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/ i915/intel_ i2c.c:844 intel_gmbus_ get_adapter+ 0x32/0x37 [i915]
[ 35.461437] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
[ 35.461445] CPU: 6 PID: 411 Comm: kworker/u16:2 Not tainted 4.16.0-rc7.x64- g1cda370ffded #1
[ 35.461447] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
[ 35.461450] Workqueue: events_unbound async_run_entry_fn
[ 35.461465] RIP: 0010:intel_gmbus_get_ adapter+ 0x32/0x37 [i915]
[ 35.461467] RSP: 0018:ffff9b4e43d47c40 EFLAGS: 00010286
[ 35.461469] RAX: 0000000000000000 RBX: ffff98f90639f800 RCX: ffffffffae051960
[ 35.461471] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000246
[ 35.461472] RBP: ffff98f905410000 R08: 0000004d062a83f6 R09: 00000000000003bd
[ 35.461474] R10: 0000000000000031 R11: ffffffffad4eda58 R12: ffff98f905410000
[ 35.461475] R13: ffff98f9064c1000 R14: ffff9b4e43d47cf0 R15: ffff98f905410000
[ 35.461477] FS: 0000000000000000(0000) GS:ffff98f92e58 0000(0000) knlGS:000000000 0000000
[ 35.461479] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 35.461481] CR2: 00007f5682359008 CR3: 00000001b700c005 CR4: 00000000003606e0
[ 35.461483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 35.461484] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 35.461486] Call Trace:
[ 35.461501] intel_hdmi_set_edid+ 0x37/0x27f [i915]
[ 35.461515] intel_hdmi_detect+ 0x7c/0x97 [i915]
[ 35.461518] drm_helper_probe_single_ connector_ modes+0xe1/ 0x6c0
[ 35.461521] drm_setup_crtcs+0x129/ 0xa6a
[ 35.461523] ? __switch_to_asm+ 0x34/0x70
[ 35.461525] ? __switch_to_asm+ 0x34/0x70
[ 35.461527] ? __switch_to_asm+ 0x40/0x70
[ 35.461528] ? __switch_to_asm+ 0x34/0x70
[ 35.461529] ? __switch_to_asm+ 0x40/0x70
[ 35.461531] ? __switch_to_asm+ 0x34/0x70
[ 35.461532] ? __switch_to_asm+ 0x40/0x70
[ 35.461534] ? __switch_to_asm+ 0x34/0x70
[ 35.461536] __drm_fb_helper_ initial_ config_ and_unlock+ 0x34/0x46f
[ 35.461538] ? __switch_to_asm+ 0x40/0x70
[ 35.461541] ? _cond_resched+0x10/0x33
[ 35.461557] intel_fbdev_initial_ config+ 0xf/0x1c [i915]
[ 35.461560] async_run_entry_fn+ 0x2e/0xf5
[ 35.461563] process_one_work+ 0x15b/0x364
[ 35.461565] worker_thread+ 0x2c/0x3a0
[ 35.461567] ? process_one_work+ 0x364/0x364
[ 35.461568] kthread+0x10c/0x122
[ 35.461570] ? _kthread_create_ on_node+ 0x5d/0x5d
[ 35.461572] ret_from_fork+0x35/ 0x40
[ 35.461574] Code: 74 16 89 f6 48 8d 04 b6 48 c1 e0 05 48 29 f0 48 8d 84 c7 e8 11 00 00 c3 48 c7 c6 b0 19 1e c0 48 c7 c7 64 8a 1c c0 e8 47 88 ed ec <0f> 0b 31 c0 c3 8b 87 a4 04 00 00 80 e4 fc 09 c6 89 b7 a4 04 00
[ 35.461604] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/ i915/intel_ i2c.c:844 intel_gmbus_ get_adapter+ 0x32/0x37 [i915]
[ 35.461606] ---[ end trace 4fe1e63e2dd93373 ]---
[ 35.461609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 35.461613] IP: i2c_transfer+0x4/0x86
[ 35.461614] PGD 0 P4D 0
[ 35.461616] Oops: 0000 [#1] SMP PTI
[ 35.461618] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
[ 35.461624] CPU: 6 PID: 411 Comm: kworker/u16:2 Tainted: G W 4.16.0-rc7.x64- g1cda370ffded #1
[ 35.461625] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
[ 35.461628] Workqueue: events_unbound async_run_entry_fn
[ 35.461630] RIP: 0010:i2c_transfer+ 0x4/0x86
[ 35.461631] RSP: 0018:ffff9b4e43d47b30 EFLAGS: 00010246
[ 35.461633] RAX: ffff9b4e43d47b6e RBX: 0000000000000005 RCX: 0000000000000001
[ 35.461635] RDX: 0000000000000002 RSI: ffff9b4e43d47b80 RDI: 0000000000000000
[ 35.461636] RBP: ffff9b4e43d47bd8 R08: 0000004d062a83f6 R09: 00000000000003bd
[ 35.461638] R10: 0000000000000031 R11: ffffffffad4eda58 R12: 0000000000000002
[ 35.461639] R13: 0000000000000001 R14: ffff9b4e43d47b6f R15: ffff9b4e43d47c07
[ 35.461641] FS: 0000000000000000(0000) GS:ffff98f92e58 0000(0000) knlGS:000000000 0000000
[ 35.461643] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 35.461645] CR2: 0000000000000010 CR3: 00000001b700c005 CR4: 00000000003606e0
[ 35.461646] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 35.461647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 35.461649] Call Trace:
[ 35.461652] drm_do_probe_ddc_ edid+0xb3/ 0x128
[ 35.461654] drm_get_edid+0xe5/ 0x38d
[ 35.461669] intel_hdmi_set_edid+ 0x45/0x27f [i915]
[ 35.461684] intel_hdmi_detect+ 0x7c/0x97 [i915]
[ 35.461687] drm_helper_probe_single_ connector_ modes+0xe1/ 0x6c0
[ 35.461689] drm_setup_crtcs+0x129/ 0xa6a
[ 35.461691] ? __switch_to_asm+ 0x34/0x70
[ 35.461693] ? __switch_to_asm+ 0x34/0x70
[ 35.461694] ? __switch_to_asm+ 0x40/0x70
[ 35.461696] ? __switch_to_asm+ 0x34/0x70
[ 35.461697] ? __switch_to_asm+ 0x40/0x70
[ 35.461698] ? __switch_to_asm+ 0x34/0x70
[ 35.461700] ? __switch_to_asm+ 0x40/0x70
[ 35.461701] ? __switch_to_asm+ 0x34/0x70
[ 35.461703] __drm_fb_helper_ initial_ config_ and_unlock+ 0x34/0x46f
[ 35.461705] ? __switch_to_asm+ 0x40/0x70
[ 35.461707] ? _cond_resched+0x10/0x33
[ 35.461724] intel_fbdev_initial_ config+ 0xf/0x1c [i915]
[ 35.461727] async_run_entry_fn+ 0x2e/0xf5
[ 35.461729] process_one_work+ 0x15b/0x364
[ 35.461731] worker_thread+ 0x2c/0x3a0
[ 35.461733] ? process_one_work+ 0x364/0x364
[ 35.461734] kthread+0x10c/0x122
[ 35.461736] ? _kthread_create_ on_node+ 0x5d/0x5d
[ 35.461738] ret_from_fork+0x35/ 0x40
[ 35.461739] Code: 5c fa e1 ad 48 89 df e8 ea fb ff ff e9 2a ff ff ff 0f 1f 44 00 00 31 c0 e9 43 fd ff ff 31 c0 45 31 e4 e9 c5 fd ff ff 41 54 55 53 <48> 8b 47 10 48 83 78 10 00 74 70 41 89 d4 48 89 f5 48 89 fb 65
[ 35.461756] RIP: i2c_transfer+0x4/0x86 RSP: ffff9b4e43d47b30
[ 35.461757] CR2: 0000000000000010
[ 35.461759] ---[ end trace 4fe1e63e2dd93374 ]---Based on a patch by Fei Li.
v2: s/reverting/
sticking/ (Chris) Cc: <email address hidden>
Cc: Fei Li <email address hidden>
Co-developed-by: Fei Li <email address hidden>
Reported-by: Pavel Nakonechnyi <email address hidden>
Reported-and-tested- by: Seweryn Kokot <email address hidden>
Reported-and-tested- by: Laszlo Valko <email address hidden>
Bugzilla: https://bugs.freedeskt op.org/ show_bug. cgi?id= 105549
Bugzilla: https://bugs.freedeskt op.org/ show_bug. cgi?id= 105961
Reviewed-by: Chris Wilson <email address hidden>
Signed-off-by: Jani Nikula <email address hidden>
Link: https://patchwork<email address hidden>
(cherry picked from commit f212bf9abe5de9f938fecea7df0704 6e74052dde)
Signed-off-by: Joonas Lahtinen <email address hidden>
(cherry picked from commit a3520b8992e57bc94ab6ec9f95f09c 6c932555fd)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - 729ddb7... by Luca Coelho
-
iwlwifi: add a bunch of new 9000 PCI IDs
BugLink: https:/
/bugs.launchpad .net/bugs/ 1748853 A lot of new PCI IDs were added for the 9000 series. Add them to the
list of supported PCI IDs.Cc: <email address hidden> # 4.13+
Signed-off-by: Luca Coelho <email address hidden>
(cherry picked from commit 9e5053ad9d590e095829a8bb07adbb dbd893f0f9)
Signed-off-by: AceLan Kao <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Kai-Heng Feng <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden> - 8750810... by Luca Coelho
-
iwlwifi: add shared clock PHY config flag for some devices
BugLink: https:/
/bugs.launchpad .net/bugs/ 1748853 Some devices use a shared clock which is very sensitive to variations
and cause trouble in some situations. We need to set a bit in the phy
configuration to indicate that to the FW. To make this generic, add a
extra_phy_config_ flags element to the device configuration and OR it
into the phy_cfg before sending it to the firmware. And also create a
set of configurations for devices that use shared clocks and need this
extra bit to be set.Fixes: c62446d2b028 ("iwlwifi: add new 9460 series PCI IDs")
Signed-off-by: Luca Coelho <email address hidden>
(backported from commit 86a2b2043af79deff5cf000c5a0884 7faa4f2ee0)
Signed-off-by: AceLan Kao <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Kai-Heng Feng <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden> - 3cdc650... by Kai-Heng Feng
-
PCI / PM: Always check PME wakeup capability for runtime wakeup support
BugLink: https:/
/bugs.launchpad .net/bugs/ 1764684 USB controller ASM1042 stops working after commit de3ef1eb1cd0 (PM /
core: Drop run_wake flag from struct dev_pm_info).The device in question is not power managed by platform firmware,
furthermore, it only supports PME# from D3cold:
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2- ,D3hot- ,D3cold+ )
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-Before commit de3ef1eb1cd0, the device never gets runtime suspended.
After that commit, the device gets runtime suspended to D3hot, which can
not generate any PME#.usb_hcd_pci_probe() unconditionally calls device_
wakeup_ enable( ), hence
device_can_wakeup() in pci_dev_run_wake() always returns true.So pci_dev_run_wake() needs to check PME wakeup capability as its first
condition.In addition, change wakeup flag passed to pci_target_state() from false
to true, because we want to find the deepest state different from D3cold
that the device can still generate PME#. In this case, it's D0 for the
device in question.Fixes: de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info)
Signed-off-by: Kai-Heng Feng <email address hidden>
Cc: 4.13+ <email address hidden> # 4.13+
Acked-by: Bjorn Helgaas <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit 8feaec33b9868582654cd3d5355225 dcb79aeca6)
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Po-Hsu Lin <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden> - 1919930... by Jeffrey Hugo
-
init: fix false positives in W+X checking
load_module() creates W+X mappings via __vmalloc_
node_range( ) (from
layout_and_allocate( )->move_ module( )->module_ alloc() ) by using
PAGE_KERNEL_EXEC. These mappings are later cleaned up via
"call_rcu_sched(& freeinit- >rcu, do_free_init)" from do_init_module(). This is a problem because call_rcu_sched() queues work, which can be run
after debug_checkwx() is run, resulting in a race condition. If hit,
the race results in a nasty splat about insecure W+X mappings, which
results in a poor user experience as these are not the mappings that
debug_checkwx() is intended to catch.This issue is observed on multiple arm64 platforms, and has been
artificially triggered on an x86 platform.Address the race by flushing the queued work before running the
arch-defined mark_rodata_ro() which then calls debug_checkwx().Link: http://<email address hidden>
Fixes: e1a58320a38d ("x86/mm: Warn on W^X mappings")BugLink: https:/
/launchpad. net/bugs/ 1769696 Signed-off-by: Jeffrey Hugo <email address hidden>
Reported-by: Timur Tabi <email address hidden>
Reported-by: Jan Glauber <email address hidden>
Acked-by: Kees Cook <email address hidden>
Acked-by: Ingo Molnar <email address hidden>
Acked-by: Will Deacon <email address hidden>
Acked-by: Laura Abbott <email address hidden>
Cc: Mark Rutland <email address hidden>
Cc: Ard Biesheuvel <email address hidden>
Cc: Catalin Marinas <email address hidden>
Cc: Stephen Smalley <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry picked from commit ae646f0b9ca135b87bc73ff606ef99 6c3029780a)
Signed-off-by: Manoj Iyer <email address hidden>
Acked-by: Joseph Salisbury <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden> - 53878f8... by Greg Kroah-Hartman <email address hidden>
-
Linux 4.15.18
BugLink: http://
bugs.launchpad. net/bugs/ 1769723 Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden> - d26337f... by Amir Goldstein <email address hidden>
-
ovl: set lower layer st_dev only if setting lower st_ino
BugLink: http://
bugs.launchpad. net/bugs/ 1769723 commit 9f99e50d460ac7f
d5f6c9b97aad008 8c28c8656d upstream. For broken hardlinks, we do not return lower st_ino, so we should
also not return lower pseudo st_dev.Fixes: a0c5ad307ac0 ("ovl: relax same fs constraint for constant st_ino")
Cc: <email address hidden> #v4.15
Signed-off-by: Amir Goldstein <email address hidden>
Signed-off-by: Miklos Szeredi <email address hidden>
Signed-off-by: Amir Goldstein <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>