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,
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
