On Sat, Dec 26, 2020 at 12:46:27AM +0000, Vincent Pelletier wrote: > Hello Artur, > > On Fri, 25 Dec 2020 10:56:02 +0000, Artur Petrosyan <Arthur.Petrosyan@xxxxxxxxxxxx> wrote: > > According your debug log core enters suspend on receiving an > > GINTSTS_ErlySusp interrupt. It means that the driver goes to L2 state > > (suspend). In suspend mode accepting and processing EP requests can lead > > to unexpected behavior. That is why the driver rejects EP request with > > -EAGAIN. > > > > As core may use power saving modes which are initiated by the Suspend > > interrupt, then in any suspend mode whether it is hibernation or partial > > power down the core registers are not available. This is why we avoid to > > get new EP requests. This seems like a design mistake. Even though the controller may be in a low-power state, there's no reason the UDC driver can't accept new requests or unlink old ones. It even ought to be willing to halt endpoints. None of these actions require the driver to touch the hardware. The hardware-specific parts of the actions can be carried out when the controller returns to full power. > This is my understanding from reading the commit history, yes. > > But from userland's point of view this causes a weird situation: > - sequence 1: > - userland submits buffer (ex: to receive the next host request) > - UDC is suspended > - UDC is awoken by host initiating a transfer > Result: the AIO completes successfully, the suspension was completely > invisible to userland, and I'm happy. > - sequence 2: > - UDC is suspended > - userland submits buffer (ex: to receive the next host request) > Result: the AIO completes with an error, the suspension got in the > way, and I'm confused about what I need to make my code do to > recover: should I change my IO completion codepath so that it > resubmits any EAGAIN completion, hoping to catch the UDC at a time it > is awoken so the AIO finally sticks and everything can sleep until an > actual transfer completion ? Indeed, the same problem will occur with synchronous (non-AIO) submissions. > I do not know if it makes sense from a kernel point of view, but would > it be possible for the dwc2 module to sit on the AIO requests while the > controller is suspended, and submit them when it wakes up rather than > failing them immediately and sending them back to userland ? > I expect that this code actually knows (without polling) when the > controller is awoken. The kernel shouldn't have to sit on anything. The requests should be accepted immediately. Alan Stern
