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 find into type 'int', which is used for the cmd paremeter 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 to take a negative value, 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 <natechancel...@gmail.com>
Reviewed-by: Bart Van Assche <bvanass...@acm.org>

 static void __exit esas2r_exit(void)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 
ff67ef5d5347..28cfd3d01c5a 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -251,10 +251,11 @@ static int number_of_controllers;

Acked-by: Don Brace <don.br...@microsemi.com>

 
diff --git a/drivers/scsi/smartpqi/smartpqi_init.c 
b/drivers/scsi/smartpqi/smartpqi_init.c
index f564af8949e8..5d9ccbab7581 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -6043,7 +6043,8 @@ static int pqi_passthru_ioctl(struct pqi_ctrl_info 
*ctrl_info, void __user *arg)
        return rc;
 }

Acked-by: Don Brace <don.br...@microsemi.com>
 

Reply via email to