Re: [PATCHv2 00/12] Re-implement am53c974 driver
I'm tempted to merge this into drivers-for-3.19 ASAP, any argument against that? Guennadi, do you have any additional hardware to Hannes one real and one virtual adapter to test this new driver on before? -- 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: Another (ESP?) scsi blk-mq problem on sparc64
On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote: I would suggest looking into the possibility that we allocate the memory using the count of valid cpus, rather than the largest cpu number. That's a common error that runs into problems with discontiguous cpu numbering like Sparc sometimes has. Yes, that does look like the case. Do you have a good trick on how to allocate a map for the highest possible cpu number without first iterating the cpu map? I couldn't find something that looks like a highest_possible_cpu() helper. -- 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: [PATCHv2 00/12] Re-implement am53c974 driver
On 11/24/2014 09:14 AM, Christoph Hellwig wrote: I'm tempted to merge this into drivers-for-3.19 ASAP, any argument against that? Guennadi, do you have any additional hardware to Hannes one real and one virtual adapter to test this new driver on before? Certainly not from me :-) It would be nice to have it in, as then I could do some more in-depth testing for EH async aborts and the EH rework in general. And qemu would finally have all SCSI HBAs working again :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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] blk-mq: handle the single queue case in blk_mq_hctx_next_cpu
Don't duplicate the code to handle the not cpu bounce case in the
caller, do it inside blk_mq_hctx_next_cpu instead.
Signed-off-by: Christoph Hellwig h...@lst.de
---
block/blk-mq.c | 31 ++-
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c234f33..f8e5358 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -798,10 +798,11 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx
*hctx)
*/
static int blk_mq_hctx_next_cpu(struct blk_mq_hw_ctx *hctx)
{
- int cpu = hctx-next_cpu;
+ if (hctx-queue-nr_hw_queues == 1)
+ return WORK_CPU_UNBOUND;
if (--hctx-next_cpu_batch = 0) {
- int next_cpu;
+ int cpu = hctx-next_cpu, next_cpu;
next_cpu = cpumask_next(hctx-next_cpu, hctx-cpumask);
if (next_cpu = nr_cpu_ids)
@@ -809,9 +810,11 @@ static int blk_mq_hctx_next_cpu(struct blk_mq_hw_ctx *hctx)
hctx-next_cpu = next_cpu;
hctx-next_cpu_batch = BLK_MQ_CPU_WORK_BATCH;
+
+ return cpu;
}
- return cpu;
+ return hctx-next_cpu;
}
void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool async)
@@ -830,14 +833,8 @@ void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool
async)
put_cpu();
}
- if (hctx-queue-nr_hw_queues == 1)
- kblockd_schedule_delayed_work(hctx-run_work, 0);
- else {
- unsigned int cpu;
-
- cpu = blk_mq_hctx_next_cpu(hctx);
- kblockd_schedule_delayed_work_on(cpu, hctx-run_work, 0);
- }
+ kblockd_schedule_delayed_work_on(blk_mq_hctx_next_cpu(hctx),
+ hctx-run_work, 0);
}
void blk_mq_run_queues(struct request_queue *q, bool async)
@@ -929,16 +926,8 @@ static void blk_mq_delay_work_fn(struct work_struct *work)
void blk_mq_delay_queue(struct blk_mq_hw_ctx *hctx, unsigned long msecs)
{
- unsigned long tmo = msecs_to_jiffies(msecs);
-
- if (hctx-queue-nr_hw_queues == 1)
- kblockd_schedule_delayed_work(hctx-delay_work, tmo);
- else {
- unsigned int cpu;
-
- cpu = blk_mq_hctx_next_cpu(hctx);
- kblockd_schedule_delayed_work_on(cpu, hctx-delay_work, tmo);
- }
+ kblockd_schedule_delayed_work_on(blk_mq_hctx_next_cpu(hctx),
+ hctx-delay_work, msecs_to_jiffies(msecs));
}
EXPORT_SYMBOL(blk_mq_delay_queue);
--
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
[PATCH] libsas: allow async aborts
We now first try to call -eh_abort_handler from a work queue, but libsas was always failing that for no good reason. Allow async aborts. Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/scsi/libsas/sas_scsi_host.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c index 89e8b68..3ebdfaf 100644 --- a/drivers/scsi/libsas/sas_scsi_host.c +++ b/drivers/scsi/libsas/sas_scsi_host.c @@ -539,9 +539,6 @@ int sas_eh_abort_handler(struct scsi_cmnd *cmd) struct Scsi_Host *host = cmd-device-host; struct sas_internal *i = to_sas_internal(host-transportt); - if (current != host-ehandler) - return FAILED; - if (!i-dft-lldd_abort_task) return FAILED; -- 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
[PATCH] libsas: remove task_collector mode
The task_collector mode (or latency_injector, (C) Dan Willians) is an optional I/O path in libsas that queues up scsi commands instead of directly sending it to the hardware. It generall increases latencies to in the optiomal case slightly reduce mmio traffic to the hardware. Only the obsolete aic94xx driver and the mvsas driver allowed to use it without recompiling the kernel, and most drivers didn't support it at all. Remove the giant blob of code to allow better optimizations for scsi-mq in the future. Signed-off-by: Christoph Hellwig h...@lst.de --- Documentation/scsi/libsas.txt | 82 + drivers/scsi/aic94xx/aic94xx.h | 2 +- drivers/scsi/aic94xx/aic94xx_hwi.c | 3 +- drivers/scsi/aic94xx/aic94xx_init.c | 11 --- drivers/scsi/aic94xx/aic94xx_task.c | 13 ++- drivers/scsi/isci/init.c| 2 - drivers/scsi/isci/task.c| 147 ++ drivers/scsi/isci/task.h| 1 - drivers/scsi/libsas/sas_ata.c | 9 +- drivers/scsi/libsas/sas_expander.c | 2 +- drivers/scsi/libsas/sas_init.c | 21 - drivers/scsi/libsas/sas_internal.h | 2 - drivers/scsi/libsas/sas_scsi_host.c | 176 +--- drivers/scsi/mvsas/mv_init.c| 22 - drivers/scsi/mvsas/mv_sas.c | 109 +- drivers/scsi/mvsas/mv_sas.h | 10 +- drivers/scsi/pm8001/pm8001_init.c | 2 - drivers/scsi/pm8001/pm8001_sas.c| 22 + drivers/scsi/pm8001/pm8001_sas.h| 3 +- include/scsi/libsas.h | 14 +-- 20 files changed, 97 insertions(+), 556 deletions(-) diff --git a/Documentation/scsi/libsas.txt b/Documentation/scsi/libsas.txt index 3cc9c78..8cac649 100644 --- a/Documentation/scsi/libsas.txt +++ b/Documentation/scsi/libsas.txt @@ -226,9 +226,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha) my_ha-sas_ha.lldd_dev_found = my_dev_found; my_ha-sas_ha.lldd_dev_gone = my_dev_gone; - my_ha-sas_ha.lldd_max_execute_num = lldd_max_execute_num; (1) - - my_ha-sas_ha.lldd_queue_size = ha_can_queue; my_ha-sas_ha.lldd_execute_task = my_execute_task; my_ha-sas_ha.lldd_abort_task = my_abort_task; @@ -247,28 +244,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha) return sas_register_ha(my_ha-sas_ha); } -(1) This is normally a LLDD parameter, something of the -lines of a task collector. What it tells the SAS Layer is -whether the SAS layer should run in Direct Mode (default: -value 0 or 1) or Task Collector Mode (value greater than 1). - -In Direct Mode, the SAS Layer calls Execute Task as soon as -it has a command to send to the SDS, _and_ this is a single -command, i.e. not linked. - -Some hardware (e.g. aic94xx) has the capability to DMA more -than one task at a time (interrupt) from host memory. Task -Collector Mode is an optional feature for HAs which support -this in their hardware. (Again, it is completely optional -even if your hardware supports it.) - -In Task Collector Mode, the SAS Layer would do _natural_ -coalescing of tasks and at the appropriate moment it would -call your driver to DMA more than one task in a single HA -interrupt. DMBS may want to use this by insmod/modprobe -setting the lldd_max_execute_num to something greater than -1. - (2) SAS 1.1 does not define I_T Nexus Reset TMF. Events @@ -325,71 +300,22 @@ PHYE_SPINUP_HOLD -- SATA is present, COMWAKE not sent. The Execute Command SCSI RPC: - int (*lldd_execute_task)(struct sas_task *, int num, -unsigned long gfp_flags); + int (*lldd_execute_task)(struct sas_task *, gfp_t gfp_flags); -Used to queue a task to the SAS LLDD. @task is the tasks to -be executed. @num should be the number of tasks being -queued at this function call (they are linked listed via -task::list), @gfp_mask should be the gfp_mask defining the -context of the caller. +Used to queue a task to the SAS LLDD. @task is the task to be executed. +@gfp_mask is the gfp_mask defining the context of the caller. This function should implement the Execute Command SCSI RPC, -or if you're sending a SCSI Task as linked commands, you -should also use this function. -That is, when lldd_execute_task() is called, the command(s) +That is, when lldd_execute_task() is called, the command go out on the transport *immediately*. There is *no* queuing of any sort and at any level in a SAS LLDD. -The use of task::list is two-fold, one for linked commands, -the other discussed below. - -It is possible to queue up more than one task at a time, by -initializing the list element of struct sas_task, and -passing the number of tasks enlisted in this manner in num. - Returns: -SAS_QUEUE_FULL, -ENOMEM, nothing was queued; 0, the task(s) were queued. -If you want to pass num 1, then either -A) you're the only caller of this function and keep track - of what you've queued to the LLDD, or -B) you
Re: [PATCH] scsi_debug: switch to table based parser
Any chance to get a review for this one? -- 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] libsas: remove task_collector mode
On 11/24/2014 09:41 AM, Christoph Hellwig wrote: The task_collector mode (or latency_injector, (C) Dan Willians) is an optional I/O path in libsas that queues up scsi commands instead of directly sending it to the hardware. It generall increases latencies to in the optiomal case slightly reduce mmio traffic to the hardware. Only the obsolete aic94xx driver and the mvsas driver allowed to use it without recompiling the kernel, and most drivers didn't support it at all. Remove the giant blob of code to allow better optimizations for scsi-mq in the future. Signed-off-by: Christoph Hellwig h...@lst.de --- Documentation/scsi/libsas.txt | 82 + drivers/scsi/aic94xx/aic94xx.h | 2 +- drivers/scsi/aic94xx/aic94xx_hwi.c | 3 +- drivers/scsi/aic94xx/aic94xx_init.c | 11 --- drivers/scsi/aic94xx/aic94xx_task.c | 13 ++- drivers/scsi/isci/init.c| 2 - drivers/scsi/isci/task.c| 147 ++ drivers/scsi/isci/task.h| 1 - drivers/scsi/libsas/sas_ata.c | 9 +- drivers/scsi/libsas/sas_expander.c | 2 +- drivers/scsi/libsas/sas_init.c | 21 - drivers/scsi/libsas/sas_internal.h | 2 - drivers/scsi/libsas/sas_scsi_host.c | 176 +--- drivers/scsi/mvsas/mv_init.c| 22 - drivers/scsi/mvsas/mv_sas.c | 109 +- drivers/scsi/mvsas/mv_sas.h | 10 +- drivers/scsi/pm8001/pm8001_init.c | 2 - drivers/scsi/pm8001/pm8001_sas.c| 22 + drivers/scsi/pm8001/pm8001_sas.h| 3 +- include/scsi/libsas.h | 14 +-- 20 files changed, 97 insertions(+), 556 deletions(-) diff --git a/Documentation/scsi/libsas.txt b/Documentation/scsi/libsas.txt index 3cc9c78..8cac649 100644 --- a/Documentation/scsi/libsas.txt +++ b/Documentation/scsi/libsas.txt @@ -226,9 +226,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha) my_ha-sas_ha.lldd_dev_found = my_dev_found; my_ha-sas_ha.lldd_dev_gone = my_dev_gone; - my_ha-sas_ha.lldd_max_execute_num = lldd_max_execute_num; (1) - - my_ha-sas_ha.lldd_queue_size = ha_can_queue; my_ha-sas_ha.lldd_execute_task = my_execute_task; my_ha-sas_ha.lldd_abort_task = my_abort_task; @@ -247,28 +244,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha) return sas_register_ha(my_ha-sas_ha); } -(1) This is normally a LLDD parameter, something of the -lines of a task collector. What it tells the SAS Layer is -whether the SAS layer should run in Direct Mode (default: -value 0 or 1) or Task Collector Mode (value greater than 1). - -In Direct Mode, the SAS Layer calls Execute Task as soon as -it has a command to send to the SDS, _and_ this is a single -command, i.e. not linked. - -Some hardware (e.g. aic94xx) has the capability to DMA more -than one task at a time (interrupt) from host memory. Task -Collector Mode is an optional feature for HAs which support -this in their hardware. (Again, it is completely optional -even if your hardware supports it.) - -In Task Collector Mode, the SAS Layer would do _natural_ -coalescing of tasks and at the appropriate moment it would -call your driver to DMA more than one task in a single HA -interrupt. DMBS may want to use this by insmod/modprobe -setting the lldd_max_execute_num to something greater than -1. - (2) SAS 1.1 does not define I_T Nexus Reset TMF. Events @@ -325,71 +300,22 @@ PHYE_SPINUP_HOLD -- SATA is present, COMWAKE not sent. The Execute Command SCSI RPC: - int (*lldd_execute_task)(struct sas_task *, int num, - unsigned long gfp_flags); + int (*lldd_execute_task)(struct sas_task *, gfp_t gfp_flags); -Used to queue a task to the SAS LLDD. @task is the tasks to -be executed. @num should be the number of tasks being -queued at this function call (they are linked listed via -task::list), @gfp_mask should be the gfp_mask defining the -context of the caller. +Used to queue a task to the SAS LLDD. @task is the task to be executed. +@gfp_mask is the gfp_mask defining the context of the caller. This function should implement the Execute Command SCSI RPC, -or if you're sending a SCSI Task as linked commands, you -should also use this function. -That is, when lldd_execute_task() is called, the command(s) +That is, when lldd_execute_task() is called, the command go out on the transport *immediately*. There is *no* queuing of any sort and at any level in a SAS LLDD. -The use of task::list is two-fold, one for linked commands, -the other discussed below. - -It is possible to queue up more than one task at a time, by -initializing the list element of struct sas_task, and -passing the number of tasks enlisted in this manner in num. - Returns: -SAS_QUEUE_FULL, -ENOMEM, nothing was queued; 0, the task(s) were queued. -If
Re: [PATCH] libsas: allow async aborts
On 11/24/2014 09:40 AM, Christoph Hellwig wrote: We now first try to call -eh_abort_handler from a work queue, but libsas was always failing that for no good reason. Allow async aborts. Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/scsi/libsas/sas_scsi_host.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c index 89e8b68..3ebdfaf 100644 --- a/drivers/scsi/libsas/sas_scsi_host.c +++ b/drivers/scsi/libsas/sas_scsi_host.c @@ -539,9 +539,6 @@ int sas_eh_abort_handler(struct scsi_cmnd *cmd) struct Scsi_Host *host = cmd-device-host; struct sas_internal *i = to_sas_internal(host-transportt); - if (current != host-ehandler) - return FAILED; - if (!i-dft-lldd_abort_task) return FAILED; Was about to post a similar patch myself. Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
Re: [PATCH] libsas: remove task_collector mode
Why did you not remove the last argument from asd_can_queue() and asd_can_dequeue(), too? With that patch it's always '1' ... Because I wanted to remove the libsas (mis-)feature and avoid to many boad driver changes. Especially for a unmaintained big driver like aic94xx. This 'while' loop can go, too. Same here. Note that this driver never even allowed task collector mode, so it was already dead code. -- 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] scsi_debug: switch to table based parser
On 10/23/2014 10:33 PM, Douglas Gilbert wrote: Changing a frequently hacked, big switch parser to being table based is, of necessity, not a small patch. Testing showed up some breakages which required extra code and re-factoring. Since supporting the REPORT SUPPORTED OPERATION CODES command, checking cdbs for non-zero values in reserved locations, and the table based parser are closely related; implementing them at the same time seemed to be practical. But some additions, such as the COMPARE AND WRITE command, should really be in their own patches (but adding new bugs was a useful technique for finding existing ones). The first attachment is large and against Christoph's drivers-for-3.19 branch. It will also apply to his drivers-for-3.18 branch. The second, smaller attachment is for anyone who wants to look at (or try) this patch on lk 3.17.1; first apply the second patch, then the first. Almost all of my testing has been on lk 3.17.0 and .1 . Perhaps contributors to this driver, such as Martin Petersen who has written large parts of this driver (e.g. logical block provisioning, DIF and error injection), might run any test cases they have to determine what I have broken. Speed improvements at this stage are marginal at best. ChangeLog: - remove big switch statement in queuecommand() and replace with a table based parser - implement REPORT SUPPORTED OPERATION CODES command which reads that table - add 'strict' option which when set will cause each incoming cdb to be checked against the cdb usage mask held in the table based parser - add logic for ILLEGAL REQUEST sense key specific field pointers, use for most ILLEGAL REQUESTs - add 'capacity data has changed' unit attention since the virtual_gb option can be changed on-the-fly - implement REPORT SUPPORTED TASK MANAGEMENT FUNCTIONS command - implement COMPARE AND WRITE command - implement NDOB (no data-out buffer) in WRITE SAME(16) - make GET LBA STATUS work when no logical block provisioning Todo: - re-order teardown in scsi_debug_exit() - make sdebug_dev_info::stopped atomic (add to end of uas_bm ?) - review Rob Elliott's suggestions; look at speed ups - remove host_lock logic and make the host_lock option a dummy - update some mode page and VPD data to reflect more recent devices - changing remaining and byte handling over to get/put_unaligned_be*() - set INFO field for COMPARE AND WRITE command MISCOMPAREs Signed-off-by: Douglas Gilbert dgilb...@interlog.com Hmm. There are at least three things packed into this patch: - Table-based parsing - Sense code generation fixes for invalid field in cdb - Additional cdb decoding. Can you please split the patch into logical sections, eg patches for - sense code generation improvements - table-based parsing - Additional CDB decoding With that it should be easier to review. And please add a definition to XDWRITEREAD(10) to include/scsi/scsi.h instead of using the raw value in scsi_debug. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
Re: [PATCH] libsas: remove task_collector mode
On 11/24/2014 09:54 AM, Christoph Hellwig wrote: Why did you not remove the last argument from asd_can_queue() and asd_can_dequeue(), too? With that patch it's always '1' ... Because I wanted to remove the libsas (mis-)feature and avoid to many boad driver changes. Especially for a unmaintained big driver like aic94xx. This 'while' loop can go, too. Same here. Note that this driver never even allowed task collector mode, so it was already dead code. Okay. Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
Re: BUG in scsi_lib.c due to a bad commit
On Thu, Nov 20, 2014 at 07:27:49PM +0100, Barto wrote: but the sata DVD burner is now connected on a Jmicron sata PCIe card ( with this configuration the bug doesn't occur ), I don't know if this change can modify the result of your command, here is the result of another command : $ for i in /sys/class/scsi_host/*; do cat $i/proc_name; done pata_jmicron pata_jmicron ata_piix ata_piix ata_piix ata_piix ahci ahci Interesting. So the jmicron card also has a queue depth of just one, but the error still occurs? I've added the linux-ide list, maybe someone there has an idea how piix vs jmicron could have such different behaviors for queueing or error handling. -- 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
LSF/MM 2015 Call For Proposals
The annual Linux Storage, Filesystem and Memory Management Summit for 2015 will be held on March 9th and 10th before the Linux Foundation Vault conference at the Revere Hotel, Boston MA. For those that do not know, Vault is designed to be an event where open source storage and filesystem practitioners meet storage implementors and, as such, it would be of benefit for LSF/MM attendees to go to at least the first day of Vault. http://events.linuxfoundation.org/events/linux-storage-filesystem-and-mm-summit http://events.linuxfoundation.org/events/vault On behalf of the committee I am issuing a call for agenda proposals that are suitable for cross-track discussion as well as technical subjects for the breakout sessions. 1) Proposals for agenda topics should be sent before January 16th, 2015 to: lsf...@lists.linux-foundation.org and cc the Linux list or lists that are most interested in it: ATA: linux-...@vger.kernel.org FS: linux-fsde...@vger.kernel.org MM: linux...@kvack.org SCSI: linux-scsi@vger.kernel.org If advance notice is required for visa applications then please send proposals before January 1st. The committee will complete the first round of selections near that date to accommodate applications. Please tag your proposal with [LSF/MM TOPIC] to make it easier to track. Agenda topics and attendees will be selected by the program committee, but the final agenda will be formed by consensus of the attendees on the day. We will try to cap attendance at around 25-30 per track to facilitate discussions although the final numbers will depend on the room sizes at the venue. 2) Requests to attend the summit should be sent to: lsf...@lists.linux-foundation.org Please summarise what expertise you will bring to the meeting, and what you would like to discuss. Please also tag your email with [LSF/MM ATTEND] so there is less chance of it getting lost. Presentations are allowed to guide discussion, but are strongly discouraged. There will be no recording or audio bridge. However, we expect that written minutes will be published as we did in previous years 2014: http://lwn.net/Articles/LSFMM2014/ 2013: http://lwn.net/Articles/548089/ 2012: http://lwn.net/Articles/490114/ http://lwn.net/Articles/490501/ 3) If you have feedback on last year's meeting that we can use to improve this year's, please also send that to: lsf...@lists.linux-foundation.org 4) We would like to remind those that are are also interested in presenting at the Vault conference that the CFP deadline for Vault is December 1st. Thank you on behalf of the program committee: Storage: James Bottomley Martin Petersen Christoph Hellwig Filesystem: Jeff Layton Ric Wheeler Jan Kara Trond Myklebust Theodore Ts'o MM: Rik van Riel Michel Lespinasse Sasha Levin -- Mel Gorman SUSE Labs -- 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
ARCMSR - Notify sense data report - Lost patch?
Hi, sorting out some diffs between the official Arcea driver and the newest 3.18 patches I found a patch that might got lost: https://lkml.org/lkml/2014/2/20/956 Could you check if that is desired? Thanks in advance. Markus Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Ãber das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497
[PATCH v3 37/41] virtio_scsi: v1.0 support
Note: for consistency, and to avoid sparse errors,
convert all fields, even those no longer in use
for virtio v1.0.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/linux/virtio_scsi.h | 32 +++-
drivers/scsi/virtio_scsi.c | 51 -
2 files changed, 49 insertions(+), 34 deletions(-)
diff --git a/include/linux/virtio_scsi.h b/include/linux/virtio_scsi.h
index de429d1..af44864 100644
--- a/include/linux/virtio_scsi.h
+++ b/include/linux/virtio_scsi.h
@@ -27,13 +27,15 @@
#ifndef _LINUX_VIRTIO_SCSI_H
#define _LINUX_VIRTIO_SCSI_H
+#include linux/virtio_types.h
+
#define VIRTIO_SCSI_CDB_SIZE 32
#define VIRTIO_SCSI_SENSE_SIZE 96
/* SCSI command request, followed by data-out */
struct virtio_scsi_cmd_req {
u8 lun[8]; /* Logical Unit Number */
- u64 tag;/* Command identifier */
+ __virtio64 tag; /* Command identifier */
u8 task_attr; /* Task attribute */
u8 prio;/* SAM command priority field */
u8 crn;
@@ -43,20 +45,20 @@ struct virtio_scsi_cmd_req {
/* SCSI command request, followed by protection information */
struct virtio_scsi_cmd_req_pi {
u8 lun[8]; /* Logical Unit Number */
- u64 tag;/* Command identifier */
+ __virtio64 tag; /* Command identifier */
u8 task_attr; /* Task attribute */
u8 prio;/* SAM command priority field */
u8 crn;
- u32 pi_bytesout;/* DataOUT PI Number of bytes */
- u32 pi_bytesin; /* DataIN PI Number of bytes */
+ __virtio32 pi_bytesout; /* DataOUT PI Number of bytes */
+ __virtio32 pi_bytesin; /* DataIN PI Number of bytes */
u8 cdb[VIRTIO_SCSI_CDB_SIZE];
} __packed;
/* Response, followed by sense data and data-in */
struct virtio_scsi_cmd_resp {
- u32 sense_len; /* Sense data length */
- u32 resid; /* Residual bytes in data buffer */
- u16 status_qualifier; /* Status qualifier */
+ __virtio32 sense_len; /* Sense data length */
+ __virtio32 resid; /* Residual bytes in data buffer */
+ __virtio16 status_qualifier;/* Status qualifier */
u8 status; /* Command completion status */
u8 response;/* Response values */
u8 sense[VIRTIO_SCSI_SENSE_SIZE];
@@ -64,10 +66,10 @@ struct virtio_scsi_cmd_resp {
/* Task Management Request */
struct virtio_scsi_ctrl_tmf_req {
- u32 type;
- u32 subtype;
+ __virtio32 type;
+ __virtio32 subtype;
u8 lun[8];
- u64 tag;
+ __virtio64 tag;
} __packed;
struct virtio_scsi_ctrl_tmf_resp {
@@ -76,20 +78,20 @@ struct virtio_scsi_ctrl_tmf_resp {
/* Asynchronous notification query/subscription */
struct virtio_scsi_ctrl_an_req {
- u32 type;
+ __virtio32 type;
u8 lun[8];
- u32 event_requested;
+ __virtio32 event_requested;
} __packed;
struct virtio_scsi_ctrl_an_resp {
- u32 event_actual;
+ __virtio32 event_actual;
u8 response;
} __packed;
struct virtio_scsi_event {
- u32 event;
+ __virtio32 event;
u8 lun[8];
- u32 reason;
+ __virtio32 reason;
} __packed;
struct virtio_scsi_config {
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index b83846f..c2779ea 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -158,7 +158,7 @@ static void virtscsi_complete_cmd(struct virtio_scsi
*vscsi, void *buf)
sc, resp-response, resp-status, resp-sense_len);
sc-result = resp-status;
- virtscsi_compute_resid(sc, resp-resid);
+ virtscsi_compute_resid(sc, __virtio32_to_cpu(vscsi-vdev, resp-resid));
switch (resp-response) {
case VIRTIO_SCSI_S_OK:
set_host_byte(sc, DID_OK);
@@ -196,10 +196,13 @@ static void virtscsi_complete_cmd(struct virtio_scsi
*vscsi, void *buf)
break;
}
- WARN_ON(resp-sense_len VIRTIO_SCSI_SENSE_SIZE);
+ WARN_ON(__virtio32_to_cpu(vscsi-vdev, resp-sense_len)
+ VIRTIO_SCSI_SENSE_SIZE);
if (sc-sense_buffer) {
memcpy(sc-sense_buffer, resp-sense,
- min_t(u32, resp-sense_len, VIRTIO_SCSI_SENSE_SIZE));
+ min_t(u32,
+__virtio32_to_cpu(vscsi-vdev, resp-sense_len),
+VIRTIO_SCSI_SENSE_SIZE));
if (resp-sense_len)
set_driver_byte(sc, DRIVER_SENSE);
}
@@ -323,7 +326,7 @@ static void virtscsi_handle_transport_reset(struct
virtio_scsi *vscsi,
unsigned int target = event-lun[1];
unsigned int lun = (event-lun[2] 8) | event-lun[3];
- switch (event-reason) {
+ switch
[PATCH 2/3] wd719x: Introduce Western Digital WD7193/7197/7296 PCI SCSI card driver
Introduce wd719x, a driver for Western Digital WD7193, WD7197 and WD7296 PCI
SCSI controllers based on WD33C296A chip.
Tested with WD7193 card.
Reviewed-by: Christoph Hellwig h...@lst.de
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/scsi/Kconfig |8 +
drivers/scsi/Makefile |1 +
drivers/scsi/wd719x.c | 1008 +
drivers/scsi/wd719x.h | 249
4 files changed, 1266 insertions(+)
create mode 100644 drivers/scsi/wd719x.c
create mode 100644 drivers/scsi/wd719x.h
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 3a820f6..fd81d14 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1451,6 +1451,14 @@ config SCSI_NSP32
To compile this driver as a module, choose M here: the
module will be called nsp32.
+config SCSI_WD719X
+ tristate Western Digital WD7193/7197/7296 support
+ depends on PCI SCSI
+ select EEPROM_93CX6
+ ---help---
+ This is a driver for Western Digital WD7193, WD7197 and WD7296 PCI
+ SCSI controllers (based on WD33C296A chip).
+
config SCSI_DEBUG
tristate SCSI debugging host simulator
depends on SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 59f1ce6..d8bfca5 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -143,6 +143,7 @@ obj-$(CONFIG_SCSI_VIRTIO) += virtio_scsi.o
obj-$(CONFIG_VMWARE_PVSCSI)+= vmw_pvscsi.o
obj-$(CONFIG_XEN_SCSI_FRONTEND)+= xen-scsifront.o
obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o
+obj-$(CONFIG_SCSI_WD719X) += wd719x.o
obj-$(CONFIG_ARM) += arm/
diff --git a/drivers/scsi/wd719x.c b/drivers/scsi/wd719x.c
new file mode 100644
index 000..ce6dafd
--- /dev/null
+++ b/drivers/scsi/wd719x.c
@@ -0,0 +1,1008 @@
+/*
+ * Driver for Western Digital WD7193, WD7197 and WD7296 SCSI cards
+ * Copyright 2013 Ondrej Zary
+ *
+ * Original driver by
+ * Aaron Dewell dew...@woods.net
+ * Gaerti juergen.gaert...@mbox.si.uni-hannover.de
+ *
+ * HW documentation available in book:
+ *
+ * SPIDER Command Protocol
+ * by Chandru M. Sippy
+ * SCSI Storage Products (MCP)
+ * Western Digital Corporation
+ * 09-15-95
+ *
+ *
http://web.archive.org/web/20070717175254/http://sun1.rrzn.uni-hannover.de/gaertner.juergen/wd719x/Linux/Docu/Spider/
+ */
+
+/*
+ * Driver workflow:
+ * 1. SCSI command is transformed to SCB (Spider Control Block) by the
+ *queuecommand function.
+ * 2. The address of the SCB is stored in a list to be able to access it, if
+ *something goes wrong.
+ * 3. The address of the SCB is written to the Controller, which loads the SCB
+ *via BM-DMA and processes it.
+ * 4. After it has finished, it generates an interrupt, and sets registers.
+ *
+ * flaws:
+ * - abort/reset functions
+ *
+ * ToDo:
+ * - tagged queueing
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/pci.h
+#include linux/firmware.h
+#include linux/eeprom_93cx6.h
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_device.h
+#include scsi/scsi_host.h
+#include wd719x.h
+
+/* low-level register access */
+static inline u8 wd719x_readb(struct wd719x *wd, u8 reg)
+{
+ return ioread8(wd-base + reg);
+}
+
+static inline u32 wd719x_readl(struct wd719x *wd, u8 reg)
+{
+ return ioread32(wd-base + reg);
+}
+
+static inline void wd719x_writeb(struct wd719x *wd, u8 reg, u8 val)
+{
+ iowrite8(val, wd-base + reg);
+}
+
+static inline void wd719x_writew(struct wd719x *wd, u8 reg, u16 val)
+{
+ iowrite16(val, wd-base + reg);
+}
+
+static inline void wd719x_writel(struct wd719x *wd, u8 reg, u32 val)
+{
+ iowrite32(val, wd-base + reg);
+}
+
+/* wait until the command register is ready */
+static inline int wd719x_wait_ready(struct wd719x *wd)
+{
+ int i = 0;
+
+ do {
+ if (wd719x_readb(wd, WD719X_AMR_COMMAND) == WD719X_CMD_READY)
+ return 0;
+ udelay(1);
+ } while (i++ WD719X_WAIT_FOR_CMD_READY);
+
+ dev_err(wd-pdev-dev, command register is not ready: 0x%02x\n,
+ wd719x_readb(wd, WD719X_AMR_COMMAND));
+
+ return -ETIMEDOUT;
+}
+
+/* poll interrupt status register until command finishes */
+static inline int wd719x_wait_done(struct wd719x *wd, int timeout)
+{
+ u8 status;
+
+ while (timeout 0) {
+ status = wd719x_readb(wd, WD719X_AMR_INT_STATUS);
+ if (status)
+ break;
+ timeout--;
+ udelay(1);
+ }
+
+ if (timeout = 0) {
+ dev_err(wd-pdev-dev, direct command timed out\n);
+ return -ETIMEDOUT;
+ }
+
+ if (status != WD719X_INT_NOERRORS) {
+ dev_err(wd-pdev-dev, direct command failed, status 0x%02x,
SUE 0x%02x\n,
+ status, wd719x_readb(wd, WD719X_AMR_SCB_ERROR));
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int
[PATCH 1/3] eeprom-93cx6: Add (read-only) support for 8-bit mode
Add read-only support for EEPROMs configured in 8-bit mode (ORG pin connected
to GND).
This will be used by wd719x driver.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/misc/eeprom/eeprom_93cx6.c | 62 +++-
include/linux/eeprom_93cx6.h |4 +++
2 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/eeprom/eeprom_93cx6.c
b/drivers/misc/eeprom/eeprom_93cx6.c
index 0ff4b02..0cf2c9d 100644
--- a/drivers/misc/eeprom/eeprom_93cx6.c
+++ b/drivers/misc/eeprom/eeprom_93cx6.c
@@ -170,7 +170,7 @@ static void eeprom_93cx6_read_bits(struct eeprom_93cx6
*eeprom,
}
/**
- * eeprom_93cx6_read - Read multiple words from eeprom
+ * eeprom_93cx6_read - Read a word from eeprom
* @eeprom: Pointer to eeprom structure
* @word: Word index from where we should start reading
* @data: target pointer where the information will have to be stored
@@ -235,6 +235,66 @@ void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom,
const u8 word,
EXPORT_SYMBOL_GPL(eeprom_93cx6_multiread);
/**
+ * eeprom_93cx6_readb - Read a byte from eeprom
+ * @eeprom: Pointer to eeprom structure
+ * @word: Byte index from where we should start reading
+ * @data: target pointer where the information will have to be stored
+ *
+ * This function will read a byte of the eeprom data
+ * into the given data pointer.
+ */
+void eeprom_93cx6_readb(struct eeprom_93cx6 *eeprom, const u8 byte,
+ u8 *data)
+{
+ u16 command;
+ u16 tmp;
+
+ /*
+* Initialize the eeprom register
+*/
+ eeprom_93cx6_startup(eeprom);
+
+ /*
+* Select the read opcode and the byte to be read.
+*/
+ command = (PCI_EEPROM_READ_OPCODE (eeprom-width + 1)) | byte;
+ eeprom_93cx6_write_bits(eeprom, command,
+ PCI_EEPROM_WIDTH_OPCODE + eeprom-width + 1);
+
+ /*
+* Read the requested 8 bits.
+*/
+ eeprom_93cx6_read_bits(eeprom, tmp, 8);
+ *data = tmp 0xff;
+
+ /*
+* Cleanup eeprom register.
+*/
+ eeprom_93cx6_cleanup(eeprom);
+}
+EXPORT_SYMBOL_GPL(eeprom_93cx6_readb);
+
+/**
+ * eeprom_93cx6_multireadb - Read multiple bytes from eeprom
+ * @eeprom: Pointer to eeprom structure
+ * @byte: Index from where we should start reading
+ * @data: target pointer where the information will have to be stored
+ * @words: Number of bytes that should be read.
+ *
+ * This function will read all requested bytes from the eeprom,
+ * this is done by calling eeprom_93cx6_readb() multiple times.
+ */
+void eeprom_93cx6_multireadb(struct eeprom_93cx6 *eeprom, const u8 byte,
+ u8 *data, const u16 bytes)
+{
+ unsigned int i;
+
+ for (i = 0; i bytes; i++)
+ eeprom_93cx6_readb(eeprom, byte + i, data[i]);
+}
+EXPORT_SYMBOL_GPL(eeprom_93cx6_multireadb);
+
+/**
* eeprom_93cx6_wren - set the write enable state
* @eeprom: Pointer to eeprom structure
* @enable: true to enable writes, otherwise disable writes
diff --git a/include/linux/eeprom_93cx6.h b/include/linux/eeprom_93cx6.h
index e50f98b..eb0b198 100644
--- a/include/linux/eeprom_93cx6.h
+++ b/include/linux/eeprom_93cx6.h
@@ -75,6 +75,10 @@ extern void eeprom_93cx6_read(struct eeprom_93cx6 *eeprom,
const u8 word, u16 *data);
extern void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom,
const u8 word, __le16 *data, const u16 words);
+extern void eeprom_93cx6_readb(struct eeprom_93cx6 *eeprom,
+ const u8 byte, u8 *data);
+extern void eeprom_93cx6_multireadb(struct eeprom_93cx6 *eeprom,
+ const u8 byte, u8 *data, const u16 bytes);
extern void eeprom_93cx6_wren(struct eeprom_93cx6 *eeprom, bool enable);
--
Ondrej Zary
--
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] wd719x: Introduce Western Digital WD7193/7197/7296 PCI SCSI card driver
Hello, this is a new driver for Western Digital WD7193, WD7197 and WD7296 PCI SCSI controllers based on WD33C296A chip. These nice cards never worked good with Linux. It's based on old and ugly wd719x driver written back in 2.0 days, then hacked to 2.2 and finally to 2.4 kernels. Most of the code is rewritten: from ~4100 lines to ~1200. I've tested the driver on a WD7193 card with some hard drives and CD-ROMs: QUANTUM LP240S GM240S01X 4.6 IBM 0663L12 e g IBM DORS-32160 WA0A SONY CD-ROM CDU-55S 1.0t SONY CD-ROM CDU-415 1.1g The card supports TCQ and linked commands (for cmd_per_lun 1?) but I don't know how it should be implemented in a driver. Device/bus/host resets seem to work fine when tested by sg_reset. But don't know how to test command abort. The card requires firmware that can be cut out of the Windows NT driver that can be downloaded from WD at: http://support.wdc.com/product/download.asp?groupid=801sid=27lang=en There is no license anywhere in the file or on the page - so I guess that the firmware cannot be added to linux-firmware. This script that downloads and extracts the firmware is in Documentation/ -- Ondrej Zary -- 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 3/3] wd719x: Add firmware documentation
Add documentation and script to obtain required firmware. Signed-off-by: Ondrej Zary li...@rainbow-software.org --- Documentation/scsi/wd719x.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/scsi/wd719x.txt diff --git a/Documentation/scsi/wd719x.txt b/Documentation/scsi/wd719x.txt new file mode 100644 index 000..0816b02 --- /dev/null +++ b/Documentation/scsi/wd719x.txt @@ -0,0 +1,21 @@ +Driver for Western Digital WD7193, WD7197 and WD7296 SCSI cards +--- + +The card requires firmware that can be cut out of the Windows NT driver that +can be downloaded from WD at: +http://support.wdc.com/product/download.asp?groupid=801sid=27lang=en + +There is no license anywhere in the file or on the page - so the firmware +probably cannot be added to linux-firmware. + +This script downloads and extracts the firmware, creating wd719x-risc.bin and +d719x-wcs.bin files. Put them in /lib/firmware/. + +#!/bin/sh +wget http://support.wdc.com/download/archive/pciscsi.exe +lha xi pciscsi.exe pci-scsi.exe +lha xi pci-scsi.exe nt/wd7296a.sys +rm pci-scsi.exe +dd if=wd7296a.sys of=wd719x-risc.bin bs=1 skip=5760 count=14336 +dd if=wd7296a.sys of=wd719x-wcs.bin bs=1 skip=20096 count=514 +rm wd7296a.sys -- Ondrej Zary -- 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] eeprom-93cx6: Add (read-only) support for 8-bit mode
On 11/24/2014 01:11 PM, Ondrej Zary wrote: Add read-only support for EEPROMs configured in 8-bit mode (ORG pin connected to GND). This will be used by wd719x driver. Signed-off-by: Ondrej Zary li...@rainbow-software.org Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
Re: [PATCH 2/3] wd719x: Introduce Western Digital WD7193/7197/7296 PCI SCSI card driver
On 11/24/2014 01:11 PM, Ondrej Zary wrote:
Introduce wd719x, a driver for Western Digital WD7193, WD7197 and WD7296 PCI
SCSI controllers based on WD33C296A chip.
Tested with WD7193 card.
Reviewed-by: Christoph Hellwig h...@lst.de
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/scsi/Kconfig |8 +
drivers/scsi/Makefile |1 +
drivers/scsi/wd719x.c | 1008
+
drivers/scsi/wd719x.h | 249
4 files changed, 1266 insertions(+)
create mode 100644 drivers/scsi/wd719x.c
create mode 100644 drivers/scsi/wd719x.h
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 3a820f6..fd81d14 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1451,6 +1451,14 @@ config SCSI_NSP32
To compile this driver as a module, choose M here: the
module will be called nsp32.
+config SCSI_WD719X
+ tristate Western Digital WD7193/7197/7296 support
+ depends on PCI SCSI
+ select EEPROM_93CX6
+ ---help---
+ This is a driver for Western Digital WD7193, WD7197 and WD7296 PCI
+ SCSI controllers (based on WD33C296A chip).
+
config SCSI_DEBUG
tristate SCSI debugging host simulator
depends on SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 59f1ce6..d8bfca5 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -143,6 +143,7 @@ obj-$(CONFIG_SCSI_VIRTIO) += virtio_scsi.o
obj-$(CONFIG_VMWARE_PVSCSI) += vmw_pvscsi.o
obj-$(CONFIG_XEN_SCSI_FRONTEND) += xen-scsifront.o
obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o
+obj-$(CONFIG_SCSI_WD719X)+= wd719x.o
obj-$(CONFIG_ARM)+= arm/
diff --git a/drivers/scsi/wd719x.c b/drivers/scsi/wd719x.c
new file mode 100644
index 000..ce6dafd
--- /dev/null
+++ b/drivers/scsi/wd719x.c
@@ -0,0 +1,1008 @@
+/*
+ * Driver for Western Digital WD7193, WD7197 and WD7296 SCSI cards
+ * Copyright 2013 Ondrej Zary
+ *
+ * Original driver by
+ * Aaron Dewell dew...@woods.net
+ * Gaerti juergen.gaert...@mbox.si.uni-hannover.de
+ *
+ * HW documentation available in book:
+ *
+ * SPIDER Command Protocol
+ * by Chandru M. Sippy
+ * SCSI Storage Products (MCP)
+ * Western Digital Corporation
+ * 09-15-95
+ *
+ *
http://web.archive.org/web/20070717175254/http://sun1.rrzn.uni-hannover.de/gaertner.juergen/wd719x/Linux/Docu/Spider/
+ */
+
+/*
+ * Driver workflow:
+ * 1. SCSI command is transformed to SCB (Spider Control Block) by the
+ *queuecommand function.
+ * 2. The address of the SCB is stored in a list to be able to access it, if
+ *something goes wrong.
+ * 3. The address of the SCB is written to the Controller, which loads the
SCB
+ *via BM-DMA and processes it.
+ * 4. After it has finished, it generates an interrupt, and sets registers.
+ *
+ * flaws:
+ * - abort/reset functions
+ *
+ * ToDo:
+ * - tagged queueing
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/pci.h
+#include linux/firmware.h
+#include linux/eeprom_93cx6.h
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_device.h
+#include scsi/scsi_host.h
+#include wd719x.h
+
+/* low-level register access */
+static inline u8 wd719x_readb(struct wd719x *wd, u8 reg)
+{
+ return ioread8(wd-base + reg);
+}
+
+static inline u32 wd719x_readl(struct wd719x *wd, u8 reg)
+{
+ return ioread32(wd-base + reg);
+}
+
+static inline void wd719x_writeb(struct wd719x *wd, u8 reg, u8 val)
+{
+ iowrite8(val, wd-base + reg);
+}
+
+static inline void wd719x_writew(struct wd719x *wd, u8 reg, u16 val)
+{
+ iowrite16(val, wd-base + reg);
+}
+
+static inline void wd719x_writel(struct wd719x *wd, u8 reg, u32 val)
+{
+ iowrite32(val, wd-base + reg);
+}
+
+/* wait until the command register is ready */
+static inline int wd719x_wait_ready(struct wd719x *wd)
+{
+ int i = 0;
+
+ do {
+ if (wd719x_readb(wd, WD719X_AMR_COMMAND) == WD719X_CMD_READY)
+ return 0;
+ udelay(1);
+ } while (i++ WD719X_WAIT_FOR_CMD_READY);
+
+ dev_err(wd-pdev-dev, command register is not ready: 0x%02x\n,
+ wd719x_readb(wd, WD719X_AMR_COMMAND));
+
+ return -ETIMEDOUT;
+}
+
+/* poll interrupt status register until command finishes */
+static inline int wd719x_wait_done(struct wd719x *wd, int timeout)
+{
+ u8 status;
+
+ while (timeout 0) {
+ status = wd719x_readb(wd, WD719X_AMR_INT_STATUS);
+ if (status)
+ break;
+ timeout--;
+ udelay(1);
+ }
+
+ if (timeout = 0) {
+ dev_err(wd-pdev-dev, direct command timed out\n);
+ return -ETIMEDOUT;
+ }
+
+ if (status != WD719X_INT_NOERRORS) {
+ dev_err(wd-pdev-dev, direct command failed, status 0x%02x,
SUE 0x%02x\n,
+ status,
Re: ARCMSR - Notify sense data report - Lost patch?
On Mon, Nov 24, 2014 at 11:47:02AM +, Markus Stockhausen wrote: Hi, sorting out some diffs between the official Arcea driver and the newest 3.18 patches I found a patch that might got lost: https://lkml.org/lkml/2014/2/20/956 Could you check if that is desired? Looks sensible to me. Did you test it? -- 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 07/12] scsi: add 'am53c974' driver
Can someone give me a review for this patch as well? Fortuately the driver seems incredibly simple. -- 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] aic94xx: Fixup compilation warning
Can someone review this trivial patch for me? Thanks! -- 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
AW: ARCMSR - Notify sense data report - Lost patch?
Von: linux-scsi-ow...@vger.kernel.org [linux-scsi-ow...@vger.kernel.org]quot; im Auftrag von quot;Christoph Hellwig [h...@infradead.org] Gesendet: Montag, 24. November 2014 14:23 An: Markus Stockhausen Cc: ching2...@areca.com.tw; the...@redhat.com; linux-scsi@vger.kernel.org Betreff: Re: ARCMSR - Notify sense data report - Lost patch? On Mon, Nov 24, 2014 at 11:47:02AM +, Markus Stockhausen wrote: Hi, sorting out some diffs between the official Arcea driver and the newest 3.18 patches I found a patch that might got lost: https://lkml.org/lkml/2014/2/20/956 Could you check if that is desired? Looks sensible to me. Did you test it? No not really, as I don't know how. We had a controller crash the last week and I was wondering about the differences between vendor and upstream version. So I basically did some code comparison between the two source. Besides a lot of layout differences and other hacks this was one of the first things I noticed and wondered what difference those flags could make. Especially regarding stability. Hopefully Ching and/or Tomas know better as they seem repsonsible for the rest of the 3.18 arcmsr patches. Markus Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Ãber das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497
Re: [PATCH 07/12] scsi: add 'am53c974' driver
+/*
+ * AMD am53c974 driver.
+ * Copyright (c) 2014 Hannes Reinecke, SUSE Linux GmbH
+ */
Is there anything left from the old driver that should get credit here?
+#define PCI_ESP_GET_PRIV(esp) ((struct pci_esp_priv *) \
+pci_get_drvdata((struct pci_dev *) \
+(esp)-dev))
I think an inline function would be a lot cleaner, especially as that
should avoid all these casts.
+#ifdef ESP_DMA_DEBUG
+ shost_printk(KERN_INFO, esp-host, start dma addr[%x] count[%d:%d]\n,
+ addr, esp_count, dma_count);
+#endif
Can you add a esp_dma_printk or similar instead of all these ifdefs?
+ u8 carryFlag = 1, j = 0x80, bval;
carry_flag.
+ if (pci_request_regions(pdev, DRV_MODULE_NAME)) {
+ if (request_irq(pdev-irq, scsi_esp_intr, IRQF_SHARED,
+ DRV_MODULE_NAME, esp)) {
Please propagate the return values from these two.
Otherwise looks good. Please resend with fixes for these and Dave's
style comment, and I'll apply it.
--
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 07/12] scsi: add 'am53c974' driver
On 11/24/2014 02:50 PM, Christoph Hellwig wrote:
+/*
+ * AMD am53c974 driver.
+ * Copyright (c) 2014 Hannes Reinecke, SUSE Linux GmbH
+ */
Is there anything left from the old driver that should get credit here?
Hmm. I copied the EEprom handling more-or-less verbatim from the
tmscsim driver; not sure if that warrants a credit.
+#define PCI_ESP_GET_PRIV(esp) ((struct pci_esp_priv *) \
+ pci_get_drvdata((struct pci_dev *) \
+ (esp)-dev))
I think an inline function would be a lot cleaner, especially as that
should avoid all these casts.
Ok.
+#ifdef ESP_DMA_DEBUG
+shost_printk(KERN_INFO, esp-host, start dma addr[%x] count[%d:%d]\n,
+ addr, esp_count, dma_count);
+#endif
Can you add a esp_dma_printk or similar instead of all these ifdefs?
Yep, I can.
+u8 carryFlag = 1, j = 0x80, bval;
carry_flag.
As said, copied verbatim. Will be fixing it up.
+if (pci_request_regions(pdev, DRV_MODULE_NAME)) {
+if (request_irq(pdev-irq, scsi_esp_intr, IRQF_SHARED,
+DRV_MODULE_NAME, esp)) {
Please propagate the return values from these two.
Ok.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, 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] bfa: switch to mid layer queue full tracking
As far as I can tell the queue tracking in the bfa driver is a copypaste
copy of the midlayer version, just without support to configure it through
sysfs.
Remove the bfa copy and rely on the mid layer version.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/bfa/bfad_im.c | 66 ++
drivers/scsi/bfa/bfad_im.h | 6 -
2 files changed, 2 insertions(+), 70 deletions(-)
diff --git a/drivers/scsi/bfa/bfad_im.c b/drivers/scsi/bfa/bfad_im.c
index 7223b00..ac55fd9 100644
--- a/drivers/scsi/bfa/bfad_im.c
+++ b/drivers/scsi/bfa/bfad_im.c
@@ -43,8 +43,6 @@ bfa_cb_ioim_done(void *drv, struct bfad_ioim_s *dio,
{
struct scsi_cmnd *cmnd = (struct scsi_cmnd *)dio;
struct bfad_s *bfad = drv;
- struct bfad_itnim_data_s *itnim_data;
- struct bfad_itnim_s *itnim;
u8 host_status = DID_OK;
switch (io_status) {
@@ -93,19 +91,6 @@ bfa_cb_ioim_done(void *drv, struct bfad_ioim_s *dio,
cmnd-host_scribble = NULL;
bfa_trc(bfad, cmnd-result);
- itnim_data = cmnd-device-hostdata;
- if (itnim_data) {
- itnim = itnim_data-itnim;
- if (!cmnd-result itnim
-(bfa_lun_queue_depth cmnd-device-queue_depth)) {
- /* Queue depth adjustment for good status completion */
- bfad_ramp_up_qdepth(itnim, cmnd-device);
- } else if (cmnd-result == SAM_STAT_TASK_SET_FULL itnim) {
- /* qfull handling */
- bfad_handle_qfull(itnim, cmnd-device);
- }
- }
-
cmnd-scsi_done(cmnd);
}
@@ -113,8 +98,6 @@ void
bfa_cb_ioim_good_comp(void *drv, struct bfad_ioim_s *dio)
{
struct scsi_cmnd *cmnd = (struct scsi_cmnd *)dio;
- struct bfad_itnim_data_s *itnim_data;
- struct bfad_itnim_s *itnim;
cmnd-result = ScsiResult(DID_OK, SCSI_STATUS_GOOD);
@@ -123,17 +106,6 @@ bfa_cb_ioim_good_comp(void *drv, struct bfad_ioim_s *dio)
scsi_dma_unmap(cmnd);
cmnd-host_scribble = NULL;
-
- /* Queue depth adjustment */
- if (bfa_lun_queue_depth cmnd-device-queue_depth) {
- itnim_data = cmnd-device-hostdata;
- if (itnim_data) {
- itnim = itnim_data-itnim;
- if (itnim)
- bfad_ramp_up_qdepth(itnim, cmnd-device);
- }
- }
-
cmnd-scsi_done(cmnd);
}
@@ -801,6 +773,7 @@ struct scsi_host_template bfad_im_scsi_host_template = {
.max_sectors = BFAD_MAX_SECTORS,
.vendor_id = BFA_PCI_VENDOR_ID_BROCADE,
.use_blk_tags = 1,
+ .track_queue_depth = 1,
};
struct scsi_host_template bfad_im_vport_template = {
@@ -823,6 +796,7 @@ struct scsi_host_template bfad_im_vport_template = {
.shost_attrs = bfad_im_vport_attrs,
.max_sectors = BFAD_MAX_SECTORS,
.use_blk_tags = 1,
+ .track_queue_depth = 1,
};
bfa_status_t
@@ -853,42 +827,6 @@ bfad_im_module_exit(void)
fc_release_transport(bfad_im_scsi_vport_transport_template);
}
-void
-bfad_ramp_up_qdepth(struct bfad_itnim_s *itnim, struct scsi_device *sdev)
-{
- struct scsi_device *tmp_sdev;
-
- if (((jiffies - itnim-last_ramp_up_time)
- BFA_QUEUE_FULL_RAMP_UP_TIME * HZ)
- ((jiffies - itnim-last_queue_full_time)
- BFA_QUEUE_FULL_RAMP_UP_TIME * HZ)) {
- shost_for_each_device(tmp_sdev, sdev-host) {
- if (bfa_lun_queue_depth tmp_sdev-queue_depth) {
- if (tmp_sdev-id != sdev-id)
- continue;
- scsi_change_queue_depth(tmp_sdev,
- tmp_sdev-queue_depth + 1);
-
- itnim-last_ramp_up_time = jiffies;
- }
- }
- }
-}
-
-void
-bfad_handle_qfull(struct bfad_itnim_s *itnim, struct scsi_device *sdev)
-{
- struct scsi_device *tmp_sdev;
-
- itnim-last_queue_full_time = jiffies;
-
- shost_for_each_device(tmp_sdev, sdev-host) {
- if (tmp_sdev-id != sdev-id)
- continue;
- scsi_track_queue_full(tmp_sdev, tmp_sdev-queue_depth - 1);
- }
-}
-
struct bfad_itnim_s *
bfad_get_itnim(struct bfad_im_port_s *im_port, int id)
{
diff --git a/drivers/scsi/bfa/bfad_im.h b/drivers/scsi/bfa/bfad_im.h
index f6c1023..7db2b75 100644
--- a/drivers/scsi/bfa/bfad_im.h
+++ b/drivers/scsi/bfa/bfad_im.h
@@ -44,7 +44,6 @@ u32 bfad_im_supported_speeds(struct bfa_s *bfa);
#define BFAD_TARGET_RESET_TMO 60
#define BFAD_LUN_RESET_TMO 60
#define ScsiResult(host_code, scsi_code) (((host_code) 16) | scsi_code)
-#define BFA_QUEUE_FULL_RAMP_UP_TIME 120
/*
* itnim flags
@@ -94,8 +93,6 @@ struct bfad_itnim_s {
u16
[PATCH 05/12] esp_scsi: read status registers
A read to ESP_INTRPT will clear ESP_STATUS and ESP_SSTEP. So read
all status registers in one go to avoid losing information.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Acked-by: David S. Miller da...@davemloft.net
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/esp_scsi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 3a5d81c..0ad0f08 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -982,7 +982,6 @@ static int esp_check_spur_intr(struct esp *esp)
default:
if (!(esp-sreg ESP_STAT_INTR)) {
- esp-ireg = esp_read8(ESP_INTRPT);
if (esp-ireg ESP_INTR_SR)
return 1;
@@ -2056,7 +2055,12 @@ static void __esp_interrupt(struct esp *esp)
int finish_reset, intr_done;
u8 phase;
+ /*
+ * Once INTRPT is read STATUS and SSTEP are cleared.
+ */
esp-sreg = esp_read8(ESP_STATUS);
+ esp-seqreg = esp_read8(ESP_SSTEP);
+ esp-ireg = esp_read8(ESP_INTRPT);
if (esp-flags ESP_FLAG_RESETTING) {
finish_reset = 1;
@@ -2069,8 +2073,6 @@ static void __esp_interrupt(struct esp *esp)
return;
}
- esp-ireg = esp_read8(ESP_INTRPT);
-
if (esp-ireg ESP_INTR_SR)
finish_reset = 1;
--
1.8.5.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
[PATCH 1/4] scsi: remove -change_queue_type method
Since we got rid of ordered tag support in 2010 the prime use case of
switching on and off ordered tags has been obsolete. The other function
of enabling/dsiabling tagging entirely has only been correctly implemented
by the 53c700 driver and isn't generally useful.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/infiniband/ulp/srp/ib_srp.c | 1 -
drivers/scsi/53c700.c| 35 ---
drivers/scsi/aic94xx/aic94xx_init.c | 1 -
drivers/scsi/bnx2fc/bnx2fc_fcoe.c| 1 -
drivers/scsi/esas2r/esas2r_main.c| 1 -
drivers/scsi/fcoe/fcoe.c | 1 -
drivers/scsi/fnic/fnic_main.c| 1 -
drivers/scsi/ibmvscsi/ibmvfc.c | 1 -
drivers/scsi/ipr.c | 25 -
drivers/scsi/isci/init.c | 1 -
drivers/scsi/libsas/sas_scsi_host.c | 8
drivers/scsi/lpfc/lpfc_scsi.c| 2 --
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 1 -
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1 -
drivers/scsi/mvsas/mv_init.c | 1 -
drivers/scsi/pm8001/pm8001_init.c| 1 -
drivers/scsi/pmcraid.c | 1 -
drivers/scsi/qla2xxx/qla_os.c| 1 -
drivers/scsi/scsi.c | 16
drivers/scsi/scsi_debug.c| 27 ---
drivers/scsi/scsi_sysfs.c| 30 --
drivers/target/loopback/tcm_loop.c | 1 -
include/scsi/libsas.h| 1 -
include/scsi/scsi_host.h | 13 -
include/scsi/scsi_tcq.h | 3 ---
25 files changed, 4 insertions(+), 171 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 5461924..a164036 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2740,7 +2740,6 @@ static struct scsi_host_template srp_template = {
.info = srp_target_info,
.queuecommand = srp_queuecommand,
.change_queue_depth = srp_change_queue_depth,
- .change_queue_type = scsi_change_queue_type,
.eh_abort_handler = srp_abort,
.eh_device_reset_handler= srp_reset_device,
.eh_host_reset_handler = srp_reset_host,
diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index aa915da..e722911 100644
--- a/drivers/scsi/53c700.c
+++ b/drivers/scsi/53c700.c
@@ -176,7 +176,6 @@ STATIC int NCR_700_slave_alloc(struct scsi_device *SDpnt);
STATIC int NCR_700_slave_configure(struct scsi_device *SDpnt);
STATIC void NCR_700_slave_destroy(struct scsi_device *SDpnt);
static int NCR_700_change_queue_depth(struct scsi_device *SDpnt, int depth);
-static int NCR_700_change_queue_type(struct scsi_device *SDpnt, int depth);
STATIC struct device_attribute *NCR_700_dev_attrs[];
@@ -326,7 +325,6 @@ NCR_700_detect(struct scsi_host_template *tpnt,
tpnt-slave_destroy = NCR_700_slave_destroy;
tpnt-slave_alloc = NCR_700_slave_alloc;
tpnt-change_queue_depth = NCR_700_change_queue_depth;
- tpnt-change_queue_type = NCR_700_change_queue_type;
tpnt-use_blk_tags = 1;
if(tpnt-name == NULL)
@@ -2082,39 +2080,6 @@ NCR_700_change_queue_depth(struct scsi_device *SDp, int
depth)
return scsi_change_queue_depth(SDp, depth);
}
-static int NCR_700_change_queue_type(struct scsi_device *SDp, int tag_type)
-{
- int change_tag = ((tag_type ==0 scsi_get_tag_type(SDp) != 0)
- || (tag_type != 0 scsi_get_tag_type(SDp) == 0));
- struct NCR_700_Host_Parameters *hostdata =
- (struct NCR_700_Host_Parameters *)SDp-host-hostdata[0];
-
- /* We have a global (per target) flag to track whether TCQ is
-* enabled, so we'll be turning it off for the entire target here.
-* our tag algorithm will fail if we mix tagged and untagged commands,
-* so quiesce the device before doing this */
- if (change_tag)
- scsi_target_quiesce(SDp-sdev_target);
-
- scsi_set_tag_type(SDp, tag_type);
- if (!tag_type) {
- /* shift back to the default unqueued number of commands
-* (the user can still raise this) */
- scsi_change_queue_depth(SDp, SDp-host-cmd_per_lun);
- hostdata-tag_negotiated = ~(1 sdev_id(SDp));
- } else {
- /* Here, we cleared the negotiation flag above, so this
-* will force the driver to renegotiate */
- scsi_change_queue_depth(SDp, SDp-queue_depth);
- if (change_tag)
- NCR_700_set_tag_neg_state(SDp,
NCR_700_START_TAG_NEGOTIATION);
- }
- if (change_tag)
- scsi_target_resume(SDp-sdev_target);
-
- return tag_type;
-}
-
static ssize_t
NCR_700_show_active_tags(struct device *dev, struct device_attribute *attr,
char *buf)
{
[PATCHv3 00/12] Re-implement am53c974 driver
Hi all, having found some issues with the current tmscsim driver I looked at the code and found is really awkward to clean up. Seeing that the am53c974 chip is actually based on the 'ESP' chip design I've re-implemented it based on the common esp_scsi routines. This new driver (cunningly named 'am53c974') provides all features found on the tmscsim driver, with the goal of obsoleting the old tmscsim driver. Tested with Tekram DC390 and qemu esp-scsi. Changes to v1: - Include suggestions from Paolo Bonzini - Remove the tmscsim driver - Update MAINTAINERS file Changes to v2: - Include review from David Miller - Include review from Christoph Hellwig - Add Reviewed-by/Acked-by tags where applicable Hannes Reinecke (11): esp_scsi: spellcheck 'driver' esp_scsi: make number of tags configurable esp_scsi: convert to dev_printk esp_scsi: debug event and command esp_scsi: read status registers esp_scsi: use FIFO for command submission scsi: add 'am53c974' driver am53c974: BLAST residual handling esp: correctly detect am53c974 esp: enable CONFIG2_FENAB for am53c974 Replace tmscsim by am53c974 Paolo Bonzini (1): esp_scsi: let DMA driver provide a config2 value MAINTAINERS |7 +- drivers/scsi/Kconfig|8 +- drivers/scsi/Makefile |2 +- drivers/scsi/am53c974.c | 586 +++ drivers/scsi/esp_scsi.c | 411 +--- drivers/scsi/esp_scsi.h | 22 +- drivers/scsi/tmscsim.c | 2626 --- drivers/scsi/tmscsim.h | 549 -- 8 files changed, 859 insertions(+), 3352 deletions(-) create mode 100644 drivers/scsi/am53c974.c delete mode 100644 drivers/scsi/tmscsim.c delete mode 100644 drivers/scsi/tmscsim.h -- 1.8.5.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
[PATCH 08/12] am53c974: BLAST residual handling
The am53c974 has an design issue where a single byte might be
left in the SCSI FIFO after a DMA transfer.
As the handling code is currently untested add a WARN_ON()
statement here.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Acked-by: David S. Miller da...@davemloft.net
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/am53c974.c | 6 ++
drivers/scsi/esp_scsi.c | 29 +
drivers/scsi/esp_scsi.h | 1 +
3 files changed, 36 insertions(+)
diff --git a/drivers/scsi/am53c974.c b/drivers/scsi/am53c974.c
index a16c9cf..a42e8db 100644
--- a/drivers/scsi/am53c974.c
+++ b/drivers/scsi/am53c974.c
@@ -200,6 +200,12 @@ static void pci_esp_dma_drain(struct esp *esp)
}
pci_esp_write8(esp, ESP_DMA_CMD_DIR | ESP_DMA_CMD_IDLE, ESP_DMA_CMD);
esp_dma_log(DMA blast done (%d tries, %d bytes left)\n, lim, resid);
+ /* BLAST residual handling is currently untested */
+ if (WARN_ON_ONCE(resid == 1)) {
+ struct esp_cmd_entry *ent = esp-active_cmd;
+
+ ent-flags |= ESP_CMD_FLAG_RESIDUAL;
+ }
}
static void pci_esp_dma_invalidate(struct esp *esp)
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 2a3277d..07b4d93 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -1334,6 +1334,35 @@ static int esp_data_bytes_sent(struct esp *esp, struct
esp_cmd_entry *ent,
bytes_sent = esp-data_dma_len;
bytes_sent -= ecount;
+ /*
+* The am53c974 has a DMA 'pecularity'. The doc states:
+* In some odd byte conditions, one residual byte will
+* be left in the SCSI FIFO, and the FIFO Flags will
+* never count to '0 '. When this happens, the residual
+* byte should be retrieved via PIO following completion
+* of the BLAST operation.
+*/
+ if (fifo_cnt == 1 ent-flags ESP_CMD_FLAG_RESIDUAL) {
+ size_t count = 1;
+ size_t offset = bytes_sent;
+ u8 bval = esp_read8(ESP_FDATA);
+
+ if (ent-flags ESP_CMD_FLAG_AUTOSENSE)
+ ent-sense_ptr[bytes_sent] = bval;
+ else {
+ struct esp_cmd_priv *p = ESP_CMD_PRIV(cmd);
+ u8 *ptr;
+
+ ptr = scsi_kmap_atomic_sg(p-cur_sg, p-u.num_sg,
+ offset, count);
+ if (likely(ptr)) {
+ *(ptr + offset) = bval;
+ scsi_kunmap_atomic_sg(ptr);
+ }
+ }
+ bytes_sent += fifo_cnt;
+ ent-flags = ~ESP_CMD_FLAG_RESIDUAL;
+ }
if (!(ent-flags ESP_CMD_FLAG_WRITE))
bytes_sent -= fifo_cnt;
diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
index 27dcaf8..5fa456c 100644
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -269,6 +269,7 @@ struct esp_cmd_entry {
#define ESP_CMD_FLAG_WRITE 0x01 /* DMA is a write */
#define ESP_CMD_FLAG_ABORT 0x02 /* being aborted */
#define ESP_CMD_FLAG_AUTOSENSE 0x04 /* Doing automatic REQUEST_SENSE */
+#define ESP_CMD_FLAG_RESIDUAL 0x08 /* AM53c974 BLAST residual */
u8 tag[2];
u8 orig_tag[2];
--
1.8.5.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
[PATCH 04/12] esp_scsi: debug event and command
Add new debug definitions for event and command logging.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Acked-by: David S. Miller da...@davemloft.net
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/esp_scsi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 10a3d17..3a5d81c 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -49,6 +49,8 @@ static u32 esp_debug;
#define ESP_DEBUG_DATADONE 0x0100
#define ESP_DEBUG_RECONNECT0x0200
#define ESP_DEBUG_AUTOSENSE0x0400
+#define ESP_DEBUG_EVENT0x0800
+#define ESP_DEBUG_COMMAND 0x1000
#define esp_log_intr(f, a...) \
do { if (esp_debug ESP_DEBUG_INTR) \
@@ -100,6 +102,16 @@ do { if (esp_debug ESP_DEBUG_AUTOSENSE) \
shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
+#define esp_log_event(f, a...) \
+do { if (esp_debug ESP_DEBUG_EVENT)\
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
+} while (0)
+
+#define esp_log_command(f, a...) \
+do { if (esp_debug ESP_DEBUG_COMMAND) \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
+} while (0)
+
#define esp_read8(REG) esp-ops-esp_read8(esp, REG)
#define esp_write8(VAL,REG)esp-ops-esp_write8(esp, VAL, REG)
@@ -126,6 +138,7 @@ void scsi_esp_cmd(struct esp *esp, u8 val)
esp-esp_event_cur = (idx + 1) (ESP_EVENT_LOG_SZ - 1);
+ esp_log_command(cmd[%02x]\n, val);
esp_write8(val, ESP_CMD);
}
EXPORT_SYMBOL(scsi_esp_cmd);
@@ -1638,6 +1651,8 @@ static int esp_process_event(struct esp *esp)
again:
write = 0;
+ esp_log_event(process event %d phase %x\n,
+ esp-event, esp-sreg ESP_STAT_PMASK);
switch (esp-event) {
case ESP_EVENT_CHECK_PHASE:
switch (esp-sreg ESP_STAT_PMASK) {
--
1.8.5.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
[PATCH 3/4] scsi: remove scsi_get_tag_type
Both remaining users are better of just checking sdev-simple_tags
directly.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/53c700.c | 4 ++--
drivers/scsi/ipr.c | 2 +-
include/scsi/scsi_tcq.h | 13 -
3 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index e722911..2c87a7a 100644
--- a/drivers/scsi/53c700.c
+++ b/drivers/scsi/53c700.c
@@ -1816,8 +1816,8 @@ NCR_700_queuecommand_lck(struct scsi_cmnd *SCp, void
(*done)(struct scsi_cmnd *)
hostdata-tag_negotiated = ~(1scmd_id(SCp));
}
- if((hostdata-tag_negotiated (1scmd_id(SCp)))
- scsi_get_tag_type(SCp-device)) {
+ if ((hostdata-tag_negotiated (1scmd_id(SCp)))
+ SCp-device-simple_tags) {
slot-tag = SCp-request-tag;
CDEBUG(KERN_DEBUG, SCp, sending out tag %d, slot %p\n,
slot-tag, slot);
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index c35ef5f..c91c7c5 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -5755,7 +5755,7 @@ static void ipr_erp_cancel_all(struct ipr_cmnd *ipr_cmd)
ipr_reinit_ipr_cmnd_for_erp(ipr_cmd);
- if (!scsi_get_tag_type(scsi_cmd-device)) {
+ if (!scsi_cmd-device-simple_tags) {
ipr_erp_request_sense(ipr_cmd);
return;
}
diff --git a/include/scsi/scsi_tcq.h b/include/scsi/scsi_tcq.h
index 59578be..681e010 100644
--- a/include/scsi/scsi_tcq.h
+++ b/include/scsi/scsi_tcq.h
@@ -15,19 +15,6 @@
#ifdef CONFIG_BLOCK
-/**
- * scsi_get_tag_type - get the type of tag the device supports
- * @sdev: the scsi device
- */
-static inline int scsi_get_tag_type(struct scsi_device *sdev)
-{
- if (!sdev-tagged_supported)
- return 0;
- if (sdev-simple_tags)
- return MSG_SIMPLE_TAG;
- return 0;
-}
-
static inline void scsi_set_tag_type(struct scsi_device *sdev, int tag)
{
switch (tag) {
--
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
[PATCH 10/12] esp_scsi: let DMA driver provide a config2 value
From: Paolo Bonzini pbonz...@redhat.com
On PCscsi, the FENAB configuration also enables 24-bit DMA
transfer lengths (and provides the chip id in TCHI after reset).
We want to be able to enable this parameter from the DMA driver.
Check if the caller of scsi_esp_register provided a value for esp-config2.
If this is the case, assume this is not an ESP100, skip the detection
phase and leave esp-config2 untouched. It will be used in esp_reset_esp.
Reviewed-by: Hannes Reinecke h...@suse.de
Acked-by: David S. Miller da...@davemloft.net
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/scsi/esp_scsi.c | 70 ++---
1 file changed, 37 insertions(+), 33 deletions(-)
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 8a162be..cfbae52 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2219,46 +2219,50 @@ static void esp_get_revision(struct esp *esp)
u8 val;
esp-config1 = (ESP_CONFIG1_PENABLE | (esp-scsi_id 7));
- esp-config2 = (ESP_CONFIG2_SCSI2ENAB | ESP_CONFIG2_REGPARITY);
+ if (esp-config2 == 0) {
+ esp-config2 = (ESP_CONFIG2_SCSI2ENAB | ESP_CONFIG2_REGPARITY);
+ esp_write8(esp-config2, ESP_CFG2);
+
+ val = esp_read8(ESP_CFG2);
+ val = ~ESP_CONFIG2_MAGIC;
+
+ esp-config2 = 0;
+ if (val != (ESP_CONFIG2_SCSI2ENAB | ESP_CONFIG2_REGPARITY)) {
+ /*
+* If what we write to cfg2 does not come back,
+* cfg2 is not implemented.
+* Therefore this must be a plain esp100.
+*/
+ esp-rev = ESP100;
+ return;
+ }
+ }
+
+ esp_set_all_config3(esp, 5);
+ esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
+ esp_write8(0, ESP_CFG3);
+ esp_write8(esp-prev_cfg3, ESP_CFG3);
- val = esp_read8(ESP_CFG2);
- val = ~ESP_CONFIG2_MAGIC;
- if (val != (ESP_CONFIG2_SCSI2ENAB | ESP_CONFIG2_REGPARITY)) {
- /* If what we write to cfg2 does not come back, cfg2 is not
-* implemented, therefore this must be a plain esp100.
+ val = esp_read8(ESP_CFG3);
+ if (val != 5) {
+ /* The cfg2 register is implemented, however
+* cfg3 is not, must be esp100a.
*/
- esp-rev = ESP100;
+ esp-rev = ESP100A;
} else {
- esp-config2 = 0;
- esp_set_all_config3(esp, 5);
- esp-prev_cfg3 = 5;
- esp_write8(esp-config2, ESP_CFG2);
- esp_write8(0, ESP_CFG3);
+ esp_set_all_config3(esp, 0);
+ esp-prev_cfg3 = 0;
esp_write8(esp-prev_cfg3, ESP_CFG3);
- val = esp_read8(ESP_CFG3);
- if (val != 5) {
- /* The cfg2 register is implemented, however
-* cfg3 is not, must be esp100a.
-*/
- esp-rev = ESP100A;
+ /* All of cfg{1,2,3} implemented, must be one of
+* the fas variants, figure out which one.
+*/
+ if (esp-cfact == 0 || esp-cfact ESP_CCF_F5) {
+ esp-rev = FAST;
+ esp-sync_defp = SYNC_DEFP_FAST;
} else {
- esp_set_all_config3(esp, 0);
- esp-prev_cfg3 = 0;
- esp_write8(esp-prev_cfg3, ESP_CFG3);
-
- /* All of cfg{1,2,3} implemented, must be one of
-* the fas variants, figure out which one.
-*/
- if (esp-cfact == 0 || esp-cfact ESP_CCF_F5) {
- esp-rev = FAST;
- esp-sync_defp = SYNC_DEFP_FAST;
- } else {
- esp-rev = ESP236;
- }
- esp-config2 = 0;
- esp_write8(esp-config2, ESP_CFG2);
+ esp-rev = ESP236;
}
}
}
--
1.8.5.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
[PATCH 09/12] esp: correctly detect am53c974
The am53c974 returns the same ID as the FAS236, but implements
things slightly differently. So detect the am53c974 by checking
for ESP_CONFIG4 register.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/am53c974.c | 2 ++
drivers/scsi/esp_scsi.c | 17 -
drivers/scsi/esp_scsi.h | 15 +++
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/am53c974.c b/drivers/scsi/am53c974.c
index a42e8db..6e88e38 100644
--- a/drivers/scsi/am53c974.c
+++ b/drivers/scsi/am53c974.c
@@ -368,6 +368,8 @@ static void dc390_check_eeprom(struct esp *esp)
}
esp-scsi_id = EEbuf[DC390_EE_ADAPT_SCSI_ID];
esp-num_tags = 2 EEbuf[DC390_EE_TAG_CMD_NUM];
+ if (EEbuf[DC390_EE_MODE2] DC390_EE_MODE2_ACTIVE_NEGATION)
+ esp-config4 |= ESP_CONFIG4_RADE | ESP_CONFIG4_RAE;
}
static int pci_esp_probe_one(struct pci_dev *pdev,
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 07b4d93..8a162be 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -268,6 +268,19 @@ static void esp_reset_esp(struct esp *esp)
} else {
esp-min_period = ((5 * esp-ccycle) / 1000);
}
+ if (esp-rev == FAS236) {
+ /*
+* The AM53c974 chip returns the same ID as FAS236;
+* try to configure glitch eater.
+*/
+ u8 config4 = ESP_CONFIG4_GE1;
+ esp_write8(config4, ESP_CFG4);
+ config4 = esp_read8(ESP_CFG4);
+ if (config4 ESP_CONFIG4_GE1) {
+ esp-rev = PCSCSI;
+ esp_write8(esp-config4, ESP_CFG4);
+ }
+ }
esp-max_period = (esp-max_period + 3)2;
esp-min_period = (esp-min_period + 3)2;
@@ -293,7 +306,8 @@ static void esp_reset_esp(struct esp *esp)
/* fallthrough... */
case FAS236:
- /* Fast 236 or HME */
+ case PCSCSI:
+ /* Fast 236, AM53c974 or HME */
esp_write8(esp-config2, ESP_CFG2);
if (esp-rev == FASHME) {
u8 cfg3 = esp-target[0].esp_config3;
@@ -2364,6 +2378,7 @@ static const char *esp_chip_names[] = {
FAS100A,
FAST,
FASHME,
+ AM53C974,
};
static struct scsi_transport_template *esp_transport_template;
diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
index 5fa456c..84dcbe4 100644
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -25,6 +25,7 @@
#define ESP_CTEST 0x0aUL /* wo Chip test register 0x28 */
#define ESP_CFG2 0x0bUL /* rw Second cfg register 0x2c */
#define ESP_CFG3 0x0cUL /* rw Third cfg register 0x30 */
+#define ESP_CFG4 0x0dUL /* rw Fourth cfg register 0x34 */
#define ESP_TCHI 0x0eUL /* rw High bits transf count 0x38 */
#define ESP_UIDESP_TCHI/* ro Unique ID code
0x38 */
#define FAS_RLOESP_TCHI/* rw HME extended counter
0x38 */
@@ -76,6 +77,18 @@
#define ESP_CONFIG3_IMS 0x80 /* ID msg chk'ng(esp/fas236) */
#define ESP_CONFIG3_OBPUSH0x80 /* Push odd-byte to dma (hme) */
+/* ESP config register 4 read-write, found only on am53c974 chips */
+#define ESP_CONFIG4_RADE 0x04 /* Active negation */
+#define ESP_CONFIG4_RAE 0x08 /* Active negation on REQ and ACK */
+#define ESP_CONFIG4_PWD 0x20 /* Reduced power feature */
+#define ESP_CONFIG4_GE0 0x40 /* Glitch eater bit 0 */
+#define ESP_CONFIG4_GE1 0x80 /* Glitch eater bit 1 */
+
+#define ESP_CONFIG_GE_12NS(0)
+#define ESP_CONFIG_GE_25NS(ESP_CONFIG_GE1)
+#define ESP_CONFIG_GE_35NS(ESP_CONFIG_GE0)
+#define ESP_CONFIG_GE_0NS (ESP_CONFIG_GE0 | ESP_CONFIG_GE1)
+
/* ESP command register read-write */
/* Group 1 commands: These may be sent at any point in time to the ESP
*chip. None of them can generate interrupts 'cept
@@ -254,6 +267,7 @@ enum esp_rev {
FAS100A= 0x04,
FAST = 0x05,
FASHME = 0x06,
+ PCSCSI = 0x07, /* AM53c974 */
};
struct esp_cmd_entry {
@@ -466,6 +480,7 @@ struct esp {
u8 bursts;
u8 config1;
u8 config2;
+ u8 config4;
u8 scsi_id;
u32 scsi_id_mask;
--
1.8.5.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
[PATCH 03/12] esp_scsi: convert to dev_printk
Use dev_printk functions for correct device annotations.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Acked-by: David S. Miller da...@davemloft.net
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/esp_scsi.c | 212
1 file changed, 106 insertions(+), 106 deletions(-)
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index a2e7868..10a3d17 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -52,52 +52,52 @@ static u32 esp_debug;
#define esp_log_intr(f, a...) \
do { if (esp_debug ESP_DEBUG_INTR) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_log_reset(f, a...) \
do { if (esp_debug ESP_DEBUG_RESET) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_log_msgin(f, a...) \
do { if (esp_debug ESP_DEBUG_MSGIN) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_log_msgout(f, a...) \
do { if (esp_debug ESP_DEBUG_MSGOUT) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_log_cmddone(f, a...) \
do { if (esp_debug ESP_DEBUG_CMDDONE) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_log_disconnect(f, a...) \
do { if (esp_debug ESP_DEBUG_DISCONNECT) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_log_datastart(f, a...) \
do { if (esp_debug ESP_DEBUG_DATASTART) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_log_datadone(f, a...) \
do { if (esp_debug ESP_DEBUG_DATADONE) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_log_reconnect(f, a...) \
do { if (esp_debug ESP_DEBUG_RECONNECT) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_log_autosense(f, a...) \
do { if (esp_debug ESP_DEBUG_AUTOSENSE) \
- printk(f, ## a); \
+ shost_printk(KERN_DEBUG, esp-host, f, ## a); \
} while (0)
#define esp_read8(REG) esp-ops-esp_read8(esp, REG)
@@ -150,19 +150,17 @@ static void esp_dump_cmd_log(struct esp *esp)
int idx = esp-esp_event_cur;
int stop = idx;
- printk(KERN_INFO PFX esp%d: Dumping command log\n,
- esp-host-unique_id);
+ shost_printk(KERN_INFO, esp-host, Dumping command log\n);
do {
struct esp_event_ent *p = esp-esp_event_log[idx];
- printk(KERN_INFO PFX esp%d: ent[%d] %s ,
- esp-host-unique_id, idx,
- p-type == ESP_EVENT_TYPE_CMD ? CMD : EVENT);
-
- printk(val[%02x] sreg[%02x] seqreg[%02x]
- sreg2[%02x] ireg[%02x] ss[%02x] event[%02x]\n,
- p-val, p-sreg, p-seqreg,
- p-sreg2, p-ireg, p-select_state, p-event);
+ shost_printk(KERN_INFO, esp-host,
+ent[%d] %s val[%02x] sreg[%02x] seqreg[%02x]
+sreg2[%02x] ireg[%02x] ss[%02x] event[%02x]\n,
+idx,
+p-type == ESP_EVENT_TYPE_CMD ? CMD : EVENT,
+p-val, p-sreg, p-seqreg,
+p-sreg2, p-ireg, p-select_state, p-event);
idx = (idx + 1) (ESP_EVENT_LOG_SZ - 1);
} while (idx != stop);
@@ -176,9 +174,8 @@ static void esp_flush_fifo(struct esp *esp)
while (esp_read8(ESP_FFLAGS) ESP_FF_FBYTES) {
if (--lim == 0) {
- printk(KERN_ALERT PFX esp%d: ESP_FF_BYTES
- will not clear!\n,
- esp-host-unique_id);
+ shost_printk(KERN_ALERT, esp-host,
+ESP_FF_BYTES will not clear!\n);
break;
}
udelay(1);
@@ -383,12 +380,11 @@ static void esp_advance_dma(struct esp *esp, struct
esp_cmd_entry *ent,
p-cur_residue -= len;
p-tot_residue -= len;
if (p-cur_residue 0 || p-tot_residue 0) {
- printk(KERN_ERR PFX esp%d: Data transfer overflow.\n,
- esp-host-unique_id);
- printk(KERN_ERR PFX esp%d: cur_residue[%d] tot_residue[%d]
- len[%u]\n,
- esp-host-unique_id,
- p-cur_residue, p-tot_residue,
[PATCH 06/12] esp_scsi: use FIFO for command submission
Using DMA for command submission has the drawback that it might
generate additional DMA completion interrupts after the command
has been submitted to the device.
Additionally the am53c974 has a design flaw causing it
to generate spurious interrupts even though DMA completion
interrupts are not enabled.
This can be avoided by using the FIFO for command submission.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Acked-by: David S. Miller da...@davemloft.net
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/esp_scsi.c | 46 +-
drivers/scsi/esp_scsi.h | 1 +
2 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 0ad0f08..2a3277d 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -143,6 +143,24 @@ void scsi_esp_cmd(struct esp *esp, u8 val)
}
EXPORT_SYMBOL(scsi_esp_cmd);
+static void esp_send_dma_cmd(struct esp *esp, int len, int max_len, int cmd)
+{
+ if (esp-flags ESP_FLAG_USE_FIFO) {
+ int i;
+
+ scsi_esp_cmd(esp, ESP_CMD_FLUSH);
+ for (i = 0; i len; i++)
+ esp_write8(esp-command_block[i], ESP_FDATA);
+ scsi_esp_cmd(esp, cmd);
+ } else {
+ if (esp-rev == FASHME)
+ scsi_esp_cmd(esp, ESP_CMD_FLUSH);
+ cmd |= ESP_CMD_DMA;
+ esp-ops-send_dma_cmd(esp, esp-command_block_dma,
+ len, max_len, 0, cmd);
+ }
+}
+
static void esp_event(struct esp *esp, u8 val)
{
struct esp_event_ent *p;
@@ -650,10 +668,7 @@ static void esp_autosense(struct esp *esp, struct
esp_cmd_entry *ent)
val = (p - esp-command_block);
- if (esp-rev == FASHME)
- scsi_esp_cmd(esp, ESP_CMD_FLUSH);
- esp-ops-send_dma_cmd(esp, esp-command_block_dma,
- val, 16, 0, ESP_CMD_DMA | ESP_CMD_SELA);
+ esp_send_dma_cmd(esp, val, 16, ESP_CMD_SELA);
}
static struct esp_cmd_entry *find_and_prep_issuable_command(struct esp *esp)
@@ -789,12 +804,12 @@ build_identify:
}
if (!(esp-flags ESP_FLAG_DOING_SLOWCMD)) {
- start_cmd = ESP_CMD_DMA | ESP_CMD_SELA;
+ start_cmd = ESP_CMD_SELA;
if (ent-tag[0]) {
*p++ = ent-tag[0];
*p++ = ent-tag[1];
- start_cmd = ESP_CMD_DMA | ESP_CMD_SA3;
+ start_cmd = ESP_CMD_SA3;
}
for (i = 0; i cmd-cmd_len; i++)
@@ -814,7 +829,7 @@ build_identify:
esp-msg_out_len += 2;
}
- start_cmd = ESP_CMD_DMA | ESP_CMD_SELAS;
+ start_cmd = ESP_CMD_SELAS;
esp-select_state = ESP_SELECT_MSGOUT;
}
val = tgt;
@@ -834,10 +849,7 @@ build_identify:
printk(]\n);
}
- if (esp-rev == FASHME)
- scsi_esp_cmd(esp, ESP_CMD_FLUSH);
- esp-ops-send_dma_cmd(esp, esp-command_block_dma,
- val, 16, 0, start_cmd);
+ esp_send_dma_cmd(esp, val, 16, start_cmd);
}
static struct esp_cmd_entry *esp_get_ent(struct esp *esp)
@@ -1646,7 +1658,7 @@ static int esp_msgin_process(struct esp *esp)
static int esp_process_event(struct esp *esp)
{
- int write;
+ int write, i;
again:
write = 0;
@@ -1872,6 +1884,10 @@ again:
if (esp-msg_out_len == 1) {
esp_write8(esp-msg_out[0], ESP_FDATA);
scsi_esp_cmd(esp, ESP_CMD_TI);
+ } else if (esp-flags ESP_FLAG_USE_FIFO) {
+ for (i = 0; i esp-msg_out_len; i++)
+ esp_write8(esp-msg_out[i], ESP_FDATA);
+ scsi_esp_cmd(esp, ESP_CMD_TI);
} else {
/* Use DMA. */
memcpy(esp-command_block,
@@ -1949,11 +1965,7 @@ again:
case ESP_EVENT_CMD_START:
memcpy(esp-command_block, esp-cmd_bytes_ptr,
esp-cmd_bytes_left);
- if (esp-rev == FASHME)
- scsi_esp_cmd(esp, ESP_CMD_FLUSH);
- esp-ops-send_dma_cmd(esp, esp-command_block_dma,
- esp-cmd_bytes_left, 16, 0,
- ESP_CMD_DMA | ESP_CMD_TI);
+ esp_send_dma_cmd(esp, esp-cmd_bytes_left, 16, ESP_CMD_TI);
esp_event(esp, ESP_EVENT_CMD_DONE);
esp-flags |= ESP_FLAG_QUICKIRQ_CHECK;
break;
diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
index 975d293..27dcaf8 100644
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -478,6 +478,7 @@ struct esp {
#define
[PATCH 02/12] esp_scsi: make number of tags configurable
Add a field 'num_tags' to the esp structure to allow drivers
to overwrite the number of avialable tags if required.
Default is ESP_DEFAULT_TAGS.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Acked-by: David S. Miller da...@davemloft.net
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/esp_scsi.c | 12 ++--
drivers/scsi/esp_scsi.h | 3 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 38c23e0..a2e7868 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2317,6 +2317,10 @@ int scsi_esp_register(struct esp *esp, struct device
*dev)
static int instance;
int err;
+ if (!esp-num_tags)
+ esp-num_tags = ESP_DEFAULT_TAGS;
+ else if (esp-num_tags = ESP_MAX_TAG)
+ esp-num_tags = ESP_MAX_TAG - 1;
esp-host-transportt = esp_transport_template;
esp-host-max_lun = ESP_MAX_LUN;
esp-host-cmd_per_lun = 2;
@@ -2403,12 +2407,8 @@ static int esp_slave_configure(struct scsi_device *dev)
struct esp *esp = shost_priv(dev-host);
struct esp_target_data *tp = esp-target[dev-id];
- if (dev-tagged_supported) {
- /* XXX make this configurable somehow XXX */
- int goal_tags = min(ESP_DEFAULT_TAGS, ESP_MAX_TAG);
-
- scsi_adjust_queue_depth(dev, goal_tags);
- }
+ if (dev-tagged_supported)
+ scsi_adjust_queue_depth(dev, esp-num_tags);
tp-flags |= ESP_TGT_DISCONNECT;
diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
index b5862e4..975d293 100644
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -283,7 +283,6 @@ struct esp_cmd_entry {
struct completion *eh_done;
};
-/* XXX make this configurable somehow XXX */
#define ESP_DEFAULT_TAGS 16
#define ESP_MAX_TARGET 16
@@ -445,7 +444,7 @@ struct esp {
u8 prev_soff;
u8 prev_stp;
u8 prev_cfg3;
- u8 __pad;
+ u8 num_tags;
struct list_headesp_cmd_pool;
--
1.8.5.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
[PATCH 4/4] scsi: remove scsi_set_tag_type
There is no benefit over just setting sdev-simple_tags directly.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/53c700.c | 2 +-
drivers/scsi/tmscsim.c | 2 +-
include/scsi/scsi_tcq.h | 15 ---
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index 2c87a7a..82abfce 100644
--- a/drivers/scsi/53c700.c
+++ b/drivers/scsi/53c700.c
@@ -902,8 +902,8 @@ process_message(struct Scsi_Host *host, struct
NCR_700_Host_Parameters *hostdata
hostdata-tag_negotiated = ~(1scmd_id(SCp));
SCp-device-tagged_supported = 0;
+ SCp-device-simple_tags = 0;
scsi_change_queue_depth(SCp-device, host-cmd_per_lun);
- scsi_set_tag_type(SCp-device, 0);
} else {
shost_printk(KERN_WARNING, host,
(%d:%d) Unexpected REJECT Message %s\n,
diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c
index 6c3c2ce..14ccc9a 100644
--- a/drivers/scsi/tmscsim.c
+++ b/drivers/scsi/tmscsim.c
@@ -2190,7 +2190,7 @@ static int dc390_slave_configure(struct scsi_device *sdev)
* XXX: Note that while this driver used to called scsi_activate_tcq,
* it never actually set a tag type, so emulate the old behavior.
*/
- scsi_set_tag_type(sdev, 0);
+ sdev-simple_tags = 0;
if (sdev-tagged_supported (dcb-DevMode TAG_QUEUEING_)) {
dcb-SyncMode |= EN_TAG_QUEUEING;
diff --git a/include/scsi/scsi_tcq.h b/include/scsi/scsi_tcq.h
index 681e010..e624aca 100644
--- a/include/scsi/scsi_tcq.h
+++ b/include/scsi/scsi_tcq.h
@@ -15,21 +15,6 @@
#ifdef CONFIG_BLOCK
-static inline void scsi_set_tag_type(struct scsi_device *sdev, int tag)
-{
- switch (tag) {
- case MSG_ORDERED_TAG:
- case MSG_SIMPLE_TAG:
- sdev-simple_tags = 1;
- break;
- case 0:
- /* fall through */
- default:
- sdev-simple_tags = 0;
- break;
- }
-}
-
static inline struct scsi_cmnd *scsi_mq_find_tag(struct Scsi_Host *shost,
int unique_tag)
{
--
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
[PATCH 2/4] scsi: never drop to untagged mode during queue ramp down
Dropping to untagged mode when ramping down a queue due to QUEUE FULL
events has two problems:
- nothing in the midlayer or drivers ever moves back to tagged mode
during queue ramp up.
- cmd_per_lun isn't the untagged queue depth for many modern drivers
that can handle multiple untagged commands, and this is the only
place in the midlayer assuming that.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/scsi.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 72282ae..6b0d524 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -820,12 +820,6 @@ int scsi_track_queue_full(struct scsi_device *sdev, int
depth)
if (sdev-last_queue_full_count = 10)
return 0;
- if (sdev-last_queue_full_depth 8) {
- /* Drop back to untagged */
- scsi_set_tag_type(sdev, 0);
- scsi_change_queue_depth(sdev, sdev-host-cmd_per_lun);
- return -1;
- }
return scsi_change_queue_depth(sdev, depth);
}
--
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
queue_type fixups
These are a few patches that follow up my previous cleanups for the queue depth and type handling. The first patch removes the now pointless write support for the queue_type sysfs attribute. The second changes the queue full tracking code to never drop out of tagged mode, as we can't recover from that, and the last two are random cleanups. -- 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 11/12] esp: enable CONFIG2_FENAB for am53c974
CONFIG2_FENAB ('feature enable') changed definition between chip
revisions, from 'Latch SCSI Phase' to 'Latch SCSI Phase, display
chip ID upon reset, and enable 24 bit addresses'.
So only enable it for am53c974 where we know what it's doing.
Acked-by: David S. Miller da...@davemloft.net
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/am53c974.c | 40
drivers/scsi/esp_scsi.c | 2 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/scsi/am53c974.c b/drivers/scsi/am53c974.c
index 6e88e38..25f0619 100644
--- a/drivers/scsi/am53c974.c
+++ b/drivers/scsi/am53c974.c
@@ -18,6 +18,7 @@
#define DRV_MODULE_VERSION 1.00
static bool am53c974_debug;
+static bool am53c974_fenab = true;
#define esp_dma_log(f, a...) \
do {\
@@ -256,6 +257,8 @@ static void pci_esp_send_dma_cmd(struct esp *esp, u32 addr,
u32 esp_count,
pci_esp_write8(esp, (esp_count 0) 0xff, ESP_TCLOW);
pci_esp_write8(esp, (esp_count 8) 0xff, ESP_TCMED);
+ if (esp-config2 ESP_CONFIG2_FENAB)
+ pci_esp_write8(esp, (esp_count 16) 0xff, ESP_TCHI);
pci_esp_write32(esp, esp_count, ESP_DMA_STC);
pci_esp_write32(esp, addr, ESP_DMA_SPA);
@@ -268,6 +271,33 @@ static void pci_esp_send_dma_cmd(struct esp *esp, u32
addr, u32 esp_count,
pci_esp_write8(esp, ESP_DMA_CMD_START | val, ESP_DMA_CMD);
}
+static u32 pci_esp_dma_length_limit(struct esp *esp, u32 dma_addr, u32 dma_len)
+{
+ int dma_limit = 16;
+ u32 base, end;
+
+ /*
+* If CONFIG2_FENAB is set we can
+* handle up to 24 bit addresses
+*/
+ if (esp-config2 ESP_CONFIG2_FENAB)
+ dma_limit = 24;
+
+ if (dma_len (1U dma_limit))
+ dma_len = (1U dma_limit);
+
+ /*
+* Prevent crossing a 24-bit address boundary.
+*/
+ base = dma_addr ((1U 24) - 1U);
+ end = base + dma_len;
+ if (end (1U 24))
+ end = (1U 24);
+ dma_len = end - base;
+
+ return dma_len;
+}
+
static const struct esp_driver_ops pci_esp_ops = {
.esp_write8 = pci_esp_write8,
.esp_read8 = pci_esp_read8,
@@ -281,6 +311,7 @@ static const struct esp_driver_ops pci_esp_ops = {
.dma_invalidate = pci_esp_dma_invalidate,
.send_dma_cmd = pci_esp_send_dma_cmd,
.dma_error = pci_esp_dma_error,
+ .dma_length_limit = pci_esp_dma_length_limit,
};
/*
@@ -418,6 +449,12 @@ static int pci_esp_probe_one(struct pci_dev *pdev,
* DMA for command submission.
*/
esp-flags |= ESP_FLAG_USE_FIFO;
+ /*
+* Enable CONFIG2_FENAB to allow for large DMA transfers
+*/
+ if (am53c974_fenab)
+ esp-config2 |= ESP_CONFIG2_FENAB;
+
pep-esp = esp;
if (pci_request_regions(pdev, DRV_MODULE_NAME)) {
@@ -541,5 +578,8 @@ MODULE_VERSION(DRV_MODULE_VERSION);
module_param(am53c974_debug, bool, 0644);
MODULE_PARM_DESC(am53c974_debug, Enable debugging);
+module_param(am53c974_fenab, bool, 0444);
+MODULE_PARM_DESC(am53c974_fenab, Enable 24-bit DMA transfer sizes);
+
module_init(am53c974_module_init);
module_exit(am53c974_module_exit);
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index cfbae52..dc120f9 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -1343,6 +1343,8 @@ static int esp_data_bytes_sent(struct esp *esp, struct
esp_cmd_entry *ent,
(((unsigned int)esp_read8(ESP_TCMED)) 8));
if (esp-rev == FASHME)
ecount |= ((unsigned int)esp_read8(FAS_RLO)) 16;
+ if (esp-rev == PCSCSI (esp-config2 ESP_CONFIG2_FENAB))
+ ecount |= ((unsigned int)esp_read8(ESP_TCHI)) 16;
}
bytes_sent = esp-data_dma_len;
--
1.8.5.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
[PATCH 07/12] scsi: add 'am53c974' driver
This patch adds a new implementation for the Tekram DC-390T /
AMD AM53c974 SCSI controller, based on the generic
esp_scsi infrastructure.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/Kconfig| 18 ++
drivers/scsi/Makefile | 1 +
drivers/scsi/am53c974.c | 537
3 files changed, 556 insertions(+)
create mode 100644 drivers/scsi/am53c974.c
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 60c67e1..519c3ef 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1357,6 +1357,24 @@ config SCSI_DC390T
To compile this driver as a module, choose M here: the
module will be called tmscsim.
+config SCSI_AM53C974
+ tristate Tekram DC390(T) and Am53/79C974 SCSI support (new driver)
+ depends on PCI SCSI
+ select SCSI_SPI_ATTRS
+ ---help---
+ This driver supports PCI SCSI host adapters based on the Am53C974A
+ chip, e.g. Tekram DC390(T), DawiControl 2974 and some onboard
+ PCscsi/PCnet (Am53/79C974) solutions.
+ This is a new implementation base on the generic esp_scsi driver.
+
+ Documentation can be found in file:Documentation/scsi/tmscsim.txt.
+
+ Note that this driver does NOT support Tekram DC390W/U/F, which are
+ based on NCR/Symbios chips. Use NCR53C8XX SCSI support for those.
+
+ To compile this driver as a module, choose M here: the
+ module will be called am53c974.
+
config SCSI_T128
tristate Trantor T128/T128F/T228 SCSI support
depends on ISA SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 59f1ce6..79a6571 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_SCSI_7000FASST)+= wd7000.o
obj-$(CONFIG_SCSI_EATA)+= eata.o
obj-$(CONFIG_SCSI_DC395x) += dc395x.o
obj-$(CONFIG_SCSI_DC390T) += tmscsim.o
+obj-$(CONFIG_SCSI_AM53C974)+= esp_scsi.o am53c974.o
obj-$(CONFIG_MEGARAID_LEGACY) += megaraid.o
obj-$(CONFIG_MEGARAID_NEWGEN) += megaraid/
obj-$(CONFIG_MEGARAID_SAS) += megaraid/
diff --git a/drivers/scsi/am53c974.c b/drivers/scsi/am53c974.c
new file mode 100644
index 000..a16c9cf
--- /dev/null
+++ b/drivers/scsi/am53c974.c
@@ -0,0 +1,537 @@
+/*
+ * AMD am53c974 driver.
+ * Copyright (c) 2014 Hannes Reinecke, SUSE Linux GmbH
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pci.h
+#include linux/interrupt.h
+
+#include scsi/scsi_host.h
+
+#include esp_scsi.h
+
+#define DRV_MODULE_NAME am53c974
+#define DRV_MODULE_VERSION 1.00
+
+static bool am53c974_debug;
+
+#define esp_dma_log(f, a...) \
+ do {\
+ if (am53c974_debug) \
+ shost_printk(KERN_DEBUG, esp-host, f, ##a);\
+ } while (0)
+
+#define ESP_DMA_CMD 0x10
+#define ESP_DMA_STC 0x11
+#define ESP_DMA_SPA 0x12
+#define ESP_DMA_WBC 0x13
+#define ESP_DMA_WAC 0x14
+#define ESP_DMA_STATUS 0x15
+#define ESP_DMA_SMDLA 0x16
+#define ESP_DMA_WMAC 0x17
+
+#define ESP_DMA_CMD_IDLE 0x00
+#define ESP_DMA_CMD_BLAST 0x01
+#define ESP_DMA_CMD_ABORT 0x02
+#define ESP_DMA_CMD_START 0x03
+#define ESP_DMA_CMD_MASK 0x03
+#define ESP_DMA_CMD_DIAG 0x04
+#define ESP_DMA_CMD_MDL 0x10
+#define ESP_DMA_CMD_INTE_P 0x20
+#define ESP_DMA_CMD_INTE_D 0x40
+#define ESP_DMA_CMD_DIR 0x80
+
+#define ESP_DMA_STAT_PWDN 0x01
+#define ESP_DMA_STAT_ERROR 0x02
+#define ESP_DMA_STAT_ABORT 0x04
+#define ESP_DMA_STAT_DONE 0x08
+#define ESP_DMA_STAT_SCSIINT 0x10
+#define ESP_DMA_STAT_BCMPLT 0x20
+
+/* EEPROM is accessed with 16-bit values */
+#define DC390_EEPROM_READ 0x80
+#define DC390_EEPROM_LEN 0x40
+
+/*
+ * DC390 EEPROM
+ *
+ * 8 * 4 bytes of per-device options
+ * followed by HBA specific options
+ */
+
+/* Per-device options */
+#define DC390_EE_MODE1 0x00
+#define DC390_EE_SPEED 0x01
+
+/* HBA-specific options */
+#define DC390_EE_ADAPT_SCSI_ID 0x40
+#define DC390_EE_MODE2 0x41
+#define DC390_EE_DELAY 0x42
+#define DC390_EE_TAG_CMD_NUM 0x43
+
+#define DC390_EE_MODE1_PARITY_CHK 0x01
+#define DC390_EE_MODE1_SYNC_NEGO0x02
+#define DC390_EE_MODE1_EN_DISC 0x04
+#define DC390_EE_MODE1_SEND_START 0x08
+#define DC390_EE_MODE1_TCQ 0x10
+
+#define DC390_EE_MODE2_MORE_2DRV0x01
+#define DC390_EE_MODE2_GREATER_1G 0x02
+#define DC390_EE_MODE2_RST_SCSI_BUS 0x04
+#define DC390_EE_MODE2_ACTIVE_NEGATION 0x08
+#define DC390_EE_MODE2_NO_SEEK 0x10
+#define DC390_EE_MODE2_LUN_CHECK0x20
+
+struct pci_esp_priv {
+ struct esp *esp;
+ u8 dma_status;
+};
+
+static void pci_esp_dma_drain(struct esp *esp);
+
+static inline struct pci_esp_priv *pci_esp_get_priv(struct esp *esp)
+{
+ struct pci_dev *pdev = esp-dev;
+
+ return
[PATCH 01/12] esp_scsi: spellcheck 'driver'
Reviewed-by: Paolo Bonzini pbonz...@redhat.com Acked-by: David S. Miller da...@davemloft.net Signed-off-by: Hannes Reinecke h...@suse.de --- drivers/scsi/esp_scsi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h index cd68805..b5862e4 100644 --- a/drivers/scsi/esp_scsi.h +++ b/drivers/scsi/esp_scsi.h @@ -1,4 +1,4 @@ -/* esp_scsi.h: Defines and structures for the ESP drier. +/* esp_scsi.h: Defines and structures for the ESP driver. * * Copyright (C) 2007 David S. Miller (da...@davemloft.net) */ -- 1.8.5.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] blk-mq: handle the single queue case in blk_mq_hctx_next_cpu
On 11/24/2014 01:27 AM, Christoph Hellwig wrote: Don't duplicate the code to handle the not cpu bounce case in the caller, do it inside blk_mq_hctx_next_cpu instead. Thanks, applied. -- Jens Axboe -- 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: [PATCHv3 00/12] Re-implement am53c974 driver
Thanks, applied to drivers-for-3.19. -- 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: AW: ARCMSR - Notify sense data report - Lost patch?
On 11/24/2014 02:45 PM, Markus Stockhausen wrote: Von: linux-scsi-ow...@vger.kernel.org [linux-scsi-ow...@vger.kernel.org]quot; im Auftrag von quot;Christoph Hellwig [h...@infradead.org] Gesendet: Montag, 24. November 2014 14:23 An: Markus Stockhausen Cc: ching2...@areca.com.tw; the...@redhat.com; linux-scsi@vger.kernel.org Betreff: Re: ARCMSR - Notify sense data report - Lost patch? On Mon, Nov 24, 2014 at 11:47:02AM +, Markus Stockhausen wrote: Hi, sorting out some diffs between the official Arcea driver and the newest 3.18 patches I found a patch that might got lost: https://lkml.org/lkml/2014/2/20/956 Could you check if that is desired? Looks sensible to me. Did you test it? No not really, as I don't know how. We had a controller crash the last week and I was wondering about the differences between vendor and upstream version. So I basically did some code comparison between the two source. Besides a lot of layout differences and other hacks this was one of the first things I noticed and wondered what difference those flags could make. Especially regarding stability. Hopefully Ching and/or Tomas know better as they seem repsonsible for the rest of the 3.18 arcmsr patches. I don't know why Ching hasn't re-posted this in later series. The Areca in-house driver works stable? Markus -- 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: Another (ESP?) scsi blk-mq problem on sparc64
On 11/24/2014 01:21 AM, Christoph Hellwig wrote:
On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote:
I would suggest looking into the possibility that we allocate the memory
using the count of valid cpus, rather than the largest cpu number.
That's a common error that runs into problems with discontiguous
cpu numbering like Sparc sometimes has.
Yes, that does look like the case. Do you have a good trick on how
to allocate a map for the highest possible cpu number without first
iterating the cpu map? I couldn't find something that looks like a
highest_possible_cpu() helper.
Honestly I think that num_posible_cpus() should return the max of number
of CPUs (weigt), and the highest numbered CPU. It's a pain in the butt
to handle this otherwise.
/* If cpus are offline, map them to first hctx */
map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
set-numa_node);
is where it goes wrong, assuming Meelis has NR_CPUS set to something
14, which was the highest numbered CPU, iirc. A construct like:
map = alloc(num_possible_cpus());
for_each_possible_cpu(i)
map[i] = ...
seems like the obvious way to do things, yet it's broken. And not broken
on x86 where we'd find the issue pretty quickly, but on sparc64 where
it'll take a lot longer to run into. It just violates the principle of
least surprise, which is bad for an API.
That said, if there was a helper like Christoph suggested, it'd be a bit
better. And perhaps we can't just modify num_possible_cpus(), we'd need
num_*_cpus() for the other bitmaps, too. That might be breaking other
things...
Meelis, can you try the attached?
--
Jens Axboe
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 1065d7c65fa1..15da9cc08f64 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -87,10 +87,14 @@ int blk_mq_update_queue_map(unsigned int *map, unsigned int nr_queues)
unsigned int *blk_mq_make_queue_map(struct blk_mq_tag_set *set)
{
+ unsigned int max_cpus;
unsigned int *map;
+ for_each_possible_cpu(max_cpus)
+ ;
+
/* If cpus are offline, map them to first hctx */
- map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
+ map = kzalloc_node(sizeof(*map) * max_cpus, GFP_KERNEL,
set-numa_node);
if (!map)
return NULL;
Re: [PATCH] megaraid_sas: Enable shared host tag map
On Mon, Nov 24, 2014 at 04:33:55PM +0100, Hannes Reinecke wrote: The megaraid SAS driver uses a shared host tag map internally, so we should be telling the block layer about it. But it doesn't make use of request-tag yet. This would only be useful if you got rid of the internal tag allocator. -- 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] aic94xx: Fixup compilation warning
On Mon, 2014-11-24 at 05:40 -0800, Christoph Hellwig wrote: Can someone review this trivial patch for me? Thanks! I don't really think we need reviewers for trivial patches, do we? However, the patch is clearly bogus. What's supposed to happen is that the unset variables (size and offs) get initialised to default values on error return, which is what's missing for offset, so this is the correct patch, isn't it? James --- diff --git a/drivers/scsi/aic94xx/aic94xx_sds.c b/drivers/scsi/aic94xx/aic94xx_sds.c index edb43fd..d11b4d7 100644 --- a/drivers/scsi/aic94xx/aic94xx_sds.c +++ b/drivers/scsi/aic94xx/aic94xx_sds.c @@ -1003,6 +1003,7 @@ static int asd_process_ctrl_a_user(struct asd_ha_struct *asd_ha, } size = sizeof(struct asd_ctrla_phy_settings); + offs = 0; ps = dflt_ps; }
Re: [PATCH v3 09/11] IB/srp: Use block layer tags
On 11/12/14 11:45, Christoph Hellwig wrote: FYI, I've updated this to use .use_blk_tags = 1 isntead of scsi_activate_tcq now that I've rebased the drivers-for-3.19 branch over the tcq rework. Please verify that it's workign as intented. [ just arrived home from traveling ] Hello Christoph, The SRP initiator passes the same tests as before. I have checked with ibdump and Wireshark that the SRP tags are still assigned properly. These tests have been run with and without blk-mq (use_blk_mq=Y versus N). The code I have tested is branch drivers-for-3.19 / commit 18f87a67e6d681d1c6f8b3c47985f21b25959a77. Bart. -- 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] megaraid_sas: Enable shared host tag map
On 11/24/2014 04:35 PM, Christoph Hellwig wrote: On Mon, Nov 24, 2014 at 04:33:55PM +0100, Hannes Reinecke wrote: The megaraid SAS driver uses a shared host tag map internally, so we should be telling the block layer about it. But it doesn't make use of request-tag yet. This would only be useful if you got rid of the internal tag allocator. It is useful as is, as we'll be getting prefixed logging output :-) But yeah, it would be good to get rid of the internal tag allocator. Which I didn't do yet as the driver is using a larger tag map than that one announced to the block layer. This is to facilitate internal command submission, which should always work independent on any tag starvation issues from the upper layers. So when moving to the generic tag allocation code I'd need: - an block-layer helper for allocating a tag without a request (basically separating the existing blk-tag functionality, easy) - introducing 'emergency pools' for the tag map, allowing to allocate a tag even under I/O pressure. What I did was to: - Split off blk_reserve_tag() functionality from blk_start_tag() (and similar with blk_end_tag) - registered the overall size of the shared tag map - called blk_resize_tags() to shrink it to -can_queue - Implemented a 'force' attribute to blk_reserve_tag() to allow it to dip into the excess size. But then I didn't really like this mis-use of the blk_resize_tag() operation; I'd rather have it marked explicitly. However, I'm sure megasas isn't the only driver requiring such a feature (libata eg would benefit from this, too). Ideas? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
RE: [PATCH] megaraid_sas: Enable shared host tag map
-Original Message- From: Christoph Hellwig [mailto:h...@lst.de] Sent: Monday, November 24, 2014 9:06 PM To: Hannes Reinecke Cc: James Bottomley; Sumit Saxena; Kashyap Desai; Christoph Hellwig; linux- s...@vger.kernel.org Subject: Re: [PATCH] megaraid_sas: Enable shared host tag map On Mon, Nov 24, 2014 at 04:33:55PM +0100, Hannes Reinecke wrote: The megaraid SAS driver uses a shared host tag map internally, so we should be telling the block layer about it. But it doesn't make use of request-tag yet. This would only be useful if you got rid of the internal tag allocator. I have patch for code changes in this particular area and that is currently under internal test cycle. Next patch series will start using shared blk tag for internal MPT frame allocation. It will get-rid-off MPT frame pool link list completely and also does lots of refactor w.r.t MFI/MPT frame corruption issue. Using shared blk tag gave good performance improvement as driver completely removed mpt frame spin lock used in megasas_get_cmd_fusion/ megasas_return_cmd_fusion. ~ Kashyap -- 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] aic94xx: Fixup compilation warning
On 11/24/2014 04:39 PM, James Bottomley wrote: On Mon, 2014-11-24 at 05:40 -0800, Christoph Hellwig wrote: Can someone review this trivial patch for me? Thanks! I don't really think we need reviewers for trivial patches, do we? However, the patch is clearly bogus. What's supposed to happen is that the unset variables (size and offs) get initialised to default values on error return, which is what's missing for offset, so this is the correct patch, isn't it? James --- diff --git a/drivers/scsi/aic94xx/aic94xx_sds.c b/drivers/scsi/aic94xx/aic94xx_sds.c index edb43fd..d11b4d7 100644 --- a/drivers/scsi/aic94xx/aic94xx_sds.c +++ b/drivers/scsi/aic94xx/aic94xx_sds.c @@ -1003,6 +1003,7 @@ static int asd_process_ctrl_a_user(struct asd_ha_struct *asd_ha, } size = sizeof(struct asd_ctrla_phy_settings); + offs = 0; ps = dflt_ps; } Yep, that would work, as well. Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
RE: [PATCH] megaraid_sas: Enable shared host tag map
-Original Message- From: Hannes Reinecke [mailto:h...@suse.de] Sent: Monday, November 24, 2014 9:21 PM To: Christoph Hellwig Cc: James Bottomley; Sumit Saxena; Kashyap Desai; linux- s...@vger.kernel.org Subject: Re: [PATCH] megaraid_sas: Enable shared host tag map On 11/24/2014 04:35 PM, Christoph Hellwig wrote: On Mon, Nov 24, 2014 at 04:33:55PM +0100, Hannes Reinecke wrote: The megaraid SAS driver uses a shared host tag map internally, so we should be telling the block layer about it. But it doesn't make use of request-tag yet. This would only be useful if you got rid of the internal tag allocator. It is useful as is, as we'll be getting prefixed logging output :-) But yeah, it would be good to get rid of the internal tag allocator. Which I didn't do yet as the driver is using a larger tag map than that one announced to the block layer. This is to facilitate internal command submission, which should always work independent on any tag starvation issues from the upper layers. So when moving to the generic tag allocation code I'd need: - an block-layer helper for allocating a tag without a request (basically separating the existing blk-tag functionality, easy) - introducing 'emergency pools' for the tag map, allowing to allocate a tag even under I/O pressure. What I did was to: - Split off blk_reserve_tag() functionality from blk_start_tag() (and similar with blk_end_tag) - registered the overall size of the shared tag map - called blk_resize_tags() to shrink it to -can_queue - Implemented a 'force' attribute to blk_reserve_tag() to allow it to dip into the excess size. Hannes, I just received your reply... My response crossed with yours. I have attached preview patch for your reference which I refer in my earlier response. Megaraid_sas driver will expose only actual IO command queue depth to the SML and it will manage all internal used commands without taking any help from SML. Driver will now expose max_scsi_cmds to the upper layer which will be lower than actually FW can support max command. E.a + instance-max_scsi_cmds = instance-max_fw_cmds - + (MEGASAS_FUSION_INTERNAL_CMDS + + MEGASAS_FUSION_IOCTL_CMDS); We have to do this to make use of existing OS distribution which really does not support blk_reserve_tag(). ~ Kashyap But then I didn't really like this mis-use of the blk_resize_tag() operation; I'd rather have it marked explicitly. However, I'm sure megasas isn't the only driver requiring such a feature (libata eg would benefit from this, too). Ideas? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de+49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 21284 (AG Nürnberg) blk_shared.patch Description: Binary data
Re: [PATCH] aic94xx: Fixup compilation warning
On 11/24/2014 02:40 PM, Christoph Hellwig wrote:
Can someone review this trivial patch for me? Thanks!
The compiler complains because when asd_find_flash_de fails, the offs is not
initialized.
When that happens this code is invoked :
if (err) {
ASD_DPRINTK(couldn't find CTRL-A user settings section\n);
ASD_DPRINTK(Creating default CTRL-A user settings section\n);
dflt_ps.id0 = 'h';
dflt_ps.num_phys = 8;
for (i =0; i ASD_MAX_PHYS; i++) {
memcpy(dflt_ps.phy_ent[i].sas_addr,
asd_ha-hw_prof.sas_addr, SAS_ADDR_SIZE);
dflt_ps.phy_ent[i].sas_link_rates = 0x98;
dflt_ps.phy_ent[i].flags = 0x0;
dflt_ps.phy_ent[i].sata_link_rates = 0x0;
}
size = sizeof(struct asd_ctrla_phy_settings);
ps = dflt_ps;
the dflt_ps is initialized and the address assigned to 'ps', but none of them
is used later
}
if (size == 0)
goto out;
err = -ENOMEM;
el = kmalloc(size, GFP_KERNEL);
if (!el) {
ASD_DPRINTK(no mem for ctrla user settings section\n);
goto out;
}
err = asd_read_flash_seg(asd_ha, (void *)el, offs, size);
if (err) {
ASD_DPRINTK(couldn't read ctrla phy settings section\n);
goto out2;
}
err = -ENOENT;
ps = asd_find_ll_by_id(el, 'h', 0xFF);
here^ a new value is assigned to 'ps'
I have no idea what was intended in the originally so - it looks likely, but
how do we know that
the '0' is a correct value for offs?
Probably the error path is never used, this patch should fix the gcc warning
too -
@@ -990,20 +990,7 @@ static int asd_process_ctrl_a_user(struct asd_ha_struct
*asd_ha,
err = asd_find_flash_de(flash_dir, FLASH_DE_CTRL_A_USER, offs, size);
if (err) {
ASD_DPRINTK(couldn't find CTRL-A user settings section\n);
- ASD_DPRINTK(Creating default CTRL-A user settings section\n);
-
- dflt_ps.id0 = 'h';
- dflt_ps.num_phys = 8;
- for (i =0; i ASD_MAX_PHYS; i++) {
- memcpy(dflt_ps.phy_ent[i].sas_addr,
- asd_ha-hw_prof.sas_addr, SAS_ADDR_SIZE);
- dflt_ps.phy_ent[i].sas_link_rates = 0x98;
- dflt_ps.phy_ent[i].flags = 0x0;
- dflt_ps.phy_ent[i].sata_link_rates = 0x0;
- }
-
- size = sizeof(struct asd_ctrla_phy_settings);
- ps = dflt_ps;
+ goto out;
}
if (size == 0)
Somebody with access to this hw might help and test offs = 0;.
It's a question whether we should touch old drivers at all.
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] aic94xx: Fixup compilation warning
On Mon, 2014-11-24 at 17:04 +0100, Tomas Henzl wrote:
On 11/24/2014 02:40 PM, Christoph Hellwig wrote:
Can someone review this trivial patch for me? Thanks!
The compiler complains because when asd_find_flash_de fails, the offs is not
initialized.
When that happens this code is invoked :
if (err) {
ASD_DPRINTK(couldn't find CTRL-A user settings section\n);
ASD_DPRINTK(Creating default CTRL-A user settings
section\n);
dflt_ps.id0 = 'h';
dflt_ps.num_phys = 8;
for (i =0; i ASD_MAX_PHYS; i++) {
memcpy(dflt_ps.phy_ent[i].sas_addr,
asd_ha-hw_prof.sas_addr, SAS_ADDR_SIZE);
dflt_ps.phy_ent[i].sas_link_rates = 0x98;
dflt_ps.phy_ent[i].flags = 0x0;
dflt_ps.phy_ent[i].sata_link_rates = 0x0;
}
size = sizeof(struct asd_ctrla_phy_settings);
ps = dflt_ps;
the dflt_ps is initialized and the address assigned to 'ps', but none of them
is used later
}
if (size == 0)
goto out;
err = -ENOMEM;
el = kmalloc(size, GFP_KERNEL);
if (!el) {
ASD_DPRINTK(no mem for ctrla user settings section\n);
goto out;
}
err = asd_read_flash_seg(asd_ha, (void *)el, offs, size);
if (err) {
ASD_DPRINTK(couldn't read ctrla phy settings section\n);
goto out2;
}
err = -ENOENT;
ps = asd_find_ll_by_id(el, 'h', 0xFF);
here^ a new value is assigned to 'ps'
I have no idea what was intended in the originally so - it looks likely, but
how do we know that
the '0' is a correct value for offs?
Yes, it seems to be the default from the hw ... if you don't have any
nvram then the phy setting are up first.
Probably the error path is never used, this patch should fix the gcc warning
too -
@@ -990,20 +990,7 @@ static int asd_process_ctrl_a_user(struct asd_ha_struct
*asd_ha,
err = asd_find_flash_de(flash_dir, FLASH_DE_CTRL_A_USER, offs, size);
if (err) {
ASD_DPRINTK(couldn't find CTRL-A user settings section\n);
- ASD_DPRINTK(Creating default CTRL-A user settings section\n);
-
- dflt_ps.id0 = 'h';
- dflt_ps.num_phys = 8;
- for (i =0; i ASD_MAX_PHYS; i++) {
- memcpy(dflt_ps.phy_ent[i].sas_addr,
-asd_ha-hw_prof.sas_addr, SAS_ADDR_SIZE);
- dflt_ps.phy_ent[i].sas_link_rates = 0x98;
- dflt_ps.phy_ent[i].flags = 0x0;
- dflt_ps.phy_ent[i].sata_link_rates = 0x0;
- }
-
- size = sizeof(struct asd_ctrla_phy_settings);
- ps = dflt_ps;
+ goto out;
I did think about that. There does seem to be a definite reason to
expect the phy setting read to succeed even though the nvram read
failed. I think the reason was that there were some aic94xx cards that
had no nvram and therefore always failed the read, but I can't find any
evidence of that any more.
James
Re: Another (ESP?) scsi blk-mq problem on sparc64
On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote:
On 11/24/2014 01:21 AM, Christoph Hellwig wrote:
On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote:
I would suggest looking into the possibility that we allocate the memory
using the count of valid cpus, rather than the largest cpu number.
That's a common error that runs into problems with discontiguous
cpu numbering like Sparc sometimes has.
Yes, that does look like the case. Do you have a good trick on how
to allocate a map for the highest possible cpu number without first
iterating the cpu map? I couldn't find something that looks like a
highest_possible_cpu() helper.
Honestly I think that num_posible_cpus() should return the max of
number of CPUs (weigt), and the highest numbered CPU. It's a pain in
the butt to handle this otherwise.
Hear, hear!!! That would make my life easier, and would make this sort
of problem much less likely to occur!
Thanx, Paul
/* If cpus are offline, map them to first hctx */
map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
set-numa_node);
is where it goes wrong, assuming Meelis has NR_CPUS set to something
14, which was the highest numbered CPU, iirc. A construct like:
map = alloc(num_possible_cpus());
for_each_possible_cpu(i)
map[i] = ...
seems like the obvious way to do things, yet it's broken. And not
broken on x86 where we'd find the issue pretty quickly, but on
sparc64 where it'll take a lot longer to run into. It just violates
the principle of least surprise, which is bad for an API.
That said, if there was a helper like Christoph suggested, it'd be a
bit better. And perhaps we can't just modify num_possible_cpus(),
we'd need num_*_cpus() for the other bitmaps, too. That might be
breaking other things...
Meelis, can you try the attached?
--
Jens Axboe
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 1065d7c65fa1..15da9cc08f64 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -87,10 +87,14 @@ int blk_mq_update_queue_map(unsigned int *map, unsigned
int nr_queues)
unsigned int *blk_mq_make_queue_map(struct blk_mq_tag_set *set)
{
+ unsigned int max_cpus;
unsigned int *map;
+ for_each_possible_cpu(max_cpus)
+ ;
+
/* If cpus are offline, map them to first hctx */
- map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
+ map = kzalloc_node(sizeof(*map) * max_cpus, GFP_KERNEL,
set-numa_node);
if (!map)
return NULL;
--
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] aic94xx: Fixup compilation warning
On 11/24/2014 05:10 PM, James Bottomley wrote:
On Mon, 2014-11-24 at 17:04 +0100, Tomas Henzl wrote:
On 11/24/2014 02:40 PM, Christoph Hellwig wrote:
Can someone review this trivial patch for me? Thanks!
The compiler complains because when asd_find_flash_de fails, the offs is not
initialized.
When that happens this code is invoked :
if (err) {
ASD_DPRINTK(couldn't find CTRL-A user settings section\n);
ASD_DPRINTK(Creating default CTRL-A user settings
section\n);
dflt_ps.id0 = 'h';
dflt_ps.num_phys = 8;
for (i =0; i ASD_MAX_PHYS; i++) {
memcpy(dflt_ps.phy_ent[i].sas_addr,
asd_ha-hw_prof.sas_addr, SAS_ADDR_SIZE);
dflt_ps.phy_ent[i].sas_link_rates = 0x98;
dflt_ps.phy_ent[i].flags = 0x0;
dflt_ps.phy_ent[i].sata_link_rates = 0x0;
}
size = sizeof(struct asd_ctrla_phy_settings);
ps = dflt_ps;
the dflt_ps is initialized and the address assigned to 'ps', but none of
them is used later
}
if (size == 0)
goto out;
err = -ENOMEM;
el = kmalloc(size, GFP_KERNEL);
if (!el) {
ASD_DPRINTK(no mem for ctrla user settings section\n);
goto out;
}
err = asd_read_flash_seg(asd_ha, (void *)el, offs, size);
if (err) {
ASD_DPRINTK(couldn't read ctrla phy settings section\n);
goto out2;
}
err = -ENOENT;
ps = asd_find_ll_by_id(el, 'h', 0xFF);
here^ a new value is assigned to 'ps'
I have no idea what was intended in the originally so - it looks likely, but
how do we know that
the '0' is a correct value for offs?
Yes, it seems to be the default from the hw ... if you don't have any
nvram then the phy setting are up first.
Probably the error path is never used, this patch should fix the gcc warning
too -
@@ -990,20 +990,7 @@ static int asd_process_ctrl_a_user(struct asd_ha_struct
*asd_ha,
err = asd_find_flash_de(flash_dir, FLASH_DE_CTRL_A_USER, offs, size);
if (err) {
ASD_DPRINTK(couldn't find CTRL-A user settings section\n);
-ASD_DPRINTK(Creating default CTRL-A user settings section\n);
-
-dflt_ps.id0 = 'h';
-dflt_ps.num_phys = 8;
-for (i =0; i ASD_MAX_PHYS; i++) {
-memcpy(dflt_ps.phy_ent[i].sas_addr,
- asd_ha-hw_prof.sas_addr, SAS_ADDR_SIZE);
-dflt_ps.phy_ent[i].sas_link_rates = 0x98;
-dflt_ps.phy_ent[i].flags = 0x0;
-dflt_ps.phy_ent[i].sata_link_rates = 0x0;
-}
-
-size = sizeof(struct asd_ctrla_phy_settings);
-ps = dflt_ps;
+goto out;
I did think about that. There does seem to be a definite reason to
expect the phy setting read to succeed even though the nvram read
failed. I think the reason was that there were some aic94xx cards that
had no nvram and therefore always failed the read, but I can't find any
evidence of that any more.
The dead code there brought me to the idea that the error path was not much
used...
Using a '0' is at least so good as some random value, so I'm fine
with your or Hannes's patch.
James
N�r��y���b�X��ǧv�^�){.n�+{{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!tml=
--
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] libsas: remove task_collector mode
On Mon, Nov 24, 2014 at 12:41 AM, Christoph Hellwig h...@lst.de wrote: The task_collector mode (or latency_injector, (C) Dan Willians) is an optional I/O path in libsas that queues up scsi commands instead of directly sending it to the hardware. It generall increases latencies to in the optiomal case slightly reduce mmio traffic to the hardware. Only the obsolete aic94xx driver and the mvsas driver allowed to use it without recompiling the kernel, and most drivers didn't support it at all. Remove the giant blob of code to allow better optimizations for scsi-mq in the future. Signed-off-by: Christoph Hellwig h...@lst.de Acked-by: Dan Williams dan.j.willi...@intel.com -- 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 1/6] isci: Fix a typo for the word destroy
From: Markus Elfring elfr...@users.sourceforge.net Date: Mon, 24 Nov 2014 15:35:48 +0100 A word was corrected in the description for the sci_remote_device_destruct() function. Signed-off-by: Markus Elfring elfr...@users.sourceforge.net --- drivers/scsi/isci/remote_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/isci/remote_device.c b/drivers/scsi/isci/remote_device.c index cc51f38..f54bb98 100644 --- a/drivers/scsi/isci/remote_device.c +++ b/drivers/scsi/isci/remote_device.c @@ -1008,7 +1008,7 @@ static void sci_remote_device_initial_state_enter(struct sci_base_state_machine * successfully destructed or if some failure occurred. enum sci_status This value * is returned if the device is successfully destructed. * SCI_FAILURE_INVALID_REMOTE_DEVICE This value is returned if the supplied - * device isn't valid (e.g. it's already been destoryed, the handle isn't + * device isn't valid (e.g. it's already been destroyed, the handle isn't * valid, etc.). */ static enum sci_status sci_remote_device_destruct(struct isci_remote_device *idev) -- 2.1.3 -- 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/6] SCSI-libfc: Fix typos for the word destroy
From: Markus Elfring elfr...@users.sourceforge.net Date: Mon, 24 Nov 2014 15:40:41 +0100 Identifiers were corrected in descriptions for the functions fc_fcp_pkt_destroy() and fc_fcp_destroy(). Signed-off-by: Markus Elfring elfr...@users.sourceforge.net --- drivers/scsi/libfc/fc_fcp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c index 1d7e76e..5649fc9 100644 --- a/drivers/scsi/libfc/fc_fcp.c +++ b/drivers/scsi/libfc/fc_fcp.c @@ -191,7 +191,7 @@ static void fc_fcp_pkt_hold(struct fc_fcp_pkt *fsp) } /** - * fc_fcp_pkt_destory() - Release hold on a fcp_pkt + * fc_fcp_pkt_destroy() - Release hold on a fcp_pkt * @seq: The sequence that the FCP packet is on (required by destructor API) * @fsp: The FCP packet to be released * @@ -2216,7 +2216,7 @@ int fc_change_queue_type(struct scsi_device *sdev, int tag_type) EXPORT_SYMBOL(fc_change_queue_type); /** - * fc_fcp_destory() - Tear down the FCP layer for a given local port + * fc_fcp_destroy() - Tear down the FCP layer for a given local port * @lport: The local port that no longer needs the FCP layer */ void fc_fcp_destroy(struct fc_lport *lport) -- 2.1.3 -- 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: Another (ESP?) scsi blk-mq problem on sparc64
On 11/24/2014 09:22 AM, Paul E. McKenney wrote: On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote: On 11/24/2014 01:21 AM, Christoph Hellwig wrote: On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote: I would suggest looking into the possibility that we allocate the memory using the count of valid cpus, rather than the largest cpu number. That's a common error that runs into problems with discontiguous cpu numbering like Sparc sometimes has. Yes, that does look like the case. Do you have a good trick on how to allocate a map for the highest possible cpu number without first iterating the cpu map? I couldn't find something that looks like a highest_possible_cpu() helper. Honestly I think that num_posible_cpus() should return the max of number of CPUs (weigt), and the highest numbered CPU. It's a pain in the butt to handle this otherwise. Hear, hear!!! That would make my life easier, and would make this sort of problem much less likely to occur! How about this one? -- Jens Axboe diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h index 0a9a6da21e74..db21f68aaef0 100644 --- a/include/linux/cpumask.h +++ b/include/linux/cpumask.h @@ -83,7 +83,13 @@ extern const struct cpumask *const cpu_active_mask; #if NR_CPUS 1 #define num_online_cpus() cpumask_weight(cpu_online_mask) -#define num_possible_cpus() cpumask_weight(cpu_possible_mask) +/* + * For platforms with discontig CPU numbering, the weight of the possible + * bitmask may be less than the highest numbered CPU. Return the max of + * the two, to prevent accidentical bugs. + */ +#define num_possible_cpus() \ + max_t(unsigned int, cpumask_weight(cpu_possible_mask), nr_cpu_ids) #define num_present_cpus() cpumask_weight(cpu_present_mask) #define num_active_cpus() cpumask_weight(cpu_active_mask) #define cpu_online(cpu) cpumask_test_cpu((cpu), cpu_online_mask)
Re: Another (ESP?) scsi blk-mq problem on sparc64
On Mon, Nov 24, 2014 at 10:16:15AM -0700, Jens Axboe wrote: On 11/24/2014 09:22 AM, Paul E. McKenney wrote: On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote: On 11/24/2014 01:21 AM, Christoph Hellwig wrote: On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote: I would suggest looking into the possibility that we allocate the memory using the count of valid cpus, rather than the largest cpu number. That's a common error that runs into problems with discontiguous cpu numbering like Sparc sometimes has. Yes, that does look like the case. Do you have a good trick on how to allocate a map for the highest possible cpu number without first iterating the cpu map? I couldn't find something that looks like a highest_possible_cpu() helper. Honestly I think that num_posible_cpus() should return the max of number of CPUs (weigt), and the highest numbered CPU. It's a pain in the butt to handle this otherwise. Hear, hear!!! That would make my life easier, and would make this sort of problem much less likely to occur! How about this one? Works for me! (Just for the record, as far as I know, this doesn't matter for RCU, which already uses nr_cpu_ids.) Thanx, Paul -- Jens Axboe diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h index 0a9a6da21e74..db21f68aaef0 100644 --- a/include/linux/cpumask.h +++ b/include/linux/cpumask.h @@ -83,7 +83,13 @@ extern const struct cpumask *const cpu_active_mask; #if NR_CPUS 1 #define num_online_cpus()cpumask_weight(cpu_online_mask) -#define num_possible_cpus() cpumask_weight(cpu_possible_mask) +/* + * For platforms with discontig CPU numbering, the weight of the possible + * bitmask may be less than the highest numbered CPU. Return the max of + * the two, to prevent accidentical bugs. + */ +#define num_possible_cpus() \ + max_t(unsigned int, cpumask_weight(cpu_possible_mask), nr_cpu_ids) #define num_present_cpus() cpumask_weight(cpu_present_mask) #define num_active_cpus()cpumask_weight(cpu_active_mask) #define cpu_online(cpu) cpumask_test_cpu((cpu), cpu_online_mask) -- 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: Another (ESP?) scsi blk-mq problem on sparc64
On 11/24/2014 10:31 AM, Paul E. McKenney wrote: On Mon, Nov 24, 2014 at 10:16:15AM -0700, Jens Axboe wrote: On 11/24/2014 09:22 AM, Paul E. McKenney wrote: On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote: On 11/24/2014 01:21 AM, Christoph Hellwig wrote: On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote: I would suggest looking into the possibility that we allocate the memory using the count of valid cpus, rather than the largest cpu number. That's a common error that runs into problems with discontiguous cpu numbering like Sparc sometimes has. Yes, that does look like the case. Do you have a good trick on how to allocate a map for the highest possible cpu number without first iterating the cpu map? I couldn't find something that looks like a highest_possible_cpu() helper. Honestly I think that num_posible_cpus() should return the max of number of CPUs (weigt), and the highest numbered CPU. It's a pain in the butt to handle this otherwise. Hear, hear!!! That would make my life easier, and would make this sort of problem much less likely to occur! How about this one? Works for me! Thanks! I'll add an appropriate comment and send it out for review. (Just for the record, as far as I know, this doesn't matter for RCU, which already uses nr_cpu_ids.) Was that done after hitting something like this? Meelis, can you check if it fixes your issue? -- Jens Axboe -- 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: Another (ESP?) scsi blk-mq problem on sparc64
On Mon, Nov 24, 2014 at 10:33:37AM -0700, Jens Axboe wrote: On 11/24/2014 10:31 AM, Paul E. McKenney wrote: On Mon, Nov 24, 2014 at 10:16:15AM -0700, Jens Axboe wrote: On 11/24/2014 09:22 AM, Paul E. McKenney wrote: On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote: On 11/24/2014 01:21 AM, Christoph Hellwig wrote: On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote: I would suggest looking into the possibility that we allocate the memory using the count of valid cpus, rather than the largest cpu number. That's a common error that runs into problems with discontiguous cpu numbering like Sparc sometimes has. Yes, that does look like the case. Do you have a good trick on how to allocate a map for the highest possible cpu number without first iterating the cpu map? I couldn't find something that looks like a highest_possible_cpu() helper. Honestly I think that num_posible_cpus() should return the max of number of CPUs (weigt), and the highest numbered CPU. It's a pain in the butt to handle this otherwise. Hear, hear!!! That would make my life easier, and would make this sort of problem much less likely to occur! How about this one? Works for me! Thanks! I'll add an appropriate comment and send it out for review. (Just for the record, as far as I know, this doesn't matter for RCU, which already uses nr_cpu_ids.) Was that done after hitting something like this? Nope. It was done after people started griping about RCU's older habit of sizing its data structures based on NR_CPUS. Something about distros cranking NR_CPUS up to 1024 and beyond. ;-) Thanx, Paul Meelis, can you check if it fixes your issue? -- Jens Axboe -- 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
Fix Penguin Penalty 17th October2014 ( mail-archive.com )
Dear Sir Did your website get hit by Google Penguin update on October 17th 2014? What basically is Google Penguin Update? It is actually a code name for Google algorithm which aims at decreasing your websites search engine rankings that violate Googles guidelines by using black hat SEO techniques to rank your webpage by giving number of spammy links to the page. We are one of those few SEO companies that can help you avoid penalties from Google Updates like Penguin and Panda. Our clients have survived all the previous and present updates with ease. They have never been hit because we use 100% white hat SEO techniques to rank Webpages. Simple thing that we do to keep websites away from any Penguin or Panda penalties is follow Google guidelines and we give Google users the best answers to their queries. If you are looking to increase the quality of your websites and to get more targeted traffic or save your websites from these Google penalties email us back with your interest. We will be glad to serve you and help you grow your business. Regards Julia kites SEO Manager ( TOB ) B7 Green Avenue, Amritsar 143001 Punjab NO CLICK in the subject to STOP EMAILS -- 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
AW: AW: ARCMSR - Notify sense data report - Lost patch?
Von: Tomas Henzl [the...@redhat.com] Gesendet: Montag, 24. November 2014 15:47 An: Markus Stockhausen; Christoph Hellwig Cc: ching2...@areca.com.tw; linux-scsi@vger.kernel.org Betreff: Re: AW: ARCMSR - Notify sense data report - Lost patch? On 11/24/2014 02:45 PM, Markus Stockhausen wrote: Von: linux-scsi-ow...@vger.kernel.org [linux-scsi-ow...@vger.kernel.org]quot; im Auftrag von quot;Christoph Hellwig [h...@infradead.org] Gesendet: Montag, 24. November 2014 14:23 An: Markus Stockhausen Cc: ching2...@areca.com.tw; the...@redhat.com; linux-scsi@vger.kernel.org Betreff: Re: ARCMSR - Notify sense data report - Lost patch? On Mon, Nov 24, 2014 at 11:47:02AM +, Markus Stockhausen wrote: Hi, sorting out some diffs between the official Arcea driver and the newest 3.18 patches I found a patch that might got lost: https://lkml.org/lkml/2014/2/20/956 Could you check if that is desired? Looks sensible to me. Did you test it? No not really, as I don't know how. We had a controller crash the last week and I was wondering about the differences between vendor and upstream version. So I basically did some code comparison between the two source. Besides a lot of layout differences and other hacks this was one of the first things I noticed and wondered what difference those flags could make. Especially regarding stability. Hopefully Ching and/or Tomas know better as they seem repsonsible for the rest of the 3.18 arcmsr patches. I don't know why Ching hasn't re-posted this in later series. The Areca in-house driver works stable? Sorry - No idea. We are on a stock kernel (3.10 longterm no vendor driver) and have to decide which way to go ... Sadly quite limited test possibilites. None of the two options feels 100% comfortable. @Ching: Does any of the patches fit for stable? Markus Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Ãber das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497
RE: [PATCH 00/13] hpsa update
-Original Message- From: Christoph Hellwig [mailto:h...@infradead.org] Sent: Thursday, November 20, 2014 9:55 AM To: Don Brace Cc: h...@infradead.org; webb.sca...@hp.com; james.bottom...@parallels.com; brace; linux-scsi@vger.kernel.org Subject: Re: [PATCH 00/13] hpsa update I've applied all patches to drivers-for-3.19. If you could do me two favours: - please look into sparse endianess warnings. This series introduces a few new ones, but given that the area around it was full of it I didn't pull it for that for now. - please review the various hpsa fixes Tomas Henzl sent over the last few weeks. Thanks, Christoph I created a patch for the extra sparse warnings and I have it in for a local review. I will get it up soon. Most of the people in my area are off this week. -- 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] scsi: ufs: ensure clk gating work is finished before module unloading
Looks good to me. Reviewed-by: Subhash Jadavani subha...@codeaurora.org -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Akinobu Mita Sent: Sunday, November 23, 2014 9:24 PM To: linux-scsi@vger.kernel.org Cc: Akinobu Mita; Akinobu Mita; Vinayak Holikatti; Dolev Raviv; Subhash Jadavani; Yaniv Gardi; Sujit Reddy Thumma; Maya Erez; Sahitya Tummala; Christoph Hellwig; James E.J. Bottomley Subject: [PATCH] scsi: ufs: ensure clk gating work is finished before module unloading When dynamic clk gating feature is enabled, delayed workqueue machanism is used in order to detect certain period of inactivity. But there is no guarantee that scheduled gating work is completed before module unloading. So it can cause kernel crash by accessing memory after it was freed. Fix it by cancelling clk gating and ungating works and ensure that its execution is finished before module unloading. Signed-off-by: Akinobu Mita m...@fixstars.com Cc: Vinayak Holikatti vinholika...@gmail.com Cc: Dolev Raviv dra...@codeaurora.org Cc: Subhash Jadavani subha...@codeaurora.org Cc: Yaniv Gardi yga...@codeaurora.org Cc: Sujit Reddy Thumma sthu...@codeaurora.org Cc: Maya Erez me...@codeaurora.org Cc: Sahitya Tummala stumm...@codeaurora.org Cc: Christoph Hellwig h...@lst.de Cc: James E.J. Bottomley jbottom...@parallels.com Cc: linux-scsi@vger.kernel.org --- drivers/scsi/ufs/ufshcd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index d18adc4..713420b 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -744,6 +744,8 @@ static void ufshcd_exit_clk_gating(struct ufs_hba *hba) if (!ufshcd_is_clkgating_allowed(hba)) return; device_remove_file(hba-dev, hba-clk_gating.delay_attr); + cancel_work_sync(hba-clk_gating.ungate_work); + cancel_delayed_work_sync(hba-clk_gating.gate_work); } /* Must be called with host lock acquired */ -- 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 -- 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 2/3] wd719x: Introduce Western Digital WD7193/7197/7296 PCI SCSI card driver
On Monday 24 November 2014 14:15:47 Hannes Reinecke wrote:
On 11/24/2014 01:11 PM, Ondrej Zary wrote:
Introduce wd719x, a driver for Western Digital WD7193, WD7197 and WD7296
PCI SCSI controllers based on WD33C296A chip.
Tested with WD7193 card.
Reviewed-by: Christoph Hellwig h...@lst.de
Signed-off-by: Ondrej Zary li...@rainbow-software.org
[...]
+ result = wd719x_send_scb(scb);
+ if (result != DID_OK) {
+ dev_warn(wd-pdev-dev, can't queue SCB\n);
+ wd719x_finish_cmd(cmd, result);
+ }
+
+ spin_unlock_irqrestore(wd-sh-host_lock, flags);
+
+ return 0;
+}
Why did you use 'wait_ready' here?
Any sane HBA driver should set the queue depth parameters
correctly to avoid this from happening.
Wouldn't it be far better to just return HOST_BUSY here if
the command register isn't free and submit the command
directly otherwise?
It probably comes from the original driver. Will send a new version.
--
Ondrej Zary
--
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] esas2r: fix an oversight in setting return value
Acked-by: Bradley Grove bgr...@attotech.com Thanks, Brad On 11/16/2014 08:35 AM, Tomas Henzl wrote: The patch moves an error code assigment to a 'default' case in the previous switch statement. Signed-off-by: Tomas Henzl the...@redhat.com --- drivers/scsi/esas2r/esas2r_ioctl.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/esas2r/esas2r_ioctl.c b/drivers/scsi/esas2r/esas2r_ioctl.c index c88b9f9491..baf913047b 100644 --- a/drivers/scsi/esas2r/esas2r_ioctl.c +++ b/drivers/scsi/esas2r/esas2r_ioctl.c @@ -1524,9 +1524,12 @@ ioctl_done: case -EINVAL: ioctl-header.return_code = IOCTL_INVALID_PARAM; break; + + default: + ioctl-header.return_code = IOCTL_GENERAL_ERROR; + break; } - ioctl-header.return_code = IOCTL_GENERAL_ERROR; } /* Always copy the buffer back, if only to pick up the status */ -- 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 2/3] esas2r: fix an error path in esas2r_ioctl_handler
Acked-by: Bradley Grove bgr...@attotech.com
Thanks,
Brad
On 11/16/2014 08:35 AM, Tomas Henzl wrote:
Is seems strange to manipulate nvram_semaphore when in this place,
this patch fixes it.
Signed-off-by: Tomas Henzl the...@redhat.com
---
drivers/scsi/esas2r/esas2r_ioctl.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/esas2r/esas2r_ioctl.c
b/drivers/scsi/esas2r/esas2r_ioctl.c
index 9ac8207554..c88b9f9491 100644
--- a/drivers/scsi/esas2r/esas2r_ioctl.c
+++ b/drivers/scsi/esas2r/esas2r_ioctl.c
@@ -1420,9 +1420,10 @@ int esas2r_ioctl_handler(void *hostdata, int cmd, void
__user *arg)
rq = esas2r_alloc_request(a);
if (rq == NULL) {
- up(a-nvram_semaphore);
- ioctl-data.prw.code = 0;
- break;
+ kfree(ioctl);
+ esas2r_log(ESAS2R_LOG_WARN,
+ could not allocate an internal request);
+ return -ENOMEM;
}
code = esas2r_write_params(a, rq,
--
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] esas2r: fix an oversight in setting return value
Acked-by: Bradley Grove bgr...@attotech.com Thanks, Brad On 11/16/2014 08:35 AM, Tomas Henzl wrote: The patch moves an error code assigment to a 'default' case in the previous switch statement. Signed-off-by: Tomas Henzl the...@redhat.com --- drivers/scsi/esas2r/esas2r_ioctl.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/esas2r/esas2r_ioctl.c b/drivers/scsi/esas2r/esas2r_ioctl.c index c88b9f9491..baf913047b 100644 --- a/drivers/scsi/esas2r/esas2r_ioctl.c +++ b/drivers/scsi/esas2r/esas2r_ioctl.c @@ -1524,9 +1524,12 @@ ioctl_done: case -EINVAL: ioctl-header.return_code = IOCTL_INVALID_PARAM; break; + + default: + ioctl-header.return_code = IOCTL_GENERAL_ERROR; + break; } - ioctl-header.return_code = IOCTL_GENERAL_ERROR; } /* Always copy the buffer back, if only to pick up the status */ -- 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] esas2r: fir error handling in do_fm_api
Looks good.
Acked-by: Bradley Grove bgr...@attotech.com
Thanks,
Brad
On 11/16/2014 08:35 AM, Tomas Henzl wrote:
This patch fixes an error path and rearranges error handling.
Signed-off-by: Tomas Henzl the...@redhat.com
---
drivers/scsi/esas2r/esas2r_ioctl.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/esas2r/esas2r_ioctl.c
b/drivers/scsi/esas2r/esas2r_ioctl.c
index d89a0277a8..9ac8207554 100644
--- a/drivers/scsi/esas2r/esas2r_ioctl.c
+++ b/drivers/scsi/esas2r/esas2r_ioctl.c
@@ -117,9 +117,8 @@ static void do_fm_api(struct esas2r_adapter *a, struct
esas2r_flash_img *fi)
rq = esas2r_alloc_request(a);
if (rq == NULL) {
- up(a-fm_api_semaphore);
fi-status = FI_STAT_BUSY;
- return;
+ goto free_sem;
}
if (fi == a-firmware.header) {
@@ -135,7 +134,7 @@ static void do_fm_api(struct esas2r_adapter *a, struct
esas2r_flash_img *fi)
if (a-firmware.header_buff == NULL) {
esas2r_debug(failed to allocate header buffer!);
fi-status = FI_STAT_BUSY;
- return;
+ goto free_req;
}
memcpy(a-firmware.header_buff, fi,
@@ -171,9 +170,10 @@ all_done:
a-firmware.header_buff,
(dma_addr_t)a-firmware.header_buff_phys);
}
-
- up(a-fm_api_semaphore);
+free_req:
esas2r_free_request(a, (struct esas2r_request *)rq);
+free_sem:
+ up(a-fm_api_semaphore);
return;
}
--
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: Another (ESP?) scsi blk-mq problem on sparc64
From: Jens Axboe ax...@kernel.dk Date: Mon, 24 Nov 2014 10:16:15 -0700 How about this one? The num in num_possible_cpus() means a count, as in how many are there. It doesn't mean largest ID of members of set X, which is what you are asking for. Even worse, having num_online_cpus() and num_possible_cpus() count from a different perspective is really confusing. Usually when people want a per-cpu thing they allocate percpu memory which hides all of these details, why don't you allocate the map as dynamic per-cpu memory? It will also do the NUMA node local allocations for you as well. -- 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: Another (ESP?) scsi blk-mq problem on sparc64
On 11/24/2014 02:56 PM, David Miller wrote: From: Jens Axboe ax...@kernel.dk Date: Mon, 24 Nov 2014 10:16:15 -0700 How about this one? The num in num_possible_cpus() means a count, as in how many are there. It doesn't mean largest ID of members of set X, which is what you are asking for. Even worse, having num_online_cpus() and num_possible_cpus() count from a different perspective is really confusing. Not disagreeing with you... Personally I don't care too much, I can just work-around this in blk-mq. I'm more worried about others reimplementing the same bugs later. And yes, the fact that's it's the weight of the bitmap is exactly the problem, as we have no good way of saying allocate me this array indexed by cpu count, since we don't know the numbers of the CPUs. This isn't a problem on x86 (or on anything but sparc64, as far as I'm aware), since the weight and highest CPU count are one and the same. Usually when people want a per-cpu thing they allocate percpu memory which hides all of these details, why don't you allocate the map as dynamic per-cpu memory? It will also do the NUMA node local allocations for you as well. The allocation is node affine currently. This isn't per-cpu storage, for the per-cpu storage blk-mq uses the normal per-cpu primitives for alloctions. It's just a small array mapping a cpu number to a hardware queue number. It's read-only storage, after it has been updated. I'll just updated blk-mq to use nr_cpu_ids and be done with it. -- Jens Axboe -- 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: Another (ESP?) scsi blk-mq problem on sparc64
From: Jens Axboe ax...@kernel.dk Date: Mon, 24 Nov 2014 15:01:55 -0700 I'll just updated blk-mq to use nr_cpu_ids and be done with it. Wow, a grep on nr_cpu_ids gets a lot of hits on people allocating just these kinds of tables :) -- 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: Another (ESP?) scsi blk-mq problem on sparc64
On 11/24/2014 03:09 PM, David Miller wrote: From: Jens Axboe ax...@kernel.dk Date: Mon, 24 Nov 2014 15:01:55 -0700 I'll just updated blk-mq to use nr_cpu_ids and be done with it. Wow, a grep on nr_cpu_ids gets a lot of hits on people allocating just these kinds of tables :) Yep! It'd be nicer to export a helper for that, I bet it's just one of those things that people started using because it's there and there are no functions for getting this information. -- Jens Axboe -- 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: Another (ESP?) scsi blk-mq problem on sparc64
Yes, that does look like the case. Do you have a good trick on how to allocate a map for the highest possible cpu number without first iterating the cpu map? I couldn't find something that looks like a highest_possible_cpu() helper. Honestly I think that num_posible_cpus() should return the max of number of CPUs (weigt), and the highest numbered CPU. It's a pain in the butt to handle this otherwise. Hear, hear!!! That would make my life easier, and would make this sort of problem much less likely to occur! How about this one? It make the machine work. -- Meelis Roos (mr...@linux.ee) -- 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 3/3] wd719x: Add firmware documentation
Add documentation and script to obtain required firmware. Signed-off-by: Ondrej Zary li...@rainbow-software.org --- Documentation/scsi/wd719x.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/scsi/wd719x.txt diff --git a/Documentation/scsi/wd719x.txt b/Documentation/scsi/wd719x.txt new file mode 100644 index 000..0816b02 --- /dev/null +++ b/Documentation/scsi/wd719x.txt @@ -0,0 +1,21 @@ +Driver for Western Digital WD7193, WD7197 and WD7296 SCSI cards +--- + +The card requires firmware that can be cut out of the Windows NT driver that +can be downloaded from WD at: +http://support.wdc.com/product/download.asp?groupid=801sid=27lang=en + +There is no license anywhere in the file or on the page - so the firmware +probably cannot be added to linux-firmware. + +This script downloads and extracts the firmware, creating wd719x-risc.bin and +d719x-wcs.bin files. Put them in /lib/firmware/. + +#!/bin/sh +wget http://support.wdc.com/download/archive/pciscsi.exe +lha xi pciscsi.exe pci-scsi.exe +lha xi pci-scsi.exe nt/wd7296a.sys +rm pci-scsi.exe +dd if=wd7296a.sys of=wd719x-risc.bin bs=1 skip=5760 count=14336 +dd if=wd7296a.sys of=wd719x-wcs.bin bs=1 skip=20096 count=514 +rm wd7296a.sys -- Ondrej Zary -- 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 v2 0/3] wd719x: Introduce Western Digital WD7193/7197/7296 PCI SCSI card driver
Hello, this is a new driver for Western Digital WD7193, WD7197 and WD7296 PCI SCSI controllers based on WD33C296A chip. These nice cards never worked good with Linux. It's based on old and ugly wd719x driver written back in 2.0 days, then hacked to 2.2 and finally to 2.4 kernels. Most of the code is rewritten: from ~4100 lines to ~1200. I've tested the driver on a WD7193 card with some hard drives and CD-ROMs: QUANTUM LP240S GM240S01X 4.6 IBM 0663L12 e g IBM DORS-32160 WA0A SONY CD-ROM CDU-55S 1.0t SONY CD-ROM CDU-415 1.1g The card supports TCQ and linked commands (for cmd_per_lun 1?) but I don't know how it should be implemented in a driver. Device/bus/host resets seem to work fine when tested by sg_reset. But don't know how to test command abort. The card requires firmware that can be cut out of the Windows NT driver that can be downloaded from WD at: http://support.wdc.com/product/download.asp?groupid=801sid=27lang=en There is no license anywhere in the file or on the page - so I guess that the firmware cannot be added to linux-firmware. This script that downloads and extracts the firmware is in Documentation/ -- Ondrej Zary -- 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 1/3] eeprom-93cx6: Add (read-only) support for 8-bit mode
Add read-only support for EEPROMs configured in 8-bit mode (ORG pin connected
to GND).
This will be used by wd719x driver.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Reviewed-by: Hannes Reinecke h...@suse.de
---
drivers/misc/eeprom/eeprom_93cx6.c | 62 +++-
include/linux/eeprom_93cx6.h |4 +++
2 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/eeprom/eeprom_93cx6.c
b/drivers/misc/eeprom/eeprom_93cx6.c
index 0ff4b02..0cf2c9d 100644
--- a/drivers/misc/eeprom/eeprom_93cx6.c
+++ b/drivers/misc/eeprom/eeprom_93cx6.c
@@ -170,7 +170,7 @@ static void eeprom_93cx6_read_bits(struct eeprom_93cx6
*eeprom,
}
/**
- * eeprom_93cx6_read - Read multiple words from eeprom
+ * eeprom_93cx6_read - Read a word from eeprom
* @eeprom: Pointer to eeprom structure
* @word: Word index from where we should start reading
* @data: target pointer where the information will have to be stored
@@ -235,6 +235,66 @@ void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom,
const u8 word,
EXPORT_SYMBOL_GPL(eeprom_93cx6_multiread);
/**
+ * eeprom_93cx6_readb - Read a byte from eeprom
+ * @eeprom: Pointer to eeprom structure
+ * @word: Byte index from where we should start reading
+ * @data: target pointer where the information will have to be stored
+ *
+ * This function will read a byte of the eeprom data
+ * into the given data pointer.
+ */
+void eeprom_93cx6_readb(struct eeprom_93cx6 *eeprom, const u8 byte,
+ u8 *data)
+{
+ u16 command;
+ u16 tmp;
+
+ /*
+* Initialize the eeprom register
+*/
+ eeprom_93cx6_startup(eeprom);
+
+ /*
+* Select the read opcode and the byte to be read.
+*/
+ command = (PCI_EEPROM_READ_OPCODE (eeprom-width + 1)) | byte;
+ eeprom_93cx6_write_bits(eeprom, command,
+ PCI_EEPROM_WIDTH_OPCODE + eeprom-width + 1);
+
+ /*
+* Read the requested 8 bits.
+*/
+ eeprom_93cx6_read_bits(eeprom, tmp, 8);
+ *data = tmp 0xff;
+
+ /*
+* Cleanup eeprom register.
+*/
+ eeprom_93cx6_cleanup(eeprom);
+}
+EXPORT_SYMBOL_GPL(eeprom_93cx6_readb);
+
+/**
+ * eeprom_93cx6_multireadb - Read multiple bytes from eeprom
+ * @eeprom: Pointer to eeprom structure
+ * @byte: Index from where we should start reading
+ * @data: target pointer where the information will have to be stored
+ * @words: Number of bytes that should be read.
+ *
+ * This function will read all requested bytes from the eeprom,
+ * this is done by calling eeprom_93cx6_readb() multiple times.
+ */
+void eeprom_93cx6_multireadb(struct eeprom_93cx6 *eeprom, const u8 byte,
+ u8 *data, const u16 bytes)
+{
+ unsigned int i;
+
+ for (i = 0; i bytes; i++)
+ eeprom_93cx6_readb(eeprom, byte + i, data[i]);
+}
+EXPORT_SYMBOL_GPL(eeprom_93cx6_multireadb);
+
+/**
* eeprom_93cx6_wren - set the write enable state
* @eeprom: Pointer to eeprom structure
* @enable: true to enable writes, otherwise disable writes
diff --git a/include/linux/eeprom_93cx6.h b/include/linux/eeprom_93cx6.h
index e50f98b..eb0b198 100644
--- a/include/linux/eeprom_93cx6.h
+++ b/include/linux/eeprom_93cx6.h
@@ -75,6 +75,10 @@ extern void eeprom_93cx6_read(struct eeprom_93cx6 *eeprom,
const u8 word, u16 *data);
extern void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom,
const u8 word, __le16 *data, const u16 words);
+extern void eeprom_93cx6_readb(struct eeprom_93cx6 *eeprom,
+ const u8 byte, u8 *data);
+extern void eeprom_93cx6_multireadb(struct eeprom_93cx6 *eeprom,
+ const u8 byte, u8 *data, const u16 bytes);
extern void eeprom_93cx6_wren(struct eeprom_93cx6 *eeprom, bool enable);
--
Ondrej Zary
--
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] wd719x: Introduce Western Digital WD7193/7197/7296 PCI SCSI card driver
Introduce wd719x, a driver for Western Digital WD7193, WD7197 and WD7296 PCI
SCSI controllers based on WD33C296A chip.
Tested with WD7193 card.
Reviewed-by: Christoph Hellwig h...@lst.de
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/scsi/Kconfig |8 +
drivers/scsi/Makefile |1 +
drivers/scsi/wd719x.c | 997 +
drivers/scsi/wd719x.h | 249
4 files changed, 1255 insertions(+)
create mode 100644 drivers/scsi/wd719x.c
create mode 100644 drivers/scsi/wd719x.h
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 3a820f6..fd81d14 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1451,6 +1451,14 @@ config SCSI_NSP32
To compile this driver as a module, choose M here: the
module will be called nsp32.
+config SCSI_WD719X
+ tristate Western Digital WD7193/7197/7296 support
+ depends on PCI SCSI
+ select EEPROM_93CX6
+ ---help---
+ This is a driver for Western Digital WD7193, WD7197 and WD7296 PCI
+ SCSI controllers (based on WD33C296A chip).
+
config SCSI_DEBUG
tristate SCSI debugging host simulator
depends on SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 59f1ce6..d8bfca5 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -143,6 +143,7 @@ obj-$(CONFIG_SCSI_VIRTIO) += virtio_scsi.o
obj-$(CONFIG_VMWARE_PVSCSI)+= vmw_pvscsi.o
obj-$(CONFIG_XEN_SCSI_FRONTEND)+= xen-scsifront.o
obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o
+obj-$(CONFIG_SCSI_WD719X) += wd719x.o
obj-$(CONFIG_ARM) += arm/
diff --git a/drivers/scsi/wd719x.c b/drivers/scsi/wd719x.c
new file mode 100644
index 000..23bb5a3
--- /dev/null
+++ b/drivers/scsi/wd719x.c
@@ -0,0 +1,997 @@
+/*
+ * Driver for Western Digital WD7193, WD7197 and WD7296 SCSI cards
+ * Copyright 2013 Ondrej Zary
+ *
+ * Original driver by
+ * Aaron Dewell dew...@woods.net
+ * Gaerti juergen.gaert...@mbox.si.uni-hannover.de
+ *
+ * HW documentation available in book:
+ *
+ * SPIDER Command Protocol
+ * by Chandru M. Sippy
+ * SCSI Storage Products (MCP)
+ * Western Digital Corporation
+ * 09-15-95
+ *
+ *
http://web.archive.org/web/20070717175254/http://sun1.rrzn.uni-hannover.de/gaertner.juergen/wd719x/Linux/Docu/Spider/
+ */
+
+/*
+ * Driver workflow:
+ * 1. SCSI command is transformed to SCB (Spider Control Block) by the
+ *queuecommand function.
+ * 2. The address of the SCB is stored in a list to be able to access it, if
+ *something goes wrong.
+ * 3. The address of the SCB is written to the Controller, which loads the SCB
+ *via BM-DMA and processes it.
+ * 4. After it has finished, it generates an interrupt, and sets registers.
+ *
+ * flaws:
+ * - abort/reset functions
+ *
+ * ToDo:
+ * - tagged queueing
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/pci.h
+#include linux/firmware.h
+#include linux/eeprom_93cx6.h
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_device.h
+#include scsi/scsi_host.h
+#include wd719x.h
+
+/* low-level register access */
+static inline u8 wd719x_readb(struct wd719x *wd, u8 reg)
+{
+ return ioread8(wd-base + reg);
+}
+
+static inline u32 wd719x_readl(struct wd719x *wd, u8 reg)
+{
+ return ioread32(wd-base + reg);
+}
+
+static inline void wd719x_writeb(struct wd719x *wd, u8 reg, u8 val)
+{
+ iowrite8(val, wd-base + reg);
+}
+
+static inline void wd719x_writew(struct wd719x *wd, u8 reg, u16 val)
+{
+ iowrite16(val, wd-base + reg);
+}
+
+static inline void wd719x_writel(struct wd719x *wd, u8 reg, u32 val)
+{
+ iowrite32(val, wd-base + reg);
+}
+
+/* wait until the command register is ready */
+static inline int wd719x_wait_ready(struct wd719x *wd)
+{
+ int i = 0;
+
+ do {
+ if (wd719x_readb(wd, WD719X_AMR_COMMAND) == WD719X_CMD_READY)
+ return 0;
+ udelay(1);
+ } while (i++ WD719X_WAIT_FOR_CMD_READY);
+
+ dev_err(wd-pdev-dev, command register is not ready: 0x%02x\n,
+ wd719x_readb(wd, WD719X_AMR_COMMAND));
+
+ return -ETIMEDOUT;
+}
+
+/* poll interrupt status register until command finishes */
+static inline int wd719x_wait_done(struct wd719x *wd, int timeout)
+{
+ u8 status;
+
+ while (timeout 0) {
+ status = wd719x_readb(wd, WD719X_AMR_INT_STATUS);
+ if (status)
+ break;
+ timeout--;
+ udelay(1);
+ }
+
+ if (timeout = 0) {
+ dev_err(wd-pdev-dev, direct command timed out\n);
+ return -ETIMEDOUT;
+ }
+
+ if (status != WD719X_INT_NOERRORS) {
+ dev_err(wd-pdev-dev, direct command failed, status 0x%02x,
SUE 0x%02x\n,
+ status, wd719x_readb(wd, WD719X_AMR_SCB_ERROR));
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int
Re: Another (ESP?) scsi blk-mq problem on sparc64
From: mr...@linux.ee Date: Tue, 25 Nov 2014 00:23:20 +0200 (EET) Yes, that does look like the case. Do you have a good trick on how to allocate a map for the highest possible cpu number without first iterating the cpu map? I couldn't find something that looks like a highest_possible_cpu() helper. Honestly I think that num_posible_cpus() should return the max of number of CPUs (weigt), and the highest numbered CPU. It's a pain in the butt to handle this otherwise. Hear, hear!!! That would make my life easier, and would make this sort of problem much less likely to occur! How about this one? It make the machine work. Thanks for testing! -- 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 net-next] cxgb4/cxgb4vf/csiostor: Add T4/T5 PCI ID Table
Add a new file t4_pci_id_tbl.h that contains T4/T5 PCI ID Table so that for all
drivers that uses T4/T5 PCI functions changes can be done in one place.
checkpatch.pl script reports following error, which if tried to fix ends up in
compilation error.
ERROR: Macros with complex values should be enclosed in parentheses
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \
+ { 0, } \
+ }
WARNING: added, moved or deleted file(s), does MAINTAINERS need
updating?
new file mode 100644
ERROR: Macros with complex values should be enclosed in parentheses
+#define CH_PCI_ID_TABLE_FENTRY(devid) \
+ CH_PCI_ID_TABLE_ENTRY((devid) | \
+ ((CH_PCI_DEVICE_ID_FUNCTION) 8)), \
+ CH_PCI_ID_TABLE_ENTRY((devid) | \
+ ((CH_PCI_DEVICE_ID_FUNCTION2) 8))
ERROR: Macros with complex values should be enclosed in parentheses
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { 0, } }
ERROR: Macros with complex values should be enclosed in parentheses
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { 0, } }
Signed-off-by: Hariprasad Shenai haripra...@chelsio.com
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 125 +++-
drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 160
.../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c| 73 ++
drivers/scsi/csiostor/csio_hw_chip.h | 49 +--
drivers/scsi/csiostor/csio_init.c | 64 +++--
5 files changed, 209 insertions(+), 262 deletions(-)
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index a576da1..3aea82b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -210,114 +210,25 @@ struct filter_entry {
NETIF_MSG_TIMER | NETIF_MSG_IFDOWN | NETIF_MSG_IFUP |\
NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
-#define CH_DEVICE(devid, data) { PCI_VDEVICE(CHELSIO, devid), (data) }
-
-static const struct pci_device_id cxgb4_pci_tbl[] = {
- CH_DEVICE(0xa000, 0), /* PE10K */
- CH_DEVICE(0x4001, -1),
- CH_DEVICE(0x4002, -1),
- CH_DEVICE(0x4003, -1),
- CH_DEVICE(0x4004, -1),
- CH_DEVICE(0x4005, -1),
- CH_DEVICE(0x4006, -1),
- CH_DEVICE(0x4007, -1),
- CH_DEVICE(0x4008, -1),
- CH_DEVICE(0x4009, -1),
- CH_DEVICE(0x400a, -1),
- CH_DEVICE(0x400d, -1),
- CH_DEVICE(0x400e, -1),
- CH_DEVICE(0x4080, -1),
- CH_DEVICE(0x4081, -1),
- CH_DEVICE(0x4082, -1),
- CH_DEVICE(0x4083, -1),
- CH_DEVICE(0x4084, -1),
- CH_DEVICE(0x4085, -1),
- CH_DEVICE(0x4086, -1),
- CH_DEVICE(0x4087, -1),
- CH_DEVICE(0x4088, -1),
- CH_DEVICE(0x4401, 4),
- CH_DEVICE(0x4402, 4),
- CH_DEVICE(0x4403, 4),
- CH_DEVICE(0x4404, 4),
- CH_DEVICE(0x4405, 4),
- CH_DEVICE(0x4406, 4),
- CH_DEVICE(0x4407, 4),
- CH_DEVICE(0x4408, 4),
- CH_DEVICE(0x4409, 4),
- CH_DEVICE(0x440a, 4),
- CH_DEVICE(0x440d, 4),
- CH_DEVICE(0x440e, 4),
- CH_DEVICE(0x4480, 4),
- CH_DEVICE(0x4481, 4),
- CH_DEVICE(0x4482, 4),
- CH_DEVICE(0x4483, 4),
- CH_DEVICE(0x4484, 4),
- CH_DEVICE(0x4485, 4),
- CH_DEVICE(0x4486, 4),
- CH_DEVICE(0x4487, 4),
- CH_DEVICE(0x4488, 4),
- CH_DEVICE(0x5001, 4),
- CH_DEVICE(0x5002, 4),
- CH_DEVICE(0x5003, 4),
- CH_DEVICE(0x5004, 4),
- CH_DEVICE(0x5005, 4),
- CH_DEVICE(0x5006, 4),
- CH_DEVICE(0x5007, 4),
- CH_DEVICE(0x5008, 4),
- CH_DEVICE(0x5009, 4),
- CH_DEVICE(0x500A, 4),
- CH_DEVICE(0x500B, 4),
- CH_DEVICE(0x500C, 4),
- CH_DEVICE(0x500D, 4),
- CH_DEVICE(0x500E, 4),
- CH_DEVICE(0x500F, 4),
- CH_DEVICE(0x5010, 4),
- CH_DEVICE(0x5011, 4),
- CH_DEVICE(0x5012, 4),
- CH_DEVICE(0x5013, 4),
- CH_DEVICE(0x5014, 4),
- CH_DEVICE(0x5015, 4),
- CH_DEVICE(0x5080, 4),
- CH_DEVICE(0x5081, 4),
- CH_DEVICE(0x5082, 4),
- CH_DEVICE(0x5083, 4),
- CH_DEVICE(0x5084, 4),
- CH_DEVICE(0x5085, 4),
- CH_DEVICE(0x5086, 4),
- CH_DEVICE(0x5087, 4),
- CH_DEVICE(0x5088, 4),
- CH_DEVICE(0x5401, 4),
- CH_DEVICE(0x5402, 4),
- CH_DEVICE(0x5403, 4),
- CH_DEVICE(0x5404, 4),
- CH_DEVICE(0x5405, 4),
- CH_DEVICE(0x5406, 4),
- CH_DEVICE(0x5407, 4),
- CH_DEVICE(0x5408, 4),
- CH_DEVICE(0x5409, 4),
- CH_DEVICE(0x540A, 4),
- CH_DEVICE(0x540B, 4),
- CH_DEVICE(0x540C, 4),
- CH_DEVICE(0x540D, 4),
- CH_DEVICE(0x540E, 4),
- CH_DEVICE(0x540F, 4),
-
[PATCH v2 0/5] scsi_debug: switch to table based parser
This series of patches is in response to Hannes' comments earlier today. He wanted the single large patch broken up. Changes since v1: - break single big patch into 4 smaller ones and one less large - resync with drivers-for-3.19 Patches: [PATCH v2 1/5] pinpoint invalid field in sense data [PATCH v2 2/5] append inject error flags onto scsi_cmnd object [PATCH v2 3/5] add Capacity Changed Unit Attention [PATCH v2 4/5] change SCSI command parser to table driven [PATCH v2 5/5] Add Report supported opcodes+tmfs; Compare and write Todo: - re-order teardown in scsi_debug_exit() - make sdebug_dev_info::stopped atomic (add to end of uas_bm ?) - review Rob Elliott's suggestions; look at speed ups - remove host_lock logic and make the host_lock option a dummy - update some mode page and VPD data to reflect more recent devices - changing remaining and byte handling over to get/put_unaligned_be*() - set INFO field for COMPARE AND WRITE command MISCOMPAREs Hannes also asked that XDWRITEREAD_10 be added to scsi.h . It has been there for a while. I guess he meant something else. Signed-off-by: Douglas Gilbert dgilb...@interlog.com -- 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 v2 1/5] scsi_debug: pinpoint invalid field in sense data
Use Sense Key Specific field in the sense data of an ILLEGAL REQUEST
to optionally pinpoint the location of the problem field. This may
be either in the cdb or the associated parameter list.
---
drivers/scsi/scsi_debug.c | 138 +-
1 file changed, 88 insertions(+), 50 deletions(-)
Signed-off-by: Douglas Gilbert dgilb...@interlog.com
From e3cded06f31aa46a889664c1ea7df7b8b9b998e7 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert dgilb...@interlog.com
Date: Mon, 24 Nov 2014 20:08:11 -0500
Subject: [PATCH 1/5] pinpoint invalid field in sense data
Use Sense Key Specific field in the sense data of an ILLEGAL REQUEST
to optionally pinpoint the location of the problem field. This may
be either in the cdb or the associated parameter list.
---
drivers/scsi/scsi_debug.c | 138 +-
1 file changed, 88 insertions(+), 50 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index ce71b6d..a1bca60 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -63,31 +63,34 @@
#include sd.h
#include scsi_logging.h
-#define SCSI_DEBUG_VERSION 1.84
-static const char *scsi_debug_version_date = 20140706;
+#define SCSI_DEBUG_VERSION 1.85
+static const char *scsi_debug_version_date = 20141022;
#define MY_NAME scsi_debug
/* Additional Sense Code (ASC) */
#define NO_ADDITIONAL_SENSE 0x0
#define LOGICAL_UNIT_NOT_READY 0x4
-#define LOGICAL_UNIT_COMMUNICATION_FAILURE 0x8
#define UNRECOVERED_READ_ERR 0x11
#define PARAMETER_LIST_LENGTH_ERR 0x1a
#define INVALID_OPCODE 0x20
-#define ADDR_OUT_OF_RANGE 0x21
#define INVALID_COMMAND_OPCODE 0x20
+#define LBA_OUT_OF_RANGE 0x21
#define INVALID_FIELD_IN_CDB 0x24
#define INVALID_FIELD_IN_PARAM_LIST 0x26
#define UA_RESET_ASC 0x29
#define UA_CHANGED_ASC 0x2a
+#define INSUFF_RES_ASC 0x55
+#define INSUFF_RES_ASCQ 0x3
#define POWER_ON_RESET_ASCQ 0x0
#define BUS_RESET_ASCQ 0x2 /* scsi bus reset occurred */
#define MODE_CHANGED_ASCQ 0x1 /* mode parameters changed */
+#define CAPACITY_CHANGED_ASCQ 0x9
#define SAVING_PARAMS_UNSUP 0x39
#define TRANSPORT_PROBLEM 0x4b
#define THRESHOLD_EXCEEDED 0x5d
#define LOW_POWER_COND_ON 0x5e
+#define MISCOMPARE_VERIFY_ASC 0x1d
/* Additional Sense Code Qualifier (ASCQ) */
#define ACK_NAK_TO 0x3
@@ -394,6 +397,50 @@ static void sdebug_max_tgts_luns(void)
spin_unlock(sdebug_host_list_lock);
}
+enum sdeb_cmd_data {SDEB_IN_DATA = 0, SDEB_IN_CDB = 1};
+
+/* Set in_bit to -1 to indicate no bit position of invalid field */
+static void
+mk_sense_invalid_fld(struct scsi_cmnd *scp, enum sdeb_cmd_data c_d,
+ int in_byte, int in_bit)
+{
+ unsigned char *sbuff;
+ u8 sks[4];
+ int sl, asc;
+
+ sbuff = scp-sense_buffer;
+ if (!sbuff) {
+ sdev_printk(KERN_ERR, scp-device,
+ %s: sense_buffer is NULL\n, __func__);
+ return;
+ }
+ asc = c_d ? INVALID_FIELD_IN_CDB : INVALID_FIELD_IN_PARAM_LIST;
+ memset(sbuff, 0, SCSI_SENSE_BUFFERSIZE);
+ scsi_build_sense_buffer(scsi_debug_dsense, sbuff, ILLEGAL_REQUEST,
+asc, 0);
+ memset(sks, 0, sizeof(sks));
+ sks[0] = 0x80;
+ if (c_d)
+ sks[0] |= 0x40;
+ if (in_bit = 0) {
+ sks[0] |= 0x8;
+ sks[0] |= 0x7 in_bit;
+ }
+ put_unaligned_be16(in_byte, sks + 1);
+ if (scsi_debug_dsense) {
+ sl = sbuff[7] + 8;
+ sbuff[7] = sl;
+ sbuff[sl] = 0x2;
+ sbuff[sl + 1] = 0x6;
+ memcpy(sbuff + sl + 4, sks, 3);
+ } else
+ memcpy(sbuff + 15, sks, 3);
+ if (SCSI_DEBUG_OPT_NOISE scsi_debug_opts)
+ sdev_printk(KERN_INFO, scp-device, %s: [sense_key,asc,ascq
+ ]: [0x5,0x%x,0x0] %c byte=%d, bit=%d\n,
+ my_name, asc, c_d ? 'C' : 'D', in_byte, in_bit);
+}
+
static void mk_sense_buffer(struct scsi_cmnd *scp, int key, int asc, int asq)
{
unsigned char *sbuff;
@@ -414,6 +461,12 @@ static void mk_sense_buffer(struct scsi_cmnd *scp, int key, int asc, int asq)
my_name, key, asc, asq);
}
+static void
+mk_sense_invalid_opcode(struct scsi_cmnd *scp)
+{
+ mk_sense_buffer(scp, ILLEGAL_REQUEST, INVALID_OPCODE, 0);
+}
+
static void get_data_transfer_info(unsigned char *cmd,
unsigned long long *lba, unsigned int *num,
u32 *ei_lba)
@@ -944,8 +997,7 @@ static int resp_inquiry(struct scsi_cmnd *scp, int target,
pq_pdt = (scsi_debug_ptype 0x1f);
arr[0] = pq_pdt;
if (0x2 cmd[1]) { /* CMDDT bit set */
- mk_sense_buffer(scp, ILLEGAL_REQUEST, INVALID_FIELD_IN_CDB,
- 0);
+ mk_sense_invalid_fld(scp, SDEB_IN_CDB, 1, 1);
kfree(arr);
return check_condition_result;
} else if (0x1 cmd[1]) { /* EVPD bit set */
@@ -1029,9 +1081,7 @@ static int resp_inquiry(struct scsi_cmnd *scp, int target,
arr[1] = cmd[2];/*sanity */
arr[3] = inquiry_evpd_b2(arr[4]);
} else {
- /* Illegal request, invalid field in cdb */
- mk_sense_buffer(scp, ILLEGAL_REQUEST,
- INVALID_FIELD_IN_CDB, 0);
+ mk_sense_invalid_fld(scp, SDEB_IN_CDB, 2, -1);
kfree(arr);
return check_condition_result;
}
@@ -1123,8 +1173,7 @@ static int
[PATCH v2 5/5] scsi_debug: Add Report supported opcodes+tmfs; Compare and write
From: Douglas Gilbert dgilb...@interlog.com
Date: Mon, 24 Nov 2014 21:27:12 -0500
Subject: [PATCH 5/5] Add Report supported opcodes+tmfs; Compare and write
The Report supported operation codes command is very closely integrated
into the table driven parser and very useful for testing it. Its cdb
masks form the basis of the 'strict' parameter's checks. The Report
supported TMFs command is a simple extension. The Compare and write
command may even be useful, as it should be atomic due to the read-write
lock that the driver uses on its backing store (ram).
---
drivers/scsi/scsi_debug.c | 326 +++---
1 file changed, 307 insertions(+), 19 deletions(-)
Signed-off-by: Douglas Gilbert dgilb...@interlog.com
From aacd419f11adb4601a45fe17bef4314e0c261610 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert dgilb...@interlog.com
Date: Mon, 24 Nov 2014 21:27:12 -0500
Subject: [PATCH 5/5] Add Report supported opcodes+tmfs; Compare and write
The Report supported operation codes command is very closely integrated
into the table driven parser and very useful for testing it. Its cdb
masks form the basis of the 'strict' parameter's checks. The Report
supported TMFs command is a simple extension. The Compare and write
command may even be useful, as it should be atomic due to the read-write
lock that the driver uses on its backing store (ram).
---
drivers/scsi/scsi_debug.c | 326 +++---
1 file changed, 307 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 58e6040..cc2b382 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -307,7 +307,6 @@ static const unsigned char opcode_ind_arr[256] = {
#define FF_SA (F_SA_HIGH | F_SA_LOW)
struct sdebug_dev_info;
-static int scsi_debug_queuecommand(struct scsi_cmnd *scp);
static int resp_inquiry(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_report_luns(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_requests(struct scsi_cmnd *, struct sdebug_dev_info *);
@@ -322,9 +321,12 @@ static int resp_readcap16(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_get_lba_status(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_report_tgtpgs(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_unmap(struct scsi_cmnd *, struct sdebug_dev_info *);
+static int resp_rsup_opcodes(struct scsi_cmnd *, struct sdebug_dev_info *);
+static int resp_rsup_tmfs(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_write_same_10(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_write_same_16(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_xdwriteread_10(struct scsi_cmnd *, struct sdebug_dev_info *);
+static int resp_comp_write(struct scsi_cmnd *, struct sdebug_dev_info *);
struct opcode_info_t {
u8 num_attached; /* 0 if this is it (i.e. a leaf); use 0xff
@@ -383,10 +385,10 @@ static const struct opcode_info_t vl_iarr[1] = { /* VARIABLE LENGTH */
};
static const struct opcode_info_t maint_in_iarr[2] = {
- {0, 0xa3, 0xc, F_SA_LOW | F_D_IN, NULL, NULL,
+ {0, 0xa3, 0xc, F_SA_LOW | F_D_IN, resp_rsup_opcodes, NULL,
{12, 0xc, 0x87, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0,
0xc7, 0, 0, 0, 0} },
- {0, 0xa3, 0xd, F_SA_LOW | F_D_IN, NULL, NULL,
+ {0, 0xa3, 0xd, F_SA_LOW | F_D_IN, resp_rsup_tmfs, NULL,
{12, 0xd, 0x80, 0, 0, 0, 0xff, 0xff, 0xff, 0xff, 0, 0xc7, 0, 0,
0, 0} },
};
@@ -487,7 +489,7 @@ static const struct opcode_info_t opcode_info_arr[SDEB_I_LAST_ELEMENT + 1] = {
{0, 0x35, 0, F_DELAY_OVERR | FF_DIRECT_IO, NULL, NULL, /* SYNC_CACHE */
{10, 0x7, 0xff, 0xff, 0xff, 0xff, 0x1f, 0xff, 0xff, 0xc7, 0, 0,
0, 0, 0, 0} },
- {0, 0x89, 0, F_D_OUT | FF_DIRECT_IO, NULL, NULL,
+ {0, 0x89, 0, F_D_OUT | FF_DIRECT_IO, resp_comp_write, NULL,
{16, 0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0, 0,
0, 0xff, 0x1f, 0xc7} }, /* COMPARE AND WRITE */
@@ -1603,6 +1605,184 @@ static int resp_report_tgtpgs(struct scsi_cmnd * scp,
return ret;
}
+static int
+resp_rsup_opcodes(struct scsi_cmnd *scp, struct sdebug_dev_info *devip)
+{
+ bool rctd;
+ u8 reporting_opts, req_opcode, sdeb_i, supp;
+ u16 req_sa, u;
+ u32 alloc_len, a_len;
+ int k, offset, len, errsts, count, bump, na;
+ const struct opcode_info_t *oip;
+ const struct opcode_info_t *r_oip;
+ u8 *arr;
+ u8 *cmd = scp-cmnd;
+
+ rctd = !!(cmd[2] 0x80);
+ reporting_opts = cmd[2] 0x7;
+ req_opcode = cmd[3];
+ req_sa = get_unaligned_be16(cmd + 4);
+ alloc_len = get_unaligned_be32(cmd + 6);
+ if (alloc_len 4 alloc_len 0x) {
+ mk_sense_invalid_fld(scp, SDEB_IN_CDB, 6, -1);
+ return check_condition_result;
+ }
+ if (alloc_len 8192)
+ a_len = 8192;
+ else
+ a_len = alloc_len;
+ arr = kzalloc((a_len 256) ? 320 : a_len + 64, GFP_KERNEL);
+ if (NULL == arr) {
+ mk_sense_buffer(scp, ILLEGAL_REQUEST, INSUFF_RES_ASC,
+
[PATCH v2 4/5] scsi_debug: change SCSI command parser to table driven
From: Douglas Gilbert dgilb...@interlog.com
Date: Mon, 24 Nov 2014 20:46:29 -0500
Subject: [PATCH 4/5] change SCSI command parser to table driven
The existing 'big switch' parser in queuecommand() is changed to
a table driven parser. The old and new queuecommand() were moved
in the source so diff would not shuffle them. Apart from the new
tables most other changes are refactoring existing response code
to be more easily called out of the table parser. The 'strict'
parameter is added so that cdb_s can be checked for non-zero
values in parts of the cdb that are reserved. Some other changes
include: tweak request sense response when D_SENSE differs; support
NDOB in Write Same(16); and fix crash in Get LBA Status when LBP
was inactive.
---
drivers/scsi/scsi_debug.c | 1391 +++--
1 file changed, 833 insertions(+), 558 deletions(-)
Signed-off-by: Douglas Gilbert dgilb...@interlog.com
From 040f9c4c79663d2fa37ceeed03cfb19e445e17f1 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert dgilb...@interlog.com
Date: Mon, 24 Nov 2014 20:46:29 -0500
Subject: [PATCH 4/5] change SCSI command parser to table driven
The existing 'big switch' parser in queuecommand() is changed to
a table driven parser. The old and new queuecommand() were moved
in the source so diff would not shuffle them. Apart from the new
tables most other changes are refactoring existing response code
to be more easily called out of the table parser. The 'strict'
parameter is added so that cdb_s can be checked for non-zero
values in parts of the cdb that are reserved. Some other changes
include: tweak request sense response when D_SENSE differs; support
NDOB in Write Same(16); and fix crash in Get LBA Status when LBP
was inactive.
---
drivers/scsi/scsi_debug.c | 1391 +++--
1 file changed, 833 insertions(+), 558 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index ee99aca..58e6040 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -71,10 +71,10 @@ static const char *scsi_debug_version_date = 20141022;
/* Additional Sense Code (ASC) */
#define NO_ADDITIONAL_SENSE 0x0
#define LOGICAL_UNIT_NOT_READY 0x4
+#define LOGICAL_UNIT_COMMUNICATION_FAILURE 0x8
#define UNRECOVERED_READ_ERR 0x11
#define PARAMETER_LIST_LENGTH_ERR 0x1a
#define INVALID_OPCODE 0x20
-#define INVALID_COMMAND_OPCODE 0x20
#define LBA_OUT_OF_RANGE 0x21
#define INVALID_FIELD_IN_CDB 0x24
#define INVALID_FIELD_IN_PARAM_LIST 0x26
@@ -136,6 +136,7 @@ static const char *scsi_debug_version_date = 20141022;
#define DEF_VIRTUAL_GB 0
#define DEF_VPD_USE_HOSTNO 1
#define DEF_WRITESAME_LENGTH 0x
+#define DEF_STRICT 0
#define DELAY_OVERRIDDEN -
/* bit mask values for scsi_debug_opts */
@@ -183,8 +184,8 @@ static const char *scsi_debug_version_date = 20141022;
#define SDEBUG_NUM_UAS 4
/* for check_readiness() */
-#define UAS_ONLY 1
-#define UAS_TUR 0
+#define UAS_ONLY 1 /* check for UAs only */
+#define UAS_TUR 0 /* if no UAs then check if media access possible */
/* when 1==SCSI_DEBUG_OPT_MEDIUM_ERR, a medium error is simulated at this
* sector on read commands: */
@@ -210,6 +211,291 @@ static const char *scsi_debug_version_date = 20141022;
#warning Expect DEF_CMD_PER_LUN = SCSI_DEBUG_CANQUEUE
#endif
+/* SCSI opcodes (first byte of cdb) mapped onto these indexes */
+enum sdeb_opcode_index {
+ SDEB_I_INVALID_OPCODE = 0,
+ SDEB_I_INQUIRY = 1,
+ SDEB_I_REPORT_LUNS = 2,
+ SDEB_I_REQUEST_SENSE = 3,
+ SDEB_I_TEST_UNIT_READY = 4,
+ SDEB_I_MODE_SENSE = 5, /* 6, 10 */
+ SDEB_I_MODE_SELECT = 6, /* 6, 10 */
+ SDEB_I_LOG_SENSE = 7,
+ SDEB_I_READ_CAPACITY = 8, /* 10; 16 is in SA_IN(16) */
+ SDEB_I_READ = 9, /* 6, 10, 12, 16 */
+ SDEB_I_WRITE = 10, /* 6, 10, 12, 16 */
+ SDEB_I_START_STOP = 11,
+ SDEB_I_SERV_ACT_IN = 12, /* 12, 16 */
+ SDEB_I_SERV_ACT_OUT = 13, /* 12, 16 */
+ SDEB_I_MAINT_IN = 14,
+ SDEB_I_MAINT_OUT = 15,
+ SDEB_I_VERIFY = 16, /* 10 only */
+ SDEB_I_VARIABLE_LEN = 17,
+ SDEB_I_RESERVE = 18, /* 6, 10 */
+ SDEB_I_RELEASE = 19, /* 6, 10 */
+ SDEB_I_ALLOW_REMOVAL = 20, /* PREVENT ALLOW MEDIUM REMOVAL */
+ SDEB_I_REZERO_UNIT = 21, /* REWIND in SSC */
+ SDEB_I_ATA_PT = 22, /* 12, 16 */
+ SDEB_I_SEND_DIAG = 23,
+ SDEB_I_UNMAP = 24,
+ SDEB_I_XDWRITEREAD = 25, /* 10 only */
+ SDEB_I_WRITE_BUFFER = 26,
+ SDEB_I_WRITE_SAME = 27, /* 10, 16 */
+ SDEB_I_SYNC_CACHE = 28, /* 10 only */
+ SDEB_I_COMP_WRITE = 29,
+ SDEB_I_LAST_ELEMENT = 30, /* keep this last */
+};
+
+static const unsigned char opcode_ind_arr[256] = {
+/* 0x0; 0x0-0x1f: 6 byte cdbs */
+ SDEB_I_TEST_UNIT_READY, SDEB_I_REZERO_UNIT, 0, SDEB_I_REQUEST_SENSE,
+ 0, 0, 0, 0,
+ SDEB_I_READ, 0, SDEB_I_WRITE, 0, 0, 0, 0, 0,
+ 0, 0, SDEB_I_INQUIRY, 0, 0, SDEB_I_MODE_SELECT, SDEB_I_RESERVE,
+ SDEB_I_RELEASE,
+ 0, 0, SDEB_I_MODE_SENSE, SDEB_I_START_STOP, 0, SDEB_I_SEND_DIAG,
+ SDEB_I_ALLOW_REMOVAL, 0,
+/* 0x20; 0x20-0x3f: 10 byte cdbs */
+ 0, 0, 0, 0, 0, SDEB_I_READ_CAPACITY,
[PATCH v2 2/5] scsi_debug: append inject error flags onto scsi_cmnd object
From: Douglas Gilbert dgilb...@interlog.com
Date: Mon, 24 Nov 2014 20:18:02 -0500
Subject: [PATCH 2/5] append inject error flags onto scsi_cmnd object
The way the existing scsi_debug command parser associated various
inject error flags to a command was difficult to replicate in the
table driven parser. This patch adds infrastructure to append those
flags to the end of a scsi_cmnd object with the cmd_size host
template option.
---
drivers/scsi/scsi_debug.c | 68 +++
1 file changed, 68 insertions(+)
Signed-off-by: Douglas Gilbert dgilb...@interlog.com
From f951ae83459d893db05d8c1a0c98fb0eb5ef48fc Mon Sep 17 00:00:00 2001
From: Douglas Gilbert dgilb...@interlog.com
Date: Mon, 24 Nov 2014 20:18:02 -0500
Subject: [PATCH 2/5] append inject error flags onto scsi_cmnd object
The way the existing scsi_debug command parser associated various
inject error flags to a command was difficult to replicate in the
table driven parser. This patch adds infrastructure to append those
flags to the end of a scsi_cmnd object with the cmd_size host
template option.
---
drivers/scsi/scsi_debug.c | 68 +++
1 file changed, 68 insertions(+)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index a1bca60..d337eaa 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -209,6 +209,14 @@ static const char *scsi_debug_version_date = 20141022;
#warning Expect DEF_CMD_PER_LUN = SCSI_DEBUG_CANQUEUE
#endif
+struct sdebug_scmd_extra_t {
+ bool inj_recovered;
+ bool inj_transport;
+ bool inj_dif;
+ bool inj_dix;
+ bool inj_short;
+};
+
static int scsi_debug_add_host = DEF_NUM_HOST;
static int scsi_debug_ato = DEF_ATO;
static int scsi_debug_delay = DEF_DELAY;
@@ -248,6 +256,7 @@ static unsigned int scsi_debug_write_same_length = DEF_WRITESAME_LENGTH;
static bool scsi_debug_removable = DEF_REMOVABLE;
static bool scsi_debug_clustering;
static bool scsi_debug_host_lock = DEF_HOST_LOCK;
+static bool sdebug_any_injecting_opt;
static atomic_t sdebug_cmnd_count;
static atomic_t sdebug_completions;
@@ -3416,6 +3425,16 @@ static ssize_t opts_store(struct device_driver *ddp, const char *buf,
return -EINVAL;
opts_done:
scsi_debug_opts = opts;
+ if (SCSI_DEBUG_OPT_RECOVERED_ERR opts)
+ sdebug_any_injecting_opt = true;
+ else if (SCSI_DEBUG_OPT_TRANSPORT_ERR opts)
+ sdebug_any_injecting_opt = true;
+ else if (SCSI_DEBUG_OPT_DIF_ERR opts)
+ sdebug_any_injecting_opt = true;
+ else if (SCSI_DEBUG_OPT_DIX_ERR opts)
+ sdebug_any_injecting_opt = true;
+ else if (SCSI_DEBUG_OPT_SHORT_TRANSFER opts)
+ sdebug_any_injecting_opt = true;
atomic_set(sdebug_cmnd_count, 0);
atomic_set(sdebug_a_tsf, 0);
return count;
@@ -4563,6 +4582,41 @@ sdebug_change_qtype(struct scsi_device *sdev, int qtype)
return qtype;
}
+static int
+check_inject(struct scsi_cmnd *scp)
+{
+ struct sdebug_scmd_extra_t *ep = scsi_cmd_priv(scp);
+
+ memset(ep, 0, sizeof(struct sdebug_scmd_extra_t));
+
+ if (atomic_inc_return(sdebug_cmnd_count) =
+ abs(scsi_debug_every_nth)) {
+ atomic_set(sdebug_cmnd_count, 0);
+ if (scsi_debug_every_nth -1)
+ scsi_debug_every_nth = -1;
+ if (SCSI_DEBUG_OPT_TIMEOUT scsi_debug_opts)
+ return 1; /* ignore command causing timeout */
+ else if (SCSI_DEBUG_OPT_MAC_TIMEOUT scsi_debug_opts
+ scsi_medium_access_command(scp))
+ return 1; /* time out reads and writes */
+ if (sdebug_any_injecting_opt) {
+ int opts = scsi_debug_opts;
+
+ if (SCSI_DEBUG_OPT_RECOVERED_ERR opts)
+ep-inj_recovered = true;
+ else if (SCSI_DEBUG_OPT_TRANSPORT_ERR opts)
+ep-inj_transport = true;
+ else if (SCSI_DEBUG_OPT_DIF_ERR opts)
+ep-inj_dif = true;
+ else if (SCSI_DEBUG_OPT_DIX_ERR opts)
+ep-inj_dix = true;
+ else if (SCSI_DEBUG_OPT_SHORT_TRANSFER opts)
+ep-inj_short = true;
+ }
+ }
+ return 0;
+}
+
static struct scsi_host_template sdebug_driver_template = {
.show_info = scsi_debug_show_info,
.write_info = scsi_debug_write_info,
@@ -4589,11 +4643,13 @@ static struct scsi_host_template sdebug_driver_template = {
.use_clustering = DISABLE_CLUSTERING,
.module = THIS_MODULE,
.track_queue_depth = 1,
+ .cmd_size = sizeof(struct sdebug_scmd_extra_t),
};
static int sdebug_driver_probe(struct device * dev)
{
int error = 0;
+ int opts;
struct sdebug_host_info *sdbg_host;
struct Scsi_Host *hpnt;
int host_prot;
@@ -4662,6 +4718,18 @@ static int sdebug_driver_probe(struct device * dev)
else
scsi_host_set_guard(hpnt, SHOST_DIX_GUARD_CRC);
+ opts = scsi_debug_opts;
+ if (SCSI_DEBUG_OPT_RECOVERED_ERR opts)
+ sdebug_any_injecting_opt = true;
+ else if (SCSI_DEBUG_OPT_TRANSPORT_ERR opts)
+ sdebug_any_injecting_opt = true;
+ else if (SCSI_DEBUG_OPT_DIF_ERR opts)
+ sdebug_any_injecting_opt = true;
+ else if (SCSI_DEBUG_OPT_DIX_ERR opts)
+ sdebug_any_injecting_opt = true;
+ else if (SCSI_DEBUG_OPT_SHORT_TRANSFER opts)
+ sdebug_any_injecting_opt =
[PATCH v2 3/5] scsi_debug: add Capacity Changed Unit Attention
From: Douglas Gilbert dgilb...@interlog.com
Date: Mon, 24 Nov 2014 20:27:51 -0500
Subject: [PATCH 3/5] add Capacity Changed Unit Attention
Via sysfs the virtual_gb scsi_debug parameter can be changed while
LUs are in use. If that changes, the 'Capacity data has changed'
Unit Attention is queued on all LUs.
---
drivers/scsi/scsi_debug.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
Signed-off-by: Douglas Gilbert dgilb...@interlog.com
From 54eeff05237c4872fb1f5dcf1edddaace467d5b0 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert dgilb...@interlog.com
Date: Mon, 24 Nov 2014 20:27:51 -0500
Subject: [PATCH 3/5] add Capacity Changed Unit Attention
Via sysfs the virtual_gb scsi_debug parameter can be changed while
LUs are in use. If that changes, the 'Capacity data has changed'
Unit Attention is queued on all LUs.
---
drivers/scsi/scsi_debug.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index d337eaa..ee99aca 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -179,7 +179,8 @@ static const char *scsi_debug_version_date = 20141022;
#define SDEBUG_UA_POR 0 /* Power on, reset, or bus device reset */
#define SDEBUG_UA_BUS_RESET 1
#define SDEBUG_UA_MODE_CHANGED 2
-#define SDEBUG_NUM_UAS 3
+#define SDEBUG_UA_CAPACITY_CHANGED 3
+#define SDEBUG_NUM_UAS 4
/* for check_readiness() */
#define UAS_ONLY 1
@@ -582,6 +583,11 @@ static int check_readiness(struct scsi_cmnd *SCpnt, int uas_only,
if (debug)
cp = mode parameters changed;
break;
+ case SDEBUG_UA_CAPACITY_CHANGED:
+ mk_sense_buffer(SCpnt, UNIT_ATTENTION,
+ UA_CHANGED_ASC, CAPACITY_CHANGED_ASCQ);
+ if (debug)
+cp = capacity data changed;
default:
pr_warn(%s: unexpected unit attention code=%d\n,
__func__, k);
@@ -3638,16 +3644,30 @@ static ssize_t virtual_gb_show(struct device_driver *ddp, char *buf)
{
return scnprintf(buf, PAGE_SIZE, %d\n, scsi_debug_virtual_gb);
}
+
static ssize_t virtual_gb_store(struct device_driver *ddp, const char *buf,
size_t count)
{
-int n;
+ int n;
+ bool changed;
if ((count 0) (1 == sscanf(buf, %d, n)) (n = 0)) {
+ changed = (scsi_debug_virtual_gb != n);
scsi_debug_virtual_gb = n;
-
sdebug_capacity = get_sdebug_capacity();
-
+ if (changed) {
+ struct sdebug_host_info *sdhp;
+ struct sdebug_dev_info *dp;
+
+ list_for_each_entry(sdhp, sdebug_host_list,
+ host_list) {
+list_for_each_entry(dp, sdhp-dev_info_list,
+ dev_list) {
+ set_bit(SDEBUG_UA_CAPACITY_CHANGED,
+ dp-uas_bm);
+}
+ }
+ }
return count;
}
return -EINVAL;
--
1.9.1
Re: [PATCH v2 1/5] scsi_debug: pinpoint invalid field in sense data
On 11/25/2014 05:04 AM, Douglas Gilbert wrote: Use Sense Key Specific field in the sense data of an ILLEGAL REQUEST to optionally pinpoint the location of the problem field. This may be either in the cdb or the associated parameter list. --- drivers/scsi/scsi_debug.c | 138 +- 1 file changed, 88 insertions(+), 50 deletions(-) Signed-off-by: Douglas Gilbert dgilb...@interlog.com Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
Re: [PATCH v2 2/5] scsi_debug: append inject error flags onto scsi_cmnd object
On 11/25/2014 05:05 AM, Douglas Gilbert wrote: From: Douglas Gilbert dgilb...@interlog.com Date: Mon, 24 Nov 2014 20:18:02 -0500 Subject: [PATCH 2/5] append inject error flags onto scsi_cmnd object The way the existing scsi_debug command parser associated various inject error flags to a command was difficult to replicate in the table driven parser. This patch adds infrastructure to append those flags to the end of a scsi_cmnd object with the cmd_size host template option. --- drivers/scsi/scsi_debug.c | 68 +++ 1 file changed, 68 insertions(+) Signed-off-by: Douglas Gilbert dgilb...@interlog.com Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
Re: [PATCH v2 3/5] scsi_debug: add Capacity Changed Unit Attention
On 11/25/2014 05:05 AM, Douglas Gilbert wrote: From: Douglas Gilbert dgilb...@interlog.com Date: Mon, 24 Nov 2014 20:27:51 -0500 Subject: [PATCH 3/5] add Capacity Changed Unit Attention Via sysfs the virtual_gb scsi_debug parameter can be changed while LUs are in use. If that changes, the 'Capacity data has changed' Unit Attention is queued on all LUs. --- drivers/scsi/scsi_debug.c | 28 1 file changed, 24 insertions(+), 4 deletions(-) Signed-off-by: Douglas Gilbert dgilb...@interlog.com Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
Re: [PATCH v2 4/5] scsi_debug: change SCSI command parser to table driven
On 11/25/2014 05:05 AM, Douglas Gilbert wrote: + case 0x53: /* XDWRITEREAD(10) */ + ei_lba = 0; + lba = get_unaligned_be32(cmd + 2); + num = get_unaligned_be16(cmd + 7); + check_prot = false; + break; Why not use 'XDWRITEREAD_10' here? It did work in the original version ... (This is the bit I meant :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
Re: [PATCH v2 5/5] scsi_debug: Add Report supported opcodes+tmfs; Compare and write
On 11/25/2014 05:05 AM, Douglas Gilbert wrote: From: Douglas Gilbert dgilb...@interlog.com Date: Mon, 24 Nov 2014 21:27:12 -0500 Subject: [PATCH 5/5] Add Report supported opcodes+tmfs; Compare and write The Report supported operation codes command is very closely integrated into the table driven parser and very useful for testing it. Its cdb masks form the basis of the 'strict' parameter's checks. The Report supported TMFs command is a simple extension. The Compare and write command may even be useful, as it should be atomic due to the read-write lock that the driver uses on its backing store (ram). --- drivers/scsi/scsi_debug.c | 326 +++--- 1 file changed, 307 insertions(+), 19 deletions(-) Signed-off-by: Douglas Gilbert dgilb...@interlog.com Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
