usb: gadget: f_fs: Fail waiting IO after eps disabled

Normally in epfile_io() and epfile_ioctl(), if the endpoint is
not enabled the system call will block waiting until the endpoint
is enabled. During a USB disconnect, the function's endpoints get
disabled, so that if an IO call occurs right after that, it would
perform the same blocking wait. From the kernel perspective this
is indistinguishable from an IO call happening after the function
is first initialized but not yet enabled. Hence a userspace
process would be blocked and unaware of the cable disconnection.

For userspace daemons such as ADB, this can be a problem since its
read/write threads cannot be reaped until the I/O call returns,
which won't happen until the cable is reconnected. In that case,
the previous pending read/write would proceed to get successfully
queued. In the case of a read, the previous read consumes data
meant for the new session, and in the case of a write, stale data
could be sent to the host.

To fix this, add a counter to keep track of the epfile's open
status. Upon the endpoint getting disabled mark the endpoint as
invalid so as to fail subsequent IOs until the epfile is fully
closed. Returning -ENODEV upon failure should allow the userspace
process to close the file, so that it can reopen and begin a new
session.

Change-Id: I655ffdaa03485753431ff05dc521bf8d1b463ff1
Signed-off-by: Jack Pham <jackp@codeaurora.org>