summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-10-08drm/i915/tgl: Add DC3CO required register and bitsAnshuman Gupta
Adding following definition to i915_reg.h 1. DC_STATE_EN register DC3CO bit fields and masks. DC3CO enable bit will be used by driver to make DC3CO ready for DMC f/w and status bit will be used as DC3CO entry status. 2. Transcoder EXITLINE register and its bit fields and mask. Transcoder EXITLINE enable bit represents PSR2 idle frame reset should be applied at exit line and exitlines mask represent required number of scanlines at which DC3CO exit happens. B.Specs:49196 v1: Use of REG_BIT and using extra space for EXITLINE_ macro definition. [Animesh] v2: Grouping EXITLINE reg bits with EXITLINE(trans) define, no functional change. [Ville] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007094607.2111-1-anshuman.gupta@intel.com
2019-10-08drm/i915/perf: Set the exclusive stream under perf->lockChris Wilson
The BKL struct_mutex is no more, the only serialisation we required for setting the exclusive stream is already managed by ce->pin_mutex in gen8_configure_all_contexts(). As such, we can manipulate i915_perf.exclusive_stream underneath our own (already held) perf->lock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007140812.10963-2-chris@chris-wilson.co.uk Link: https://patchwork.freedesktop.org/patch/msgid/20191007210942.18145-2-chris@chris-wilson.co.uk
2019-10-08drm/i915/perf: Wean ourselves off dev_privChris Wilson
Use the local uncore accessors for the GT rather than using the [not-so] magic global dev_priv mmio routines. In the process, we also teach the perf stream to use backpointers to the i915_perf rather than digging it out of dev_priv. v2: Rebase onto i915_perf_types.h Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191007140812.10963-1-chris@chris-wilson.co.uk Link: https://patchwork.freedesktop.org/patch/msgid/20191007210942.18145-1-chris@chris-wilson.co.uk
2019-10-08drm/i915: Fix Kconfig indentationKrzysztof Kozlowski
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007173346.9379-1-krzk@kernel.org
2019-10-08drm/sun4i: dsi: Fix video start delay computationJagan Teki
The LCD timing definitions between Linux DRM vs Allwinner are different, below diagram shows this clear differences. Active Front Sync Back Region Porch Porch <-----------------------><----------------><--------------><--------------> //////////////////////| ////////////////////// | ////////////////////// |.................. ................ ________________ <----- [hv]display -----> <------------- [hv]sync_start ------------> <--------------------- [hv]sync_end ----------------------> <-------------------------------- [hv]total ------------------------------> <----- lcd_[xy] --------> <- lcd_[hv]spw -> <---------- lcd_[hv]bp ---------> <-------------------------------- lcd_[hv]t ------------------------------> The DSI driver misinterpreted the vbp term from the BSP code to refer only to the backporch, when in fact it was backporch + sync. Thus the driver incorrectly used the vertical front porch plus sync in its calculation of the DRQ set bit value, when it should not have included the sync timing. Including additional sync timings leads to flip_done timed out as: WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 [CRTC:46:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 Hardware name: Allwinner sun8i Family Workqueue: events deferred_probe_work_func [<c010ed54>] (unwind_backtrace) from [<c010b76c>] (show_stack+0x10/0x14) [<c010b76c>] (show_stack) from [<c0688c70>] (dump_stack+0x84/0x98) [<c0688c70>] (dump_stack) from [<c011d9e4>] (__warn+0xfc/0x114) [<c011d9e4>] (__warn) from [<c011da40>] (warn_slowpath_fmt+0x44/0x68) [<c011da40>] (warn_slowpath_fmt) from [<c040cd50>] (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) [<c040cd50>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c040e694>] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) [<c040e694>] (drm_atomic_helper_commit_tail_rpm) from [<c040e4dc>] (commit_tail+0x40/0x6c) [<c040e4dc>] (commit_tail) from [<c040e5cc>] (drm_atomic_helper_commit+0xbc/0x128) [<c040e5cc>] (drm_atomic_helper_commit) from [<c0411b64>] (restore_fbdev_mode_atomic+0x1cc/0x1dc) [<c0411b64>] (restore_fbdev_mode_atomic) from [<c04156f8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) [<c04156f8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0415774>] (drm_fb_helper_set_par+0x30/0x54) [<c0415774>] (drm_fb_helper_set_par) from [<c03ad450>] (fbcon_init+0x560/0x5ac) [<c03ad450>] (fbcon_init) from [<c03eb8a0>] (visual_init+0xbc/0x104) [<c03eb8a0>] (visual_init) from [<c03ed1b8>] (do_bind_con_driver+0x1b0/0x390) [<c03ed1b8>] (do_bind_con_driver) from [<c03ed780>] (do_take_over_console+0x13c/0x1c4) [<c03ed780>] (do_take_over_console) from [<c03ad800>] (do_fbcon_takeover+0x74/0xcc) [<c03ad800>] (do_fbcon_takeover) from [<c013c9c8>] (notifier_call_chain+0x44/0x84) [<c013c9c8>] (notifier_call_chain) from [<c013cd20>] (__blocking_notifier_call_chain+0x48/0x60) [<c013cd20>] (__blocking_notifier_call_chain) from [<c013cd50>] (blocking_notifier_call_chain+0x18/0x20) [<c013cd50>] (blocking_notifier_call_chain) from [<c03a6e44>] (register_framebuffer+0x1e0/0x2f8) [<c03a6e44>] (register_framebuffer) from [<c04153c0>] (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) [<c04153c0>] (__drm_fb_helper_initial_config_and_unlock) from [<c04158c8>] (drm_fbdev_client_hotplug+0xe8/0x1b8) [<c04158c8>] (drm_fbdev_client_hotplug) from [<c0415a20>] (drm_fbdev_generic_setup+0x88/0x118) [<c0415a20>] (drm_fbdev_generic_setup) from [<c043f060>] (sun4i_drv_bind+0x128/0x160) [<c043f060>] (sun4i_drv_bind) from [<c044b598>] (try_to_bring_up_master+0x164/0x1a0) [<c044b598>] (try_to_bring_up_master) from [<c044b668>] (__component_add+0x94/0x140) [<c044b668>] (__component_add) from [<c0445e1c>] (sun6i_dsi_probe+0x144/0x234) [<c0445e1c>] (sun6i_dsi_probe) from [<c0452ef4>] (platform_drv_probe+0x48/0x9c) [<c0452ef4>] (platform_drv_probe) from [<c04512cc>] (really_probe+0x1dc/0x2c8) [<c04512cc>] (really_probe) from [<c0451518>] (driver_probe_device+0x60/0x160) [<c0451518>] (driver_probe_device) from [<c044f7a4>] (bus_for_each_drv+0x74/0xb8) [<c044f7a4>] (bus_for_each_drv) from [<c045107c>] (__device_attach+0xd0/0x13c) [<c045107c>] (__device_attach) from [<c0450474>] (bus_probe_device+0x84/0x8c) [<c0450474>] (bus_probe_device) from [<c0450900>] (deferred_probe_work_func+0x64/0x90) [<c0450900>] (deferred_probe_work_func) from [<c0135970>] (process_one_work+0x204/0x420) [<c0135970>] (process_one_work) from [<c013690c>] (worker_thread+0x274/0x5a0) [<c013690c>] (worker_thread) from [<c013b3d8>] (kthread+0x11c/0x14c) [<c013b3d8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) Exception stack(0xde539fb0 to 0xde539ff8) 9fa0: 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---[ end trace 495200a78b24980e ]--- random: fast init done [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] flip_done timed out With the terms(as described in above diagram) fixed, the panel displays correctly without any timeouts. Tested-by: Merlijn Wajer <merlijn@wizzup.org> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191006160303.24413-2-icenowy@aosc.io
2019-10-08Merge tag 'drm-intel-next-2019-10-07' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - Never allow userptr into the mappable GGTT (Chris) No existing users. Avoid anyone from even trying to spare a deadlock scenario. Cross-subsystem Changes: Core Changes: Driver Changes: - Eliminate struct_mutex use as BKL! (Chris) Only used for execbuf serialisation. - Initialize DDI TC and TBT ports (D-I) on Tigerlake (Lucas) - Fix DKL link training for 2.7GHz and 1.62GHz (Jose) - Add Tigerlake DKL PHY programming sequences (Clinton) - Add Tigerlake Thunderbolt PLL divider values (Imre) - drm/i915: Use helpers for drm_mm_node booleans (Chris) - Restrict L3 remapping sysfs interface to dwords (Chris) - Fix audio power up sequence for gen10+ display (Kai) - Skip redundant execlist resubmission (Chris) - Only unwedge if we can reset GPU first (Chris) - Initialise breadcrumb lists on the virtual engine (Chris) - Don't rely on kernel context existing during early errors (Matt A) - Update Icelake+ MG_DP_MODE programming table (Clinton) - Update DMC firmware for Icelake (Anusha) - Downgrade DP MST error after unplugging TypeC cable (Srinivasan) - Limit MST modes based on plane size too (Ville) - Polish intel_tv_mode_valid() (Ville) - Fix g4x sprite scaling stride check with GTT remapping (Ville) - Don't advertize non-exisiting crtcs (Ville) - Clean up encoder->crtc_mask setup (Ville) - Use tc_port instead of port parameter to MG registers (Jose) - Remove static variable for aux last status (Jani) - Implement a better i945gm vblank irq vs. C-states workaround (Ville) - Make the object creation interface consistent (CQ) - Rename intel_vga_msr_write() to intel_vga_reset_io_mem() (Jani, Ville) - Eliminate previous drm_dbg/drm_err usage (Jani) - Move gmbus setup down to intel_modeset_init() (Jani) - Abstract all vgaarb access to intel_vga.[ch] (Jani) - Split out i915_switcheroo.[ch] from i915_drv.c (Jani) - Use intel_gt in has_reset* (Chris) - Eliminate return value for i915_gem_init_early (Matt A) - Selftest improvements (Chris) - Update HuC firmware header version number format (Daniele) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007134801.GA24313@jlahtine-desk.ger.corp.intel.com
2019-10-07drm/i915/gt: Treat a busy timeline as 'active' while waitingChris Wilson
If we cannot claim the timeline->mutex while preparing for a wait on it, we have to skip the timeline. In doing so, treat it as active so that under a intel_gt_wait_for_idle() loop, we repeat the wait after scheduling away. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191006165002.30312-4-chris@chris-wilson.co.uk
2019-10-07drm/i915/selftests: Appease lockdepChris Wilson
Disable irqs around updating the context image to keep lockdep happy: <4>[ 673.483340] WARNING: possible irq lock inversion dependency detected <4>[ 673.483342] 5.4.0-rc1-CI-Trybot_5118+ #1 Tainted: G U <4>[ 673.483342] -------------------------------------------------------- <4>[ 673.483343] swapper/2/0 just changed the state of lock: <4>[ 673.483344] ffff88845db885a0 (&i915_request_get(rq)->submit/1){-...}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.483387] but this lock took another, HARDIRQ-unsafe lock in the past: <4>[ 673.483388] (&ce->pin_mutex/2){+...} <4>[ 673.483389] and interrupts could create inverse lock ordering between them. <4>[ 673.483390] other info that might help us debug this: <4>[ 673.483390] Chain exists of: &i915_request_get(rq)->submit/1 --> &engine->active.lock --> &ce->pin_mutex/2 <4>[ 673.483392] Possible interrupt unsafe locking scenario: <4>[ 673.483392] CPU0 CPU1 <4>[ 673.483393] ---- ---- <4>[ 673.483393] lock(&ce->pin_mutex/2); <4>[ 673.483394] local_irq_disable(); <4>[ 673.483395] lock(&i915_request_get(rq)->submit/1); <4>[ 673.483396] lock(&engine->active.lock); <4>[ 673.483396] <Interrupt> <4>[ 673.483397] lock(&i915_request_get(rq)->submit/1); <4>[ 673.483398] *** DEADLOCK *** <4>[ 673.483398] 2 locks held by swapper/2/0: <4>[ 673.483399] #0: ffff8883f61ac9b0 (&(&gt->irq_lock)->rlock){-.-.}, at: gen11_gt_irq_handler+0x42/0x280 [i915] <4>[ 673.483433] #1: ffff88845db8c418 (&(&rq->lock)->rlock){-.-.}, at: intel_engine_breadcrumbs_irq+0x34a/0x5a0 [i915] <4>[ 673.483463] the shortest dependencies between 2nd lock and 1st lock: <4>[ 673.483466] -> (&ce->pin_mutex/2){+...} ops: 614520 { <4>[ 673.483468] HARDIRQ-ON-W at: <4>[ 673.483471] lock_acquire+0xa7/0x1c0 <4>[ 673.483501] live_unlite_restore+0x1d8/0x6c0 [i915] <4>[ 673.483543] __i915_subtests+0xb8/0x210 [i915] <4>[ 673.483581] __run_selftests+0x112/0x170 [i915] <4>[ 673.483615] i915_live_selftests+0x2c/0x60 [i915] <4>[ 673.483644] i915_pci_probe+0x93/0x1b0 [i915] <4>[ 673.483646] pci_device_probe+0x9e/0x120 <4>[ 673.483648] really_probe+0xea/0x420 <4>[ 673.483649] driver_probe_device+0x10b/0x120 <4>[ 673.483651] device_driver_attach+0x4a/0x50 <4>[ 673.483652] __driver_attach+0x97/0x130 <4>[ 673.483653] bus_for_each_dev+0x74/0xc0 <4>[ 673.483654] bus_add_driver+0x142/0x220 <4>[ 673.483655] driver_register+0x56/0xf0 <4>[ 673.483657] do_one_initcall+0x58/0x2ff <4>[ 673.483659] do_init_module+0x56/0x1f8 <4>[ 673.483660] load_module+0x243e/0x29f0 <4>[ 673.483661] __do_sys_finit_module+0xe9/0x110 <4>[ 673.483662] do_syscall_64+0x4f/0x210 <4>[ 673.483665] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.483665] INITIAL USE at: <4>[ 673.483667] lock_acquire+0xa7/0x1c0 <4>[ 673.483698] live_unlite_restore+0x1d8/0x6c0 [i915] <4>[ 673.483733] __i915_subtests+0xb8/0x210 [i915] <4>[ 673.483764] __run_selftests+0x112/0x170 [i915] <4>[ 673.483793] i915_live_selftests+0x2c/0x60 [i915] <4>[ 673.483821] i915_pci_probe+0x93/0x1b0 [i915] <4>[ 673.483822] pci_device_probe+0x9e/0x120 <4>[ 673.483824] really_probe+0xea/0x420 <4>[ 673.483825] driver_probe_device+0x10b/0x120 <4>[ 673.483826] device_driver_attach+0x4a/0x50 <4>[ 673.483827] __driver_attach+0x97/0x130 <4>[ 673.483828] bus_for_each_dev+0x74/0xc0 <4>[ 673.483829] bus_add_driver+0x142/0x220 <4>[ 673.483830] driver_register+0x56/0xf0 <4>[ 673.483831] do_one_initcall+0x58/0x2ff <4>[ 673.483833] do_init_module+0x56/0x1f8 <4>[ 673.483834] load_module+0x243e/0x29f0 <4>[ 673.483835] __do_sys_finit_module+0xe9/0x110 <4>[ 673.483836] do_syscall_64+0x4f/0x210 <4>[ 673.483837] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.483838] } <4>[ 673.483868] ... key at: [<ffffffffa0a8f132>] __key.70113+0x2/0xffffffffffef2ed0 [i915] <4>[ 673.483869] ... acquired at: <4>[ 673.483935] __execlists_reset+0xfb/0xc20 [i915] <4>[ 673.483965] execlists_reset+0x3d/0x50 [i915] <4>[ 673.483995] intel_engine_reset+0xdf/0x230 [i915] <4>[ 673.484022] live_preempt_hang+0x1d7/0x2e0 [i915] <4>[ 673.484064] __i915_subtests+0xb8/0x210 [i915] <4>[ 673.484130] __run_selftests+0x112/0x170 [i915] <4>[ 673.484163] i915_live_selftests+0x2c/0x60 [i915] <4>[ 673.484193] i915_pci_probe+0x93/0x1b0 [i915] <4>[ 673.484194] pci_device_probe+0x9e/0x120 <4>[ 673.484195] really_probe+0xea/0x420 <4>[ 673.484196] driver_probe_device+0x10b/0x120 <4>[ 673.484197] device_driver_attach+0x4a/0x50 <4>[ 673.484198] __driver_attach+0x97/0x130 <4>[ 673.484199] bus_for_each_dev+0x74/0xc0 <4>[ 673.484200] bus_add_driver+0x142/0x220 <4>[ 673.484202] driver_register+0x56/0xf0 <4>[ 673.484203] do_one_initcall+0x58/0x2ff <4>[ 673.484204] do_init_module+0x56/0x1f8 <4>[ 673.484205] load_module+0x243e/0x29f0 <4>[ 673.484206] __do_sys_finit_module+0xe9/0x110 <4>[ 673.484207] do_syscall_64+0x4f/0x210 <4>[ 673.484208] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.484209] -> (&engine->active.lock){..-.} ops: 972791 { <4>[ 673.484211] IN-SOFTIRQ-W at: <4>[ 673.484213] lock_acquire+0xa7/0x1c0 <4>[ 673.484214] _raw_spin_lock_irqsave+0x33/0x50 <4>[ 673.484244] execlists_submission_tasklet+0xaf/0x100 [i915] <4>[ 673.484246] tasklet_action_common.isra.18+0x6c/0x1c0 <4>[ 673.484247] __do_softirq+0xdf/0x47f <4>[ 673.484248] irq_exit+0xba/0xc0 <4>[ 673.484249] do_IRQ+0x83/0x160 <4>[ 673.484250] ret_from_intr+0x0/0x1d <4>[ 673.484252] cpuidle_enter_state+0xb2/0x450 <4>[ 673.484253] cpuidle_enter+0x24/0x40 <4>[ 673.484254] do_idle+0x1e7/0x250 <4>[ 673.484256] cpu_startup_entry+0x14/0x20 <4>[ 673.484257] start_secondary+0x15f/0x1b0 <4>[ 673.484258] secondary_startup_64+0xa4/0xb0 <4>[ 673.484259] INITIAL USE at: <4>[ 673.484261] lock_acquire+0xa7/0x1c0 <4>[ 673.484290] intel_engine_init_active+0x7e/0xb0 [i915] <4>[ 673.484305] intel_engines_setup+0x1cd/0x3b0 [i915] <4>[ 673.484305] i915_gem_init+0x12d/0x900 [i915] <4>[ 673.484305] i915_driver_probe+0xb70/0x15d0 [i915] <4>[ 673.484305] i915_pci_probe+0x43/0x1b0 [i915] <4>[ 673.484305] pci_device_probe+0x9e/0x120 <4>[ 673.484305] really_probe+0xea/0x420 <4>[ 673.484305] driver_probe_device+0x10b/0x120 <4>[ 673.484305] device_driver_attach+0x4a/0x50 <4>[ 673.484305] __driver_attach+0x97/0x130 <4>[ 673.484305] bus_for_each_dev+0x74/0xc0 <4>[ 673.484305] bus_add_driver+0x142/0x220 <4>[ 673.484305] driver_register+0x56/0xf0 <4>[ 673.484305] do_one_initcall+0x58/0x2ff <4>[ 673.484305] do_init_module+0x56/0x1f8 <4>[ 673.484305] load_module+0x243e/0x29f0 <4>[ 673.484305] __do_sys_finit_module+0xe9/0x110 <4>[ 673.484305] do_syscall_64+0x4f/0x210 <4>[ 673.484305] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.484305] } <4>[ 673.484305] ... key at: [<ffffffffa0a8f160>] __key.70307+0x0/0xffffffffffef2ea0 [i915] <4>[ 673.484305] ... acquired at: <4>[ 673.484305] _raw_spin_lock_irqsave+0x33/0x50 <4>[ 673.484305] execlists_submit_request+0x2b/0x1e0 [i915] <4>[ 673.484305] submit_notify+0xa8/0x13c [i915] <4>[ 673.484305] __i915_sw_fence_complete+0x81/0x250 [i915] <4>[ 673.484305] i915_sw_fence_wake+0x51/0x70 [i915] <4>[ 673.484305] __i915_sw_fence_complete+0x1ee/0x250 [i915] <4>[ 673.484305] dma_i915_sw_fence_wake+0x1b/0x30 [i915] <4>[ 673.484305] dma_fence_signal_locked+0x9e/0x1b0 <4>[ 673.484305] dma_fence_signal+0x1f/0x40 <4>[ 673.484305] fence_work+0x28/0x80 [i915] <4>[ 673.484305] process_one_work+0x26a/0x620 <4>[ 673.484305] worker_thread+0x37/0x380 <4>[ 673.484305] kthread+0x119/0x130 <4>[ 673.484305] ret_from_fork+0x24/0x50 <4>[ 673.484305] -> (&i915_request_get(rq)->submit/1){-...} ops: 857694 { <4>[ 673.484305] IN-HARDIRQ-W at: <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915] <4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915] <4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70 <4>[ 673.484305] handle_irq_event+0x2f/0x50 <4>[ 673.484305] handle_edge_irq+0x99/0x1b0 <4>[ 673.484305] do_IRQ+0x7e/0x160 <4>[ 673.484305] ret_from_intr+0x0/0x1d <4>[ 673.484305] cpuidle_enter_state+0xb2/0x450 <4>[ 673.484305] cpuidle_enter+0x24/0x40 <4>[ 673.484305] do_idle+0x1e7/0x250 <4>[ 673.484305] cpu_startup_entry+0x14/0x20 <4>[ 673.484305] start_secondary+0x15f/0x1b0 <4>[ 673.484305] secondary_startup_64+0xa4/0xb0 <4>[ 673.484305] INITIAL USE at: <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] __engine_park+0x233/0x420 [i915] <4>[ 673.484305] ____intel_wakeref_put_last+0x1c/0x70 [i915] <4>[ 673.484305] intel_gt_resume+0x202/0x2c0 [i915] <4>[ 673.484305] i915_gem_init+0x36e/0x900 [i915] <4>[ 673.484305] i915_driver_probe+0xb70/0x15d0 [i915] <4>[ 673.484305] i915_pci_probe+0x43/0x1b0 [i915] <4>[ 673.484305] pci_device_probe+0x9e/0x120 <4>[ 673.484305] really_probe+0xea/0x420 <4>[ 673.484305] driver_probe_device+0x10b/0x120 <4>[ 673.484305] device_driver_attach+0x4a/0x50 <4>[ 673.484305] __driver_attach+0x97/0x130 <4>[ 673.484305] bus_for_each_dev+0x74/0xc0 <4>[ 673.484305] bus_add_driver+0x142/0x220 <4>[ 673.484305] driver_register+0x56/0xf0 <4>[ 673.484305] do_one_initcall+0x58/0x2ff <4>[ 673.484305] do_init_module+0x56/0x1f8 <4>[ 673.484305] load_module+0x243e/0x29f0 <4>[ 673.484305] __do_sys_finit_module+0xe9/0x110 <4>[ 673.484305] do_syscall_64+0x4f/0x210 <4>[ 673.484305] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.484305] } <4>[ 673.484305] ... key at: [<ffffffffa0a8f6a1>] __key.80173+0x1/0xffffffffffef2960 [i915] <4>[ 673.484305] ... acquired at: <4>[ 673.484305] mark_lock+0x382/0x500 <4>[ 673.484305] __lock_acquire+0x7e1/0x15d0 <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915] <4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915] <4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70 <4>[ 673.484305] handle_irq_event+0x2f/0x50 <4>[ 673.484305] handle_edge_irq+0x99/0x1b0 <4>[ 673.484305] do_IRQ+0x7e/0x160 <4>[ 673.484305] ret_from_intr+0x0/0x1d <4>[ 673.484305] cpuidle_enter_state+0xb2/0x450 <4>[ 673.484305] cpuidle_enter+0x24/0x40 <4>[ 673.484305] do_idle+0x1e7/0x250 <4>[ 673.484305] cpu_startup_entry+0x14/0x20 <4>[ 673.484305] start_secondary+0x15f/0x1b0 <4>[ 673.484305] secondary_startup_64+0xa4/0xb0 <4>[ 673.484305] stack backtrace: <4>[ 673.484305] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G U 5.4.0-rc1-CI-Trybot_5118+ #1 <4>[ 673.484305] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411 05/02/2019 <4>[ 673.484305] Call Trace: <4>[ 673.484305] <IRQ> <4>[ 673.484305] dump_stack+0x67/0x9b <4>[ 673.484305] check_usage_forwards+0x13c/0x150 <4>[ 673.484305] ? mark_lock+0x382/0x500 <4>[ 673.484305] mark_lock+0x382/0x500 <4>[ 673.484305] ? check_usage_backwards+0x140/0x140 <4>[ 673.484305] __lock_acquire+0x7e1/0x15d0 <4>[ 673.484305] ? debug_object_deactivate+0x17e/0x190 <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] ? __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] ? __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915] <4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915] <4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70 <4>[ 673.484305] handle_irq_event+0x2f/0x50 <4>[ 673.484305] handle_edge_irq+0x99/0x1b0 <4>[ 673.484305] do_IRQ+0x7e/0x160 <4>[ 673.484305] common_interrupt+0xf/0xf <4>[ 673.484305] </IRQ> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004203121.31138-1-chris@chris-wilson.co.uk
2019-10-07drm/i915/execlists: Fix annotation for decoupling virtual requestChris Wilson
As we may signal a request and take the engine->active.lock within the signaler, the engine submission paths have to use a nested annotation on their requests -- but we guarantee that we can never submit on the same engine as the signaling fence. <4>[ 723.763281] WARNING: possible circular locking dependency detected <4>[ 723.763285] 5.3.0-g80fa0e042cdb-drmtip_379+ #1 Tainted: G U <4>[ 723.763288] ------------------------------------------------------ <4>[ 723.763291] gem_exec_await/1388 is trying to acquire lock: <4>[ 723.763294] ffff93a7b53221d8 (&engine->active.lock){..-.}, at: execlists_submit_request+0x2b/0x1e0 [i915] <4>[ 723.763378] but task is already holding lock: <4>[ 723.763381] ffff93a7c25f6d20 (&i915_request_get(rq)->submit/1){-.-.}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 723.763420] which lock already depends on the new lock. <4>[ 723.763423] the existing dependency chain (in reverse order) is: <4>[ 723.763427] -> #2 (&i915_request_get(rq)->submit/1){-.-.}: <4>[ 723.763434] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 723.763478] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 723.763513] intel_engine_breadcrumbs_irq+0x3aa/0x5e0 [i915] <4>[ 723.763600] cs_irq_handler+0x49/0x50 [i915] <4>[ 723.763659] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 723.763690] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 723.763695] __handle_irq_event_percpu+0x41/0x2d0 <4>[ 723.763699] handle_irq_event_percpu+0x2b/0x70 <4>[ 723.763702] handle_irq_event+0x2f/0x50 <4>[ 723.763706] handle_edge_irq+0xee/0x1a0 <4>[ 723.763709] do_IRQ+0x7e/0x160 <4>[ 723.763712] ret_from_intr+0x0/0x1d <4>[ 723.763717] __slab_alloc.isra.28.constprop.33+0x4f/0x70 <4>[ 723.763720] kmem_cache_alloc+0x28d/0x2f0 <4>[ 723.763724] vm_area_dup+0x15/0x40 <4>[ 723.763727] dup_mm+0x2dd/0x550 <4>[ 723.763730] copy_process+0xf21/0x1ef0 <4>[ 723.763734] _do_fork+0x71/0x670 <4>[ 723.763737] __se_sys_clone+0x6e/0xa0 <4>[ 723.763741] do_syscall_64+0x4f/0x210 <4>[ 723.763744] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 723.763747] -> #1 (&(&rq->lock)->rlock#2){-.-.}: <4>[ 723.763752] _raw_spin_lock+0x2a/0x40 <4>[ 723.763789] __unwind_incomplete_requests+0x3eb/0x450 [i915] <4>[ 723.763825] __execlists_submission_tasklet+0x9ec/0x1d60 [i915] <4>[ 723.763864] execlists_submission_tasklet+0x34/0x50 [i915] <4>[ 723.763874] tasklet_action_common.isra.5+0x47/0xb0 <4>[ 723.763878] __do_softirq+0xd8/0x4ae <4>[ 723.763881] irq_exit+0xa9/0xc0 <4>[ 723.763883] smp_apic_timer_interrupt+0xb7/0x280 <4>[ 723.763887] apic_timer_interrupt+0xf/0x20 <4>[ 723.763892] cpuidle_enter_state+0xae/0x450 <4>[ 723.763895] cpuidle_enter+0x24/0x40 <4>[ 723.763899] do_idle+0x1e7/0x250 <4>[ 723.763902] cpu_startup_entry+0x14/0x20 <4>[ 723.763905] start_secondary+0x15f/0x1b0 <4>[ 723.763908] secondary_startup_64+0xa4/0xb0 <4>[ 723.763911] -> #0 (&engine->active.lock){..-.}: <4>[ 723.763916] __lock_acquire+0x15d8/0x1ea0 <4>[ 723.763919] lock_acquire+0xa6/0x1c0 <4>[ 723.763922] _raw_spin_lock_irqsave+0x33/0x50 <4>[ 723.763956] execlists_submit_request+0x2b/0x1e0 [i915] <4>[ 723.764002] submit_notify+0xa8/0x13c [i915] <4>[ 723.764035] __i915_sw_fence_complete+0x81/0x250 [i915] <4>[ 723.764054] i915_sw_fence_wake+0x51/0x64 [i915] <4>[ 723.764054] __i915_sw_fence_complete+0x1ee/0x250 [i915] <4>[ 723.764054] dma_i915_sw_fence_wake_timer+0x14/0x20 [i915] <4>[ 723.764054] dma_fence_signal_locked+0x9e/0x1c0 <4>[ 723.764054] dma_fence_signal+0x1f/0x40 <4>[ 723.764054] vgem_fence_signal_ioctl+0x67/0xc0 [vgem] <4>[ 723.764054] drm_ioctl_kernel+0x83/0xf0 <4>[ 723.764054] drm_ioctl+0x2f3/0x3b0 <4>[ 723.764054] do_vfs_ioctl+0xa0/0x6f0 <4>[ 723.764054] ksys_ioctl+0x35/0x60 <4>[ 723.764054] __x64_sys_ioctl+0x11/0x20 <4>[ 723.764054] do_syscall_64+0x4f/0x210 <4>[ 723.764054] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 723.764054] other info that might help us debug this: <4>[ 723.764054] Chain exists of: &engine->active.lock --> &(&rq->lock)->rlock#2 --> &i915_request_get(rq)->submit/1 <4>[ 723.764054] Possible unsafe locking scenario: <4>[ 723.764054] CPU0 CPU1 <4>[ 723.764054] ---- ---- <4>[ 723.764054] lock(&i915_request_get(rq)->submit/1); <4>[ 723.764054] lock(&(&rq->lock)->rlock#2); <4>[ 723.764054] lock(&i915_request_get(rq)->submit/1); <4>[ 723.764054] lock(&engine->active.lock); <4>[ 723.764054] *** DEADLOCK *** Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111862 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004194758.19679-1-chris@chris-wilson.co.uk
2019-10-07drm/i915/gt: Prefer local path to runtime powermanagementChris Wilson
Avoid going to the base i915 device when we already have a path from gt to the runtime powermanagement interface. The benefit is that it looks a bit more self-consistent to always be acquiring the gt->uncore->rpm for use with the gt->uncore. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007154531.1750-1-chris@chris-wilson.co.uk
2019-10-07drm/i915: make array hw_engine_mask static, makes object smallerColin Ian King
Don't populate the array hw_engine_mask on the stack but instead make it static. Makes the object code smaller by 316 bytes. Before: text data bss dec hex filename 34004 4388 320 38712 9738 gpu/drm/i915/gt/intel_reset.o After: text data bss dec hex filename 33528 4548 320 38396 95fc gpu/drm/i915/gt/intel_reset.o (gcc version 9.2.1, amd64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191007154151.23245-1-colin.king@canonical.com
2019-10-07drm/tilcdc: plane: Make structure tilcdc_plane_funcs constantNishka Dasgupta
The static structure tilcdc_plane_funcs, of type drm_plane_funcs, is used only when passed the fourth argument to drm_plane_init(); however, this fourth parameter is declared as const in the function definition. Hence make tilcdc_plane_funcs constant as well. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190813090503.9063-1-nishkadg.linux@gmail.com
2019-10-07drm/i915/vbt: Child device size remains unchanged through VBT 229Matt Roper
The latest documented version of the VBT is 229, but no further data has been added to the child device definition in block 2. Update the child device version test to eliminate the "Expected child device config size for VBT version XXX not known; assuming 39" debug messages from the logs. Bspec: 20124 Bspec: 20157 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002192258.1013-1-matthew.d.roper@intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2019-10-07drm/i915/perf: move perf types to their own headerLionel Landwerlin
Following a pattern used throughout the driver. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190909093116.7747-7-lionel.g.landwerlin@intel.com
2019-10-07drm/i915/gt: Restore dropped 'interruptible' flagChris Wilson
Lost in the rebasing was Tvrtko's reminder that we need to keep an uninterruptible wait around for the Ironlake VT-d w/a Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191006165002.30312-3-chris@chris-wilson.co.uk
2019-10-07drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controllerMatthias Kaehlcke
The DDC/CI protocol involves sending a multi-byte request to the display via I2C, which is typically followed by a multi-byte response. The internal I2C controller only allows single byte reads/writes or reads of 8 sequential bytes, hence DDC/CI is not supported when the internal I2C controller is used. The I2C transfers complete without errors, however the data in the response is garbage. Abort transfers to/from slave address 0x37 (DDC) with -EOPNOTSUPP, to make it evident that the communication is failing. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002124354.v2.1.I709dfec496f5f0b44a7b61dcd4937924da8d8382@changeid
2019-10-07drm/i915: Update DRIVER_DATE to 20191007Joonas Lahtinen
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-10-07drm/sun4i: sun6i_mipi_dsi: fix DCS long write packet lengthIcenowy Zheng
The packet length of DCS long write packet should not be added with 1 when constructing long write packet. Fix this. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191006160303.24413-4-icenowy@aosc.io
2019-10-07drm/sun4i: dsi: fix the overhead of the horizontal front porchIcenowy Zheng
The formula in the BSP kernel indicates that a 16-byte overhead is used when sending the HFP. However, this value is currently set to 6 in the sun6i_mipi_dsi driver, which makes some panels flashing. Fix this overhead value. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191006160303.24413-3-icenowy@aosc.io
2019-10-07cec: add cec_adapter to cec_notifier_cec_adap_unregister()Hans Verkuil
It is possible for one HDMI connector to have multiple CEC adapters. The typical real-world scenario is that where one adapter is used when the device is in standby, and one that's better/smarter when the device is powered up. The cec-notifier changes were made with that in mind, but I missed that in order to support this you need to tell cec_notifier_cec_adap_unregister() which adapter you are unregistering from the notifier. Add this additional argument. It is currently unused, but once all drivers use this, the CEC core will be adapted for these use-cases. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/e9fc8740-6be6-43a7-beee-ce2d7b54936e@xs4all.nl
2019-10-06Linux 5.4-rc2Linus Torvalds
2019-10-06elf: don't use MAP_FIXED_NOREPLACE for elf executable mappingsLinus Torvalds
In commit 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") we changed elf to use MAP_FIXED_NOREPLACE instead of MAP_FIXED for the executable mappings. Then, people reported that it broke some binaries that had overlapping segments from the same file, and commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments") re-instated MAP_FIXED for some overlaying elf segment cases. But only some - despite the summary line of that commit, it only did it when it also does a temporary brk vma for one obvious overlapping case. Now Russell King reports another overlapping case with old 32-bit x86 binaries, which doesn't trigger that limited case. End result: we had better just drop MAP_FIXED_NOREPLACE entirely, and go back to MAP_FIXED. Yes, it's a sign of old binaries generated with old tool-chains, but we do pride ourselves on not breaking existing setups. This still leaves MAP_FIXED_NOREPLACE in place for the load_elf_interp() and the old load_elf_library() use-cases, because nobody has reported breakage for those. Yet. Note that in all the cases seen so far, the overlapping elf sections seem to be just re-mapping of the same executable with different section attributes. We could possibly introduce a new MAP_FIXED_NOFILECHANGE flag or similar, which acts like NOREPLACE, but allows just remapping the same executable file using different protection flags. It's not clear that would make a huge difference to anything, but if people really hate that "elf remaps over previous maps" behavior, maybe at least a more limited form of remapping would alleviate some concerns. Alternatively, we should take a look at our elf_map() logic to see if we end up not mapping things properly the first time. In the meantime, this is the minimal "don't do that then" patch while people hopefully think about it more. Reported-by: Russell King <linux@armlinux.org.uk> Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") Fixes: ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments") Cc: Michal Hocko <mhocko@suse.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-06Merge tag 'dma-mapping-5.4-1' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds
Pull dma-mapping regression fix from Christoph Hellwig: "Revert an incorret hunk from a patch that caused problems on various arm boards (Andrey Smirnov)" * tag 'dma-mapping-5.4-1' of git://git.infradead.org/users/hch/dma-mapping: dma-mapping: fix false positive warnings in dma_common_free_remap()
2019-10-06drm/i915: move gmbus setup down to intel_modeset_init()Jani Nikula
Pair the gmbus setup and teardown in the same layer. This also fixes the double gmbus teardown on the i915_driver_modeset_probe() error path. Move the gmbus setup a bit later in the sequence to make the follow-up refactoring easier, and to pinpoint any unexpected consequences of this change right here, instead of the later refactoring. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004122019.12009-3-jani.nikula@intel.com
2019-10-06drm/i915: split out i915_switcheroo.[ch] from i915_drv.cJani Nikula
Split out code related to vga switcheroo register/unregister and state handling from i915_drv.c into new i915_switcheroo.[ch] files. It's a bit difficult to draw the line how much to move to the new file from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo() and i915_resume_switcheroo() in place was the cleanest. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004122019.12009-2-jani.nikula@intel.com
2019-10-06drm/i915/vga: rename intel_vga_msr_write() to intel_vga_reset_io_mem()Jani Nikula
Rename the function per Ville's suggestion. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004122019.12009-1-jani.nikula@intel.com
2019-10-05Merge tag 'armsoc-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Olof Johansson: "A few fixes this time around: - Fixup of some clock specifications for DRA7 (device-tree fix) - Removal of some dead/legacy CPU OPP/PM code for OMAP that throws warnings at boot - A few more minor fixups for OMAPs, most around display - Enable STM32 QSPI as =y since their rootfs sometimes comes from there - Switch CONFIG_REMOTEPROC to =y since it went from tristate to bool - Fix of thermal zone definition for ux500 (5.4 regression)" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI support ARM: dts: ux500: Fix up the CPU thermal zone arm64/ARM: configs: Change CONFIG_REMOTEPROC from m to y ARM: dts: am4372: Set memory bandwidth limit for DISPC ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage() ARM: OMAP2+: Add missing LCDC midlemode for am335x ARM: OMAP2+: Fix missing reset done flag for am3 and am43 ARM: dts: Fix gpio0 flags for am335x-icev2 ARM: omap2plus_defconfig: Enable more droid4 devices as loadable modules ARM: omap2plus_defconfig: Enable DRM_TI_TFP410 DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again ARM: dts: Fix wrong clocks for dra7 mcasp clk: ti: dra7: Fix mcasp8 clock bits
2019-10-05Merge tag 'kbuild-fixes-v5.4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - remove unneeded ar-option and KBUILD_ARFLAGS - remove long-deprecated SUBDIRS - fix modpost to suppress false-positive warnings for UML builds - fix namespace.pl to handle relative paths to ${objtree}, ${srctree} - make setlocalversion work for /bin/sh - make header archive reproducible - fix some Makefiles and documents * tag 'kbuild-fixes-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kheaders: make headers archive reproducible kbuild: update compile-test header list for v5.4-rc2 kbuild: two minor updates for Documentation/kbuild/modules.rst scripts/setlocalversion: clear local variable to make it work for sh namespace: fix namespace.pl script to support relative paths video/logo: do not generate unneeded logo C files video/logo: remove unneeded *.o pattern from clean-files integrity: remove pointless subdir-$(CONFIG_...) integrity: remove unneeded, broken attempt to add -fshort-wchar modpost: fix static EXPORT_SYMBOL warnings for UML build kbuild: correct formatting of header in kbuild module docs kbuild: remove SUBDIRS support kbuild: remove ar-option and KBUILD_ARFLAGS
2019-10-05Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Twelve patches mostly small but obvious fixes or cosmetic but small updates" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: qla2xxx: Fix Nport ID display value scsi: qla2xxx: Fix N2N link up fail scsi: qla2xxx: Fix N2N link reset scsi: qla2xxx: Optimize NPIV tear down process scsi: qla2xxx: Fix stale mem access on driver unload scsi: qla2xxx: Fix unbound sleep in fcport delete path. scsi: qla2xxx: Silence fwdump template message scsi: hisi_sas: Make three functions static scsi: megaraid: disable device when probe failed after enabled device scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue scsi: qedf: Remove always false 'tmp_prio < 0' statement scsi: ufs: skip shutdown if hba is not powered scsi: bnx2fc: Handle scope bits when array returns BUSY or TSF
2019-10-05Merge branch 'readdir' (readdir speedup and sanity checking)Linus Torvalds
This makes getdents() and getdents64() do sanity checking on the pathname that it gives to user space. And to mitigate the performance impact of that, it first cleans up the way it does the user copying, so that the code avoids doing the SMAP/PAN updates between each part of the dirent structure write. I really wanted to do this during the merge window, but didn't have time. The conversion of filldir to unsafe_put_user() is something I've had around for years now in a private branch, but the extra pathname checking finally made me clean it up to the point where it is mergable. It's worth noting that the filename validity checking really should be a bit smarter: it would be much better to delay the error reporting until the end of the readdir, so that non-corrupted filenames are still returned. But that involves bigger changes, so let's see if anybody actually hits the corrupt directory entry case before worrying about it further. * branch 'readdir': Make filldir[64]() verify the directory entry filename is valid Convert filldir[64]() from __put_user() to unsafe_put_user()
2019-10-05Make filldir[64]() verify the directory entry filename is validLinus Torvalds
This has been discussed several times, and now filesystem people are talking about doing it individually at the filesystem layer, so head that off at the pass and just do it in getdents{64}(). This is partially based on a patch by Jann Horn, but checks for NUL bytes as well, and somewhat simplified. There's also commentary about how it might be better if invalid names due to filesystem corruption don't cause an immediate failure, but only an error at the end of the readdir(), so that people can still see the filenames that are ok. There's also been discussion about just how much POSIX strictly speaking requires this since it's about filesystem corruption. It's really more "protect user space from bad behavior" as pointed out by Jann. But since Eric Biederman looked up the POSIX wording, here it is for context: "From readdir: The readdir() function shall return a pointer to a structure representing the directory entry at the current position in the directory stream specified by the argument dirp, and position the directory stream at the next entry. It shall return a null pointer upon reaching the end of the directory stream. The structure dirent defined in the <dirent.h> header describes a directory entry. From definitions: 3.129 Directory Entry (or Link) An object that associates a filename with a file. Several directory entries can associate names with the same file. ... 3.169 Filename A name consisting of 1 to {NAME_MAX} bytes used to name a file. The characters composing the name may be selected from the set of all character values excluding the slash character and the null byte. The filenames dot and dot-dot have special meaning. A filename is sometimes referred to as a 'pathname component'." Note that I didn't bother adding the checks to any legacy interfaces that nobody uses. Also note that if this ends up being noticeable as a performance regression, we can fix that to do a much more optimized model that checks for both NUL and '/' at the same time one word at a time. We haven't really tended to optimize 'memchr()', and it only checks for one pattern at a time anyway, and we really _should_ check for NUL too (but see the comment about "soft errors" in the code about why it currently only checks for '/') See the CONFIG_DCACHE_WORD_ACCESS case of hash_name() for how the name lookup code looks for pathname terminating characters in parallel. Link: https://lore.kernel.org/lkml/20190118161440.220134-2-jannh@google.com/ Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jann Horn <jannh@google.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-05Convert filldir[64]() from __put_user() to unsafe_put_user()Linus Torvalds
We really should avoid the "__{get,put}_user()" functions entirely, because they can easily be mis-used and the original intent of being used for simple direct user accesses no longer holds in a post-SMAP/PAN world. Manually optimizing away the user access range check makes no sense any more, when the range check is generally much cheaper than the "enable user accesses" code that the __{get,put}_user() functions still need. So instead of __put_user(), use the unsafe_put_user() interface with user_access_{begin,end}() that really does generate better code these days, and which is generally a nicer interface. Under some loads, the multiple user writes that filldir() does are actually quite noticeable. This also makes the dirent name copy use unsafe_put_user() with a couple of macros. We do not want to make function calls with SMAP/PAN disabled, and the code this generates is quite good when the architecture uses "asm goto" for unsafe_put_user() like x86 does. Note that this doesn't bother with the legacy cases. Nobody should use them anyway, so performance doesn't really matter there. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-05drm/mcde: Fix reference to DOC commentJonathan Neuschäfer
The :doc: reference did not match the DOC comment's name. Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE") Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191002153827.23026-1-j.neuschaefer@gmx.net
2019-10-05Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds
Pull networking fixes from David Miller: 1) Fix ieeeu02154 atusb driver use-after-free, from Johan Hovold. 2) Need to validate TCA_CBQ_WRROPT netlink attributes, from Eric Dumazet. 3) txq null deref in mac80211, from Miaoqing Pan. 4) ionic driver needs to select NET_DEVLINK, from Arnd Bergmann. 5) Need to disable bh during nft_connlimit GC, from Pablo Neira Ayuso. 6) Avoid division by zero in taprio scheduler, from Vladimir Oltean. 7) Various xgmac fixes in stmmac driver from Jose Abreu. 8) Avoid 64-bit division in mlx5 leading to link errors on 32-bit from Michal Kubecek. 9) Fix bad VLAN check in rtl8366 DSA driver, from Linus Walleij. 10) Fix sleep while atomic in sja1105, from Vladimir Oltean. 11) Suspend/resume deadlock in stmmac, from Thierry Reding. 12) Various UDP GSO fixes from Josh Hunt. 13) Fix slab out of bounds access in tcp_zerocopy_receive(), from Eric Dumazet. 14) Fix OOPS in __ipv6_ifa_notify(), from David Ahern. 15) Memory leak in NFC's llcp_sock_bind, from Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (72 commits) selftests/net: add nettest to .gitignore net: qlogic: Fix memory leak in ql_alloc_large_buffers nfc: fix memory leak in llcp_sock_bind() sch_dsmark: fix potential NULL deref in dsmark_init() net: phy: at803x: use operating parameters from PHY-specific status net: phy: extract pause mode net: phy: extract link partner advertisement reading net: phy: fix write to mii-ctrl1000 register ipv6: Handle missing host route in __ipv6_ifa_notify net: phy: allow for reset line to be tied to a sleepy GPIO controller net: ipv4: avoid mixed n_redirects and rate_tokens usage r8152: Set macpassthru in reset_resume callback cxgb4:Fix out-of-bounds MSI-X info array access Revert "ipv6: Handle race in addrconf_dad_work" net: make sock_prot_memory_pressure() return "const char *" rxrpc: Fix rxrpc_recvmsg tracepoint qmi_wwan: add support for Cinterion CLS8 devices tcp: fix slab-out-of-bounds in tcp_zerocopy_receive() lib: textsearch: fix escapes in example code udp: only do GSO if # of segs > 1 ...
2019-10-05Merge tag 's390-5.4-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - defconfig updates - Fix build errors with CC_OPTIMIZE_FOR_SIZE due to usage of "i" constraint for function arguments. Two kvm changes acked-by Christian Borntraeger. - Fix -Wunused-but-set-variable warnings in mm code. - Avoid a constant misuse in qdio. - Handle a case when cpumf is temporarily unavailable. * tag 's390-5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: KVM: s390: mark __insn32_query() as __always_inline KVM: s390: fix __insn32_query() inline assembly s390: update defconfigs s390/pci: mark function(s) __always_inline s390/mm: mark function(s) __always_inline s390/jump_label: mark function(s) __always_inline s390/cpu_mf: mark function(s) __always_inline s390/atomic,bitops: mark function(s) __always_inline s390/mm: fix -Wunused-but-set-variable warnings s390: mark __cpacf_query() as __always_inline s390/qdio: clarify size of the QIB parm area s390/cpumf: Fix indentation in sampling device driver s390/cpumsf: Check for CPU Measurement sampling s390/cpumf: Use consistant debug print format
2019-10-05KVM: s390: mark __insn32_query() as __always_inlineHeiko Carstens
__insn32_query() will not compile if the compiler decides to not inline it, since it contains an inline assembly with an "i" constraint with variable contents. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-10-05KVM: s390: fix __insn32_query() inline assemblyHeiko Carstens
The inline assembly constraints of __insn32_query() tell the compiler that only the first byte of "query" is being written to. Intended was probably that 32 bytes are written to. Fix and simplify the code and just use a "memory" clobber. Fixes: d668139718a9 ("KVM: s390: provide query function for instructions returning 32 byte") Cc: stable@vger.kernel.org # v5.2+ Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-10-05drm/lima: Add support for multiple reset linesPeter Griffin
Some SoCs like HiKey have 2 reset lines, so update to use the devm_reset_control_array_* variant of the API so that multiple resets can be specified in DT. Cc: Qiang Yu <yuq825@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: lima@lists.freedesktop.org Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191001182927.70448-1-john.stultz@linaro.org
2019-10-05dma-mapping: fix false positivse warnings in dma_common_free_remap()Andrey Smirnov
Commit 5cf4537975bb ("dma-mapping: introduce a dma_common_find_pages helper") changed invalid input check in dma_common_free_remap() from: if (!area || !area->flags != VM_DMA_COHERENT) to if (!area || !area->flags != VM_DMA_COHERENT || !area->pages) which seem to produce false positives for memory obtained via dma_common_contiguous_remap() This triggers the following warning message when doing "reboot" on ZII VF610 Dev Board Rev B: WARNING: CPU: 0 PID: 1 at kernel/dma/remap.c:112 dma_common_free_remap+0x88/0x8c trying to free invalid coherent area: 9ef82980 Modules linked in: CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.3.0-rc6-next-20190820 #119 Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) Backtrace: [<8010d1ec>] (dump_backtrace) from [<8010d588>] (show_stack+0x20/0x24) r7:8015ed78 r6:00000009 r5:00000000 r4:9f4d9b14 [<8010d568>] (show_stack) from [<8077e3f0>] (dump_stack+0x24/0x28) [<8077e3cc>] (dump_stack) from [<801197a0>] (__warn.part.3+0xcc/0xe4) [<801196d4>] (__warn.part.3) from [<80119830>] (warn_slowpath_fmt+0x78/0x94) r6:00000070 r5:808e540c r4:81c03048 [<801197bc>] (warn_slowpath_fmt) from [<8015ed78>] (dma_common_free_remap+0x88/0x8c) r3:9ef82980 r2:808e53e0 r7:00001000 r6:a0b1e000 r5:a0b1e000 r4:00001000 [<8015ecf0>] (dma_common_free_remap) from [<8010fa9c>] (remap_allocator_free+0x60/0x68) r5:81c03048 r4:9f4d9b78 [<8010fa3c>] (remap_allocator_free) from [<801100d0>] (__arm_dma_free.constprop.3+0xf8/0x148) r5:81c03048 r4:9ef82900 [<8010ffd8>] (__arm_dma_free.constprop.3) from [<80110144>] (arm_dma_free+0x24/0x2c) r5:9f563410 r4:80110120 [<80110120>] (arm_dma_free) from [<8015d80c>] (dma_free_attrs+0xa0/0xdc) [<8015d76c>] (dma_free_attrs) from [<8020f3e4>] (dma_pool_destroy+0xc0/0x154) r8:9efa8860 r7:808f02f0 r6:808f02d0 r5:9ef82880 r4:9ef82780 [<8020f324>] (dma_pool_destroy) from [<805525d0>] (ehci_mem_cleanup+0x6c/0x150) r7:9f563410 r6:9efa8810 r5:00000000 r4:9efd0148 [<80552564>] (ehci_mem_cleanup) from [<80558e0c>] (ehci_stop+0xac/0xc0) r5:9efd0148 r4:9efd0000 [<80558d60>] (ehci_stop) from [<8053c4bc>] (usb_remove_hcd+0xf4/0x1b0) r7:9f563410 r6:9efd0074 r5:81c03048 r4:9efd0000 [<8053c3c8>] (usb_remove_hcd) from [<8056361c>] (host_stop+0x48/0xb8) r7:9f563410 r6:9efd0000 r5:9f5f4040 r4:9f5f5040 [<805635d4>] (host_stop) from [<80563d0c>] (ci_hdrc_host_destroy+0x34/0x38) r7:9f563410 r6:9f5f5040 r5:9efa8800 r4:9f5f4040 [<80563cd8>] (ci_hdrc_host_destroy) from [<8055ef18>] (ci_hdrc_remove+0x50/0x10c) [<8055eec8>] (ci_hdrc_remove) from [<804a2ed8>] (platform_drv_remove+0x34/0x4c) r7:9f563410 r6:81c4f99c r5:9efa8810 r4:9efa8810 [<804a2ea4>] (platform_drv_remove) from [<804a18a8>] (device_release_driver_internal+0xec/0x19c) r5:00000000 r4:9efa8810 [<804a17bc>] (device_release_driver_internal) from [<804a1978>] (device_release_driver+0x20/0x24) r7:9f563410 r6:81c41ed0 r5:9efa8810 r4:9f4a1dac [<804a1958>] (device_release_driver) from [<804a01b8>] (bus_remove_device+0xdc/0x108) [<804a00dc>] (bus_remove_device) from [<8049c204>] (device_del+0x150/0x36c) r7:9f563410 r6:81c03048 r5:9efa8854 r4:9efa8810 [<8049c0b4>] (device_del) from [<804a3368>] (platform_device_del.part.2+0x20/0x84) r10:9f563414 r9:809177e0 r8:81cb07dc r7:81c78320 r6:9f563454 r5:9efa8800 r4:9efa8800 [<804a3348>] (platform_device_del.part.2) from [<804a3420>] (platform_device_unregister+0x28/0x34) r5:9f563400 r4:9efa8800 [<804a33f8>] (platform_device_unregister) from [<8055dce0>] (ci_hdrc_remove_device+0x1c/0x30) r5:9f563400 r4:00000001 [<8055dcc4>] (ci_hdrc_remove_device) from [<805652ac>] (ci_hdrc_imx_remove+0x38/0x118) r7:81c78320 r6:9f563454 r5:9f563410 r4:9f541010 [<8056538c>] (ci_hdrc_imx_shutdown) from [<804a2970>] (platform_drv_shutdown+0x2c/0x30) [<804a2944>] (platform_drv_shutdown) from [<8049e4fc>] (device_shutdown+0x158/0x1f0) [<8049e3a4>] (device_shutdown) from [<8013ac80>] (kernel_restart_prepare+0x44/0x48) r10:00000058 r9:9f4d8000 r8:fee1dead r7:379ce700 r6:81c0b280 r5:81c03048 r4:00000000 [<8013ac3c>] (kernel_restart_prepare) from [<8013ad14>] (kernel_restart+0x1c/0x60) [<8013acf8>] (kernel_restart) from [<8013af84>] (__do_sys_reboot+0xe0/0x1d8) r5:81c03048 r4:00000000 [<8013aea4>] (__do_sys_reboot) from [<8013b0ec>] (sys_reboot+0x18/0x1c) r8:80101204 r7:00000058 r6:00000000 r5:00000000 r4:00000000 [<8013b0d4>] (sys_reboot) from [<80101000>] (ret_fast_syscall+0x0/0x54) Exception stack(0x9f4d9fa8 to 0x9f4d9ff0) 9fa0: 00000000 00000000 fee1dead 28121969 01234567 379ce700 9fc0: 00000000 00000000 00000000 00000058 00000000 00000000 00000000 00016d04 9fe0: 00028e0c 7ec87c64 000135ec 76c1f410 Restore original invalid input check in dma_common_free_remap() to avoid this problem. Fixes: 5cf4537975bb ("dma-mapping: introduce a dma_common_find_pages helper") Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> [hch: just revert the offending hunk instead of creating a new helper] Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-10-05kheaders: make headers archive reproducibleDmitry Goldin
In commit 43d8ce9d65a5 ("Provide in-kernel headers to make extending kernel easier") a new mechanism was introduced, for kernels >=5.2, which embeds the kernel headers in the kernel image or a module and exposes them in procfs for use by userland tools. The archive containing the header files has nondeterminism caused by header files metadata. This patch normalizes the metadata and utilizes KBUILD_BUILD_TIMESTAMP if provided and otherwise falls back to the default behaviour. In commit f7b101d33046 ("kheaders: Move from proc to sysfs") it was modified to use sysfs and the script for generation of the archive was renamed to what is being patched. Signed-off-by: Dmitry Goldin <dgoldin+lkml@protonmail.ch> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-05kbuild: update compile-test header list for v5.4-rc2Masahiro Yamada
Commit 6dc280ebeed2 ("coda: remove uapi/linux/coda_psdev.h") removed a header in question. Some more build errors were fixed. Add more headers into the test coverage. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-05kbuild: two minor updates for Documentation/kbuild/modules.rstMasahiro Yamada
Capitalize the first word in the sentence. Use obj-m instead of obj-y. obj-y still works, but we have no built-in objects in external module builds. So, obj-m is better IMHO. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-05scripts/setlocalversion: clear local variable to make it work for shMasahiro Yamada
Geert Uytterhoeven reports a strange side-effect of commit 858805b336be ("kbuild: add $(BASH) to run scripts with bash-extension"), which inserts the contents of a localversion file in the build directory twice. [Steps to Reproduce] $ echo bar > localversion $ mkdir build $ cd build/ $ echo foo > localversion $ make -s -f ../Makefile defconfig include/config/kernel.release $ cat include/config/kernel.release 5.4.0-rc1foofoobar This comes down to the behavior change of local variables. The 'man sh' on my Ubuntu machine, where sh is an alias to dash, explains as follows: When a variable is made local, it inherits the initial value and exported and readonly flags from the variable with the same name in the surrounding scope, if there is one. Otherwise, the variable is initially unset. [Test Code] foo () { local res echo "res: $res" } res=1 foo [Result] $ sh test.sh res: 1 $ bash test.sh res: So, scripts/setlocalversion correctly works only for bash in spite of its hashbang being #!/bin/sh. Nobody had noticed it before because CONFIG_SHELL was previously set to bash almost all the time. Now that CONFIG_SHELL is set to sh, we must write portable and correct code. I gave the Fixes tag to the commit that uncovered the issue. Clear the variable 'res' in collect_files() to make it work for sh (and it also works on distributions where sh is an alias to bash). Fixes: 858805b336be ("kbuild: add $(BASH) to run scripts with bash-extension") Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-10-05namespace: fix namespace.pl script to support relative pathsJacob Keller
The namespace.pl script does not work properly if objtree is not set to an absolute path. The do_nm function is run from within the find function, which changes directories. Because of this, appending objtree, $File::Find::dir, and $source, will return a path which is not valid from the current directory. This used to work when objtree was set to an absolute path when using "make namespacecheck". It appears to have not worked when calling ./scripts/namespace.pl directly. This behavior was changed in 7e1c04779efd ("kbuild: Use relative path for $(objtree)", 2014-05-14) Rather than fixing the Makefile to set objtree to an absolute path, just fix namespace.pl to work when srctree and objtree are relative. Also fix the script to use an absolute path for these by default. Use the File::Spec module for this purpose. It's been part of perl 5 since 5.005. The curdir() function is used to get the current directory when the objtree and srctree aren't set in the environment. rel2abs() is used to convert possibly relative objtree and srctree environment variables to absolute paths. Finally, the catfile() function is used instead of string appending paths together, since this is more robust when joining paths together. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-05video/logo: do not generate unneeded logo C filesMasahiro Yamada
Currently, all the logo C files are generated irrespective of the CONFIG options. Adding them to extra-y is wrong. What we need to do here is to add them to 'targets' so that if_changed works properly. Files listed in 'targets' are cleaned, so clean-files is unneeded. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-05video/logo: remove unneeded *.o pattern from clean-filesMasahiro Yamada
The pattern *.o is cleaned up globally by the top Makefile. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-05integrity: remove pointless subdir-$(CONFIG_...)Masahiro Yamada
The ima/ and evm/ sub-directories contain built-in objects, so obj-$(CONFIG_...) is the correct way to descend into them. subdir-$(CONFIG_...) is redundant. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-05integrity: remove unneeded, broken attempt to add -fshort-wcharMasahiro Yamada
I guess commit 15ea0e1e3e18 ("efi: Import certificates from UEFI Secure Boot") attempted to add -fshort-wchar for building load_uefi.o, but it has never worked as intended. load_uefi.o is created in the platform_certs/ sub-directory. If you really want to add -fshort-wchar, the correct code is: $(obj)/platform_certs/load_uefi.o: KBUILD_CFLAGS += -fshort-wchar But, you do not need to fix it. Commit 8c97023cf051 ("Kbuild: use -fshort-wchar globally") had already added -fshort-wchar globally. This code was unneeded in the first place. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-04selftests/net: add nettest to .gitignoreJakub Kicinski
nettest is missing from gitignore. Fixes: acda655fefae ("selftests: Add nettest") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-04net: qlogic: Fix memory leak in ql_alloc_large_buffersNavid Emamdoost
In ql_alloc_large_buffers, a new skb is allocated via netdev_alloc_skb. This skb should be released if pci_dma_mapping_error fails. Fixes: 0f8ab89e825f ("qla3xxx: Check return code from pci_map_single() in ql_release_to_lrg_buf_free_list(), ql_populate_free_queue(), ql_alloc_large_buffers(), and ql3xxx_send()") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>