On Wed, May 25, 2016 at 08:19:47AM -0700, Guenter Roeck wrote: > On Wed, May 25, 2016 at 02:28:46PM +0300, Heikki Krogerus wrote: > > Hi, > > > > On Tue, May 24, 2016 at 02:51:40PM +0200, Oliver Neukum wrote: > > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > > > > > > Hi, > > > > > > as this discussion seems to go in circles, I am starting anew > > > at the top. > > > > > > > Like I've told some of you guys, I'm trying to implement a bus for > > > > the Alternate Modes, but I'm still nowhere near finished with that > > > > one, so let's just get the class ready now. The altmode bus should in > > > > any case not affect the userspace interface proposed in this patch. > > > > > > > > As you can see, the Alternate Modes are handled completely differently > > > > compared to the original proposal. Every Alternate Mode will have > > > > their own device instance (which will be then later bound to an > > > > Alternate Mode specific driver once we have the bus), but also every > > > > partner, cable and cable plug will have their own device instances > > > > representing them. > > > > > > The API works for a DFP. I fail to see how the UFP learns about entering > > > an alternate mode. > > > Secondly, support to trigger a reset is missing > > > > I'm fine with adding an attribute for port and cable resets if it's > > something that is needed. So do you want to be able to execute hard > > reset on a port? > > > > But could you please explain the case(s) where you need to tricker a > > reset. > > > > > > An other change is that the data role is now handled in two ways. > > > > The current_data_role file will represent static mode of the port, and > > > > it will use the names for the roles as they are defined in the spec: > > > > DFP, UFP and DRP. This file should be used if the port needs to be > > > > > > Good, but support for Try.SRC and Try.SNK is missing. > > > > OK, but what is Try.SNK? It's not in the specs? > > > > It is not in the USB PD specification, but in "USB Type-C Specification > Release 1.2 - Cable and Connector Specification". > > Section 4.5.2.2.11, "Try.SNK State", says > > "Note: if both Try.SRC and Try.SNK mechanisms are implemented, only one > shall be enabled by the port at any given time. Deciding which of these > two mechanisms is enabled is product design-specific." > > ... which is why I suggested earlier that there should be a platform > parameter to enable one or the other. Heh, I'm still living the year 2015 :). I've missed the Type-C 1.2 spec. Thanks guys, -- heikki -- 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
