[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B7A7E86.4090806@gmail.com>
Date: Tue, 16 Feb 2010 12:16:22 +0100
From: Roel Kluin <roel.kluin@...il.com>
To: Joe Perches <joe@...ches.com>
CC: Matthew Dharm <mdharm-usb@...-eyed-alien.net>,
linux-usb@...r.kernel.org, usb-storage@...ts.one-eyed-alien.net,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] USB: misplaced parenthesis
> I think it'd be better if you hoisted the set'n'test out of the if()
ok, I agree.
> Isn't this the current logic?
>
> result = usbat_write_block(us, USBAT_ATA, srb->cmnd, 12,
> srb->cmnd[0] == GPCMD_BLANK ? 75 : 10, 0);
> result = result != USB_STOR_TRANSPORT_GOOD;
> if (result)
> return result;
Thanks for your comments, Yes that was the current logic, which I thought
was wrong, but now I think it could also be obscurely written but right:
in drivers/usb/storage/transport.h line 100 note the definitions:
#define USB_STOR_TRANSPORT_GOOD 0 /* Transport good, command good */
#define USB_STOR_TRANSPORT_FAILED 1 /* Transport good, command failed */
#define USB_STOR_TRANSPORT_NO_SENSE 2 /* Command failed, no auto-sense */
#define USB_STOR_TRANSPORT_ERROR 3 /* Transport bad (i.e. device dead) */
With the current logic usbat_hp8200e_transport() returns TRANSPORT_FAILED,
even if usbat_write_block() returned TRANSPORT_NO_SENSE or TRANSPORT_ERROR.
This could be intended, but then the author chose a very obscure way to write:
if (usbat_write_block(us, USBAT_ATA, srb->cmnd, 12,
srb->cmnd[0] == GPCMD_BLANK ? 75 : 10, 0) !=
USB_STOR_TRANSPORT_GOOD)
return USB_STOR_TRANSPORT_FAILED;
Or was the parenthesis misplaced and should it really be:
result = usbat_write_block(us, USBAT_ATA, srb->cmnd, 12,
srb->cmnd[0] == GPCMD_BLANK ? 75 : 10, 0);
if (result != USB_STOR_TRANSPORT_GOOD)
return result;
Maybe someone with the specs/more knowledge of this driver could look into
this?
Thanks, Roel
--
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/
Powered by blists - more mailing lists