linux-stable.git/drivers, branch v4.17.6

staging: comedi: quatech_daqp_cs: fix no-op loop daqp_ao_insn_write()

2018-07-11T14:31:34+00:00

commit 1376b0a2160319125c3a2822e8c09bd283cd8141 upstream.

There is a '>' vs '<' typo so this loop is a no-op.

Fixes: d35dcc89fc93 ("staging: comedi: quatech_daqp_cs: fix daqp_ao_insn_write()")
Signed-off-by: Dan Carpenter 
Reviewed-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Change erase functions to check chip good only

2018-07-11T14:31:34+00:00

commit 79ca484b613041ca223f74b34608bb6f5221724b upstream.

Currently the functions use to check both chip ready and good.
But the chip ready is not enough to check the operation status.
So change this to check the chip good instead of this.
About the retry functions to make sure the error handling remain it.

Signed-off-by: Tokunori Ikegami 
Reviewed-by: Joakim Tjernlund 
Cc: Chris Packham 
Cc: Brian Norris 
Cc: David Woodhouse 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-mtd@lists.infradead.org
Cc: stable@vger.kernel.org
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Change erase functions to retry for error

2018-07-11T14:31:34+00:00

commit 45f75b8a919a4255f52df454f1ffdee0e42443b2 upstream.

For the word write functions it is retried for error.
But it is not implemented to retry for the erase functions.
To make sure for the erase functions change to retry as same.

This is needed to prevent the flash erase error caused only once.
It was caused by the error case of chip_good() in the do_erase_oneblock().
Also it was confirmed on the MACRONIX flash device MX29GL512FHT2I-11G.
But the error issue behavior is not able to reproduce at this moment.
The flash controller is parallel Flash interface integrated on BCM53003.

Signed-off-by: Tokunori Ikegami 
Reviewed-by: Joakim Tjernlund 
Cc: Chris Packham 
Cc: Brian Norris 
Cc: David Woodhouse 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-mtd@lists.infradead.org
Cc: stable@vger.kernel.org
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Change definition naming to retry write operation

2018-07-11T14:31:33+00:00

commit 85a82e28b023de9b259a86824afbd6ba07bd6475 upstream.

The definition can be used for other program and erase operations also.
So change the naming to MAX_RETRIES from MAX_WORD_RETRIES.

Signed-off-by: Tokunori Ikegami 
Reviewed-by: Joakim Tjernlund 
Cc: Chris Packham 
Cc: Brian Norris 
Cc: David Woodhouse 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-mtd@lists.infradead.org
Cc: stable@vger.kernel.org
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

dm: prevent DAX mounts if not supported

2018-07-11T14:31:33+00:00

commit dbc626597c39b24cefce09fbd8e9dea85869a801 upstream.

Currently device_supports_dax() just checks to see if the QUEUE_FLAG_DAX
flag is set on the device's request queue to decide whether or not the
device supports filesystem DAX.  Really we should be using
bdev_dax_supported() like filesystems do at mount time.  This performs
other tests like checking to make sure the dax_direct_access() path works.

We also explicitly clear QUEUE_FLAG_DAX on the DM device's request queue if
any of the underlying devices do not support DAX.  This makes the handling
of QUEUE_FLAG_DAX consistent with the setting/clearing of most other flags
in dm_table_set_restrictions().

Now that bdev_dax_supported() explicitly checks for QUEUE_FLAG_DAX, this
will ensure that filesystems built upon DM devices will only be able to
mount with DAX if all underlying devices also support DAX.

Signed-off-by: Ross Zwisler 
Fixes: commit 545ed20e6df6 ("dm: add infrastructure for DAX support")
Cc: stable@vger.kernel.org
Acked-by: Dan Williams 
Reviewed-by: Toshi Kani 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

dax: check for QUEUE_FLAG_DAX in bdev_dax_supported()

2018-07-11T14:31:33+00:00

commit 15256f6cc4b44f2e70503758150267fd2a53c0d6 upstream.

Add an explicit check for QUEUE_FLAG_DAX to __bdev_dax_supported().  This
is needed for DM configurations where the first element in the dm-linear or
dm-stripe target supports DAX, but other elements do not.  Without this
check __bdev_dax_supported() will pass for such devices, letting a
filesystem on that device mount with the DAX option.

Signed-off-by: Ross Zwisler 
Suggested-by: Mike Snitzer 
Fixes: commit 545ed20e6df6 ("dm: add infrastructure for DAX support")
Cc: stable@vger.kernel.org
Acked-by: Dan Williams 
Reviewed-by: Toshi Kani 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

dax: change bdev_dax_supported() to support boolean returns

2018-07-11T14:31:33+00:00

commit 80660f20252d6f76c9f203874ad7c7a4a8508cf8 upstream.

The function return values are confusing with the way the function is
named. We expect a true or false return value but it actually returns
0/-errno.  This makes the code very confusing. Changing the return values
to return a bool where if DAX is supported then return true and no DAX
support returns false.

Signed-off-by: Dave Jiang 
Signed-off-by: Ross Zwisler 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong 
Signed-off-by: Greg Kroah-Hartman

fs: allow per-device dax status checking for filesystems

2018-07-11T14:31:33+00:00

commit ba23cba9b3bdc967aabdc6ff1e3e9b11ce05bb4f upstream.

Change bdev_dax_supported so it takes a bdev parameter.  This enables
multi-device filesystems like xfs to check that a dax device can work for
the particular filesystem.  Once that's in place, actually fix all the
parts of XFS where we need to be able to distinguish between datadev and
rtdev.

This patch fixes the problem where we screw up the dax support checking
in xfs if the datadev and rtdev have different dax capabilities.

Signed-off-by: Darrick J. Wong 
[rez: Re-added __bdev_dax_supported() for !CONFIG_FS_DAX cases]
Signed-off-by: Ross Zwisler 
Reviewed-by: Eric Sandeen 
Signed-off-by: Greg Kroah-Hartman

i2c: smbus: kill memory leak on emulated and failed DMA SMBus xfers

2018-07-11T14:31:32+00:00

commit 9aa613674f89d01248ae2e4afe691b515ff8fbb6 upstream.

If DMA safe memory was allocated, but the subsequent I2C transfer
fails the memory is leaked. Plug this leak.

Fixes: 8a77821e74d6 ("i2c: smbus: use DMA safe buffers for emulated SMBus transactions")
Signed-off-by: Peter Rosin 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

i2c: core: smbus: fix a potential missing-check bug

2018-07-11T14:31:32+00:00

commit 8e03477cb709b73a2c1e1f4349ee3b7b33c50416 upstream.

In i2c_smbus_xfer_emulated(), the function i2c_transfer() is invoked to
transfer i2c messages. The number of actual transferred messages is
returned and saved to 'status'. If 'status' is negative, that means an
error occurred during the transfer process. In that case, the value of
'status' is an error code to indicate the reason of the transfer failure.
In most cases, i2c_transfer() can transfer 'num' messages with no error.
And so 'status' == 'num'. However, due to unexpected errors, it is probable
that only partial messages are transferred by i2c_transfer(). As a result,
'status' != 'num'. This special case is not checked after the invocation of
i2c_transfer() and can potentially lead to unexpected issues in the
following execution since it is expected that 'status' == 'num'.

This patch checks the return value of i2c_transfer() and returns an error
code -EIO if the number of actual transferred messages 'status' is not
equal to 'num'.

Signed-off-by: Wenwen Wang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman