> Do you expect the device-initiated transitions to always be causing > trouble or are there scenarios where they are useful? It's a particular problem on Android devices. > Having to recompile the driver is a middle ground rarely chosen > upstream. If the code has very low chance of being useful - let's > remove it (git will hold it forever if needed); if there are reasonable > chances someone will find it useful it should be configurable from user > space, or preferably automatically enabled based on some device match > list. I like the sound of the device match list but I don't know what you mean. Is there a driver or other reference you could point me at that provides additional info? > > > Was linux-usb consulted? Adding the list to Cc. > > > > No, they weren't, but the change was discussed with the driver > maintainer at > > Microchip. > > Good to hear manufacturer is advising but the Linux USB community > may have it's own preferences / experience. Understood. > > > Please split the ret code changes to a separate, earlier patch. > > > > There are ret code changes in later patches in this set. As a general, > rule > > should ret code changes be put into their own patch? > > It's case by case, in this patch the ret code changes and error > propagation does not seem to be inherently related to the main > change the patch is making. I think you're referring to patch 7 - > similar comment indeed applies there. I'd recommend taking the > error propagation changes into a separate patch (can be a single > one for code extracted from both patches). Thanks, I am working on this and have incorporated the error propagation changes from patch 7.
