linux-toradex.git/drivers, branch v4.4.136

drm/i915: Disable LVDS on Radiant P845

2018-06-06T14:46:23+00:00

commit b3fb22733ae61050f8d10a1d6a8af176c5c5db1a upstream.

Radiant P845 does not have LVDS, only VGA.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468
Signed-off-by: Ondrej Zary 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20180309222204.4771-1-linux@rainbow-software.org
(cherry picked from commit 7f7105f99b75aca4f8c2a748ed6b82c7f8be3293)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman

hwtracing: stm: fix build error on some arches

2018-06-06T14:46:23+00:00

commit 806e30873f0e74d9d41b0ef761bd4d3e55c7d510 upstream.

Commit b5e2ced9bf81 ("stm class: Use vmalloc for the master map") caused
a build error on some arches as vmalloc.h was not explicitly included.

Fix that by adding it to the list of includes.

Fixes: b5e2ced9bf81 ("stm class: Use vmalloc for the master map")
Reported-by: kbuild test robot 
Cc: Alexander Shishkin 
Signed-off-by: Greg Kroah-Hartman

stm class: Use vmalloc for the master map

2018-06-06T14:46:23+00:00

commit b5e2ced9bf81393034072dd4d372f6b430bc1f0a upstream.

Fengguang is running into a warning from the buddy allocator:

> swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc1 #262
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> Call Trace:
...
>  __kmalloc+0x14b/0x180: ____cache_alloc at mm/slab.c:3127
>  stm_register_device+0xf3/0x5c0: stm_register_device at drivers/hwtracing/stm/core.c:695
...

Which is basically a result of the stm class trying to allocate ~512kB
for the dummy_stm with its default parameters. There's no reason, however,
for it not to be vmalloc()ed instead, which is what this patch does.

Reported-by: Fengguang Wu 
Signed-off-by: Alexander Shishkin 
CC: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman

scsi: scsi_transport_srp: Fix shost to rport translation

2018-06-06T14:46:23+00:00

commit c9ddf73476ff4fffb7a87bd5107a0705bf2cf64b upstream.

Since an SRP remote port is attached as a child to shost->shost_gendev
and as the only child, the translation from the shost pointer into an
rport pointer must happen by looking up the shost child that is an
rport. This patch fixes the following KASAN complaint:

BUG: KASAN: slab-out-of-bounds in srp_timed_out+0x57/0x110 [scsi_transport_srp]
Read of size 4 at addr ffff880035d3fcc0 by task kworker/1:0H/19

CPU: 1 PID: 19 Comm: kworker/1:0H Not tainted 4.16.0-rc3-dbg+ #1
Workqueue: kblockd blk_mq_timeout_work
Call Trace:
dump_stack+0x85/0xc7
print_address_description+0x65/0x270
kasan_report+0x231/0x350
srp_timed_out+0x57/0x110 [scsi_transport_srp]
scsi_times_out+0xc7/0x3f0 [scsi_mod]
blk_mq_terminate_expired+0xc2/0x140
bt_iter+0xbc/0xd0
blk_mq_queue_tag_busy_iter+0x1c7/0x350
blk_mq_timeout_work+0x325/0x3f0
process_one_work+0x441/0xa50
worker_thread+0x76/0x6c0
kthread+0x1b2/0x1d0
ret_from_fork+0x24/0x30

Fixes: e68ca75200fe ("scsi_transport_srp: Reduce failover time")
Signed-off-by: Bart Van Assche 
Cc: Hannes Reinecke 
Cc: Johannes Thumshirn 
Cc: Jason Gunthorpe 
Cc: Doug Ledford 
Cc: Laurence Oberman 
Cc: stable@vger.kernel.org
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

iio:kfifo_buf: check for uint overflow

2018-06-06T14:46:22+00:00

commit 3d13de4b027d5f6276c0f9d3a264f518747d83f2 upstream.

Currently, the following causes a kernel OOPS in memcpy:

echo 1073741825 > buffer/length
echo 1 > buffer/enable

Note that using 1073741824 instead of 1073741825 causes "write error:
Cannot allocate memory" but no OOPS.

This is because 1073741824 == 2^30 and 1073741825 == 2^30+1. Since kfifo
rounds up to the nearest power of 2, it will actually call kmalloc with
roundup_pow_of_two(length) * bytes_per_datum.

Using length == 1073741825 and bytes_per_datum == 2, we get:

kmalloc(roundup_pow_of_two(1073741825) * 2
or kmalloc(2147483648 * 2)
or kmalloc(4294967296)
or kmalloc(UINT_MAX + 1)

so this overflows to 0, causing kmalloc to return ZERO_SIZE_PTR and
subsequent memcpy to fail once the device is enabled.

Fix this by checking for overflow prior to allocating a kfifo. With this
check added, the above code returns -EINVAL when enabling the buffer,
rather than causing an OOPS.

Signed-off-by: Martin Kelly 
cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

dmaengine: usb-dmac: fix endless loop in usb_dmac_chan_terminate_all()

2018-06-06T14:46:22+00:00

commit d9f5efade2cfd729138a7cafb46d01044da40f5e upstream.

This patch fixes an issue that list_for_each_entry() in
usb_dmac_chan_terminate_all() is possible to cause endless loop because
this will move own desc to the desc_freed. So, this driver should use
list_for_each_entry_safe() instead of list_for_each_entry().

Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Vinod Koul 
Signed-off-by: Biju Das 
Signed-off-by: Greg Kroah-Hartman

i2c: rcar: revoke START request early

2018-06-06T14:46:22+00:00

commit 52df445f29b79006d8b2dcd129152987c0d3bd64 upstream.

If we don't clear START generation as soon as possible, it may cause
another message to be generated, e.g. when receiving NACK in address
phase. To keep the race window as small as possible, we clear it right
at the beginning of the interrupt. We don't need any checks since we
always want to stop START and STOP generation on the next occasion after
we started it.

This patch improves the situation but sadly does not completely fix it.
It is still to be researched if we can do better given this HW design.

Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
Signed-off-by: Greg Kroah-Hartman

i2c: rcar: check master irqs before slave irqs

2018-06-06T14:46:22+00:00

commit c3be0af15959e11fa535d5332ab3d7cf34abd09b upstream.

Due to the HW design, master IRQs are timing critical, so give them
precedence over slave IRQ.

Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
Signed-off-by: Greg Kroah-Hartman

i2c: rcar: don't issue stop when HW does it automatically

2018-06-06T14:46:22+00:00

commit d89667b14f9d13b684287f6189ca209af5feee43 upstream.

The manual says (55.4.8.6) that HW does automatically send STOP after
NACK was received. My measuerments confirm that.

Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
Signed-off-by: Greg Kroah-Hartman

i2c: rcar: init new messages in irq

2018-06-06T14:46:22+00:00

commit cc21d0b4b62e41e5013d763adade5ea4462c33a4 upstream.

Setting up new messages was done in process context while handling a
message was in interrupt context. Because of the HW design, this IP core
is sensitive to timing, so the context switches were too expensive. Move
this setup to interrupt context as well.

In my test setup, this fixed the occasional 'data byte sent twice' issue
which a number of people have seen. It also fixes to send REP_START
after a read message which was wrongly send as a STOP + START sequence
before.

Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Fabrizio Castro 
Reviewed-by: Chris Paterson 
Signed-off-by: Greg Kroah-Hartman