greybus: reduce the ranting

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>

drivers/staging/greybus/es1.c

@@ -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)

drivers/staging/greybus/es2.c

@@ -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)