Age | Commit message (Collapse) | Author | Files | Lines |
|
Use the dma_fence_match_context helper to check if all backing fences
are from our own context, in which case we don't have to wait.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.com>
[rebased on code-motion]
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Otherwise, if userspace doesn't re-use a given plane, it's hwpipe(s)
could stay permanently assigned.
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
If we follow the typical pattern of the base class being the first
member, we can use the default dma_fence_free function.
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Without this, polling on the dma-buf (and presumably other devices
synchronizing against our rendering) would return immediately, even
while the BO was busy.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Otherwise if someone was using old bindings with "core_clk" instead of
"core" as the clock name, we'd never find it and gpu would be stuck at
27MHz (or whatever it's slowest rate is).
Fixes: 98db803 ("msm/drm: gpu: Dynamically locate the clocks from the device tree")
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Somehow the helper was never retrofitted for mdp5. Which meant when
plane_state->fence was added, it could get copied into new state in
mdp5_plane_duplicate_state().
If an update to disable the plane (for example on rmfb) managed to sneak
in after an nonblock update had swapped state, but before it was
committed, we'd get a splat:
WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 drm_atomic_helper_wait_for_fences+0xe0/0xf8
Modules linked in:
CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: G W 4.11.0-rc8+ #1187
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Workqueue: events drm_mode_rmfb_work_fn
task: ffffffc036560d00 task.stack: ffffffc036550000
PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8
LR is at complete_commit.isra.1+0x44/0x1c0
pc : [<ffffff80084f6040>] lr : [<ffffff800854176c>] pstate: 20000145
sp : ffffffc036553b60
x29: ffffffc036553b60 x28: ffffffc0264e6a00
x27: ffffffc035659000 x26: 0000000000000000
x25: ffffffc0240e8000 x24: 0000000000000038
x23: 0000000000000000 x22: ffffff800858f200
x21: ffffffc0240e8000 x20: ffffffc02f56a800
x19: 0000000000000000 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: ffffffc00a192700
x13: 0000000000000004 x12: 0000000000000000
x11: ffffff80089a1690 x10: 00000000000008f0
x9 : ffffffc036553b20 x8 : ffffffc036561650
x7 : ffffffc03fe6cb40 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000002
x3 : ffffffc035659000 x2 : ffffffc0240e8c80
x1 : 0000000000000000 x0 : ffffffc02adbe588
---[ end trace 13aeec77c3fb55e2 ]---
Call trace:
Exception stack(0xffffffc036553990 to 0xffffffc036553ac0)
3980: 0000000000000000 0000008000000000
39a0: ffffffc036553b60 ffffff80084f6040 0000000000004ff0 0000000000000038
39c0: ffffffc0365539d0 ffffff800857e098 ffffffc036553a00 ffffff800857e1b0
39e0: ffffffc036553a10 ffffff800857c554 ffffffc0365e8400 ffffffc0365e8400
3a00: ffffffc036553a20 ffffff8008103358 000000000001aad7 ffffff800851b72c
3a20: ffffffc036553a50 ffffff80080e9228 ffffffc02adbe588 0000000000000000
3a40: ffffffc0240e8c80 ffffffc035659000 0000000000000002 0000000000000001
3a60: 0000000000000000 ffffffc03fe6cb40 ffffffc036561650 ffffffc036553b20
3a80: 00000000000008f0 ffffff80089a1690 0000000000000000 0000000000000004
3aa0: ffffffc00a192700 0000000000000000 0000000000000000 0000000000000000
[<ffffff80084f6040>] drm_atomic_helper_wait_for_fences+0xe0/0xf8
[<ffffff800854176c>] complete_commit.isra.1+0x44/0x1c0
[<ffffff8008541c64>] msm_atomic_commit+0x32c/0x350
[<ffffff8008516230>] drm_atomic_commit+0x50/0x60
[<ffffff8008517548>] drm_atomic_remove_fb+0x158/0x250
[<ffffff80085186d0>] drm_framebuffer_remove+0x50/0x158
[<ffffff8008518818>] drm_mode_rmfb_work_fn+0x40/0x58
[<ffffff80080d5668>] process_one_work+0x1d0/0x378
[<ffffff80080d5a54>] worker_thread+0x244/0x488
[<ffffff80080db7fc>] kthread+0xfc/0x128
[<ffffff8008082ec0>] ret_from_fork+0x10/0x50
Fixes: 9626014 ("drm/fence: add in-fences support")
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Otherwise, if nothing else enabled selects it, dev_pm_opp_of_add_table()
will return -ENOTSUPP.
Fixes: e2af8b6 ("drm/msm: gpu: Use OPP tables if we can")
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
this bug happened when amdgpu load failed.
[ 75.740951] BUG: unable to handle kernel paging request at 00000000000031c0
[ 75.748167] IP: [<ffffffffa064a0e0>] amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu]
[ 75.755774] PGD 0
[ 75.759185] Oops: 0000 [#1] SMP
[ 75.762408] Modules linked in: amdgpu(OE-) ttm(OE) drm_kms_helper(OE) drm(OE) i2c_algo_bit(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) rpcsec_gss_krb5(E) nfsv4(E) nfs(E) fscache(E) eeepc_wmi(E) asus_wmi(E) sparse_keymap(E) intel_rapl(E) snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_intel(E) snd_hda_codec(E) snd_hda_core(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) snd_hwdep(E) snd_pcm(E) snd_seq_midi(E) coretemp(E) kvm_intel(E) snd_seq_midi_event(E) snd_rawmidi(E) kvm(E) snd_seq(E) joydev(E) snd_seq_device(E) snd_timer(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) mei_me(E) ghash_clmulni_intel(E) snd(E) aesni_intel(E) mei(E) soundcore(E) aes_x86_64(E) shpchp(E) serio_raw(E) lrw(E) acpi_pad(E) gf128mul(E) glue_helper(E) ablk_helper(E) mac_hid(E)
[ 75.835574] cryptd(E) parport_pc(E) ppdev(E) lp(E) nfsd(E) parport(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) autofs4(E) hid_generic(E) usbhid(E) mxm_wmi(E) psmouse(E) e1000e(E) ptp(E) pps_core(E) ahci(E) libahci(E) wmi(E) video(E) i2c_hid(E) hid(E)
[ 75.858489] CPU: 5 PID: 1603 Comm: rmmod Tainted: G OE 4.9.0-custom #2
[ 75.866183] Hardware name: System manufacturer System Product Name/Z170-A, BIOS 0901 08/31/2015
[ 75.875050] task: ffff88045d1bbb80 task.stack: ffffc90002de4000
[ 75.881094] RIP: 0010:[<ffffffffa064a0e0>] [<ffffffffa064a0e0>] amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu]
[ 75.891238] RSP: 0018:ffffc90002de7d48 EFLAGS: 00010286
[ 75.896648] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
[ 75.903933] RDX: 0000000000000000 RSI: ffff88045d1bbb80 RDI: 0000000000000286
[ 75.911183] RBP: ffffc90002de7d50 R08: 0000000000000502 R09: 0000000000000004
[ 75.918449] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880464bf0000
[ 75.925675] R13: ffffffffa0853000 R14: 0000000000000000 R15: 0000564e44f88210
[ 75.932980] FS: 00007f13d5400700(0000) GS:ffff880476540000(0000) knlGS:0000000000000000
[ 75.941238] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 75.947088] CR2: 00000000000031c0 CR3: 000000045fd0b000 CR4: 00000000003406e0
[ 75.954332] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 75.961566] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 75.968834] Stack:
[ 75.970881] ffff880464bf0000 ffffc90002de7d60 ffffffffa0636592 ffffc90002de7d80
[ 75.978454] ffffffffa059015f ffff880464bf0000 ffff880464bf0000 ffffc90002de7da8
[ 75.986076] ffffffffa0595216 ffff880464bf0000 ffff880460f4d000 ffffffffa0853000
[ 75.993692] Call Trace:
[ 75.996177] [<ffffffffa0636592>] amdgpu_driver_lastclose_kms+0x12/0x20 [amdgpu]
[ 76.003700] [<ffffffffa059015f>] drm_lastclose+0x2f/0xd0 [drm]
[ 76.009777] [<ffffffffa0595216>] drm_dev_unregister+0x16/0xd0 [drm]
[ 76.016255] [<ffffffffa0595944>] drm_put_dev+0x34/0x70 [drm]
[ 76.022139] [<ffffffffa062f365>] amdgpu_pci_remove+0x15/0x20 [amdgpu]
[ 76.028800] [<ffffffff81416499>] pci_device_remove+0x39/0xc0
[ 76.034661] [<ffffffff81531caa>] __device_release_driver+0x9a/0x140
[ 76.041121] [<ffffffff81531e58>] driver_detach+0xb8/0xc0
[ 76.046575] [<ffffffff81530c95>] bus_remove_driver+0x55/0xd0
[ 76.052401] [<ffffffff815325fc>] driver_unregister+0x2c/0x50
[ 76.058244] [<ffffffff81416289>] pci_unregister_driver+0x29/0x90
[ 76.064466] [<ffffffffa0596c5e>] drm_pci_exit+0x9e/0xb0 [drm]
[ 76.070507] [<ffffffffa0796d71>] amdgpu_exit+0x1c/0x32 [amdgpu]
[ 76.076609] [<ffffffff81104810>] SyS_delete_module+0x1a0/0x200
[ 76.082627] [<ffffffff810e2b1a>] ? rcu_eqs_enter.isra.36+0x4a/0x50
[ 76.089001] [<ffffffff8100392e>] do_syscall_64+0x6e/0x180
[ 76.094583] [<ffffffff817e1d2f>] entry_SYSCALL64_slow_path+0x25/0x25
[ 76.101114] Code: 94 c0 c3 31 c0 5d c3 0f 1f 40 00 0f 1f 44 00 00 55 31 c0 48 89 e5 53 48 89 fb 48 c7 c7 1d 21 84 a0 e8 ab 77 b3 e0 e8 fc 8b d7 e0 <48> 8b bb c0 31 00 00 48 85 ff 74 09 e8 ff eb fc ff 85 c0 75 03
[ 76.121432] RIP [<ffffffffa064a0e0>] amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu]
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Smatch complains about a signedness bug here:
vega10_hwmgr.c:4202 vega10_force_clock_level()
warn: always true condition '(i >= 0) => (0-u32max >= 0)'
Fixes: 7b52db39a4c2 ("drm/amd/powerplay: fix bug sclk/mclk
level can't be set on vega10.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Huang <JinHuiEric.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[ 338.384770] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 338.384817] IP: [< (null)>] (null)
[ 338.385505] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
[ 338.385950] Call Trace:
[ 338.385993] [<ffffffffa05d2313>] ? amdgpu_vm_flush+0x283/0x400 [amdgpu]
[ 338.386025] [<ffffffff811818d3>] ? printk+0x4d/0x4f
[ 338.386074] [<ffffffffa05d4906>] amdgpu_ib_schedule+0x4a6/0x4d0 [amdgpu]
[ 338.386140] [<ffffffffa0673e54>] amdgpu_job_run+0x64/0x180 [amdgpu]
[ 338.386203] [<ffffffffa0672e09>] amd_sched_main+0x2e9/0x4a0 [amdgpu]
[ 338.386232] [<ffffffff810bfce0>] ? prepare_to_wait_event+0x110/0x110
[ 338.386295] [<ffffffffa0672b20>] ? amd_sched_select_entity+0xe0/0xe0 [amdgpu]
[ 338.386327] [<ffffffff8109b423>] kthread+0xd3/0xf0
[ 338.386349] [<ffffffff8109b350>] ? kthread_park+0x60/0x60
[ 338.386376] [<ffffffff817e1ee5>] ret_from_fork+0x25/0x30
[ 338.386401] Code: Bad RIP value.
[ 338.386420] RIP [< (null)>] (null)
[ 338.386443] RSP <ffffc90001bd7d40>
[ 338.386458] CR2: 0000000000000000
[ 338.398508] ---[ end trace 4c66fcdc74b9a0a2 ]---
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We end up reading the interrupt register for HPD5, and then writing it
to HPD6 which on systems without anything using HPD5 results in
permanently disabling hotplug on one of the display outputs after the
first time we acknowledge a hotplug interrupt from the GPU.
This code is really bad. But for now, let's just fix this. I will
hopefully have a large patch series to refactor all of this soon.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Lyude <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Even if the vblank period would allow it, it still seems to
be problematic on some cards.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868
Cc: stable@vger.kernel.org
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Check to make sure the vblank period is long enough to support
mclk switching.
v2: drop needless initial assignment (Nils)
bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868
Cc: stable@vger.kernel.org
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Even if the vblank period would allow it, it still seems to
be problematic on some cards.
v2: fix logic inversion (Nils)
bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868
Cc: stable@vger.kernel.org
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Even if the vblank period would allow it, it still seems to
be problematic on some cards.
v2: fix logic inversion (Nils)
bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868
Cc: stable@vger.kernel.org
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Reinitializing the VM manager during suspend/resume is a very very bad
idea since all the VMs are still active and kicking.
This can lead to random VM faults after resume when new processes
become the same client ID assigned.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
With LVDS we were incorrectly picking the pre-programmed mode instead of
the prefered mode provided by VBT. Make sure we pick the VBT mode if
one is provided. It is likely that the mode read-out code is still wrong
but this patch fixes the immediate problem on most machines.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78562
Cc: <stable@vger.kernel.org>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170418114332.12183-1-patrik.r.jakobsson@gmail.com
|
|
I failed to properly onion-wrap the unwind code: We acquire the vblank
reference before we start with the wait-wound locking dance, hence we
must make sure we retry before we drop the reference. Oops.
v2: The vblank_put must be after the frambuffer_put (Michel). I suck at
unwrapping code that doesn't use separate labels for each stage, but
checks each pointer first ... While re-reading everything I also
realized that we must clean up the fb refcounts, and specifically
plane->old_fb before we drop the locks, either in the final unlocking,
or in the w/w retry path. Hence the correct fix is to drop the
vblank_put to the very bottom.
Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl")
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Reported-by: Tommi Rantala <tt.rantala@gmail.com>
Cc: Tommi Rantala <tt.rantala@gmail.com>
Cc: Michel Dänzer <michel@daenzer.net>
Tested-by: Tommi Rantala <tt.rantala@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170522135945.28831-1-daniel.vetter@ffwll.ch
|
|
qxl_release_map will enter an atomic context, but since we still need to
alloc memory for BOs, we better delay that until we have everything we
need, in case we need to sleep inside the allocation. This avoids the
Sleep in atomic state below, which was reported by Mike.
[ 43.910362] BUG: sleeping function called from invalid context at mm/slab.h:432
[ 43.910955] in_atomic(): 1, irqs_disabled(): 0, pid: 2077, name: Xorg
[ 43.911472] Preemption disabled at:
[ 43.911478] [<ffffffffa02b1c45>] qxl_bo_kmap_atomic_page+0xa5/0x100 [qxl]
[ 43.912103] CPU: 0 PID: 2077 Comm: Xorg Tainted: G E 4.12.0-master #38
[ 43.912550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.8.1-0-g4adadbd-20161202_174313-build11a 04/01/2014
[ 43.913202] Call Trace:
[ 43.913371] dump_stack+0x65/0x89
[ 43.913581] ? qxl_bo_kmap_atomic_page+0xa5/0x100 [qxl]
[ 43.913876] ___might_sleep+0x11a/0x190
[ 43.914095] __might_sleep+0x4a/0x80
[ 43.914319] ? qxl_bo_create+0x50/0x190 [qxl]
[ 43.914565] kmem_cache_alloc_trace+0x46/0x180
[ 43.914836] qxl_bo_create+0x50/0x190 [qxl]
[ 43.915082] ? refcount_dec_and_test+0x11/0x20
[ 43.915332] ? ttm_mem_io_reserve+0x41/0xe0 [ttm]
[ 43.915595] qxl_alloc_bo_reserved+0x37/0xb0 [qxl]
[ 43.915884] qxl_cursor_atomic_update+0x8f/0x260 [qxl]
[ 43.916172] ? drm_atomic_helper_update_legacy_modeset_state+0x1d6/0x210 [drm_kms_helper]
[ 43.916623] drm_atomic_helper_commit_planes+0xec/0x230 [drm_kms_helper]
[ 43.916995] drm_atomic_helper_commit_tail+0x2b/0x60 [drm_kms_helper]
[ 43.917398] commit_tail+0x65/0x70 [drm_kms_helper]
[ 43.917693] drm_atomic_helper_commit+0xa9/0x100 [drm_kms_helper]
[ 43.918039] drm_atomic_commit+0x4b/0x50 [drm]
[ 43.918334] drm_atomic_helper_update_plane+0xf1/0x110 [drm_kms_helper]
[ 43.918902] __setplane_internal+0x19f/0x280 [drm]
[ 43.919240] drm_mode_cursor_universal+0x101/0x1c0 [drm]
[ 43.919541] drm_mode_cursor_common+0x15b/0x1d0 [drm]
[ 43.919858] drm_mode_cursor2_ioctl+0xe/0x10 [drm]
[ 43.920157] drm_ioctl+0x211/0x460 [drm]
[ 43.920383] ? drm_mode_cursor_ioctl+0x50/0x50 [drm]
[ 43.920664] ? handle_mm_fault+0x93/0x160
[ 43.920893] do_vfs_ioctl+0x96/0x6e0
[ 43.921117] ? __fget+0x73/0xa0
[ 43.921322] SyS_ioctl+0x41/0x70
[ 43.921545] entry_SYSCALL_64_fastpath+0x1a/0xa5
[ 43.922188] RIP: 0033:0x7f1145804bc7
[ 43.922526] RSP: 002b:00007ffcd3e50508 EFLAGS: 00003246 ORIG_RAX: 0000000000000010
[ 43.923367] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 00007f1145804bc7
[ 43.923852] RDX: 00007ffcd3e50540 RSI: 00000000c02464bb RDI: 000000000000000b
[ 43.924299] RBP: 0000000000000040 R08: 0000000000000040 R09: 000000000000000c
[ 43.924694] R10: 00007ffcd3e50340 R11: 0000000000003246 R12: 0000000000000018
[ 43.925128] R13: 00000000022bc390 R14: 0000000000000040 R15: 00007ffcd3e5062c
Reported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170519175819.15682-1-krisman@collabora.co.uk
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
Nicolai Stange reports the following oops which is caused by
dereferencing rdev->pdev before it's subsequently set by
radeon_device_init(). Fix it.
BUG: unable to handle kernel NULL pointer dereference at 00000000000007cb
IP: radeon_driver_load_kms+0xeb/0x230 [radeon]
...
Call Trace:
drm_dev_register+0x146/0x1d0 [drm]
drm_get_pci_dev+0x9a/0x180 [drm]
radeon_pci_probe+0xb8/0xe0 [radeon]
local_pci_probe+0x45/0xa0
pci_device_probe+0x14f/0x1a0
driver_probe_device+0x29c/0x450
__driver_attach+0xdf/0xf0
? driver_probe_device+0x450/0x450
bus_for_each_dev+0x6c/0xc0
driver_attach+0x1e/0x20
bus_add_driver+0x170/0x270
driver_register+0x60/0xe0
? 0xffffffffc0508000
__pci_register_driver+0x4c/0x50
drm_pci_init+0xeb/0x100 [drm]
? vga_switcheroo_register_handler+0x6a/0x90
? 0xffffffffc0508000
radeon_init+0x98/0xb6 [radeon]
do_one_initcall+0x52/0x1a0
? __vunmap+0x81/0xb0
? kmem_cache_alloc_trace+0x159/0x1b0
? do_init_module+0x27/0x1f8
do_init_module+0x5f/0x1f8
load_module+0x27ce/0x2be0
SYSC_finit_module+0xdf/0x110
? SYSC_finit_module+0xdf/0x110
SyS_finit_module+0xe/0x10
do_syscall_64+0x67/0x150
entry_SYSCALL64_slow_path+0x25/0x25
Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo")
Reported-and-tested-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/cfb91ba052af06117137eec0637543a2626a7979.1495135190.git.lukas@wunner.de
|
|
|
|
The code to fetch a 64-bit value from user space was entirely buggered,
and has been since the code was merged in early 2016 in commit
b2f680380ddf ("x86/mm/32: Add support for 64-bit __get_user() on 32-bit
kernels").
Happily the buggered routine is almost certainly entirely unused, since
the normal way to access user space memory is just with the non-inlined
"get_user()", and the inlined version didn't even historically exist.
The normal "get_user()" case is handled by external hand-written asm in
arch/x86/lib/getuser.S that doesn't have either of these issues.
There were two independent bugs in __get_user_asm_u64():
- it still did the STAC/CLAC user space access marking, even though
that is now done by the wrapper macros, see commit 11f1a4b9755f
("x86: reorganize SMAP handling in user space accesses").
This didn't result in a semantic error, it just means that the
inlined optimized version was hugely less efficient than the
allegedly slower standard version, since the CLAC/STAC overhead is
quite high on modern Intel CPU's.
- the double register %eax/%edx was marked as an output, but the %eax
part of it was touched early in the asm, and could thus clobber other
inputs to the asm that gcc didn't expect it to touch.
In particular, that meant that the generated code could look like
this:
mov (%eax),%eax
mov 0x4(%eax),%edx
where the load of %edx obviously was _supposed_ to be from the 32-bit
word that followed the source of %eax, but because %eax was
overwritten by the first instruction, the source of %edx was
basically random garbage.
The fixes are trivial: remove the extraneous STAC/CLAC entries, and mark
the 64-bit output as early-clobber to let gcc know that no inputs should
alias with the output register.
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: stable@kernel.org # v4.8+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Al noticed that unsafe_put_user() had type problems, and fixed them in
commit a7cc722fff0b ("fix unsafe_put_user()"), which made me look more
at those functions.
It turns out that unsafe_get_user() had a type issue too: it limited the
largest size of the type it could handle to "unsigned long". Which is
fine with the current users, but doesn't match our existing normal
get_user() semantics, which can also handle "u64" even when that does
not fit in a long.
While at it, also clean up the type cast in unsafe_put_user(). We
actually want to just make it an assignment to the expected type of the
pointer, because we actually do want warnings from types that don't
convert silently. And it makes the code more readable by not having
that one very long and complex line.
[ This patch might become stable material if we ever end up back-porting
any new users of the unsafe uaccess code, but as things stand now this
doesn't matter for any current existing uses. ]
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
failing sys_wait4() won't fill struct rusage...
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
__put_user_size() relies upon its first argument having the same type as what
the second one points to; the only other user makes sure of that and
unsafe_put_user() should do the same.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
On rdma read errors, release the sq ref that was taken
when the req was initialized. This avoids a hang in
nvmet_sq_destroy() when the queue is being freed.
Signed-off-by: Vijay Immanuel <vijayi@attalasystems.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Remove NVMET_FCTGTFEAT_NEEDS_CMD_CPUSCHED. It's unnecessary.
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Per the recommendation by Sagi on:
http://lists.infradead.org/pipermail/linux-nvme/2017-April/009261.html
Rather than waiting for reset work thread to stop queues and abort the ios,
immediately stop the queues on error detection. Reset thread will restop
the queues (as it's called on other paths), but it does not appear to have
a side effect.
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
In order to create an association, the remoteport must be
serving either a target role or a discovery role.
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
FC Port roles is a bit mask, not individual values.
Correct nvme definitions to unique bits.
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
CMB doesn't get unmapped until removal while getting remapped on every
reset. Add the unmapping and sysfs file removal to the reset path in
nvme_pci_disable to match the mapping path in nvme_pci_enable.
Fixes: 202021c1a ("nvme : Add sysfs entry for NVMe CMBs when appropriate")
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Acked-by: Keith Busch <keith.busch@intel.com>
Reviewed-By: Stephen Bates <sbates@raithlin.com>
Cc: <stable@vger.kernel.org> # 4.9+
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
get_msr() of MSR_EFER is currently always going to succeed, but static
checker doesn't see that far.
Don't complicate stuff and just use 0 for the fallback -- it means that
the feature is not present.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
|
|
Static analysis noticed that pmu->nr_arch_gp_counters can be 32
(INTEL_PMC_MAX_GENERIC) and therefore cannot be used to shift 'int'.
I didn't add BUILD_BUG_ON for it as we have a better checker.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 25462f7f5295 ("KVM: x86/vPMU: Define kvm_pmu_ops to support vPMU function dispatch")
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
|
|
Static checker noticed that base3 could be used uninitialized if the
segment was not present (useable). Random stack values probably would
not pass VMCS entry checks.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 1aa366163b8b ("KVM: x86 emulator: consolidate segment accessors")
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
|
|
Huawei folks reported a read out-of-bounds vulnerability in kvm pio emulation.
- "inb" instruction to access PIT Mod/Command register (ioport 0x43, write only,
a read should be ignored) in guest can get a random number.
- "rep insb" instruction to access PIT register port 0x43 can control memcpy()
in emulator_pio_in_emulated() to copy max 0x400 bytes but only read 1 bytes,
which will disclose the unimportant kernel memory in host but no crash.
The similar test program below can reproduce the read out-of-bounds vulnerability:
void hexdump(void *mem, unsigned int len)
{
unsigned int i, j;
for(i = 0; i < len + ((len % HEXDUMP_COLS) ? (HEXDUMP_COLS - len % HEXDUMP_COLS) : 0); i++)
{
/* print offset */
if(i % HEXDUMP_COLS == 0)
{
printf("0x%06x: ", i);
}
/* print hex data */
if(i < len)
{
printf("%02x ", 0xFF & ((char*)mem)[i]);
}
else /* end of block, just aligning for ASCII dump */
{
printf(" ");
}
/* print ASCII dump */
if(i % HEXDUMP_COLS == (HEXDUMP_COLS - 1))
{
for(j = i - (HEXDUMP_COLS - 1); j <= i; j++)
{
if(j >= len) /* end of block, not really printing */
{
putchar(' ');
}
else if(isprint(((char*)mem)[j])) /* printable char */
{
putchar(0xFF & ((char*)mem)[j]);
}
else /* other char */
{
putchar('.');
}
}
putchar('\n');
}
}
}
int main(void)
{
int i;
if (iopl(3))
{
err(1, "set iopl unsuccessfully\n");
return -1;
}
static char buf[0x40];
/* test ioport 0x40,0x41,0x42,0x43,0x44,0x45 */
memset(buf, 0xab, sizeof(buf));
asm volatile("push %rdi;");
asm volatile("mov %0, %%rdi;"::"q"(buf));
asm volatile ("mov $0x40, %rdx;");
asm volatile ("in %dx,%al;");
asm volatile ("stosb;");
asm volatile ("mov $0x41, %rdx;");
asm volatile ("in %dx,%al;");
asm volatile ("stosb;");
asm volatile ("mov $0x42, %rdx;");
asm volatile ("in %dx,%al;");
asm volatile ("stosb;");
asm volatile ("mov $0x43, %rdx;");
asm volatile ("in %dx,%al;");
asm volatile ("stosb;");
asm volatile ("mov $0x44, %rdx;");
asm volatile ("in %dx,%al;");
asm volatile ("stosb;");
asm volatile ("mov $0x45, %rdx;");
asm volatile ("in %dx,%al;");
asm volatile ("stosb;");
asm volatile ("pop %rdi;");
hexdump(buf, 0x40);
printf("\n");
/* ins port 0x40 */
memset(buf, 0xab, sizeof(buf));
asm volatile("push %rdi;");
asm volatile("mov %0, %%rdi;"::"q"(buf));
asm volatile ("mov $0x20, %rcx;");
asm volatile ("mov $0x40, %rdx;");
asm volatile ("rep insb;");
asm volatile ("pop %rdi;");
hexdump(buf, 0x40);
printf("\n");
/* ins port 0x43 */
memset(buf, 0xab, sizeof(buf));
asm volatile("push %rdi;");
asm volatile("mov %0, %%rdi;"::"q"(buf));
asm volatile ("mov $0x20, %rcx;");
asm volatile ("mov $0x43, %rdx;");
asm volatile ("rep insb;");
asm volatile ("pop %rdi;");
hexdump(buf, 0x40);
printf("\n");
return 0;
}
The vcpu->arch.pio_data buffer is used by both in/out instrutions emulation
w/o clear after using which results in some random datas are left over in
the buffer. Guest reads port 0x43 will be ignored since it is write only,
however, the function kernel_pio() can't distigush this ignore from successfully
reads data from device's ioport. There is no new data fill the buffer from
port 0x43, however, emulator_pio_in_emulated() will copy the stale data in
the buffer to the guest unconditionally. This patch fixes it by clearing the
buffer before in instruction emulation to avoid to grant guest the stale data
in the buffer.
In addition, string I/O is not supported for in kernel device. So there is no
iteration to read ioport %RCX times for string I/O. The function kernel_pio()
just reads one round, and then copy the io size * %RCX to the guest unconditionally,
actually it copies the one round ioport data w/ other random datas which are left
over in the vcpu->arch.pio_data buffer to the guest. This patch fixes it by
introducing the string I/O support for in kernel device in order to grant the right
ioport datas to the guest.
Before the patch:
0x000000: fe 38 93 93 ff ff ab ab .8......
0x000008: ab ab ab ab ab ab ab ab ........
0x000010: ab ab ab ab ab ab ab ab ........
0x000018: ab ab ab ab ab ab ab ab ........
0x000020: ab ab ab ab ab ab ab ab ........
0x000028: ab ab ab ab ab ab ab ab ........
0x000030: ab ab ab ab ab ab ab ab ........
0x000038: ab ab ab ab ab ab ab ab ........
0x000000: f6 00 00 00 00 00 00 00 ........
0x000008: 00 00 00 00 00 00 00 00 ........
0x000010: 00 00 00 00 4d 51 30 30 ....MQ00
0x000018: 30 30 20 33 20 20 20 20 00 3
0x000020: ab ab ab ab ab ab ab ab ........
0x000028: ab ab ab ab ab ab ab ab ........
0x000030: ab ab ab ab ab ab ab ab ........
0x000038: ab ab ab ab ab ab ab ab ........
0x000000: f6 00 00 00 00 00 00 00 ........
0x000008: 00 00 00 00 00 00 00 00 ........
0x000010: 00 00 00 00 4d 51 30 30 ....MQ00
0x000018: 30 30 20 33 20 20 20 20 00 3
0x000020: ab ab ab ab ab ab ab ab ........
0x000028: ab ab ab ab ab ab ab ab ........
0x000030: ab ab ab ab ab ab ab ab ........
0x000038: ab ab ab ab ab ab ab ab ........
After the patch:
0x000000: 1e 02 f8 00 ff ff ab ab ........
0x000008: ab ab ab ab ab ab ab ab ........
0x000010: ab ab ab ab ab ab ab ab ........
0x000018: ab ab ab ab ab ab ab ab ........
0x000020: ab ab ab ab ab ab ab ab ........
0x000028: ab ab ab ab ab ab ab ab ........
0x000030: ab ab ab ab ab ab ab ab ........
0x000038: ab ab ab ab ab ab ab ab ........
0x000000: d2 e2 d2 df d2 db d2 d7 ........
0x000008: d2 d3 d2 cf d2 cb d2 c7 ........
0x000010: d2 c4 d2 c0 d2 bc d2 b8 ........
0x000018: d2 b4 d2 b0 d2 ac d2 a8 ........
0x000020: ab ab ab ab ab ab ab ab ........
0x000028: ab ab ab ab ab ab ab ab ........
0x000030: ab ab ab ab ab ab ab ab ........
0x000038: ab ab ab ab ab ab ab ab ........
0x000000: 00 00 00 00 00 00 00 00 ........
0x000008: 00 00 00 00 00 00 00 00 ........
0x000010: 00 00 00 00 00 00 00 00 ........
0x000018: 00 00 00 00 00 00 00 00 ........
0x000020: ab ab ab ab ab ab ab ab ........
0x000028: ab ab ab ab ab ab ab ab ........
0x000030: ab ab ab ab ab ab ab ab ........
0x000038: ab ab ab ab ab ab ab ab ........
Reported-by: Moguofang <moguofang@huawei.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Moguofang <moguofang@huawei.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
|
|
BUG: using __this_cpu_read() in preemptible [00000000] code: qemu-system-x86/2809
caller is __this_cpu_preempt_check+0x13/0x20
CPU: 2 PID: 2809 Comm: qemu-system-x86 Not tainted 4.11.0+ #13
Call Trace:
dump_stack+0x99/0xce
check_preemption_disabled+0xf5/0x100
__this_cpu_preempt_check+0x13/0x20
get_kvmclock_ns+0x6f/0x110 [kvm]
get_time_ref_counter+0x5d/0x80 [kvm]
kvm_hv_process_stimers+0x2a1/0x8a0 [kvm]
? kvm_hv_process_stimers+0x2a1/0x8a0 [kvm]
? kvm_arch_vcpu_ioctl_run+0xac9/0x1ce0 [kvm]
kvm_arch_vcpu_ioctl_run+0x5bf/0x1ce0 [kvm]
kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
? kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
? __fget+0xf3/0x210
do_vfs_ioctl+0xa4/0x700
? __fget+0x114/0x210
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x23/0xc2
RIP: 0033:0x7f9d164ed357
? __this_cpu_preempt_check+0x13/0x20
This can be reproduced by run kvm-unit-tests/hyperv_stimer.flat w/
CONFIG_PREEMPT and CONFIG_DEBUG_PREEMPT enabled.
Safe access to per-CPU data requires a couple of constraints, though: the
thread working with the data cannot be preempted and it cannot be migrated
while it manipulates per-CPU variables. If the thread is preempted, the
thread that replaces it could try to work with the same variables; migration
to another CPU could also cause confusion. However there is no preemption
disable when reads host per-CPU tsc rate to calculate the current kvmclock
timestamp.
This patch fixes it by utilizing get_cpu/put_cpu pair to guarantee both
__this_cpu_read() and rdtsc() are not preempted.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
|
|
sscanf is a very poor way to parse integer. For example, I input
"discard" for act_mask, it gets 0xd and completely messes up. Using
correct API to do integer parse.
This patch also makes attributes accept any base of integer.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Commit bd698d24b1b57 ("i2c: designware: Get selected speed mode
sda-hold-time via ACPI") updated the logic that reads the timing
parameters for various I2C bus rates from the DSDT, to only read
the timing parameters for the currently selected mode.
This causes a WARN_ON() splat on platforms that legally omit the clock
frequency from the ACPI description, because in the new situation, the
core I2C designware driver still accesses the fields in the driver
struct that we no longer populate, and proceeds to calculate them from
the clock frequency. Since the clock frequency is unspecified, the
driver complains loudly using a WARN_ON().
So revert back to the old situation, where the struct fields for all
timings are populated, but retain the new logic which chooses the SDA
hold time from the timing mode that is currently in use.
Fixes: bd698d24b1b57 ("i2c: designware: Get selected speed mode ...")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
The way we handle include paths for DT has changed a bit, which
broke a file that had an unconventional way to reference a common
header file:
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts:47:10: fatal error: include/dt-bindings/input/linux-event-codes.h: No such file or directory
This removes the leading "include/" from the path name, which fixes it.
Fixes: d5d332d3f7e8 ("devicetree: Move include prefixes from arch to separate directory")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The bcm_kona_wdt_set_resolution_reg() call takes the spinlock, so
initialize it earlier. Fixes a warning at boot with lock debugging
enabled.
Fixes: 6adb730dc208 ("watchdog: bcm281xx: Watchdog Driver")
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
The ICH9 is listed as having TCO v2, and indeed the behavior in the
datasheet corresponds to v2 (for example the NO_REBOOT flag is
accessible via the 16KiB-aligned Root Complex Base Address).
However, the TCO counts twice just like in v1; the documentation
of the SECOND_TO_STS bit says: "ICH9 sets this bit to 1 to indicate
that the TIMEOUT bit had been (or is currently) set and a second
timeout occurred before the TCO_RLD register was written. If this
bit is set and the NO_REBOOT config bit is 0, then the ICH9 will
reboot the system after the second timeout. The same can be found
in the BayTrail (Atom E3800) datasheet, and even HOWTOs around
the Internet say that it will reboot after _twice_ the specified
heartbeat.
I did not find the Apollo Lake datasheet, but because v4/v5 has
a SECOND_TO_STS bit just like the previous version I'm enabling
this for Apollo Lake as well.
Cc: linux-watchdog@vger.kernel.org
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
gcc-7 notices that the length we pass to strncat is wrong:
drivers/firmware/ti_sci.c: In function 'ti_sci_probe':
drivers/firmware/ti_sci.c:204:32: error: specified bound 50 equals the size of the destination [-Werror=stringop-overflow=]
Instead of the total length, we must pass the length of the
remaining space here.
Fixes: aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
Cc: stable@vger.kernel.org
Acked-by: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
gcc-7 warns about some declarations that are more 'const' than necessary:
arch/arm/mach-at91/pm.c:338:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
static const struct of_device_id const ramc_ids[] __initconst = {
arch/arm/mach-bcm/bcm_kona_smc.c:36:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
static const struct of_device_id const bcm_kona_smc_ids[] __initconst = {
arch/arm/mach-spear/time.c:207:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
static const struct of_device_id const timer_of_match[] __initconst = {
arch/arm/mach-omap2/prm_common.c:714:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
static const struct of_device_id const omap_prcm_dt_match_table[] __initconst = {
arch/arm/mach-omap2/vc.c:562:35: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
static const struct i2c_init_data const omap4_i2c_timing_data[] __initconst = {
The ones in arch/arm were apparently all introduced accidentally by one
commit that correctly marked a lot of variables as __initconst.
Fixes: 19c233b79d1a ("ARM: appropriate __init annotation for const data")
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Krzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Enable Qualcomm drivers needed to boot Dragonboard 410c with HDMI. This
enables support for clocks, regulators, and USB PHY.
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
[Olof: Turned off _RPM configs per follow-up email]
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
Sync the defconfig with savedefconfig as config options change/move over
time.
Generated with the following commands:
make defconfig
make savedefconfig
cp defconfig arch/arm64/configs/defconfig
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
|