While examining output from trial builds with -Wformat-security enabled,
many strings were found that should be defined as "const", or as a char
array instead of char pointer.  This makes some static analysis easier,
by producing fewer false positives.

As these are all trivial changes, it seemed best to put them all in a
single patch rather than chopping them up per maintainer.

Link: http://lkml.kernel.org/r/20170405214711.GA5711@beastSigned-off-by: NKees Cook <keescook@chromium.org>
Acked-by: Jes Sorensen <jes@trained-monkey.org>	[runner.c]
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Cc: Salil Mehta <salil.mehta@huawei.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: Florian Westphal <fw@strlen.de>
Cc: Antonio Quartulli <a@unstable.cc>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Kejian Yan <yankejian@huawei.com>
Cc: Daode Huang <huangdaode@hisilicon.com>
Cc: Qianqian Xie <xieqianqian@huawei.com>
Cc: Philippe Reynes <tremyfr@gmail.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Christian Gromm <christian.gromm@microchip.com>
Cc: Andrey Shvetsov <andrey.shvetsov@k2l.de>
Cc: Jason Litzinger <jlitzingerdev@gmail.com>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

set_memory_* functions have moved to set_memory.h.  Switch to this
explicitly.

[akpm@linux-foundation.org: track drivers/gpu/drm/i915/i915_gem_gtt.c linux-next changes]
Link: http://lkml.kernel.org/r/1488920133-27229-8-git-send-email-labbott@redhat.comSigned-off-by: NLaura Abbott <labbott@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

__vmalloc* allows users to provide gfp flags for the underlying
allocation.  This API is quite popular

  $ git grep "=[[:space:]]__vmalloc\|return[[:space:]]*__vmalloc" | wc -l
  77

The only problem is that many people are not aware that they really want
to give __GFP_HIGHMEM along with other flags because there is really no
reason to consume precious lowmemory on CONFIG_HIGHMEM systems for pages
which are mapped to the kernel vmalloc space.  About half of users don't
use this flag, though.  This signals that we make the API unnecessarily
too complex.

This patch simply uses __GFP_HIGHMEM implicitly when allocating pages to
be mapped to the vmalloc space.  Current users which add __GFP_HIGHMEM
are simplified and drop the flag.

Link: http://lkml.kernel.org/r/20170307141020.29107-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
Reviewed-by: NMatthew Wilcox <mawilcox@microsoft.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: Cristopher Lameter <cl@linux.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There are many code paths opencoding kvmalloc.  Let's use the helper
instead.  The main difference to kvmalloc is that those users are
usually not considering all the aspects of the memory allocator.  E.g.
allocation requests <= 32kB (with 4kB pages) are basically never failing
and invoke OOM killer to satisfy the allocation.  This sounds too
disruptive for something that has a reasonable fallback - the vmalloc.
On the other hand those requests might fallback to vmalloc even when the
memory allocator would succeed after several more reclaim/compaction
attempts previously.  There is no guarantee something like that happens
though.

This patch converts many of those places to kv[mz]alloc* helpers because
they are more conservative.

Link: http://lkml.kernel.org/r/20170306103327.2766-2-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> # Xen bits
Acked-by: NKees Cook <keescook@chromium.org>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Acked-by: Andreas Dilger <andreas.dilger@intel.com> # Lustre
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> # KVM/s390
Acked-by: Dan Williams <dan.j.williams@intel.com> # nvdim
Acked-by: David Sterba <dsterba@suse.com> # btrfs
Acked-by: Ilya Dryomov <idryomov@gmail.com> # Ceph
Acked-by: Tariq Toukan <tariqt@mellanox.com> # mlx4
Acked-by: Leon Romanovsky <leonro@mellanox.com> # mlx5
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Cc: Santosh Raspatur <santosh@chelsio.com>
Cc: Hariprasad S <hariprasad@chelsio.com>
Cc: Yishai Hadas <yishaih@mellanox.com>
Cc: Oleg Drokin <oleg.drokin@intel.com>
Cc: "Yan, Zheng" <zyan@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We are going to add more parameters to find_vqs, let's wrap the call so
we don't need to tweak all drivers every time.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.

Add a quirk to get the full 10 bpc.

Cc: stable@vger.kernel.org
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1492787108-23959-1-git-send-email-mario.kleiner.de@gmail.com

A missing u64 cast causes a 32-Bit wraparound from
4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected
if card has 4096 Mib per FBP.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The error return code PTR_ERR(mc) is always 0 since mc is
equal to 0 in this error handling case.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

So far we only allowed for 1 retry and just failed the query
- and thereby high precision vblank timestamping - if we did
not get a reasonable result, as such a failure wasn't considered
all too horrible. There are a few NVidia gpu models out there which
may need a bit more than 1 retry to get a successful query result
under some conditions.

Since Linux 4.4 the update code for vblank counter and timestamp
in drm_update_vblank_count() changed so that the implementation
assumes that high precision vblank timestamping of a kms driver
either consistently succeeds or consistently fails for a given
video mode and encoder/connector combo. Iow. switching from success
to fail or vice versa on a modeset or connector change is ok, but
spurious temporary failure for a given setup can confuse the core
code and potentially cause bad miscounting of vblanks and confusion
or hangs in userspace clients which rely on vblank  stuff, e.g.,
desktop compositors.

Therefore change the max retry count to a larger number - more than
any gpu so far is known to need to succeed, but still low enough
so that these queries which do also happen in vblank interrupt are
still fast enough to be not disastrously long if something would
go badly wrong with them.

As such sporadic retries only happen seldom even on affected gpu's,
this could mean a vblank irq could take a few dozen microseconds
longer every few hours of uptime -- better than a desktop compositor
randomly hanging every couple of hours or days of uptime in a hard
to reproduce manner.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes OOB VBIOS accesses on some boards.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>

On 32-bit machines, we can't divide 64-bit integers:

drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check':
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to `__aeabi_uldivmod'
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined reference to `__aeabi_uldivmod'

This calls the div_u64 function explicitly instead.

Fixes: 4cea4e9f6690 ("drm: mali-dp: Add plane upscaling support")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.

In fact, without checking for a completed request we may try to use the
signaler after it has been retired and its dependency tree freed:

[   60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
[   60.044118] Read of size 8 by task gem_exec_fence/530
[   60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G            E   4.11.0-rc7+ #46
[   60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
[   60.044290] Call Trace:
[   60.044337]  dump_stack+0x4d/0x6a
[   60.044383]  kasan_object_err+0x21/0x70
[   60.044435]  kasan_report+0x225/0x4e0
[   60.044488]  ? __list_add_valid+0x1d/0xd0
[   60.044534]  ? kasan_kmalloc+0xad/0xe0
[   60.044587]  __asan_load8+0x5e/0x70
[   60.044639]  __list_add_valid+0x1d/0xd0
[   60.044788]  __i915_priotree_add_dependency+0x67/0x130 [i915]
[   60.044895]  i915_gem_request_await_request+0xa8/0x370 [i915]
[   60.044974]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[   60.045049]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[   60.045077]  ? save_stack+0xb1/0xd0
[   60.045105]  ? save_stack_trace+0x1b/0x20
[   60.045132]  ? save_stack+0x46/0xd0
[   60.045158]  ? kasan_kmalloc+0xad/0xe0
[   60.045184]  ? __kmalloc+0xd8/0x670
[   60.045229]  ? drm_ioctl+0x359/0x640 [drm]
[   60.045256]  ? SyS_ioctl+0x41/0x70
[   60.045330]  ? i915_vma_move_to_active+0x540/0x540 [i915]
[   60.045360]  ? tty_insert_flip_string_flags+0xa1/0xf0
[   60.045387]  ? tty_flip_buffer_push+0x63/0x70
[   60.045414]  ? remove_wait_queue+0xa9/0xc0
[   60.045441]  ? kasan_unpoison_shadow+0x35/0x50
[   60.045467]  ? kasan_kmalloc+0xad/0xe0
[   60.045494]  ? kasan_check_write+0x14/0x20
[   60.045568]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[   60.045616]  drm_ioctl+0x359/0x640 [drm]
[   60.045705]  ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
[   60.045751]  ? drm_version+0x150/0x150 [drm]
[   60.045778]  ? compat_start_thread+0x60/0x60
[   60.045805]  ? plist_del+0xda/0x1a0
[   60.045833]  do_vfs_ioctl+0x12e/0x910
[   60.045860]  ? ioctl_preallocate+0x130/0x130
[   60.045886]  ? pci_mmcfg_check_reserved+0xc0/0xc0
[   60.045913]  ? vfs_write+0x196/0x240
[   60.045939]  ? __fget_light+0xa7/0xc0
[   60.045965]  SyS_ioctl+0x41/0x70
[   60.045991]  entry_SYSCALL_64_fastpath+0x17/0x98
[   60.046017] RIP: 0033:0x7feb2baefc47
[   60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[   60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
[   60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
[   60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
[   60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
[   60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
[   60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
[   60.046225] Allocated:
[   60.046246] PID = 530
[   60.046269]  save_stack_trace+0x1b/0x20
[   60.046292]  save_stack+0x46/0xd0
[   60.046318]  kasan_kmalloc+0xad/0xe0
[   60.046343]  kasan_slab_alloc+0x12/0x20
[   60.046368]  kmem_cache_alloc+0xab/0x650
[   60.046445]  i915_gem_request_await_request+0x88/0x370 [i915]
[   60.046559]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[   60.046705]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[   60.046849]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[   60.046936]  drm_ioctl+0x359/0x640 [drm]
[   60.046987]  do_vfs_ioctl+0x12e/0x910
[   60.047038]  SyS_ioctl+0x41/0x70
[   60.047090]  entry_SYSCALL_64_fastpath+0x17/0x98
[   60.047139] Freed:
[   60.047179] PID = 530
[   60.047223]  save_stack_trace+0x1b/0x20
[   60.047269]  save_stack+0x46/0xd0
[   60.047317]  kasan_slab_free+0x72/0xc0
[   60.047366]  kmem_cache_free+0x39/0x160
[   60.047512]  i915_gem_request_retire+0x83f/0x930 [i915]
[   60.047657]  i915_gem_request_alloc+0x166/0x600 [i915]
[   60.047799]  i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
[   60.047897]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[   60.047942]  drm_ioctl+0x359/0x640 [drm]
[   60.047968]  do_vfs_ioctl+0x12e/0x910
[   60.047993]  SyS_ioctl+0x41/0x70
[   60.048019]  entry_SYSCALL_64_fastpath+0x17/0x98
[   60.048044] Memory state around the buggy address:
[   60.048066]  ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[   60.048105]  ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[   60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[   60.048170]                                ^
[   60.048191]  ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[   60.048225]  ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc

Note to hit the use-after-free requires us to be passed back a request
via a fence-array, that is from explicit fencing accumulated into a
sync-file fence-array.

Fixes: 52e54209 ("drm/i915/scheduler: Record all dependencies upon request construction")
Testcase: igt/gem_exec_fence/expired-history
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
(cherry picked from commit ade0b0c9)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The busy-spin, as the first stage of intel_wait_for_register(), is
currently under suspicion for causing:

[   62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[   62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper prime_numbers
[   62.034932] CPU: 1 PID: 183 Comm: kworker/1:2 Not tainted 4.11.0-rc7+ #471
[   62.034933] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[   62.034934] Workqueue: pm pm_runtime_work
[   62.034936] task: ffff880275a04ec0 task.stack: ffffc900002d8000
[   62.034936] RIP: 0010:__intel_wait_for_register_fw+0x77/0x1a0 [i915]
[   62.034937] RSP: 0018:ffffc900002dbc38 EFLAGS: 00000082
[   62.034939] RAX: ffffc90003530094 RBX: 0000000000130094 RCX: 0000000000000001
[   62.034940] RDX: 00000000000000a1 RSI: ffff88027fd15e58 RDI: 0000000000000000
[   62.034941] RBP: ffffc900002dbc78 R08: 0000000000000002 R09: 0000000000000000
[   62.034942] R10: ffffc900002dbc18 R11: ffff880276429dd0 R12: ffff8802707c0000
[   62.034943] R13: 00000000000000a0 R14: 0000000000000000 R15: 00000000fffefc10
[   62.034945] FS:  0000000000000000(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000
[   62.034945] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   62.034947] CR2: 00007ffd3cd98ff8 CR3: 0000000274c19000 CR4: 00000000001006e0
[   62.034947] Call Trace:
[   62.034948]  intel_wait_for_register+0x77/0x140 [i915]
[   62.034949]  vlv_suspend_complete+0x23/0x5b0 [i915]
[   62.034950]  intel_runtime_suspend+0x16c/0x2a0 [i915]
[   62.034950]  pci_pm_runtime_suspend+0x50/0x180
[   62.034951]  ? pci_pm_runtime_resume+0xa0/0xa0
[   62.034952]  __rpm_callback+0xc5/0x210
[   62.034953]  rpm_callback+0x1f/0x80
[   62.034953]  ? pci_pm_runtime_resume+0xa0/0xa0
[   62.034954]  rpm_suspend+0x118/0x580
[   62.034955]  pm_runtime_work+0x64/0x90
[   62.034956]  process_one_work+0x1bb/0x3e0
[   62.034956]  worker_thread+0x46/0x4f0
[   62.034957]  ? __schedule+0x18b/0x610
[   62.034958]  kthread+0xff/0x140
[   62.034958]  ? process_one_work+0x3e0/0x3e0
[   62.034959]  ? kthread_create_on_node+

and related hard lockups in CI for byt and bsw.

Note this effectively reverts commits 41ce405e and b2736695
("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")

v2: Convert bool allow into a u32 mask for clarity and repeat the
comment on vlv rc6 timing to justify the 3ms timeout used for the wait (Ville)

Fixes: 41ce405e ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
Fixes: b2736695 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100718Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.ukTested-by: NTomi Sarvela <tomi.p.sarvela@intel.com>
(cherry picked from commit 3dd14c04)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Avoid having too large a stack by creating the fake struct inode/file on
the heap instead.

drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free':
drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
Reported-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 66d9cb5d ("drm/i915: Mock the GEM device for self-testing")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170419094143.16922-2-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 2310b3c9)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Previously with commit a9c1f90c
("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain,
seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed
to be unmasked for IVB and SNB in order to prevent system hang
with chained batchbuffers.

Our CI was seeing incomplete results with tests that used
chained batches and it was found out that HSW needs to have this
same bit unmasked to reliably survive chained batches.

Always unmask GEN6_PM_RP_UP_EI_EXPIRED on Haswell to
prevent system hang with batch chaining.

Testcase: igt/gem_exec_fence/nb-await-default
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100672
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1492082127-29007-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 3396a273)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

i915_gem_request_alloc() uses error pointers.  It never returns NULLs.

Fixes: 0daf0113 ("drm/i915: Mock infrastructure for request emission")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwandaReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit be02f755)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore that piece of information and do the retrain
unconditionally. We do of course still check whether the link is
supposed to be running or not.

To actually get read out the EDID and update things properly we
also need to nuke the goto out added by commit 7d23e3c3
("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure
why that was there. Perhaps to avoid an EDID read if the connector
status didn't appear to change, but that sort of thing is quite racy
and would have failed anyway if we failed to keep up with the
hotplugs (if we missed the HPD down in between two HPD ups). And
now that we take this codepath unconditionally we definitely need
to drop the goto as otherwise we would never do the EDID read.

v2: Drop the goto that made us skip EDID reads entirely. Doh!
v3: Rebase due to locking changes
    s/apparely/apparently/ in the comment (Chris)

Cc: stable@vger.kernel.org
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Reported-by: NPalmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.htmlSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
(cherry picked from commit 1a36147b)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr ffff8801f7788358
[31908.547297] Read of size 8 by task drv_selftest/3781
[31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: G    BU  W       4.10.0+ #451
[31908.547553] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[31908.547682] Call Trace:
[31908.547772]  dump_stack+0x68/0x9f
[31908.547857]  kasan_object_err+0x1c/0x70
[31908.547947]  kasan_report_error+0x1f1/0x4f0
[31908.548038]  ? kfree+0xaa/0x170
[31908.548121]  kasan_report+0x34/0x40
[31908.548211]  ? klist_children_get+0x20/0x30
[31908.548472]  ? intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.548567]  __asan_load8+0x5e/0x70
[31908.548824]  intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.549080]  intel_audio_deinit+0x28/0x80 [i915]
[31908.549315]  i915_driver_unload+0xe4/0x360 [i915]
[31908.549551]  ? i915_driver_load+0x1d70/0x1d70 [i915]
[31908.549651]  ? trace_hardirqs_on+0xd/0x10
[31908.549885]  i915_pci_remove+0x23/0x30 [i915]
[31908.549978]  pci_device_remove+0x5c/0x100
[31908.550069]  device_release_driver_internal+0x1db/0x2e0
[31908.550165]  driver_detach+0x68/0xc0
[31908.550256]  bus_remove_driver+0x8b/0x150
[31908.550346]  driver_unregister+0x3e/0x60
[31908.550439]  pci_unregister_driver+0x1d/0x110
[31908.550531]  ? find_module_all+0x7a/0xa0
[31908.550791]  i915_exit+0x1a/0x87 [i915]
[31908.550881]  SyS_delete_module+0x264/0x2c0
[31908.550971]  ? free_module+0x430/0x430
[31908.551064]  ? trace_hardirqs_off_caller+0x16/0x110
[31908.551159]  ? trace_hardirqs_on_caller+0x16/0x280
[31908.551256]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[31908.551350]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.551440] RIP: 0033:0x7f1d67312ec7
[31908.551520] RSP: 002b:00007ffebe34e888 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[31908.551650] RAX: ffffffffffffffda RBX: ffffffff811123f6 RCX: 00007f1d67312ec7
[31908.551743] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000560d0af476b8
[31908.551837] RBP: ffff880233d87f98 R08: 0000000000000000 R09: 00007ffebe34e8b8
[31908.551930] R10: 00007f1d68adf8c0 R11: 0000000000000206 R12: 0000000000000000
[31908.552023] R13: 0000560d0af46440 R14: 0000000000000034 R15: 00007ffebe34d860
[31908.552121]  ? trace_hardirqs_off_caller+0x16/0x110
[31908.552217] Object at ffff8801f7788000, in cache kmalloc-2048 size: 2048
[31908.552306] Allocated:
[31908.552377] PID = 3781
[31908.552456]  save_stack_trace+0x16/0x20
[31908.552539]  kasan_kmalloc+0xee/0x190
[31908.552627]  __kmalloc+0xdb/0x1b0
[31908.552713]  platform_device_alloc+0x27/0x90
[31908.552804]  platform_device_register_full+0x36/0x220
[31908.553066]  intel_lpe_audio_init+0x41e/0x570 [i915]
[31908.553320]  intel_audio_init+0xd/0x40 [i915]
[31908.553552]  i915_driver_load+0x13f5/0x1d70 [i915]
[31908.553788]  i915_pci_probe+0x65/0xe0 [i915]
[31908.553881]  pci_device_probe+0xda/0x140
[31908.553969]  driver_probe_device+0x400/0x660
[31908.554058]  __driver_attach+0x11c/0x120
[31908.554147]  bus_for_each_dev+0xe6/0x150
[31908.554237]  driver_attach+0x26/0x30
[31908.554325]  bus_add_driver+0x26b/0x3b0
[31908.554412]  driver_register+0xce/0x190
[31908.554502]  __pci_register_driver+0xaf/0xc0
[31908.554589]  0xffffffffa0550063
[31908.554675]  do_one_initcall+0x8b/0x1e0
[31908.554764]  do_init_module+0x102/0x325
[31908.554852]  load_module+0x3aad/0x45e0
[31908.554944]  SyS_finit_module+0x169/0x1a0
[31908.555033]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.555119] Freed:
[31908.555188] PID = 3781
[31908.555266]  save_stack_trace+0x16/0x20
[31908.555349]  kasan_slab_free+0xb0/0x180
[31908.555436]  kfree+0xaa/0x170
[31908.555520]  platform_device_release+0x76/0x80
[31908.555610]  device_release+0x45/0xe0
[31908.555698]  kobject_put+0x11f/0x260
[31908.555785]  put_device+0x12/0x20
[31908.555871]  platform_device_unregister+0x1b/0x20
[31908.556135]  intel_lpe_audio_teardown+0x5c/0xb0 [i915]
[31908.556390]  intel_audio_deinit+0x28/0x80 [i915]
[31908.556622]  i915_driver_unload+0xe4/0x360 [i915]
[31908.556858]  i915_pci_remove+0x23/0x30 [i915]
[31908.556948]  pci_device_remove+0x5c/0x100
[31908.557037]  device_release_driver_internal+0x1db/0x2e0
[31908.557129]  driver_detach+0x68/0xc0
[31908.557217]  bus_remove_driver+0x8b/0x150
[31908.557304]  driver_unregister+0x3e/0x60
[31908.557394]  pci_unregister_driver+0x1d/0x110
[31908.557653]  i915_exit+0x1a/0x87 [i915]
[31908.557741]  SyS_delete_module+0x264/0x2c0
[31908.557834]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.557919] Memory state around the buggy address:
[31908.558005]  ffff8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558127]  ffff8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558255] >ffff8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558374]                                                     ^
[31908.558467]  ffff8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558595]  ffff8801f7788400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

v2: Just leak the memory (8 bytes) as freeing it ourselves is not safe,
and we need to coordinate a proper fix in platform_device itself.

Fixes: eef57324 ("drm/i915: setup bridge for HDMI LPE audio driver")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99952Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Jerome Anand <jerome.anand@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412080251.30648-1-chris@chris-wilson.co.ukReviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 48ae8074)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Many sightings report the greater prevalence of allocation failures.
This is all due to the incorrect use of mapping_gfp_constraint(), so
remove it in favour of just querying the mapping_gfp_mask() which are
the exact gfp_t we wanted in the first place.

We still do expect a higher chance of reporting ENOMEM, as that is the
intention of using __GFP_NORETRY -- to fail rather than oom after having
reclaimed from our bo caches, and having done a direct|kswapd reclaim
pass.
Reported-by: NJason Ekstrand <jason.ekstrand@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100594
Fixes: 24f8e00a ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170405221514.23251-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit b268d9fe)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We're clearing the legacy_cursor_update flag before calling
drm_atomic_helper_setup_commit() which means the helper will
wait for the flip to complete before cleaning up the framebuffers.
That's not what we want for the legacy cursor, so let's clear
the flag after setting up the commit.

Also toss in a FIXME about solving these problems in a nicer
way using the fabled vblank workers.

v2: Also unsync with legacy page flips

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
Cc: Rafael Ristovski <rafael.ristovski@gmail.com>
Fixes: a5509abd ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170329142123.5923-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit 89520304)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If the engine is continually completing nops, we can saturate the
signaler and keep it working indefinitely. This angers the NMI watchdog!

A good example is to disable semaphores on snb and run igt/gem_exec_nop -
the parallel, multi-engine workloads are more than sufficient to hog the
CPU, preventing the system from even processing ICMP echo replies.

v2: Tvrtko dug into cond_resched() on x86 and found that it only
depended upon preempt_count and not tif_need_resched() - which means
that we would always call schedule() at that point.

Fixes: c81d4613 ("drm/i915: Convert trace-irq to the breadcrumb waiter")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170404120531.10737-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit a7980a64)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If the signal to park arrives before we sleep, then we need to check
kthread_should_park() before sleeping to avoid missing the signal.
Otherwise, if the signal arrives whilst we are processing completed
requests, we will reset the current->state back to TASK_INTERRUPTIBLE
and so miss the wakeup.

Fixes: fe3288b5 ("drm/i915: Park the breadcrumbs signaler across a GPU reset")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403105124.8969-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit b1becb88)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When downscaling, mclk needs to be sufficiently higher than pxlclk in
order to be able to fetch the higher-resolution data and produce output
pixels. When not scaling, or when upscaling, mclk can be equal to
pxlclk. Since the driver doesn't control mclk, just ensure that the
requirement is satisfied with the current clock rate.
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

Apply image enhacement when we are upscaling by a factor of 2
or more in either direction.
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

Enable the scaling engine for upscaling a single plane using the polyphase
scaler. No image enhancement support or downscaling yet*, and composition
result scaling is not implemented.

* Downscaling a plane requires mclk > pxlclk.
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

Add a core_id file in the driver's sysfs directory,
exposing the hardware CORE ID. This is useful to allow
userspace to discover the hardware version used.
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

All DPs have a COLORADJ matrix which is applied prior to output gamma.
Attach that to the CTM property. Also, ensure the input CTM's coefficients
can fit in the DP registers' Q3.12 format.
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC
properties. The expected LUT size is 4096 in order
to produce as accurate a set of segments as possible.

This version uses only the green channel's gamma curve
to set the hardware curve on DP550/650. For the sake of
simplicity, it uses the same table of coefficients for
all 3 curves on DP500.
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>

Add a custom CRTC state struct to enable storing driver's private
state. This patch only adds the base drm_crtc_state struct and
the atomic functions that handle it.
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

Now that we are using a custom plane state in mali-dp, we need a
bespoke reset that takes into account the larger structure.
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
[Updated commit message]
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

The newly introduced function causes a harmless build warning:

drivers/gpu/drm/arm/malidp_planes.c: In function 'malidp_plane_atomic_print_state':
drivers/gpu/drm/arm/malidp_planes.c:98:23: error: unused variable 'mp' [-Werror=unused-variable]

The variable serves no purpose here and can be removed.

Fixes: 242f43b69c61 ("drm: mali-dp: add atomic_print_state for planes")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

Add function to dump the state of the plane.
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

Enable runtime and system Power Management. Clocks are now managed
from malidp_crtc_{enable,disable} functions. Suspend-to-RAM tested
as working on Juno.
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

Mali DP needs to have all the planes that are becoming inactive in the
new state disabled before re-enabling the active CRTC, otherwise we
start streaming out data from old pointers in memory.
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

Change "S_IRUSR | S_IWUSR" to "0600", it's easier to parse mentally.

This change should be part of commit 50f83737 ("drm/vmwgfx: Revert
"drm/vmwgfx: Replace numeric parameter like 0444 with macro""), but the
patch was truncated somewhere in the patch route, so add the missing
change. Extract from the original commit message:

  commit 50f83737
  Author: Øyvind A. Holm <sunny@sunbase.org>
  Date:   Thu Mar 23 14:54:48 2017 -0700

    drm/vmwgfx: Revert "drm/vmwgfx: Replace numeric parameter like 0444
    with macro"

    This reverts commit 2d8e60e8 ("drm/vmwgfx: Replace numeric
    parameter like 0444 with macro")

    The commit belongs to the series of 1285 patches sent to LKML on
    2016-08-02, it changes the representation of file permissions from
    the octal value "0600" to "S_IRUSR | S_IWUSR".

    The general consensus was that the changes does not increase
    readability, quite the opposite; 0600 is easier to parse mentally
    than S_IRUSR | S_IWUSR.
Signed-off-by: NØyvind A. Holm <sunny@sunbase.org>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Few parts of kernel define their own macro for aligning down so provide
a common define for this, with the same usage and assumptions as existing
ALIGN.

Convert also three existing implementations to this one.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.htmlSigned-off-by: NLogan Gunthorpe <logang@deltatee.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1492630570-879-1-git-send-email-logang@deltatee.com

A group of Linux kernel hackers reported chasing a bug that resulted
from their assumption that SLAB_DESTROY_BY_RCU provided an existence
guarantee, that is, that no block from such a slab would be reallocated
during an RCU read-side critical section.  Of course, that is not the
case.  Instead, SLAB_DESTROY_BY_RCU only prevents freeing of an entire
slab of blocks.

However, there is a phrase for this, namely "type safety".  This commit
therefore renames SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU in order
to avoid future instances of this sort of confusion.
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
[ paulmck: Add comments mentioning the old name, as requested by Eric
  Dumazet, in order to help people familiar with the old name find
  the new one. ]
Acked-by: NDavid Rientjes <rientjes@google.com>

It's not possible for endpoint to be zero so the test doesn't work.  If
we break on the first iteration through the loop then endpoint is 1 and
"ret" is uninitialized.

Fixes: ebc94461 ("drm: convert drivers to use drm_of_find_panel_or_bridge")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170415192142.GA6416@mwanda