linux-toradex.git/drivers/scsi/arcmsr, branch v4.4.156

scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware

2016-11-10T15:36:35+00:00

commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f upstream.

The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller
firmware. Depending on how drive caches are handled internally by
controller firmware this could potentially lead to data integrity
problems.

Ensure that cache flushes are passed to the controller.

[mkp: applied by hand and removed unused vars]

Signed-off-by: Ching Huang 
Reported-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: arcmsr: Simplify user_len checking

2016-10-22T10:26:56+00:00

commit 4bd173c30792791a6daca8c64793ec0a4ae8324f upstream.

Do the user_len check first and then the ver_addr allocation so that we
can save us the kfree() on the error path when user_len is >
ARCMSR_API_DATA_BUFLEN.

Signed-off-by: Borislav Petkov 
Cc: Marco Grassi 
Cc: Dan Carpenter 
Cc: Tomas Henzl 
Cc: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer()

2016-10-22T10:26:55+00:00

commit 7bc2b55a5c030685b399bb65b6baa9ccc3d1f167 upstream.

We need to put an upper bound on "user_len" so the memcpy() doesn't
overflow.

Reported-by: Marco Grassi 
Signed-off-by: Dan Carpenter 
Reviewed-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

arcmsr: fixes not release allocated resource

2016-09-15T06:27:45+00:00

[ Upstream commit 98f90debc2b64a40a416dd9794ac2d8de6b43af2 ]

Releasing allocated resource if get configuration data failed.

Signed-off-by: Ching Huang 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Hannes Reinicke 
Reviewed-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

arcmsr: fixed getting wrong configuration data

2016-09-15T06:27:45+00:00

[ Upstream commit 251e2d25bfb72b69edd414abfa42a41191d9657a ]

Fixed getting wrong configuration data of adapter type B and type D.

Signed-off-by: Ching Huang 
Reviewed-by: Hannes Reinicke 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'libnvdimm-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm

2015-09-08T21:35:59+00:00

Pull libnvdimm updates from Dan Williams:
 "This update has successfully completed a 0day-kbuild run and has
  appeared in a linux-next release.  The changes outside of the typical
  drivers/nvdimm/ and drivers/acpi/nfit.[ch] paths are related to the
  removal of IORESOURCE_CACHEABLE, the introduction of memremap(), and
  the introduction of ZONE_DEVICE + devm_memremap_pages().

  Summary:

   - Introduce ZONE_DEVICE and devm_memremap_pages() as a generic
     mechanism for adding device-driver-discovered memory regions to the
     kernel's direct map.

     This facility is used by the pmem driver to enable pfn_to_page()
     operations on the page frames returned by DAX ('direct_access' in
     'struct block_device_operations').

     For now, the 'memmap' allocation for these "device" pages comes
     from "System RAM".  Support for allocating the memmap from device
     memory will arrive in a later kernel.

   - Introduce memremap() to replace usages of ioremap_cache() and
     ioremap_wt().  memremap() drops the __iomem annotation for these
     mappings to memory that do not have i/o side effects.  The
     replacement of ioremap_cache() with memremap() is limited to the
     pmem driver to ease merging the api change in v4.3.

     Completion of the conversion is targeted for v4.4.

   - Similar to the usage of memcpy_to_pmem() + wmb_pmem() in the pmem
     driver, update the VFS DAX implementation and PMEM api to provide
     persistence guarantees for kernel operations on a DAX mapping.

   - Convert the ACPI NFIT 'BLK' driver to map the block apertures as
     cacheable to improve performance.

   - Miscellaneous updates and fixes to libnvdimm including support for
     issuing "address range scrub" commands, clarifying the optimal
     'sector size' of pmem devices, a clarification of the usage of the
     ACPI '_STA' (status) property for DIMM devices, and other minor
     fixes"

* tag 'libnvdimm-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: (34 commits)
  libnvdimm, pmem: direct map legacy pmem by default
  libnvdimm, pmem: 'struct page' for pmem
  libnvdimm, pfn: 'struct page' provider infrastructure
  x86, pmem: clarify that ARCH_HAS_PMEM_API implies PMEM mapped WB
  add devm_memremap_pages
  mm: ZONE_DEVICE for "device memory"
  mm: move __phys_to_pfn and __pfn_to_phys to asm/generic/memory_model.h
  dax: drop size parameter to ->direct_access()
  nd_blk: change aperture mapping from WC to WB
  nvdimm: change to use generic kvfree()
  pmem, dax: have direct_access use __pmem annotation
  dax: update I/O path to do proper PMEM flushing
  pmem: add copy_from_iter_pmem() and clear_pmem()
  pmem, x86: clean up conditional pmem includes
  pmem: remove layer when calling arch_has_wmb_pmem()
  pmem, x86: move x86 PMEM API to new pmem.h header
  libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option
  pmem: switch to devm_ allocations
  devres: add devm_memremap
  libnvdimm, btt: write and validate parent_uuid
  ...

cleanup IORESOURCE_CACHEABLE vs ioremap()

2015-08-11T03:07:06+00:00

Quoting Arnd:
    I was thinking the opposite approach and basically removing all uses
    of IORESOURCE_CACHEABLE from the kernel. There are only a handful of
    them.and we can probably replace them all with hardcoded
    ioremap_cached() calls in the cases they are actually useful.

All existing usages of IORESOURCE_CACHEABLE call ioremap() instead of
ioremap_nocache() if the resource is cacheable, however ioremap() is
uncached by default. Clearly none of the existing usages care about the
cacheability. Particularly devm_ioremap_resource() never worked as
advertised since it always fell back to plain ioremap().

Clean this up as the new direction we want is to convert
ioremap_() usages to memremap(..., flags).

Suggested-by: Arnd Bergmann 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dan Williams

scsi/arcmsr: Fix typos in error log

2015-08-07T12:31:26+00:00

This fixes some typos in one of the error logs.

Signed-off-by: Nik Nyby 
Signed-off-by: Jiri Kosina

scsi: drop reason argument from ->change_queue_depth

2014-11-24T13:45:27+00:00

Drop the now unused reason argument from the ->change_queue_depth method.
Also add a return value to scsi_adjust_queue_depth, and rename it to
scsi_change_queue_depth now that it can be used as the default
->change_queue_depth implementation.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Mike Christie 
Reviewed-by: Hannes Reinecke

scsi: don't set tagging state from scsi_adjust_queue_depth

2014-11-12T10:19:43+00:00

Remove the tagged argument from scsi_adjust_queue_depth, and just let it
handle the queue depth.  For most drivers those two are fairly separate,
given that most modern drivers don't care about the SCSI "tagged" status
of a command at all, and many old drivers allow queuing of multiple
untagged commands in the driver.

Instead we start out with the ->simple_tags flag set before calling
->slave_configure, which is how all drivers actually looking at
->simple_tags except for one worke anyway.  The one other case looks
broken, but I've kept the behavior as-is for now.

Except for that we only change ->simple_tags from the ->change_queue_type,
and when rejecting a tag message in a single driver, so keeping this
churn out of scsi_adjust_queue_depth is a clear win.

Now that the usage of scsi_adjust_queue_depth is more obvious we can
also remove all the trivial instances in ->slave_alloc or ->slave_configure
that just set it to the cmd_per_lun default.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Mike Christie 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Martin K. Petersen