cec_read() is non-atomic in the presence of other I2C bus transactions
to the same device.  This presents a problem when we add support for
the TDA9950 CEC engine part - both drivers can be trying to access the
device.

Avoid the inherent problems by switching to i2c_transfer() instead,
which allows us to perform more than one bus transaction atomically.

As this means we will be using I2C transactions rather than SMBUS, we
have to check that the host supports I2C functionality.
Tested-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Some TDA998x contain several different I2C devices - there is the HDMI
encoder, and there is a TDA9950 CEC engine.  These two share the same
interrupt signal.

In order to allow a driver for the CEC engine to work, we need to be
able to share the interrupt with the CEC driver, so convert the handler
and registration to allow this to happen.
Tested-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Disabling the pre-filter block of the TDA998x saves 40mW and the colour
conversion block saves 15mW.  As we always disable these two blocks, we
can power these sections of the chip down to save 55mW of unnecessary
power consumption.
Tested-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Rather than storing the DPMS mode (which will always be on or off) use a
boolean to store this instead.
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

tda998x_audio_get_eld() is needlessly complex - the connector associated
with the encoder is always our own priv->connector.  Remove this
complexity, but ensure that there are no races when copying out the ELD.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Group the TDA998x audio functions together rather than split between
two different locations in the file, keeping like code together.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Separate out the connector initialisation from the rest of the drivers
initialisation.
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Group the TDA998x connector functions and funcs structures together
before the encoder support, rather than scattered amongst the rest of
the file.  This keeps like code together.
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The naming of tda998x_encoder_set_config() is a left-over from when
TDA998x was a slave encoder.  Since this is part of the initialisation,
drop the _encoder from the name, and move it near tda998x_bind().
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Correct two references to tda998x_connector_get_modes() which were
incorrectly referring to tda998x_encoder_get_modes().
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Check for audio support by the attached sink by consulting the EDID
prior to enabling audio over the TMDS link.  We must consult the EDID
after calling drm_helper_probe_single_connector_modes(), as this can
use an override EDID, or load a replacement EDID.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The CEA 861B specification indicates the situations when we are able to
send each infoframe based on the version of the EDID's CEA extension.
Update the tda998x driver to follow the CEA specification wrt sending
of infoframes.

Since we only support the generation of AVI version 2, this limits us
to CEA extension version 3, so we treat CEA extension version 2 as
CEA 861 (no infoframes, no audio.)
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Avoid a race between programming audio and an in-progress mode set.
A mode set is complex, and disables the ability to send infoframes
to the sink, and is disruptive to audio - we have to mute the audio
FIFO while doing a mode set.

If an attempt is made to start up the audio side, we will undo the
audio FIFO mute before the mode set has completed.

Move the lock so that we prevent audio interfering with an in-progress
mode set.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Avoid a racy access to the mode clock by storing the current mode clock
during a mode set under the audio mutex.  This allows us to access it
from the audio path in a safe way.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

As priv->audio_params can now be changed at run time, we need to be more
careful about how we deal with a mode set.  We must take the audio lock
while checking if there's a valid audio configuration.

However, it's slightly worse than that - during mode set, we mute the
audio, and it must not be unmuted until we have finished the mode set.
It is possible that the audio side may start while a mode set is in
progress, so take the audio_mutex lock around the whole mode setting
procedure.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

We will need the audio mutex initialised in all cases, so lets move this
to be early, rather than only being initialised for the DT case.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Connectors shouldn't be registered until the rest of the whole device
is set up, so that consistent state is presented to userspace.

As such, remove the calls to drm_connector_register() and
drm_connector_unregister() from tda998x, as these are now handled by
drm_dev_(un)register() itself.

To work with this change, the mali-dp and hdlcd bind and unbind
sequences have to be reordered, to ensure that the componentised
encoder/connector is bound before drm_dev_register() registers all
connectors. Similarly, the device must be unregistered before the
component is unbound.

Altogether, this allows other drivers using tda998x to be
de-midlayered, and to have less racy initialisation of their components.

Splitting this commit into three (one per driver) isn't possible without
intermediate breakage, so it is all squashed together here.
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

While the driver is probing the adapter, an error may occur before the
netdev structure is allocated and attached to pci_dev. In this case,
not only netdev isn't available, but the tg3 private structure is also
not available as it is just math from the NULL pointer, so dereferences
must be skipped.

The following trace is seen when the error is triggered:

  [1.402247] Unable to handle kernel paging request for data at address 0x00001a99
  [1.402410] Faulting instruction address: 0xc0000000007e33f8
  [1.402450] Oops: Kernel access of bad area, sig: 11 [#1]
  [1.402481] SMP NR_CPUS=2048 NUMA PowerNV
  [1.402513] Modules linked in:
  [1.402545] CPU: 0 PID: 651 Comm: eehd Not tainted 4.4.0-36-generic #55-Ubuntu
  [1.402591] task: c000001fe4e42a20 ti: c000001fe4e88000 task.ti: c000001fe4e88000
  [1.402742] NIP: c0000000007e33f8 LR: c0000000007e3164 CTR: c000000000595ea0
  [1.402787] REGS: c000001fe4e8b790 TRAP: 0300   Not tainted  (4.4.0-36-generic)
  [1.402832] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 28000422  XER: 20000000
  [1.403058] CFAR: c000000000008468 DAR: 0000000000001a99 DSISR: 42000000 SOFTE: 1
  GPR00: c0000000007e3164 c000001fe4e8ba10 c0000000015c5e00 0000000000000000
  GPR04: 0000000000000001 0000000000000000 0000000000000039 0000000000000299
  GPR08: 0000000000000000 0000000000000001 c000001fe4e88000 0000000000000006
  GPR12: 0000000000000000 c00000000fb40000 c0000000000e6558 c000003ca1bffd00
  GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000d52768
  GPR24: c000000000d52740 0000000000000100 c000003ca1b52000 0000000000000002
  GPR28: 0000000000000900 0000000000000000 c00000000152a0c0 c000003ca1b52000
  [1.404226] NIP [c0000000007e33f8] tg3_io_error_detected+0x308/0x340
  [1.404265] LR [c0000000007e3164] tg3_io_error_detected+0x74/0x340

This patch avoids the NULL pointer dereference by moving the access after
the netdev NULL pointer check on tg3_io_error_detected(). Also, we add a
check for netdev being NULL on tg3_io_resume() [suggested by Michael Chan].

Fixes: 0486a063 ("tg3: prevent ifup/ifdown during PCI error recovery")
Fixes: dfc8f370 ("net/tg3: Release IRQs on permanent error")
Tested-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: NMilton Miller <miltonm@us.ibm.com>
Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Acked-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The udl damage handler is supposed to render 'height' lines, but its
iterator has an obvious typo that makes it miss most lines if the
rectangle does not cover 0/0.

Fix the damage handler to correctly render all lines.

This is a fallout from:

    commit e3758824
    Author: Noralf Trønnes <noralf@tronnes.org>
    Date:   Thu Apr 28 17:18:37 2016 +0200

        drm/udl: Use drm_fb_helper deferred_io support
Tested-by: Npoma <poma@gmail.com>
Cc: stable@vger.kernel.org # 4.7+
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NEric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add clock quirks for Jet parts.
Reviewed-by: NSonny Jiang <sonny.jiang@amd.com>
Tested-by: NSonny Jiang <sonny.jiang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some code called by drm_crtc_force_disable_all() wants to wait for all
fences, so only do fence teardown after CRTCs are disabled.

Fixes: 84b89bdc ("drm/amdgpu: Turn off CRTCs on driver unload")
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 62469c76 ("net: ethernet: bcmgenet: use phydev
from struct net_device") because it causes GENETv1/2/3 adapters to
expose the following behavior after an ifconfig down/up sequence:

PING fainelli-linux (10.112.156.244): 56 data bytes
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.352 ms
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.472 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.496 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.517 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.536 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.557 ms (DUP!)
64 bytes from 10.112.156.244: seq=1 ttl=61 time=752.448 ms (DUP!)

This was previously fixed by commit 5dbebbb4 ("net: bcmgenet:
Software reset EPHY after power on") but the commit we are reverting was
essentially making this previous commit void, here is why.

Without commit 62469c76 we would have the following scenario after
an ifconfig down then up sequence:

- bcmgenet_open() calls bcmgenet_power_up() to make sure the PHY is
  initialized *before* we get to initialize the UniMAC, this is
  critical to ensure the PHY is in a correct state, priv->phydev is
  valid, this code executes fine

- second time from bcmgenet_mii_probe(), through the normal
  phy_init_hw() call (which arguably could be optimized out)

Everything is fine in that case. With commit 62469c76, we would have
the following scenario to happen after an ifconfig down then up
sequence:

- bcmgenet_close() calls phy_disonnect() which makes dev->phydev become
  NULL

- when bcmgenet_open() executes again and calls bcmgenet_mii_reset() from
  bcmgenet_power_up() to initialize the internal PHY, the NULL check
  becomes true, so we do not reset the PHY, yet we keep going on and
  initialize the UniMAC, causing MAC activity to occur

- we call bcmgenet_mii_reset() from bcmgenet_mii_probe(), but this is
  too late, the PHY is botched, and causes the above bogus pings/packets
  transmission/reception to occur
Reported-by: NJaedon Shin <jaedon.shin@gmail.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The FEC receive accelerator (RACC) supports shifting the data payload of
received packets by 16-bits, which aligns the payload (IP header) on a
4-byte boundary, which is, if not required, at least strongly suggested
by the Linux networking layer.

Without this patch, a huge number of alignment faults will be taken by the
IP stack, as seen in /proc/cpu/alignment:

	~/$ cat /proc/cpu/alignment
	User:		0
	System:		72645 (inet_gro_receive+0x104/0x27c)
	Skipped:	0
	Half:		0
	Word:		0
	DWord:		0
	Multi:		72645
	User faults:	3 (fixup+warn)

This patch was suggested by Andrew Lunn in this message to linux-netdev:
	http://marc.info/?l=linux-arm-kernel&m=147465452108384&w=2

and adapted from a patch by Russell King from 2014:
	http://git.arm.linux.org.uk/cgit/linux-arm.git/commit/?id=70d8a8aSigned-off-by: NEric Nelson <eric@nelint.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According to the i.MX27 reference manual, this SoC does not have support
for the receive accelerator (RACC) register at offset 0x1C4.

	http://cache.nxp.com/files/32bit/doc/ref_manual/MCIMX27RM.pdfSigned-off-by: NEric Nelson <eric@nelint.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According to the i.MX25 reference manual, this SoC does not have support
for the receive accelerator (RACC) register at offset 0x1C4.

http://www.nxp.com/files/dsp/doc/ref_manual/IMX25RM.pdfSigned-off-by: NEric Nelson <eric@nelint.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Current implementation of joydev's input_device_id table recognizes only
devices with ABS_X, ABS_WHEEL or ABS_THROTTLE axes as joysticks.

There are joystick devices that do not have those axes, for example TRC
Rudder device. The device in question has ABS_Z, ABS_RX and ABS_RY axes
causing it not being detected as joystick.

This patch adds ABS_Z to the input_device_id list allowing devices with
ABS_Z axis to be detected correctly.
Signed-off-by: NVille Ranki <ville.ranki@iki.fi>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch avoids that the following memory leak is triggered if
use_blk_mq is disabled after a SCSI host has been allocated by the
ib_srp driver and before the same SCSI host is freed:

unreferenced object 0xffff8803a168c568 (size 256):
  backtrace:
    [<ffffffff81620c95>] kmemleak_alloc+0x45/0xa0
    [<ffffffff811bb104>] __kmalloc_node+0x1e4/0x400
    [<ffffffff81309fe4>] blk_mq_alloc_tag_set+0xb4/0x230
    [<ffffffff814731b7>] scsi_mq_setup_tags+0xc7/0xd0
    [<ffffffff81469c26>] scsi_add_host_with_dma+0x216/0x2d0
    [<ffffffffa064bef5>] srp_create_target+0xe55/0x13d0 [ib_srp]
    [<ffffffff8143ce23>] dev_attr_store+0x13/0x20
    [<ffffffff8125f030>] sysfs_kf_write+0x40/0x50
    [<ffffffff8125e397>] kernfs_fop_write+0x137/0x1c0
    [<ffffffff811d8c13>] __vfs_write+0x23/0x140
    [<ffffffff811d92e0>] vfs_write+0xb0/0x190
    [<ffffffff811da5b4>] SyS_write+0x44/0xa0
    [<ffffffff8162c8a5>] entry_SYSCALL_64_fastpath+0x18/0xa8

Fixes: 9aa9cc42 ("scsi: remove the disable_blk_mq host flag")
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The definition of the flush hint table as:

	void __iomem *flush_wpq[0][0];

...passed the unit test, but is broken as flush_wpq[0][1] and
flush_wpq[1][0] refer to the same entry.  Fix this to use a helper that
calculates a slot in the table based on the geometry of flush hints in
the region.  This is important to get right since virtualization
solutions use this mechanism to trigger hypervisor flushes to platform
persistence.
Reported-by: NDave Jiang <dave.jiang@intel.com>
Tested-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Otherwise, nvme_rdma_stop_and_clear_queue() will incorrectly
try to stop/free rdma qps/cm_ids that are already freed.

Fixes: e89ca58f ("nvme-rdma: add DELETING queue flag")
Reported-by: NSteve Wise <swise@opengridcomputing.com>
Tested-by: NSteve Wise <swise@opengridcomputing.com>
Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJens Axboe <axboe@fb.com>

If the i2c device is already runtime suspended, if qup_i2c_suspend is
executed during suspend-to-idle or suspend-to-ram it will result in the
following splat:

WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90
Modules linked in:

CPU: 3 PID: 1593 Comm: bash Tainted: G        W       4.8.0-rc3 #14
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
PC is at clk_core_unprepare+0x80/0x90
LR is at clk_unprepare+0x28/0x40
pc : [<ffff0000086eecf0>] lr : [<ffff0000086f0c58>] pstate: 60000145
Call trace:
 clk_core_unprepare+0x80/0x90
 qup_i2c_disable_clocks+0x2c/0x68
 qup_i2c_suspend+0x10/0x20
 platform_pm_suspend+0x24/0x68
 ...

This patch fixes the issue by executing qup_i2c_pm_suspend_runtime
conditionally in qup_i2c_suspend.
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Reviewed-by: NAndy Gross <andy.gross@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

Commit 815806e3 ("regmap: drop cache if the bus transfer error")
added a call to regcache_drop_region() to error path in
_regmap_raw_write(). However that path runs with regmap lock taken,
and regcache_drop_region() tries to re-take it, causing a deadlock.
Fix that by calling map->cache_ops->drop() directly.
Signed-off-by: NNikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] https://github.com/victronenergy/venus/issues/24Signed-off-by: NSergei Miroshnichenko <sergeimir@emcraft.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

When there is no Card which is set to "broken-cd", it's displayed a clock
information continuously. Because it's polling for detecting card.
This patch is fixed this problem.

Fixes: 65257a0d ("mmc: dw_mmc: remove UBSAN warning in dw_mci_setup_bus()")
Reported-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This reverts commit aff51175.

The commit caused fence timeouts within nvc0_screen_destroy and most likely
other places as well.

The most obvious effect is, that userspace processes take minutes to
actually quit.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch cleans devlink resources by calling devlink_port_unregister()
to avoid the following issues:

- Kernel panic when triggering reset flow.
- Memory leak due to unfreed resources in mlx4_init_port_info().

Fixes: 09d4d087 ("mlx4: Implement devlink interface")
Signed-off-by: NKamal Heib <kamalh@mellanox.com>
Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The cached value of the last selected channel prevents retries on the
next call, even on failure to update the selected channel. Fix that.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

For the DSMs where the kernel knows the format of the output buffer and
originates those DSMs from within the kernel, return -EIO for any
non-zero status.  If the BIOS is indicating a status that we do not know
how to handle, fail the DSM.

Cc: <stable@vger.kernel.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The internal alloc_nvdimm_map() helper might fail, particularly if the
memory region is already busy.  Report request_mem_region() failures and
check for the failure.
Reported-by: NRyan Chen <ryan.chan105@gmail.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

the eg20t driver call request_irq() function before the pch_base_address,
base address of i2c controller's register, is assigned an effective value.

there is one possible scenario that an interrupt which isn't inside eg20t
arrives immediately after request_irq() is executed when i2c controller
shares an interrupt number with others. since the interrupt handler
pch_i2c_handler() has already active as shared action, it will be called
and read its own register to determine if this interrupt is from itself.

At that moment, since base address of i2c registers is not remapped
in kernel space yet,so the INT handler will access an illegal address
and then a error occurs.
Signed-off-by: NYadi.hu <yadi.hu@windriver.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org