From e4c4b4dce628d529bc073952ddcf272d307d06bd Mon Sep 17 00:00:00 2001 From: Alex Elder Date: Thu, 26 Mar 2015 21:25:08 -0500 Subject: [PATCH] greybus: reduce the ranting Cut out some comments that are no longer operative. Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman --- drivers/staging/greybus/es1.c | 27 --------------------------- drivers/staging/greybus/es2.c | 27 --------------------------- 2 files changed, 54 deletions(-) diff --git a/drivers/staging/greybus/es1.c b/drivers/staging/greybus/es1.c index af8e7b33270b..f559c1d53e89 100644 --- 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. - * - */ } 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 23e27782fe9f..a6c47a3dd62f 100644 --- 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. - * - */ } static void apb1_log_get(struct es1_ap_dev *es1) -- 2.39.2