On Mo, 2018-11-12 at 12:04 +0000, Mayuresh Kulkarni wrote: > I think I now understand the disconnect between us this point. Below is an > attempt to bridge that, so please bear with me: > 1. In our use-case(s), the end user can "interact" with composite USB device > either by physically interacting with or via an app on Android. > 2. When the interaction is "physical" (e.g.: something that is sensed by a > sensor or a button press), we need "remote-wake" from USB device to host. > 3. When the interaction is via app (e.g.: to toggle some control), we need > "host-wake" from host to USB device. All of these events can occur at the same time. And you cannot prevent that. > And this is where, the knowledge of wake-up source and difference in handling > comes into picture. > For (2), the host needs to first wake-up and then queue a request to read-out > "what" happened. > For (3), the host needs to first wake-up the device and then queue the > command(s) to the take action asked by the end user. > > I agree that in both of above cases, "a USB request" needs to be send from user- > space to kernel to device. But in my opinion, each of the them has a different > context associated with it. E.g.: for (2), a single read request is sufficient > to "know" what happened while for (3), a write and a read request is needed. There is a natural race condition between remote and host wake up. You cannot rule out that your app wakes the device up, exactly when user interaction would have woken it anyway. Your app will know what it wants to do with the device. And you can detect that. Hence the correct algorithm is: 1. wake up the device 2. query it for a cause of wake up 3. If the host wants to do IO, do all of it. Regards Oliver
