KVM: MMU: fix validation of mmio page fault

commit 6f691251c0350ac52a007c54bf3ef62e9d8cdc5e upstream.

We got the bug that qemu complained with "KVM: unknown exit, hardware
reason 31" and KVM shown these info:
[84245.284948] EPT: Misconfiguration.
[84245.285056] EPT: GPA: 0xfeda848
[84245.285154] ept_misconfig_inspect_spte: spte 0x5eaef50107 level 4
[84245.285344] ept_misconfig_inspect_spte: spte 0x5f5fadc107 level 3
[84245.285532] ept_misconfig_inspect_spte: spte 0x5141d18107 level 2
[84245.285723] ept_misconfig_inspect_spte: spte 0x52e40dad77 level 1

This is because we got a mmio #PF and the handler see the mmio spte becomes
normal (points to the ram page)

However, this is valid after introducing fast mmio spte invalidation which
increases the generation-number instead of zapping mmio sptes, a example
is as follows:
1. QEMU drops mmio region by adding a new memslot
2. invalidate all mmio sptes
3.

        VCPU 0                        VCPU 1
    access the invalid mmio spte
                            access the region originally was MMIO before
                            set the spte to the normal ram map

    mmio #PF
    check the spte and see it becomes normal ram mapping !!!

This patch fixes the bug just by dropping the check in mmio handler, it's
good for backport. Full check will be introduced in later patches

Reported-by: Pavel Shirshov <ru.pchel@gmail.com>
Tested-by: Pavel Shirshov <ru.pchel@gmail.com>
Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: cp2112: fix I2C_SMBUS_BYTE write

commit 6d00d153f00097d259f86304e11858a50a1b8ad1 upstream.

When doing an I2C_SMBUS_BYTE write (one byte write, no address),
the data to be written is in "command" not "data->byte".

Signed-off-by: Ellen Wang <ellen@cumulusnetworks.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: cp2112: fix byte order in SMBUS operations

commit 29e2d6d1f6f61ba2b5cc9d9867e01d8c31a6c4f7 upstream.

Change all occurrences of be16 to le16 in cp2112_xfer(),
because SMBUS words are little endian, not big endian.

Signed-off-by: Ellen Wang <ellen@cumulusnetworks.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_error

commit 3af4e5a95184d6d3c1c6a065f163faa174a96a1d upstream.

It was reported that after 10-20 reboots, a usb keyboard plugged
into a docking station would not work unless it was replugged in.

Using usbmon, it turns out the interrupt URBs were streaming with
callback errors of -71 for some reason.  The hid-core.c::hid_io_error was
supposed to retry and then reset, but the reset wasn't really happening.

The check for HID_NO_BANDWIDTH was inverted.  Fix was simple.

Tested by reporter and locally by me by unplugging a keyboard halfway until I
could recreate a stream of errors but no disconnect.

Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: ghash-clmulni: specify context size for ghash async algorithm

commit 71c6da846be478a61556717ef1ee1cea91f5d6a8 upstream.

Currently context size (cra_ctxsize) doesn't specified for
ghash_async_alg. Which means it's zero. Thus crypto_create_tfm()
doesn't allocate needed space for ghash_async_ctx, so any
read/write to ctx (e.g. in ghash_async_init_tfm()) is not valid.

Signed-off-by: Andrey Ryabinin <aryabinin@odin.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: vmx - Fixing GHASH Key issue on little endian

commit 3c5f0ed78e976be705218cad62acf6a68e9d121e upstream.

GHASH table algorithm is using a big endian key.
In little endian machines key will be LE ordered.
After a lxvd2x instruction key is loaded as it is,
LE/BE order, in first case it'll generate a wrong
table resulting in wrong hashes from the algorithm.

Bug affects only LE machines.
In order to fix it we do a swap for loaded key.

Signed-off-by: Leonidas S Barbosa <leosilva@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: samsung: fix DMA for FIFO smaller than cache line size

commit 736cd79f483fd7a1e0b71e6eaddf01d8d87fbbbb upstream.

So far DMA mode were activated when only number of bytes to send was
equal or greater than min_dma_size. Due to requirement that DMA transaction
buffer should be aligned to cache line size, the excessive bytes were
written to FIFO before starting DMA transaction. The problem occurred
when FIFO size were smaller than cache alignment, because writing all
excessive bytes to FIFO would fail. It happened in DMA mode when PIO
interrupts disabled, which caused driver hung.

The solution is to test if buffer is alligned to cache line size before
activating DMA mode, and if it's not, running PIO mode to align buffer
and then starting DMA transaction. In PIO mode, when interrupts are
enabled, lack of space in FIFO isn't the problem, so buffer aligning
will always finish with success.

Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: samsung: fix DMA mode enter condition for small FIFO sizes

commit 81ccb2a69f76b88295a1da9fc9484df715fe3bfa upstream.

Due to some of serial ports can have FIFO size smaller than cache line
size, and because of need to align DMA buffer address to cache line size,
it's necessary to calculate minimum number of bytes for which we want
to start DMA transaction to be at least cache line size. The simplest
way to meet this requirement is to get maximum of cache line size and
FIFO size.

Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250_pci: Add support for Pericom PI7C9X795[1248]

commit 89c043a6cb2d4525d48a38ed78d5f0f5672338b3 upstream.

Pericom PI7C9X795[1248] are Uno/Dual/Quad/Octal UART devices, this
patch enables them, also defines PCI_VENDOR_ID_PERICOM here.

Signed-off-by: Adam Lee <adam.lee@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250: bind to ALi Fast Infrared Controller (ALI5123)

commit 1d7002777a8fe8188caaa98d4a8eb4ed298fcdae upstream.

This way this device can be used with irtty-sir -
at least on Toshiba Satellite A20-S103 it is not configured by default
and needs PNP activation before it starts to respond on I/O ports.

This device has actually its own driver (ali-ircc),
but this driver seems to be non-functional for a very long time
(see http://permalink.gmane.org/gmane.linux.irda.general/484
http://permalink.gmane.org/gmane.network.protocols.obex.openobex.user/943
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535070 ).

Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250: don't bind to SMSC IrCC IR port

commit ffa34de03bcfbfa88d8352942bc238bb48e94e2d upstream.

SMSC IrCC SIR/FIR port should not be bound to by
(legacy) serial driver so its own driver (smsc-ircc2)
can bind to it.

Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: arizona: Poll for FLL clock OK rather than use interrupts

commit 0e7659712836ca59b4735bc5cc94de38698a5e01 upstream.

The extcon driver takes the DAPM mutex from within the interrupt thread
in several places, which makes it possible to get into a situation where
the interrupt thread is blocked waiting on the DAPM mutex whilst a DAPM
sequence is running which is attempting to configure the FLL. In this
case the FLL completion can't be completed as as the IRQ handler is
ONE_SHOT, which cause the FLL lock to use the full time out (250mS) and
report that the process timed out.

It is not really practical to make the extcon driver not take the DAPM
mutex from within the interrupt thread, at least not without extensive
modification. So this patch fixes the issue by switching the wait for
the FLL lock to polling. A few fast polls are done first as the FLL
should lock quickly for a good quality reference clock, (indeed it hits
on the first poll on my system) and it will poll every 20mS after that
until it times out.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: arizona: Fix gain settings of FLL in free-run mode

commit 1cf5a330c05ae37a0a98ac7c9800a6f50d5579ec upstream.

The wrong register was used to set the gain of ref loop, when changing
the FLL output on an active FLL. This patch corrects the offset of the
gain register.

Signed-off-by: Nikesh Oswal <Nikesh.Oswal@wolfsonmicro.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: adav80x: Remove .read_flag_mask setting from adav80x_regmap_config

commit 9d8352864907f0ad76124c5b28f65b5a382d7d7c upstream.

Don't set .read_flag_mask for adav803, it's for adav801 only.

Fixes: 0c2d69645628 ("ASoC: adav80x: Split SPI and I2C code into different modules")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: samsung: Remove redundant arndale_audio_remove

commit 14a500fe1396934c6b3ed8f009459a4723da7862 upstream.

There is no use of snd_soc_unregister_card in remove function
as devm_snd_soc_register_card in probe function automatically
handles it. So, remove use of snd_soc_unregister_card and with
this change remove arndale_audio_remove as it is now redundant.

Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: rt5640: fix line out no sound issue

commit 9b850ca4f1c5acd7fcbbd4b38a2d27132801a8d5 upstream.

The power for line out was not turned on when line out is enabled.
So we add "LOUT amp" widget to turn on the power for line out.

Signed-off-by: John Lin <john.lin@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: serial: men_z135_uart.c: Fix race between IRQ and set_termios()

commit 8117e347406278fd399b077add4e638cd017ae2d upstream.

Fix panic caused by a race between men_z135_intr() and men_z135_set_termios().

men_z135_intr() and men_z135_set_termios() both hold the struct uart_port::lock
spinlock, but men_z135_intr() does a spin_lock_irqsave() and
men_z135_set_termios() does a normal spin_lock(), which can lead to a deadlock
when an interrupt is called while the lock is being helt by
men_z135_set_termios().

This was discovered using a insmod, hardware looppback send/receive, rmmod
stress test.

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Cc: Andreas Werner <andreas.werner@men.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: host: ehci-sys: delete useless bus_to_hcd conversion

commit 0521cfd06e1ebcd575e7ae36aab068b38df23850 upstream.

The ehci platform device's drvdata is the pointer of struct usb_hcd
already, so we doesn't need to call bus_to_hcd conversion again.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth

commit 913e4a90b6f9687ac0f543e7b632753e4f51c441 upstream.

According to USB Audio Device 2.0 Spec, Ch4.10.1.1:
wMaxPacketSize is defined as follows:
Maximum packet size this endpoint is capable of sending or receiving
when this configuration is selected.
This is determined by the audio bandwidth constraints of the endpoint.

In current code, the wMaxPacketSize is defined as the maximum packet size
for ISO endpoint, and it will let the host reserve much more space than
it really needs, so that we can't let more endpoints work together at
one frame.

We find this issue when we try to let 4 f_uac2 gadgets work together [1]
at FS connection.

[1]http://www.spinics.net/lists/linux-usb/msg123478.html

Acked-by: Daniel Mack <zonque@gmail.com>
Cc: andrzej.p@samsung.com
Cc: Daniel Mack <zonque@gmail.com>
Cc: tiwai@suse.de
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes

commit b2fb5b1a0f50d3ebc12342c8d8dead245e9c9d4e upstream.

DWC3 uses bounce buffer to handle non max packet aligned OUT transfers and
the size of bounce buffer is 512 bytes. However if the host initiates OUT
transfers of size more than 512 bytes (and non max packet aligned), the
driver throws a WARN dump but still programs the TRB to receive more than
512 bytes. This will cause bounce buffer to overflow and corrupt the
adjacent memory locations which can be fatal.

Fix it by programming the TRB to receive a maximum of DWC3_EP0_BOUNCE_SIZE
(512) bytes.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

doc: usb: gadget-testing: using the updated testusb.c

commit f811a38300be3cdb603171aea5ad3fb42b71ca53 upstream.

testusb.c at http://www.linux-usb.org/usbtest/ is out of date,
using the one at the kernel source folder.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: m66592-udc: forever loop in set_feature()

commit 5feb5d2003499b1094d898c010a7604d7afddc4c upstream.

There is an "&&" vs "||" typo here so this loops 3000 times or if we get
unlucky it could loop forever.

Fixes: ceaa0a6eeadf ('usb: gadget: m66592-udc: add support for TEST_MODE')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xfs: Fix file type directory corruption for btree directories

commit 037542345a82aaaa228ec280fe6ddff1568d169f upstream.

Users have occasionally reported that file type for some directory
entries is wrong. This mostly happened after updating libraries some
libraries. After some debugging the problem was traced down to
xfs_dir2_node_replace(). The function uses args->filetype as a file type
to store in the replaced directory entry however it also calls
xfs_da3_node_lookup_int() which will store file type of the current
directory entry in args->filetype. Thus we fail to change file type of a
directory entry to a proper type.

Fix the problem by storing new file type in a local variable before
calling xfs_da3_node_lookup_int().

Reported-by: Giacomo Comes <comes@naic.edu>
Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xfs: Fix xfs_attr_leafblock definition

commit ffeecc5213024ae663377b442eedcfbacf6d0c5d upstream.

struct xfs_attr_leafblock contains 'entries' array which is declared
with size 1 altough it can in fact contain much more entries. Since this
array is followed by further struct members, gcc (at least in version
4.8.3) thinks that the array has the fixed size of 1 element and thus
may optimize away all accesses beyond the end of array resulting in
non-working code. This problem was only observed with userspace code in
xfsprogs, however it's better to be safe in kernel as well and have
matching kernel and xfsprogs definitions.

Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

libxfs: readahead of dir3 data blocks should use the read verifier

commit 2f123bce18943fff819bc10f8868ffb9149fc622 upstream.

In the dir3 data block readahead function, use the regular read
verifier to check the block's CRC and spot-check the block contents
instead of directly calling only the spot-checking routine.  This
prevents corrupted directory data blocks from being read into the
kernel, which can lead to garbage ls output and directory loops (if
say one of the entries contains slashes and other junk).

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: pl2303: fix baud-rate divisor calculations

commit 49bda21266fdf195142e8b5dea057f09e96ada9f upstream.

This commit fixes the following issues:

1. The 9th bit of buf was believed to be the LSB of divisor's
exponent, but the hardware interprets it as MSB (9th bit) of the
mantissa. The exponent is actually one bit shorter and applies
to base 4, not 2 as previously believed.

2. Loop iterations doubled the exponent instead of incrementing.

3. The exponent wasn't checked for overflow.

4. The function returned requested rate instead of actual rate.

Due to issue #2, the old code deviated from the wrong formula
described in #1 and actually yielded correct rates when divisor
was lower than 4096 by using exponents of 0, 2 or 4 base-2,
interpreted as 0, 1, 2 base-4 with the 9th mantissa bit clear.
However, at 93.75 kbaud or less the rate turned out too slow
due to #2 or too fast due to #2 and #3.

I tested this patch by sending and validating 0x00,0x01,..,0xff
to an FTDI dongle at 234, 987, 2401, 9601, 31415, 115199, 250k,
500k, 750k, 1M, 1.5M, 3M+1 baud. All rates passed.

I also used pv to check speed at some rates unsupported by FTDI:
45 (the lowest possible), 2M, 4M, 5M and 6M-1. Looked sane.

Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Fixes: 399aa9a75ad3 ("USB: pl2303: use divisors for unsupported baud
rates")
[johan: update summary ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: ftdi_sio: Added custom PID for CustomWare products

commit 1fb8dc36384ae1140ee6ccc470de74397606a9d5 upstream.

CustomWare uses the FTDI VID with custom PIDs for their ShipModul MiniPlex
products.

Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module

commit 44840dec6127e4d7c5074f75d2dd96bc4ab85fe3 upstream.

This is an HP-branded Sierra Wireless EM7355:
https://bugzilla.redhat.com/show_bug.cgi?id=1223646#c2

Signed-off-by: David Ward <david.ward@ll.mit.edu>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: symbolserial: Use usb_get_serial_port_data

commit 951d3793bbfc0a441d791d820183aa3085c83ea9 upstream.

The driver used usb_get_serial_data(port->serial) which compiled but resulted
in a NULL pointer being returned (and subsequently used). I did not go deeper
into this but I guess this is a regression.

Signed-off-by: Philipp Hachtmann <hachti@hachti.de>
Fixes: a85796ee5149 ("USB: symbolserial: move private-data allocation to
port_probe")
Acked-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: dw: Allow interface drivers to limit data I/O to word sizes

commit c4fe57f76269dbb2af135071513f260ca40229a3 upstream.

The commit dd11444327ce ("spi: dw-spi: Convert 16bit accesses to 32bit
accesses") changed all 16bit accesses in the DW_apb_ssi driver to 32bit.
This, unfortunately, breaks data register access on picoXcell, where the
DW IP needs data register accesses to be word accesses (all other
accesses appear to be OK).

This change introduces a new master variable to allow interface drivers
to specify that 16bit data transfer I/O is required.  This change also
introduces the ability to set this variable via device tree bindings in
the MMIO interface driver.  Both the core and the MMIO interface driver
default to the current 32bit behaviour.

Before this change, on a picoXcell pc3x3:
 spi_master spi32766: interrupt_transfer: fifo overrun/underrun
 m25p80 spi32766.0: error -5 reading 9f
 m25p80: probe of spi32766.0 failed with error -5

After this change:
 m25p80 spi32766.0: m25p40 (512 Kbytes)

Fixes: dd11444327ce ("spi: dw-spi: Convert 16bit accesses to 32bit accesses")
Signed-off-by: Michael van der Westhuizen <michael@smart-africa.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: img-spfi: fix kbuild test robot warning

commit 9176c6657b5c313cf504d157e6d91496ee5c8708 upstream.

drivers/spi/spi-img-spfi.c: In function 'img_spfi_setup':
drivers/spi/spi-img-spfi.c:446: warning: 'ret' may be used
uninitialized in this function.

Fixes: commit b03ba9e314c1 ("spi: img-spfi: fix multiple calls to request gpio")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: img-spfi: fix multiple calls to request gpio

commit b03ba9e314c12b2127243145b5c1f41b2408de62 upstream.

spfi_setup may be called many times by the spi framework, but
gpio_request_one can only be called once without freeing, repeatedly
calling gpio_request_one will cause an error to be thrown, which
causes the request to spi_setup to be marked as failed.

We can have a per-spi_device flag that indicates whether or not the
gpio has been requested. If the gpio has already been requested use
gpio_direction_output to set the direction of the gpio.

Fixes: 8c2c8c03cdcb ("spi: img-spfi: Control CS lines with GPIO")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: img-spfi: check for timeout error before proceeding

commit 011710e2ab659c7ad6e5e554806414bd7a9508be upstream.

Calling spfi_wait_all_done is not required if the transfer has timed
out before all data is transferred.

spfi_wait_all_done polls for Alldone interrupt which is triggered to
mark the transfer as complete and to indicate it is now safe to issue
a new transfer.

Fixes: 8c2c8c0 ("spi: img-spfi: Control CS lines with GPIO")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: sh-msiof: Fix FIFO size to 64 word from 256 word

commit fe78d0b7691c02744004b15f6979b3f106464bc4 upstream.

The upper limit of Tx/Rx FIFO size is 64 word by the
specification of H/W. This patch corrects to 64 word from 256 word.

Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: Fix regression in spi-bitbang-txrx.h

commit 26a67ec47a4c58fe79c6421c3dc3d697d322d2d6 upstream.

This patch fixes a regression introduced by commit 232a5adc5199 ("spi:
bitbang: only toggle bitchanges"). The attempt to optimize writes of
consecutive bit patterns broke most of the combinations of word size
and SPI modes due to selecting the wrong bit as the MSB value.

Fixes: 232a5adc5199 (spi: bitbang: only toggle bitchanges)
Signed-off-by: Lars Persson <larper@axis.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: bcm2835: set up spi-mode before asserting cs-gpio

commit acace73df2c1913a526c1b41e4741a4a6704c863 upstream.

When using reverse polarity for clock (spi-cpol) on a device
the clock line gets altered after chip-select has been asserted
resulting in an additional clock beat, which confuses hardware.

This did not show when using native-CS, as the same register
is used to control cs as well as polarity, so the changes came
into effect at the same time. Unfortunately this is not true
with gpio-cs.

To avoid this situation this patch moves the setup of polarity
(spi-cpol and spi-cpha) outside of the chip-select into
prepare_message, which is run prior to asserting chip-select.

Also fixes resetting 3-wire mode after use of rx-mode, so that
a 3-Wire sequence TX, RX, TX works as well (right now it runs
TX, RX, RX instead)

Reported-by: Noralf Tronnes <noralf@tronnes.org>
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: Disable async suspend/resume for JMicron multi-function SATA/AHCI

commit 91f15fb30c77d4a0d0d9b97e5cec647650853145 upstream.

On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
function 1 doesn't work if it is powered on before the SATA controller at
function 0.  The result is that PATA doesn't work after resume, and we
print messages like this:

  pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
  irq 17: nobody cared (try booting with the "irqpoll" option)

Async resume was introduced in v3.15 by 76569faa62c4 ("PM / sleep:
Asynchronous threads for resume_noirq").  Prior to that, we powered on
the functions in order, so this problem shouldn't happen.

e6b7e41cdd8c ("ata: Disabling the async PM for JMicron chip 363/361")
solved the problem for JMicron 361 and 363 devices.  With async suspend
disabled, we always power on function 0 before function 1.

Barto then reported the same problem with a JMicron 368 (see comment #57 in
the bugzilla).

Rather than extending the blacklist piecemeal, disable async suspend for
all JMicron multi-function SATA/PATA/AHCI devices.

This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
the problem will occur even if pata_jmicron isn't loaded until after the
suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
power-on order even if the drivers aren't loaded.

[bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551
Reported-and-tested-by: Barto <mister.freeman@laposte.net>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: Add VPD function 0 quirk for Intel Ethernet devices

commit 7aa6ca4d39edf01f997b9e02cf6d2fdeb224f351 upstream.

Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device
functions other than function 0, so that on multi-function devices, we will
always read VPD from function 0 instead of from the other functions.

[bhelgaas: changelog]
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: Add dev_flags bit to access VPD through function 0

commit 932c435caba8a2ce473a91753bad0173269ef334 upstream.

Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through
function 0 to provide VPD access on other functions.  This is for hardware
devices that provide copies of the same VPD capability registers in
multiple functions.  Because the kernel expects that each function has its
own registers, both the locking and the state tracking are affected by VPD
accesses to different functions.

On such devices for example, if a VPD write is performed on function 0,
*any* later attempt to read VPD from any other function of that device will
hang.  This has to do with how the kernel tracks the expected value of the
F bit per function.

Concurrent accesses to different functions of the same device can not only
hang but also corrupt both read and write VPD data.

When hangs occur, typically the error message:

  vpd r/w failed.  This is likely a firmware bug on this device.

will be seen.

Never set this bit on function 0 or there will be an infinite recursion.

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: Fix TI816X class code quirk

commit d1541dc977d376406f4584d8eb055488655c98ec upstream.

In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO".
But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class
and needs to be shifted to make space for the low-order interface byte.

Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code.

Fixes: 63c4408074cb ("PCI: Add quirk for setting valid class for TI816X Endpoint")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: qcom: Fix MSM8916 prng clock enable bit

commit 1c4b4b0eb1909010b8ebda1ef208bf3ed62e7487 upstream.

Fix the enable bit of the pseudorandom number generator clock.

Reported-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Fixes: 3966fab8b6ab "clk: qcom: Add MSM8916 Global Clock Controller support"
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: qcom: Set CLK_SET_RATE_PARENT on ce1 clocks

commit d7a304e9d018c99dda80f4c16ec0fe817b5be4a1 upstream.

The other ce clocks have the flag set, but ce1 doesn't, so
clk_set_rate() doesn't propagate up the tree to the ce1_src_clk.
Set the flag as this is supported.

Reported-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Tested-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Fixes: 02824653200b ("clk: qcom: Add APQ8084 Global Clock Controller support")
Fixes: d33faa9ead8d ("clk: qcom: Add support for MSM8974's global clock controller (GCC)")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: pxa: fix core frequency reporting unit

commit 4b5fb7dc9096d949a22651370bb6bf11f21edb30 upstream.

Legacy drivers which are not yet ported, such as cpufreq-pxa[23]xx, rely
on pxaXXx_get_clk_frequency_khz() to find the CPU core frequency.

This reporting was broken because the expected unit is kHz and not
Hz. Fix the reporting for pxa25x, pxa27x and pxa3xx.

Fixes: fe7710fae477 ("clk: add pxa25x clock drivers")
Fixes: d40670dc6169 ("clk: add pxa27x clock drivers")
Fixes: 9bbb8a338fb2 ("clk: pxa: add pxa3xx clock driver")
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: versatile: off by one in clk_sp810_timerclken_of_get()

commit 3294bee87091be5f179474f6c39d1d87769635e2 upstream.

The ">" should be ">=" or we end up reading beyond the end of the array.

Fixes: 6e973d2c4385 ('clk: vexpress: Add separate SP810 driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: pistachio: correct critical clock list

commit d31ff5f7f3b142b8d1ebb3da89187c54cdf2bc71 upstream.

Current critical clock list for pistachio enables
only mips and sys clocks by default but there are
also other clocks that are not claimed by anyone and
needs to be enabled by default.

This patch updates the critical clocks that need
to be enabled by default.

Add a separate struct to distinguish the critical clocks
as listed:
1.) core clocks:
a.) mips clock
2.) peripheral system clocks:
a.) sys clock
b.) sys_bus clock
c.) DDR clock
d.) ROM clock

Fixes: b35d7c33419c("CLK: Pistachio: Register core clocks")
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Signed-off-by: Damien.Horsley <Damien.Horsley@imgtec.com>
Signed-off-by: Govindraj Raja <govindraj.raja@imgtec.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: pistachio: Fix override of clk-pll settings from boot loader

commit e53f21c761d141bbcbce06e9ddab3b4e0a828f2c upstream.

PLL enable callbacks are overriding PLL mode (int/frac) and
Noise reduction (on/off) settings set by the boot loader which
results in the incorrect clock rate.

PLL mode and noise reduction are defined by the DSMPD and DACPD bits
of the PLL control register. PLL .enable() callbacks enable PLL
by deasserting all power-down bits of the PLL control register,
including DSMPD and DACPD bits, which is not necessary since
these bits don't actually enable/disable PLL.

This commit fixes the problem by removing DSMPD and DACPD bits
from the "PLL enable" mask.

Fixes: 43049b0c83f17("CLK: Pistachio: Add PLL driver")
Reviewed-by: Andrew Bresitcker <abrestic@chromium.org>
Signed-off-by: Zdenko Pulitika <zdenko.pulitika@imgtec.com>
Signed-off-by: Govindraj Raja <govindraj.raja@imgtec.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: s5pv210: add missing call to samsung_clk_of_add_provider()

commit ba30011577330b7e29ecb5916d89c6db9fbc5b3d upstream.

Commit d5e136a21b2028fb1f45143ea7112d5869bfc6c7 ("clk: samsung: Register
clk provider only after registering its all clocks", merged to v3.17-rc1)
modified a way that driver registers registers to core framework. This
change has not been applied to s5pv210 clocks driver, which has been
merged in parallel to that commit. This patch adds a missing call to
samsung_clk_of_add_provider(), so the driver is operational again.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: exynos4: Fix wrong clock for Exynos4x12 ADC

commit e323d56eb06b266b77c2b430cb5f1977ba549e03 upstream.

The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
However TSADC is present only on Exynos4210 so on Trats2 board (with
Exynos4412 SoC) the exynos-adc driver could not be probed:
   ERROR: could not get clock /adc@126C0000:adc(0)
   exynos-adc 126c0000.adc: failed getting clock, err = -2
   exynos-adc: probe of 126c0000.adc failed with error -2

Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
Converter is located in different register and it is named in datasheet
as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
is the same as purpose of TSADC from Exynos4210.

The patch adds gate clock for Exynos4x12 using the proper register so
backward compatibility is preserved. This fixes the probe of exynos-adc
driver on Exynos4x12 boards and allows accessing sensors connected to it
on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: c63c57433003 ("ARM: dts: Add ADC's dt data to read raw data for exynos4x12")
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: rockchip: rk3288: add CLK_SET_RATE_PARENT to sclk_mac

commit 4791eb61dbe8100ccac59fecfac9d93a15db1447 upstream.

The dwmac ethernet controller on the rk3288 supports phys connected
via rgmii and rmii. With rgmii phys it is expected that the mac clock
is provided externally while with rmii phys the clock can be external
but also generated from the plls. In the later case it of course needs
be at 50MHz, which gets set from the dwmac_rk driver.
As most devices use a rgmii phy it never surfaced so far that the mac
clk mux, doesn't go up one lever to the pll clock in the rmii case with
internal clock generation, as it is missing the CLK_SET_RATE_PARENT flag,
and thus will not set the correct frequency in most cases.

Fixes: b9e4ba541607 ("clk: rockchip: add clock controller for rk3288")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PM / clk: don't return int on __pm_clk_enable()

commit f4745a92781b872455f32feb01d1dce92aefcb6c upstream.

Static analysis by cppcheck found an issue that was recently introduced by
commit 471f7707b6f0b1 ("PM / clock_ops: make __pm_clk_enable more generic")
where a return status in ret was not being initialised and garbage
being returned when ce->status >= PCE_STATUS_ERROR.

The fact that ret is not being checked by the caller and that
ret is only used internally __pm_clk_enable() to check if clk_enable()
was OK means we can ignore returning it instead turn
__pm_clk_enable() into function with a void return.

Fixes: 471f7707b6f0b1 ("PM / clock_ops: make __pm_clk_enable more generic")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: comedi: usbduxsigma: don't clobber ao_timer in command test

commit c04a1f17803e0d3eeada586ca34a6b436959bc20 upstream.

`devpriv->ao_timer` is used while an asynchronous command is running on
the AO subdevice.  It also gets modified by the subdevice's `cmdtest`
handler for checking new asynchronous commands,
`usbduxsigma_ao_cmdtest()`, which is not correct as it's allowed to
check new commands while an old command is still running.  Fix it by
moving the code which sets up `devpriv->ao_timer` into the subdevice's
`cmd` handler, `usbduxsigma_ao_cmd()`.

Note that the removed code in `usbduxsigma_ao_cmdtest()` checked that
`devpriv->ao_timer` did not end up less that 1, but that could not
happen due because `cmd->scan_begin_arg` or `cmd->convert_arg` had
already been range-checked.

Also note that we tested the `high_speed` variable in the old code, but
that is currently always 0 and means that we always use "scan" timing
(`cmd->scan_begin_src == TRIG_TIMER` and `cmd->convert_src == TRIG_NOW`)
and never "convert" (individual sample) timing (`cmd->scan_begin_src ==
TRIG_FOLLOW` and `cmd->convert_src == TRIG_TIMER`).  The moved code
tests `cmd->convert_src` instead to decide whether "scan" or "convert"
timing is being used, although currently only "scan" timing is
supported.

Fixes: fb1ef622e7a3 ("staging: comedi: usbduxsigma: tidy up analog output command support")
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: Bernd Porr <mail@berndporr.me.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: comedi: usbduxsigma: don't clobber ai_timer in command test

commit 423b24c37dd5794a674c74b0ed56392003a69891 upstream.

`devpriv->ai_timer` is used while an asynchronous command is running on
the AI subdevice.  It also gets modified by the subdevice's `cmdtest`
handler for checking new asynchronous commands
(`usbduxsigma_ai_cmdtest()`), which is not correct as it's allowed to
check new commands while an old command is still running.  Fix it by
moving the code which sets up `devpriv->ai_timer` and
`devpriv->ai_interval` into the subdevice's `cmd` handler,
`usbduxsigma_ai_cmd()`.

Note that the removed code in `usbduxsigma_ai_cmdtest()` checked that
`devpriv->ai_timer` did not end up less than than 1, but that could not
happen because `cmd->scan_begin_arg` had already been checked to be at
least the minimum required value (at least when `cmd->scan_begin_src ==
TRIG_TIMER`, which had also been checked to be the case).

Fixes: b986be8527c7 ("staging: comedi: usbduxsigma: tidy up analog input command support)
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: Bernd Porr <mail@berndporr.me.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: comedi: adl_pci7x3x: fix digital output on PCI-7230

commit ad83dbd974feb2e2a8cc071a1d28782bd4d2c70e upstream.

The "adl_pci7x3x" driver replaced the "adl_pci7230" and "adl_pci7432"
drivers in commits 8f567c373c4b ("staging: comedi: new adl_pci7x3x
driver") and 657f77d173d3 ("staging: comedi: remove adl_pci7230 and
adl_pci7432 drivers").  Although the new driver code agrees with the
user manuals for the respective boards, digital outputs stopped working
on the PCI-7230.  This has 16 digital output channels and the previous
adl_pci7230 driver shifted the 16 bit output state left by 16 bits
before writing to the hardware register.  The new adl_pci7x3x driver
doesn't do that.  Fix it in `adl_pci7x3x_do_insn_bits()` by checking
for the special case of the subdevice having only 16 channels and
duplicating the 16 bit output state into both halves of the 32-bit
register.  That should work both for what the board actually does and
for what the user manual says it should do.

Fixes: 8f567c373c4b ("staging: comedi: new adl_pci7x3x driver")
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sched: Fix cpu_active_mask/cpu_online_mask race

commit dd9d3843755da95f63dd3a376f62b3e45c011210 upstream.

There is a race condition in SMP bootup code, which may result
in

    WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
    workqueue_cpu_up_callback()
or
    kernel BUG at kernel/smpboot.c:135!

It can be triggered with a bit of luck in Linux guests running
on busy hosts.

CPU0                        CPUn
====                        ====

_cpu_up()
  __cpu_up()
    start_secondary()
      set_cpu_online()
cpumask_set_cpu(cpu,
   to_cpumask(cpu_online_bits));
  cpu_notify(CPU_ONLINE)
    <do stuff, see below>
cpumask_set_cpu(cpu,
   to_cpumask(cpu_active_bits));

During the various CPU_ONLINE callbacks CPUn is online but not
active. Several things can go wrong at that point, depending on
the scheduling of tasks on CPU0.

Variant 1:

  cpu_notify(CPU_ONLINE)
    workqueue_cpu_up_callback()
      rebind_workers()
        set_cpus_allowed_ptr()

  This call fails because it requires an active CPU; rebind_workers()
  ends with a warning:

    WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
    workqueue_cpu_up_callback()

Variant 2:

  cpu_notify(CPU_ONLINE)
    smpboot_thread_call()
      smpboot_unpark_threads()
       ..
        __kthread_unpark()
          __kthread_bind()
          wake_up_state()
           ..
            select_task_rq()
              select_fallback_rq()

  The ->wake_cpu of the unparked thread is not allowed, making a call
  to select_fallback_rq() necessary. Then, select_fallback_rq() cannot
  find an allowed, active CPU and promptly resets the allowed CPUs, so
  that the task in question ends up on CPU0.

  When those unparked tasks are eventually executed, they run
  immediately into a BUG:

    kernel BUG at kernel/smpboot.c:135!

Just changing the order in which the online/active bits are set
(and adding some memory barriers), would solve the two issues
above. However, it would change the order of operations back to
the one before commit 6acbfb96976f ("sched: Fix hotplug vs.
set_cpus_allowed_ptr()"), thus, reintroducing that particular
problem.

Going further back into history, we have at least the following
commits touching this topic:
- commit 2baab4e90495 ("sched: Fix select_fallback_rq() vs cpu_active/cpu_online")
- commit 5fbd036b552f ("sched: Cleanup cpu_active madness")

Together, these give us the following non-working solutions:

  - secondary CPU sets active before online, because active is assumed to
    be a subset of online;

  - secondary CPU sets online before active, because the primary CPU
    assumes that an online CPU is also active;

  - secondary CPU sets online and waits for primary CPU to set active,
    because it might deadlock.

Commit 875ebe940d77 ("powerpc/smp: Wait until secondaries are
active & online") introduces an arch-specific solution to this
arch-independent problem.

Now, go for a more general solution without explicit waiting and
simply set active twice: once on the secondary CPU after online
was set and once on the primary CPU after online was seen.

set_cpus_allowed_ptr()")

Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Anton Blanchard <anton@samba.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Wilson <msw@amazon.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
Link: http://lkml.kernel.org/r/1439408156-18840-1-git-send-email-jschoenh@amazon.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adis16480: Fix scale factors

commit 7abad1063deb0f77d275c61f58863ec319c58c5c upstream.

The different devices support by the adis16480 driver have slightly
different scales for the gyroscope and accelerometer channels.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: Add inverse unit conversion macros

commit c689a923c867eac40ed3826c1d9328edea8b6bc7 upstream.

Add inverse unit conversion macro to convert from standard IIO units to
units that might be used by some devices.

Those are useful in combination with scale factors that are specified as
IIO_VAL_FRACTIONAL. Typically the denominator for those specifications will
contain the maximum raw value the sensor will generate and the numerator
the value it maps to in a specific unit. Sometimes datasheets specify those
in different units than the standard IIO units (e.g. degree/s instead of
rad/s) and so we need to do a unit conversion.

From a mathematical point of view it does not make a difference whether we
apply the unit conversion to the numerator or the inverse unit conversion
to the denominator since (x / y) / z = x / (y * z). But as the denominator
is typically a larger value and we are rounding both the numerator and
denominator to integer values using the later method gives us a better
precision (E.g. the relative error is smaller if we round 8000.3 to 8000
rather than rounding 8.3 to 8).

This is where in inverse unit conversion macros will be used.

Marked for stable as used by some upcoming fixes.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adis16400: Fix adis16448 gyroscope scale

commit 8166537283b31d7abaae9e56bd48fbbc30cdc579 upstream.

Use the correct scale for the adis16448 gyroscope output.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: industrialio-buffer: Fix iio_buffer_poll return value

commit 1bdc0293901cbea23c6dc29432e81919d4719844 upstream.

Change return value to 0 if no device is bound since
unsigned int cannot support negative error codes.

Fixes: f18e7a068 ("iio: Return -ENODEV for file operations if the
device has been unregistered")

Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: event: Remove negative error code from iio_event_poll

commit 41d903c00051d8f31c98a8136edbac67e6f8688f upstream.

Negative return values are not supported by iio_event_poll since
its return type is unsigned int.

Fixes: f18e7a068a0a3 ("iio: Return -ENODEV for file operations if the device has been unregistered")

Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: bmg160: IIO_BUFFER and IIO_TRIGGERED_BUFFER are required

commit 06d2f6ca5a38abe92f1f3a132b331eee773868c3 upstream.

This patch adds selects for IIO_BUFFER and IIO_TRIGGERED_BUFFER. Without
IIO_BUFFER, the driver does not compile.

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/setup: fix novx parameter

commit 89b1145e93771d727645c96e323539c029b63f1c upstream.

The novx parameter disables the vector facility but the HWCAP_S390_VXRS
bit in the ELf hardware capabilies is always set if the machine has
the vector facility. If the user space program uses the "vx" string
in the features field of /proc/cpuinfo to utilize vector instruction
it will crash if the novx kernel paramter is set.

Convert setup_hwcaps to an arch_initcall and use MACHINE_HAS_VX to
decide if the HWCAPS_S390_VXRS bit needs to be set.

Reported-by: Ulrich Weigand <uweigand@de.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/sclp: fix compile error

commit a313bdc5310dd807655d3ca3eb2219cd65dfe45a upstream.

Fix this error when compiling with CONFIG_SMP=n and
CONFIG_DYNAMIC_DEBUG=y:

drivers/s390/char/sclp_early.c: In function 'sclp_read_info_early':
drivers/s390/char/sclp_early.c:87:19: error: 'EBUSY' undeclared (first use in this function)
   } while (rc == -EBUSY);
                   ^

Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Limit the number of loops for reading a split 64bit register

commit acd29f7b22262d9e848393b9b6ae13eb42d22514 upstream.

In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
reads. Due to the nature of the registers we try to read in this manner,
they may increment between the two instruction (e.g. a timestamp
counter). To keep the result accurate, we repeat the read if we detect
an overflow (i.e. the upper value varies). However, some hardware is just
plain flaky and may endless loop as the the upper 32bits are not stable.
Just give up after a couple of tries and report whatever we read last.

v2: Use the most recent values when erring out on an unstable register.

Reported-by: russianneuromancer@ya.ru
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91906
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Always mark the object as dirty when used by the GPU

commit 51bc140431e233284660b1d22c47dec9ecdb521e upstream.

There have been many hard to track down bugs whereby userspace forgot to
flag a write buffer and then cause graphics corruption or a hung GPU
when that buffer was later purged under memory pressure (as the buffer
appeared clean, its pages would have been evicted rather than preserved
and any changes more recent than in the backing storage would be lost).
In retrospect this is a rare optimisation against memory pressure,
already the slow path. If we always mark the buffer as dirty when
accessed by the GPU, anything not used can still be evicted cheaply
(ideal behaviour for mark-and-sweep eviction) but we do not run the risk
of corruption. For correct read serialisation, userspace still has to
notify when the GPU writes to an object. However, there are certain
situations under which userspace may wish to tell white lies to the
kernel...

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "Goel, Akash" <akash.goel@intel.co>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Allow DSI dual link to be configured on any pipe

commit 824257857fd81f5e749831ff9cd63566b5a86abe upstream.

Just like single link MIPI panels, similarly for dual link panels, pipe
to be configured is based on the DVO port from VBT Block 2. In hardware,
Port A is mapped with Pipe A and Port C is mapped with Pipe B.

This issue got introduced in -

commit 7e9804fdcffc650515c60f524b8b2076ee59e710
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Jan 16 14:27:23 2015 +0200

    drm/i915/dsi: add drm mipi dsi host support

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/qxl: validate monitors config modes

commit bd3e1c7c6de9f5f70d97cdb6c817151c0477c5e3 upstream.

Due to some recent changes in
drm_helper_probe_single_connector_modes_merge_bits(), old custom modes
were not being pruned properly. In current kernels,
drm_mode_validate_basic() is called to sanity-check each mode in the
list. If the sanity-check passes, the mode's status gets set to to
MODE_OK. In older kernels this check was not done, so old custom modes
would still have a status of MODE_UNVERIFIED at this point, and would
therefore be pruned later in the function.

As a result of this new behavior, the list of modes for a device always
includes every custom mode ever configured for the device, with the
largest one listed first. Since desktop environments usually choose the
first preferred mode when a hotplug event is emitted, this had the
result of making it very difficult for the user to reduce the size of
the display.

The qxl driver did implement the mode_valid connector function, but it
was empty. In order to restore the old behavior where old custom modes
are pruned, we implement a proper mode_valid function for the qxl
driver. This function now checks each mode against the last configured
custom mode and the list of standard modes. If the mode doesn't match
any of these, its status is set to MODE_BAD so that it will be pruned as
expected.

Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Preserve SSC earlier

commit 69f92f67b68ab7028ffe15f0eea76b59f8859383 upstream.

Commit 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
added code to intel_modeset_gem_init to override the SSC status read
from VBT with the SSC status set by BIOS.

However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
which calls intel_setup_outputs, which *modifies* SSC status by way of
intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
doesn't preserve the SSC status set by BIOS but whatever
intel_init_pch_refclk decided on.

This is a problem on dual gpu laptops such as the MacBook Pro which
require either a handler to switch DDC lines, or the discrete gpu
to proxy DDC/AUX communication: Both the handler and the discrete
gpu may initialize after the i915 driver, and consequently, an LVDS
connector may initially seem disconnected and the SSC therefore
is disabled by intel_init_pch_refclk, but on reprobe the connector
may turn out to be connected and the SSC must then be enabled.

Due to 92122789b2d6 however, the SSC is not enabled on reprobe since
it is assumed BIOS disabled it while in fact it was disabled by
intel_init_pch_refclk.

Also, because the SSC status is preserved so late, the preserved value
only ever gets used on resume but not on panel initialization:
intel_modeset_init calls intel_init_display which indirectly calls
intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
is the sole user of dev_priv->vbt.lvds_use_ssc).

Fix this by moving the code introduced by 92122789b2d6 from
intel_modeset_gem_init to intel_modeset_init before the invocation
of intel_setup_outputs and intel_init_display.

Add a DRM_DEBUG_KMS as suggested way back by Jani:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko <pvt.gord@gmail.com>
    [MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]
Tested-by: William Brown <william@blackhats.net.au>
    [MBP  8,2 2011  intel SNB + amd turks     pre-retina]
Tested-by: Lukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]
Tested-by: Bruno Bierbaumer <bruno@bierbaumer.net>
    [MBP 11,3 2013  intel HSW + nvidia GK107  retina -- work in progress]
Fixes: 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon: fix HDMI quantization_range for pre-DCE5 asics

commit 86b7709d48f0df8796bddd7e1ce45c6fb7a7c6ec upstream.

Support for output_csc is only available on DCE5 and newer so
don't mess with the HDMI quantization_range on pre-DCE5 asics.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=83226

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon/native: Send out the full AUX address

commit 7040c399aea2b0213a9aefd73e507369a6d641d6 upstream.

AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.

Port of:
drm/radeon/atom: Send out the full AUX address
to radeon non-atom aux path

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon/atom: Send out the full AUX address

commit 3f8340cc72c9a1a4b49bce7802afd7f248400ef5 upstream.

AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Check DP link status on long hpd too

commit d14e7b6d1d8747826cb900db852351c550e00fdd upstream.

We are no longer checkling the DP link status on long hpd. We used to do
that from the .hot_plug() handler, but it was removed when MST got
introduced.

If there's no userspace we now fail to retrain the link if the sink
power is toggled (or cable yanked and replugged), meaning the user is
left staring at a blank screen. With the retraining put back that should
be fixed.

Also remove the leftover comment that referred to the old retraining
from .hot_plug().

Fixes a regression introduced in:
commit 0e32b39ceed665bfa4a77a4bc307b6652b991632
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 2 14:02:48 2014 +1000

    drm/i915: add DP 1.2 MST support (v0.7)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453
Tested-by: Palmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6

commit 54875571bbfde00fc63741715c531cbb5246c3b2 upstream.

commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
Author: Imre Deak <imre.deak@intel.com>
Date:   Thu Oct 23 19:23:26 2014 +0300

    drm/i915: add poweroff_late handler

introduced a regression on old platforms during hibernation. A workaround was
added in

commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Mar 2 13:04:41 2015 +0200

    drm/i915: gen4: work around hang during hibernation

using an explicit blacklist for the GENs/BIOS vendors where the issue was
reported. Later there we had reports of the same failure on platforms not on
this list.

To my best knowledge the correct thing to do is still to put the device to PCI
D3 state during hibernation, see [1] and [2] for the reasons. This also aligns
with our future plans to unify more the runtime and system suspend/resume
paths. Since an exact blacklist seems to be impractical (multiple GENs and
BIOS vendors are affected) apply the workaround on everything pre GEN6.

[1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/060710.html
[2] https://lkml.org/lkml/2015/6/22/274

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=95061
Reported-by: Ilya Tumaykin <itumaykin@gmail.com>
Reported-by: Dirk Griesbach <spamthis@freenet.de>
Reported-by: Pavel Machek <pavel@ucw.cz>
Reported-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Tested-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd

commit 924f92bf12bfbef3662619e3ed24a1cea7c1cbcd upstream.

Most of the time this isn't an issue since hotplugging an adaptor will
trigger a crtc mode change which in turn, causes the driver to probe
every DisplayPort for a dpcd. However, in cases where hotplugging
doesn't cause a mode change (specifically when one unplugs a monitor
from a DisplayPort connector, then plugs that same monitor back in
seconds later on the same port without any other monitors connected), we
never probe for the dpcd before starting the initial link training. What
happens from there looks like this:

- GPU has only one monitor connected. It's connected via
  DisplayPort, and does not go through an adaptor of any sort.

- User unplugs DisplayPort connector from GPU.

- Change in HPD is detected by the driver, we probe every
  DisplayPort for a possible connection.

- Probe the port the user originally had the monitor connected
  on for it's dpcd. This fails, and we clear the first (and only
  the first) byte of the dpcd to indicate we no longer have a
  dpcd for this port.

- User plugs the previously disconnected monitor back into the
  same DisplayPort.

- radeon_connector_hotplug() is called before everyone else,
  and tries to handle the link training. Since only the first
  byte of the dpcd is zeroed, the driver is able to complete
  link training but does so against the wrong dpcd, causing it
  to initialize the link with the wrong settings.

- Display stays blank (usually), dpcd is probed after the
  initial link training, and the driver prints no obvious
  messages to the log.

In theory, since only one byte of the dpcd is chopped off (specifically,
the byte that contains the revision information for DisplayPort), it's
not entirely impossible that this bug may not show on certain monitors.
For instance, the only reason this bug was visible on my ASUS PB238
monitor was due to the fact that this monitor using the enhanced framing
symbol sequence, the flag for which is ignored if the radeon driver
thinks that the DisplayPort version is below 1.1.

Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/ldt: Further fix FPU emulation

commit 12e244f4b550498bbaf654a52f93633f7dde2dc7 upstream.

The previous fix confused a selector with a segment prefix.  Fix it.

Compile-tested only.

Cc: Juergen Gross <jgross@suse.com>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Fixes: 4809146b86c3 ("x86/ldt: Correct FPU emulation access to LDT")
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/ldt: Correct FPU emulation access to LDT

commit 4809146b86c3d41ce588fdb767d021e2a80600dd upstream.

Commit 37868fe113ff ("x86/ldt: Make modify_ldt synchronous")
introduced a new struct ldt_struct anchored at mm->context.ldt.

Adapt the x86 fpu emulation code to use that new structure.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: billm@melbpc.org.au
Link: http://lkml.kernel.org/r/1438883674-1240-1-git-send-email-jgross@suse.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/ldt: Correct LDT access in single stepping logic

commit 136d9d83c07c5e30ac49fc83b27e8c4842f108fc upstream.

Commit 37868fe113ff ("x86/ldt: Make modify_ldt synchronous")
introduced a new struct ldt_struct anchored at mm->context.ldt.

convert_ip_to_linear() was changed to reflect this, but indexing
into the ldt has to be changed as the pointer is no longer void *.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bp@suse.de
Link: http://lkml.kernel.org/r/1438848278-12906-1-git-send-email-jgross@suse.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/ldt: Make modify_ldt synchronous

commit 37868fe113ff2ba814b3b4eb12df214df555f8dc upstream.

modify_ldt() has questionable locking and does not synchronize
threads.  Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.

This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.

This fixes some fallout from the CVE-2015-5157 fixes.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: security@kernel.org <security@kernel.org>
Cc: xen-devel <xen-devel@lists.xen.org>
Link: http://lkml.kernel.org/r/4c6978476782160600471bd865b318db34c7b628.1438291540.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 4.1.7

ARM: 8405/1: VDSO: fix regression with toolchains lacking ld.bfd executable

commit 3473f26592c1c365d376aee29433d7db75f14d1e upstream.

The Sourcery CodeBench Lite 2014.05 toolchain (gcc 4.8.3, binutils
2.24.51) has a GCC which implements -fuse-ld, and it doesn't include
the gold linker, but it lacks an ld.bfd executable in its
installation.  This means that passing -fuse-ld=bfd fails with:

      VDSO    arch/arm/vdso/vdso.so.raw
    collect2: fatal error: cannot find 'ld'

Arguably this is a deficiency in the toolchain, but I suspect it's
commonly used enough that it's worth accommodating: just use

cc-ldoption (to cause a link attempt) instead of cc-option to test
whether we can use -fuse-ld.  So -fuse-ld=bfd won't be used with this
toolchain, but the build will rightly succeed, just as it does for
toolchains which don't implement -fuse-ld (and don't use gold as the
default linker).

Note: this will change the failure mode for a corner case I was trying
to handle in d2b30cd4b722, where the toolchain defaults to the gold
linker and the BFD linker is not found in PATH, from:

      VDSO    arch/arm/vdso/vdso.so.raw
    collect2: fatal error: cannot find 'ld'

i.e. the BFD linker is not found, to:

      OBJCOPY arch/arm/vdso/vdso.so
    BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
    linking with -N

that is, we fail to prevent gold from being used as the linker, and it
produces an object that objcopy can't digest.

Reported-by: Baruch Siach <baruch@tkos.co.il>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Tested-by: Raphaël Poggi <poggi.raph@gmail.com>
Fixes: d2b30cd4b722 ("ARM: 8384/1: VDSO: force use of BFD linker")
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/idle: Restore trace_cpu_idle to mwait_idle() calls

commit e43d0189ac02415fe4487f79fc35e8f147e9ea0d upstream.

Commit b253149b843f ("sched/idle/x86: Restore mwait_idle() to fix boot
hangs, to improve power savings and to improve performance") restores
mwait_idle(), but the trace_cpu_idle related calls are missing. This
causes powertop on my old desktop powered by Intel Core2 E6550 to
report zero wakeups and zero events.

Add them back to restore the proper behaviour.

Fixes: b253149b843f ("sched/idle/x86: Restore mwait_idle() to ...")
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Cc: <len.brown@intel.com>
Link: http://lkml.kernel.org/r/1440046479-4262-1-git-send-email-jszhang@marvell.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/apic: Fix fallout from x2apic cleanup

commit a57e456a7b28431b55e407e5ab78ebd5b378d19e upstream.

In the recent x2apic cleanup I got two things really wrong:
1) The safety check in __disable_x2apic which allows the function to
   be called unconditionally is backwards. The check is there to
   prevent access to the apic MSR in case that the machine has no
   apic. Though right now it returns if the machine has an apic and
   therefor the disabling of x2apic is never invoked.

2) x2apic_disable() sets x2apic_mode to 0 after registering the local
   apic. That's wrong, because register_lapic_address() checks x2apic
   mode and therefor takes the wrong code path.

This results in boot failures on machines with x2apic preenabled by
BIOS and can also lead to an fatal MSR access on machines without
apic.

The solutions are simple:
1) Correct the sanity check for apic availability
2) Clear x2apic_mode _before_ calling register_lapic_address()

Fixes: 659006bf3ae3 'x86/x2apic: Split enable and setup function'
Reported-and-tested-by: Javier Monteagudo <javiermon@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1224764
Cc: Laura Abbott <labbott@redhat.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/xen: make CONFIG_XEN depend on CONFIG_X86_LOCAL_APIC

commit 87ffd2b9bb74061c120f450e4d0f3409bb603ae0 upstream.

Since commit feb44f1f7a4ac299d1ab1c3606860e70b9b89d69 (x86/xen:
Provide a "Xen PV" APIC driver to support >255 VCPUs) Xen guests need
a full APIC driver and thus should depend on X86_LOCAL_APIC.

This fixes an i386 build failure with !SMP && !CONFIG_X86_UP_APIC by
disabling Xen support in this configuration.

Users needing Xen support in a non-SMP i386 kernel will need to enable
CONFIG_X86_UP_APIC.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: perf: fix unassigned cpu_pmu->plat_device when probing PMU PPIs

commit b265da5a45ce60bd3d7505cc0eaa6cfba50946a1 upstream.

Commit d795ef9aa831 ("arm64: perf: don't warn about missing
interrupt-affinity property for PPIs") added a check for PPIs so that
we avoid parsing the interrupt-affinity property for these naturally
affine interrupts.

Unfortunately, this check can trigger an early (successful) return and
we will not assign the value of cpu_pmu->plat_device. This patch fixes
the issue.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: KVM: Fix host crash when injecting a fault into a 32bit guest

commit 126c69a0bd0e441bf6766a5d9bf20de011be9f68 upstream.

When injecting a fault into a misbehaving 32bit guest, it seems
rather idiotic to also inject a 64bit fault that is only going
to corrupt the guest state. This leads to a situation where we
perform an illegal exception return at EL2 causing the host
to crash instead of killing the guest.

Just fix the stupid bug that has been there from day 1.

Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fnic: Use the local variable instead of I/O flag to acquire io_req_lock in fnic_queuecommand() to avoid deadloack

commit db196935d9562abec4510f48d887bc1f1e054fcf upstream.

We added changes in fnic driver patch 1.6.0.16 to acquire
io_req_lock in fnic_queuecommand() before issuing I/O so that io completion
is serialized. But when releasing the lock we check for the I/O flag and
this could be modified if IO abort occurs before I/O completion. In this case
we wont release the lock and causes deadlock in some scenerios. Using the
local variable to check the IO lock status will resolve the problem.

Fixes: 41df7b02db82cf6c14f094757bac3830d10a827f
Signed-off-by: Hiral Shah <hishah@cisco.com>
Signed-off-by: Sesidhar Baddela <sebaddel@cisco.com>
Signed-off-by: Anil Chintalapati <achintal@cisco.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add factory recertified Crucial M500s to blacklist

commit 7a7184b01aa9deb86df661c6f7cbcf69a95b728c upstream.

The Crucial M500 is known to have issues with queued TRIM commands, the
factory recertified SSDs use a different model number naming convention
which causes them to get ignored by the blacklist.

The new naming convention boils down to: s/Crucial_/FC/

Signed-off-by: Guillermo A. Amaral <g@maral.me>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: pcan_usb: don't provide CAN FD bittimings by non-FD adapters

commit 06b23f7fbbf26a025fd68395c7586949db586b47 upstream.

The CAN FD data bittiming constants are provided via netlink only when there
are valid CAN FD constants available in priv->data_bittiming_const.

Due to the indirection of pointer assignments in the peak_usb driver the
priv->data_bittiming_const never becomes NULL - not even for non-FD adapters.

The data_bittiming_const points to zero'ed data which leads to this result
when running 'ip -details link show can0':

35: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can state STOPPED restart-ms 0
  pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
  : dtseg1 0..0 dtseg2 0..0 dsjw 1..0 dbrp 0..0 dbrp-inc 0  <== BROKEN!
  clock 8000000

This patch changes the struct peak_usb_adapter::bittiming_const and struct
peak_usb_adapter::data_bittiming_const to pointers to fix the assignemnt
problems.

Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

SCSI: Fix NULL pointer dereference in runtime PM

commit 49718f0fb8c9af192b33d8af3a2826db04025371 upstream.

The routines in scsi_rpm.c assume that if a runtime-PM callback is
invoked for a SCSI device, it can only mean that the device's driver
has asked the block layer to handle the runtime power management (by
calling blk_pm_runtime_init(), which among other things sets q->dev).

However, this assumption turns out to be wrong for things like the ses
driver.  Normally ses devices are not allowed to do runtime PM, but
userspace can override this setting.  If this happens, the kernel gets
a NULL pointer dereference when blk_post_runtime_resume() tries to use
the uninitialized q->dev pointer.

This patch fixes the problem by calling the block layer's runtime-PM
routines only if the device's driver really does have a runtime-PM
callback routine.  Since ses doesn't define any such callbacks, the
crash won't occur.

This fixes Bugzilla #101371.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Stanisław Pitucha <viraptor@gmail.com>
Reported-by: Ilan Cohen <ilanco@gmail.com>
Tested-by: Ilan Cohen <ilanco@gmail.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

genirq: Introduce irq_chip_set_type_parent() helper

commit b7560de198222994374c1340a389f12d5efb244a upstream.

This helper is required for irq chips which do not implement a
irq_set_type callback and need to call down the irq domain hierarchy
for the actual trigger type change.

This helper is required to fix further wreckage caused by the
conversion of TI OMAP to hierarchical irq domains and therefor tagged
for stable.

[ tglx: Massaged changelog ]

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-3-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

genirq: Don't return ENOSYS in irq_chip_retrigger_hierarchy

commit 6d4affea7d5aa5ca5ff4c3e5fbf3ee16801cc527 upstream.

irq_chip_retrigger_hierarchy() returns -ENOSYS if it was not able to
find at least one .irq_retrigger() callback implemented in the IRQ
domain hierarchy.

That's wrong, because check_irq_resend() expects a 0 return value from
the callback in case that the hardware assisted resend was not
possible. If the return value is non zero the core code assumes
hardware resend success and the software resend is not invoked.

This results in lost interrupts on platforms where none of the parent
irq chips in the hierarchy implements the retrigger callback.

This is observable on TI OMAP, where the hierarchy is:

 ARM GIC <- OMAP wakeupgen <- TI Crossbar

Return 0 instead so the software resend mechanism gets invoked.

[ tglx: Massaged changelog ]

Fixes: 85f08c17de26 ('genirq: Introduce helper functions...')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Link: http://lkml.kernel.org/r/1439554830-19502-2-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism

commit 63059a272398ef5dc1bd7065a036e8b6e82d1af7 upstream.

The conversion of the wakeupgen irqchip to hierarchical irq domains
failed to provide a mechanism to properly set the trigger type of an
interrupt.

The wakeupgen irq chip itself has no mechanism and therefor no
irq_set_type() callback. The code before the conversion relayed the
trigger configuration directly to the underlying GIC.

Restore the correct behaviour by setting the wakeupgen irq_set_type
callback to irq_chip_set_type_parent(). This propagates the
set_trigger() call to the underlying GIC irqchip.

[ tglx: Massaged changelog ]

Fixes: 7136d457f365 ('ARM: omap: convert wakeupgen to stacked domains')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <marc.zyngier@arm.com>
Link: http://lkml.kernel.org/r/1439554830-19502-5-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

irqchip/crossbar: Restore set_wake functionality

commit 8200fe4347870d4ad6475048bcdf3e7c106c5268 upstream.

The TI crossbar irqchip doesn't provides any facility to configure the
wakeup sources, but the conversion to hierarchical irqdomains set the
irq_set_wake callback to irq_chip_set_wake_parent. The parent chip
(OMAP wakeupgen) has no irq_set_wake function either so the call will
fail with -ENOSYS. As a result the irq_set_wake() call in the resume
path will trigger an 'Unbalanced wake disable' warning.

Before the conversion the GIC irqchip was the top level irqchip and
correctly flagged with IRQCHIP_SKIP_SET_WAKE.

Restore the correct behaviour by removing the irq_set_type callback
from the crossbar irqchip and set the IRQCHIP_SKIP_SET_WAKE flag which
lets the irq_set_irq_wake() call from the driver succeed.

[ tglx: Massaged changelog ]

Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Link: http://lkml.kernel.org/r/1439554830-19502-7-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

irqchip/crossbar: Restore the mask on suspend behaviour

commit 4fd8f47e7e5b64a74b60f23c2e08ba8234d659d1 upstream.

The ARM GIC requires that all interrupts which are not used as a
wakeup source have to be masked during suspend.

The conversion of the crossbar irqchip to hierarchical irq domains
failed to mark the crossbar irqchip with the IRQCHIP_MASK_ON_SUSPEND
flag and therefor broke the suspend requirement of the GIC.

Before the conversion the flags were visible because the GIC was the
top level irqchip. After the conversion the crossbar irqchip is the
top level irq chip whose flags are evaluated in suspend_device_irq().
As the flag is not set the masking of the non-wakeup irqs is not
invoked which breaks suspend.

Add the IRQCHIP_MASK_ON_SUSPEND flag to the crossbar irqchip, so the
GIC interrupts get masked properly.

[ tglx: Massaged changelog ]

Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Link: http://lkml.kernel.org/r/1439554830-19502-6-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

irqchip/crossbar: Restore the irq_set_type() mechanism

commit e269ec42328783e51be08c191aa935dba56141fc upstream.

The conversion of the crossbar irqchip to hierarchical irq domains
failed to provide a mechanism to properly set the trigger type of an
interrupt.

The crossbar irq chip itself has no mechanism and therefor no
irq_set_type() callback. The code before the conversion relayed the
trigger configuration directly to the underlying GIC.

Restore the correct behaviour by setting the crossbar irq_set_type
callback to irq_chip_set_type_parent(). This propagates the
set_trigger() call to the underlying GIC irqchip.

[ tglx: Massaged changelog ]

Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Link: http://lkml.kernel.org/r/1439554830-19502-4-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9p: ensure err is initialized to 0 in p9_client_read/write

commit 999b8b88c6060adf7a9b7907740ae86ace65291e upstream.

Some use of those functions were providing unitialized values to those
functions. Notably, when reading 0 bytes from an empty file on a 9P
filesystem, the return code of read() was not 0.

Tested with this simple program:

    #include <assert.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    #include <unistd.h>

    int main(int argc, const char **argv)
    {
        assert(argc == 2);
        char buffer[256];
        int fd = open(argv[1], O_RDONLY|O_NOCTTY);
        assert(fd >= 0);
        assert(read(fd, buffer, 0) == 0);
        return 0;
    }

Signed-off-by: Vincent Bernat <vincent@bernat.im>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Avoid TP3 on CHV

commit ed63baaf849e91c84ac3e042b1fd6a0af07c16f3 upstream.

This patch removes TP3 support on CHV since there is no support
for HBR2 on this platform.

v2: rename the function to indicate it checks source rates (Jani)
v3: update comment to indicate TP3 dependency on HBR2 supported
    hardware (Jani)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
[Jani: fixed a couple of checkpatch warnings.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: remove HBR2 from chv supported list

commit 5e86dfe39f54ab13fd8079ac3d6cb100318909a3 upstream.

This patch removes 5.4Gbps from supported link rate for CHV since
it is not supported in it.

v2: change the ordering for better readability (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Flag the execlists context object as dirty after every use

commit 903ecd0bb970438c3a60c2c33ec9032d6443bf67 upstream.

Everytime we use the logical context with execlists it becomes dirty (as
the hardware will write the new register values afterwards, as well as
the GPU state that will be used). We need to then flag the context as
dirty everytime since after a swap-out/swap-in cycle the dirty flag will
be cleared, and a further swap-out cycle will then loose the most recent
GPU state.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/atmel-hlcdc: Compile suspend/resume for PM_SLEEP only

commit dbb3df2d58754e4df58620e60370d166c2cb6744 upstream.

If PM is enabled but PM_SLEEP is disabled, the suspend/resume functions
are still unused and produce a compiler warning.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: gpio_keys_polled - request GPIO pin as input.

commit 1ae5ddb6f8837558928a1a694c7b8af7f09fdd21 upstream.

GPIOF_IN flag was lost in:
Commit 633a21d80b4a("input: gpio_keys_polled: Add support for GPIO
descriptors").

Without this flag, legacy code path (for non-descriptor GPIO declarations)
would configure GPIO as output (0 meaning GPIOF_DIR_OUT | GPIOF_INIT_LOW).

Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>