USB-ethernet State Handling

Description

When the USB-ethernet package is initialized by a call to usbs_eth_init it installs usbs_eth_state_change_handler to handle USB state changes. This allows the package to detect when the connection between the host and the peripheral is established or broken, resulting in internal calls to usbs_eth_enable and usbs_eth_disable respectively. This is appropriate if no other code needs to access the USB device. However, if there is other code, either other USB-related packages or the application itself, that needs to perform I/O over the USB bus, then typically the USB-ethernet package should not have exclusive access to state change events. Instead, the assumption is that higher-level code, typically provided by the application, will install an alternative state change handler in the control endpoint data structure after the call to usbs_eth_init. This alternative handler will either chain into usbs_eth_state_change_handler when appropriate, or else it will invoke usbs_eth_enable and usbs_eth_disable directly. For further details of state change handlers and control endpoints generally, see the documentation for the common USB-slave package.

Similarly, usbs_eth_init will install usbs_eth_class_control_handler in the control endpoint data structure as the appropriate handler for class-specific USB control messages. This code will handle the ethernet-specific control messages , for example requests by the host to enable or disable promiscuous mode or to obtain the MAC address. If the USB device is not shared with any other code then this is both necessary and sufficient. However, if other code is involved and if that code also needs to process certain control messages, higher-level code should install its own handler and chain to the USB-ethernet one when appropriate. It should be noted that the request code is encoded in just a single byte, so there is a real possibility that exactly the same number will be used by different protocols for different requests. Any such problems will have to be identified and resolved by application developers, and may involve modifying the source code for the USB-ethernet package.

As an alternative to chaining the state change handler, higher-level code can instead call usbs_eth_disable and usbs_eth_enable directly. These functions may also be called if the USB-ethernet package should become inactive for reasons not related directly to events on the USB bus. The main effect of usbs_eth_enable is to restart receive operations and to allow transmits. The main effect of usbs_eth_disable is to block further transmits: any current receive operations need to be aborted at the USB level, for example by halting the appropriate endpoint.