linux-stable.git/Documentation, branch linux-4.0.y

PCI: Add pci_bus_addr_t

2015-07-21T17:10:14+00:00

commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d upstream.

David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
to fit in upstream windows") fails to boot on sparc/T5-8:

pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000)

The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so
dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so
they don't fit in a dma_addr_t. d63e2e1f3df9 added new checking that
tripped over this mismatch.

Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
including both raw BAR values and DMA addresses. This will be 64 bits
on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then
dma_addr_t only needs to be wide enough to hold addresses from the DMA API.

[bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at
least as wide as dma_addr_t, documentation]
Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com
Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
Reported-by: David Ahern
Tested-by: David Ahern
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Acked-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman

spi: pl022: Specify 'num-cs' property as required in devicetree binding

2015-07-21T17:10:13+00:00

commit ea6055c46eda1e19e02209814955e13f334bbe1b upstream.

Since commit 39a6ac11df65 ("spi/pl022: Devicetree support w/o platform data")
the 'num-cs' parameter cannot be passed through platform data when probing
with devicetree. Instead, it's a required devicetree property.

Fix the binding documentation so the property is properly specified.

Fixes: 39a6ac11df65 ("spi/pl022: Devicetree support w/o platform data")
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

net: mvneta: introduce compatible string "marvell, armada-xp-neta"

2015-07-10T16:45:37+00:00

[ Upstream commit f522a975a8101895a85354b9c143f41b8248e71a ]

The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
380 and 385 SoCs. Since at least one more hardware feature is available
for the Armada XP SoCs then a way to identify them is needed.

This patch introduces a new compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot 
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Cc:  # v3.8+
Acked-by: Gregory CLEMENT 
Acked-by: Thomas Petazzoni 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

pty: Fix input race when closing

2015-06-06T15:21:01+00:00

commit 1a48632ffed61352a7810ce089dc5a8bcd505a60 upstream.

A read() from a pty master may mistakenly indicate EOF (errno == -EIO)
after the pty slave has closed, even though input data remains to be read.
For example,

       pty slave       |        input worker        |    pty master
                       |                            |
                       |                            |   n_tty_read()
pty_write()            |                            |     input avail? no
  add data             |                            |     sleep
  schedule worker  --->|                            |     .
                       |---> flush_to_ldisc()       |     .
pty_close()            |       fill read buffer     |     .
  wait for worker      |       wakeup reader    --->|     .
                       |       read buffer full?    |---> input avail ? yes
                       |<---   yes - exit worker    |     copy 4096 bytes to user
  TTY_OTHER_CLOSED <---|                            |<--- kick worker
                       |                            |

		                **** New read() before worker starts ****

                       |                            |   n_tty_read()
                       |                            |     input avail? no
                       |                            |     TTY_OTHER_CLOSED? yes
                       |                            |     return -EIO

Several conditions are required to trigger this race:
1. the ldisc read buffer must become full so the input worker exits
2. the read() count parameter must be >= 4096 so the ldisc read buffer
   is empty
3. the subsequent read() occurs before the kicked worker has processed
   more input

However, the underlying cause of the race is that data is pipelined, while
tty state is not; ie., data already written by the pty slave end is not
yet visible to the pty master end, but state changes by the pty slave end
are visible to the pty master end immediately.

Pipeline the TTY_OTHER_CLOSED state through input worker to the reader.
1. Introduce TTY_OTHER_DONE which is set by the input worker when
   TTY_OTHER_CLOSED is set and either the input buffers are flushed or
   input processing has completed. Readers/polls are woken when
   TTY_OTHER_DONE is set.
2. Reader/poll checks TTY_OTHER_DONE instead of TTY_OTHER_CLOSED.
3. A new input worker is started from pty_close() after setting
   TTY_OTHER_CLOSED, which ensures the TTY_OTHER_DONE state will be
   set if the last input worker is already finished (or just about to
   exit).

Remove tty_flush_to_ldisc(); no in-tree callers.

Fixes: 52bce7f8d4fc ("pty, n_tty: Simplify input processing on final close")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96311
BugLink: http://bugs.launchpad.net/bugs/1429756
Reported-by: Andy Whitcroft 
Reported-by: H.J. Lu 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

hwmon: (tmp401) Do not auto-detect chip on I2C address 0x37

2015-06-06T15:20:55+00:00

commit 9aecac04d8d89e730ae362a748113b19c06a9d39 upstream.

I2C address 0x37 may be used by EEPROMs, which can result in false
positives. Do not attempt to detect a chip at this address.

Reviewed-by: Jean Delvare 
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

KVM: MMU: fix SMAP virtualization

2015-06-06T15:20:48+00:00

commit 0be0226f07d14b153a5eedf2bb86e1eb7dcefab5 upstream.

KVM may turn a user page to a kernel page when kernel writes a readonly
user page if CR0.WP = 1. This shadow page entry will be reused after
SMAP is enabled so that kernel is allowed to access this user page

Fix it by setting SMAP && !CR0.WP into shadow page's role and reset mmu
once CR4.SMAP is updated

Signed-off-by: Xiao Guangrong 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: imx28: Fix AUART4 TX-DMA interrupt name

2015-05-17T16:55:08+00:00

commit 4ada77e37a773168fea484899201e272ab44ba8b upstream.

Fix a typo in the TX DMA interrupt name for AUART4.
This patch makes AUART4 operational again.

Signed-off-by: Marek Vasut 
Fixes: f30fb03d4d3a ("ARM: dts: add generic DMA device tree binding for mxs-dma")
Acked-by: Stefan Wahren 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

uas: Add US_FL_MAX_SECTORS_240 flag

2015-05-13T12:14:28+00:00

commit ee136af4a064c2f61e2025873584d2c7ec93f4ae upstream.

The usb-storage driver sets max_sectors = 240 in its scsi-host template,
for uas we do not want to do that for all devices, but testing has shown
that some devices need it.

This commit adds a US_FL_MAX_SECTORS_240 flag for such devices, and
implements support for it in uas.c, while at it it also adds support
for US_FL_MAX_SECTORS_64 to uas.c.

Signed-off-by: Hans de Goede 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

KVM: s390: fix get_all_floating_irqs

2015-05-06T20:03:39+00:00

commit 94aa033efcac47b09db22cb561e135baf37b7887 upstream.

This fixes a bug introduced with commit c05c4186bbe4 ("KVM: s390:
add floating irq controller").

get_all_floating_irqs() does copy_to_user() while holding
a spin lock. Let's fix this by filling a temporary buffer
first and copy it to userspace after giving up the lock.

Reviewed-by: David Hildenbrand 
Signed-off-by: Jens Freimann 
Signed-off-by: Christian Borntraeger 
Acked-by: Cornelia Huck 
Signed-off-by: Greg Kroah-Hartman

net: rfs: fix crash in get_rps_cpus()

2015-05-06T20:03:35+00:00

[ Upstream commit a31196b07f8034eba6a3487a1ad1bb5ec5cd58a5 ]

Commit 567e4b79731c ("net: rfs: add hash collision detection") had one
mistake :

RPS_NO_CPU is no longer the marker for invalid cpu in set_rps_cpu()
and get_rps_cpu(), as @next_cpu was the result of an AND with
rps_cpu_mask

This bug showed up on a host with 72 cpus :
next_cpu was 0x7f, and the code was trying to access percpu data of an
non existent cpu.

In a follow up patch, we might get rid of compares against nr_cpu_ids,
if we init the tables with 0. This is silly to test for a very unlikely
condition that exists only shortly after table initialization, as
we got rid of rps_reset_sock_flow() and similar functions that were
writing this RPS_NO_CPU magic value at flow dismantle : When table is
old enough, it never contains this value anymore.

Fixes: 567e4b79731c ("net: rfs: add hash collision detection")
Signed-off-by: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman