From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755219AbcEaROr (ORCPT ); Tue, 31 May 2016 13:14:47 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:38873 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750730AbcEaROp (ORCPT ); Tue, 31 May 2016 13:14:45 -0400 Date: Tue, 31 May 2016 10:14:31 -0700 From: Guenter Roeck To: Heikki Krogerus Cc: Oliver Neukum , Andy Shevchenko , Rajaram R , Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class Message-ID: <20160531171431.GA14007@roeck-us.net> References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <20160530131951.GA13055@kuha.fi.intel.com> <1464616767.5364.5.camel@suse.com> <20160531083121.GA10084@kuha.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160531083121.GA10084@kuha.fi.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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