Make sure size of response buffer is at least 6 bytes, or
we will underflow and pass large size_t to memcpy_fromio().
This was encountered while testing earlier version of
locality patchset.

Cc: stable@vger.kernel.org
Fixes: 30fc8d13 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: NJerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Sessions are different from transient objects in that their handles
may not be virtualized (because they're used for some hmac
calculations).  Additionally when a session is context saved, a
vestigial memory remains in the TPM and if it is also flushed, that
will be lost and the session context will refuse to load next time, so
the code is updated to flush only transient objects after a context
save.  Add a separate array (chip->session_tbl) to save and restore
sessions by handle.  Use the failure of a context save or load to
signal that the session has been flushed from the TPM and we can
remove its memory from chip->session_tbl.

Sessions are also isolated during each instance of a tpm space.  This
means that spaces shouldn't be able to see each other's sessions and
is enforced by ensuring that a space user may only refer to sessions
handles that are present in their own chip->session_tbl.  Finally when
a space is closed, all the sessions belonging to it should be flushed
so the handles may be re-used by other spaces.

Note that if we get a session save or load error, all sessions are
effectively flushed.  Even though we restore the session buffer, all
the old sessions will refuse to load after the flush and they'll be
purged from our session memory.  This means that while transient
context handling is still soft in the face of errors, session handling
is hard (any failure of the model means all sessions are lost).

Fixes-from: Colin Ian King <colin.king@canonical.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Currently the tpm spaces are not exposed to userspace.  Make this
exposure via a separate device, which can now be opened multiple times
because each read/write transaction goes separately via the space.

Concurrency is protected by the chip->tpm_mutex for each read/write
transaction separately.  The TPM is cleared of all transient objects
by the time the mutex is dropped, so there should be no interference
between the kernel and userspace.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Added an ability to virtualize TPM commands into an isolated context
that we call a TPM space because the word context is already heavily
used in the TPM specification. Both the handle areas and bodies (where
necessary) are virtualized.

The mechanism works by adding a new parameter struct tpm_space to the
tpm_transmit() function. This new structure contains the list of virtual
handles and a buffer of page size (currently) for backing storage.

When tpm_transmit() is called with a struct tpm_space instance it will
execute the following sequence:

1. Take locks.
2. Load transient objects from the backing storage by using ContextLoad
   and map virtual handles to physical handles.
3. Perform the transaction.
4. Save transient objects to backing storage by using ContextSave and
   map resulting physical handle to virtual handle if there is such.

This commit does not implement virtualization support for hmac and
policy sessions.
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Reviewed-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Check for every TPM 2.0 command that the command code is supported and
the command buffer has at least the length that can contain the header
and the handle area.

For ContextSave and FlushContext we mark the body to be part of the
handle area. This gives validation for these commands at zero
cost, including the body of the command.

The more important reason for this is that we can virtualize these
commands in the same way as you would virtualize the handle area of a
command.
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Reviewed-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Reviewed-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Check that the length matches the length reported by the response
header already in tpm_transmit() to improve validation.
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Reviewed-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Encapsulated crb_wait_for_reg32() so that state changes in other CRB
registers than TPM_CRB_CTRL_REQ_x can be waited.
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: NJerry Snitselaar <jsnitsel@redhat.com>
Tested-by: NGang Wei <gang.wei@intel.com>

In order to provide access to locality registers, this commits adds
mapping of the head of the CRB registers, which are located right
before the control area.
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: NJerry Snitselaar <jsnitsel@redhat.com>
Tested-by: NGang Wei <gang.wei@intel.com>

Testing the implementation with a Raspberry Pi 2 showed that under some
circumstances its SPI master erroneously releases the CS line before the
transfer is complete, i.e. before the end of the last clock. In this case
the TPM ignores the transfer and misses for example the GO command. The
driver is unable to detect this communication problem and will wait for a
command response that is never going to arrive, timing out eventually.

As a workaround, the small delay ensures that the CS line is held long
enough, even with a faulty SPI master. Other SPI masters are not affected,
except for a negligible performance penalty.

Cc: <stable@vger.kernel.org>
Fixes: 0edbfea5 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: NAlexander Steffen <Alexander.Steffen@infineon.com>
Signed-off-by: NPeter Huewe <peter.huewe@infineon.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NBenoit Houyere <benoit.houyere@st.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Limiting transfers to MAX_SPI_FRAMESIZE was not expected by the upper
layers, as tpm_tis has no such limitation. Add a loop to hide that
limitation.

v2: Moved scope of spi_message to the top as requested by Jarkko
Cc: <stable@vger.kernel.org>
Fixes: 0edbfea5 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: NAlexander Steffen <Alexander.Steffen@infineon.com>
Signed-off-by: NPeter Huewe <peter.huewe@infineon.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NBenoit Houyere <benoit.houyere@st.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Wait states are signaled in the last byte received from the TPM in
response to the header, not the first byte. Check rx_buf[3] instead of
rx_buf[0].

Cc: <stable@vger.kernel.org>
Fixes: 0edbfea5 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: NAlexander Steffen <Alexander.Steffen@infineon.com>
Signed-off-by: NPeter Huewe <peter.huewe@infineon.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NBenoit Houyere <benoit.houyere@st.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Abort the transfer with ETIMEDOUT when the TPM signals more than
TPM_RETRY wait states. Continuing with the transfer in this state
will only lead to arbitrary failures in other parts of the code.

Cc: <stable@vger.kernel.org>
Fixes: 0edbfea5 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: NAlexander Steffen <Alexander.Steffen@infineon.com>
Signed-off-by: NPeter Huewe <peter.huewe@infineon.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NBenoit Houyere <benoit.houyere@st.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The algorithm for sending data to the TPM is mostly identical to the
algorithm for receiving data from the TPM, so a single function is
sufficient to handle both cases.

This is a prequisite for all the other fixes, so we don't have to fix
everything twice (send/receive)

v2: u16 instead of u8 for the length.
Cc: <stable@vger.kernel.org>
Fixes: 0edbfea5 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: NAlexander Steffen <Alexander.Steffen@infineon.com>
Signed-off-by: NPeter Huewe <peter.huewe@infineon.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NBenoit Houyere <benoit.houyere@st.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

This fix enables a platform to enter the idle state (suspend-to-idle)

The driver needs to request explicitly go_idle upon completion
from the pm suspend handler.
The runtime pm is disabled on suspend during prepare state by calling
pm_runtime_get_noresume, hence we cannot relay on runtime pm to leave
the device in low power state. Symmetrically cmdReady is called
upon resume.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Siged-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

We get a newly introduced harmless warning when CONFIG_CRYPTO is disabled:

warning: (TCG_TPM && TRUSTED_KEYS && IMA) selects CRYPTO_HASH_INFO which has unmet direct dependencies (CRYPTO)

This adds another select to avoid the warning, consistent with other users
of the crypto code.

Fixes: c1f92b4b ("tpm: enhance TPM 2.0 PCR extend to support multiple banks")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NPeter Huewe <peterhuewe@gmx.de>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Commit 500462a9 "timers: Switch to a non-cascading wheel" replaced
the 'classic' timer wheel, which aimed for near 'exact' expiry of the
timers.  Their analysis was that the vast majority of timeout timers
are used as safeguards, not as real timers, and are cancelled or
rearmed before expiration.  The only exception noted to this were
networking timers with a small expiry time.

Not included in the analysis was the TPM polling timer, which resulted
in a longer normal delay and, every so often, a very long delay.  The
non-cascading wheel delay is based on CONFIG_HZ.  For a description of
the different rings and their delays, refer to the comments in
kernel/time/timer.c.

Below are the delays given for rings 0 - 2, which explains the longer
"normal" delays and the very, long delays as seen on systems with
CONFIG_HZ 250.

* HZ 1000 steps
 * Level Offset  Granularity            Range
 *  0      0         1 ms                0 ms - 63 ms
 *  1     64         8 ms               64 ms - 511 ms
 *  2    128        64 ms              512 ms - 4095 ms (512ms - ~4s)

* HZ  250
 * Level Offset  Granularity            Range
 *  0      0         4 ms                0 ms - 255 ms
 *  1     64        32 ms              256 ms - 2047 ms (256ms - ~2s)
 *  2    128       256 ms             2048 ms - 16383 ms (~2s - ~16s)

Below is a comparison of extending the TPM with 1000 measurements,
using msleep() vs. usleep_delay() when configured for 1000 hz vs. 250
hz, before and after commit 500462a9.

linux-4.7 | msleep() usleep_range()
1000 hz: 0m44.628s | 1m34.497s 29.243s
250 hz: 1m28.510s | 4m49.269s 32.386s

linux-4.7  | min-max (msleep)  min-max (usleep_range)
1000 hz: 0:017 - 2:760s | 0:015 - 3:967s    0:014 - 0:418s
250 hz: 0:028 - 1:954s | 0:040 - 4:096s    0:016 - 0:816s

This patch replaces the msleep() with usleep_range() calls in the
i2c nuvoton driver with a consistent max range value.
Signed-of-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org (linux-4.8)
Signed-off-by: NNayna Jain <nayna@linux.vnet.ibm.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The expectation is that the if the CRB cmd/rsp buffer falls within the
ACPI region that the entire buffer will be within the reason. Otherwise
resource reservation will fail when it crosses regions.

Work around this BIOS bug by limiting the cmd/rsp buffer to the length
of the declared ACPI region. BIOS vendors should fix this by making
the ACPI and register length declarations consistent.
Reported-by: NDavide Guerri <davide.guerri@gmail.com>
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NDavide Guerri <davide.guerri@gmail.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

TIS v1.3 for TPM 1.2 and PTP for TPM 2.0 disagree about which timeout
value applies to reading a valid burstcount. It is TIMEOUT_D according to
TIS, but TIMEOUT_A according to PTP, so choose the appropriate value
depending on whether we deal with a TPM 1.2 or a TPM 2.0.

This is important since according to the PTP TIMEOUT_D is much smaller
than TIMEOUT_A. So the previous implementation could run into timeouts
with a TPM 2.0, even though the TPM was behaving perfectly fine.

During tpm2_probe TIMEOUT_D will be used even with a TPM 2.0, because
TPM_CHIP_FLAG_TPM2 is not yet set. This is fine, since the timeout values
will only be changed afterwards by tpm_get_timeouts. Until then
TIS_TIMEOUT_D_MAX applies, which is large enough.

Cc: stable@vger.kernel.org
Fixes: aec04cbd ("tpm: TPM 2.0 FIFO Interface")
Signed-off-by: NAlexander Steffen <Alexander.Steffen@infineon.com>
Signed-off-by: NPeter Huewe <peter.huewe@infineon.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

aarch64-linux-gcc-7 complains about code it doesn't fully understand:

drivers/infiniband/hw/qib/qib_iba7322.c: In function 'qib_7322_txchk_change':
include/asm-generic/bitops/non-atomic.h:105:35: error: 'shadow' may be used uninitialized in this function [-Werror=maybe-uninitialized]

The code is right, and despite trying hard, I could not come up with a version
that I liked better than just adding a fake initialization here to shut up the
warning.

Fixes: f931551b ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NIra Weiny <ira.weiny@intel.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

When the rdma device is removed, we must cleanup all
the rdma resources within the DEVICE_REMOVAL event
handler to let the device teardown gracefully. When
this happens with live I/O, some memory regions are
occupied. Thus, track them too and dereg all the mr's.

We are safe with mr access by iscsi_iser_cleanup_task.
Reported-by: NRaju Rangoju <rajur@chelsio.com>
Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NMax Gurtovoy <maxg@mellanox.com>
Reviewed-by: NMax Gurtovoy <maxg@mellanox.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

This workqueue is used by our storage target mode ULPs
via the new CQ API. Recent observations when working
with very high-end flash storage devices reveal that
UNBOUND workqueue threads can migrate between cpu cores
and even numa nodes (although some numa locality is accounted
for).

While this attribute can be useful in some workloads,
it does not fit in very nicely with the normal
run-to-completion model we usually use in our target-mode
ULPs and the block-mq irq<->cpu affinity facilities.

The whole block-mq concept is that the completion will
land on the same cpu where the submission was performed.
The fact that our submitter thread is migrating cpus
can break this locality.

We assume that as a target mode ULP, we will serve multiple
initiators/clients and we can spread the load enough without
having to use unbound kworkers.

Also, while we're at it, expose this workqueue via sysfs which
is harmless and can be useful for debug.
Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>--
Signed-off-by: NDoug Ledford <dledford@redhat.com>

The caller might not want this overhead.
Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NYuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

According to C9-147, MSN should only be incremented when the last packet of
a multi packet request has been received.

"Logically, the requester associates a sequential Send Sequence Number
(SSN) with each WQE posted to the send queue. The SSN bears a one-
to-one relationship to the MSN returned by the responder in each re-
sponse packet. Therefore, when the requester receives a response, it in-
terprets the MSN as representing the SSN of the most recent request
completed by the responder to determine which send WQE(s) can be
completed."

Fixes: 8700e3e7 ("Soft RoCE driver")
Signed-off-by: NDavid Marchand <david.marchand@6wind.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Avoid that the following error message is reported on the console
while loading an RDMA driver with I/O MMU support enabled:

DMAR: Allocating domain for mlx5_0 failed

Ensure that DMA mapping operations that use to_pci_dev() to
access to struct pci_dev see the correct PCI device. E.g. the s390
and powerpc DMA mapping operations use to_pci_dev() even with I/O
MMU support disabled.

This patch preserves the following changes of the DMA mapping updates
patch series:
- Introduction of dma_virt_ops.
- Removal of ib_device.dma_ops.
- Removal of struct ib_dma_mapping_ops.
- Removal of an if-statement from each ib_dma_*() operation.
- IB HW drivers no longer set dma_device directly.
Reported-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Reported-by: NParav Pandit <parav@mellanox.com>
Fixes: commit 99db9494 ("IB/core: Remove ib_device.dma_device")
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: parav@mellanox.com
Tested-by: parav@mellanox.com
Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

All Soft-RoCE (rxe) is handled now in rdma-core user space library,
so the documentation. The patch below updates the documentation
link to that new location.
Reported-by: NJosh Beavers <josh.beavers@gmail.com>
Signed-off-by: NLeon Romanovsky <leon@kernel.org>
Reviewed-by: NIra Weiny <ira.weiny@intel.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

We want to return zero on success or negative error codes.  The type
should be int and not u8.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NYuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

"goto err;" has it's own kfree_skb() call so it's a double free.  We
only need to free on the "goto exit;" path.

Fixes: 8700e3e7 ("Soft RoCE driver")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Restore device state when ethernet link changes to active.
Acked-by: NGeorge Zhang <georgezhang@vmware.com>
Acked-by: NJorgen Hansen <jhansen@vmware.com>
Acked-by: NBryan Tan <bryantan@vmware.com>
Signed-off-by: NAditya Sarwade <asarwade@vmware.com>
Signed-off-by: NAdit Ranadive <aditr@vmware.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Moved the header page count to a macro.
Reported-by: NYuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: NAdit Ranadive <aditr@vmware.com>
Reviewed-by: NAditya Sarwade <asarwade@vmware.com>
Tested-by: NAndrew Boyer <andrew.boyer@dell.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Removed the unused nreq and redundant index variables.
Moved hardcoded async and cq ring pages number to macro.
Reported-by: NYuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: NAdit Ranadive <aditr@vmware.com>
Reviewed-by: NAditya Sarwade <asarwade@vmware.com>
Tested-by: NAndrew Boyer <andrew.boyer@dell.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

When vmalloc_user is used to create memory that is supposed to be mmap'd
to user space, it is necessary for the mmap cookie (eg the offset) to be
aligned to SHMLBA.

This creates a situation where all virtual mappings of the same physical
page share the same virtual cache index and guarantees VIPT coherence.
Otherwise the cache is non-coherent and the kernel will not see writes
by userspace when reading the shared page (or vice-versa).
Reported-by: NJosh Beavers <josh.beavers@gmail.com>
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

We need to make sure that the cq work item does not
run when we are destroying the cq. Unlike flush_work,
cancel_work_sync protects against self-requeue of the
work item (which we can do in ib_cq_poll_work).
Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>--
Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Netdev notification events are de-registered only when all
client iwdev instances are removed. If a single client is closed
and re-opened, netdev events could arrive even before the Control
Queue-Pair (CQP) is created, causing a NULL pointer dereference crash
in i40iw_get_cqp_request. Fix this by allowing netdev event
notification only after we have reached the INET_NOTIFIER state with
respect to device initialization.
Reported-by: NStefan Assmann <sassmann@redhat.com>
Signed-off-by: NShiraz Saleem <shiraz.saleem@intel.com>
Reviewed-by: NYuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

The latest gcc-7 snapshot adds a warning to point out that when
atk_read_value_old or atk_read_value_new fails, we copy
uninitialized data into sensor->cached_value:

drivers/hwmon/asus_atk0110.c: In function 'atk_input_show':
drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Adding an error check avoids this. All versions of the driver
are affected.

Fixes: 2c03d07a ("hwmon: Add Asus ATK0110 support")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NLuca Tettamanti <kronos.it@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

This was broken in commit cd979883 ("xen/acpi-processor:
fix enabling interrupts on syscore_resume"). do_suspend (from
xen/manage.c) and thus xen_resume_notifier never get called on
the initial-domain at resume (it is if running as guest.)

The rationale for the breaking change was that upload_pm_data()
potentially does blocking work in syscore_resume(). This patch
addresses the original issue by scheduling upload_pm_data() to
execute in workqueue context.

Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: stable@vger.kernel.org
Based-on-patch-by: NKonrad Wilk <konrad.wilk@oracle.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NAnkur Arora <ankur.a.arora@oracle.com>
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>

Otherwise this can also prevent modesets e.g. for switching VTs, when
multiple monitors with different native resolutions are connected.

The depths must match though, so keep the != test for that.

Also update the DRM_DEBUG output to be slightly more accurate, this
doesn't only affect requests from userspace.

Bugzilla: https://bugs.freedesktop.org/99841
Fixes: 865afb11 ("drm/fb-helper: reject any changes to the fbdev")
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170323085326.20185-1-michel@daenzer.net

Replace hard coded "ACPI0007" with ACPI_PROCESSOR_DEVICE_HID
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NAnkur Arora <ankur.a.arora@oracle.com>
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>

Disabling interrupts for even a millisecond can cause problems for some
devices. That can happen when Intel host controllers wait for the present
state to propagate.

The spin lock is not necessary here. Anything that is racing with changes
to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host.

Although the spin lock probably should be removed from the code paths that
lead to this point, such a patch would touch too much code to be suitable
for stable trees. Consequently, for this patch, just drop the spin lock
while waiting.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>