staging/fwserial: Update TODO file per reviewer comments
Pursuant to this review https://lkml.org/lkml/2012/11/12/500
by Stefan Richter, update the TODO file.
- Clarify purpose of TODO file
- Remove firewire item #4. As discussed in this conversation
https://lkml.org/lkml/2012/11/13/564 knowing the AR buffer size
is not a hard requirement. The required rx buffer size can be
determined experimentally.
- Remove firewire item #5. This was a private note for further
experimentation.
- Change firewire item #1. Change suggested header from uapi header
to kernel-only header.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff --git a/drivers/staging/fwserial/TODO b/drivers/staging/fwserial/TODO
index ffe47d1..8dae8fb 100644
--- a/drivers/staging/fwserial/TODO
+++ b/drivers/staging/fwserial/TODO
@@ -1,5 +1,5 @@
-TODOs
------
+TODOs prior to this driver moving out of staging
+------------------------------------------------
1. Implement retries for RCODE_BUSY, RCODE_NO_ACK and RCODE_SEND_ERROR
- I/O is handled asynchronously which presents some issues when error
conditions occur.
@@ -11,14 +11,9 @@
-- Issues with firewire stack --
1. This driver uses the same unregistered vendor id that the firewire core does
(0xd00d1e). Perhaps this could be exposed as a define in
- firewire-constants.h?
+ firewire.h?
3. Maybe device_max_receive() and link_speed_to_max_payload() should be
taken up by the firewire core?
-4. To avoid dropping rx data while still limiting the maximum buffering,
- the size of the AR context must be known. How to expose this to drivers?
-5. Explore if bigger AR context will reduce RCODE_BUSY responses
- (or auto-grow to certain max size -- but this would require major surgery
- as the current AR is contiguously mapped)
-- Issues with TTY core --
1. Hack for alternate device name scheme