linux-kernel - Re: [PATCH] usb: storage: freecom: Fixed several coding style issues.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100710164946.GI17833@buzzloop.caiaq.de>
Date:	Sat, 10 Jul 2010 18:49:46 +0200
From:	Daniel Mack <daniel@...aq.de>
To:	Martin Enderleit <menderleit@...il.com>
Cc:	mdharm-usb@...-eyed-alien.net, gregkh@...e.de,
	linux-usb@...r.kernel.org, usb-storage@...ts.one-eyed-alien.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: storage: freecom: Fixed several coding style
 issues.

On Sat, Jul 10, 2010 at 04:50:12PM +0200, Martin Enderleit wrote:
> Fixed several coding style issues in freecom.c.
> 
> Signed-off-by: Martin Enderleit <menderleit@...il.com>
> ---
>  drivers/usb/storage/freecom.c |   23 +++++++++++------------
>  1 files changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/usb/storage/freecom.c b/drivers/usb/storage/freecom.c
> index 54cc942..6542ca4 100644
> --- a/drivers/usb/storage/freecom.c
> +++ b/drivers/usb/storage/freecom.c
> @@ -269,7 +269,7 @@ static int freecom_transport(struct scsi_cmnd *srb, struct us_data *us)
>  	/* The firmware will time-out commands after 20 seconds. Some commands
>  	 * can legitimately take longer than this, so we use a different
>  	 * command that only waits for the interrupt and then sends status,
> -	 * without having to send a new ATAPI command to the device. 
> +	 * without having to send a new ATAPI command to the device.
>  	 *
>  	 * NOTE: There is some indication that a data transfer after a timeout
>  	 * may not work, but that is a condition that should never happen.
> @@ -324,14 +324,14 @@ static int freecom_transport(struct scsi_cmnd *srb, struct us_data *us)
>  
>  	/* Find the length we desire to read. */
>  	switch (srb->cmnd[0]) {
> -		case INQUIRY:
> -		case REQUEST_SENSE:		/* 16 or 18 bytes? spec says 18, lots of devices only have 16 */
> -		case MODE_SENSE:
> -		case MODE_SENSE_10:
> -			length = le16_to_cpu(fst->Count);
> -			break;
> -		default:
> -			length = scsi_bufflen(srb);
> +	case INQUIRY:
> +	case REQUEST_SENSE:	/* 16 or 18 bytes? spec says 18, lots of devices only have 16 */
> +	case MODE_SENSE:
> +	case MODE_SENSE_10:
> +		length = le16_to_cpu(fst->Count);
> +		break;
> +	default:
> +		length = scsi_bufflen(srb);
>  	}
>  
>  	/* verify that this amount is legal */
> @@ -414,7 +414,7 @@ static int freecom_transport(struct scsi_cmnd *srb, struct us_data *us)
>  		/* should never hit here -- filtered in usb.c */
>  		US_DEBUGP ("freecom unimplemented direction: %d\n",
>  				us->srb->sc_data_direction);
> -		// Return fail, SCSI seems to handle this better.
> +		/* Return fail, SCSI seems to handle this better. */
>  		return USB_STOR_TRANSPORT_FAILED;
>  		break;

While at it, you can also remove this useless break;

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/