As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Reviewed-by: NTomas Henzl <thenzl@redhat.com>
Cc: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com>
Cc: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
Cc: support@lsi.com
Cc: DL-MPTFusionLinux@lsi.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: NChristoph Hellwig <hch@lst.de>

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Reviewed-by: NTomas Henzl <thenzl@redhat.com>
Cc: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com>
Cc: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
Cc: support@lsi.com
Cc: DL-MPTFusionLinux@lsi.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: NChristoph Hellwig <hch@lst.de>

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Acked-by: NKashyap Desai <Kashyap.desai@avagotech.com>
Cc: Neela Syam Kolli <megaraidlinux@lsi.com>
Cc: linux-scsi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Currently the driver fails to analize MSI-X re-enablement
status on resuming and always assumes the success. This
update checks the MSI-X initialization result and fails
to resume if MSI-Xs re-enablement failed.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Acked-by: NKashyap Desai <Kashyap.desai@avagotech.com>
Cc: Neela Syam Kolli <megaraidlinux@lsi.com>
Cc: linux-scsi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: NChristoph Hellwig <hch@lst.de>

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Acked-by: N"Stephen M. Cameron" <scameron@beardog.cce.hp.com>
Cc: iss_storagedev@hp.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Currently the driver falls back to INTx mode when MSI-X
initialization failed. This is a suboptimal behaviour
for chips that also support MSI. This update changes that
behaviour and falls back to MSI mode in case MSI-X mode
initialization failed.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Acked-by: N"Stephen M. Cameron" <scameron@beardog.cce.hp.com>
Cc: iss_storagedev@hp.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: NChristoph Hellwig <hch@lst.de>

port_detect is only called from the module_init routine and thus implicitly
serialized, so remove the driver lock which was held over potentially
sleeping function calls.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reported-by: NArthur Marsh <arthur.marsh@internode.on.net>
Tested-by: NArthur Marsh <arthur.marsh@internode.on.net>
Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: NHannes Reinecke <hare@suse.de>

SCSI Well-known logical units generally don't have any scsi driver
associated with it which means no one will call scsi_autopm_put_device()
on these wlun scsi devices and this would result in keeping the
corresponding scsi device always active (hence LLD can't be suspended as
well). Same exact problem can be seen for other scsi device representing
normal logical unit whose driver is yet to be loaded. This patch fixes
the above problem with this approach:

- make the scsi_autopm_put_device call at the end of scsi_sysfs_add_sdev
  to make it balance out the get earlier in the function.
- let drivers do paired get/put calls in their probe methods.
Signed-off-by: NSubhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: NDolev Raviv <draviv@codeaurora.org>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

The SCSI specification requires that the second Command Data Byte
should contain the LUN value in its high-order bits if the recipient
device reports SCSI level 2 or below.  Nevertheless, some USB
mass-storage devices use those bits for other purposes in
vendor-specific commands.  Currently Linux has no way to send such
commands, because the SCSI stack always overwrites the LUN bits.

Testing shows that Windows 7 and XP do not store the LUN bits in the
CDB when sending commands to a USB device.  This doesn't matter if the
device uses the Bulk-Only or UAS transports (which virtually all
modern USB mass-storage devices do), as these have a separate
mechanism for sending the LUN value.

Therefore this patch introduces a flag in the Scsi_Host structure to
inform the SCSI midlayer that a transport does not require the LUN
bits to be stored in the CDB, and it makes usb-storage set this flag
for all devices using the Bulk-Only transport.  (UAS is handled by a
separate driver, but it doesn't really matter because no SCSI-2 or
lower device is at all likely to use UAS.)

The patch also cleans up the code responsible for storing the LUN
value by adding a bitflag to the scsi_device structure.  The test for
whether to stick the LUN value in the CDB can be made when the device
is probed, and stored for future use rather than being made over and
over in the fast path.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NTiziano Bacocco <tiziano.bacocco@gmail.com>
Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
Acked-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Add a use_cmd_list flag in struct Scsi_Host to request keeping track of
all outstanding commands per device.

Default behaviour is not to keep track of cmd_list per sdev, as this may
introduce lock contention. (overhead is more on multi-node NUMA.), and
only enable it on the two drivers that need it.
Signed-off-by: NKashyap Desai <kashyap.desai@avagotech.com>
Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

The SYNCHRONIZE_CACHE command is a medium write command and hence can
fail when the device is write protected. Avoid sending such commands by
making sure that write-cache-enable is disabled even though the device
claim to support it.
Signed-off-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: NDolev Raviv <draviv@codeaurora.org>
Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: NVenkatesh Srinivas <venkateshs@google.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Convert spaces to tabs in kernel-doc notation.
Correct duplicated (copy-paste) kernel-doc comments that are incorrect.
Fix kernel-doc warning:

Warning(..//drivers/scsi/scsi_error.c:1647): No description found for parameter 'shost'
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Reviewed-by: NEwan D. Milne <emilne@redhat.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu.
This function is used by iscsi drivers and userspace to send iscsi PDUs/
commands. For login commands, we have a set buffer size. For all other
commands we do not support data buffers.

This was reported by Dan Carpenter here:
http://www.spinics.net/lists/linux-scsi/msg66838.htmlReported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Reviewed-by: NSagi Grimberg <sagig@mellanox.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

The NTB translate register must have the value to be BAR size aligned.
This alignment check make sure that the DMA memory allocated has the
proper alignment. Another requirement for NTB to function properly with
memory window BAR size greater or equal to 4M is to use the CMA feature
in 3.16 kernel with the appropriate CONFIG_CMA_ALIGNMENT and
CONFIG_CMA_SIZE_MBYTES set.
Signed-off-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

The detection of an uneven number of queues on the given memory windows
was not correct.  The mw_num is zero based and the mod should be
division to spread them evenly over the mw's.
Signed-off-by: NJon Mason <jon.mason@intel.com>

double-free is a bad thing
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The DT-based panel capabilities selection was picking up
a subset of available modes based on hardware configuration.
This was wrong, as the capabilities describe available
memory models and adapt the display controller to them
that the RGB output is wired up correctly (as in: R and
B components are not swapped).

This patch fixes it by removing the unnecessary limitation.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Type error and cause AST2000 cannot be detected correctly
Signed-off-by: NY.C. Chen <yc_chen@aspeedtech.com>
Reviewed-by: NEgbert Eich <eich@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some config settings like 3rd TX chips will not get correctly
if the extended reg is protected
Signed-off-by: NY.C. Chen <yc_chen@aspeedtech.com>
Reviewed-by: NEgbert Eich <eich@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Resuming from hibernate (S4) will restart and re-initialize xHC.
The device contexts are freed and will be re-allocated later during device reset.

Usb core will disable link pm in device resume before device reset, which will
try to change the max exit latency, accessing the device contexts before they are re-allocated.

There is no need to zero (disable) the max exit latency when disabling hw lpm
for a freshly re-initialized xHC. So check that device context exists before
doing anything. The max exit latency will be set again after device reset when usb core
enables the link pm.
Reported-by: NImre Deak <imre.deak@intel.com>
Tested-by: NImre Deak <imre.deak@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The xhci driver will OOPS on resume from S2/S3 if dma_alloc_coherent()
is out of memory. This is a result of two things:
1. xhci_mem_cleanup() in xhci-mem.c free's xhci->lpm_command if
it's not NULL, but doesn't set it to NULL after the free.
2. xhci_mem_cleanup() is called twice on resume, once for normal
restart and once from xhci_mem_init() if dma_alloc_coherent() fails,
resulting in a free of xhci->lpm_command that has already been freed.
The fix is to set xhci->lpm_command to NULL after freeing it.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If xhci initialization fails before the roothub bandwidth
domains (xhci->rh_bw[i]) are allocated it will oops when
trying to access rh_bw members in xhci_mem_cleanup().
Reported-by: NManuel Reimer <manuel.reimer@gmx.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware
seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/
SCM chip set. However its firmware restricts it to only work with Jaz
drives.

On connecting the cable a message like this appears four times in the log:
 reset full speed USB device number 4 using uhci_hcd

That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it.
Signed-off-by: NMark Knibbs <markk@clara.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Cc: stable@vger.kernel.org # 3.16
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If VRAM carveout is used, due to no IOMMU, we should have a default
value for msm.vram so that we don't simply crash.
Reported-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Reported-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NRob Clark <robdclark@gmail.com>

There is currently a nested function in Russel King's tree
for the msm HDMI driver.

The last nested function was removed from the Linux kernel
when the Thinkpad driver was fixed.

I believe nested functions are not desired upstream, and it
also breaks compilation with clang so here is a patch to
change the nested function into static function. The patch
works with both clang and gcc.
Signed-off-by: NMark Charlebois <charlebm@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We need to make sure to deqeueue the descriptor from the active list before
we call vchan_cookie_complete(). Also we need obviously only set chan->desc
to NULL after we stopped using it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Initialize USB PHY after every Link controller reset

Cc: 3.16+ <stable@vger.kernel.org>
Cc: Tim Bird <tbird20d@gmail.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NIvan T. Ivanov <iivanov@mm-sol.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.

Cc: 3.16+ <stable@vger.kernel.org>
Cc: Tim Bird <tbird20d@gmail.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NIvan T. Ivanov <iivanov@mm-sol.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During surprise device hotplug removal tests, it was observed that
hub_events may try to call usb_lock_device on a device that has already
been freed. Protect the usb_device by taking out a reference (under the
hub_event_lock) when hub_events pulls it off the list, returning the
reference after hub_events is finished using it.
Signed-off-by: NJoe Lawrence <joe.lawrence@stratus.com>
Suggested-by: David Bulkow <david.bulkow@stratus.com> for using kref
Suggested-by: Alan Stern <stern@rowland.harvard.edu> for placement
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are a large numbers of issues with ASM1051 devices in uas mode:

1) They do not support REPORT SUPPORTED OPERATION CODES

2) They use out of spec 8 byte status iu-s when they have no sense data,
   switching to normal 16 byte status iu-s when they do have sense data.

3) They hang / crash when combined with some disks, e.g. a Crucial M500 ssd.

4) They hang / crash when stressed (through e.g. sg_reset --bus) with disks
   with which then normally do work (once 1 & 2 are worked around).

Where as in BOT mode they appear to work fine, so the best way forward with
these devices is to just blacklist them for uas usage.

Unfortunately this is easier said then done. as older versions of the ASM1053
(which works fine) use the same usb-id as the ASM1051.

When connected over USB-3 the 2 can be told apart by the number of streams
they support. So this patch adds some less then pretty code to disable uas for
the ASM1051. When connected over USB-2, simply disable uas alltogether for
devices with the shared usb-id.

Cc: stable@vger.kernel.org # 3.16
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When running a 32-bit inputattach utility in a 64-bit system, there will be
error code "inputattach: can't set device type". This is caused by the
serport device driver not supporting compat_ioctl, so that SPIOCSTYPE ioctl
fails.

Cc: stable@vger.kernel.org
Signed-off-by: NJohn Sung <penmount.touch@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

[Nick Dyer: reworked to move free of input device into separate function
and only call in paths that require it.]
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When a writeback or a promotion of a block is completed, the cell of
that block is removed from the prison, the block is marked as clean, and
the clear_dirty() callback of the cache policy is called.

Unfortunately, performing those actions in this order allows an incoming
new write bio for that block to come in before clearing the dirty status
is completed and therefore possibly causing one of these two scenarios:

Scenario A:

Thread 1                      Thread 2
cell_defer()                  .
- cell removed from prison    .
- detained bios queued        .
.                             incoming write bio
.                             remapped to cache
.                             set_dirty() called,
.                               but block already dirty
.                               => it does nothing
clear_dirty()                 .
- block marked clean          .
- policy clear_dirty() called .

Result: Block is marked clean even though it is actually dirty. No
writeback will occur.

Scenario B:

Thread 1                      Thread 2
cell_defer()                  .
- cell removed from prison    .
- detained bios queued        .
clear_dirty()                 .
- block marked clean          .
.                             incoming write bio
.                             remapped to cache
.                             set_dirty() called
.                             - block marked dirty
.                             - policy set_dirty() called
- policy clear_dirty() called .

Result: Block is properly marked as dirty, but policy thinks it is clean
and therefore never asks us to writeback it.
This case is visible in "dmsetup status" dirty block count (which
normally decreases to 0 on a quiet device).

Fix these issues by calling clear_dirty() before calling cell_defer().
Incoming bios for that block will then be detained in the cell and
released only after clear_dirty() has completed, so the race will not
occur.

Found by inspecting the code after noticing spurious dirty counts
(scenario B).
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Acked-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

Add the IRQCHIP_SKIP_SET_WAKE flag to baytrail gpio irq_chip
to resolve unbalaced IRQ wake disable warnings.
Suggested-by: NBorun Fu <borun.fu@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix to return -ENOMEM from the workqueue alloc error handling
case instead of 0, as done elsewhere in this function.
Reviewed-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>

drivers/block/rbd.c: In function ‘rbd_dev_device_setup’:
drivers/block/rbd.c:5090:19: warning: format not a string literal and no format arguments [-Wformat-security]
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NIlya Dryomov <ilya.dryomov@inktank.com>

ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of
physical buttons, instead they generate primary button click when user
presses somewhat hard on the surface of the touchpad. Unfortunately they
also report primary button click whenever there are 2 or more contacts
on the pad, messing up all multi-finger gestures (2-finger scrolling,
multi-finger tapping, etc). To cope with this behavior we introduce a
delay (currently 50 msecs) in reporting primary press in case more
contacts appear.

Cc: stable@vger.kernel.org
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When trying to use the matrix-keypad driver with GPIO drivers that
require nested irq handlers (e.g. I2C GPIO adapters like PCA9554),
request_irq() fails because the GPIO driver requires a threaded
interrupt handler.

Use request_any_context_irq() to be able to use any GPIO driver as
keypad driver.
Signed-off-by: NLothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>