Commit graph

535764 commits

Author SHA1 Message Date
Sinclair Yeh
05c9501859 drm/vmwgfx: Fix crash when unloading vmwgfx v2
This patch fixes two issues.  One, when a surface is a proxy for a DMA
buffer, it holds an extra reference that needs to be cleared.

Two, when fbdev is enabled, we need to unpin the framebuffer before
unloading the driver.  This is done by a call to vmw_fb_off().

v2
Moved unreferencing surface to from vmw_framebuffer_surface_destroy()
to vmw_kms_new_framebuffer()

Added "struct vmw_framebuffer *vfb = NULL;" to silence a compiler
warning.

Removed error checking after calling vmw_surface/dmabuf_reference()

Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2015-08-12 10:06:13 -07:00
Thomas Hellstrom
df45e9d410 drm/vmwgfx: Fix framebuffer creation on older hardware
On older hardware, texture max width and height is not available, so set
it to something reasonable, like 8192.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2015-08-12 10:05:44 -07:00
Sinclair Yeh
65ade7d34b drm/vmwgfx: Fixed topology boundary checking for Screen Targets
For a Screen Target capable display device, the display topology is
limited by SVGA_REG_MAX_PRIMARY_BOUNDING_BOX_MEM.  Two values are
checked against this limit:
  1.  Size of the bounding box enclosing all the displays, and
  2.  Size of the total number of displays, e.g. framebuffers

The limitations above mean we do not have exact max width and
height for the topology.  The best current option is to set those to
the maximum texture width/height.

Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
2015-08-12 10:05:34 -07:00
Alex Deucher
e037239e5e drm/radeon: add new OLAND pci id
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2015-08-12 12:24:05 -04:00
Alex Deucher
b8826b0cbf Revert "drm/amdgpu: Configure doorbell to maximum slots"
This reverts commit 78ad5cdd21.
This commit breaks dpm and suspend/resume on CZ.
2015-08-12 12:24:04 -04:00
Boyuan Zhang
8c8bac59dd drm/amdgpu: add context buffer size check for HEVC
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2015-08-12 12:24:03 -04:00
Linus Torvalds
cec45d901e regmap: Fix handling of present bits on rbtree cache block resize
When expanding a cache block we use krealloc() to resize the register
 present bitmap without initialising the newly allocated data (the
 original code was written for kzalloc()).  Add an appropraite memset()
 to fix that.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJVyztsAAoJECTWi3JdVIfQ8QIH/RGXFhPUPWdXhi4JYn8+bIGb
 6SSBzsxGlCocWBrzyaZRcz/WB7Na7t+oXoYEjk8CA+/8zPLRoCXHKmIETmQW0+7G
 hUY+YNk8xxUtPuReeGgqZ7z9l9mC2f0UVPvgWn6dELamxtqr0LmODdKp5D3vLQLp
 c2eFqZr3wjYwC9vuWElaUftyQzSYaj6Rr6PnZ6bD/pN/YY3zd53gt7QluT9SzUxs
 5uZXhd1UD6GTDxCrtfqemlEaOYpQOdMO0h/3Eko4MbdCeq3bOq6kn9a+E7nfvE4v
 dIeEdafqVABgKHi66B83Fu/5eJI+kI+qo9u2QuWLB9AWAJnZuiZc968eIDaKMBE=
 =GTVe
 -----END PGP SIGNATURE-----

Merge tag 'regmap-fix-v4.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

Pull regmap fix from Mark Brown:
 "regmap: Fix handling of present bits on rbtree cache block resize

  When expanding a cache block we use krealloc() to resize the register
  present bitmap without initialising the newly allocated data (the
  original code was written for kzalloc()).  Add an appropraite memset()
  to fix that"

* tag 'regmap-fix-v4.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: regcache-rbtree: Clean new present bits on present bitmap resize
2015-08-12 09:06:39 -07:00
Thierry Reding
d4853630b3 drm/atomic: Use KMS VBLANK API
Instead of using the legacy VBLANK API, use the new KMS API. This is
part of an effort to convert all existing users so that the KMS API can
be changed to properly use per-CRTC data.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:41:30 +02:00
Thierry Reding
c30e11fc66 drm/irq: Document return values more consistently
Some of the functions are documented inconsistently. Add Returns:
sections where missing and use consistent style to describe the return
value.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:40:31 +02:00
Thierry Reding
cc1ef118fc drm/irq: Make pipe unsigned and name consistent
Name all references to the pipe number (CRTC index) consistently to make
it easier to distinguish which is a pipe number and which is a pointer
to struct drm_crtc.

While at it also make all references to the pipe number unsigned because
there is no longer any reason why it should ever be negative.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:39:52 +02:00
Thierry Reding
7d1de85163 drm/irq: Check for valid VBLANK before dereference
When accessing the array of per-CRTC VBLANK structures we must always
check that the index into the array is valid before dereferencing to
avoid crashing.

Signed-off-by: Thierry Reding <treding@nvidia.com>
[danvet: Squash in my own whitespace ocd fixup in drm_vblank_count.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:39:47 +02:00
Thierry Reding
2a7d3d6d5d drm/irq: Remove negative CRTC index special-case
The drm_send_vblank_event() function treats negative CRTC indices as
meaning that a driver doesn't have proper VBLANK handling. This is the
only place where DRM needs negative CRTC indices, so in order to enable
subsequent cleanup, remove this special case and replace it by the more
obvious check for whether or not VBLANK support was initialized.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:28:21 +02:00
Yi Zhang
34dd051741 dm cache policy smq: move 'dm-cache-default' module alias to SMQ
When creating dm-cache with the default policy, it will call
request_module("dm-cache-default") to register the default policy.
But the "dm-cache-default" alias was left referring to the MQ policy.
Fix this by moving the module alias to SMQ.

Fixes: bccab6a0 (dm cache: switch the "default" cache replacement policy from mq to smq)
Signed-off-by: Yi Zhang <yizhan@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2015-08-12 11:27:29 -04:00
Thierry Reding
b54a0935b0 drm/plane: Remove redundant extern
Use of the extern keyword for function prototypes is unnecessary, so it
can be removed.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:15:12 +02:00
Thierry Reding
45e3743aff drm/plane: Use consistent data types for format count
Rather than a mix of the the sized uint32_t and signed integer, use an
unsized unsigned int to specify the format count.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:14:24 +02:00
Thierry Reding
798ae0f669 vga_switcheroo: Remove unnecessary checks
debugfs_remove() gracefully ignores NULL parameters, so the explicit
checks can be removed.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:13:19 +02:00
Thierry Reding
7491bfb446 vga_switcheroo: Wrap overly long lines
Wrap overly long lines to make checkpatch happy. While at it, also add
blank lines after declarations to eliminate additional problems flagged
by checkpatch.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:13:18 +02:00
Thierry Reding
9b0be1ebec vga_switcheroo: Use pr_fmt()
Use pr_fmt() to define the "vga_switcheroo: " prefix that is prepended
to all output messages emitted by pr_*() functions. This allows making
existing strings much shorter and eliminates a bunch of warnings from
checkpatch about lines being overly long.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:13:18 +02:00
Thierry Reding
7130927830 vga_switcheroo: Cleanup header comment
The header comment uses a weird combination of formatting styles. Make
it consistent.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:11:59 +02:00
Thierry Reding
bf8252b3fc vga_switcheroo: Use pr_*() instead of printk()
This silences a bunch of checkpatch warnings and makes the code shorter.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:11:59 +02:00
Thierry Reding
5d90ccf908 vgaarb: Fix a few checkpatch errors and warnings
Wrap overly long lines (offending lines were mostly comments, so trivial
to fix up) and a number of other coding style issues pointed out by the
checkpatch tool.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:11:58 +02:00
Thierry Reding
8b7e2e865f vgaarb: Use vgaarb: prefix consistently in messages
Define the pr_fmt() macro to causes all messages emitted by pr_*()
functions to be prefixed with "vgaarb: ".

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:11:58 +02:00
Thierry Reding
eb6944f2fc vgaarb: Stop complaining about absent devices
Some setups do not register a default VGA device, in which case the VGA
arbiter will still complain about the (non-existent) PCI device being a
non-VGA device.

Fix this by making the error message conditional on a default VGA device
having been set up. Note that the easy route of erroring out early isn't
going to work because otherwise priv->target won't be properly updated.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 17:11:57 +02:00
Joe Thornber
b0dc3c8bc1 dm btree: add ref counting ops for the leaves of top level btrees
When using nested btrees, the top leaves of the top levels contain
block addresses for the root of the next tree down.  If we shadow a
shared leaf node the leaf values (sub tree roots) should be incremented
accordingly.

This is only an issue if there is metadata sharing in the top levels.
Which only occurs if metadata snapshots are being used (as is possible
with dm-thinp).  And could result in a block from the thinp metadata
snap being reused early, thus corrupting the thinp metadata snap.

Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2015-08-12 10:50:37 -04:00
Joe Thornber
7f518ad0a2 dm thin metadata: delete btrees when releasing metadata snapshot
The device details and mapping trees were just being decremented
before.  Now btree_del() is called to do a deep delete.

Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2015-08-12 10:42:51 -04:00
Matt Fleming
d7a702f0b1 perf/x86/intel/cqm: Do not access cpu_data() from CPU_UP_PREPARE handler
Tony reports that booting his 144-cpu machine with maxcpus=10 triggers
the following WARN_ON():

[   21.045727] WARNING: CPU: 8 PID: 647 at arch/x86/kernel/cpu/perf_event_intel_cqm.c:1267 intel_cqm_cpu_prepare+0x75/0x90()
[   21.045744] CPU: 8 PID: 647 Comm: systemd-udevd Not tainted 4.2.0-rc4 #1
[   21.045745] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRHSXSD1.86B.0066.R00.1506021730 06/02/2015
[   21.045747]  0000000000000000 0000000082771b09 ffff880856333ba8 ffffffff81669b67
[   21.045748]  0000000000000000 0000000000000000 ffff880856333be8 ffffffff8107b02a
[   21.045750]  ffff88085b789800 ffff88085f68a020 ffffffff819e2470 000000000000000a
[   21.045750] Call Trace:
[   21.045757]  [<ffffffff81669b67>] dump_stack+0x45/0x57
[   21.045759]  [<ffffffff8107b02a>] warn_slowpath_common+0x8a/0xc0
[   21.045761]  [<ffffffff8107b15a>] warn_slowpath_null+0x1a/0x20
[   21.045762]  [<ffffffff81036725>] intel_cqm_cpu_prepare+0x75/0x90
[   21.045764]  [<ffffffff81036872>] intel_cqm_cpu_notifier+0x42/0x160
[   21.045767]  [<ffffffff8109a33d>] notifier_call_chain+0x4d/0x80
[   21.045769]  [<ffffffff8109a44e>] __raw_notifier_call_chain+0xe/0x10
[   21.045770]  [<ffffffff8107b538>] _cpu_up+0xe8/0x190
[   21.045771]  [<ffffffff8107b65a>] cpu_up+0x7a/0xa0
[   21.045774]  [<ffffffff8165e920>] cpu_subsys_online+0x40/0x90
[   21.045777]  [<ffffffff81433b37>] device_online+0x67/0x90
[   21.045778]  [<ffffffff81433bea>] online_store+0x8a/0xa0
[   21.045782]  [<ffffffff81430e78>] dev_attr_store+0x18/0x30
[   21.045785]  [<ffffffff8126b6ba>] sysfs_kf_write+0x3a/0x50
[   21.045786]  [<ffffffff8126ad40>] kernfs_fop_write+0x120/0x170
[   21.045789]  [<ffffffff811f0b77>] __vfs_write+0x37/0x100
[   21.045791]  [<ffffffff811f38b8>] ? __sb_start_write+0x58/0x110
[   21.045795]  [<ffffffff81296d2d>] ? security_file_permission+0x3d/0xc0
[   21.045796]  [<ffffffff811f1279>] vfs_write+0xa9/0x190
[   21.045797]  [<ffffffff811f2075>] SyS_write+0x55/0xc0
[   21.045800]  [<ffffffff81067300>] ? do_page_fault+0x30/0x80
[   21.045804]  [<ffffffff816709ae>] entry_SYSCALL_64_fastpath+0x12/0x71
[   21.045805] ---[ end trace fe228b836d8af405 ]---

The root cause is that CPU_UP_PREPARE is completely the wrong notifier
action from which to access cpu_data(), because smp_store_cpu_info()
won't have been executed by the target CPU at that point, which in turn
means that ->x86_cache_max_rmid and ->x86_cache_occ_scale haven't been
filled out.

Instead let's invoke our handler from CPU_STARTING and rename it
appropriately.

Reported-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Kanaka Juvva <kanaka.d.juvva@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vikas Shivappa <vikas.shivappa@intel.com>
Link: http://lkml.kernel.org/r/1438863163-14083-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-08-12 11:37:23 +02:00
Peter Zijlstra
dbc72b7a0c perf/x86/intel: Fix memory leak on hot-plug allocation fail
We fail to free the shared_regs allocation if the constraint_list
allocation fails.

Cure this and be more consistent in NULL-ing the pointers after free.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-08-12 11:37:22 +02:00
Peter Zijlstra
c7999c6f3f perf: Fix PERF_EVENT_IOC_PERIOD migration race
I ran the perf fuzzer, which triggered some WARN()s which are due to
trying to stop/restart an event on the wrong CPU.

Use the normal IPI pattern to ensure we run the code on the correct CPU.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: bad7192b84 ("perf: Fix PERF_EVENT_IOC_PERIOD to force-reset the period")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-08-12 11:37:22 +02:00
Ben Hutchings
ee9397a6fb perf: Fix double-free of the AUX buffer
If rb->aux_refcount is decremented to zero before rb->refcount,
__rb_free_aux() may be called twice resulting in a double free of
rb->aux_pages.  Fix this by adding a check to __rb_free_aux().

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: 57ffc5ca67 ("perf: Fix AUX buffer refcounting")
Link: http://lkml.kernel.org/r/1437953468.12842.17.camel@decadent.org.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-08-12 11:37:21 +02:00
Tomeu Vizoso
e984a1791a memory: omap-gpmc: Don't try to save uninitialized GPMC context
If for some reason the GPMC device hasn't been probed yet, gpmc_base is
going to be NULL. Because there's no context yet to be saved, just turn
these functions into no-ops until that device gets probed.

Unable to handle kernel NULL pointer dereference at virtual address 00000010
pgd = c0204000
[00000010] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc5-next-20150804-05947-g23f38fe8eda9 #1
Hardware name: Generic OMAP3-GP (Flattened Device Tree)
task: c0e623e8 ti: c0e5c000 task.ti: c0e5c000
PC is at omap3_gpmc_save_context+0x8/0xc4
LR is at omap_sram_idle+0x154/0x23c
pc : [<c087c7ac>]    lr : [<c023262c>]    psr: 60000193
sp : c0e5df40  ip : c0f92a80  fp : c0999eb0
r10: c0e57364  r9 : c0e66f14  r8 : 00000003
r7 : 00000000  r6 : 00000003  r5 : 00000000  r4 : c0f5f174
r3 : c0fa4fe8  r2 : 00000000  r1 : 00000000  r0 : fa200280
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80204019  DAC: 00000015
Process swapper/0 (pid: 0, stack limit = 0xc0e5c220)
Stack: (0xc0e5df40 to 0xc0e5e000)
df40: 00000000 c0e66ef8 c0f5f1a4 00000000 00000003 c02333a4 c3813822 00000000
df60: 00000000 c0e5a5c8 cfb8a5d0 c07f0c44 0e4f1d7e 00000000 00000000 00000000
df80: c3813822 00000000 cfb8a5d0 c0e5e4e4 cfb8a5d0 c0e66f14 c0e5a5c8 c0e5e54c
dfa0: c0e5e544 c0e57364 c0999eb0 c0277758 000000fa c0f5d000 00000000 c0d61c18
dfc0: ffffffff ffffffff 00000000 c0d61674 00000000 c0df7a48 00000000 c0f5d5d4
dfe0: c0e5e4c0 c0df7a44 c0e634f8 80204059 00000000 8020807c 00000000 00000000
[<c087c7ac>] (omap3_gpmc_save_context) from [<c023262c>] (omap_sram_idle+0x154/0x23c)
[<c023262c>] (omap_sram_idle) from [<c02333a4>] (omap3_enter_idle_bm+0xec/0x1a8)
[<c02333a4>] (omap3_enter_idle_bm) from [<c07f0c44>] (cpuidle_enter_state+0xbc/0x284)
[<c07f0c44>] (cpuidle_enter_state) from [<c0277758>] (cpu_startup_entry+0x174/0x24c)
[<c0277758>] (cpu_startup_entry) from [<c0d61c18>] (start_kernel+0x358/0x3c0)
[<c0d61c18>] (start_kernel) from [<8020807c>] (0x8020807c)
Code: c0ccace8 c0ccacc0 e59f30b4 e5932000 (e5921010)

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Suggested-by: Javier Martinez Canillas <javier@dowhile0.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Roger Quadros <rogerq@ti.com>
[tony@atomide.com: updated description as suggested by Javier]
Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-08-12 01:43:49 -07:00
Linus Torvalds
58ccab9134 Leonidas Spyropoulos found that modules like nouveau were being unselected
by make localmodconfig even though their configs were set and the module
 was loaded and visible by lsmod. The reason for this was because
 streamline-config.pl only looks at Makefiles, and not Kbuild files. As
 these modules use Kbuild for their names, they too need to be checked
 by localmodconfig. This was fixed by Richard Weinberger.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJVymvhAAoJEEjnJuOKh9ldSM4IAJlSMMqJ3cfYFBBpEPXc6cKw
 1hSgbX3FF8BDk/YKskBYm3qmFPTNZT/lLA/lG5w5Yt2Nf3jWKgVou/j1f0sboigl
 9fkoXgUXBRi8myubWHLAqvsNCxCLjTTjXRV+AWxTiPaGh6vnKX7393WFdvlLKhQz
 CVLRzbPfvVqSH+R1oxAeapmQ8TA3A7IPW5v1HtkrnWXqJOt1A1/4UnZ+Es/jgd7L
 1Syvf26C3kseWcqeUXIrvOBa4AgDS4kR8pdZJpvvSWbQRgebgEMH6gEk5jyI4JVd
 6RpoTUSgVwhFof6cblvlNs9ROZYCUJLzlxgiDD2tOYIwtrtc23QgY8a+WEE2eG8=
 =4S3x
 -----END PGP SIGNATURE-----

Merge tag 'localmodconfig-v4.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-kconfig

Pull localmodconfig fix from Steven Rostedt:
 "Leonidas Spyropoulos found that modules like nouveau were being
  unselected by make localmodconfig even though their configs were set
  and the module was loaded and visible by lsmod.

  The reason for this was because streamline-config.pl only looks at
  Makefiles, and not Kbuild files.  As these modules use Kbuild for
  their names, they too need to be checked by localmodconfig.  This was
  fixed by Richard Weinberger"

* tag 'localmodconfig-v4.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-kconfig:
  localmodconfig: Use Kbuild files too
2015-08-11 15:13:41 -07:00
Richard Weinberger
c0ddc8c745 localmodconfig: Use Kbuild files too
In kbuild it is allowed to define objects in files named "Makefile"
and "Kbuild".
Currently localmodconfig reads objects only from "Makefile"s and misses
modules like nouveau.

Link: http://lkml.kernel.org/r/1437948415-16290-1-git-send-email-richard@nod.at

Cc: stable@vger.kernel.org
Reported-and-tested-by: Leonidas Spyropoulos <artafinde@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2015-08-11 17:34:35 -04:00
David S. Miller
28eaad7504 Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
Johan Hedberg says:

====================
pull request: bluetooth 2015-08-11

Here's an important regression fix for the 4.2-rc series that ensures
user space isn't given invalid LTK values. The bug essentially prevents
the encryption of subsequent LE connections, i.e. makes it impossible to
pair devices over LE.

Let me know if there are any issues pulling. Thanks.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-11 14:16:07 -07:00
LEROY Christophe
c68875fa82 net: fs_enet: mask interrupts for TX partial frames.
We are not interested in interrupts for partially transmitted frames.
Unlike SCC and FCC, the FEC doesn't handle the I bit in buffer
descriptors, instead it defines two interrupt bits, TXB and TXF.

We have to mask TXB in order to only get interrupts once the
frame is fully transmitted.

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-11 12:05:34 -07:00
LEROY Christophe
8961822c46 net: fs_enet: explicitly remove I flag on TX partial frames
We are not interested in interrupts for partially transmitted frames,
we have to clear BD_ENET_TX_INTR explicitly otherwise it may remain
from a previously used descriptor.

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-11 12:05:34 -07:00
Linus Torvalds
edf15b4d4b fbdev fixes for 4.2
* Fix display regression on Versatile boards
 * Fix OF node refcount bugs on omapdss
 * fix WARN about clock prepare on pxa3xx_gcu
 * Fix mem leak in videomode helpers
 * Fix fbconsole related boot problem on sun7i-a20-olinuxino-micro
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJVyfKLAAoJEPo9qoy8lh719REQAJ5voAa4JZMdFaOjHSQlUMLW
 S+poOCaEoqW6V/Y2jbrEzBfFo6fZTJ5k1ip0jylbDaes4r02JXQIobdSiSTGjSmB
 g0ohUSymcIBk+MBgmDDCQl2PQcuwFes3t+yvssIXHhgHC6rH5IH/tB4e8c33K/G0
 cklaXC/h1Sp1ewk0V0IA4OvMY55VSk5BoQE1f6dZvT5zqKGaxKfl+VArNLWhGkxm
 8dcOTCGYcpoZGWNKmYdoRV6//Ydc/WUMVvFxOIgCTDWSChA0a1fancHB9Oa+3ZZc
 NoQQG+haN+/BnexTtGg0lZeNV2yRZfmwzRMM3o1rHF4QXvTpq48bAcIzVVAkN3fa
 txe3hurZ6rRiLo1wck64HmaVw0IvgyIHxCMz8+zIhpLntw4pfY1qtr3ZgaSsxmSw
 OWNK4En6Qfe0TuwulmeV+/f4f/1iY9eXDlctxuMQuqvv1sKea6S7eo5Fc+0/EHED
 ogIvFlzZPgziPc8P7se010cwDLTOfHd8UPCZGL9Brwl0tDI8EIR75msDWJvmo9hJ
 M15qT0d3w9iYxgkmJvl8cAxHB5+67R23GXexzA9Xt+h9FIaMIatq0fGPIl6s7wvf
 BYZTPGM7yjNouBGkej2VMSRZAw2NJnhHMJQqXJQbCHVxSpaNZK88YWB9B2PiifQI
 sQZDGeb67LkT0gqRp779
 =PAKL
 -----END PGP SIGNATURE-----

Merge tag 'fbdev-fixes-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux

Pull fbdev fixes from Tomi Valkeinen:
 - fix display regression on Versatile boards
 - fix OF node refcount bugs on omapdss
 - fix WARN about clock prepare on pxa3xx_gcu
 - fix mem leak in videomode helpers
 - fix fbconsole related boot problem on sun7i-a20-olinuxino-micro

* tag 'fbdev-fixes-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
  fbcon: unconditionally initialize cursor blink interval
  video: Fix possible leak in of_get_videomode()
  video: fbdev: pxa3xx_gcu: prepare the clocks
  OMAPDSS: Fix omap_dss_find_output_by_port_node() port refcount decrement
  OMAPDSS: Fix node refcount leak in omapdss_of_get_next_port()
  fbdev: select versatile helpers for the integrator
2015-08-11 10:23:59 -07:00
Inki Dae
845249172a drm/atomic: fix null pointer access to mode_fixup callback
This patch fixes null pointer access incurred when
encoder driver didn't set its own mode_fixup callback.

mode_fixup callback shoudn't be called if the callback
of drm_encoder_helper_funcs is NULL.

Changelog v2:
- change it to else if

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-11 17:20:30 +02:00
Olof Johansson
e2e927c823 Few trivial omap MMC regression fixes for card voltages where
the syscon areas for PBIAS regulator were missing "simple-bus"
 that prevents probing of the children in the mapped region.
 
 This probably was not noticed earlier as the bootloader has
 already configured the regulator for the card in the slot.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJVwympAAoJEBvUPslcq6VzeCUQAOBLq8Rq4DOe+VhbzPT9GRAw
 GoKAsJr1lBscj+WRQO5+pOeHE/vCXtQ/UrE+Y+9QXCjAV5IcSYYpNh7mHs5KnZzy
 B9EN5edlMp3Tt4U4Rej1PQLwCMa0TYHsj80lDH8yyMRLilts4SsFsWgdQ5PPYf4E
 O0T5RZR8cZgxsQWD6YyEg8FjCbsyTDOeiOJ0hnXX4qUPzS+AYcCsWpTFFrHfDrDB
 kH+mjEmFZCpxELeO8NFCBFz/HbLLzSRHafCmHFPfMn/kTeFhFnM4oHucTxyDpeMb
 9KXuehg9VsWjsZuCx34k7gf4emoxHDk9C/oHjVXJYBqR7RqOqYthB4cw4yijE9Ey
 KYEJGx9QlG76O2pU0EDlqVgUOQPV67q2fz2he6tIWbRulS8UHf6bcwiu412RifM8
 dXd4xctbrIprhbXjTt8pbuwx88z/1haO3H1Ir4yb++W7UBX6Bh1vfcjyzIzpyDbW
 /bRtq9MtM8Jx30mZDHyvE3LUKoIQo3oRWjm8ZqqjDulFd02CzyoGDs+hfCRt/ia4
 Tz+gCRJbF9g25XTbMxET8+7tzaztwW28jKKS6E9GM6jEDglG1avxku0yjx44yK6+
 iLgIeesXGbtKzPM9dWfXqzy7f6HfVvonvPPZlh1zygerr03G5Z3GY02ToiaEheEg
 aSe76i5wbpuhe6C+vWYy
 =qK3L
 -----END PGP SIGNATURE-----

Merge tag 'omap-for-v4.2/fixes-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

Few trivial omap MMC regression fixes for card voltages where
the syscon areas for PBIAS regulator were missing "simple-bus"
that prevents probing of the children in the mapped region.

This probably was not noticed earlier as the bootloader has
already configured the regulator for the card in the slot.

* tag 'omap-for-v4.2/fixes-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: dts: dra7: Fix broken pbias device creation
  ARM: dts: OMAP5: Fix broken pbias device creation
  ARM: dts: OMAP4: Fix broken pbias device creation
  ARM: dts: omap243x: Fix broken pbias device creation

Signed-off-by: Olof Johansson <olof@lixom.net>
2015-08-11 15:22:10 +02:00
Nathan Lynch
09edea4f8f ARM: 8410/1: VDSO: fix coarse clock monotonicity regression
Since 906c55579a ("timekeeping: Copy the shadow-timekeeper over the
real timekeeper last") it has become possible on ARM to:

- Obtain a CLOCK_MONOTONIC_COARSE or CLOCK_REALTIME_COARSE timestamp
  via syscall.
- Subsequently obtain a timestamp for the same clock ID via VDSO which
  predates the first timestamp (by one jiffy).

This is because ARM's update_vsyscall is deriving the coarse time
using the __current_kernel_time interface, when it should really be
using the timekeeper object provided to it by the timekeeping core.
It happened to work before only because __current_kernel_time would
access the same timekeeper object which had been passed to
update_vsyscall.  This is no longer the case.

Cc: stable@vger.kernel.org
Fixes: 906c55579a ("timekeeping: Copy the shadow-timekeeper over the real timekeeper last")
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-08-11 13:42:44 +01:00
Daniel Vetter
0695726e85 drm/i915: Use CONFIG_DRM_FBDEV_EMULATION
Instead of our own duplicated one. This fixes a bug in the driver
unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
try to unregister the nonexistent fbdev drm_framebuffer.

Cc: Archit Taneja <architt@codeaurora.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-11 14:00:29 +02:00
Julien Grall
c22fe519e7 xen/xenbus: Don't leak memory when unmapping the ring on HVM backend
The commit ccc9d90a9a "xenbus_client:
Extend interface to support multi-page ring" removes the call to
free_xenballooned_pages() in xenbus_unmap_ring_vfree_hvm(), leaking a
page for every shared ring.

Only with backends running in HVM domains were affected.

Signed-off-by: Julien Grall <julien.grall@citrix.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
2015-08-11 11:05:58 +01:00
David Vrabel
ad6cd7bafc Revert "xen/events/fifo: Handle linked events when closing a port"
This reverts commit fcdf31a7c1.

This was causing a WARNING whenever a PIRQ was closed since
shutdown_pirq() is called with irqs disabled.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: <stable@vger.kernel.org>
2015-08-11 11:05:42 +01:00
Maarten Lankhorst
cebbb7396b drm/core: Set mode to NULL when connectors in a set drops to 0.
Without this when a MST connector is removed drm_atomic_helper_set_config
can complain about set->mode && !set->num_connectors.

------------[ cut here ]------------
WARNING: CPU: 2 PID: 2403 at drivers/gpu/drm/drm_atomic_helper.c:1673 drm_atomic_helper_set_config+0x22e/0x420()
CPU: 2 PID: 2403 Comm: kms_flip Not tainted 4.2.0-rc5 #4233
Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
 ffffffff81ac75e8 ffff88004e4ffbf8 ffffffff81714c34 0000000080000000
 0000000000000000 ffff88004e4ffc38 ffffffff8107bf81 ffff88004e4ffc48
 ffff8800d8ca0690 ffff8800d8d7a080 ffff8800d8cc2290 ffff8800d07bc9f0
Call Trace:
 [<ffffffff81714c34>] dump_stack+0x4f/0x7b
 [<ffffffff8107bf81>] warn_slowpath_common+0x81/0xc0
 [<ffffffff8107c065>] warn_slowpath_null+0x15/0x20
 [<ffffffff813d9e3e>] drm_atomic_helper_set_config+0x22e/0x420
 [<ffffffff813da174>] ? drm_atomic_helper_plane_set_property+0x84/0xc0
 [<ffffffff813ee101>] drm_mode_set_config_internal+0x61/0x100
 [<ffffffff813dc4ed>] restore_fbdev_mode+0xbd/0xe0
 [<ffffffff813de1e4>] drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x70
 [<ffffffffc0123d11>] intel_fbdev_restore_mode+0x21/0x80 [i915]
 [<ffffffffc014bf69>] i915_driver_lastclose+0x9/0x10 [i915]
 [<ffffffff813e2429>] drm_lastclose+0x29/0x130
 [<ffffffff813e2844>] drm_release+0x314/0x500
 [<ffffffff81194795>] __fput+0xe5/0x1f0
 [<ffffffff811948d9>] ____fput+0x9/0x10
 [<ffffffff810968d8>] task_work_run+0x88/0xb0
 [<ffffffff8107d53f>] do_exit+0x37f/0xa90
 [<ffffffff8127e258>] ? selinux_file_ioctl+0x48/0xc0
 [<ffffffff81277dfe>] ? security_file_ioctl+0x3e/0x60
 [<ffffffff8107ec80>] do_group_exit+0x40/0xa0
 [<ffffffff8107ecef>] SyS_exit_group+0xf/0x10
 [<ffffffff8171bdd7>] entry_SYSCALL_64_fastpath+0x12/0x6a
---[ end trace 0daf358c49351567 ]---

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-11 12:04:19 +02:00
Daniel Vetter
992cbf19b3 drm/atomic: Call ww_acquire_done after check phase is complete
We want to make sure that no one tries to acquire more locks and
states, and ww mutexes provide debug facilities for that. So use them.

v2: Only call acquire_done when ->atomic_check was successful to avoid
falling over an -EDEADLK (spotted by Maarten).

Cc: Rob Clark <robdclark@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-08-11 12:04:18 +02:00
Daniel Vetter
460e8e2cf4 drm/atomic: Paper over locking WARN in default_state_clear
In

commit 6f75cea66c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Nov 19 18:38:07 2014 +0100

    drm/atomic: Only destroy connector states with connection mutex held

I tried to fix races of atomic commits against connector
hot-unplugging. The idea is to ensure lifetimes by holding the
connection_mutex long enough. That works for synchronous commits, but
not for async ones.

For async atomic commit we really need to fix up connector lifetimes
for real. But that's a much bigger task, so just add more duct-tape:
For cleaning up connector states we currently don't need the connector
itself. So NULL it out and remove the locking check. Of course that
check was to protect the entire sequence, but the modeset itself
should be save since currently DP MST hot-removal does a dpms-off. And
that should synchronize with any outstanding async atomic commit.

Or at least that's my hope, this is all a giant mess.

Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-08-11 12:04:17 +02:00
Daniel Vetter
fbb40b2857 drm/edid: Use ARRAY_SIZE in drm_add_modes_noedid
Spotted while reading code for random reasons.

Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-08-11 12:04:16 +02:00
Daniel Vetter
2143287d4e drm/qxl: Don't take dev->struct_mutex in bo_force_delete
It really doesn't protect anything which doesn't have other locks
already. It also doesn't seem to be wired up into the driver unload
code fwiw, but that's a different issue.

Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-08-11 12:04:16 +02:00
Daniel Vetter
c325f88d7d drm/nouveau: Don't take dev->struct_mutex in ttm_fini
This is only called in driver load/unload paths, no need to grab any
locks at all. Also, ttm takes care of itself anyway.

Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-08-11 12:04:15 +02:00
Daniel Vetter
648a4ce7ca drm/rockchip: Don't grab dev->struct_mutex for in mmap offset ioctl
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).

Aside: I stumbled over the mmap handler which directly does a
dma_mmap_attrs. But totally fails to grab a reference on the
underlying object and hence looks like it happily just leaks the ptes
since there's no guarantee the mmap isn't still around when
gem_free_object is called. Which the kerneldoc of dma_mmap_attrs
explicitly forbids.

v2: Fixup compile fail 0-day spotted.

Cc: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-08-11 12:04:06 +02:00
Marek Szyprowski
9992349a54 drm/exynos/fimc: fix runtime pm support
Once pm_runtime_set_active() gets called, the kernel assumes that given
device has already enabled runtime pm and will call pm_runtime_suspend()
without matching pm_runtime_resume(). In case of DRM FIMC IPP driver,
this will result in calling clk_disable() without respective call to
clk_enable(). This patch removes call to pm_runtime_set_active() to
ensure that pm_runtime_suspend/resume calls will match.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-11 17:21:35 +09:00