Found something interesting.
While researching the set_configuration() callback, I got curious, and did a find/grep, to find everyone who called it.
c:\Freescale_BM_USB_Stack_v5.0\Src\usb_core\device\sources\classes>find . -name *.[ch] | xargs grep set_configuration
./cdc/usb_cdc.c: cdc_obj_ptr->desc_callback.set_configuration((uint32_t)cdc_obj_ptr->controller_handle, (uint8_t)(*(uint16_t*)val));
./msd/usb_msc.c: msc_dev_ptr->desc_callback.set_configuration((uint32_t)msc_dev_ptr->controller_handle, (uint8_t)(*(uint16_t *)val));
It appears that only the CDC and MSC classes pass the SetConfiguration event to the application. The Audio, DFU, HID, and PHDC classes do not.
A composite device that combined both a CDC and an MSC would hit the callback twice. Conversely, an Audio/HID composite device would never hit the callback.
Possibly similar lines should be added to the Audio, DFU, HID, and PHDC device class drivers.
Possibly, those lines should be guarded with #if !USBCFG_DEV_COMPOSITE/#endif, and an unguarded similar line added to usb_composite.c.
All such lines should certainly be guarded with lines of the form:
if (cdc_obj_ptr->desc_callback.set_configuration)
or
if (msc_dev_ptr->desc_callback.set_configuration)
to make certain nobody crashes their device by passing a NULL callback.
