summaryrefslogtreecommitdiff
path: root/drivers/scsi/esas2r/esas2r.h
AgeCommit message (Collapse)Author
2019-02-08scsi: ata: Use unsigned int for cmd's type in ioctls in scsi_host_templateNathan Chancellor
Clang warns several times in the scsi subsystem (trimmed for brevity): drivers/scsi/hpsa.c:6209:7: warning: overflow converting case value to switch condition type (2147762695 to 18446744071562347015) [-Wswitch] case CCISS_GETBUSTYPES: ^ drivers/scsi/hpsa.c:6208:7: warning: overflow converting case value to switch condition type (2147762694 to 18446744071562347014) [-Wswitch] case CCISS_GETHEARTBEAT: ^ The root cause is that the _IOC macro can generate really large numbers, which don't fit into type 'int', which is used for the cmd parameter in the ioctls in scsi_host_template. My research into how GCC and Clang are handling this at a low level didn't prove fruitful. However, looking at the rest of the kernel tree, all ioctls use an 'unsigned int' for the cmd parameter, which will fit all of the _IOC values in the scsi/ata subsystems. Make that change because none of the ioctls expect a negative value for any command, it brings the ioctls inline with the reset of the kernel, and it removes ambiguity, which is never good when dealing with compilers. Link: https://github.com/ClangBuiltLinux/linux/issues/85 Link: https://github.com/ClangBuiltLinux/linux/issues/154 Link: https://github.com/ClangBuiltLinux/linux/issues/157 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Bradley Grove <bgrove@attotech.com> Acked-by: Don Brace <don.brace@microsemi.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-03-19scsi: esas2r: remove initialization / cleanup dead woodChristoph Hellwig
esas2r has been converted to hotplug style initialization long ago, but kept various remant of the old-style scsi_module.c initialization around. Remove those. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-06-12scsi: esas2r: Replace semaphore fs_api_semaphore with mutexBinoy Jayan
The semaphore 'fs_api_semaphore' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.jayan@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-06-12scsi: esas2r: Replace semaphore fm_api_semaphore with mutexBinoy Jayan
The semaphore 'fm_api_semaphore' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.jayan@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2014-11-24scsi: drop reason argument from ->change_queue_depthChristoph Hellwig
Drop the now unused reason argument from the ->change_queue_depth method. Also add a return value to scsi_adjust_queue_depth, and rename it to scsi_change_queue_depth now that it can be used as the default ->change_queue_depth implementation. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Hannes Reinecke <hare@suse.de>
2014-11-12scsi: don't set tagging state from scsi_adjust_queue_depthChristoph Hellwig
Remove the tagged argument from scsi_adjust_queue_depth, and just let it handle the queue depth. For most drivers those two are fairly separate, given that most modern drivers don't care about the SCSI "tagged" status of a command at all, and many old drivers allow queuing of multiple untagged commands in the driver. Instead we start out with the ->simple_tags flag set before calling ->slave_configure, which is how all drivers actually looking at ->simple_tags except for one worke anyway. The one other case looks broken, but I've kept the behavior as-is for now. Except for that we only change ->simple_tags from the ->change_queue_type, and when rejecting a tag message in a single driver, so keeping this churn out of scsi_adjust_queue_depth is a clear win. Now that the usage of scsi_adjust_queue_depth is more obvious we can also remove all the trivial instances in ->slave_alloc or ->slave_configure that just set it to the cmd_per_lun default. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
2014-11-12scsi: provide a generic change_queue_type methodChristoph Hellwig
Most drivers use exactly the same implementation, so provide it as a library function. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
2013-10-25[SCSI] esas2r: Fixes for big-endian platformsBradley Grove
In esas2r_format_init_msg(), sgl_page_size and epoch_time params are converted to little endian and the firmware version read from the hba is converted to cpu endianess. In esas2r_rq_init_request, correct and simplify the construction of the SCSI handle. These fixes are the result of testing on a PPC64 machine. Signed-off-by: Bradley Grove <bgrove@attotech.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2013-10-25[SCSI] esas2r: Directly call kernel functions for atomic bit operationsBradley Grove
Previously the code embedded the kernel's test_bit/clear_bit functions in wrappers that accepted u32 parameters. The wrapper cast these parameters to longs before passing them to the kernel's bit functions. This did not work properly on platforms with 64-bit longs. Signed-off-by: Bradley Grove <bgrove@attotech.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2013-09-03[SCSI] esas2r: ATTO Technology ExpressSAS 6G SAS/SATA RAID Adapter DriverBradley Grove
This is a new driver for ATTO Technology's ExpressSAS series of hardware RAID adapters. It supports the following adapters: - ExpressSAS R60F - ExpressSAS R680 - ExpressSAS R608 - ExpressSAS R644 Signed-off-by: Bradley Grove <bgrove@attotech.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>