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>

diff --git a/drivers/staging/greybus/es1.c b/drivers/staging/greybus/es1.c
index af8e7b33270b21ec3fb641d217ae42ec64640d01..f559c1d53e8931a3719d82252caa23bb83edc08a 100644 (file)
--- a/drivers/staging/greybus/es1.c
+++ b/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)

diff --git a/drivers/staging/greybus/es2.c b/drivers/staging/greybus/es2.c
index 23e27782fe9f740cdee7265aa6d5f0624afa440e..a6c47a3dd62f4ea6d7f7b12a81e1b6d62793bd9e 100644 (file)
--- a/drivers/staging/greybus/es2.c
+++ b/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)