As part of device initialization sequence, sending NOP OUT UPIU and
waiting for NOP IN UPIU response is mandatory. This confirms that the
device UFS Transport (UTP) layer is functional and the host can configure
the device with further commands. Add support for sending NOP OUT UPIU to
check the
This patch series replace the previous Query Request and NOP patches:
[PATCH 1/8] scsi: ufs: add support for query
[PATCH 6/8] scsi: ufs: Add support for sending NOP OUT UPIU
[PATCH 7/8] scsi: ufs: Set fDeviceInit flag to initiate device initialization
Major difference -
Sending the query
From: Dolev Raviv dra...@codeaurora.org
Allow UFS device to complete its initialization and accept
SCSI commands by setting fDeviceInit flag. The device may take
time for this operation and hence the host should poll until
fDeviceInit flag is toggled to zero. This step is mandated by
UFS device
There is a possible race condition in the hardware when the abort
command is issued to terminate the ongoing SCSI command as described
below:
- A bit in the door-bell register is set in the controller for a
new SCSI command.
- In some rare situations, before controller get a chance to issue
Background operations in the UFS device can be disabled by
the host to reduce the response latency of transfer requests.
Add support for enabling/disabling the background operations
during runtime suspend/resume of the device.
If the device is in critical need of BKOPS it will raise an
Add runtime PM helpers to suspend/resume UFS controller at runtime.
Enable runtime PM by default for pci and platform drivers as the
initialized hardware can suspend if it is not used after bootup.
Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org
---
drivers/scsi/ufs/ufshcd-pci.c|
The first patch fixes many issues with current task management handling
in UFSHCD driver. Others improve error handling in various scenarios.
These patches depends on:
[PATCH V4 1/2] scsi: ufs: Add support for sending NOP OUT UPIU
[PATCH V4 2/2] scsi: ufs: Set fDeviceInit flag to initiate device
Add host assisted background operations for UFS device and runtime PM
helpers for ufshcd platform and pci glue drivers. The background operations
are disabled during runtime resume and enabled when the device is idle and
runtime suspended.
These patches depends on:
[PATCH V4 1/2] scsi: ufs: Add
Currently, sending Task Management (TM) command to the card might
be broken in some scenarios as listed below:
Problem: If there are more than 8 TM commands the implementation
returns error to the caller.
Fix: Wait for one of the slots to be emptied and send the command.
Problem:
Error handling in UFS driver is broken and resets the host controller
for fatal errors without re-initialization. Correct the fatal error
handling sequence according to UFS Host Controller Interface (HCI)
v1.1 specification.
o Upon determining fatal error condition the host controller may hang
As of now SCSI initiated error handling is broken because,
the reset APIs don't try to bring back the device initialized and
ready for further transfers.
In case of timeouts, the scsi error handler takes care of handling aborts
and resets. Improve the error handling in such scenario by resetting
On Sat, July 20, 2013, Sujit Reddy Thumma wrote:
On 7/19/2013 7:26 PM, Seungwon Jeon wrote:
On Tue, July 09, 2013 Sujit Reddy Thumma wrote:
Currently, sending Task Management (TM) command to the card might
be broken in some scenarios as listed below:
Problem: If there are more than 8 TM
On Sat, July 20, 2013, Sujit Reddy Thumma wrote:
On 7/19/2013 7:27 PM, Seungwon Jeon wrote:
On Tue, July 09, 2013, Sujit Reddy Thumma wrote:
As of now SCSI initiated error handling is broken because,
the reset APIs don't try to bring back the device initialized and
ready for further
On Sat, July 20, 2013, Sujit Reddy Thumma wrote:
On 7/19/2013 7:28 PM, Seungwon Jeon wrote:
On Tue, July 09, 2013, Sujit Reddy Thumma wrote:
Error handling in UFS driver is broken and resets the host controller
for fatal errors without re-initialization. Correct the fatal error
handling
On 7/23/2013 2:04 PM, Seungwon Jeon wrote:
On Sat, July 20, 2013, Sujit Reddy Thumma wrote:
On 7/19/2013 7:28 PM, Seungwon Jeon wrote:
On Tue, July 09, 2013, Sujit Reddy Thumma wrote:
Error handling in UFS driver is broken and resets the host controller
for fatal errors without
On 7/23/2013 1:54 PM, Seungwon Jeon wrote:
On Sat, July 20, 2013, Sujit Reddy Thumma wrote:
On 7/19/2013 7:26 PM, Seungwon Jeon wrote:
On Tue, July 09, 2013 Sujit Reddy Thumma wrote:
Currently, sending Task Management (TM) command to the card might
be broken in some scenarios as listed below:
On 7/23/2013 1:57 PM, Seungwon Jeon wrote:
On Sat, July 20, 2013, Sujit Reddy Thumma wrote:
On 7/19/2013 7:27 PM, Seungwon Jeon wrote:
On Tue, July 09, 2013, Sujit Reddy Thumma wrote:
As of now SCSI initiated error handling is broken because,
the reset APIs don't try to bring back the device
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Please apply via the subsystem-tree.
drivers/scsi/ufs/ufshcd-pltfrm.c |6 --
1 file changed, 6 deletions(-)
diff --git
I hit this during driver probe with the latest fnic updates (this trace
is from a backport into a distro kernel, but the issue is the same).
BUG: sleeping function called from invalid context at mm/slab.c:3113
in_atomic(): 0, irqs_disabled(): 1, pid: 610, name: work_for_cpu
INFO: lockdep is
The slot-response value may not be aligned, so should be read
using the appropriate kernel unaligned accessor.
Signed-off-by: Chris Metcalf cmetc...@tilera.com
---
drivers/scsi/mvsas/mv_sas.c | 5 +++--
drivers/scsi/mvsas/mv_sas.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff
On Tue, 2013-07-23 at 16:50 -0400, Chris Metcalf wrote:
The slot-response value may not be aligned, so should be read
using the appropriate kernel unaligned accessor.
Hm, institutional memory re-presenting the wrong patch? However, I am
reminded to push the right one in spite of no ack from
On 7/23/2013 5:00 PM, James Bottomley wrote:
On Tue, 2013-07-23 at 16:50 -0400, Chris Metcalf wrote:
The slot-response value may not be aligned, so should be read
using the appropriate kernel unaligned accessor.
Hm, institutional memory re-presenting the wrong patch? However, I am
reminded
It seems some iSCSI targets (including the Linux kernel target) close
the TCP connection from the target side immediately after processing a
session logout.
When a TCP FIN comes in right after the iSCSI logout response,
iscsi_sw_sk_state_check sees the local socket as not yet being in
CLOSE_WAIT
On Tue, 2013-07-23 at 17:17 -0400, Chris Metcalf wrote:
On 7/23/2013 5:00 PM, James Bottomley wrote:
On Tue, 2013-07-23 at 16:50 -0400, Chris Metcalf wrote:
The slot-response value may not be aligned, so should be read
using the appropriate kernel unaligned accessor.
Hm, institutional
On 7/23/2013 6:33 PM, James Bottomley wrote:
On Tue, 2013-07-23 at 17:17 -0400, Chris Metcalf wrote:
On 7/23/2013 5:00 PM, James Bottomley wrote:
On Tue, 2013-07-23 at 16:50 -0400, Chris Metcalf wrote:
The slot-response value may not be aligned, so should be read
using the appropriate kernel
On Tue, 2013-07-23 at 18:40 -0400, Chris Metcalf wrote:
On 7/23/2013 6:33 PM, James Bottomley wrote:
On Tue, 2013-07-23 at 17:17 -0400, Chris Metcalf wrote:
On 7/23/2013 5:00 PM, James Bottomley wrote:
On Tue, 2013-07-23 at 16:50 -0400, Chris Metcalf wrote:
The slot-response value may not
This looks like a candidate for stable:
commit 16da05b1158d1bcb31656e636a8736a663b1cf1f
Author: Andi Kleen a...@firstfloor.org
Date: Mon Sep 3 20:50:30 2012 +0200
[SCSI] Fix incorrect memset in bnx2fc_parse_fcp_rsp
Typically this sort of bug can result in leaking kernel memory to
Dear Friend
It is my interest to contact you in respect of our client from your country who
died 3 years ago leaving some huge amount of money in our bank without any next
of kin or link to his family. I shall explain in details when I read your
reply.You are my first contact, I shall wait for
28 matches
Mail list logo
