[PATCH kernel] commit 4fbdf9cb ("lpfc: Fix for lun discovery issue with saturn adapter.")
This reverts 4fbdf9cb is breaks LPFC on POWER7 machine, big endian kernel.
This is the hardware used for verification:
0005:01:00.0 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse
Fibre Channel Host Adapter [10df:f100] (rev 03)
0005:01:00.1 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse
Fibre Channel Host Adapter [10df:f100] (rev 03)
Signed-off-by: Alexey Kardashevskiy
---
drivers/scsi/lpfc/lpfc_scsi.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index cb73cf9..c140f99 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -1130,25 +1130,6 @@ lpfc_release_scsi_buf(struct lpfc_hba *phba, struct
lpfc_scsi_buf *psb)
}
/**
- * lpfc_fcpcmd_to_iocb - copy the fcp_cmd data into the IOCB
- * @data: A pointer to the immediate command data portion of the IOCB.
- * @fcp_cmnd: The FCP Command that is provided by the SCSI layer.
- *
- * The routine copies the entire FCP command from @fcp_cmnd to @data while
- * byte swapping the data to big endian format for transmission on the wire.
- **/
-static void
-lpfc_fcpcmd_to_iocb(uint8_t *data, struct fcp_cmnd *fcp_cmnd)
-{
- int i, j;
-
- for (i = 0, j = 0; i < sizeof(struct fcp_cmnd);
-i += sizeof(uint32_t), j++) {
- ((uint32_t *)data)[j] = cpu_to_be32(((uint32_t *)fcp_cmnd)[j]);
- }
-}
-
-/**
* lpfc_scsi_prep_dma_buf_s3 - DMA mapping for scsi buffer to SLI3 IF spec
* @phba: The Hba for which this call is being executed.
* @lpfc_cmd: The scsi buffer which is going to be mapped.
@@ -1283,7 +1264,6 @@ lpfc_scsi_prep_dma_buf_s3(struct lpfc_hba *phba, struct
lpfc_scsi_buf *lpfc_cmd)
* we need to set word 4 of IOCB here
*/
iocb_cmd->un.fcpi.fcpi_parm = scsi_bufflen(scsi_cmnd);
- lpfc_fcpcmd_to_iocb(iocb_cmd->unsli3.fcp_ext.icd, fcp_cmnd);
return 0;
}
@@ -4147,6 +4127,24 @@ lpfc_scsi_cmd_iocb_cmpl(struct lpfc_hba *phba, struct
lpfc_iocbq *pIocbIn,
}
/**
+ * lpfc_fcpcmd_to_iocb - copy the fcp_cmd data into the IOCB
+ * @data: A pointer to the immediate command data portion of the IOCB.
+ * @fcp_cmnd: The FCP Command that is provided by the SCSI layer.
+ *
+ * The routine copies the entire FCP command from @fcp_cmnd to @data while
+ * byte swapping the data to big endian format for transmission on the wire.
+ **/
+static void
+lpfc_fcpcmd_to_iocb(uint8_t *data, struct fcp_cmnd *fcp_cmnd)
+{
+ int i, j;
+ for (i = 0, j = 0; i < sizeof(struct fcp_cmnd);
+i += sizeof(uint32_t), j++) {
+ ((uint32_t *)data)[j] = cpu_to_be32(((uint32_t *)fcp_cmnd)[j]);
+ }
+}
+
+/**
* lpfc_scsi_prep_cmnd - Wrapper func for convert scsi cmnd to FCP info unit
* @vport: The virtual port for which this call is being executed.
* @lpfc_cmd: The scsi command which needs to send.
@@ -4225,6 +4223,9 @@ lpfc_scsi_prep_cmnd(struct lpfc_vport *vport, struct
lpfc_scsi_buf *lpfc_cmd,
fcp_cmnd->fcpCntl3 = 0;
phba->fc4ControlRequests++;
}
+ if (phba->sli_rev == 3 &&
+ !(phba->sli3_options & LPFC_SLI3_BG_ENABLED))
+ lpfc_fcpcmd_to_iocb(iocb_cmd->unsli3.fcp_ext.icd, fcp_cmnd);
/*
* Finish initializing those IOCB fields that are independent
* of the scsi_cmnd request_buffer
--
2.0.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: [PATCH kernel] commit 4fbdf9cb ("lpfc: Fix for lun discovery issue with saturn adapter.")
Alexey Kardashevskiy wrote: > This reverts 4fbdf9cb is breaks LPFC on POWER7 machine, big endian kernel. > > This is the hardware used for verification: > 0005:01:00.0 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse > Fibre Channel Host Adapter [10df:f100] (rev 03) > 0005:01:00.1 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse > Fibre Channel Host Adapter [10df:f100] (rev 03) > > Signed-off-by: Alexey Kardashevskiy This issue is not specific to POWER7. I hit it on x86 [1] and James promised to look at it. [1] http://marc.info/?l=linux-scsi&m=142938432414173 Sebastian -- 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 kernel] commit 4fbdf9cb ("lpfc: Fix for lun discovery issue with saturn adapter.")
On 04/28/2015 07:18 PM, Sebastian Herbszt wrote: Alexey Kardashevskiy wrote: This reverts 4fbdf9cb is breaks LPFC on POWER7 machine, big endian kernel. This is the hardware used for verification: 0005:01:00.0 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse Fibre Channel Host Adapter [10df:f100] (rev 03) 0005:01:00.1 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse Fibre Channel Host Adapter [10df:f100] (rev 03) Signed-off-by: Alexey Kardashevskiy This issue is not specific to POWER7. I hit it on x86 [1] and James promised to look at it. [1] http://marc.info/?l=linux-scsi&m=142938432414173 Sebastian Well, I hope so, I just wanted to be more specific and the fault looks much different (and much cooler! :) ) on my hardware (it actually enters an infinite loop of oops'es): Welcome to Fedora 20 (Heisenbug)! INFO: rcu_sched self-detected stall on CPU INFO: rcu_sched self-detected stall on CPU INFO: rcu_sched self-detected stall on CPU 1: (2100 ticks this GP) idle=981/141/0 softirq=234/234 fqs =2083 2: (2100 ticks this GP) idle=c3d/141/0 softirq=259/259 fqs =2083 (t=2100 jiffies g=-7 c=-8 q=11820) (t=2100 jiffies g=-7 c=-8 q=11820) Task dump for CPU 0: kworker/u97:0 R running task 8192 7 2 0x0804 Workqueue: events_unbound .async_run_entry_fn Call Trace: [c00ffa29ef80] [c00ffa29f060] 0xc00ffa29f060 (unreliable) Task dump for CPU 1: kworker/u97:2 R running task10304 1636 2 0x0804 Workqueue: events_unbound .async_run_entry_fn Call Trace: [c00ff2fd2f80] [c00ff2fd3060] 0xc00ff2fd3060 (unreliable) Task dump for CPU 2: kworker/u97:1 R running task 8288 1633 2 0x0804 Workqueue: events_unbound .async_run_entry_fn Call Trace: [c00ff2f92eb0] [c00cf610] .sched_show_task+0xf0/0x180 (unreliable) [c00ff2f92f30] [c01041d8] .rcu_dump_cpu_stacks+0xd8/0x150 [c00ff2f92fd0] [c0108794] .rcu_check_callbacks+0x674/0x990 [c00ff2f93110] [c010e994] .update_process_times+0x44/0x90 [c00ff2f93190] [c01223f0] .tick_sched_handle.isra.16+0x20/0xa0 [c00ff2f93210] [c01224cc] .tick_sched_timer+0x5c/0xb0 [c00ff2f932b0] [c010f108] .__run_hrtimer+0x98/0x260 [c00ff2f93350] [c010fff8] .hrtimer_interrupt+0x138/0x2f0 [c00ff2f93460] [c001be1c] .__timer_interrupt+0x8c/0x230 [c00ff2f93500] [c001c488] .timer_interrupt+0x98/0xd0 [c00ff2f93580] [c00025d0] decrementer_common+0x150/0x180 --- interrupt: 901 at .string_get_size+0x120/0x250 LR = .sd_revalidate_disk+0x57c/0x1c10 [c00ff2f93870] [c048f84c] .string_get_size+0x18c/0x250 (unreliable ) [c00ff2f93940] [c05e7c1c] .sd_revalidate_disk+0x57c/0x1c10 [c00ff2f93a70] [c05e951c] .sd_probe_async+0xac/0x230 [c00ff2f93b00] [c00c28ec] .async_run_entry_fn+0x6c/0x180 [c00ff2f93ba0] [c00b7b78] .process_one_work+0x1a8/0x4a0 [c00ff2f93c40] [c00b7ff0] .worker_thread+0x180/0x5a0 [c00ff2f93d30] [c00bee08] .kthread+0x108/0x130 [c00ff2f93e30] [c0009590] .ret_from_kernel_thread+0x58/0xc8 Task dump for CPU 0: kworker/u97:0 R running task 8192 7 2 0x0804 Workqueue: events_unbound .async_run_entry_fn Call Trace: [c00ffa29ef80] [c00ffa29f060] 0xc00ffa29f060 (unreliable) Task dump for CPU 1: kworker/u97:2 R running task 9488 1636 2 0x0804 Workqueue: events_unbound .async_run_entry_fn Call Trace: [c00ff2fd2eb0] [c00cf610] .sched_show_task+0xf0/0x180 (unreliable) [c00ff2fd2f30] [c01041d8] .rcu_dump_cpu_stacks+0xd8/0x150 [c00ff2fd2fd0] [c0108794] .rcu_check_callbacks+0x674/0x990 [c00ff2fd3110] [c010e994] .update_process_times+0x44/0x90 [c00ff2fd3190] [c01223f0] .tick_sched_handle.isra.16+0x20/0xa0 [c00ff2fd3210] [c01224cc] .tick_sched_timer+0x5c/0xb0 [c00ff2fd32b0] [c010f108] .__run_hrtimer+0x98/0x260 [c00ff2fd3350] [c010fff8] .hrtimer_interrupt+0x138/0x2f0 [c00ff2fd3460] [c001be1c] .__timer_interrupt+0x8c/0x230 [c00ff2fd3500] [c001c488] .timer_interrupt+0x98/0xd0 [c00ff2fd3580] [c00025d0] decrementer_common+0x150/0x180 --- interrupt: 901 at .string_get_size+0x110/0x250 LR = .sd_revalidate_disk+0x57c/0x1c10 [c00ff2fd3870] [c048f84c] .string_get_size+0x18c/0x250 (unreliable ) [c00ff2fd3940] [c05e7c1c] .sd_revalidate_disk+0x57c/0x1c10 [c00ff2fd3a70] [c05e951c] .sd_probe_async+0xac/0x230 [c00ff2fd3b00] [c00c28ec] .async_run_entry_fn+0x6c/0x180 [c00ff2fd3ba0] [c00b7b78] .process_one_work+0x1a8/0x4a0 [c00ff2fd3c40] [c00b7ff0] .worker_thread+0x180/0x5a0 [c00ff2fd3d30] [c00bee08] .kthread+0x108/0x130 [c00ff2fd3e30] [c0009590] .ret_from_kernel_thread+0x58/0xc8 Task du
Re: [PATCH v8 1/3] scsi: ufs: add ioctl interface for query request
Reviewed-by: Dov Levenglick > From: Dolev Raviv > > This patch exposes the ioctl interface for UFS driver via SCSI device > ioctl interface. As of now UFS driver would provide the ioctl for query > interface to connected UFS device. > > Signed-off-by: Dolev Raviv > Signed-off-by: Noa Rubens > Signed-off-by: Raviv Shvili > Signed-off-by: Yaniv Gardi > Signed-off-by: Gilad Broner > --- > drivers/scsi/ufs/ufs.h| 53 +++--- > drivers/scsi/ufs/ufshcd.c | 219 > +- > include/scsi/scsi.h | 1 + > include/uapi/scsi/Kbuild | 1 + > include/uapi/scsi/ufs/Kbuild | 3 + > include/uapi/scsi/ufs/ioctl.h | 57 +++ > include/uapi/scsi/ufs/ufs.h | 66 + > 7 files changed, 356 insertions(+), 44 deletions(-) > create mode 100644 include/uapi/scsi/ufs/Kbuild > create mode 100644 include/uapi/scsi/ufs/ioctl.h > create mode 100644 include/uapi/scsi/ufs/ufs.h > > + UPIU_QUERY_OPCODE_CLEAR_FLAG= 0x7, > + UPIU_QUERY_OPCODE_TOGGLE_FLAG = 0x8, > +}; > +#endif /* UAPI_UFS_H_ */ > -- > Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > > -- > 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 > QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 v8 2/3] scsi: ufs: add debugfs for ufs
Reviewed-by: Dov Levenglick
> From: Lee Susman
>
> Adding debugfs capability for ufshcd.
>
> debugfs attributes introduced in this patch:
> - View driver/controller runtime data
> - Command tag statistics for performance analisis
> - Dump device descriptor info
> - Track recoverable errors statistics during runtime
> - Change UFS power mode during runtime
> entry a string in the format 'GGLLMM' where:
> G - selected gear
> L - number of lanes
> M - power mode
> (1=fast mode, 2=slow mode, 4=fast-auto mode,
> 5=slow-auto mode)
> First letter is for RX, second is for TX.
> - Get/set DME attributes
>
> Signed-off-by: Lee Susman
> Signed-off-by: Dolev Raviv
> Signed-off-by: Yaniv Gardi
> Signed-off-by: Raviv Shvili
> Signed-off-by: Gilad Broner
> ---
> drivers/scsi/ufs/Makefile | 3 +-
> drivers/scsi/ufs/ufs-debugfs.c | 901
> +
> drivers/scsi/ufs/ufs-debugfs.h | 38 ++
> drivers/scsi/ufs/ufshcd.c | 229 ++-
> drivers/scsi/ufs/ufshcd.h | 65 +++
> drivers/scsi/ufs/ufshci.h | 2 +
> 6 files changed, 1225 insertions(+), 13 deletions(-)
> create mode 100644 drivers/scsi/ufs/ufs-debugfs.c
> create mode 100644 drivers/scsi/ufs/ufs-debugfs.h
>
> @@ -72,6 +72,8 @@ enum {
> REG_UIC_COMMAND_ARG_1 = 0x94,
> REG_UIC_COMMAND_ARG_2 = 0x98,
> REG_UIC_COMMAND_ARG_3 = 0x9C,
> +
> + UFSHCI_REG_SPACE_SIZE = 0xA0,
> };
>
> /* Controller capability masks */
> --
> Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> --
> 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
>
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
[PATCH] drivers/scsi/arm/acornscsi.c: rename CONFIG_ACORNSCSI_CONSTANTS
CONFIG_ACORNSCSI_CONSTANTS is a file local CPP identifier and thereby
violates the naming convention of Kconfig options in Make and CPP
syntax; only Kconfig options should carry the 'CONFIG_' prefix.
This patch removes the 'CONFIG_' prefix to apply to this convention and
to make static analysis tools happy.
Signed-off-by: Valentin Rothberg
---
I detected this issue with ./scripts/checkkconfigsymbols.py
---
drivers/scsi/arm/acornscsi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/arm/acornscsi.c b/drivers/scsi/arm/acornscsi.c
index deaaf84989cd..ce764c3ed99c 100644
--- a/drivers/scsi/arm/acornscsi.c
+++ b/drivers/scsi/arm/acornscsi.c
@@ -96,7 +96,7 @@
* Define this if you want to have verbose explanation of SCSI
* status/messages.
*/
-#undef CONFIG_ACORNSCSI_CONSTANTS
+#undef ACORNSCSI_CONSTANTS
/*
* Define this if you want to use the on board DMAC [don't remove this option]
* If not set, then use PIO mode (not currently supported).
@@ -399,7 +399,7 @@ void acornscsi_resetcard(AS_Host *host)
/*=
* Utility routines (eg. debug)
*/
-#ifdef CONFIG_ACORNSCSI_CONSTANTS
+#ifdef ACORNSCSI_CONSTANTS
static char *acornscsi_interrupttype[] = {
"rst", "suc", "p/a", "3",
"term", "5", "6","7",
@@ -477,7 +477,7 @@ void print_scsi_status(unsigned int ssr)
static
void print_sbic_status(int asr, int ssr, int cmdphase)
{
-#ifdef CONFIG_ACORNSCSI_CONSTANTS
+#ifdef ACORNSCSI_CONSTANTS
printk("sbic: %c%c%c%c%c%c ",
asr & ASR_INT ? 'I' : 'i',
asr & ASR_LCI ? 'L' : 'l',
--
2.1.4
--
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/4] bfa:Fix for crash when bfa_itnim is NULL
Anil, the issue you are fixing here is described in comments, but adding the description to the body of your mail might make it more attractive for reviewers. Please add a proper description to your patches in the future. > From: Anil Gurumurthy > > Signed-off-by: Sudarsana Kalluru > Signed-off-by: Anil Gurumurthy Reviewed-by: Tomas Henzl Tomas -- 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 4/4] bfa:Update driver version to 3.2.25.0
On 02/03/2015 09:45 AM, anil.gurumur...@qlogic.com wrote: > From: Anil Gurumurthy > > Signed-off-by: Sudarsana Kalluru > Signed-off-by: Anil Gurumurthy Reviewed-by: Tomas Henzl Tomas -- 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 3/4] bfa:File header and user visible string changes
On 02/03/2015 09:45 AM, anil.gurumur...@qlogic.com wrote: > From: Anil Gurumurthy > > Signed-off-by: Sudarsana Kalluru > Signed-off-by: Anil Gurumurthy Reviewed-by: Tomas Henzl Tomas -- 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] drivers/scsi/arm/acornscsi.c: rename CONFIG_ACORNSCSI_CONSTANTS
On Tue, 2015-04-28 at 16:15 +0200, Valentin Rothberg wrote: > CONFIG_ACORNSCSI_CONSTANTS is a file local CPP identifier and thereby > violates the naming convention of Kconfig options in Make and CPP > syntax; only Kconfig options should carry the 'CONFIG_' prefix. > > This patch removes the 'CONFIG_' prefix to apply to this convention and > to make static analysis tools happy. Will the Erlangen bot still spot ACORNSCSI_CONSTANTS as a potential issue? Paul Bolle -- 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] drivers/scsi/arm/acornscsi.c: rename CONFIG_ACORNSCSI_CONSTANTS
Hi Paul, On Tue, Apr 28, 2015 at 9:10 PM, Paul Bolle wrote: > On Tue, 2015-04-28 at 16:15 +0200, Valentin Rothberg wrote: >> CONFIG_ACORNSCSI_CONSTANTS is a file local CPP identifier and thereby >> violates the naming convention of Kconfig options in Make and CPP >> syntax; only Kconfig options should carry the 'CONFIG_' prefix. >> >> This patch removes the 'CONFIG_' prefix to apply to this convention and >> to make static analysis tools happy. > > Will the Erlangen bot still spot ACORNSCSI_CONSTANTS as a potential > issue? No, undertaker-checkpatch won't complain about this. There are thousands of such cases (i.e., without CONFIG_ prefix) around in the code (mostly #ifdef DEBUG). But most of them are intentionally dead or related to debugging, so they are ignored to avoid having false positives. Regards, Valentin > Paul Bolle > -- 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] drivers/scsi/arm/acornscsi.c: rename CONFIG_ACORNSCSI_CONSTANTS
Hi Valentin, On Tue, 2015-04-28 at 21:26 +0200, Valentin Rothberg wrote: > On Tue, Apr 28, 2015 at 9:10 PM, Paul Bolle wrote: > > Will the Erlangen bot still spot ACORNSCSI_CONSTANTS as a potential > > issue? > > No, undertaker-checkpatch won't complain about this. There are > thousands of such cases (i.e., without CONFIG_ prefix) around in the > code (mostly #ifdef DEBUG). But most of them are intentionally dead > or related to debugging, so they are ignored to avoid having false > positives. Well, in a few years time, once undertaker-checkpatch has stomped out most of the faux Kconfig preprocessor checks, that might be an area to cover too. Or is that issue, ie pointless preprocessor checks, harder than one might naively think? Thanks, Paul Bolle -- 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
[PATCH] scsi: aha152x: Remove residual AHA152X_DEBUG references
From: "Ewan D. Milne"
Commit f75ae8ed.. ("aha152x: debug output update and whitespace cleanup")
removed all AHA152X_DEBUG code from aha152x.c, so the build option no longer
does anything useful.
Signed-off-by: Ewan D. Milne
---
Documentation/scsi/aha152x.txt | 3 ---
drivers/scsi/aha152x.h | 22 --
2 files changed, 25 deletions(-)
diff --git a/Documentation/scsi/aha152x.txt b/Documentation/scsi/aha152x.txt
index 9484873..248dde1 100644
--- a/Documentation/scsi/aha152x.txt
+++ b/Documentation/scsi/aha152x.txt
@@ -40,9 +40,6 @@ COMPILE TIME CONFIGURATION (go into AHA152X in
drivers/scsi/Makefile):
-DSETUP1="{ IOPORT, IRQ, SCSI_ID, RECONNECT, PARITY, SYNCHRONOUS, DELAY,
EXT_TRANS }"
override for the second controller
--DAHA152X_DEBUG
- enable debugging output
-
-DAHA152X_STAT
enable some statistics
diff --git a/drivers/scsi/aha152x.h b/drivers/scsi/aha152x.h
index ac4bfa438b..1addbe6 100644
--- a/drivers/scsi/aha152x.h
+++ b/drivers/scsi/aha152x.h
@@ -294,25 +294,6 @@ typedef union {
#define SETRATE(RATE) SETPORT(SCSIRATE,(RATE) & 0x7f)
-#if defined(AHA152X_DEBUG)
-enum {
- debug_procinfo = 0x0001,
- debug_queue = 0x0002,
- debug_locking = 0x0004,
- debug_intr = 0x0008,
- debug_selection = 0x0010,
- debug_msgo = 0x0020,
- debug_msgi = 0x0040,
- debug_status= 0x0080,
- debug_cmd = 0x0100,
- debug_datai = 0x0200,
- debug_datao = 0x0400,
- debug_eh = 0x0800,
- debug_done = 0x1000,
- debug_phases= 0x2000,
-};
-#endif
-
/* for the pcmcia stub */
struct aha152x_setup {
int io_port;
@@ -324,9 +305,6 @@ struct aha152x_setup {
int delay;
int ext_trans;
int tc1550;
-#if defined(AHA152X_DEBUG)
- int debug;
-#endif
char *conf;
};
--
2.1.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: [PATCH] drivers/scsi/arm/acornscsi.c: rename CONFIG_ACORNSCSI_CONSTANTS
On Tue, Apr 28, 2015 at 9:34 PM, Paul Bolle wrote: > Hi Valentin, > > On Tue, 2015-04-28 at 21:26 +0200, Valentin Rothberg wrote: >> On Tue, Apr 28, 2015 at 9:10 PM, Paul Bolle wrote: >> > Will the Erlangen bot still spot ACORNSCSI_CONSTANTS as a potential >> > issue? >> >> No, undertaker-checkpatch won't complain about this. There are >> thousands of such cases (i.e., without CONFIG_ prefix) around in the >> code (mostly #ifdef DEBUG). But most of them are intentionally dead >> or related to debugging, so they are ignored to avoid having false >> positives. > > Well, in a few years time, once undertaker-checkpatch has stomped out > most of the faux Kconfig preprocessor checks, that might be an area to > cover too. Or is that issue, ie pointless preprocessor checks, harder > than one might naively think? To give a number from Linus' tree today: 4706 of such unprefixed dead and undead #ifdefs and 940 'real' ones. Most of them are intentional -- this doesn't mean that it's not a problem. Personally, I don't like to have code around that cannot at least be easily test compiled; we manually need to (un)define the identifiers. I like your proposal. For symbolic issues, we could even put that directly in checkkconfigsymbols.py, so a big part of the problem could be solved directly with Kernel tools. But I really hope that it won't take a few years until we get there : ) Valentin > Thanks, > > > Paul Bolle > -- 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 19/23] advansys: Remove cmd_per_lun setting
On Mon, 2015-04-27 at 09:02 +0200, Hannes Reinecke wrote: > On 04/26/2015 08:52 PM, James Bottomley wrote: > > On Sun, 2015-04-26 at 16:57 +0200, Ondrej Zary wrote: > >> On Friday 24 April 2015 13:18:38 Hannes Reinecke wrote: > >>> Ancient, and pretty much obsolete by now. > >>> > >>> Signed-off-by: Hannes Reinecke > >>> --- > >>> drivers/scsi/advansys.c | 18 -- > >>> 1 file changed, 18 deletions(-) > >>> > >>> diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c > >>> index 74e5518..5a55272 100644 > >>> --- a/drivers/scsi/advansys.c > >>> +++ b/drivers/scsi/advansys.c > >>> @@ -11212,24 +11212,6 @@ static int advansys_board_found(struct Scsi_Host > >>> *shost, unsigned int iop, } > >>> > >>> /* > >>> - * Following v1.3.89, 'cmd_per_lun' is no longer needed > >>> - * and should be set to zero. > >>> - * > >>> - * But because of a bug introduced in v1.3.89 if the driver is > >>> - * compiled as a module and 'cmd_per_lun' is zero, the Mid-Level > >>> - * SCSI function 'allocate_device' will panic. To allow the driver > >>> - * to work as a module in these kernels set 'cmd_per_lun' to 1. > >>> - * > >>> - * Note: This is wrong. cmd_per_lun should be set to the depth > >>> - * you want on untagged devices always. > >>> - #ifdef MODULE > >>> - */ > >>> - shost->cmd_per_lun = 1; > >>> -/* #else > >>> -shost->cmd_per_lun = 0; > >>> -#endif */ > >>> - > >>> - /* > >>>* Set the maximum number of scatter-gather elements the > >>>* adapter can handle. > >>>*/ > >> > >> This patch breaks my setup: "modprobe advansys" hangs. > >> > >> It works when all other patches are applied except this one. > > > > The specific problem is that a cmd_per_lun of zero breaks everything > > because we use it for the initial queue depth and if you don't actually > > set it, you get zero (because the template is in static memory). This > > should be a global fix that changes the default initial queue depth to 1 > > for the probe phase if it's unset in the template or the host. > > > > Hopefully this should set us up for removing cmd_per_lun. > > > > James > > > > --- > > > > diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c > > index 60aae01..681a59a 100644 > > --- a/drivers/scsi/scsi_scan.c > > +++ b/drivers/scsi/scsi_scan.c > > @@ -280,7 +280,8 @@ static struct scsi_device *scsi_alloc_sdev(struct > > scsi_target *starget, > > sdev->host->cmd_per_lun, shost->bqt, > > shost->hostt->tag_alloc_policy); > > } > > - scsi_change_queue_depth(sdev, sdev->host->cmd_per_lun); > > + scsi_change_queue_depth(sdev, sdev->host->cmd_per_lun ? > > + sdev->host->cmd_per_lun : 1); > > > > scsi_sysfs_device_initialize(sdev); > > > > > > > > > That fixes it on my side; tested with two devices on the narrow > board and one on the wide board. > > And while at it I've done a patch to clear up all the now-obsolete > cmd_per_lun = 1 settings in the various drivers. > > James, will you send a formal patch or should I send it, along with > the second one to clear up cmd_per_lun? I suppose I should do it formally first. After that, it might make sense for you to send it to me so I don't get the order wrong. James -- 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] sd: always retry READ CAPACITY for ALUA state transition
On Mon, 2015-04-27 at 11:35 +0200, Hannes Reinecke wrote: > During ALUA state transitions the device might return > a sense code 02/04/0a (Logical unit not accessible, asymmetric > access state transition). As this is a transient error > we should just retry the READ CAPACITY call until > the state transition finishes and the correct > capacity can be returned. > > Signed-off-by: Hannes Reinecke > --- > drivers/scsi/sd.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index 79beebf..7178b05 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -1987,6 +1987,11 @@ static int read_capacity_16(struct scsi_disk *sdkp, > struct scsi_device *sdp, >* give it one more chance */ > if (--reset_retries > 0) > continue; > + if (sense_valid && > + sshdr.sense_key == NOT_READY && > + sshdr.asc == 0x04 && sshdr.ascq == 0x0A) > + /* ALUA state transition; always retry */ > + continue; > } > retries--; > > @@ -2069,6 +2074,11 @@ static int read_capacity_10(struct scsi_disk *sdkp, > struct scsi_device *sdp, >* give it one more chance */ > if (--reset_retries > 0) > continue; > + if (sense_valid && > + sshdr.sense_key == NOT_READY && > + sshdr.asc == 0x04 && sshdr.ascq == 0x0A) > + /* ALUA state transition; always retry */ > + continue; > } > retries--; > Got to say I really don't like this infinite retry possibility. How long does the ALUA transition take? Would increasing retries work (or even hijacking reset_retries)? James -- 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
[PATCH] scsi_scan: fix queue depth initialisation problem
From: James Bottomley Date: Sun, 26 Apr 2015 11:52:46 -0700 Subject: [PATCH] scsi_scan: fix queue depth initialisation problem Currently we blindly use the value of cmd_per_lun as the initial setting for queue_depth. This fails miserably (hangs the system) if it is zero, which is the default value for anything uninitialised in the template. The net result is that every host template has to set a value for cmd_per_lun. Instead, use a default value of 1 if the actual value is unset. This should pave the way for removing cmd_per_lun from all the templates and eventually from SCSI itself. Signed-off-by: James Bottomley diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 60aae01..681a59a 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -280,7 +280,8 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget, sdev->host->cmd_per_lun, shost->bqt, shost->hostt->tag_alloc_policy); } - scsi_change_queue_depth(sdev, sdev->host->cmd_per_lun); + scsi_change_queue_depth(sdev, sdev->host->cmd_per_lun ? + sdev->host->cmd_per_lun : 1); scsi_sysfs_device_initialize(sdev); -- 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] scatterlist: enable sg chaining for all architectures
On Sat, 25 Apr 2015 23:56:16 +0900 Akinobu Mita wrote: > Some architectures enable sg chaining option while others do not. > > The requirement to enable sg chaining is that pages must be aligned > at a 32-bit boundary in order to overload the LSB of the pointer. > Regardless of whether ARCH_HAS_SG_CHAIN is defined or not, the above > requirement is always chacked by BUG_ON() in sg_assign_page. So > all architectures can enable sg chaining. > > As you can see from the changes in drivers/target/target_core_rd.c, > enabling SG chaining for all architectures allows us to allocate > discontiguous scatterlist tables which can be traversed throughout > by sg_next() without a special handling for some architectures. Thanks, I'll grab this. If anyone has concerns, speak now or hold both pieces! -- 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] scatterlist: enable sg chaining for all architectures
On Tue, 2015-04-28 at 14:27 -0700, Andrew Morton wrote: > On Sat, 25 Apr 2015 23:56:16 +0900 Akinobu Mita > wrote: > > > Some architectures enable sg chaining option while others do not. > > > > The requirement to enable sg chaining is that pages must be aligned > > at a 32-bit boundary in order to overload the LSB of the pointer. > > Regardless of whether ARCH_HAS_SG_CHAIN is defined or not, the above > > requirement is always chacked by BUG_ON() in sg_assign_page. So > > all architectures can enable sg chaining. > > > > As you can see from the changes in drivers/target/target_core_rd.c, > > enabling SG chaining for all architectures allows us to allocate > > discontiguous scatterlist tables which can be traversed throughout > > by sg_next() without a special handling for some architectures. > > Thanks, I'll grab this. If anyone has concerns, speak now or hold both > pieces! It breaks a host of architectures doesn't it? I can specifically speak for PARISC: The problem is the way our iommus are consuming scatterlists. They're assuming we can dereference the scatterlist as an array (like this code in ccio-dma.c): static int ccio_map_sg(struct device *dev, struct scatterlist *sglist, int nents, enum dma_data_direction direction) [...] for(i = 0; i < nents; i++) prev_len += sglist[i].length; If you turn on sg chaining on our architecture, we'll run off the end of that array dereference and crash. This can all be fixed by making our architecture dma mapping code use iterators instead of array lists, but that needs more code than this patch provides. I assume there are similar issues on a lot of other architectures, so before you can contemplate a patch like this, surely all the architecture consumers have to be converted to iterator instead of array format? The first place to start would be a survey of who's still using the array format. James -- 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
[PATCH 0/3] megaraid: use dev_printk() when possible
The current megaraid driver messages are somewhat inconsistent, e.g., megasas: 06.803.01.00-rc1 Mon. Mar. 10 17:00:00 PDT 2014 megasas: 0x1000:0x005b:0x15d9:0x0690: bus 1:slot 0:func 0 megasas: FW now in Ready state megaraid_sas :01:00.0: enabling device ( -> 0002) megasas: Waiting for FW to come to ready state megasas: FW in FAULT state!! megaraid_sas :01:00.0: megasas: FW restarted successfully from megasas_init_fw! megasas: Waiting for FW to come to ready state megasas: FW in FAULT state!! These patches use dev_printk() to include the driver name and device address in the conventional format. --- Bjorn Helgaas (3): megaraid: use dev_printk when possible megaraid_sas: use dev_printk when possible megaraid_sas: use dev_printk when possible drivers/scsi/megaraid.c | 92 - drivers/scsi/megaraid/megaraid_sas_base.c | 281 +-- drivers/scsi/megaraid/megaraid_sas_fusion.c | 96 + 3 files changed, 230 insertions(+), 239 deletions(-) -- 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
[PATCH 2/3] megaraid_sas: use dev_printk when possible
Use dev_printk() when possible to make messages more useful.
Signed-off-by: Bjorn Helgaas
---
drivers/scsi/megaraid/megaraid_sas_base.c | 281 ++---
1 file changed, 139 insertions(+), 142 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 890637f..9ef6631 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -217,7 +217,7 @@ struct megasas_cmd *megasas_get_cmd(struct megasas_instance
list_del_init(&cmd->list);
atomic_set(&cmd->mfi_mpt_pthr, MFI_MPT_DETACHED);
} else {
- printk(KERN_ERR "megasas: Command pool empty!\n");
+ dev_err(&instance->pdev->dev, "Command pool empty!\n");
}
spin_unlock_irqrestore(&instance->mfi_pool_lock, flags);
@@ -382,9 +382,9 @@ megasas_adp_reset_xscale(struct megasas_instance *instance,
msleep(1000); /* sleep for 3 secs */
pcidata = 0;
pci_read_config_dword(instance->pdev, MFI_1068_PCSR_OFFSET, &pcidata);
- printk(KERN_NOTICE "pcidata = %x\n", pcidata);
+ dev_notice(&instance->pdev->dev, "pcidata = %x\n", pcidata);
if (pcidata & 0x2) {
- printk(KERN_NOTICE "mfi 1068 offset read=%x\n", pcidata);
+ dev_notice(&instance->pdev->dev, "mfi 1068 offset read=%x\n",
pcidata);
pcidata &= ~0x2;
pci_write_config_dword(instance->pdev,
MFI_1068_PCSR_OFFSET, pcidata);
@@ -395,9 +395,9 @@ megasas_adp_reset_xscale(struct megasas_instance *instance,
pcidata = 0;
pci_read_config_dword(instance->pdev,
MFI_1068_FW_HANDSHAKE_OFFSET, &pcidata);
- printk(KERN_NOTICE "1068 offset handshake read=%x\n", pcidata);
+ dev_notice(&instance->pdev->dev, "1068 offset handshake
read=%x\n", pcidata);
if ((pcidata & 0x) == MFI_1068_FW_READY) {
- printk(KERN_NOTICE "1068 offset pcidt=%x\n", pcidata);
+ dev_notice(&instance->pdev->dev, "1068 offset
pcidt=%x\n", pcidata);
pcidata = 0;
pci_write_config_dword(instance->pdev,
MFI_1068_FW_HANDSHAKE_OFFSET, pcidata);
@@ -836,7 +836,7 @@ megasas_adp_reset_gen2(struct megasas_instance *instance,
while ( !( HostDiag & DIAG_WRITE_ENABLE) ) {
msleep(100);
HostDiag = (u32)readl(hostdiag_offset);
- printk(KERN_NOTICE "RESETGEN2: retry=%x, hostdiag=%x\n",
+ dev_notice(&instance->pdev->dev, "RESETGEN2: retry=%x,
hostdiag=%x\n",
retry, HostDiag);
if (retry++ >= 100)
@@ -844,7 +844,7 @@ megasas_adp_reset_gen2(struct megasas_instance *instance,
}
- printk(KERN_NOTICE "ADP_RESET_GEN2: HostDiag=%x\n", HostDiag);
+ dev_notice(&instance->pdev->dev, "ADP_RESET_GEN2: HostDiag=%x\n",
HostDiag);
writel((HostDiag | DIAG_RESET_ADAPTER), hostdiag_offset);
@@ -854,7 +854,7 @@ megasas_adp_reset_gen2(struct megasas_instance *instance,
while ( ( HostDiag & DIAG_RESET_ADAPTER) ) {
msleep(100);
HostDiag = (u32)readl(hostdiag_offset);
- printk(KERN_NOTICE "RESET_GEN2: retry=%x, hostdiag=%x\n",
+ dev_notice(&instance->pdev->dev, "RESET_GEN2: retry=%x,
hostdiag=%x\n",
retry, HostDiag);
if (retry++ >= 1000)
@@ -1253,7 +1253,7 @@ megasas_build_dcdb(struct megasas_instance *instance,
struct scsi_cmnd *scp,
&pthru->sgl);
if (pthru->sge_count > instance->max_num_sge) {
- printk(KERN_ERR "megasas: DCDB two many SGE NUM=%x\n",
+ dev_err(&instance->pdev->dev, "DCDB two many SGE NUM=%x\n",
pthru->sge_count);
return 0;
}
@@ -1394,7 +1394,7 @@ megasas_build_ldio(struct megasas_instance *instance,
struct scsi_cmnd *scp,
ldio->sge_count = megasas_make_sgl32(instance, scp, &ldio->sgl);
if (ldio->sge_count > instance->max_num_sge) {
- printk(KERN_ERR "megasas: build_ld_io: sge_count = %x\n",
+ dev_err(&instance->pdev->dev, "build_ld_io: sge_count = %x\n",
ldio->sge_count);
return 0;
}
@@ -1461,24 +1461,24 @@ megasas_dump_pending_frames(struct megasas_instance
*instance)
u32 sgcount;
u32 max_cmd = instance->max_fw_cmds;
- printk(KERN_ERR "\nmegasas[%d]: Dumping Frame Phys Address of all
pending cmds in FW\n",instance->host->host_no);
- printk(KERN_ERR "megasas[%d]: Total OS Pending cmds :
%d\n",instance->host->host_no,atomic_read(&instance->fw_outstanding));
+
[PATCH 3/3] megaraid_sas: use dev_printk when possible
Use dev_printk() when possible to make messages more useful.
Signed-off-by: Bjorn Helgaas
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 96 ++-
1 file changed, 48 insertions(+), 48 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 5a0800d..0b20bd8 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -173,7 +173,7 @@ struct megasas_cmd_fusion *megasas_get_cmd_fusion(struct
megasas_instance
struct megasas_cmd_fusion, list);
list_del_init(&cmd->list);
} else {
- printk(KERN_ERR "megasas: Command pool (fusion) empty!\n");
+ dev_err(&instance->pdev->dev, "Command pool (fusion) empty!\n");
}
spin_unlock_irqrestore(&fusion->mpt_pool_lock, flags);
@@ -244,7 +244,7 @@ static void megasas_teardown_frame_pool_fusion(
struct megasas_cmd_fusion *cmd;
if (!fusion->sg_dma_pool || !fusion->sense_dma_pool) {
- printk(KERN_ERR "megasas: dma pool is null. SG Pool %p, "
+ dev_err(&instance->pdev->dev, "dma pool is null. SG Pool %p, "
"sense pool : %p\n", fusion->sg_dma_pool,
fusion->sense_dma_pool);
return;
@@ -356,7 +356,7 @@ static int megasas_create_frame_pool_fusion(struct
megasas_instance *instance)
total_sz_chain_frame, 4,
0);
if (!fusion->sg_dma_pool) {
- printk(KERN_DEBUG "megasas: failed to setup request pool "
+ dev_printk(KERN_DEBUG, &instance->pdev->dev, "failed to setup
request pool "
"fusion\n");
return -ENOMEM;
}
@@ -365,7 +365,7 @@ static int megasas_create_frame_pool_fusion(struct
megasas_instance *instance)
SCSI_SENSE_BUFFERSIZE, 64, 0);
if (!fusion->sense_dma_pool) {
- printk(KERN_DEBUG "megasas: failed to setup sense pool "
+ dev_printk(KERN_DEBUG, &instance->pdev->dev, "failed to setup
sense pool "
"fusion\n");
pci_pool_destroy(fusion->sg_dma_pool);
fusion->sg_dma_pool = NULL;
@@ -390,7 +390,7 @@ static int megasas_create_frame_pool_fusion(struct
megasas_instance *instance)
* whatever has been allocated
*/
if (!cmd->sg_frame || !cmd->sense) {
- printk(KERN_DEBUG "megasas: pci_pool_alloc failed\n");
+ dev_printk(KERN_DEBUG, &instance->pdev->dev,
"pci_pool_alloc failed\n");
megasas_teardown_frame_pool_fusion(instance);
return -ENOMEM;
}
@@ -436,7 +436,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance *instance)
&fusion->req_frames_desc_phys, GFP_KERNEL);
if (!fusion->req_frames_desc) {
- printk(KERN_ERR "megasas; Could not allocate memory for "
+ dev_err(&instance->pdev->dev, "Could not allocate memory for "
"request_frames\n");
goto fail_req_desc;
}
@@ -447,7 +447,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance *instance)
fusion->reply_alloc_sz * count, 16, 0);
if (!fusion->reply_frames_desc_pool) {
- printk(KERN_ERR "megasas; Could not allocate memory for "
+ dev_err(&instance->pdev->dev, "Could not allocate memory for "
"reply_frame pool\n");
goto fail_reply_desc;
}
@@ -456,7 +456,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance *instance)
pci_pool_alloc(fusion->reply_frames_desc_pool, GFP_KERNEL,
&fusion->reply_frames_desc_phys);
if (!fusion->reply_frames_desc) {
- printk(KERN_ERR "megasas; Could not allocate memory for "
+ dev_err(&instance->pdev->dev, "Could not allocate memory for "
"reply_frame pool\n");
pci_pool_destroy(fusion->reply_frames_desc_pool);
goto fail_reply_desc;
@@ -473,7 +473,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance *instance)
fusion->io_frames_alloc_sz, 16, 0);
if (!fusion->io_request_frames_pool) {
- printk(KERN_ERR "megasas: Could not allocate memory for "
+ dev_err(&instance->pdev->dev, "Could not allocate memory for "
"io_request_frame pool\n");
goto fail_io_frames;
}
@@ -482,7 +482,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance *instance)
pci_pool_alloc(fusion->io_request_frames_pool, GFP_KERNEL,
[PATCH 1/3] megaraid: use dev_printk when possible
Use dev_printk() when possible to make messages more useful.
Signed-off-by: Bjorn Helgaas
---
drivers/scsi/megaraid.c | 92 ++-
1 file changed, 43 insertions(+), 49 deletions(-)
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index bc7b34c..47cda02 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -268,7 +268,7 @@ mega_query_adapter(adapter_t *adapter)
raw_mbox[2] = NC_SUBOP_PRODUCT_INFO;/* i.e. 0x0E */
if ((retval = issue_scb_block(adapter, raw_mbox)))
- printk(KERN_WARNING
+ dev_warn(&adapter->dev->dev,
"megaraid: Product_info cmd failed with error: %d\n",
retval);
@@ -334,7 +334,7 @@ mega_query_adapter(adapter_t *adapter)
adapter->bios_version[4] = 0;
}
- printk(KERN_NOTICE "megaraid: [%s:%s] detected %d logical drives.\n",
+ dev_notice(&adapter->dev->dev, "[%s:%s] detected %d logical drives.\n",
adapter->fw_version, adapter->bios_version, adapter->numldrv);
/*
@@ -342,7 +342,7 @@ mega_query_adapter(adapter_t *adapter)
*/
adapter->support_ext_cdb = mega_support_ext_cdb(adapter);
if (adapter->support_ext_cdb)
- printk(KERN_NOTICE "megaraid: supports extended CDBs.\n");
+ dev_notice(&adapter->dev->dev, "supports extended CDBs.\n");
return 0;
@@ -678,7 +678,7 @@ mega_build_cmd(adapter_t *adapter, Scsi_Cmnd *cmd, int
*busy)
if(!(adapter->flag & (1L << cmd->device->channel))) {
- printk(KERN_NOTICE
+ dev_notice(&adapter->dev->dev,
"scsi%d: scanning scsi channel %d ",
adapter->host->host_no,
cmd->device->channel);
@@ -983,7 +983,7 @@ mega_prepare_passthru(adapter_t *adapter, scb_t *scb,
Scsi_Cmnd *cmd,
case READ_CAPACITY:
if(!(adapter->flag & (1L << cmd->device->channel))) {
- printk(KERN_NOTICE
+ dev_notice(&adapter->dev->dev,
"scsi%d: scanning scsi channel %d [P%d] ",
adapter->host->host_no,
cmd->device->channel, channel);
@@ -1045,7 +1045,7 @@ mega_prepare_extpassthru(adapter_t *adapter, scb_t *scb,
Scsi_Cmnd *cmd,
case READ_CAPACITY:
if(!(adapter->flag & (1L << cmd->device->channel))) {
- printk(KERN_NOTICE
+ dev_notice(&adapter->dev->dev,
"scsi%d: scanning scsi channel %d [P%d] ",
adapter->host->host_no,
cmd->device->channel, channel);
@@ -1241,7 +1241,7 @@ issue_scb_block(adapter_t *adapter, u_char *raw_mbox)
return mbox->m_in.status;
bug_blocked_mailbox:
- printk(KERN_WARNING "megaraid: Blocked mailbox..!!\n");
+ dev_warn(&adapter->dev->dev, "Blocked mailbox..!!\n");
udelay (1000);
return -1;
}
@@ -1454,7 +1454,7 @@ mega_cmd_done(adapter_t *adapter, u8 completed[], int
nstatus, int status)
* Make sure f/w has completed a valid command
*/
if( !(scb->state & SCB_ISSUED) || scb->cmd == NULL ) {
- printk(KERN_CRIT
+ dev_crit(&adapter->dev->dev,
"megaraid: invalid command ");
printk("Id %d, scb->state:%x, scsi cmd:%p\n",
cmdid, scb->state, scb->cmd);
@@ -1467,7 +1467,7 @@ mega_cmd_done(adapter_t *adapter, u8 completed[], int
nstatus, int status)
*/
if( scb->state & SCB_ABORT ) {
- printk(KERN_WARNING
+ dev_warn(&adapter->dev->dev,
"megaraid: aborted cmd [%x] complete.\n",
scb->idx);
@@ -1486,7 +1486,7 @@ mega_cmd_done(adapter_t *adapter, u8 completed[], int
nstatus, int status)
*/
if( scb->state & SCB_RESET ) {
- printk(KERN_WARNING
+ dev_warn(&adapter->dev->dev,
"megaraid: reset cmd [%x] complete.\n",
scb->idx);
@@ -1553,7 +1553,7 @@ mega_cmd_done(adapter_t *adapter, u8 completed[], int
nstatus, int status)
if( sg_page(sgl) ) {
c = *(unsigned char *) sg_virt(&sgl[0]);
Re: [PATCH] scatterlist: enable sg chaining for all architectures
2015-04-29 7:16 GMT+09:00 James Bottomley : > On Tue, 2015-04-28 at 14:27 -0700, Andrew Morton wrote: >> On Sat, 25 Apr 2015 23:56:16 +0900 Akinobu Mita >> wrote: >> >> > Some architectures enable sg chaining option while others do not. >> > >> > The requirement to enable sg chaining is that pages must be aligned >> > at a 32-bit boundary in order to overload the LSB of the pointer. >> > Regardless of whether ARCH_HAS_SG_CHAIN is defined or not, the above >> > requirement is always chacked by BUG_ON() in sg_assign_page. So >> > all architectures can enable sg chaining. >> > >> > As you can see from the changes in drivers/target/target_core_rd.c, >> > enabling SG chaining for all architectures allows us to allocate >> > discontiguous scatterlist tables which can be traversed throughout >> > by sg_next() without a special handling for some architectures. >> >> Thanks, I'll grab this. If anyone has concerns, speak now or hold both >> pieces! > > It breaks a host of architectures doesn't it? I can specifically speak > for PARISC: The problem is the way our iommus are consuming > scatterlists. They're assuming we can dereference the scatterlist as an > array (like this code in ccio-dma.c): > > static int > ccio_map_sg(struct device *dev, struct scatterlist *sglist, int nents, > enum dma_data_direction direction) > [...] > for(i = 0; i < nents; i++) > prev_len += sglist[i].length; > > If you turn on sg chaining on our architecture, we'll run off the end of > that array dereference and crash. > > This can all be fixed by making our architecture dma mapping code use > iterators instead of array lists, but that needs more code than this > patch provides. I assume there are similar issues on a lot of other > architectures, so before you can contemplate a patch like this, surely > all the architecture consumers have to be converted to iterator instead > of array format? > > The first place to start would be a survey of who's still using the > array format. Agreed. I could find similar issues in arch/m68k/kernel/dma.c. (git grep '[^a-z]sg++' shows that there are a lot of similar issues) Andrew, could you drop this patch from -mm for now? -- 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] ufs: Reinstate NULL pointer checks for regulators
2015-04-16 4:10 GMT+09:00 Bjorn Andersson :
> The cleanup during the introduction of regulator_set_load() was a too
> optimistic and re-opened an issue with vreg being dereferenced while
> being NULL.
>
> So reinstate the NULL checks and add back the BUG_ON() to follow the
> general coding convention of the implementation.
>
> Fixes: 7b16a07c3293 ("ufs: Rename of regulator_set_optimum_mode")
> Reported-by: Akinobu Mita
> Signed-off-by: Bjorn Andersson
Tested-by: Akinobu Mita
This patch still isn't picked up by scsi tree nor regulator tree.
James, Mark,
Could you consider taking care of this patch?
> ---
> drivers/scsi/ufs/ufshcd.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 648a44675880..540e00df6de1 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -4262,8 +4262,7 @@ static int ufshcd_config_vreg_load(struct device *dev,
> struct ufs_vreg *vreg,
> {
> int ret;
>
> - if (!vreg)
> - return 0;
> + BUG_ON(!vreg);
>
> ret = regulator_set_load(vreg->reg, ua);
> if (ret < 0) {
> @@ -4277,12 +4276,18 @@ static int ufshcd_config_vreg_load(struct device
> *dev, struct ufs_vreg *vreg,
> static inline int ufshcd_config_vreg_lpm(struct ufs_hba *hba,
> struct ufs_vreg *vreg)
> {
> + if (!vreg)
> + return 0;
> +
> return ufshcd_config_vreg_load(hba->dev, vreg, UFS_VREG_LPM_LOAD_UA);
> }
>
> static inline int ufshcd_config_vreg_hpm(struct ufs_hba *hba,
> struct ufs_vreg *vreg)
> {
> + if (!vreg)
> + return 0;
> +
> return ufshcd_config_vreg_load(hba->dev, vreg, vreg->max_uA);
> }
>
> --
> 1.8.2.2
>
--
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 3/3] scsi: proper state checking and module refcount handling in scsi_device_get
2015-02-02 22:01 GMT+09:00 Christoph Hellwig :
> This effectively reverts commits 85b6c7 ("[SCSI] sd: fix cache flushing on
> module removal (and individual device removal)" and dc4515ea ("scsi: always
> increment reference count").
>
> We now never call scsi_device_get from the shutdown path, and the fact
> that we started grabbing reference there in commit 85b6c7 turned out
> turned out to create more problems than it solves, and required
> workarounds for workarounds for workarounds. Move back to properly checking
> the device state and carefully handle module refcounting.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/scsi.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 9b38299..9b7fd0b 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -979,18 +979,24 @@ EXPORT_SYMBOL(scsi_report_opcode);
> * Description: Gets a reference to the scsi_device and increments the use
> count
> * of the underlying LLDD module. You must hold host_lock of the
> * parent Scsi_Host or already have a reference when calling this.
> + *
> + * This will fail if a device is deleted or cancelled, or when the LLD module
> + * is in the process of being unloaded.
> */
> int scsi_device_get(struct scsi_device *sdev)
Hi Christoph,
This change broke ufs driver.
Because scsi_device_get() can be called while the module is being
unloaded with the device runtime suspended.
(i.e. driver_detach -> ... pm_runtime_get_sync() ... ->
ufshcd_runtime_resume -> ufshcd_resume -> ufshcd_set_dev_pwr_mode ->
scsi_device_get -> try_module_get -> return -ENXIO)
The reason for scsi_device_get() in ufshcd_set_dev_pwr_mode() is
to avoid manual delete of UFS device W-LUN by holding the reference
to it. So can we acquire shost->scan_mutex lock instead of
scsi_device_get()? I tried attached patch and it seems to be working,
but I would like to ask your opinion about this change.
> {
> - if (sdev->sdev_state == SDEV_DEL)
> - return -ENXIO;
> + if (sdev->sdev_state == SDEV_DEL || sdev->sdev_state == SDEV_CANCEL)
> + goto fail;
> if (!get_device(&sdev->sdev_gendev))
> - return -ENXIO;
> - /* We can fail try_module_get if we're doing SCSI operations
> -* from module exit (like cache flush) */
> - __module_get(sdev->host->hostt->module);
> -
> + goto fail;
> + if (!try_module_get(sdev->host->hostt->module))
> + goto fail_put_device;
> return 0;
> +
> +fail_put_device:
> + put_device(&sdev->sdev_gendev);
> +fail:
> + return -ENXIO;
> }
> EXPORT_SYMBOL(scsi_device_get);
>
> --
> 1.9.1
>
> --
> 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
From a305a5284cac23adbf7f86b3014cc2e6325c7b88 Mon Sep 17 00:00:00 2001
From: Akinobu Mita
Date: Wed, 29 Apr 2015 10:02:17 +0900
Subject: [PATCH] scsi: ufs: fix ufshcd_set_dev_pwr_mode() when unloading
module
---
drivers/scsi/ufs/ufshcd.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 540e00d..91cbc04 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4695,23 +4695,19 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
struct scsi_sense_hdr sshdr;
struct scsi_device *sdp;
unsigned long flags;
- int ret;
+ int ret = 0;
+ mutex_lock(&hba->host->scan_mutex);
spin_lock_irqsave(hba->host->host_lock, flags);
sdp = hba->sdev_ufs_device;
- if (sdp) {
- ret = scsi_device_get(sdp);
- if (!ret && !scsi_device_online(sdp)) {
- ret = -ENODEV;
- scsi_device_put(sdp);
- }
- } else {
+ if (!sdp || !scsi_device_online(sdp))
ret = -ENODEV;
- }
spin_unlock_irqrestore(hba->host->host_lock, flags);
- if (ret)
+ if (ret) {
+ mutex_unlock(&hba->host->scan_mutex);
return ret;
+ }
/*
* If scsi commands fail, the scsi mid-layer schedules scsi error-
@@ -4748,7 +4744,7 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
if (!ret)
hba->curr_dev_pwr_mode = pwr_mode;
out:
- scsi_device_put(sdp);
+ mutex_unlock(&hba->host->scan_mutex);
hba->host->eh_noresume = 0;
return ret;
}
--
1.9.1
Re: [PATCH] scatterlist: enable sg chaining for all architectures
On Wed, 2015-04-29 at 09:34 +0900, Akinobu Mita wrote: > 2015-04-29 7:16 GMT+09:00 James Bottomley > : > > On Tue, 2015-04-28 at 14:27 -0700, Andrew Morton wrote: > >> On Sat, 25 Apr 2015 23:56:16 +0900 Akinobu Mita > >> wrote: > >> > >> > Some architectures enable sg chaining option while others do not. > >> > > >> > The requirement to enable sg chaining is that pages must be aligned > >> > at a 32-bit boundary in order to overload the LSB of the pointer. > >> > Regardless of whether ARCH_HAS_SG_CHAIN is defined or not, the above > >> > requirement is always chacked by BUG_ON() in sg_assign_page. So > >> > all architectures can enable sg chaining. > >> > > >> > As you can see from the changes in drivers/target/target_core_rd.c, > >> > enabling SG chaining for all architectures allows us to allocate > >> > discontiguous scatterlist tables which can be traversed throughout > >> > by sg_next() without a special handling for some architectures. > >> > >> Thanks, I'll grab this. If anyone has concerns, speak now or hold both > >> pieces! > > > > It breaks a host of architectures doesn't it? I can specifically speak > > for PARISC: The problem is the way our iommus are consuming > > scatterlists. They're assuming we can dereference the scatterlist as an > > array (like this code in ccio-dma.c): > > > > static int > > ccio_map_sg(struct device *dev, struct scatterlist *sglist, int nents, > > enum dma_data_direction direction) > > [...] > > for(i = 0; i < nents; i++) > > prev_len += sglist[i].length; > > > > If you turn on sg chaining on our architecture, we'll run off the end of > > that array dereference and crash. > > > > This can all be fixed by making our architecture dma mapping code use > > iterators instead of array lists, but that needs more code than this > > patch provides. I assume there are similar issues on a lot of other > > architectures, so before you can contemplate a patch like this, surely > > all the architecture consumers have to be converted to iterator instead > > of array format? > > > > The first place to start would be a survey of who's still using the > > array format. > > Agreed. I could find similar issues in arch/m68k/kernel/dma.c. > (git grep '[^a-z]sg++' shows that there are a lot of similar issues) OK, so the original idea of the chained SG lists was that most of the older architectures have fixed length lists for their IOMMUs, or simply wouldn't see a benefit with IO lengths > 0.5MB (which was the default before chaining) so there wasn't much point converting them to chaining if they wouldn't see any benefit from it. ARCH_HAS_SG_CHAIN is supposed to be completely transparent to all driver side consumers, so there was never thought to be much point removing it. It looks like there's some sort of cockup going on in the target driver but otherwise, your removal patch is pretty empty, confirming this. Perhaps the best thing to do is just fix target and call it quits? James -- 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 1/3] megaraid: use dev_printk when possible
>-Original Message-
>From: Bjorn Helgaas [mailto:bhelg...@google.com]
>Sent: Wednesday, April 29, 2015 4:44 AM
>To: Kashyap Desai; Uday Lingala; Sumit Saxena
>Cc: megaraidlinux@avagotech.com; James E.J. Bottomley; linux-
>ker...@vger.kernel.org; linux-scsi@vger.kernel.org
>Subject: [PATCH 1/3] megaraid: use dev_printk when possible
>
>Use dev_printk() when possible to make messages more useful.
>
>Signed-off-by: Bjorn Helgaas
>---
> drivers/scsi/megaraid.c | 92
> ++---
>--
> 1 file changed, 43 insertions(+), 49 deletions(-)
>
>diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index
>bc7b34c..47cda02 100644
>--- a/drivers/scsi/megaraid.c
>+++ b/drivers/scsi/megaraid.c
>@@ -268,7 +268,7 @@ mega_query_adapter(adapter_t *adapter)
> raw_mbox[2] = NC_SUBOP_PRODUCT_INFO;/* i.e. 0x0E */
>
> if ((retval = issue_scb_block(adapter, raw_mbox)))
>- printk(KERN_WARNING
>+ dev_warn(&adapter->dev->dev,
> "megaraid: Product_info cmd failed with error: %d\n",
> retval);
>
>@@ -334,7 +334,7 @@ mega_query_adapter(adapter_t *adapter)
> adapter->bios_version[4] = 0;
> }
>
>- printk(KERN_NOTICE "megaraid: [%s:%s] detected %d logical
>drives.\n",
>+ dev_notice(&adapter->dev->dev, "[%s:%s] detected %d logical
>+drives.\n",
> adapter->fw_version, adapter->bios_version, adapter-
>>numldrv);
>
> /*
>@@ -342,7 +342,7 @@ mega_query_adapter(adapter_t *adapter)
>*/
> adapter->support_ext_cdb = mega_support_ext_cdb(adapter);
> if (adapter->support_ext_cdb)
>- printk(KERN_NOTICE "megaraid: supports extended
>CDBs.\n");
>+ dev_notice(&adapter->dev->dev, "supports extended
>CDBs.\n");
>
>
> return 0;
>@@ -678,7 +678,7 @@ mega_build_cmd(adapter_t *adapter, Scsi_Cmnd
>*cmd, int *busy)
>
> if(!(adapter->flag & (1L << cmd->device->channel))) {
>
>- printk(KERN_NOTICE
>+ dev_notice(&adapter->dev->dev,
> "scsi%d: scanning scsi channel %d ",
> adapter->host->host_no,
> cmd->device->channel);
>@@ -983,7 +983,7 @@ mega_prepare_passthru(adapter_t *adapter, scb_t
>*scb, Scsi_Cmnd *cmd,
> case READ_CAPACITY:
> if(!(adapter->flag & (1L << cmd->device->channel))) {
>
>- printk(KERN_NOTICE
>+ dev_notice(&adapter->dev->dev,
> "scsi%d: scanning scsi channel %d [P%d] ",
> adapter->host->host_no,
> cmd->device->channel, channel);
>@@ -1045,7 +1045,7 @@ mega_prepare_extpassthru(adapter_t *adapter,
>scb_t *scb, Scsi_Cmnd *cmd,
> case READ_CAPACITY:
> if(!(adapter->flag & (1L << cmd->device->channel))) {
>
>- printk(KERN_NOTICE
>+ dev_notice(&adapter->dev->dev,
> "scsi%d: scanning scsi channel %d [P%d] ",
> adapter->host->host_no,
> cmd->device->channel, channel);
>@@ -1241,7 +1241,7 @@ issue_scb_block(adapter_t *adapter, u_char
>*raw_mbox)
> return mbox->m_in.status;
>
> bug_blocked_mailbox:
>- printk(KERN_WARNING "megaraid: Blocked mailbox..!!\n");
>+ dev_warn(&adapter->dev->dev, "Blocked mailbox..!!\n");
> udelay (1000);
> return -1;
> }
>@@ -1454,7 +1454,7 @@ mega_cmd_done(adapter_t *adapter, u8
>completed[], int nstatus, int status)
>* Make sure f/w has completed a valid command
>*/
> if( !(scb->state & SCB_ISSUED) || scb->cmd == NULL )
>{
>- printk(KERN_CRIT
>+ dev_crit(&adapter->dev->dev,
> "megaraid: invalid command ");
> printk("Id %d, scb->state:%x, scsi cmd:%p\n",
> cmdid, scb->state, scb->cmd);
>@@ -1467,7 +1467,7 @@ mega_cmd_done(adapter_t *adapter, u8
>completed[], int nstatus, int status)
>*/
> if( scb->state & SCB_ABORT ) {
>
>- printk(KERN_WARNING
>+ dev_warn(&adapter->dev->dev,
> "megaraid: aborted cmd [%x] complete.\n",
> scb->idx);
>
>@@ -1486,7 +1486,7 @@ mega_cmd_done(adapter_t *adapter, u8
>completed[], int nstatus, int status)
>*/
> if( scb->state & SCB_RESET ) {
>
>- printk(KERN_WARNING
>+
RE: [PATCH 2/3] megaraid_sas: use dev_printk when possible
>-Original Message-
>From: Bjorn Helgaas [mailto:bhelg...@google.com]
>Sent: Wednesday, April 29, 2015 4:44 AM
>To: Kashyap Desai; Uday Lingala; Sumit Saxena
>Cc: megaraidlinux@avagotech.com; James E.J. Bottomley; linux-
>ker...@vger.kernel.org; linux-scsi@vger.kernel.org
>Subject: [PATCH 2/3] megaraid_sas: use dev_printk when possible
>
>Use dev_printk() when possible to make messages more useful.
>
>Signed-off-by: Bjorn Helgaas
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 281 ++--
>-
> 1 file changed, 139 insertions(+), 142 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index 890637f..9ef6631 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -217,7 +217,7 @@ struct megasas_cmd *megasas_get_cmd(struct
>megasas_instance
> list_del_init(&cmd->list);
> atomic_set(&cmd->mfi_mpt_pthr, MFI_MPT_DETACHED);
> } else {
>- printk(KERN_ERR "megasas: Command pool empty!\n");
>+ dev_err(&instance->pdev->dev, "Command pool empty!\n");
> }
>
> spin_unlock_irqrestore(&instance->mfi_pool_lock, flags); @@ -382,9
>+382,9 @@ megasas_adp_reset_xscale(struct megasas_instance *instance,
> msleep(1000); /* sleep for 3 secs */
> pcidata = 0;
> pci_read_config_dword(instance->pdev, MFI_1068_PCSR_OFFSET,
>&pcidata);
>- printk(KERN_NOTICE "pcidata = %x\n", pcidata);
>+ dev_notice(&instance->pdev->dev, "pcidata = %x\n", pcidata);
> if (pcidata & 0x2) {
>- printk(KERN_NOTICE "mfi 1068 offset read=%x\n", pcidata);
>+ dev_notice(&instance->pdev->dev, "mfi 1068 offset
>read=%x\n",
>+pcidata);
> pcidata &= ~0x2;
> pci_write_config_dword(instance->pdev,
> MFI_1068_PCSR_OFFSET, pcidata);
>@@ -395,9 +395,9 @@ megasas_adp_reset_xscale(struct megasas_instance
>*instance,
> pcidata = 0;
> pci_read_config_dword(instance->pdev,
> MFI_1068_FW_HANDSHAKE_OFFSET,
>&pcidata);
>- printk(KERN_NOTICE "1068 offset handshake read=%x\n",
>pcidata);
>+ dev_notice(&instance->pdev->dev, "1068 offset handshake
>read=%x\n",
>+pcidata);
> if ((pcidata & 0x) == MFI_1068_FW_READY) {
>- printk(KERN_NOTICE "1068 offset pcidt=%x\n",
>pcidata);
>+ dev_notice(&instance->pdev->dev, "1068 offset
>pcidt=%x\n", pcidata);
> pcidata = 0;
> pci_write_config_dword(instance->pdev,
> MFI_1068_FW_HANDSHAKE_OFFSET,
>pcidata); @@ -836,7 +836,7 @@ megasas_adp_reset_gen2(struct
>megasas_instance *instance,
> while ( !( HostDiag & DIAG_WRITE_ENABLE) ) {
> msleep(100);
> HostDiag = (u32)readl(hostdiag_offset);
>- printk(KERN_NOTICE "RESETGEN2: retry=%x, hostdiag=%x\n",
>+ dev_notice(&instance->pdev->dev, "RESETGEN2: retry=%x,
>+hostdiag=%x\n",
> retry, HostDiag);
>
> if (retry++ >= 100)
>@@ -844,7 +844,7 @@ megasas_adp_reset_gen2(struct megasas_instance
>*instance,
>
> }
>
>- printk(KERN_NOTICE "ADP_RESET_GEN2: HostDiag=%x\n", HostDiag);
>+ dev_notice(&instance->pdev->dev, "ADP_RESET_GEN2:
>HostDiag=%x\n",
>+HostDiag);
>
> writel((HostDiag | DIAG_RESET_ADAPTER), hostdiag_offset);
>
>@@ -854,7 +854,7 @@ megasas_adp_reset_gen2(struct megasas_instance
>*instance,
> while ( ( HostDiag & DIAG_RESET_ADAPTER) ) {
> msleep(100);
> HostDiag = (u32)readl(hostdiag_offset);
>- printk(KERN_NOTICE "RESET_GEN2: retry=%x,
>hostdiag=%x\n",
>+ dev_notice(&instance->pdev->dev, "RESET_GEN2: retry=%x,
>+hostdiag=%x\n",
> retry, HostDiag);
>
> if (retry++ >= 1000)
>@@ -1253,7 +1253,7 @@ megasas_build_dcdb(struct megasas_instance
>*instance, struct scsi_cmnd *scp,
> &pthru->sgl);
>
> if (pthru->sge_count > instance->max_num_sge) {
>- printk(KERN_ERR "megasas: DCDB two many SGE
>NUM=%x\n",
>+ dev_err(&instance->pdev->dev, "DCDB two many SGE
>NUM=%x\n",
> pthru->sge_count);
> return 0;
> }
>@@ -1394,7 +1394,7 @@ megasas_build_ldio(struct megasas_instance
>*instance, struct scsi_cmnd *scp,
> ldio->sge_count = megasas_make_sgl32(instance, scp, &ldio-
>>sgl);
>
> if (ldio->sge_count > instance->max_num_sge) {
>- printk(KERN_ERR "megasas: build_ld_io: sge_count = %x\n",
>+ dev_err(&instance->pdev->dev, "build_ld_io: sge_count =
>%x\n",
> ldio->sge_count);
> return 0;
> }
>@@ -1461,24 +1461
RE: [PATCH 3/3] megaraid_sas: use dev_printk when possible
>-Original Message-
>From: Bjorn Helgaas [mailto:bhelg...@google.com]
>Sent: Wednesday, April 29, 2015 4:44 AM
>To: Kashyap Desai; Uday Lingala; Sumit Saxena
>Cc: megaraidlinux@avagotech.com; James E.J. Bottomley; linux-
>ker...@vger.kernel.org; linux-scsi@vger.kernel.org
>Subject: [PATCH 3/3] megaraid_sas: use dev_printk when possible
>
>Use dev_printk() when possible to make messages more useful.
>
>Signed-off-by: Bjorn Helgaas
>---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 96 ++-
>
> 1 file changed, 48 insertions(+), 48 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>index 5a0800d..0b20bd8 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>@@ -173,7 +173,7 @@ struct megasas_cmd_fusion
>*megasas_get_cmd_fusion(struct megasas_instance
>struct megasas_cmd_fusion, list);
> list_del_init(&cmd->list);
> } else {
>- printk(KERN_ERR "megasas: Command pool (fusion)
>empty!\n");
>+ dev_err(&instance->pdev->dev, "Command pool (fusion)
>empty!\n");
> }
>
> spin_unlock_irqrestore(&fusion->mpt_pool_lock, flags); @@ -244,7
>+244,7 @@ static void megasas_teardown_frame_pool_fusion(
> struct megasas_cmd_fusion *cmd;
>
> if (!fusion->sg_dma_pool || !fusion->sense_dma_pool) {
>- printk(KERN_ERR "megasas: dma pool is null. SG Pool %p, "
>+ dev_err(&instance->pdev->dev, "dma pool is null. SG Pool
>%p, "
> "sense pool : %p\n", fusion->sg_dma_pool,
> fusion->sense_dma_pool);
> return;
>@@ -356,7 +356,7 @@ static int megasas_create_frame_pool_fusion(struct
>megasas_instance *instance)
> total_sz_chain_frame, 4,
> 0);
> if (!fusion->sg_dma_pool) {
>- printk(KERN_DEBUG "megasas: failed to setup request pool "
>+ dev_printk(KERN_DEBUG, &instance->pdev->dev, "failed to
>setup request pool "
> "fusion\n");
> return -ENOMEM;
> }
>@@ -365,7 +365,7 @@ static int megasas_create_frame_pool_fusion(struct
>megasas_instance *instance)
>SCSI_SENSE_BUFFERSIZE, 64,
>0);
>
> if (!fusion->sense_dma_pool) {
>- printk(KERN_DEBUG "megasas: failed to setup sense pool "
>+ dev_printk(KERN_DEBUG, &instance->pdev->dev, "failed to
>setup sense pool "
> "fusion\n");
> pci_pool_destroy(fusion->sg_dma_pool);
> fusion->sg_dma_pool = NULL;
>@@ -390,7 +390,7 @@ static int megasas_create_frame_pool_fusion(struct
>megasas_instance *instance)
>* whatever has been allocated
>*/
> if (!cmd->sg_frame || !cmd->sense) {
>- printk(KERN_DEBUG "megasas: pci_pool_alloc
>failed\n");
>+ dev_printk(KERN_DEBUG, &instance->pdev->dev,
>"pci_pool_alloc
>+failed\n");
> megasas_teardown_frame_pool_fusion(instance);
> return -ENOMEM;
> }
>@@ -436,7 +436,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance
>*instance)
> &fusion->req_frames_desc_phys,
>GFP_KERNEL);
>
> if (!fusion->req_frames_desc) {
>- printk(KERN_ERR "megasas; Could not allocate memory for "
>+ dev_err(&instance->pdev->dev, "Could not allocate memory
>for "
> "request_frames\n");
> goto fail_req_desc;
> }
>@@ -447,7 +447,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance
>*instance)
> fusion->reply_alloc_sz * count, 16, 0);
>
> if (!fusion->reply_frames_desc_pool) {
>- printk(KERN_ERR "megasas; Could not allocate memory for "
>+ dev_err(&instance->pdev->dev, "Could not allocate memory
>for "
> "reply_frame pool\n");
> goto fail_reply_desc;
> }
>@@ -456,7 +456,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance
>*instance)
> pci_pool_alloc(fusion->reply_frames_desc_pool,
>GFP_KERNEL,
> &fusion->reply_frames_desc_phys);
> if (!fusion->reply_frames_desc) {
>- printk(KERN_ERR "megasas; Could not allocate memory for "
>+ dev_err(&instance->pdev->dev, "Could not allocate memory
>for "
> "reply_frame pool\n");
> pci_pool_destroy(fusion->reply_frames_desc_pool);
> goto fail_reply_desc;
>@@ -473,7 +473,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance
>*instance)
> fusion->io_frames_alloc_sz, 16, 0);
>
> if (!fusion->io_request_frames_pool) {
>- printk
Re: [PATCH] scsi_scan: fix queue depth initialisation problem
On 04/28/2015 11:24 PM, James Bottomley wrote: > From: James Bottomley > Date: Sun, 26 Apr 2015 11:52:46 -0700 > Subject: [PATCH] scsi_scan: fix queue depth initialisation problem > > Currently we blindly use the value of cmd_per_lun as the initial setting for > queue_depth. This fails miserably (hangs the system) if it is zero, which is > the default value for anything uninitialised in the template. The net result > is that every host template has to set a value for cmd_per_lun. Instead, use > a default value of 1 if the actual value is unset. This should pave the way > for removing cmd_per_lun from all the templates and eventually from SCSI > itself. > > Signed-off-by: James Bottomley Tested-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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
[PATCH] scsi: Do not set cmd_per_lun to 1 in the host template
'0' is now used as the default cmd_per_lun value,
so there's no need to explicitly set it to '1' in the
host template.
Signed-off-by: Hannes Reinecke
---
drivers/block/cciss_scsi.c | 1 -
drivers/firewire/sbp2.c | 1 -
drivers/s390/scsi/zfcp_scsi.c | 1 -
drivers/scsi/NCR53c406a.c | 1 -
drivers/scsi/a100u2w.c | 1 -
drivers/scsi/aha152x.c | 1 -
drivers/scsi/aha1542.c | 1 -
drivers/scsi/aha1740.c | 1 -
drivers/scsi/aha1740.h | 1 -
drivers/scsi/aic94xx/aic94xx_init.c | 1 -
drivers/scsi/arm/arxescsi.c | 1 -
drivers/scsi/arm/cumana_2.c | 1 -
drivers/scsi/arm/eesox.c| 1 -
drivers/scsi/atp870u.c | 1 -
drivers/scsi/atp870u.h | 1 -
drivers/scsi/dpt_i2o.c | 1 -
drivers/scsi/fdomain.c | 1 -
drivers/scsi/imm.c | 1 -
drivers/scsi/initio.c | 1 -
drivers/scsi/isci/init.c| 1 -
drivers/scsi/mac53c94.c | 1 -
drivers/scsi/mvsas/mv_init.c| 1 -
drivers/scsi/nsp32.c| 1 -
drivers/scsi/pcmcia/nsp_cs.c| 1 -
drivers/scsi/pcmcia/qlogic_stub.c | 1 -
drivers/scsi/pcmcia/sym53c500_cs.c | 1 -
drivers/scsi/pm8001/pm8001_init.c | 1 -
drivers/scsi/ppa.c | 1 -
drivers/scsi/ps3rom.c | 1 -
drivers/scsi/qla1280.c | 1 -
drivers/scsi/qlogicfas.c| 1 -
drivers/scsi/qlogicpti.c| 1 -
drivers/scsi/sym53c416.c| 1 -
drivers/scsi/wd719x.c | 1 -
drivers/scsi/wd719x.h | 2 --
drivers/staging/rts5208/rtsx.c | 1 -
drivers/usb/image/microtek.c| 1 -
drivers/usb/storage/scsiglue.c | 1 -
drivers/usb/storage/uas.c | 1 -
include/linux/libata.h | 2 --
40 files changed, 42 deletions(-)
diff --git a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
index ecd845c..1537302 100644
--- a/drivers/block/cciss_scsi.c
+++ b/drivers/block/cciss_scsi.c
@@ -84,7 +84,6 @@ static struct scsi_host_template cciss_driver_template = {
.show_info = cciss_scsi_show_info,
.queuecommand = cciss_scsi_queue_command,
.this_id= 7,
- .cmd_per_lun= 1,
.use_clustering = DISABLE_CLUSTERING,
/* Can't have eh_bus_reset_handler or eh_host_reset_handler for cciss */
.eh_device_reset_handler= cciss_eh_device_reset_handler,
diff --git a/drivers/firewire/sbp2.c b/drivers/firewire/sbp2.c
index c22606f..6bac039 100644
--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
@@ -1611,7 +1611,6 @@ static struct scsi_host_template scsi_driver_template = {
.this_id= -1,
.sg_tablesize = SG_ALL,
.use_clustering = ENABLE_CLUSTERING,
- .cmd_per_lun= 1,
.can_queue = 1,
.sdev_attrs = sbp2_scsi_sysfs_attrs,
};
diff --git a/drivers/s390/scsi/zfcp_scsi.c b/drivers/s390/scsi/zfcp_scsi.c
index 75f4bfc..b3c6ff4 100644
--- a/drivers/s390/scsi/zfcp_scsi.c
+++ b/drivers/s390/scsi/zfcp_scsi.c
@@ -297,7 +297,6 @@ static struct scsi_host_template zfcp_scsi_host_template = {
* ZFCP_QDIO_MAX_SBALS_PER_REQ) - 2) * 8,
/* GCD, adjusted later */
.dma_boundary= ZFCP_QDIO_SBALE_LEN - 1,
- .cmd_per_lun = 1,
.use_clustering = 1,
.shost_attrs = zfcp_sysfs_shost_attrs,
.sdev_attrs = zfcp_sysfs_sdev_attrs,
diff --git a/drivers/scsi/NCR53c406a.c b/drivers/scsi/NCR53c406a.c
index 42c7161..6e110c6 100644
--- a/drivers/scsi/NCR53c406a.c
+++ b/drivers/scsi/NCR53c406a.c
@@ -1064,7 +1064,6 @@ static struct scsi_host_template driver_template =
.can_queue= 1 /* can_queue */,
.this_id = 7 /* SCSI ID of the chip
*/,
.sg_tablesize = 32/*SG_ALL*/ /*SG_NONE*/,
- .cmd_per_lun = 1 /* commands per lun */,
.unchecked_isa_dma= 1 /* unchecked_isa_dma */,
.use_clustering = ENABLE_CLUSTERING,
};
diff --git a/drivers/scsi/a100u2w.c b/drivers/scsi/a100u2w.c
index 7e33a61..cac6b37 100644
--- a/drivers/scsi/a100u2w.c
+++ b/drivers/scsi/a100u2w.c
@@ -1078,7 +1078,6 @@ static struct scsi_host_template inia100_template = {
.can_queue = 1,
.this_id= 1,
.sg_tablesize = SG_ALL,
- .cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
};
diff --git a/drivers/scsi/aha152x.c b/drivers/scsi/aha152x.c
index e31c460..f44d048 100644
--- a/drivers/scsi/aha152x.c
+++ b/drivers/scsi/aha152x.c
@@ -2922,7 +2922,
