[PATCH 1/2] block: cleanup error handling in sg_io

Make sure we always clean up through the out label and just have a single place to put the request. Signed-off-by: Christoph Hellwig --- block/scsi_ioctl.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c index 14695c6..c4e663

[PATCH 2/2] block: support > 16 byte CDBs for SG_IO

Signed-off-by: Christoph Hellwig --- block/scsi_ioctl.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c index c4e6633..a804f3e 100644 --- a/block/scsi_ioctl.c +++ b/block/scsi_ioctl.c @@ -288,8 +288,6 @@ static

support > 16 byte CDBs for blocklayer SG_IO

Follow the bsg and sg drivers to support large CDBs by allocation the larger than 16 byte CDB array if nessecary. -- 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-

Re: [PATCH 2/2] block: support > 16 byte CDBs for SG_IO

On 07/20/2014 01:23 PM, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig Hi Christoph I've quickly reviewed your code and have a few questions > --- > block/scsi_ioctl.c | 24 +--- > 1 file changed, 17 insertions(+), 7 deletions(-) > > diff --git a/block/scsi_ioc

Re: [PATCH 2/2] block: support > 16 byte CDBs for SG_IO

On Sun, Jul 20, 2014 at 02:47:49PM +0300, Boaz Harrosh wrote: > > So two things here: > - hdr->cmd_len is char so can be MAX of 255. I understand that 4 bytes > alignment is a SCSI > thing so you found no point of checking any max size? I don't see any point to force the aligmnet - the devices

[Bug 80711] SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN

https://bugzilla.kernel.org/show_bug.cgi?id=80711 --- Comment #1 from Tiziano Bacocco --- Created attachment 143541 --> https://bugzilla.kernel.org/attachment.cgi?id=143541&action=edit This patch allows using SG_FLAG_LUN_INHIBIT I hope i've not broken anything else , this patch allows using SG

Re: [PATCH 2/2] block: support > 16 byte CDBs for SG_IO

On 07/20/2014 04:27 PM, Christoph Hellwig wrote: > On Sun, Jul 20, 2014 at 02:47:49PM +0300, Boaz Harrosh wrote: >> >> So two things here: >> - hdr->cmd_len is char so can be MAX of 255. I understand that 4 bytes >> alignment is a SCSI >> thing so you found no point of checking any max size? >

Write cache and surface error behaviour

Hello list, I don't really understand this disk cache thing. Suppose a disk with write cache enabled of writeback type: Linux receives a write completed notification (a message from the disk) when the data has reached the cache of the disk. Correct? At that point it is not considered an in-flig

[PATCH] [SCSI] hpsa: Fix driver support flag initialisation on !x86

On !x86 we currently don't read the existing support flags: /home/benh/linux-3.14.13/drivers/scsi/hpsa.c:4375:17: warning: 'driver_support' is used uninitialized in this function [-Wuninitialized] driver_support |= ENABLE_UNIT_ATTN; ^ Signed-off-by: Ben Hutchings Fixes: 28e13

Re: [PATCH] [SCSI] hpsa: Fix driver support flag initialisation on !x86

On Mon, Jul 21, 2014 at 01:09:17AM +0100, Ben Hutchings wrote: > On !x86 we currently don't read the existing support flags: Arnd already sent this and I've included it in the for-3.17 queue. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majo

Re: [PATCH] [SCSI] hpsa: Fix driver support flag initialisation on !x86

On Sun, 2014-07-20 at 17:42 -0700, Christoph Hellwig wrote: > On Mon, Jul 21, 2014 at 01:09:17AM +0100, Ben Hutchings wrote: > > On !x86 we currently don't read the existing support flags: > > Arnd already sent this and I've included it in the for-3.17 queue. Thanks. Ben. -- Ben Hutchings Make

[PATCH 1/1] Drivers: scsi: storvsc: Add blist flags

Add blist flags to permit the reading of the VPD pages even when the target may claim SPC-2 compliance. MSFT targets currently claim SPC-2 compliance while they implement post SPC-2 features. With this patch we can correctly handle WRITE_SAME_16 issues. Signed-off-by: K. Y. Srinivasan --- driver

Re: [PATCH 0/25] Replace DEFINE_PCI_DEVICE_TABLE macro use

From: Benoit Taine Date: Fri, 18 Jul 2014 17:26:47 +0200 > We should prefer `const struct pci_device_id` over > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. > This issue was reported by checkpatch. > > A simplified version of the semantic patch that makes this change is as >

Re: [PATCH 1/3] scsi: update scsi_device_types

On 07/18/2014 05:17 PM, Christoph Hellwig wrote: Add two new device types, most importantly the zoned block device one. Split from an earlier patch by Hannes Reinecke. Signed-off-by: Christoph Hellwig --- drivers/scsi/scsi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi

Re: [PATCH 2/3] scsi: add a symbolic name for the ZBC device type

On 07/18/2014 05:17 PM, Christoph Hellwig wrote: Make sure we have a symbolic name for the ZBC type available, so that e.g. patch for a SATA to translate ZAC commands can make use of it. Signed-off-by: Christoph Hellwig --- include/scsi/scsi.h | 1 + 1 file changed, 1 insertion(+) diff --gi

Re: [PATCH 3/3] scsi: move the writeable from struct scsi_device to struct scsi_cd

On 07/18/2014 05:17 PM, Christoph Hellwig wrote: We currently set the field in common code based on the device type, but then only use it in the cdrom driver which also overrides the value previously set in the generic code. Just leave this entirely to the CDROM driver to make everyones life sim