RE: [PATCH 4/5] scsi: ufs: rework link start-up process
On Monday, April 29, 2013, Sujit Reddy Thumma wrote:
On 4/26/2013 10:44 AM, Seungwon Jeon wrote:
On Thursday, April 25, 2013 , Sujit Reddy Thumma wrote:
On 4/24/2013 9:36 PM, Seungwon Jeon wrote:
Link start-up requires long time with multiphase handshakes
between UFS host and device. This affects driver's probe time.
This patch let link start-up run asynchronously.
And completion time of uic command is defined to avoid a
permanent wait.
I have similar patch posted few days back scsi: ufs: Generalize UFS
Interconnect Layer (UIC) command support which does a bit more (mutex,
error handling) than what is done here. Can that be used/improved?
I completed to check your patch to compare it now.
Though it's just my thought, the patch I sent is more intuitive on the
whole.
Considering other dme operations which I have introduced, it looks like
matched.
There are lot of code duplications you might want to minimize building a
DME command.
Of course, you may disagree.
But I think the part of mutex is needed. It's a good point.
In case of error handling, I didn't catch nothing special.
Rather, handling link lost case is not proper.
When ufs host meets link lost status, it should start with dme_reset not
retried dme_linkstartup.
In section 7.2.1 (Host Controller Initialization) of JESD223A UFS HCI
v1.1 specification I find this -
6. Sent DME_LINKSTARTUP command to start the link startup procedure
9. Check value of HCS.DP and make sure that there is a device attached
to the Link. If presence of a device is detected, go to step 10;
otherwise, resend the DME_LINKSTARTUP command after IS.ULLS has been set
to 1 (Go to step 6). IS.ULLS equal 1 indicates that the UFS Device is
ready for a link startup.
Going by the spec. just retrying with DME_LINKSTARTUP is correct.
Yes, as you quoted above, HCI standard mentions that.
Also, the following is mentioned.
UIC Link Lost Status (ULLS) corresponds to the UniPro DME_LINKLOST.ind
I just referred unipro specification.
When DME_LINKLOST.ind is generated, this affects the Link is put in the
LinkLost state.
Unipro spec says that DME User must apply a DME_RESET to redo the boot sequence.
If there is misunderstood meaning and I have something to miss, we can discuss
more.
Please let me know.
In addition, it doesn't say what happens if IS.ULLS never sets to 1.
Probably, the case which never happens.
And it would be good if link start-up procedure is done in separate
process, not in driver probe.
True.
If it's all right with you, I'd like to update lock mechanism for uic
command.
I can add your signed-off. Please let me know your opinion.
I would like to get a third opinion as both the patches needs modifications.
Some comments below:
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/scsi/ufs/ufshcd.c | 114
+---
drivers/scsi/ufs/ufshcd.h |6 ++-
2 files changed, 89 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index efe2256..76ff332 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -38,6 +38,7 @@
#define UFSHCD_ENABLE_INTRS(UTP_TRANSFER_REQ_COMPL |\
UTP_TASK_REQ_COMPL |\
UFSHCD_ERROR_MASK)
+#define UIC_CMD_TIMEOUT 100
enum {
UFSHCD_MAX_CHANNEL = 0,
@@ -357,13 +358,15 @@ static inline void ufshcd_hba_capabilities(struct
ufs_hba *hba)
}
/**
- * ufshcd_send_uic_command - Send UIC commands to unipro layers
+ * ufshcd_dispatch_uic_cmd - Dispatch UIC commands to unipro layers
* @hba: per adapter instance
* @uic_command: UIC command
*/
static inline void
-ufshcd_send_uic_command(struct ufs_hba *hba, struct uic_command
*uic_cmnd)
+ufshcd_dispatch_uic_cmd(struct ufs_hba *hba, struct uic_command
*uic_cmnd)
{
+ init_completion(uic_cmnd-done);
+
/* Write Args */
ufshcd_writel(hba, REG_UIC_COMMAND_ARG_1, uic_cmnd-argument1);
ufshcd_writel(hba, REG_UIC_COMMAND_ARG_2, uic_cmnd-argument2);
@@ -375,6 +378,45 @@ ufshcd_send_uic_command(struct ufs_hba *hba, struct
uic_command *uic_cmnd)
}
/**
+ * ufshcd_wait_for_uic_cmd - Wait complectioin of UIC command
+ * @hba: per adapter instance
+ * @uic_command: UIC command
+ *
+ * Returns 0 only if success.
+ */
+static int ufshcd_wait_for_uic_cmd(struct ufs_hba *hba)
+{
+ struct uic_command *uic_cmd = hba-active_uic_cmd;
+ int ret;
+
+ if (wait_for_completion_timeout(uic_cmd-done,
+ msecs_to_jiffies(UIC_CMD_TIMEOUT)))
+ ret = ufshcd_get_uic_cmd_result(hba);
+ else
+ ret = -ETIMEDOUT;
+
+ return ret;
+}
+
+/**
+ * ufshcd_ready_uic_cmd - Check if controller is ready
+ *
Re: [PATCH 4/5] scsi: ufs: rework link start-up process
On 4/29/2013 3:54 PM, Seungwon Jeon wrote:
On Monday, April 29, 2013, Sujit Reddy Thumma wrote:
On 4/26/2013 10:44 AM, Seungwon Jeon wrote:
On Thursday, April 25, 2013 , Sujit Reddy Thumma wrote:
On 4/24/2013 9:36 PM, Seungwon Jeon wrote:
Link start-up requires long time with multiphase handshakes
between UFS host and device. This affects driver's probe time.
This patch let link start-up run asynchronously.
And completion time of uic command is defined to avoid a
permanent wait.
I have similar patch posted few days back scsi: ufs: Generalize UFS
Interconnect Layer (UIC) command support which does a bit more (mutex,
error handling) than what is done here. Can that be used/improved?
I completed to check your patch to compare it now.
Though it's just my thought, the patch I sent is more intuitive on the whole.
Considering other dme operations which I have introduced, it looks like matched.
There are lot of code duplications you might want to minimize building a
DME command.
Of course, you may disagree.
But I think the part of mutex is needed. It's a good point.
In case of error handling, I didn't catch nothing special.
Rather, handling link lost case is not proper.
When ufs host meets link lost status, it should start with dme_reset not
retried dme_linkstartup.
In section 7.2.1 (Host Controller Initialization) of JESD223A UFS HCI
v1.1 specification I find this -
6. Sent DME_LINKSTARTUP command to start the link startup procedure
9. Check value of HCS.DP and make sure that there is a device attached
to the Link. If presence of a device is detected, go to step 10;
otherwise, resend the DME_LINKSTARTUP command after IS.ULLS has been set
to 1 (Go to step 6). IS.ULLS equal 1 indicates that the UFS Device is
ready for a link startup.
Going by the spec. just retrying with DME_LINKSTARTUP is correct.
Yes, as you quoted above, HCI standard mentions that.
Also, the following is mentioned.
UIC Link Lost Status (ULLS) corresponds to the UniPro DME_LINKLOST.ind
I just referred unipro specification.
When DME_LINKLOST.ind is generated, this affects the Link is put in the
LinkLost state.
Unipro spec says that DME User must apply a DME_RESET to redo the boot sequence.
If there is misunderstood meaning and I have something to miss, we can discuss
more.
Please let me know.
Yes, it looks like the two specs. are conflicting each other. I guess we
need to take this to Jedec for clarification. Meanwhile, to be on safe
side can we add a retry mechanism that does ufshcd_hba_enable() before
sending DME_LINKSTARTUP again? This way we can be sure that the
DME_RESET and DME_ENABLE is taken care by the host reset itself.
In addition, it doesn't say what happens if IS.ULLS never sets to 1.
Probably, the case which never happens.
And it would be good if link start-up procedure is done in separate process,
not in driver probe.
True.
If it's all right with you, I'd like to update lock mechanism for uic command.
I can add your signed-off. Please let me know your opinion.
I would like to get a third opinion as both the patches needs modifications.
Some comments below:
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/scsi/ufs/ufshcd.c | 114
+---
drivers/scsi/ufs/ufshcd.h |6 ++-
2 files changed, 89 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index efe2256..76ff332 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -38,6 +38,7 @@
#define UFSHCD_ENABLE_INTRS (UTP_TRANSFER_REQ_COMPL |\
UTP_TASK_REQ_COMPL |\
UFSHCD_ERROR_MASK)
+#define UIC_CMD_TIMEOUT100
enum {
UFSHCD_MAX_CHANNEL = 0,
@@ -357,13 +358,15 @@ static inline void ufshcd_hba_capabilities(struct ufs_hba
*hba)
}
/**
- * ufshcd_send_uic_command - Send UIC commands to unipro layers
+ * ufshcd_dispatch_uic_cmd - Dispatch UIC commands to unipro layers
* @hba: per adapter instance
* @uic_command: UIC command
*/
static inline void
-ufshcd_send_uic_command(struct ufs_hba *hba, struct uic_command *uic_cmnd)
+ufshcd_dispatch_uic_cmd(struct ufs_hba *hba, struct uic_command *uic_cmnd)
{
+ init_completion(uic_cmnd-done);
+
/* Write Args */
ufshcd_writel(hba, REG_UIC_COMMAND_ARG_1, uic_cmnd-argument1);
ufshcd_writel(hba, REG_UIC_COMMAND_ARG_2, uic_cmnd-argument2);
@@ -375,6 +378,45 @@ ufshcd_send_uic_command(struct ufs_hba *hba, struct
uic_command *uic_cmnd)
}
/**
+ * ufshcd_wait_for_uic_cmd - Wait complectioin of UIC command
+ * @hba: per adapter instance
+ * @uic_command: UIC command
+ *
+ * Returns 0 only if success.
+ */
+static int ufshcd_wait_for_uic_cmd(struct ufs_hba *hba)
+{
+ struct uic_command *uic_cmd = hba-active_uic_cmd;
+ int ret;
+
+ if (wait_for_completion_timeout(uic_cmd-done,
+
Re: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
On Friday 26 April 2013, Masanori Goto wrote: 2013/4/25 Arnd Bergmann a...@arndb.de ARM cannot handle udelay for more than 2 miliseconds, so we should use mdelay instead for those. Singed-off-by: GOTO Masanori go...@debian.or.jp Thanks. I assume you mean Acked-by, not Singed-off as in burnt or Signed-off as a notification that you have applied it to your own git tree. I'll keep the patch with an your Acked-by line in my tree unless James wants to apply to the scsi tree. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WRITE SAME failed. Manually zeroing with 3w-xxxx driver
After update to 3.8 dmesg is spammed with: kernel: [ 280.272094] 3w-: scsi8: Unknown scsi opcode: 0x41 kernel: [ 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel: [ 280.272110] sd 8:0:0:0: [sda] kernel: [ 280.272112] Result: hostbyte=0x04 driverbyte=0x00 kernel: [ 280.272114] sd 8:0:0:0: [sda] CDB: kernel: [ 280.272116] cdb[0]=0x41: 41 00 10 09 aa 22 00 00 08 00 kernel: [ 280.272123] end_request: I/O error, dev sda, sector 269068834 kernel: [ 280.272130] sda6: WRITE SAME failed. Manually zeroing. [..] This goes on and on. I am not familiar with block layer or scsi drivers, so I don't know if this is an issue with the 3w- driver or the block layer. I've hacked around this by reverting block: Make blkdev_issue_zeroout use WRITE SAME (579e8f3c7b2ecf7db91398d942d76457a3ddba21), as this hw doesn't support write_same anyway. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WRITE SAME failed. Manually zeroing with 3w-xxxx driver
Florian == Florian Westphal f...@strlen.de writes: Florian After update to 3.8 dmesg is spammed with: kernel: [ Florian 280.272094] 3w-: scsi8: Unknown scsi opcode: 0x41 kernel: [ Florian 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel: Interesting. It looks like the 3ware handles this at the driver level instead of passing the command through to the disk and letting it fail. That in turn means that the logic we have in place to disable WS when the disk does not support it does not get triggered. The driver should really fill out the sense buffer in that case. Could you please test the patch below? Florian This goes on and on. The second question is what it is that's issuing these zeroouts at boot? Which filesystem are you using? What's your DM/MD config? -- Martin K. Petersen Oracle Linux Engineering 3w-: Create sense buffer for unsupported commands Make the driver return appropriate sense data when an unsupported operation is queued. This will cause the SCSI layer to stop issuing the offending command. Reported-by: Florian Westphal f...@strlen.de CC: adam radford aradf...@gmail.com Signed-off-by: Martin K. Petersen martin.peter...@oracle.com diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c index 56662ae..b9276d1 100644 --- a/drivers/scsi/3w-.c +++ b/drivers/scsi/3w-.c @@ -216,6 +216,7 @@ #include scsi/scsi_host.h #include scsi/scsi_tcq.h #include scsi/scsi_cmnd.h +#include scsi/scsi_eh.h #include 3w-.h /* Globals */ @@ -2009,7 +2010,8 @@ static int tw_scsi_queue_lck(struct scsi_cmnd *SCpnt, void (*done)(struct scsi_c printk(KERN_NOTICE 3w-: scsi%d: Unknown scsi opcode: 0x%x\n, tw_dev-host-host_no, *command); tw_dev-state[request_id] = TW_S_COMPLETED; tw_state_request_finish(tw_dev, request_id); - SCpnt-result = (DID_BAD_TARGET 16); + SCpnt-result = (DRIVER_SENSE 24) | SAM_STAT_CHECK_CONDITION; + scsi_build_sense_buffer(1, SCpnt-sense_buffer, ILLEGAL_REQUEST, 0x20, 0); done(SCpnt); retval = 0; } -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WRITE SAME failed. Manually zeroing with 3w-xxxx driver
Martin K. Petersen martin.peter...@oracle.com wrote: Florian After update to 3.8 dmesg is spammed with: kernel: [ Florian 280.272094] 3w-: scsi8: Unknown scsi opcode: 0x41 kernel: [ Florian 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel: Interesting. It looks like the 3ware handles this at the driver level instead of passing the command through to the disk and letting it fail. That in turn means that the logic we have in place to disable WS when the disk does not support it does not get triggered. The driver should really fill out the sense buffer in that case. Could you please test the patch below? Sure, I'll report back tomorrow. Thanks for the quick response, Florian -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] Wrap crc_t10dif function all to use crypto transform framework
On Sun, 2013-04-28 at 08:11 +0800, Herbert Xu wrote:
On Fri, Apr 26, 2013 at 09:44:17AM -0700, Tim Chen wrote:
+ old_tfm = crct10dif_tfm;
+ crc_t10dif_newalg = true;
+ /* make sure new alg flag is turned on before starting to switch tfm */
+ mb();
+
+ new_tfm = crypto_alloc_shash(crct10dif, 0, 0);
+ if (IS_ERR(new_tfm))
+ goto done;
+
+ if (old_tfm)
+ if (crypto_tfm_alg_priority(old_tfm-base) =
+ crypto_tfm_alg_priority(new_tfm-base)) {
+ crypto_free_shash(new_tfm);
+ goto done;
+ }
+ crct10dif_tfm = new_tfm;
+ /* make sure update to tfm pointer is completed */
+ mb();
+ crypto_free_shash(old_tfm);
This is not safe at all. You'd need to use something like RCU.
However, I think this is an overkill. Initialising it once should
be enough. If someone really wanted to change things at run-time,
they could always build this as a module and unload/reload it.
If I allocate the transform under the mod init instead, how can I make
sure that the fast version is already registered if I have it compiled
in? It is not clear to me how that's done looking at the libcrc32c
code.
Thanks.
Tim
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND^2] sd: fix infinite kernel/udev loop on non-removable Medium Not Present
On Fri, 2013-04-26 at 10:30 -0700, James Bottomley wrote:
On Fri, 2013-04-26 at 11:39 -0500, Steven J. Magnani wrote:
Commit eface65c336eff420d70beb0fb6787a732e05ffb (2.6.38) altered
set_media_not_present() in a way that prevents the sd driver from
remembering that a non-removable device has reported Medium Not
Present.
This condition can occur on hotplug of a (i.e.) USB Mass Storage
device
whose medium is offline due to an unrecoverable controller error,
but which is otherwise capable of SCSI communication (to download
new
microcode, etc.).
This actually sounds to be a bug somewhere in the device. Only
removable devices are supposed to signal medium not present.
I don't see that spelled out in the -2 family of standards (SAM-2 /
SPC-2 / SBC-2). We're only claiming SPC-2 compliance; perhaps that's
something that got clarified in a later version?
Under these conditions, the changed code results in an infinite loop
between the kernel and udevd. When udevd attempts to open the device
in response to a change notification, a SCSI Medium Not Present
error
occurs which causes the kernel to signal another change. The cycle
repeats until the device is unplugged, resulting in udevd consuming
ever-
increasing amounts of CPU and virtual memory.
One precondition for the infinite loop that got lost between
investigation of the problem and submission of the patch is that the
device has to identify itself BOTH as non-removable and write
protected. The reason is this clause in sd_open():
if (sdev-removable || sdkp-write_prot)
check_disk_change(bdev);
...which causes READ CAPACITY to be issued, to which the device responds
MEDIUM NOT PRESENT, which causes set_media_not_present() to be invoked
and to signal another changed event for userland.
Apologies for the oversight.
Resolve this by remembering media not present whether the device
has
declared itself removable or not.
Signed-off-by: Steven J. Magnani st...@digidescorp.com
---
--- a/drivers/scsi/sd.c 2013-04-12 14:16:12.252531097 -0500
+++ b/drivers/scsi/sd.c 2013-04-12 14:21:55.197216521 -0500
@@ -1298,10 +1298,8 @@ out:
static void set_media_not_present(struct scsi_disk *sdkp)
{
- if (sdkp-media_present)
+ if (sdkp-media_present) {
sdkp-device-changed = 1;
-
- if (sdkp-device-removable) {
sdkp-media_present = 0;
sdkp-capacity = 0;
I don't really like this change because it will affect TUR failure as
well, which looks like it would then zero the capacity of a
non-removable device which we aren't expecting.
I think that concern is easily addressed by tweaking the patch to keep
the sdkp-capacity = 0 statement conditional on
sdkp-device-removable.
Can we dig into what's
going wrong with the device first. It sounds like it really is a
removable device and it just needs to be flagged that way (either that
or the USB SAT is so screwed up that we might need to apply other
blacklists)
Being a USB Mass Storage device, it is removable from a USB sense, but
not I think in a SCSI sense - there is no ejectable cartridge or
anything. Commands like PREVENT ALLOW MEDIUM REMOVAL, which
identification as removable usually triggers, are nonsensical.
The scenario is generally one of these two uncommon use cases:
1. The device has come up in failsafe mode because the user damaged
the normal operational microcode by yanking power during an
operational microcode update. Failsafe mode allows for microcode update,
and not much else.
B. The internal controller has experienced an unrecoverable error
(reported with appropriate sense codes) during normal operation and the
USB connection has since been cycled (disconnected and reconnected; the
device is wall-powered, not bus-powered).
I don't think either is invalid.
I will stipulate that declaring a block device write-protected when no
medium is present does not make a whole lot of sense, and that's
something we will address going forward. However, I do think it's a Bad
Thing (from a security perspective, at minimum) if simply connecting a
device to a machine can bring down the system. The Windows FAT driver
has such issues. Surely Linux can do better, at least in this particular
case where only a minor tweak is needed, not even the addition of
defensive code.
Regards,
Steven J. Magnani I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!
#include standard.disclaimer
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
Oops, you're absolutely correct. Thanks for the follow up! Please change it as follow as you mentioned: Acked-by: GOTO Masanori go...@debian.or.jp Best regrads, -- gotom 2013/4/29 Arnd Bergmann a...@arndb.de: On Friday 26 April 2013, Masanori Goto wrote: 2013/4/25 Arnd Bergmann a...@arndb.de ARM cannot handle udelay for more than 2 miliseconds, so we should use mdelay instead for those. Singed-off-by: GOTO Masanori go...@debian.or.jp Thanks. I assume you mean Acked-by, not Singed-off as in burnt or Signed-off as a notification that you have applied it to your own git tree. I'll keep the patch with an your Acked-by line in my tree unless James wants to apply to the scsi tree. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RESEND^2] sd: fix infinite kernel/udev loop on non-removable Medium Not Present
-Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Steven J. Magnani Sent: Monday, 29 April, 2013 3:46 PM To: James Bottomley Cc: Tejun Heo; linux-ker...@vger.kernel.org; linux-scsi@vger.kernel.org; sta...@vger.kernel.org Subject: Re: [PATCH RESEND^2] sd: fix infinite kernel/udev loop on non- removable Medium Not Present On Fri, 2013-04-26 at 11:39 -0500, Steven J. Magnani wrote: The scenario is generally one of these two uncommon use cases: 1. The device has come up in failsafe mode because the user damaged the normal operational microcode by yanking power during an operational microcode update. Failsafe mode allows for microcode update, and not much else. It may not help shipping devices, but would a new sense key/additional sense code combination be helpful for devices in such a state? NOT READY/LOGICAL UNIT NOT READY, DOWNLOAD MICROCODE REQUIRED
[PATCH]st: clear driver data from struct device when released
Patch to clear driver specific data from struct device associated with
a tape drive when released by st unload or because there was a problem
attaching to the device. Currently set in st_probe but never cleared.
Signed-off-by: Shane Seymour shane.seym...@hp.com
Tested-by: Shane Seymour shane.seym...@hp.com
---
diff -uprN linux-3.9-vanilla/drivers/scsi/st.c linux-3.9/drivers/scsi/st.c
--- linux-3.9-vanilla/drivers/scsi/st.c 2013-04-29 01:36:01.0 +0100
+++ linux-3.9/drivers/scsi/st.c 2013-04-30 02:39:51.0 +0100
@@ -4212,6 +4212,7 @@ static int st_probe(struct device *dev)
out_remove_devs:
remove_cdevs(tpnt);
+ dev_set_drvdata(dev, NULL);
spin_lock(st_index_lock);
idr_remove(st_index_idr, tpnt-index);
spin_unlock(st_index_lock);
@@ -4258,6 +4259,7 @@ static void scsi_tape_release(struct kre
struct scsi_tape *tpnt = to_scsi_tape(kref);
struct gendisk *disk = tpnt-disk;
+ dev_set_drvdata(tpnt-device-sdev_gendev, NULL);
tpnt-device = NULL;
if (tpnt-buffer) {
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] target updates for v3.10-rc1
Hello Linus! Here are the target pending changes for the v3.10-rc1 merge window. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next-merge The highlights this round include: - Add fileio support for WRITE_SAME w/ UNMAP=1 discard (asias) - Add fileio support for UNMAP discard (asias) - Add tcm_vhost hotplug support to work with upstream QEMU vhost-scsi-pci code (asias + mst) - Check for aborted sequence in tcm_fc response path (mdr) - Add initial iscsit_transport support into iscsi-target code (nab) - Refactor iscsi-target RX PDU logic + export request PDU handling (nab) - Refactor iscsi-target TX queue logic + export response PDU creation (nab) - Add new iSCSI Extentions for RDMA (ISER) target driver (Or + nab) The biggest changes revolve around iscsi-target refactoring in order to support the iser-target driver. This includes the conversion of the iscsi-target data-path to use modern se_cmd-cmd_kref counting, and allowing transport independent aspects of RX/TX PDU request/response handling be shared across existing traditional iscsi-target code, and the new iser-target code. Thanks to Or Gerlitz + Mellanox for supporting the iser-target development effort! Thank you, --nab Andy Grover (2): target/iscsi: Remove chap_set_random() target/iscsi: Use ISCSI_LOGIN_CURRENT/NEXT_STAGE macros Asias He (10): target/file: Add WRITE_SAME w/ UNMAP=1 emulation support target/file: Add UNMAP emulation support target/file: Add fd_do_unmap() helper target/iblock: Add iblock_do_unmap() helper target: Add sbc_execute_unmap() helper target/file: Set is_nonrot attribute tcm_vhost: Refactor the lock nesting rule tcm_vhost: Add hotplug/hotunplug support tcm_vhost: Add ioctl to get and set events missed flag tcm_vhost: Enable VIRTIO_SCSI_F_HOTPLUG Jörn Engel (2): qla2xxx: Remove unused function target: Change default sense key of NOT_READY Mark Rustad (1): tcm_fc: Check for aborted sequence Nicholas Bellinger (9): target: Add export of target_get_sess_cmd symbol iscsi-target: Add iscsit_transport API template iscsi-target: Initial traditional TCP conversion to iscsit_transport iscsi-target: Add iser-target parameter keys + setup during login iscsi-target: Add per transport iscsi_cmd alloc/free iscsi-target: Refactor RX PDU logic + export request PDU handling iscsi-target: Refactor TX queue logic + export response PDU creation iscsi-target: Add iser network portal attribute iser-target: Add iSCSI Extensions for RDMA (iSER) target driver Wei Yongjun (1): tcm_fc: using kfree_rcu() to simplify the code drivers/infiniband/Kconfig |1 + drivers/infiniband/Makefile|1 + drivers/infiniband/ulp/isert/Kconfig |5 + drivers/infiniband/ulp/isert/Makefile |2 + drivers/infiniband/ulp/isert/ib_isert.c| 2281 drivers/infiniband/ulp/isert/ib_isert.h| 138 ++ drivers/infiniband/ulp/isert/isert_proto.h | 47 + drivers/scsi/qla2xxx/qla_target.c | 19 - drivers/scsi/qla2xxx/qla_target.h |1 - drivers/target/iscsi/Makefile |3 +- drivers/target/iscsi/iscsi_target.c| 1184 - drivers/target/iscsi/iscsi_target.h|3 +- drivers/target/iscsi/iscsi_target_auth.c | 28 +- drivers/target/iscsi/iscsi_target_configfs.c | 98 +- drivers/target/iscsi/iscsi_target_core.h | 26 +- drivers/target/iscsi/iscsi_target_device.c |7 +- drivers/target/iscsi/iscsi_target_erl1.c | 13 +- drivers/target/iscsi/iscsi_target_login.c | 472 -- drivers/target/iscsi/iscsi_target_login.h |6 + drivers/target/iscsi/iscsi_target_nego.c | 194 +-- drivers/target/iscsi/iscsi_target_nego.h | 11 +- drivers/target/iscsi/iscsi_target_parameters.c | 87 +- drivers/target/iscsi/iscsi_target_parameters.h | 16 +- drivers/target/iscsi/iscsi_target_tmr.c|4 +- drivers/target/iscsi/iscsi_target_tpg.c|6 +- drivers/target/iscsi/iscsi_target_transport.c | 55 + drivers/target/iscsi/iscsi_target_util.c | 53 +- drivers/target/iscsi/iscsi_target_util.h |1 + drivers/target/target_core_file.c | 122 ++- drivers/target/target_core_iblock.c| 108 +- drivers/target/target_core_sbc.c | 85 + drivers/target/target_core_transport.c | 13 +- drivers/target/tcm_fc/tfc_io.c |9 +- drivers/target/tcm_fc/tfc_sess.c |9 +- drivers/vhost/tcm_vhost.c | 262 +++- drivers/vhost/tcm_vhost.h | 13 + include/target/iscsi/iscsi_transport.h | 83 + include/target/target_core_backend.h |4 + include/target/target_core_fabric.h|2 +- 39 files changed, 4470 insertions(+), 1002
Re: [PATCH v2 1/4] Wrap crc_t10dif function all to use crypto transform framework
On Mon, Apr 29, 2013 at 01:40:30PM -0700, Tim Chen wrote: If I allocate the transform under the mod init instead, how can I make sure that the fast version is already registered if I have it compiled in? It is not clear to me how that's done looking at the libcrc32c code. This is only an issue when everything is built-in to the kernel. In that case we could make the crc implementations register at a point earlier than device_initcall, but no earlier than subsys_initcall since that's where cryptomgr sits. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
