diff options
Diffstat (limited to 'drivers/staging/fwserial/TODO')
| -rw-r--r-- | drivers/staging/fwserial/TODO | 37 |
1 files changed, 37 insertions, 0 deletions
diff --git a/drivers/staging/fwserial/TODO b/drivers/staging/fwserial/TODO new file mode 100644 index 000000000000..726900548eae --- /dev/null +++ b/drivers/staging/fwserial/TODO @@ -0,0 +1,37 @@ +TODOs +----- +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. +2. Implement _robust_ console on top of this. The existing prototype console + driver is not ready for the big leagues yet. +3. Expose means of controlling attach/detach of peers via sysfs. Include + GUID-to-port matching/whitelist/blacklist. + +-- 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? +2. MAX_ASYNC_PAYLOAD needs to be publicly exposed by core/ohci + - otherwise how will this driver know the max size of address window to + open for one packet write? +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 + - because udev no longer allows device renaming, devices should have + their proper names on creation. This is an issue for creating the + fwloop<n> device with the fwtty<n> devices because although duplicating + roughly the same operations as tty_port_register_device() isn't difficult, + access to the tty_class & tty_fops is restricted in scope. + + This is currently being worked around in create_loop_device() by + extracting the tty_class ptr and tty_fops ptr from the previously created + tty devices. Perhaps an add'l api can be added -- eg., + tty_{port_}register_named_device(). |