<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-op-linux/drivers, branch v4.12.5</title>
<subtitle>Talos™ II Linux sources for OpenPOWER</subtitle>
<id>https://git.raptorcs.com/git/talos-op-linux/atom?h=v4.12.5</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-op-linux/atom?h=v4.12.5'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/'/>
<updated>2017-08-06T16:21:11+00:00</updated>
<entry>
<title>mmc: tmio-mmc: fix bad pointer math</title>
<updated>2017-08-06T16:21:11+00:00</updated>
<author>
<name>Chris Brandt</name>
<email>chris.brandt@renesas.com</email>
</author>
<published>2017-07-12T15:40:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=b5dd7985e8d3357ff9537c0be231190ab1a131fe'/>
<id>urn:sha1:b5dd7985e8d3357ff9537c0be231190ab1a131fe</id>
<content type='text'>
commit 9c284c41c0886f09e75c323a16278b6d353b0b4a upstream.

The existing code gives an incorrect pointer value.
The buffer pointer 'buf' was of type unsigned short *, and 'count' was a
number in bytes. A cast of buf should have been used.

However, instead of casting, just change the code to use u32 pointers.

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Fixes: 8185e51f358a: ("mmc: tmio-mmc: add support for 32bit data port")
Signed-off-by: Chris Brandt &lt;chris.brandt@renesas.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Acked-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>ipmi/watchdog: fix watchdog timeout set on reboot</title>
<updated>2017-08-06T16:21:10+00:00</updated>
<author>
<name>Valentin Vidic</name>
<email>Valentin.Vidic@CARNet.hr</email>
</author>
<published>2017-05-05T19:07:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=fe57e31e40ae044d74dca595f1cdb9310ad982d7'/>
<id>urn:sha1:fe57e31e40ae044d74dca595f1cdb9310ad982d7</id>
<content type='text'>
commit 860f01e96981a68553f3ca49f574ff14fe955e72 upstream.

systemd by default starts watchdog on reboot and sets the timer to
ShutdownWatchdogSec=10min.  Reboot handler in ipmi_watchdog than reduces
the timer to 120s which is not enough time to boot a Xen machine with
a lot of RAM.  As a result the machine is rebooted the second time
during the long run of (XEN) Scrubbing Free RAM.....

Fix this by setting the timer to 120s only if it was previously
set to a low value.

Signed-off-by: Valentin Vidic &lt;Valentin.Vidic@CARNet.hr&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>isdn/i4l: fix buffer overflow</title>
<updated>2017-08-06T16:21:10+00:00</updated>
<author>
<name>Annie Cherkaev</name>
<email>annie.cherk@gmail.com</email>
</author>
<published>2017-07-15T21:08:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=cd043db87e4c49fa909a81c0daa2a3786dacf349'/>
<id>urn:sha1:cd043db87e4c49fa909a81c0daa2a3786dacf349</id>
<content type='text'>
commit 9f5af546e6acc30f075828cb58c7f09665033967 upstream.

This fixes a potential buffer overflow in isdn_net.c caused by an
unbounded strcpy.

[ ISDN seems to be effectively unmaintained, and the I4L driver in
  particular is long deprecated, but in case somebody uses this..
    - Linus ]

Signed-off-by: Jiten Thakkar &lt;jitenmt@gmail.com&gt;
Signed-off-by: Annie Cherkaev &lt;annie.cherk@gmail.com&gt;
Cc: Karsten Keil &lt;isdn@linux-pingi.de&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Fix scaler init during CRTC HW state readout</title>
<updated>2017-08-06T16:21:10+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2017-07-20T11:28:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=9ec2ee3a972d58f808dfadad92ba1b3617740a9f'/>
<id>urn:sha1:9ec2ee3a972d58f808dfadad92ba1b3617740a9f</id>
<content type='text'>
commit 283d6860d64f5091565bf729b0a6d6af14ae6c27 upstream.

The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even if the crtc is off. This fixes at least an initial YUV420 modeset
(added in a follow-up patchset by Shashank) when booting with the screen
off: after the initial HW readout and modeset which enables the scaler a
subsequent modeset will disable the scaler which isn't properly
allocated. This results in a funky HW state where the pipe scaler HW
registers can't be modified and the normally black screen is grey and
shifted to the right or jitters.

The problem was revealed by Shashank's YUV420 patchset and first
reported by Ville.

v2:
- In the stable tag also include versions which need backporting (Jani)

Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Cc: Shashank Sharma &lt;shashank.sharma@intel.com&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: Chandra Konduru &lt;chandra.konduru@intel.com&gt;
Cc: Matt Roper &lt;matthew.d.roper@intel.com&gt;
Reported-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Mahesh Kumar &lt;mahesh1.kumar@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20170720112820.26816-1-imre.deak@intel.com
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
(cherry picked from commit 5fb9dadf336f3590c799e8cbde348215dccc2aa2)
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/nouveau/bar/gf100: fix access to upper half of BAR2</title>
<updated>2017-08-06T16:21:10+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2017-07-25T01:06:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=7a4337a68743a77bc60d7828bd5ed4cd0b416ba6'/>
<id>urn:sha1:7a4337a68743a77bc60d7828bd5ed4cd0b416ba6</id>
<content type='text'>
commit 38bcb208f60924a031b9f809f7cd252ea4a94e5f upstream.

Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
mapped over the end of VRAM, even when the rest of the BAR has been set
to virtual mode.

We inherited our initial value from RM, but I'm not aware of any reason
we need to keep it that way.

This fixes severe GPU hang/lockup issues revealed by Wayland on F26.

Shout-out to NVIDIA for the quick response with the potential cause!

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/nouveau/disp/nv50-: bump max chans to 21</title>
<updated>2017-08-06T16:21:10+00:00</updated>
<author>
<name>Ilia Mirkin</name>
<email>imirkin@alum.mit.edu</email>
</author>
<published>2017-06-28T12:24:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=3de4f5de00a0a0351e61d477ec33afc4cca711f7'/>
<id>urn:sha1:3de4f5de00a0a0351e61d477ec33afc4cca711f7</id>
<content type='text'>
commit a90e049cacd965dade4dae7263b4d3fd550e78b6 upstream.

GP102's cursors go from chan 17..20. Increase the array size to hold
their data properly.

Fixes: e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices")
Signed-off-by: Ilia Mirkin &lt;imirkin@alum.mit.edu&gt;
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/vmwgfx: Limit max desktop dimensions to 8Kx8K</title>
<updated>2017-08-06T16:21:10+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2017-07-17T14:49:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=631c3a0a71b43e3d9dd99b15444c3533ed218192'/>
<id>urn:sha1:631c3a0a71b43e3d9dd99b15444c3533ed218192</id>
<content type='text'>
commit 7b009e76797c82178d7a03ae0eaad5951d975277 upstream.

This was originally chosen to be an arbitrarily large number.  However,
some user mode may actually try to set a 16Kx16K mode and run into other
issues.

Since 8Kx8K is the current texture limit for Mesa LLVM driver, we will
just use this limit for now.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Brian Paul &lt;brianp@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix gcc-7.1.1 warning</title>
<updated>2017-08-06T16:21:09+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2017-07-18T06:28:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=555ac1e5516124dc4c180f059054998a8c9469ff'/>
<id>urn:sha1:555ac1e5516124dc4c180f059054998a8c9469ff</id>
<content type='text'>
commit fcfffdd8f98ac305285dca568b5065ef86be6458 upstream.

The current code does not look correct, and the reason for it is
probably lost.  Since this now generates a compiler warning,
fix it to what makes sense.

Reported-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reported-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Brian Paul &lt;brianp@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>md/raid5: add thread_group worker async_tx_issue_pending_all</title>
<updated>2017-08-06T16:21:09+00:00</updated>
<author>
<name>Ofer Heifetz</name>
<email>oferh@marvell.com</email>
</author>
<published>2017-07-24T06:17:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=9425c1fdc48d3a05ea332b19454cc690faec3ee8'/>
<id>urn:sha1:9425c1fdc48d3a05ea332b19454cc690faec3ee8</id>
<content type='text'>
commit 7e96d559634b73a8158ee99a7abece2eacec2668 upstream.

Since thread_group worker and raid5d kthread are not in sync, if
worker writes stripe before raid5d then requests will be waiting
for issue_pendig.

Issue observed when building raid5 with ext4, in some build runs
jbd2 would get hung and requests were waiting in the HW engine
waiting to be issued.

Fix this by adding a call to async_tx_issue_pending_all in the
raid5_do_work.

Signed-off-by: Ofer Heifetz &lt;oferh@marvell.com&gt;
Signed-off-by: Shaohua Li &lt;shli@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>md/raid1: fix writebehind bio clone</title>
<updated>2017-08-06T16:21:09+00:00</updated>
<author>
<name>Shaohua Li</name>
<email>shli@fb.com</email>
</author>
<published>2017-07-17T21:33:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=270c1bc38fc531662bddd64a835f4afd83a9562d'/>
<id>urn:sha1:270c1bc38fc531662bddd64a835f4afd83a9562d</id>
<content type='text'>
commit 16d56e2fcc1fc15b981369653c3b41d7ff0b443d upstream.

After bio is submitted, we should not clone it as its bi_iter might be
invalid by driver. This is the case of behind_master_bio. In certain
situration, we could dispatch behind_master_bio immediately for the
first disk and then clone it for other disks.

https://bugzilla.kernel.org/show_bug.cgi?id=196383

Reported-and-tested-by: Markus &lt;m4rkusxxl@web.de&gt;
Reviewed-by: Ming Lei &lt;ming.lei@redhat.com&gt;
Fix: 841c1316c7da(md: raid1: improve write behind)
Signed-off-by: Shaohua Li &lt;shli@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
