If a device fails in a way that causes pending request to take a while
to complete, md will not be able to immediately remove it from the
array in remove_and_add_spares.
It will then incorrectly look like a spare device and md will try to
recover it even though it is failed.
This leads to a recovery process starting and instantly aborting over
and over again.

We should check if the device is faulty before considering it to be a
spare.  This will avoid trying to start a recovery that cannot
proceed.

This bug was introduced in 2.6.26 so that patch is suitable for any
kernel since then.

Cc: stable@kernel.org
Reported-by: NJim Paradis <james.paradis@stratus.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

When auditing the locking in i915_gem.c (for a prospective change which
I then abandoned), I noticed two places where struct_mutex is not held
across GEM object manipulations that would usually require it.

Since one is in initial setup and the other in driver unload, I'm
guessing the mutex is not required for either; but post a patch in case
it is.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The interface to ->truncate_range is changing very slightly: once "tmpfs:
take control of its truncate_range" has been applied, this can be applied.
 For now there is only a slight inefficiency while this remains unapplied,
but it will soon become essential for managing shmem's use of swap.

Change i915_gem_object_truncate() to use shmem_truncate_range() directly:
which should also spare i915 later change if we switch from
inode_operations->truncate_range to file_operations->fallocate.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Soon tmpfs will stop supporting ->readpage and read_cache_page_gfp(): once
"tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
be applied to ease the transition.

Make i915_gem_object_get_pages_gtt() use shmem_read_mapping_page_gfp() in
the one place it's needed; elsewhere use shmem_read_mapping_page(), with
the mapping's gfp_mask properly initialized.

Forget about __GFP_COLD: since tmpfs initializes its pages with memset,
asking for a cold page is counter-productive.

Include linux/shmem_fs.h also in drm_gem.c: with shmem_file_setup() now
declared there too, we shall remove the prototype from linux/mm.h later.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Soon tmpfs will stop supporting ->readpage and read_mapping_page(): once
"tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
be applied to ease the transition.

ttm_tt_swapin() and ttm_tt_swapout() use shmem_read_mapping_page() in
place of read_mapping_page(), since their swap_space has been created with
shmem_file_setup().
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fis the warning

  drivers/tty/serial/8250_pci.c:1457: warning: initialization from incompatible pointer type

Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix this section mismatch:

  WARNING: drivers/misc/ioc4.o(.data+0x144): Section mismatch in reference from the variable ioc4_load_modules_work to the function .devinit.text:ioc4_load_modules()
  The variable ioc4_load_modules_work references
  the function __devinit ioc4_load_modules()
  If the reference is valid then annotate the
  variable with __init* or __refdata (see linux/init.h) or name the variable:
  *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

This one is potentially fatal; by the time ioc4_load_modules is invoked
it may already have been freed.  For that reason ioc4_load_modules_work
can't be turned to __devinitdata but also because it's referenced in
ioc4_exit.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Acked-by: NBrent Casavant <bcasavan@sgi.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix this section mismatch:

  WARNING: drivers/leds/leds-lp5523.o(.text+0x12f4): Section mismatch in reference from the function lp5523_probe() to the function .init.text:lp5523_init_led()
  The function lp5523_probe() references
  the function __init lp5523_init_led().
  This is often because lp5523_probe lacks a __init
  annotation or the annotation of lp5523_init_led is wrong.

Fixing this one triggers one more mismatch, fix that one as well.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix this section mismatch:

  WARNING: drivers/leds/leds-lp5521.o(.text+0xf2c): Section mismatch in reference from the function lp5521_probe() to the function .init.text:lp5521_init_led()
  The function lp5521_probe() references
  the function __init lp5521_init_led().
  This is often because lp5521_probe lacks a __init
  annotation or the annotation of lp5521_init_led is wrong.

Fixing this mismatch triggers one more mismatch, fix that one as well.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We observed the crash point count going negative in cases where the
crash point is hit multiple times before the check of "count == 0" is
done.  Because of this we never call lkdtm_do_action().  This patch just
adds a spinlock to protect count.
Reported-by: NTapan Dhimant <tdhimant@akamai.com>
Signed-off-by: NJosh Hunt <johunt@akamai.com>
Acked-by: NAnkita Garg <ankita@in.ibm.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

PT7C4338 chip is being manufactured by Pericom Technology Inc.  It is a
serial real-time clock which provides:

1) Low-power clock/calendar.
2) Programmable square-wave output.

It has 56 bytes of nonvolatile RAM.  Its register set is same as that of
rtc device: DS1307.
Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com>
Acked-by: NTimur Tabi <timur@freescale.com>
Reviewed-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some platforms do not have virt_to_bus(), so properly depend on
CONFIG_VIRT_TO_BUS for the Comedi drivers that need this function.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

As David points out, the driver is also broken on SPARC, so might
as well just only enable it on platforms where people have reported it
working, instead of trying to list all of the ones where it doesn't
work, as the working platform list is much smaller...
Reported-by: NDavid Miller <davem@davemloft.net>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Henry Ptasinski <henryp@broadcom.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Roland Vossen <rvossen@broadcom.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Right now, bad things happen if you try to build these drivers for the
PPC platform as it seems that the code only has been tested and built on
the MIPS big endian platform.

So disable it on the PPC32 and PPC64 platforms for now, hopefully this
will be resolved in the future as I'm sure someone will want to use
these chips with that platform someday.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Henry Ptasinski <henryp@broadcom.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Roland Vossen <rvossen@broadcom.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On m68k (which doesn't support generic hardirqs yet):

drivers/staging/iio/industrialio-trigger.c: In function ‘iio_trigger_poll’:
drivers/staging/iio/industrialio-trigger.c:180: error: implicit declaration of function ‘generic_handle_irq’
drivers/staging/iio/industrialio-trigger.c: In function ‘iio_trigger_poll_chained’:
drivers/staging/iio/industrialio-trigger.c:200: error: implicit declaration of function ‘handle_nested_irq’
drivers/staging/iio/industrialio-trigger.c: In function ‘iio_trig_release’:
drivers/staging/iio/industrialio-trigger.c:379: error: implicit declaration of function ‘irq_modify_status’
drivers/staging/iio/industrialio-trigger.c:382: error: implicit declaration of function ‘irq_set_chip’
drivers/staging/iio/industrialio-trigger.c:384: error: implicit declaration of function ‘irq_set_handler’
drivers/staging/iio/industrialio-trigger.c:388: error: implicit declaration of function ‘irq_free_descs’
drivers/staging/iio/industrialio-trigger.c: In function ‘iio_trig_subirqmask’:
drivers/staging/iio/industrialio-trigger.c:402: error: implicit declaration of function ‘irq_data_get_irq_chip’
drivers/staging/iio/industrialio-trigger.c:402: warning: initialization makes pointer from integer without a cast
drivers/staging/iio/industrialio-trigger.c: In function ‘iio_trig_subirqunmask’:
drivers/staging/iio/industrialio-trigger.c:411: warning: initialization makes pointer from integer without a cast
drivers/staging/iio/industrialio-trigger.c: In function ‘iio_allocate_trigger’:
drivers/staging/iio/industrialio-trigger.c:432: error: implicit declaration of function ‘irq_alloc_descs’
drivers/staging/iio/industrialio-trigger.c:455: error: ‘handle_simple_irq’ undeclared (first use in this function)
drivers/staging/iio/industrialio-trigger.c:455: error: (Each undeclared identifier is reported only once
drivers/staging/iio/industrialio-trigger.c:455: error: for each function it appears in.)

Hence IIO_TRIGGER should depend on GENERIC_HARDIRQS.
But as IIO_TRIGGER and IIO_RING_BUFFER form a maze of dependencies and selects,
just make the whole IIO subsystem depend on GENERIC_HARDIRQS.

This dependency also covers !S390, so that one can be removed again.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

wait_event_interruptible_timeout return value was wrongly used.
The remaining timeout was used as the error code.
This fix translated wait_event_interruptible_timeout return value
into error code that can be propagated.

[10291.674121] pci_pm_suspend(): mei_pci_suspend+0x0/0x8b [mei] returns 2500
It's thinkpad t400 with
00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07)
Reported-by: NArkadiusz Miskiewicz <a.miskiewicz@gmail.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix build by moving enum list outside of
#ifdef CONFIG_IIO_RING_BUFFER.

drivers/staging/iio/accel/adis16201_core.c:413: error: 'ADIS16201_SCAN_SUPPLY' undeclared here (not in a function)
drivers/staging/iio/accel/adis16201_core.c:417: error: 'ADIS16201_SCAN_TEMP' undeclared here (not in a function)
drivers/staging/iio/accel/adis16201_core.c:422: error: 'ADIS16201_SCAN_ACC_X' undeclared here (not in a function)
drivers/staging/iio/accel/adis16201_core.c:427: error: 'ADIS16201_SCAN_ACC_Y' undeclared here (not in a function)
drivers/staging/iio/accel/adis16201_core.c:432: error: 'ADIS16201_SCAN_AUX_ADC' undeclared here (not in a function)
drivers/staging/iio/accel/adis16201_core.c:436: error: 'ADIS16201_SCAN_INCLI_X' undeclared here (not in a function)
drivers/staging/iio/accel/adis16201_core.c:441: error: 'ADIS16201_SCAN_INCLI_Y' undeclared here (not in a function)

vers/staging/iio/accel/adis16203_core.c:374: error: 'ADIS16203_SCAN_SUPPLY' undeclared here (not in a function)
drivers/staging/iio/accel/adis16203_core.c:378: error: 'ADIS16203_SCAN_AUX_ADC' undeclared here (not in a function)
drivers/staging/iio/accel/adis16203_core.c:382: error: 'ADIS16203_SCAN_INCLI_X' undeclared here (not in a function)
drivers/staging/iio/accel/adis16203_core.c:388: error: 'ADIS16203_SCAN_INCLI_Y' undeclared here (not in a function)
drivers/staging/iio/accel/adis16203_core.c:392: error: 'ADIS16203_SCAN_TEMP' undeclared here (not in a function)
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On architectures that don't define PAGE_KERNEL_NOCACHE, the Comedi driver turns
into tragedy:

  CC [M]  drivers/staging/comedi/drivers.o
drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
drivers/staging/comedi/drivers.c:505:41: error: ‘PAGE_KERNEL_NOCACHE’ undeclared (first use in this function)
drivers/staging/comedi/drivers.c:505:41: note: each undeclared identifier is rep orted only once for each function it appears in
make[3]: *** [drivers/staging/comedi/drivers.o] Error 1

Restrict the driver to only those architectures that define PAGE_KERNEL_NOCACHE.

PAGE_KERNEL_NOCACHE is a kludge - some system architectures such as SGI IP27
are even uable to offer uncached operation - at least in the way an unwitting
driver might assume.  I haven't looked in details how the driver is using
the area vmaped with PAGE_KERNEL_NOCACHE but maybe doing it XFS-style using
cached memory and the flush_kernel_vmap_range / invalidate_kernel_vmap_range
APIs in conjunction with the DMA API is a practical alternative.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Reported-by: NDavid Miller <davem@davemloft.net>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix lots more build errors in staging/iio when CONFIG_IIO_RING_BUFFER
is not enabled by moving enums and defines outside of the
CONFIG_IIO_RING_BUFFER ifdef block.

Examples (one from each driver; there were 116 total errors):

drivers/staging/iio/accel/adis16204_core.c:437: error: 'ADIS16204_SCAN_SUPPLY' undeclared here (not in a function)
drivers/staging/iio/accel/adis16209_core.c:410: error: 'ADIS16209_SCAN_SUPPLY' undeclared here (not in a function)
drivers/staging/iio/gyro/adis16260_core.c:420: error: 'ADIS16260_SCAN_GYRO' undeclared here (not in a function)
drivers/staging/iio/imu/adis16400_core.c:565: error: 'ADIS16400_SCAN_SUPPLY' undeclared here (not in a function)
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

SCSI defines discard alignment as the offset to the first
optimal discard.  In the case of SD/MMC, that is always zero
which is the default.

SCSI defines discard granularity as a hint of a optimal
discard size.  That is much better expressed by the MMC
"preferred erase size" (pref_erase) field.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

For example, an eMMC with 2 boot partitions will have 3 threads.
The names change from:

   40 ?        00:00:00 mmcqd/0
   41 ?        00:00:00 mmcqd/0
   42 ?        00:00:00 mmcqd/0

to:

   40 ?        00:00:00 mmcqd/0
   41 ?        00:00:00 mmcqd/0boot0
   42 ?        00:00:00 mmcqd/0boot1
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: Andrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The erase timeout calculation may depend on clock rate
which is zero if the clock is gated, so use
mmc_host_clk_rate() which allows for that case.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The MMC block driver and other drivers (e.g. mmc-test) will expect
the card to be switched to the User Data Area eMMC partition when
they start.  Hence the MMC block driver should ensure it is that
way when it is removed.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: Andrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

mmc_sdio_power_restore() skips some steps that are performed in other
power-related codepaths which are necessary to fully reset the card.
Without this, runtime PM fails for SD8686 SDIO wifi on OLPC XO-1.5.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

HAVE_EFFICIENT_UNALIGNED_ACCESS is a config option, therefore it needs
the CONFIG_ before it when used by the preprocessor.
Signed-off-by: NJames Hogan <james@albanarts.com>
Acked-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: NChris Ball <cjb@laptop.org>

Don't try to allocate DMA resources if the platform didn't specify
positive DMA slave IDs.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit b6147490 ("mmc: tmio: split core functionality, DMA and
MFD glue") broke handling of the TMIO_MMC_WRPROTECT_DISABLE flag by
the tmio-mmc driver. This patch restores the original behaviour.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: <stable@kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Don't use the returned sg_len from dma_map_sg() as inparameter
to dma_unmap_sg(). Use the original sg_len for both dma_map_sg
and dma_unmap_sg according to the documentation in DMA-API.txt.
Signed-off-by: NPer Forlin <per.forlin@linaro.org>
Reviewed-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The OMAP HSMMC driver uses an ocr_mask to determine the list of voltages
supported by the card. It populates this mask based on the list of
voltages supported by the regulator that supplies the voltage.

Commit 64be9782 (omap4 hsmmc: Update ocr mask for MMC2 for regulator
to use) passed a fixed ocr_mask from the OMAP4 SDP board file to limit
the voltage to 2.9-3.0 Volts, and updated the driver to use this mask
if provided, instead of using the regulator's supported voltages.

However the commit is buggy - the ocr_mask is overridden by the
regulator's capabilities anyway. Fix this.

(The bug shows up when a system-wide suspend is attempted on the OMAP4
SDP/Blaze platforms. The eMMC card comes up at 3V, but drops to 1.65V
after the system resumes).
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Acked-by: NBalaji T K <balajitk@ti.com>
Acked-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Signed-off-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

After commit e1866b33 "PM / Runtime: Rework runtime PM handling
during driver removal" was introduced, the driver core stopped
incrementing the runtime PM usage counter of the device during
the invocation of the ->remove() callback.

This indirectly broke SDIO's runtime PM path during driver removal,
because no one calls _put_sync() anymore after ->remove() completes.

This means that the power of runtime-PM-managed SDIO cards is kept
high after their driver is removed (even if it was powered down
beforehand).

Fix that by directly calling _put_sync() when the last usage
counter is downref'ed by the SDIO bus.
Reported-and-tested-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

while merging hid-stantum into hid-multitouch, I did not correctly copy/paste
the VIDs for those devices.  This patch fixes it.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In case a device does not provide the feature "Maximum Contact Count",
or set it at 0, the maxcontacts field may be at 0 while calling
input_mt_init_slots.

This patch ensures that hid-multitouch will allways report
ABS_MT_SLOT and ABS_MT_TRACKING_ID to the user space.

This corrects a bug found with some Ilitek devices that has been
integrated in 3.0-rc0.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch enables support for Marvell IDE PATA controllers found on
Asus P8P67LE motherboard.

The formatting has been corrected and I also received a report from two
users of this motherboard that the patch works.
Signed-off-by: NPaweł Drewniak <czajernia@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

A voltage value of 0xff01 requires that the driver
look up the max voltage for the board based using the
atom SetVoltage command table.

Setting the proper voltage should fix stability on
some newer asics.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The field is encoded:
0 = 4 banks
1 = 8 banks
2 = 16 banks
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch fixes the following conversion specification warning for size_t

drivers/target/tcm_fc/tfc_io.c: In function ‘ft_queue_data_in’:
drivers/target/tcm_fc/tfc_io.c:209: warning: format ‘%x’ expects type ‘unsigned int’, but argument 5 has type ‘size_t’
Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

There is a typo here, it should be an unlock instead of a lock.  The
original code will deadlock.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes a bug in ft_send_tm() that was incorrectly calling
ft_get_lun_for_cmd() -> transport_get_lun_for_cmd(), instead of using
transport_get_lun_for_tmr() for the proper struct se_lun lookup
that was triggering an OOPs in the se_cmd->tmr_req failure path.

This patch fixes the issue by re-arranging the codepath where
transport_get_lun_for_tmr() is called after tmr request is allocated and
made it available as part of se_cmd.

It also drops the now unnecessary ft_get_lun_for_cmd() unpacking code, and
uses scsilun_to_int() directly ahead of transport_get_lun_for_cmd() and
transport_get_lun_for_tmr() usage.
Signed-off-by: NPatil, Kiran <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NNicholas A. Bellinger <nab@linux-iscsi.org>

This patch fixes a number of cases in target core using an incorrectly

	if (strlen(foo) > SOME_MAX_SIZE)

As strlen() returns the number of characters in the string not counting
the NULL character at the end.  So if you do something like:

        char buf[10];

        if (strlen("0123456789") > 10)
                return -ETOOLONG;
        snprintf(buf, 10, "0123456789");
        printf("%s\n", buf);

then the last "9" gets chopped off and only "012345678" is printed.

Plus I threw in one small related cleanup.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>