- /*
- * "drain_on_open" enables a hack to work around a firmware
- * issue observed on network functions, in particular MBIM
- * functions.
- *
- * Quoting section 7 of the CDC-WMC r1.1 specification:
- *
- * "The firmware shall interpret GetEncapsulatedResponse as a
- * request to read response bytes. The firmware shall send
- * the next wLength bytes from the response. The firmware
- * shall allow the host to retrieve data using any number of
- * GetEncapsulatedResponse requests. The firmware shall
- * return a zero- length reply if there are no data bytes
- * available.
- *
- * The firmware shall send ResponseAvailable notifications
- * periodically, using any appropriate algorithm, to inform
- * the host that there is data available in the reply
- * buffer. The firmware is allowed to send ResponseAvailable
- * notifications even if there is no data available, but
- * this will obviously reduce overall performance."
- *
- * These requirements, although they make equally sense, are
- * often not implemented by network functions. Some firmwares
- * will queue data indefinitely, without ever resending a
- * notification. The result is that the driver and firmware
- * loses "syncronization" if the driver ever fails to respond
- * to a single notification, something which easily can happen
- * on release(). When this happens, the driver will appear to
- * never receive notifications for the most current data. Each
- * notification will only cause a single read, which returns
- * the oldest data in the firmware's queue.
- *
- * The "drain_on_open" hack resolves the situation by draining
- * data from the firmware until none is returned, without a
- * prior notification.
- *
- * This will inevitably race with the firmware, risking that
- * we read data from the device before handling the associated
- * notification. To make things worse, some of the devices
- * needing the hack do not implement the "return zero if no
- * data is available" requirement either. Instead they return
- * an error on the subsequent read in this case. This means
- * that "winning" the race can cause an unexpected EIO to
- * userspace.
- *
- * "winning" the race is more likely on resume() than on
- * open(), and the unexpected error is more harmful in the
- * middle of an open session. The hack is therefore only
- * applied on open(), and not on resume() where it logically
- * would be equally necessary. So we define open() as the only
- * driver <-> device "syncronization point". Should we happen
- * to lose a notification after open(), then syncronization
- * will be lost until release()
- *
- * The hack should not be enabled for CDC WDM devices
- * conforming to the CDC-WMC r1.1 specification. This is
- * ensured by setting drain_on_open to false in wdm_probe().
- */
- if (drain_on_open)
- set_bit(WDM_DRAIN_ON_OPEN, &desc->flags);
-