[PATCH] bnx2fc: fix incorrect DMA memory mapping in bnx2fc_map_sg()
In the bnx2fc_map_sg() function, the original behaviour is to
allocate the DMA memory by directly calling dma_map_sg()
instead of using scsi_dma_map().
In contrast, bnx2fc_unmap_sg_list() calls scsi_dma_unmap().
The problem is that bnx2fc_map_sg() passes to the dma_map_sg() function
the pointer to the "device" structure taken from pci_dev
and not from Scsi_Host (as scsi_dma_map/unmap() do).
In some circumstances, the two devices may be different and the
DMA library will be unable to find the correct entry
when freeing the memory.
This patch fixes the bug by replacing dma_map_sg() with scsi_dma_map().
[56068.747547] WARNING: CPU: 1 PID: 12048 at lib/dma-debug.c:1080
check_unmap+0x90a/0xa00()
[56068.785706] fcoe ctlr_0: DMA-API: device driver tries to free DMA memory it
has not allocated [device address=0x000202a1aa00] [size=36 bytes]
[56068.846700] Modules linked in: 8021q garp stp mrp llc fcoe bnx2fc cnic uio
libfcoe libfc scsi_transport_fc scsi_tgt cfg80211 rfkill x86_pkg_temp_thermal
coretemp kvm_intel kvm crct10dif_pclmul iTCO_wdt crc32_pclmul gpio_ich
crc32c_intel iTCO_vendor_support ghash_clmulni_intel joydev lpc_ich hpwdt nfsd
mfd_core microcode hpilo serio_raw pcspkr ipmi_si auth_rpcgss nfs_acl lockd
shpchp ipmi_msghandler sunrpc xfs e1000e mgag200 i2c_algo_bit drm_kms_helper
ttm ptp drm ata_generic pata_acpi bnx2x i2c_core pps_core hpsa mdio libcrc32c
[56069.077673] CPU: 1 PID: 12048 Comm: bnx2fc_thread/1 Not tainted 3.16.0-rc7+
#1
[56069.115286] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
[56069.145091] 0009 8801f36dbbd8 816c323a
8801f36dbc20
[56069.185083] 8801f36dbc10 8108350d 8800e9880960
8801f36dbd00
[56069.222738] 0024 000202a1aa00 0001
8801f36dbc70
[56069.263389] Call Trace:
[56069.275945] [] dump_stack+0x45/0x56
[56069.302133] [] warn_slowpath_common+0x7d/0xa0
[56069.334050] [] warn_slowpath_fmt+0x4c/0x50
[56069.364537] [] ? debug_dma_mapping_error+0x7c/0x90
[56069.398268] [] check_unmap+0x90a/0xa00
[56069.423761] [] debug_dma_unmap_sg+0x65/0x110
[56069.474134] [] scsi_dma_unmap+0x73/0xb0
[56069.499313] [] bnx2fc_process_scsi_cmd_compl+0xcc/0x2a0
[bnx2fc]
[56069.535588] [] bnx2fc_process_cq_compl+0x21b/0x280
[bnx2fc]
[56069.570311] [] bnx2fc_percpu_io_thread+0x106/0x180
[bnx2fc]
[56069.604560] [] ? bnx2fc_get_src_mac+0x20/0x20 [bnx2fc]
[56069.635801] [] kthread+0xd2/0xf0
[56069.659421] [] ? kthread_create_on_node+0x170/0x170
[56069.689416] [] ret_from_fork+0x7c/0xb0
[56069.715510] [] ? kthread_create_on_node+0x170/0x170
Signed-off-by: Maurizio Lombardi
---
drivers/scsi/bnx2fc/bnx2fc_io.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
index 7bc47fc..fe2cd9b 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_io.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_io.c
@@ -1640,8 +1640,6 @@ static int bnx2fc_split_bd(struct bnx2fc_cmd *io_req, u64
addr, int sg_len,
static int bnx2fc_map_sg(struct bnx2fc_cmd *io_req)
{
- struct bnx2fc_interface *interface = io_req->port->priv;
- struct bnx2fc_hba *hba = interface->hba;
struct scsi_cmnd *sc = io_req->sc_cmd;
struct fcoe_bd_ctx *bd = io_req->bd_tbl->bd_tbl;
struct scatterlist *sg;
@@ -1653,8 +1651,8 @@ static int bnx2fc_map_sg(struct bnx2fc_cmd *io_req)
u64 addr;
int i;
- sg_count = dma_map_sg(&hba->pcidev->dev, scsi_sglist(sc),
- scsi_sg_count(sc), sc->sc_data_direction);
+ sg_count = scsi_dma_map(sc);
+
scsi_for_each_sg(sc, sg, sg_count, i) {
sg_len = sg_dma_len(sg);
addr = sg_dma_address(sg);
--
Maurizio Lombardi
--
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 V3 0/4] Add XEN pvSCSI support
This series adds XEN pvSCSI support. With pvSCSI it is possible to use physical SCSI devices from a XEN domain. The support consists of a backend in the privileged Domain-0 doing the real I/O and a frontend in the unprivileged domU passing I/O-requests to the backend. The code is taken (and adapted) from the original pvSCSI implementation done for Linux 2.6 in 2008 by Fujitsu. [PATCH V2 1/4] Add XEN pvSCSI protocol description [PATCH V2 2/4] Introduce xen-scsifront module [PATCH V2 3/4] Introduce XEN scsiback module [PATCH V2 4/4] add xen pvscsi maintainer Changes in V3: - added some comments to the protocol header file - removed the CDB emulation from xen-scsiback, handled by core target infrastructure - several changes in xen-scsifront after comments from Christoph Hellwig Changes in V2: - use core target infrastructure by backend instead of pure SCSI passthrough - add support for larger SG lists by putting them in grant page(s) - add command abort capability -- 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 V3 1/4] Add XEN pvSCSI protocol description
From: Juergen Gross Add the definition of pvSCSI protocol used between the pvSCSI frontend in a XEN domU and the pvSCSI backend in a XEN driver domain (usually Dom0). This header was originally provided by Fujitsu for XEN based on Linux 2.6.18. Changes are: - added comment - adapt to Linux style guide - add support for larger SG-lists by putting them in an own granted page - remove stale definitions Signed-off-by: Juergen Gross --- include/xen/interface/io/vscsiif.h | 208 + 1 file changed, 208 insertions(+) create mode 100644 include/xen/interface/io/vscsiif.h diff --git a/include/xen/interface/io/vscsiif.h b/include/xen/interface/io/vscsiif.h new file mode 100644 index 000..ead1c0b --- /dev/null +++ b/include/xen/interface/io/vscsiif.h @@ -0,0 +1,208 @@ +/** + * vscsiif.h + * + * Based on the blkif.h code. + * + * This interface is to be regarded as a stable API between XEN domains + * running potentially different Linux kernel versions. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright(c) FUJITSU Limited 2008. + */ + +#ifndef __XEN__PUBLIC_IO_SCSI_H__ +#define __XEN__PUBLIC_IO_SCSI_H__ + +#include "ring.h" +#include "../grant_table.h" + +/* + * Front->back notifications: When enqueuing a new request, sending a + * notification can be made conditional on req_event (i.e., the generic + * hold-off mechanism provided by the ring macros). Backends must set + * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()). + * + * Back->front notifications: When enqueuing a new response, sending a + * notification can be made conditional on rsp_event (i.e., the generic + * hold-off mechanism provided by the ring macros). Frontends must set + * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()). + */ + +/* + * Feature and Parameter Negotiation + * = + * The two halves of a Xen pvSCSI driver utilize nodes within the XenStore to + * communicate capabilities and to negotiate operating parameters. This + * section enumerates these nodes which reside in the respective front and + * backend portions of the XenStore, following the XenBus convention. + * + * All data in the XenStore is stored as strings. Nodes specifying numeric + * values are encoded in decimal. Integer value ranges listed below are + * expressed as fixed sized integer types capable of storing the conversion + * of a properly formated node string, without loss of information. + * + * Any specified default value is in effect if the corresponding XenBus node + * is not present in the XenStore. + * + * XenStore nodes in sections marked "PRIVATE" are solely for use by the + * driver side whose XenBus tree contains them. + * + * + *Backend XenBus Nodes + * + * + *-- Backend Device Identification (PRIVATE) -- + * + * p-devname + * Values: string + * + * A free string used to identify the physical device (e.g. a disk name). + * + * p-dev + * Values: string + * + * A string specifying the backend device: either a 4-tuple "h:c:t:l" + * (host, controller, target, lun, all integers), or a WWN (e.g. + * "naa.60014054ac780582"). + * + * v-dev + * Values: string + * + * A string specifying the frontend device in form of a 4-tuple "h:c:t:l" + * (host, controller, target, lun, all integers). + * + *- Features - + * + * feature-sg-grant + * Values: + * Default Value: 0 + * + * Specifies the maximum number of scatter/gather elements in grant pages + * supported. If not set, t
[PATCH V3 4/4] add xen pvscsi maintainer
From: Juergen Gross Add myself as maintainer for the Xen pvSCSI stuff. Signed-off-by: Juergen Gross --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c2066f4..d020bfd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10046,6 +10046,14 @@ S: Supported F: arch/x86/pci/*xen* F: drivers/pci/*xen* +XEN PVSCSI DRIVERS +M: Juergen Gross +L: xen-de...@lists.xenproject.org (moderated for non-subscribers) +S: Supported +F: drivers/scsi/xen-scsifront.c +F: drivers/xen/xen-scsiback.c +F: include/xen/interface/io/vscsiif.h + XEN SWIOTLB SUBSYSTEM M: Konrad Rzeszutek Wilk L: xen-de...@lists.xenproject.org (moderated for non-subscribers) -- 1.8.4.5 -- 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 V3 2/4] Introduce xen-scsifront module
From: Juergen Gross
Introduces the XEN pvSCSI frontend. With pvSCSI it is possible for a XEN domU
to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands
are passed to the pvSCSI backend in a driver domain (usually Dom0) which is
owner of the physical device. This allows e.g. to use SCSI tape drives in a
XEN domU.
The code is taken from the pvSCSI implementation in XEN done by Fujitsu based
on Linux kernel 2.6.18.
Changes from the original version are:
- port to upstream kernel
- put all code in just one source file
- move module to appropriate location in kernel tree
- adapt to Linux style guide
- some minor code simplifications
- replace constants with defines
- remove not used defines
- add support for larger SG lists by putting them in a granted page
Signed-off-by: Juergen Gross
---
drivers/scsi/Kconfig |9 +
drivers/scsi/Makefile|1 +
drivers/scsi/xen-scsifront.c | 1011 ++
3 files changed, 1021 insertions(+)
create mode 100644 drivers/scsi/xen-scsifront.c
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index baca589..e860c16 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -611,6 +611,15 @@ config VMWARE_PVSCSI
To compile this driver as a module, choose M here: the
module will be called vmw_pvscsi.
+config XEN_SCSI_FRONTEND
+ tristate "XEN SCSI frontend driver"
+ depends on SCSI && XEN
+ help
+ The XEN SCSI frontend driver allows the kernel to access SCSI Devices
+ within another guest OS (usually Dom0).
+ Only needed if the kernel is running in a XEN guest and generic
+ SCSI access to a device is needed.
+
config HYPERV_STORAGE
tristate "Microsoft Hyper-V virtual storage driver"
depends on SCSI && HYPERV
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index e172d4f..a4ee9c5 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -144,6 +144,7 @@ obj-$(CONFIG_SCSI_ESAS2R) += esas2r/
obj-$(CONFIG_SCSI_PMCRAID) += pmcraid.o
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_ARM) += arm/
diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
new file mode 100644
index 000..7c60c68
--- /dev/null
+++ b/drivers/scsi/xen-scsifront.c
@@ -0,0 +1,1011 @@
+/*
+ * Xen SCSI frontend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#define DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+
+#define GRANT_INVALID_REF 0
+
+#define VSCSIFRONT_OP_ADD_LUN 1
+#define VSCSIFRONT_OP_DEL_LUN 2
+
+#define DEFAULT_TASK_COMM_LEN TASK_COMM_LEN
+
+/* tuning point*/
+#define VSCSIIF_DEFAULT_CMD_PER_LUN 10
+#define VSCSIIF_MAX_TARGET 64
+#define VSCSIIF_MAX_LUN 255
+
+#define VSCSIIF_RING_SIZE __CONST_RING_SIZE(vscsiif, PAGE_SIZE)
+#define VSCSIIF_MAX_REQS VSCSIIF_RING_SIZE
+
+#define vscsiif_grants_sg(_sg) (PFN_UP((_sg) * \
+ sizeof(struct scsiif_request_segment)))
+
+struct vscsifrnt_shadow {
+ /* command between backend and frontend */
+ unsigned char act;
+ uint16_t rqid;
+
+ /* Number of pieces o
[PATCH V3 3/4] Introduce XEN scsiback module
From: Juergen Gross
Introduces the XEN pvSCSI backend. With pvSCSI it is possible for a XEN domU
to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands
are passed to the pvSCSI backend in a driver domain (usually Dom0) which is
owner of the physical device. This allows e.g. to use SCSI tape drives in a
XEN domU.
The code is taken from the pvSCSI implementation in XEN done by Fujitsu based
on Linux kernel 2.6.18.
Changes from the original version are:
- port to upstream kernel
- put all code in just one source file
- adapt to Linux style guide
- use target core infrastructure instead doing pure pass-through
- enable module unloading
- support SG-list in grant page(s)
- support task abort
- remove redundant struct backend
- allocate resources dynamically
- correct minor error in scsiback_fast_flush_area
- free allocated resources in case of error during I/O preparation
- remove CDB emulation, now handled by target core infrastructure
Signed-off-by: Juergen Gross
---
drivers/xen/Kconfig|9 +
drivers/xen/Makefile |1 +
drivers/xen/xen-scsiback.c | 2282
3 files changed, 2292 insertions(+)
create mode 100644 drivers/xen/xen-scsiback.c
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 38fb36e..42fb963 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -172,6 +172,15 @@ config XEN_PCIDEV_BACKEND
If in doubt, say m.
+config XEN_SCSI_BACKEND
+ tristate "XEN SCSI backend driver"
+ depends on XEN && XEN_BACKEND && TARGET_CORE
+ help
+ The SCSI backend driver allows the kernel to export its SCSI Devices
+ to other guests via a high-performance shared-memory interface.
+ Only needed for systems running as XEN driver domains (e.g. Dom0) and
+ if guests need generic access to SCSI devices.
+
config XEN_PRIVCMD
tristate
depends on XEN
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 45e00af..b42ee75 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_XEN_STUB)+= xen-stub.o
obj-$(CONFIG_XEN_ACPI_HOTPLUG_MEMORY) += xen-acpi-memhotplug.o
obj-$(CONFIG_XEN_ACPI_HOTPLUG_CPU) += xen-acpi-cpuhotplug.o
obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o
+obj-$(CONFIG_XEN_SCSI_BACKEND) += xen-scsiback.o
xen-evtchn-y := evtchn.o
xen-gntdev-y := gntdev.o
xen-gntalloc-y := gntalloc.o
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
new file mode 100644
index 000..4a0d6e3
--- /dev/null
+++ b/drivers/xen/xen-scsiback.c
@@ -0,0 +1,2282 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ * Adaption to kernel taget core infrastructure taken from vhost/scsi.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define DPRINTK(_f, _a...) \
+ pr_debug("(file=%s, line=%d) " _f, __FILE__ , __LINE__ , ## _a)
+
+#define VSCSI_VERSION "v0.1"
+#define VSCSI_NAMELEN 32
+
+struct ids_tuple {
+ unsigned int hst; /* host*/
+ unsigned int chn; /
[PATCH] scsi: use correct formats in printk()
Use %llu for u64 and %u for int. Not the other way round.
Signed-off-by: Martin Kepplinger
---
applies to -next20140801
drivers/scsi/u14-34f.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/u14-34f.c b/drivers/scsi/u14-34f.c
index 4e76fe8..d8dcf36 100644
--- a/drivers/scsi/u14-34f.c
+++ b/drivers/scsi/u14-34f.c
@@ -1006,7 +1006,7 @@ static int port_detect \
sh[j]->irq, dma_name, sh[j]->sg_tablesize, sh[j]->can_queue);
if (sh[j]->max_id > 8 || sh[j]->max_lun > 8)
- printk("%s: wide SCSI support enabled, max_id %u, max_lun %u.\n",
+ printk("%s: wide SCSI support enabled, max_id %u, max_lun %llu.\n",
BN(j), sh[j]->max_id, sh[j]->max_lun);
for (i = 0; i <= sh[j]->max_channel; i++)
@@ -1285,7 +1285,7 @@ static int u14_34f_queuecommand_lck(struct scsi_cmnd
*SCpnt, void (*done)(struct
cpp->cpp_index = i;
SCpnt->host_scribble = (unsigned char *) &cpp->cpp_index;
- if (do_trace) printk("%s: qcomm, mbox %d, target %d.%d:%llu.\n",
+ if (do_trace) printk("%s: qcomm, mbox %d, target %d.%d:%u.\n",
BN(j), i, SCpnt->device->channel, SCpnt->device->id,
(u8)SCpnt->device->lun);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/18] arcmsr: precise checking adapter ID
From: Ching Huang
This patch rewrites the arcmsr_define_adapter_type function to precisely check
Areca adapter's ID.
This can prevent an unknown adapter being used as a default adapter type by
driver.
Signed-off-by: Ching Huang
---
Thanks for Christoph advice.
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-01 18:02:08.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:43:16.0 +0800
@@ -295,24 +295,43 @@ static int arcmsr_bios_param(struct scsi
return 0;
}
-static void arcmsr_define_adapter_type(struct AdapterControlBlock *acb)
+static int arcmsr_define_adapter_type(struct AdapterControlBlock *acb)
{
struct pci_dev *pdev = acb->pdev;
u16 dev_id;
- pci_read_config_word(pdev, PCI_DEVICE_ID, &dev_id);
+
+ dev_id = pdev->device;
acb->dev_id = dev_id;
switch (dev_id) {
- case 0x1880: {
+ case 0x1880:
acb->adapter_type = ACB_ADAPTER_TYPE_C;
- }
break;
- case 0x1201: {
+ case 0x1200:
+ case 0x1201:
+ case 0x1202:
acb->adapter_type = ACB_ADAPTER_TYPE_B;
- }
break;
-
- default: acb->adapter_type = ACB_ADAPTER_TYPE_A;
+ case 0x1110:
+ case 0x1120:
+ case 0x1130:
+ case 0x1160:
+ case 0x1170:
+ case 0x1210:
+ case 0x1220:
+ case 0x1230:
+ case 0x1260:
+ case 0x1270:
+ case 0x1280:
+ case 0x1380:
+ case 0x1381:
+ case 0x1680:
+ acb->adapter_type = ACB_ADAPTER_TYPE_A;
+ break;
+ default:
+ pr_notice("Unknown device ID = 0x%x\n", dev_id);
+ return false;
}
+ return true;
}
static uint8_t arcmsr_hba_wait_msgint_ready(struct AdapterControlBlock *acb)
@@ -710,7 +729,9 @@ static int arcmsr_probe(struct pci_dev *
ACB_F_MESSAGE_WQBUFFER_READED);
acb->acb_flags &= ~ACB_F_SCSISTOPADAPTER;
INIT_LIST_HEAD(&acb->ccb_free_list);
- arcmsr_define_adapter_type(acb);
+ error = arcmsr_define_adapter_type(acb);
+ if (!error)
+ goto pci_release_regs;
error = arcmsr_remap_pciregion(acb);
if(!error){
goto pci_release_regs;
--
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 v1.3 7/18] arcmsr: revise messages_isr_bh_fn to remove duplicate code
From: Ching Huang
Revise message_isr_bh_fn to remove the duplicate code for each adapter type.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:43:16.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:43:06.0 +0800
@@ -511,120 +511,65 @@ static int arcmsr_alloc_ccb_pool(struct
static void arcmsr_message_isr_bh_fn(struct work_struct *work)
{
- struct AdapterControlBlock *acb = container_of(work,struct
AdapterControlBlock, arcmsr_do_message_isr_bh);
- switch (acb->adapter_type) {
- case ACB_ADAPTER_TYPE_A: {
+ struct AdapterControlBlock *acb = container_of(work,
+ struct AdapterControlBlock, arcmsr_do_message_isr_bh);
+ char *acb_dev_map = (char *)acb->device_map;
+ uint32_t __iomem *signature = NULL;
+ char __iomem *devicemap = NULL;
+ int target, lun;
+ struct scsi_device *psdev;
+ char diff, temp;
- struct MessageUnit_A __iomem *reg = acb->pmuA;
- char *acb_dev_map = (char *)acb->device_map;
- uint32_t __iomem *signature = (uint32_t __iomem*)
(®->message_rwbuffer[0]);
- char __iomem *devicemap = (char __iomem*)
(®->message_rwbuffer[21]);
- int target, lun;
- struct scsi_device *psdev;
- char diff;
-
- atomic_inc(&acb->rq_map_token);
- if (readl(signature) == ARCMSR_SIGNATURE_GET_CONFIG) {
- for(target = 0; target < ARCMSR_MAX_TARGETID
-1; target++) {
- diff = (*acb_dev_map)^readb(devicemap);
- if (diff != 0) {
- char temp;
- *acb_dev_map = readb(devicemap);
- temp =*acb_dev_map;
- for(lun = 0; lun <
ARCMSR_MAX_TARGETLUN; lun++) {
- if((temp & 0x01)==1 &&
(diff & 0x01) == 1) {
-
scsi_add_device(acb->host, 0, target, lun);
- }else if((temp & 0x01)
== 0 && (diff & 0x01) == 1) {
- psdev =
scsi_device_lookup(acb->host, 0, target, lun);
- if (psdev !=
NULL ) {
-
scsi_remove_device(psdev);
-
scsi_device_put(psdev);
- }
- }
- temp >>= 1;
- diff >>= 1;
- }
- }
- devicemap++;
- acb_dev_map++;
- }
- }
- break;
+ switch (acb->adapter_type) {
+ case ACB_ADAPTER_TYPE_A: {
+ struct MessageUnit_A __iomem *reg = acb->pmuA;
+ signature = (uint32_t __iomem *)(®->message_rwbuffer[0]);
+ devicemap = (char __iomem *)(®->message_rwbuffer[21]);
+ break;
}
-
- case ACB_ADAPTER_TYPE_B: {
- struct MessageUnit_B *reg = acb->pmuB;
- char *acb_dev_map = (char *)acb->device_map;
- uint32_t __iomem *signature = (uint32_t
__iomem*)(®->message_rwbuffer[0]);
- char __iomem *devicemap = (char
__iomem*)(®->message_rwbuffer[21]);
- int target, lun;
- struct scsi_device *psdev;
- char diff;
-
- atomic_inc(&acb->rq_map_token);
- if (readl(signature) == ARCMSR_SIGNATURE_GET_CONFIG) {
- for(target = 0; target < ARCMSR_MAX_TARGETID
-1; target++) {
- diff = (*acb_dev_map)^readb(devicemap);
- if (diff != 0) {
- char temp;
- *acb_dev_map = readb(devicemap);
- temp =*acb_dev_map;
- for(lun = 0; lun <
ARCMSR_MAX_TARGETLUN; lun++) {
-
[PATCH v1.3 8/18] arcmsr: remove calling arcmsr_hbb_enable_driver_mode
From: Ching Huang
Remove calling arcmsr_hbb_enable_driver_mode by in-line code.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:43:06.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:44:44.0 +0800
@@ -875,17 +875,6 @@ static uint8_t arcmsr_abort_allcmd(struc
return rtnval;
}
-static bool arcmsr_hbb_enable_driver_mode(struct AdapterControlBlock *pacb)
-{
- struct MessageUnit_B *reg = pacb->pmuB;
- writel(ARCMSR_MESSAGE_START_DRIVER_MODE, reg->drv2iop_doorbell);
- if (!arcmsr_hbb_wait_msgint_ready(pacb)) {
- printk(KERN_ERR "arcmsr%d: can't set driver mode. \n",
pacb->host->host_no);
- return false;
- }
- return true;
-}
-
static void arcmsr_pci_unmap_dma(struct CommandControlBlock *ccb)
{
struct scsi_cmnd *pcmd = ccb->pcmd;
@@ -2683,7 +2672,12 @@ static int arcmsr_iop_confirm(struct Ada
timeout \n",acb->host->host_no);
return 1;
}
- arcmsr_hbb_enable_driver_mode(acb);
+ writel(ARCMSR_MESSAGE_START_DRIVER_MODE, reg->drv2iop_doorbell);
+ if (!arcmsr_hbb_wait_msgint_ready(acb)) {
+ pr_err("arcmsr%d: can't set driver mode.\n",
+ acb->host->host_no);
+ return 1;
+ }
}
break;
case ACB_ADAPTER_TYPE_C: {
--
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 v1.3 9/18] arcmsr: modify printing adapter model number and F/W messages
From: Ching Huang
Adjust printing order of adapter model name and firmware version.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:44:44.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:44:50.0 +0800
@@ -2226,10 +2226,10 @@ static bool arcmsr_get_hba_config(struct
iop_device_map++;
count--;
}
- printk(KERN_NOTICE "Areca RAID Controller%d: F/W %s & Model %s\n",
+ pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
acb->host->host_no,
- acb->firm_version,
- acb->firm_model);
+ acb->firm_model,
+ acb->firm_version);
acb->signature = readl(®->message_rwbuffer[0]);
acb->firm_request_len = readl(®->message_rwbuffer[1]);
acb->firm_numbers_queue = readl(®->message_rwbuffer[2]);
@@ -2302,10 +2302,10 @@ static bool arcmsr_get_hbb_config(struct
count--;
}
- printk(KERN_NOTICE "Areca RAID Controller%d: F/W %s & Model %s\n",
+ pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
acb->host->host_no,
- acb->firm_version,
- acb->firm_model);
+ acb->firm_model,
+ acb->firm_version);
acb->signature = readl(®->message_rwbuffer[1]);
/*firm_signature,1,00-03*/
@@ -2368,10 +2368,10 @@ static bool arcmsr_get_hbc_config(struct
iop_firm_version++;
count--;
}
- printk(KERN_NOTICE "Areca RAID Controller%d: F/W %s & Model %s\n",
+ pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
pACB->host->host_no,
- pACB->firm_version,
- pACB->firm_model);
+ pACB->firm_model,
+ pACB->firm_version);
pACB->firm_request_len = readl(®->msgcode_rwbuffer[1]);
/*firm_request_len,1,04-07*/
pACB->firm_numbers_queue = readl(®->msgcode_rwbuffer[2]);
/*firm_numbers_queue,2,08-11*/
pACB->firm_sdram_size = readl(®->msgcode_rwbuffer[3]);
/*firm_sdram_size,3,12-15*/
--
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 v1.3 10/18] arcmsr: clear outbound doorbell buffer completely
From: Ching Huang
Clear outbound doorbell buffer completely for adapter type C.
This is to prevent getting bad data input from IOP before ioctl command
beginning.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:44:50.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:45:00.0 +0800
@@ -2888,11 +2888,23 @@ static void arcmsr_clear_doorbell_queue_
break;
case ACB_ADAPTER_TYPE_C: {
struct MessageUnit_C *reg = (struct MessageUnit_C *)acb->pmuC;
- uint32_t outbound_doorbell;
+ uint32_t outbound_doorbell, i;
/* empty doorbell Qbuffer if door bell ringed */
outbound_doorbell = readl(®->outbound_doorbell);
writel(outbound_doorbell, ®->outbound_doorbell_clear);
writel(ARCMSR_HBCMU_DRV2IOP_DATA_READ_OK,
®->inbound_doorbell);
+ for (i = 0; i < 200; i++) {
+ msleep(20);
+ outbound_doorbell = readl(®->outbound_doorbell);
+ if (outbound_doorbell &
+ ARCMSR_HBCMU_IOP2DRV_DATA_WRITE_OK) {
+ writel(outbound_doorbell,
+ ®->outbound_doorbell_clear);
+ writel(ARCMSR_HBCMU_DRV2IOP_DATA_READ_OK,
+ ®->inbound_doorbell);
+ } else
+ break;
+ }
}
}
}
@@ -3120,9 +3132,7 @@ sleep:
arcmsr_get_firmware_spec(acb);
arcmsr_start_adapter_bgrb(acb);
/* clear Qbuffer if door bell ringed */
- outbound_doorbell =
readl(®->outbound_doorbell);
- writel(outbound_doorbell,
®->outbound_doorbell_clear); /*clear interrupt */
- writel(ARCMSR_HBCMU_DRV2IOP_DATA_READ_OK,
®->inbound_doorbell);
+ arcmsr_clear_doorbell_queue_buffer(acb);
/* enable outbound Post Queue,outbound doorbell
Interrupt */
arcmsr_enable_outbound_ints(acb, intmask_org);
atomic_set(&acb->rq_map_token, 16);
--
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 v1.3 11/18] arcmsr: rename function and variable
From: Ching Huang
Rename some variable and function name for readability and consistency.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:27:14.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:27:38.0 +0800
@@ -359,7 +359,7 @@ struct ARCMSR_CDB
#define ARCMSR_CDB_FLAG_ORDEREDQ 0x10
uint8_t msgPages;
- uint32_tContext;
+ uint32_tmsgContext;
uint32_tDataLength;
uint8_t Cdb[16];
uint8_t DeviceStatus;
@@ -562,7 +562,7 @@ struct AdapterControlBlock
/* dma_coherent used for memory free */
dma_addr_t dma_coherent_handle;
/* dma_coherent_handle used for memory free */
- dma_addr_t dma_coherent_handle_hbb_mu;
+ dma_addr_t dma_coherent_handle2;
unsigned intuncache_size;
uint8_t rqbuffer[ARCMSR_MAX_QBUFFER];
/* data collection buffer for read from 80331 */
@@ -613,7 +613,7 @@ struct CommandControlBlock{
struct list_headlist; /*x32:
8byte, x64: 16byte*/
struct scsi_cmnd*pcmd; /*8
bytes pointer of linux scsi command */
struct AdapterControlBlock *acb; /*x32:
4byte, x64: 8byte*/
- uint32_tcdb_phyaddr_pattern;/*x32:
4byte, x64: 4byte*/
+ uint32_tcdb_phyaddr;/*x32:
4byte, x64: 4byte*/
uint32_tarc_cdb_size;
/*x32:4byte,x64:4byte*/
uint16_tccb_flags; /*x32:
2byte, x64: 2byte*/
#define CCB_FLAG_READ 0x
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:45:00.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:45:18.0 +0800
@@ -99,16 +99,16 @@ static u32 arcmsr_disable_outbound_ints(
static void arcmsr_enable_outbound_ints(struct AdapterControlBlock *acb,
u32 intmask_org);
static void arcmsr_stop_adapter_bgrb(struct AdapterControlBlock *acb);
-static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb);
-static void arcmsr_flush_hbb_cache(struct AdapterControlBlock *acb);
+static void arcmsr_hbaA_flush_cache(struct AdapterControlBlock *acb);
+static void arcmsr_hbaB_flush_cache(struct AdapterControlBlock *acb);
static void arcmsr_request_device_map(unsigned long pacb);
-static void arcmsr_request_hba_device_map(struct AdapterControlBlock *acb);
-static void arcmsr_request_hbb_device_map(struct AdapterControlBlock *acb);
-static void arcmsr_request_hbc_device_map(struct AdapterControlBlock *acb);
+static void arcmsr_hbaA_request_device_map(struct AdapterControlBlock *acb);
+static void arcmsr_hbaB_request_device_map(struct AdapterControlBlock *acb);
+static void arcmsr_hbaC_request_device_map(struct AdapterControlBlock *acb);
static void arcmsr_message_isr_bh_fn(struct work_struct *work);
static bool arcmsr_get_firmware_spec(struct AdapterControlBlock *acb);
static void arcmsr_start_adapter_bgrb(struct AdapterControlBlock *acb);
-static void arcmsr_hbc_message_isr(struct AdapterControlBlock *pACB);
+static void arcmsr_hbaC_message_isr(struct AdapterControlBlock *pACB);
static void arcmsr_hardware_reset(struct AdapterControlBlock *acb);
static const char *arcmsr_info(struct Scsi_Host *);
static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
@@ -180,7 +180,7 @@ static struct pci_driver arcmsr_pci_driv
*/
-static void arcmsr_free_hbb_mu(struct AdapterControlBlock *acb)
+static void arcmsr_free_mu(struct AdapterControlBlock *acb)
{
switch (acb->adapter_type) {
case ACB_ADAPTER_TYPE_A:
@@ -189,7 +189,7 @@ static void arcmsr_free_hbb_mu(struct Ad
case ACB_ADAPTER_TYPE_B:{
dma_free_coherent(&acb->pdev->dev,
sizeof(struct MessageUnit_B),
- acb->pmuB, acb->dma_coherent_handle_hbb_mu);
+ acb->pmuB, acb->dma_coherent_handle2);
}
}
}
@@ -334,7 +334,7 @@ static int arcmsr_define_adapter_type(st
return true;
}
-static uint8_t arcmsr_hba_wait_msgint_ready(struct AdapterControlBlock *acb)
+static uint8_t arcmsr_hbaA_wait_msgint_ready(s
[PATCH v1.3 12/18] arcmsr: revise allocation of second dma_coherent_handle for type B adapter
From: Ching Huang
This modification is for consistency with up-coming adapter type D.
They have similar H/W and S/W structure.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:27:38.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:28:38.0 +0800
@@ -507,6 +507,7 @@ struct AdapterControlBlock
#define ACB_ADAPTER_TYPE_B0x0002/* hbb M IOP */
#define ACB_ADAPTER_TYPE_C0x0004/* hbc P IOP */
#define ACB_ADAPTER_TYPE_D0x0008/* hbd A IOP */
+ u32 roundup_ccbsize;
struct pci_dev *pdev;
struct Scsi_Host * host;
unsigned long vir2phy_offset;
@@ -563,6 +564,7 @@ struct AdapterControlBlock
dma_addr_t dma_coherent_handle;
/* dma_coherent_handle used for memory free */
dma_addr_t dma_coherent_handle2;
+ void*dma_coherent2;
unsigned intuncache_size;
uint8_t rqbuffer[ARCMSR_MAX_QBUFFER];
/* data collection buffer for read from 80331 */
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:45:18.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:45:26.0 +0800
@@ -183,13 +183,10 @@ static struct pci_driver arcmsr_pci_driv
static void arcmsr_free_mu(struct AdapterControlBlock *acb)
{
switch (acb->adapter_type) {
- case ACB_ADAPTER_TYPE_A:
- case ACB_ADAPTER_TYPE_C:
- break;
case ACB_ADAPTER_TYPE_B:{
- dma_free_coherent(&acb->pdev->dev,
- sizeof(struct MessageUnit_B),
- acb->pmuB, acb->dma_coherent_handle2);
+ dma_free_coherent(&acb->pdev->dev, acb->roundup_ccbsize,
+ acb->dma_coherent2, acb->dma_coherent_handle2);
+ break;
}
}
}
@@ -2254,12 +2251,15 @@ static bool arcmsr_hbaB_get_config(struc
char __iomem *iop_device_map;
/*firm_version,21,84-99*/
int count;
- dma_coherent = dma_alloc_coherent(&pdev->dev, sizeof(struct
MessageUnit_B), &dma_coherent_handle, GFP_KERNEL);
+
+ acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_B), 32);
+ dma_coherent = dma_alloc_coherent(&pdev->dev, acb->roundup_ccbsize,
&dma_coherent_handle, GFP_KERNEL);
if (!dma_coherent){
printk(KERN_NOTICE "arcmsr%d: dma_alloc_coherent got error for
hbb mu\n", acb->host->host_no);
return false;
}
acb->dma_coherent_handle2 = dma_coherent_handle;
+ acb->dma_coherent2 = dma_coherent;
reg = (struct MessageUnit_B *)dma_coherent;
acb->pmuB = reg;
reg->drv2iop_doorbell= (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL);
@@ -2605,6 +2605,7 @@ static int arcmsr_polling_ccbdone(struct
static int arcmsr_iop_confirm(struct AdapterControlBlock *acb)
{
uint32_t cdb_phyaddr, cdb_phyaddr_hi32;
+ dma_addr_t dma_coherent_handle;
/*
@@ -2612,8 +2613,16 @@ static int arcmsr_iop_confirm(struct Ada
** if freeccb.HighPart is not zero
*/
- cdb_phyaddr = lower_32_bits(acb->dma_coherent_handle);
- cdb_phyaddr_hi32 = upper_32_bits(acb->dma_coherent_handle);
+ switch (acb->adapter_type) {
+ case ACB_ADAPTER_TYPE_B:
+ dma_coherent_handle = acb->dma_coherent_handle2;
+ break;
+ default:
+ dma_coherent_handle = acb->dma_coherent_handle;
+ break;
+ }
+ cdb_phyaddr = lower_32_bits(dma_coherent_handle);
+ cdb_phyaddr_hi32 = upper_32_bits(dma_coherent_handle);
acb->cdb_phyaddr_hi32 = cdb_phyaddr_hi32;
/*
***
@@ -2641,7 +2650,6 @@ static int arcmsr_iop_confirm(struct Ada
break;
case ACB_ADAPTER_TYPE_B: {
- unsigned long post_queue_phyaddr;
uint32_t __iomem *rwbuffer;
struct MessageUnit_B *reg = acb->pmuB;
@@ -2653,16 +2661,15 @@ static int arcmsr_iop_confirm(struct Ada
acb->host->host_no);
return 1;
}
- post_queue_phyaddr = acb->dma_coherent_handle2;
rwbuffer = reg->message_rwbuffer;
/* driver "set config" signature */
[PATCH v1.3 13/18] arcmsr: fix ioctl data read/write error for adapter type C
From: Ching Huang
Rewrite ioctl entry and its relate functions.
This patch fix ioctl data read/write error and change data I/O access from byte
to Dword.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c
b/drivers/scsi/arcmsr/arcmsr_attr.c
--- a/drivers/scsi/arcmsr/arcmsr_attr.c 2014-02-06 17:47:24.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_attr.c 2014-04-29 17:10:42.0 +0800
@@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_
struct AdapterControlBlock *acb = (struct AdapterControlBlock *)
host->hostdata;
uint8_t *pQbuffer,*ptmpQbuffer;
int32_t allxfer_len = 0;
+ unsigned long flags;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
/* do message unit read. */
ptmpQbuffer = (uint8_t *)buf;
- while ((acb->rqbuf_firstindex != acb->rqbuf_lastindex)
- && (allxfer_len < 1031)) {
+ spin_lock_irqsave(&acb->rqbuffer_lock, flags);
+ if (acb->rqbuf_firstindex != acb->rqbuf_lastindex) {
pQbuffer = &acb->rqbuffer[acb->rqbuf_firstindex];
- memcpy(ptmpQbuffer, pQbuffer, 1);
- acb->rqbuf_firstindex++;
- acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
- ptmpQbuffer++;
- allxfer_len++;
+ if (acb->rqbuf_firstindex > acb->rqbuf_lastindex) {
+ if ((ARCMSR_MAX_QBUFFER - acb->rqbuf_firstindex) >=
1032) {
+ memcpy(ptmpQbuffer, pQbuffer, 1032);
+ acb->rqbuf_firstindex += 1032;
+ acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
+ allxfer_len = 1032;
+ } else {
+ if (((ARCMSR_MAX_QBUFFER -
acb->rqbuf_firstindex)
+ + acb->rqbuf_lastindex) > 1032) {
+ memcpy(ptmpQbuffer, pQbuffer,
+ ARCMSR_MAX_QBUFFER
+ - acb->rqbuf_firstindex);
+ ptmpQbuffer += ARCMSR_MAX_QBUFFER
+ - acb->rqbuf_firstindex;
+ memcpy(ptmpQbuffer, acb->rqbuffer, 1032
+ - (ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex));
+ acb->rqbuf_firstindex = 1032 -
+ (ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex);
+ allxfer_len = 1032;
+ } else {
+ memcpy(ptmpQbuffer, pQbuffer,
+ ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex);
+ ptmpQbuffer += ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex;
+ memcpy(ptmpQbuffer, acb->rqbuffer,
+ acb->rqbuf_lastindex);
+ allxfer_len = ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex +
+ acb->rqbuf_lastindex;
+ acb->rqbuf_firstindex =
+ acb->rqbuf_lastindex;
+ }
+ }
+ } else {
+ if ((acb->rqbuf_lastindex - acb->rqbuf_firstindex) >
1032) {
+ memcpy(ptmpQbuffer, pQbuffer, 1032);
+ acb->rqbuf_firstindex += 1032;
+ allxfer_len = 1032;
+ } else {
+ memcpy(ptmpQbuffer, pQbuffer,
acb->rqbuf_lastindex
+ - acb->rqbuf_firstindex);
+ allxfer_len = acb->rqbuf_lastindex -
+ acb->rqbuf_firstindex;
+ acb->rqbuf_firstindex = acb->rqbuf_lastindex;
+ }
+ }
}
if (acb->acb_flags & ACB_F_IOPDATA_OVERFLOW) {
struct QBUFFER __iomem *prbuffer;
- uint8_t __iomem *iop_data;
- int32_t iop_len;
-
acb->acb_flags &= ~ACB_F_IOPDATA_OVERFLOW;
prbuffer = arcmsr_get_iop_rqbuffer(acb);
- iop_data = prbuffer->data;
- iop_len = readl(&prbuffer->data_len);
- while (iop_len > 0) {
- acb->rqbuffer[acb->rqbuf_lastindex] = readb(iop_data);
Re: [Xen-devel] [PATCH V3 1/4] Add XEN pvSCSI protocol description
>>> On 04.08.14 at 10:27, wrote: > +/* Requests from the frontend to the backend */ > + > +/* > + * Request a SCSI operation specified via a CDB in vscsiif_request.cmnd. > + * The target is specified via channel, id and lun. > + */ > +#define VSCSIIF_ACT_SCSI_CDB 1 > + > +/* > + * Request abort of a running operation for the specified target given by > + * channel, id, lun and the operation's rqid in ref_rqid. > + */ > +#define VSCSIIF_ACT_SCSI_ABORT 2 > + > +/* > + * Request a device reset of the specified target (channel and id). > + */ > +#define VSCSIIF_ACT_SCSI_RESET 3 While I realize you don't want to support it, leaving out VSCSIIF_ACT_SCSI_SG_PRESET altogether from this header may lead people to the false impression that its number is available for other use. I would generally recommend the Linux headers to not deviate from the master ones more than absolutely necessary, keeping what isn't needed/wanted by Linux at least in commented out form. Jan -- 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 v1.3 14/18] arcmsr: fix sparse waring and error
From: Ching Huang
Fix sparse utility checking error and warning.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:46:30.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:45:46.0 +0800
@@ -78,7 +78,7 @@ MODULE_VERSION(ARCMSR_DRIVER_VERSION);
#defineARCMSR_SLEEPTIME10
#defineARCMSR_RETRYCOUNT 12
-wait_queue_head_t wait_q;
+static wait_queue_head_t wait_q;
static int arcmsr_iop_message_xfer(struct AdapterControlBlock *acb,
struct scsi_cmnd *cmd);
static int arcmsr_iop_confirm(struct AdapterControlBlock *acb);
@@ -371,7 +371,7 @@ static uint8_t arcmsr_hbaB_wait_msgint_r
static uint8_t arcmsr_hbaC_wait_msgint_ready(struct AdapterControlBlock *pACB)
{
- struct MessageUnit_C *phbcmu = (struct MessageUnit_C *)pACB->pmuC;
+ struct MessageUnit_C __iomem *phbcmu = pACB->pmuC;
int i;
for (i = 0; i < 2000; i++) {
@@ -421,7 +421,7 @@ static void arcmsr_hbaB_flush_cache(stru
static void arcmsr_hbaC_flush_cache(struct AdapterControlBlock *pACB)
{
- struct MessageUnit_C *reg = (struct MessageUnit_C *)pACB->pmuC;
+ struct MessageUnit_C __iomem *reg = pACB->pmuC;
int retry_count = 30;/* enlarge wait flush adapter cache time: 10
minute */
writel(ARCMSR_INBOUND_MESG0_FLUSH_CACHE, ®->inbound_msgaddr0);
writel(ARCMSR_HBCMU_DRV2IOP_MESSAGE_CMD_DONE, ®->inbound_doorbell);
@@ -842,7 +842,7 @@ static uint8_t arcmsr_hbaB_abort_allcmd(
}
static uint8_t arcmsr_hbaC_abort_allcmd(struct AdapterControlBlock *pACB)
{
- struct MessageUnit_C *reg = (struct MessageUnit_C *)pACB->pmuC;
+ struct MessageUnit_C __iomem *reg = pACB->pmuC;
writel(ARCMSR_INBOUND_MESG0_ABORT_CMD, ®->inbound_msgaddr0);
writel(ARCMSR_HBCMU_DRV2IOP_MESSAGE_CMD_DONE, ®->inbound_doorbell);
if (!arcmsr_hbaC_wait_msgint_ready(pACB)) {
@@ -930,7 +930,7 @@ static u32 arcmsr_disable_outbound_ints(
}
break;
case ACB_ADAPTER_TYPE_C:{
- struct MessageUnit_C *reg = (struct MessageUnit_C *)acb->pmuC;
+ struct MessageUnit_C __iomem *reg = acb->pmuC;
/* disable all outbound interrupt */
orig_mask = readl(®->host_int_mask); /* disable outbound
message0 int */
writel(orig_mask|ARCMSR_HBCMU_ALL_INTMASKENABLE,
®->host_int_mask);
@@ -1054,8 +1054,9 @@ static void arcmsr_done4abort_postqueue(
/*clear all outbound posted Q*/
writel(ARCMSR_DOORBELL_INT_CLEAR_PATTERN,
reg->iop2drv_doorbell); /* clear doorbell interrupt */
for (i = 0; i < ARCMSR_MAX_HBB_POSTQUEUE; i++) {
- if ((flag_ccb = readl(®->done_qbuffer[i])) != 0) {
- writel(0, ®->done_qbuffer[i]);
+ flag_ccb = reg->done_qbuffer[i];
+ if (flag_ccb != 0) {
+ reg->done_qbuffer[i] = 0;
pARCMSR_CDB = (struct ARCMSR_CDB
*)(acb->vir2phy_offset+(flag_ccb << 5));/*frame must be 32 bytes aligned*/
pCCB = container_of(pARCMSR_CDB, struct
CommandControlBlock, arcmsr_cdb);
error = (flag_ccb &
ARCMSR_CCBREPLY_FLAG_ERROR_MODE0) ? true : false;
@@ -1068,7 +1069,7 @@ static void arcmsr_done4abort_postqueue(
}
break;
case ACB_ADAPTER_TYPE_C: {
- struct MessageUnit_C *reg = acb->pmuC;
+ struct MessageUnit_C __iomem *reg = acb->pmuC;
struct ARCMSR_CDB *pARCMSR_CDB;
uint32_t flag_ccb, ccb_cdb_phy;
bool error;
@@ -1186,7 +1187,7 @@ static void arcmsr_enable_outbound_ints(
}
break;
case ACB_ADAPTER_TYPE_C: {
- struct MessageUnit_C *reg = acb->pmuC;
+ struct MessageUnit_C __iomem *reg = acb->pmuC;
mask = ~(ARCMSR_HBCMU_UTILITY_A_ISR_MASK |
ARCMSR_HBCMU_OUTBOUND_DOORBELL_ISR_MASK|ARCMSR_HBCMU_OUTBOUND_POSTQUEUE_ISR_MASK);
writel(intmask_org & mask, ®->host_int_mask);
acb->outbound_int_enable = ~(intmask_org & mask) & 0x000f;
@@ -1273,12 +1274,12 @@ static void arcmsr_post_ccb(struct Adapt
uint32_t ending_index, index = reg->postq_index;
ending_index = ((index + 1) % ARCMSR_MAX_HBB_POSTQUEUE);
- writel(0, ®->post_qbuffer[ending_index]);
+ reg->post_qbuffer[ending_index] = 0;
if (arcmsr_cdb->Flags & ARCMSR_CDB_FLAG_SGL_BSIZE) {
- writel(cdb_phyaddr | ARCMSR_CCBPOST_FLAG_SGL_BSIZE,\
-®->post_qbuffer[index]);
+ reg->post_qbuffer[index] =
+
[PATCH v1.3 15/18] arcmsr: modify some character string
From: Ching Huang
Revise comment and some character strings.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:45:46.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:46:46.0 +0800
@@ -2,11 +2,10 @@
***
**O.S : Linux
** FILE NAME : arcmsr_hba.c
-**BY: Nick Cheng
-** Description: SCSI RAID Device Driver for
-**ARECA RAID Host adapter
+**BY: Nick Cheng, C.L. Huang
+** Description: SCSI RAID Device Driver for Areca RAID Controller
***
-** Copyright (C) 2002 - 2005, Areca Technology Corporation All rights reserved
+** Copyright (C) 2002 - 2014, Areca Technology Corporation All rights reserved
**
** Web site: www.areca.com.tw
** E-mail: supp...@areca.com.tw
@@ -70,8 +69,8 @@
#include
#include
#include "arcmsr.h"
-MODULE_AUTHOR("Nick Cheng ");
-MODULE_DESCRIPTION("ARECA (ARC11xx/12xx/16xx/1880) SATA/SAS RAID Host Bus
Adapter");
+MODULE_AUTHOR("Nick Cheng, C.L. Huang ");
+MODULE_DESCRIPTION("Areca ARC11xx/12xx/16xx/188x SAS/SATA RAID Controller
Driver");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_VERSION(ARCMSR_DRIVER_VERSION);
@@ -126,8 +125,7 @@ static int arcmsr_adjust_disk_queue_dept
static struct scsi_host_template arcmsr_scsi_host_template = {
.module = THIS_MODULE,
- .name = "ARCMSR ARECA SATA/SAS RAID Controller"
- ARCMSR_DRIVER_VERSION,
+ .name = "Areca SAS/SATA RAID driver",
.info = arcmsr_info,
.queuecommand = arcmsr_queue_command,
.eh_abort_handler = arcmsr_abort,
@@ -3398,14 +3396,14 @@ static const char *arcmsr_info(struct Sc
case PCI_DEVICE_ID_ARECA_1680:
case PCI_DEVICE_ID_ARECA_1681:
case PCI_DEVICE_ID_ARECA_1880:
- type = "SAS";
+ type = "SAS/SATA";
break;
default:
- type = "X-TYPE";
+ type = "unknown";
+ raid6 = 0;
break;
}
- sprintf(buf, "Areca %s Host Adapter RAID Controller%s\n %s",
- type, raid6 ? "( RAID6 capable)" : "",
- ARCMSR_DRIVER_VERSION);
+ sprintf(buf, "Areca %s RAID Controller %s\narcmsr version %s\n",
+ type, raid6 ? "(RAID6 capable)" : "", ARCMSR_DRIVER_VERSION);
return buf;
}
--
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 v1.3 16/18] arcmsr: support new adapter ARC12x4 series
From: Ching Huang
Add code for supporting Areca new Raid adapter ARC12x4 series.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:29:54.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:06:04.0 +0800
@@ -63,12 +63,17 @@ struct device_attribute;
#define ARCMSR_MAX_QBUFFER
4096
#define ARCMSR_DEFAULT_SG_ENTRIES
38
#define ARCMSR_MAX_HBB_POSTQUEUE
264
+#define ARCMSR_MAX_ARC1214_POSTQUEUE 256
+#define ARCMSR_MAX_ARC1214_DONEQUEUE 257
#define ARCMSR_MAX_XFER_LEN
0x26000 /* 152K */
#define ARCMSR_CDB_SG_PAGE_LENGTH
256
#define ARCMST_NUM_MSIX_VECTORS4
#ifndef PCI_DEVICE_ID_ARECA_1880
#define PCI_DEVICE_ID_ARECA_1880 0x1880
#endif
+#ifndef PCI_DEVICE_ID_ARECA_1214
+ #define PCI_DEVICE_ID_ARECA_12140x1214
+#endif
/*
**
**
@@ -339,6 +344,56 @@ struct FIRMWARE_INFO
#define ARCMSR_HBCMU_MESSAGE_FIRMWARE_OK 0x8000
/*
***
+**SPEC. for Areca Type D adapter
+***
+*/
+#define ARCMSR_ARC1214_CHIP_ID 0x4
+#define ARCMSR_ARC1214_CPU_MEMORY_CONFIGURATION0x8
+#define ARCMSR_ARC1214_I2_HOST_INTERRUPT_MASK 0x00034
+#define ARCMSR_ARC1214_SAMPLE_RESET0x00100
+#define ARCMSR_ARC1214_RESET_REQUEST 0x00108
+#define ARCMSR_ARC1214_MAIN_INTERRUPT_STATUS 0x00200
+#define ARCMSR_ARC1214_PCIE_F0_INTERRUPT_ENABLE0x0020C
+#define ARCMSR_ARC1214_INBOUND_MESSAGE00x00400
+#define ARCMSR_ARC1214_INBOUND_MESSAGE10x00404
+#define ARCMSR_ARC1214_OUTBOUND_MESSAGE0 0x00420
+#define ARCMSR_ARC1214_OUTBOUND_MESSAGE1 0x00424
+#define ARCMSR_ARC1214_INBOUND_DOORBELL0x00460
+#define ARCMSR_ARC1214_OUTBOUND_DOORBELL 0x00480
+#define ARCMSR_ARC1214_OUTBOUND_DOORBELL_ENABLE0x00484
+#define ARCMSR_ARC1214_INBOUND_LIST_BASE_LOW 0x01000
+#define ARCMSR_ARC1214_INBOUND_LIST_BASE_HIGH 0x01004
+#define ARCMSR_ARC1214_INBOUND_LIST_WRITE_POINTER 0x01018
+#define ARCMSR_ARC1214_OUTBOUND_LIST_BASE_LOW 0x01060
+#define ARCMSR_ARC1214_OUTBOUND_LIST_BASE_HIGH 0x01064
+#define ARCMSR_ARC1214_OUTBOUND_LIST_COPY_POINTER 0x0106C
+#define ARCMSR_ARC1214_OUTBOUND_LIST_READ_POINTER 0x01070
+#define ARCMSR_ARC1214_OUTBOUND_INTERRUPT_CAUSE0x01088
+#define ARCMSR_ARC1214_OUTBOUND_INTERRUPT_ENABLE 0x0108C
+#define ARCMSR_ARC1214_MESSAGE_WBUFFER 0x02000
+#define ARCMSR_ARC1214_MESSAGE_RBUFFER 0x02100
+#define ARCMSR_ARC1214_MESSAGE_RWBUFFER0x02200
+/* Host Interrupt Mask */
+#define ARCMSR_ARC1214_ALL_INT_ENABLE 0x1010
+#define ARCMSR_ARC1214_ALL_INT_DISABLE 0x
+/* Host Interrupt Status */
+#define ARCMSR_ARC1214_OUTBOUND_DOORBELL_ISR 0x1000
+#define ARCMSR_ARC1214_OUTBOUND_POSTQUEUE_ISR 0x0010
+/* DoorBell*/
+#define ARCMSR_ARC1214_DRV2IOP_DATA_IN_READY 0x0001
+#define ARCMSR_ARC1214_DRV2IOP_DATA_OUT_READ 0x0002
+/*inbound message 0 ready*/
+#define ARCMSR_ARC1214_IOP2DRV_DATA_WRITE_OK 0x0001
+/*outbound DATA WRITE isr door bell clear*/
+#define ARCMSR_ARC1214_IOP2DRV_DATA_READ_OK0x0002
+/*outbound message 0 ready*/
+#define ARCMSR_ARC1214_IOP2DRV_MESSAGE_CMD_DONE0x0200
+/*outbound message cmd isr door bell clear*/
+/*ARCMSR_HBAMU_MESSAGE_FIRMWARE_OK*/
+#define ARCMSR_ARC1214_MESSAGE_FIRMWARE_OK 0x8000
+#define ARCMSR_ARC1214_OUTBOUND_LIST_INTERRUPT_CLEAR 0x0001
+/*
+***
**ARECA SCSI COMMAND DESCRIPTOR BLOCK size 0x1F8 (504)
***
*/
@@ -496,6 +551,55 @@ struct MessageUnit_C{
uint32_tmsgcode_rwbuffer[256]; /*2200 23FF*/
};
/*
+*
+** Messaging Unit (MU) of Type D processor
+*
+*/
+struct InBound_SRB {
+ uint32_t addressLow; /* pointer to SRB block */
+ uint32_t addressHigh;
+ uint32_t length; /* i
[PATCH v1.3 17/18] arcmsr: modify calling scsi_scan_host after all initialization done
From: Ching Huang
Modify calling scsi_scan_host until all initialization done.
And fix error path of free allocated resource.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:46:52.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:47:02.0 +0800
@@ -112,6 +112,7 @@ static void arcmsr_hbaD_message_isr(stru
static void arcmsr_hardware_reset(struct AdapterControlBlock *acb);
static const char *arcmsr_info(struct Scsi_Host *);
static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
+static void arcmsr_free_irq(struct pci_dev *, struct AdapterControlBlock *);
static int arcmsr_adjust_disk_queue_depth(struct scsi_device *sdev,
int queue_depth, int reason)
{
@@ -774,12 +775,11 @@ static int arcmsr_probe(struct pci_dev *
}
error = scsi_add_host(host, &pdev->dev);
if(error){
- goto RAID_controller_stop;
+ goto free_ccb_pool;
}
if (arcmsr_request_irq(pdev, acb) == FAILED)
goto scsi_host_remove;
arcmsr_iop_init(acb);
- scsi_scan_host(host);
INIT_WORK(&acb->arcmsr_do_message_isr_bh, arcmsr_message_isr_bh_fn);
atomic_set(&acb->rq_map_token, 16);
atomic_set(&acb->ante_token_value, 16);
@@ -791,13 +791,17 @@ static int arcmsr_probe(struct pci_dev *
add_timer(&acb->eternal_timer);
if(arcmsr_alloc_sysfs_attr(acb))
goto out_free_sysfs;
+ scsi_scan_host(host);
return 0;
out_free_sysfs:
-scsi_host_remove:
- scsi_remove_host(host);
-RAID_controller_stop:
+ del_timer_sync(&acb->eternal_timer);
+ flush_work(&acb->arcmsr_do_message_isr_bh);
arcmsr_stop_adapter_bgrb(acb);
arcmsr_flush_adapter_cache(acb);
+ arcmsr_free_irq(pdev, acb);
+scsi_host_remove:
+ scsi_remove_host(host);
+free_ccb_pool:
arcmsr_free_ccb_pool(acb);
free_hbb_mu:
arcmsr_free_mu(acb);
--
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 v1.3 18/18] arcmsr: replace flush_scheduled_work() by flush_work()
From: Ching Huang To prevent flushing entire workqueue, replace flush_scheduled_work() by flush_work(). Signed-off-by: Ching Huang --- diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c --- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:47:02.0 +0800 +++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-04 16:47:12.0 +0800 @@ -841,7 +841,7 @@ static int arcmsr_suspend(struct pci_dev intmask_org = arcmsr_disable_outbound_ints(acb); arcmsr_free_irq(pdev, acb); del_timer_sync(&acb->eternal_timer); - flush_scheduled_work(); + flush_work(&acb->arcmsr_do_message_isr_bh); arcmsr_stop_adapter_bgrb(acb); arcmsr_flush_adapter_cache(acb); arcmsr_enable_outbound_ints(acb, intmask_org); -- 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: [Xen-devel] [PATCH V3 1/4] Add XEN pvSCSI protocol description
On 08/04/2014 12:10 PM, Jan Beulich wrote: On 04.08.14 at 10:27, wrote: +/* Requests from the frontend to the backend */ + +/* + * Request a SCSI operation specified via a CDB in vscsiif_request.cmnd. + * The target is specified via channel, id and lun. + */ +#define VSCSIIF_ACT_SCSI_CDB 1 + +/* + * Request abort of a running operation for the specified target given by + * channel, id, lun and the operation's rqid in ref_rqid. + */ +#define VSCSIIF_ACT_SCSI_ABORT 2 + +/* + * Request a device reset of the specified target (channel and id). + */ +#define VSCSIIF_ACT_SCSI_RESET 3 While I realize you don't want to support it, leaving out VSCSIIF_ACT_SCSI_SG_PRESET altogether from this header may lead people to the false impression that its number is available for other use. I would generally recommend the Linux headers to not deviate from the master ones more than absolutely necessary, keeping what isn't needed/wanted by Linux at least in commented out form. Okay. I'll re-add the #define Juergen -- 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: use correct formats in printk()
On Mon, Aug 04, 2014 at 10:48:37AM +0200, Martin Kepplinger wrote: > Use %llu for u64 and %u for int. Not the other way round. I've already queued up an equivalent fix in my core-for-3.17 branch, I just need James to pull it into the scsi for-next tree. -- 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] Save command pool address of Scsi_Host
On Mon, Aug 04, 2014 at 06:22:59AM +0200, Juergen Gross wrote: > OTOH it would be possible to just delete .cmd_pool in the template when > deleting the pool. I'll send a patch doing this and you can decide > whether to take it or to use the other solution. > > I'm not sure which to prefer: the init/remove version is simple, while > the dynamic version requires no changes in the driver's source and the > pool's resources are allocated only when really needed. the init/remove version needs the driver to call a per-host template function/method from module_init/exit, something we've avoided successfully for the last 10 years. -- 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] Save command pool address of Scsi_Host
On Sat, Aug 02, 2014 at 12:24:34AM +0400, James Bottomley wrote: > Wait, that's not right at all. There looks to be a thinko in the > command pool handling code. We have both a cmd_pool in the host > structure and in the host template structure, but there's confusion > about which one we're supposed to be using. For anything in the I/O path: shost->cmd_pool, for finding a pool created for a specific host template: template->cmd_pool. > The origin of confusion seems to be the reference counting in the pool > itself ... you want the same pool for all hosts, since they can only > have one cmd_size, but you want it created on first host use and > destroyed again on the last one. > > If you take this patch, a host that attached, detaches and then attaches > a host will panic because it will use a freed pool structure. Yes, it also needs to set hostt->cmd_pool to NULL when the last reference goes away. -- 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 V3] Save command pool address of Scsi_Host
On Mon, Aug 04, 2014 at 06:26:09AM +0200, jgr...@suse.com wrote: > From: Juergen Gross > > If a scsi host driver specifies .cmd_len in it's scsi_host_template, a > driver's > private command pool is needed. scsi_find_host_cmd_pool() will locate it, but > scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template. > > This will result in an access error when the host is removed. > > Avoid the problem by saving the address of a new allocated command pool where > it is expected and delete it again when the pool is destroyed. I don't really like the double pointer passing - just NULLing out the pointer in the caller where needed seems cleaner. Otherwise this looks good to me. -- 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: [ANNOUNCE] scsi patch queue tree updated
On Fri, Aug 01, 2014 at 04:32:01PM -0400, James Bottomley wrote: > On Fri, 2014-08-01 at 05:20 -0700, Christoph Hellwig wrote: > > I've pushed out updates to both the core-for-3.17 and drivers-for-3.17 > > branches. > > So I'm afraid we missed the last -next build on these, so they can't go > in with the early SCSI pull. I'm open to doing one mid merge window, > but Linus tends not to like that. I don't think there are any hard and fast rules. The core-for-3.17 commit is a trivial printk specifier regression fix for something introduced in the 3.17 merge window, so pulling it in is an absolute non-brainer. The drivers side are a bunch of smaller fixes for iscsi and pm8001 which never have been a problem to put in near the end of the merge window, especially if they have a few more days linux-next exposure in Linux-next even after the 3.16 release. They absolutely would be candidates for a second pull even if they'd miss the first pull. -- 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/arcmsr: Add timeout module parameter
To modify the timeout on a queue please use blk_queue_rq_timeout in the slave_configure method instead of poking directly into the block timer, which won't work e.g. for the blk-mq path. But this really needs an explanation on why you'd need a configurable timeout to start with. -- 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 V3] Save command pool address of Scsi_Host
On 08/04/2014 01:08 PM, Christoph Hellwig wrote: On Mon, Aug 04, 2014 at 06:26:09AM +0200, jgr...@suse.com wrote: From: Juergen Gross If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's private command pool is needed. scsi_find_host_cmd_pool() will locate it, but scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template. This will result in an access error when the host is removed. Avoid the problem by saving the address of a new allocated command pool where it is expected and delete it again when the pool is destroyed. I don't really like the double pointer passing - just NULLing out the pointer in the caller where needed seems cleaner. I wanted to avoid to spread this, but I don't mind doing it. V4 is coming... Juergen -- 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 V4] Save command pool address of Scsi_Host
From: Juergen Gross
If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's
private command pool is needed. scsi_find_host_cmd_pool() will locate it, but
scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template.
This will result in an access error when the host is removed.
Avoid the problem by saving the address of a new allocated command pool where
it is expected.
Signed-off-by: Juergen Gross
---
drivers/scsi/scsi.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..f654ac1 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -380,6 +380,10 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
pool->slab_flags |= SLAB_CACHE_DMA;
pool->gfp_mask = __GFP_DMA;
}
+
+ if (hostt->cmd_size)
+ hostt->cmd_pool = pool;
+
return pool;
}
@@ -424,8 +428,10 @@ out:
out_free_slab:
kmem_cache_destroy(pool->cmd_slab);
out_free_pool:
- if (hostt->cmd_size)
- scsi_free_host_cmd_pool(pool);
+ if (hostt->cmd_size) {
+ scsi_free_host_cmd_pool(hostt->cmd_pool);
+ hostt->cmd_pool = NULL;
+ }
goto out;
}
@@ -447,8 +453,10 @@ static void scsi_put_host_cmd_pool(struct Scsi_Host *shost)
if (!--pool->users) {
kmem_cache_destroy(pool->cmd_slab);
kmem_cache_destroy(pool->sense_slab);
- if (hostt->cmd_size)
- scsi_free_host_cmd_pool(pool);
+ if (hostt->cmd_size) {
+ scsi_free_host_cmd_pool(hostt->cmd_pool);
+ hostt->cmd_pool = NULL;
+ }
}
mutex_unlock(&host_cmd_pool_mutex);
}
--
1.8.4.5
--
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 V4] Save command pool address of Scsi_Host
On 08/04/2014 01:24 PM, jgr...@suse.com wrote:
From: Juergen Gross
If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's
private command pool is needed. scsi_find_host_cmd_pool() will locate it, but
scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template.
This will result in an access error when the host is removed.
Avoid the problem by saving the address of a new allocated command pool where
it is expected.
Please ignore, should have used pool instead hostt->cm_pool for calling
scsi_free_host_cmd_pool(). V5 follows...
Juergen
Signed-off-by: Juergen Gross
---
drivers/scsi/scsi.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..f654ac1 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -380,6 +380,10 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
pool->slab_flags |= SLAB_CACHE_DMA;
pool->gfp_mask = __GFP_DMA;
}
+
+ if (hostt->cmd_size)
+ hostt->cmd_pool = pool;
+
return pool;
}
@@ -424,8 +428,10 @@ out:
out_free_slab:
kmem_cache_destroy(pool->cmd_slab);
out_free_pool:
- if (hostt->cmd_size)
- scsi_free_host_cmd_pool(pool);
+ if (hostt->cmd_size) {
+ scsi_free_host_cmd_pool(hostt->cmd_pool);
+ hostt->cmd_pool = NULL;
+ }
goto out;
}
@@ -447,8 +453,10 @@ static void scsi_put_host_cmd_pool(struct Scsi_Host *shost)
if (!--pool->users) {
kmem_cache_destroy(pool->cmd_slab);
kmem_cache_destroy(pool->sense_slab);
- if (hostt->cmd_size)
- scsi_free_host_cmd_pool(pool);
+ if (hostt->cmd_size) {
+ scsi_free_host_cmd_pool(hostt->cmd_pool);
+ hostt->cmd_pool = NULL;
+ }
}
mutex_unlock(&host_cmd_pool_mutex);
}
--
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 V5] Save command pool address of Scsi_Host
From: Juergen Gross
If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's
private command pool is needed. scsi_find_host_cmd_pool() will locate it, but
scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template.
This will result in an access error when the host is removed.
Avoid the problem by saving the address of a new allocated command pool where
it is expected.
Signed-off-by: Juergen Gross
---
drivers/scsi/scsi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..b0cef5b 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -380,6 +380,10 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
pool->slab_flags |= SLAB_CACHE_DMA;
pool->gfp_mask = __GFP_DMA;
}
+
+ if (hostt->cmd_size)
+ hostt->cmd_pool = pool;
+
return pool;
}
@@ -424,8 +428,10 @@ out:
out_free_slab:
kmem_cache_destroy(pool->cmd_slab);
out_free_pool:
- if (hostt->cmd_size)
+ if (hostt->cmd_size) {
scsi_free_host_cmd_pool(pool);
+ hostt->cmd_pool = NULL;
+ }
goto out;
}
@@ -447,8 +453,10 @@ static void scsi_put_host_cmd_pool(struct Scsi_Host *shost)
if (!--pool->users) {
kmem_cache_destroy(pool->cmd_slab);
kmem_cache_destroy(pool->sense_slab);
- if (hostt->cmd_size)
+ if (hostt->cmd_size) {
scsi_free_host_cmd_pool(pool);
+ hostt->cmd_pool = NULL;
+ }
}
mutex_unlock(&host_cmd_pool_mutex);
}
--
1.8.4.5
--
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: [ANNOUNCE] scsi patch queue tree updated
Hi Christoph, On Mon, 4 Aug 2014 04:11:47 -0700 Christoph Hellwig wrote: > > On Fri, Aug 01, 2014 at 04:32:01PM -0400, James Bottomley wrote: > > On Fri, 2014-08-01 at 05:20 -0700, Christoph Hellwig wrote: > > > I've pushed out updates to both the core-for-3.17 and drivers-for-3.17 > > > branches. > > > > So I'm afraid we missed the last -next build on these, so they can't go > > in with the early SCSI pull. I'm open to doing one mid merge window, > > but Linus tends not to like that. You realise that neither of these in linux-next as the scsi-core and scsi-drivers trees had for-3.16 branches in the last round. I assume I should just drop these trees completely from linux-next? -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [ANNOUNCE] scsi patch queue tree updated
On Mon, Aug 04, 2014 at 09:30:59PM +1000, Stephen Rothwell wrote: > You realise that neither of these in linux-next as the scsi-core and > scsi-drivers trees had for-3.16 branches in the last round. I assume I > should just drop these trees completely from linux-next? Well, they get pulled in through James, so you can drop them for now. I mostly put you on Cc so you could comment wether there are any hard rules on how long even those simple fixes should be in linux-next. I know you've put up stats for a few of the last merge windows about patches that weren't in linux-next, so there's been some tracking of it for sure. -- 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: [ANNOUNCE] scsi patch queue tree updated
Hi Christoph, On Mon, 4 Aug 2014 04:34:04 -0700 Christoph Hellwig wrote: > > On Mon, Aug 04, 2014 at 09:30:59PM +1000, Stephen Rothwell wrote: > > You realise that neither of these in linux-next as the scsi-core and > > scsi-drivers trees had for-3.16 branches in the last round. I assume I > > should just drop these trees completely from linux-next? > > Well, they get pulled in through James, so you can drop them for now. Will do. > I mostly put you on Cc so you could comment wether there are any hard > rules on how long even those simple fixes should be in linux-next. I > know you've put up stats for a few of the last merge windows about > patches that weren't in linux-next, so there's been some tracking of it > for sure. If they are simple, clear fixes, then maybe a day or two just for build coverage, but it is very much up to the maintainer. There are always a few poatches that get through late (quote a few of which I suspect have been "in train", just not yet published in the maintainer's tree). And, of course, real fixes go in just about anytime ... I don't think we believe in hard rules for anything :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH V5] Save command pool address of Scsi_Host
On 08/04/2014 02:30 PM, jgr...@suse.com wrote:
> From: Juergen Gross
>
> If a scsi host driver specifies .cmd_len in it's scsi_host_template, a
> driver's
> private command pool is needed. scsi_find_host_cmd_pool() will locate it, but
> scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template.
>
> This will result in an access error when the host is removed.
>
> Avoid the problem by saving the address of a new allocated command pool where
> it is expected.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/scsi/scsi.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 88d46fe..b0cef5b 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -380,6 +380,10 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
> pool->slab_flags |= SLAB_CACHE_DMA;
> pool->gfp_mask = __GFP_DMA;
> }
> +
> + if (hostt->cmd_size)
> + hostt->cmd_pool = pool;
> +
> return pool;
> }
>
> @@ -424,8 +428,10 @@ out:
> out_free_slab:
> kmem_cache_destroy(pool->cmd_slab);
> out_free_pool:
> - if (hostt->cmd_size)
> + if (hostt->cmd_size) {
> scsi_free_host_cmd_pool(pool);
I disagree I liked the V4 version better. It is much nicer on the review
that we NULL the same one we pass in with no need for context that's outside
of this scope
Just my $0.017
Boaz
> + hostt->cmd_pool = NULL;
> + }
> goto out;
> }
>
> @@ -447,8 +453,10 @@ static void scsi_put_host_cmd_pool(struct Scsi_Host
> *shost)
> if (!--pool->users) {
> kmem_cache_destroy(pool->cmd_slab);
> kmem_cache_destroy(pool->sense_slab);
> - if (hostt->cmd_size)
> + if (hostt->cmd_size) {
> scsi_free_host_cmd_pool(pool);
> + hostt->cmd_pool = NULL;
> + }
> }
> mutex_unlock(&host_cmd_pool_mutex);
> }
>
--
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 V5] Save command pool address of Scsi_Host
On 08/04/2014 01:49 PM, Boaz Harrosh wrote:
On 08/04/2014 02:30 PM, jgr...@suse.com wrote:
From: Juergen Gross
If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's
private command pool is needed. scsi_find_host_cmd_pool() will locate it, but
scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template.
This will result in an access error when the host is removed.
Avoid the problem by saving the address of a new allocated command pool where
it is expected.
Signed-off-by: Juergen Gross
---
drivers/scsi/scsi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..b0cef5b 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -380,6 +380,10 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
pool->slab_flags |= SLAB_CACHE_DMA;
pool->gfp_mask = __GFP_DMA;
}
+
+ if (hostt->cmd_size)
+ hostt->cmd_pool = pool;
+
return pool;
}
@@ -424,8 +428,10 @@ out:
out_free_slab:
kmem_cache_destroy(pool->cmd_slab);
out_free_pool:
- if (hostt->cmd_size)
+ if (hostt->cmd_size) {
scsi_free_host_cmd_pool(pool);
I disagree I liked the V4 version better. It is much nicer on the review
that we NULL the same one we pass in with no need for context that's outside
of this scope
:-)
I'm fine with either version.
Juergen
Just my $0.017
Boaz
+ hostt->cmd_pool = NULL;
+ }
goto out;
}
@@ -447,8 +453,10 @@ static void scsi_put_host_cmd_pool(struct Scsi_Host *shost)
if (!--pool->users) {
kmem_cache_destroy(pool->cmd_slab);
kmem_cache_destroy(pool->sense_slab);
- if (hostt->cmd_size)
+ if (hostt->cmd_size) {
scsi_free_host_cmd_pool(pool);
+ hostt->cmd_pool = NULL;
+ }
}
mutex_unlock(&host_cmd_pool_mutex);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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 V3 2/4] Introduce xen-scsifront module
On 04/08/14 09:27, jgr...@suse.com wrote:
>
> +
> +static void scsifront_backend_changed(struct xenbus_device *dev,
> + enum xenbus_state backend_state)
> +{
> + struct vscsifrnt_info *info = dev_get_drvdata(&dev->dev);
> +
> + DPRINTK("%p %u %u\n", dev, dev->state, backend_state);
> +
> + switch (backend_state) {
> + case XenbusStateUnknown:
> + case XenbusStateInitialising:
> + case XenbusStateInitWait:
> + case XenbusStateInitialised:
> + break;
> +
> + case XenbusStateConnected:
> + scsifront_read_backend_params(dev, info);
> + if (xenbus_read_driver_state(dev->nodename) ==
> + XenbusStateInitialised) {
> + scsifront_do_lun_hotplug(info, VSCSIFRONT_OP_ADD_LUN);
> + }
> +
> + if (dev->state != XenbusStateConnected)
> + xenbus_switch_state(dev, XenbusStateConnected);
> + break;
> +
> + case XenbusStateClosed:
> + if (dev->state == XenbusStateClosed)
> + break;
> + /* Missed the backend's Closing state -- fallthrough */
> + case XenbusStateClosing:
> + scsifront_disconnect(info);
> + break;
> +
> + case XenbusStateReconfiguring:
> + scsifront_do_lun_hotplug(info, VSCSIFRONT_OP_DEL_LUN);
> + xenbus_switch_state(dev, XenbusStateReconfiguring);
> + break;
> +
> + case XenbusStateReconfigured:
> + scsifront_do_lun_hotplug(info, VSCSIFRONT_OP_ADD_LUN);
> + xenbus_switch_state(dev, XenbusStateConnected);
> + break;
> + }
> +}
I would like to see this state machine in common code but I'm not going
to insist on it since this is a existing driver.
Xen related parts:
Acked-by: David Vrabel
David
--
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 V3 3/4] Introduce XEN scsiback module
On 04/08/14 09:27, jgr...@suse.com wrote: > From: Juergen Gross > > Introduces the XEN pvSCSI backend. With pvSCSI it is possible for a XEN domU > to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands > are passed to the pvSCSI backend in a driver domain (usually Dom0) which is > owner of the physical device. This allows e.g. to use SCSI tape drives in a > XEN domU. Xen related parts Acked-by: David Vrabel David -- 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: [RFC] hpsa: work in progress "lockless monster" patches
On 07/31/2014 05:16 PM, scame...@beardog.cce.hp.com wrote:
> On Thu, Jul 31, 2014 at 03:56:13PM +0200, Tomas Henzl wrote:
>> Hi Steve, Webb,
>>
>> let me start with the part most important for me - from my previous mail
>> "And please have a look at "[PATCH] hpsa: refine the pci enble/disable
>> handling"
>> I posted in June and add it to your series or review in the list. Thanks."
> Ok. I will try to get to this.
> (some customer issues have been eating a lot of my time this week).
>
> When I first saw that patch I knew that Rob Elliott had a lot of patches in
> the
> works that did a lot of cleanup to the initialization code, so I expect some
> conflicts.
Thanks, I think I should port my patch on top of your series and repost.
>
>> other comments see below
>>
>>> Hi Tomas,
>>>
>>> Thanks for taking a look and for the feedback. I'm actually the one
>>> responsible for the changes you refer to, so I'll try to address your
>>> comments.
>>>
>>>
>>> On 7/30/14 10:55 AM, Tomas Henzl wrote:
I'm not sure if I got it right,
it seems it uses the same cmd_pool for both alloc function,
from (0 - reserved_cmds) it's cmd_alloc and above that it's handled
by cmd_tagged_alloc.
The logic in both functions seems to be valid for me.
>>> Good. With Christoph's proposed changes, the block layer will select a
>>> tag for I/O requests, and it provides for the driver to reserve part of
>>> the tag space for its own use. Thus, HPSA uses a common pool for both
>>> I/O requests and internally-driven requests (IOCTLs, aborts, etc.), and
>>> we index the pool using the tag. The code is this way mostly to
>>> minimize change from the previous version, but it's also handy in terms
>>> of managing the pool (i.e., there is a single pool to administer,
>>> instead of two, and all the items are initialized the same way, etc.).
>>> The portion of the pool which is reserved to the driver (the
>>> low-numbered tags) continues to be managed through a bitmap, just as it
>>> was prior to this change; the bitmap does cover the whole pool (which is
>>> a historical artifact), but the higher bits are never set, since
>>> allocation of those entries is determined by the tag from the block
>>> layer -- nevertheless, it is convenient to have the map extend over the
>>> whole pool in certain corner cases (such as resets).
>>>
>>>
In cmd_tagged_alloc "Thus, there should never be a collision here between
two requests" if this is true you don't need the refcount and just a simple
flag were sufficient for your other needs. (And maybe you get to ~971k
IOPS..)
>>> :-) The code previously had the reference count in there to close
>>> certain race conditions' asynchronous accesses to the command block
>>> (e.g., between an abort and a completing command). We hope that, using
>>> the block layer tags, those races no longer occur, but there didn't seem
>>> to be any point in removing the reference count until we'd had more
>>> experience with the code...and, in a fit of healthy paranoia I added the
>>> check to which you refer. Unfortunately, in some of Rob Elliott's
>>> recent tests, he managed to drive a case where the check triggers. So,
>>> until we reconcile that, I'm inclined to leave the check in place
>>> (hopefully it's not costing a full 1k IOPS :-) ).
>> Let us assume that the block layer never sends duplicate tags to the driver,
>> I think there are some weaknesses in the way how it's implemented,
>> for example here - from fail_all_outstanding_cmds:
>> refcount = atomic_inc_return(&c->refcount);
>> if (refcount > 1) {
>> ...
>> finish_cmd(c); - this finishes the command
>> and the tag might be now reused,
>> when that happens you'll see a race
>> atomic_dec(&h->commands_outstanding);
>> failcount++;
>> }
>> else {what happens when right now comes a call from block
>> layer?}
>> cmd_free(h, c);
>>
>> When references are used it usually means, that when refcount==0 that
>> a release function frees the resources, in this case it is the tag number.
>> In your implementation you should ensure that when you signal
>> to the upper layer that the tag is free, that nothing else holds the
>> reference.
>> If this is true the conclusion is that you don't need this kind of references
>> and a simple flag just to debug not yet fixed races is enough.
> Part of the motivation is we want to have this code be workable for distros
> that may not have the necessary kernel changes for us to be able to use the
> block layer tagging (e.g. tags reserved for driver use). So I am floating
> the block layer tag patches, keeping them at the top of my stack of patches
> so that all this lockless stuff can still work even without using the block
> l
Re: [RFC] hpsa: work in progress "lockless monster" patches
On 08/01/2014 06:40 PM, Webb Scales wrote:
> On 7/31/14 9:56 AM, Tomas Henzl wrote:
In cmd_tagged_alloc "Thus, there should never be a collision here between
two requests" if this is true you don't need the refcount and just a simple
flag were sufficient for your other needs. (And maybe you get to ~971k
IOPS..)
>>> :-) The code previously had the reference count in there to close
>>> certain race conditions' asynchronous accesses to the command block
>>> (e.g., between an abort and a completing command). We hope that, using
>>> the block layer tags, those races no longer occur, but there didn't seem
>>> to be any point in removing the reference count until we'd had more
>>> experience with the code...and, in a fit of healthy paranoia I added the
>>> check to which you refer. Unfortunately, in some of Rob Elliott's
>>> recent tests, he managed to drive a case where the check triggers. So,
>>> until we reconcile that, I'm inclined to leave the check in place
>>> (hopefully it's not costing a full 1k IOPS :-) ).
>> Let us assume that the block layer never sends duplicate tags to the driver,
>> I think there are some weaknesses in the way how it's implemented,
>> for example here - from fail_all_outstanding_cmds:
>> refcount = atomic_inc_return(&c->refcount);
>> if (refcount > 1) {
>> ...
>> finish_cmd(c); - this finishes the command
>> and the tag might be now reused,
>> when that happens you'll see a race
>> atomic_dec(&h->commands_outstanding);
>> failcount++;
>> }
>> else {what happens when right now comes a call from block
>> layer?}
> The next call from the block layer should find that the controller has
> been marked as locked-up and return immediately with a no-connect error
> (even before trying to allocate an HPSA command block), so I don't think
> there is a race or conflict.
OK, the 'locked-up' logic and when it's activated - I mean I don't understand
every
part of your driver. I have just seen that in your current implementation
of cmd_tagged_alloc that you only print a debug message and continue with the
same block.
That might bring some issues later.
>
>
>> When references are used it usually means, that when refcount==0 that
>> a release function frees the resources, in this case it is the tag number.
>> In your implementation you should ensure that when you signal
>> to the upper layer that the tag is free, that nothing else holds the
>> reference.
> Actually, in this case, the resource is the HPSA command block which
> corresponds to the tag number. But, you are correct that trying to
> manage them separately is apt to cause problems. Having the
> cmd_[tagged_]free() routine make the call to scsi_done() -- only when
> the reference count is dropping to zero -- is an interesting
> suggestion...but I'll have to do considerable investigation before I can
> proceed with that.
I'm not sure if this is doable (calling scsi_done when refcount drops to zero)
I just see a weakness of the code that you can have called the scsi_done
and still having a refcount > 0.
There is work in progress on the code and I have found no more issues (better
said
maybe issues), so thanks for sharing the code now.
--tomash
>
>
>> If this is true the conclusion is that you don't need this kind of references
>> and a simple flag just to debug not yet fixed races is enough.
>> I'm maybe wrong because I don't understand what you want to protect
>> in the above example, so that makes me to have some doubts if I understand
>> the code properly.
> Absent the block layer support, the HPSA code has to be able to defend
> against various races where there may be more than two interested
> parties looking at the command block -- so a simple flag will not
> suffice. On the other hand, with the block layer support in place,
> we're hoping that we can get rid of the reference count altogether, but
> we're not there, yet.
>
>
> Webb
>
>
>
On 07/25/2014 09:28 PM, scame...@beardog.cce.hp.com wrote:
> hpsa: Work In Progress: "lockless monster" patches
>
> To be clear, I am not suggesting that these patches be merged at this
> time.
>
> This patchset is vs. Christoph Hellwig's scsi-mq.4 branch which
> may be found here: git://git.infradead.org/users/hch/scsi.git
>
> We've been working for a long time on a patchset for hpsa to remove
> all the locks from the main i/o path in pursuit of high IOPS. Some
> of that work is already upstream, but a lot more of it is not quite
> yet ready to be merged. However, I think we've "gone dark" for a bit
> too long on this, and even though the patches aren't really ready to
> be merged just yet, I thought I should let other people who might be
> interested have a lo
Re: [PATCH 1/15] block copy: initial XCOPY offload support
On Tue 2014-07-15 15:34:47, Mikulas Patocka wrote: > This is Martin Petersen's xcopy patch > (https://git.kernel.org/cgit/linux/kernel/git/mkp/linux.git/commit/?h=xcopy&id=0bdeed274e16b3038a851552188512071974eea8) > with some bug fixes, ported to the current kernel. > > This patch makes it possible to use the SCSI XCOPY command. > > We create a bio that has REQ_COPY flag in bi_rw and a bi_copy structure > that defines the source device. The target device is defined in the > bi_bdev and bi_iter.bi_sector. > > There is a new BLKCOPY ioctl that makes it possible to use XCOPY from > userspace. The ioctl argument is a pointer to an array of four uint64_t > values. But it is there only for block devices, right? Is there plan to enable tools such as /bin/cp to use XCOPY? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [ANNOUNCE] scsi patch queue tree updated
On Mon, 2014-08-04 at 04:11 -0700, Christoph Hellwig wrote: > On Fri, Aug 01, 2014 at 04:32:01PM -0400, James Bottomley wrote: > > On Fri, 2014-08-01 at 05:20 -0700, Christoph Hellwig wrote: > > > I've pushed out updates to both the core-for-3.17 and drivers-for-3.17 > > > branches. > > > > So I'm afraid we missed the last -next build on these, so they can't go > > in with the early SCSI pull. I'm open to doing one mid merge window, > > but Linus tends not to like that. > > I don't think there are any hard and fast rules. True, but the hardest of our semi-liquid rules is nothing in the merge window that wasn't in -next first. > The core-for-3.17 commit is a trivial printk specifier regression fix for > something introduced in the 3.17 merge window, so pulling it in is > an absolute non-brainer. > > The drivers side are a bunch of smaller fixes for iscsi and pm8001 which > never have been a problem to put in near the end of the merge window, > especially if they have a few more days linux-next exposure in > Linux-next even after the 3.16 release. They absolutely would be > candidates for a second pull even if they'd miss the first pull. OK, since I have to do a second pull anyway we might as well follow the rules. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] kexec: Export kexec_in_progress
On 07/28/2014 03:28 PM, Brian King wrote: > > Export kexec_in_progress for use by device drivers and other modules > to optimize kexec boot. > > Signed-off-by: Brian King > --- > > kernel/kexec.c |2 ++ > 1 file changed, 2 insertions(+) > > diff -puN kernel/kexec.c~kexec_export_in_prog kernel/kexec.c > --- linux/kernel/kexec.c~kexec_export_in_prog 2014-07-23 17:05:24.851887935 > -0500 > +++ linux-bjking1/kernel/kexec.c 2014-07-23 17:05:24.856887970 -0500 > @@ -1716,3 +1716,5 @@ int kernel_kexec(void) > mutex_unlock(&kexec_mutex); > return error; > } > + > +EXPORT_SYMBOL_GPL(kexec_in_progress); Eric, Can I get an ack on this so we can take this entire series through the SCSI tree? Thanks! Brian -- 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] Save command pool address of Scsi_Host
On Mon, 2014-08-04 at 04:03 -0700, Christoph Hellwig wrote: > On Mon, Aug 04, 2014 at 06:22:59AM +0200, Juergen Gross wrote: > > OTOH it would be possible to just delete .cmd_pool in the template when > > deleting the pool. I'll send a patch doing this and you can decide > > whether to take it or to use the other solution. > > > > I'm not sure which to prefer: the init/remove version is simple, while > > the dynamic version requires no changes in the driver's source and the > > pool's resources are allocated only when really needed. > > the init/remove version needs the driver to call a per-host template > function/method from module_init/exit, something we've avoided > successfully for the last 10 years. Well, not exactly. You're correct we eliminated the scsi module initialisatio which served as per-template initialisation. However, when we eliminated this, there was one thing: the proc directory, that was still per-template not per host. If you look, it already has a ref counting mechanism similar to the one you reinvented for the pools. Since it's easy to get this wrong, we should just generalise the existing mechanism for anything today that wants to be per-host-template so people have more difficulty getting it wrong and so we consolidate code that's the same. However, this is way beyond a simple bug fix. Do the bug fix first, then we can consolidate the code as an enhancement. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
