Realistically, I think it's okay. The entire philosophy is that the actual data-moving routines indicate good/bad/short, and the transport routines interpret that.
What you actually see is a proper transcription of old code to new, but
what you realize with the new code is that this code doesn't (and never
did) really handle the short case.
Matt
On Mon, Sep 23, 2002 at 01:57:31AM +0200, [EMAIL PROTECTED] wrote:
> I have not looked at this at all, maybe this is nonsense,
> but at very first sight, when I see this patch, with code like
>
> result = usb_storage_bulk_transport(us, SCSI_DATA_READ,
> buf, bulklen, 0);
> - if (result != USB_STOR_TRANSPORT_GOOD)
> + kfree(buf);
> + if (result != USB_STOR_XFER_GOOD) {
> US_DEBUGP("Result for bulk_transport in sddr09_read_sg %d\n",
> result);
> + return USB_STOR_TRANSPORT_ERROR;
> + }
> - kfree(buf);
> -
> - return result;
> + return USB_STOR_TRANSPORT_GOOD;
>
>
> it looks like information is being thrown away. Some low level
> routine returns a result, and earlier we reported this result
> to higher levels. But this patch changes the result codes
> used by the lower levels, which means that we no longer can
> transmit result codes, and the code is reduced to a simplistic
> "did he say it was OK? Then return OK. Otherwise return ERROR".
>
> Often it is useful to have more detailed information.
> For example, a short transport can be OK.
>
> Andries
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
I think the problem is there's a nut loose on your keyboard.
-- Greg to Customer
User Friendly, 1/5/1999
msg08066/pgp00000.pgp
Description: PGP signature
