On Tue, May 31, 2016 at 11:31:21AM +0300, Heikki Krogerus wrote: > Hi Oliver, > > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote: > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote: > > > Hi guys, > > > > > > I'm attaching a diff instead of full v3. I'm not yet adding attributes > > > for the reset and cable_reset. I still don't understand what is the > > > case where the userspace would need to be able to tricker reset? Why > > > isn't it enough for the userspace to be able to enter/exit modes? > > > Oliver! Can you please comment? > > > > 1. Because we need error handling. > > Devices crash. Cables will crash. We will get out of sync. > > You never put yourself in a place where you cannot handle an > > IO error. > > 2. Because it is in the spec. We do not second guess the spec. > > We implement it. > > Error conditions and crashes are the responsibility of the USB PD > stack, not userspace. In those cases the stack can not wait for a > command from the userspace. So for example if a timer like > NoResponseTimer times out, the stack an its state machines will have > to take care of the reset quite independently. > Agreed. > If you get out of sync with an alternate mode, you reset that specific > alternate mode by exiting and re-entering it, and you do not reset the > entire PD connection, port, partner or cable. > > The resets from userspace would be purely unsolicited. What would the > cases where we would need to tricker a reset like that? > > I want to be careful with exposing reset to userspace. Reset in USB PD > is not just an IO related thing. When you tricker a reset with USB PD, > even if it's a soft reset, it may lead into hard reset, which may It may also lead to and trigger error recovery, which is pretty much similar to physical disconnect and reconnect. > potentially lead into sudden voltage and current drop, which may lead > into the entire system crashing. We really need to understand the > cases where it would be necessary to tricker a reset from userspace. > Right now I don't see any. > Me not either, really. Error conditions are notoriously difficult to handle. I can get devices with external power into a state where even error recovery doesn't bring the USB-PD connection back to operational mode - it is sometimes necessary to disconnect power. With that in mind, not only is a reset from user space risky, it may actually make the situation worse. That will hopefully change over time, as the protocol implementations stabilize, but right now I am very hesitant to add another variable into the picture - especially if the benefits are not clear. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
