On Tue, Aug 30, 2016 at 06:46:24AM -0700, Guenter Roeck wrote:
> On 08/30/2016 03:04 AM, Heikki Krogerus wrote:
> > Hi Oliver,
> >
> > On Tue, Aug 30, 2016 at 11:32:01AM +0200, Oliver Neukum wrote:
> > > On Mon, 2016-08-29 at 15:36 +0300, Heikki Krogerus wrote:
> > > > +What: /sys/class/typec/<port>/current_data_role
> > > > +Date: June 2016
> > > > +Contact: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
> > > > +Description:
> > > > + The current USB data role the port is operating in.
> > > > This
> > > > + attribute can be used for requesting data role
> > > > swapping on the
> > > > + port. Swapping is only supported as an asynchronous
> > > > operation
> > > > + and requires polling of the attribute in order to know
> > > > the
> > > > + result, so successful write operation does not mean
> > > > successful
> > > > + swap.
> > > > +
> > >
> > > That is badly formulated. Does it mean that poll() or select()
> > > can be used or does the value need to be repearedly read?
> >
> > Does polling not always mean poll/select?
> >
> > > And how would you learn about an error?
> >
> > This is what I'm also really worried about. I'm now wondering did I
> > give up too easily on this to Guenter in hope to move this thing
> > forward. He said it's problematic to do these calls synchronously for
> > him. Was it something related to potential conflicting role swaps from
> > both ends?
> >
> > Guenter, can you please elaborate? And how do you plan to report
> > failures with the swaps?
> >
>
> I thought we had this sorted out. When I said "asynchronous", I did not mean
> that the sysfs operation would not wait for the operation to complete. I meant
> that the Type-C state machine operates in a different context than the sysfs/class
> code. Since the state machine operates in a different context, it may have
> to execute a callback into the class code at any time, independently of
> any pending role changes triggered through sysfs. Please have a look into
> the patch set I submitted for details. Roughly it works as follows.
>
> Class code context State machine context
>
> User requests role change
> Class code calls {dr,pr,vconn}_set
> {dr,pr,vconn}_set code validates request
> {dr,pr,vconn}_set code sends role change
> request to state machine State machine gets role change request
> {dr,pr,vconn}_set code waits for completion
> State machine sends role change request
> to link partner
> Partner reports Accept or Reject
> State machine changes state as requested
> State machine reports new role to class code
> via callbacks
> State machine informs Class code that request
> is complete
> {dr,pr,vconn}_set code gets results
> and returns to caller
> Class code reports results to user
>
> From user perspective, everything is synchronous. However, the state machine has to be
> able to run independently and report role and other state changes to the class code while
> a role change request from the class code is pending. For example, it has to be able to
> handle incoming role change requests from the link partner, and it has to be able to
> handle link state changes. All those have to be reported to the class code. This is
> impossible if the class code holds a lock while a role change triggered from user space
> is pending, which is why I asked for the locks in the class code to be removed.
>
> Maybe my use of the term "asynchronous" was misleading, and I should have said "operates
> in a different context" instead. My apologies.
Thanks for the explanation. I remember you did explain this before I
started my parental leave, but I forgot all about it.
Thanks,
--
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
