iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

greybus: reduce the ranting

Browse Source 
Cut out some comments that are no longer operative.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
This commit is contained in:
Alex Elder 2015-03-26 21:25:08 -05:00 committed by Greg Kroah-Hartman
parent 66c98986c9
commit e4c4b4dce6
2 changed files with 0 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
drivers/staging/greybus/es1.c
View File

@ -451,34 +451,7 @@ static void cport_out_callback(struct urb *urb)
*/
data = urb->transfer_buffer + 1;
greybus_data_sent(hd, data, status);
free_urb(es1, urb);
/*
* Rest assured Greg, this craziness is getting fixed.
*
* Yes, you are right, we aren't telling anyone that the urb finished.
* "That's crazy! How does this all even work?" you might be saying.
* The "magic" is the idea that greybus works on the "operation" level,
* not the "send a buffer" level. All operations are "round-trip" with
* a response from the device that the operation finished, or it will
* time out. Because of that, we don't care that this urb finished, or
* failed, or did anything else, as higher levels of the protocol stack
* will handle completions and timeouts and the rest.
*
* This protocol is "needed" due to some hardware restrictions on the
* current generation of Unipro controllers. Think about it for a
* minute, this is a USB driver, talking to a Unipro bridge, impedance
* mismatch is huge, yet the Unipro controller are even more
* underpowered than this little USB controller. We rely on the round
* trip to keep stalls in the Unipro controllers from happening so that
* we can keep data flowing properly, no matter how slow it might be.
*
* Once again, a wonderful bus protocol cut down in its prime by a naive
* controller chip. We dream of the day we have a "real" HCD for
* Unipro. Until then, we suck it up and make the hardware work, as
* that's the job of the firmware and kernel.
* </rant>
*/
}
static void apb1_log_get(struct es1_ap_dev *es1)

27
drivers/staging/greybus/es2.c
View File

@ -451,34 +451,7 @@ static void cport_out_callback(struct urb *urb)
*/
data = urb->transfer_buffer + 1;
greybus_data_sent(hd, data, status);
free_urb(es1, urb);
/*
* Rest assured Greg, this craziness is getting fixed.
*
* Yes, you are right, we aren't telling anyone that the urb finished.
* "That's crazy! How does this all even work?" you might be saying.
* The "magic" is the idea that greybus works on the "operation" level,
* not the "send a buffer" level. All operations are "round-trip" with
* a response from the device that the operation finished, or it will
* time out. Because of that, we don't care that this urb finished, or
* failed, or did anything else, as higher levels of the protocol stack
* will handle completions and timeouts and the rest.
*
* This protocol is "needed" due to some hardware restrictions on the
* current generation of Unipro controllers. Think about it for a
* minute, this is a USB driver, talking to a Unipro bridge, impedance
* mismatch is huge, yet the Unipro controller are even more
* underpowered than this little USB controller. We rely on the round
* trip to keep stalls in the Unipro controllers from happening so that
* we can keep data flowing properly, no matter how slow it might be.
*
* Once again, a wonderful bus protocol cut down in its prime by a naive
* controller chip. We dream of the day we have a "real" HCD for
* Unipro. Until then, we suck it up and make the hardware work, as
* that's the job of the firmware and kernel.
* </rant>
*/
}
static void apb1_log_get(struct es1_ap_dev *es1)