Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S947232AbdDTTrO (ORCPT ); Thu, 20 Apr 2017 15:47:14 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:33862 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S947181AbdDTTrB (ORCPT ); Thu, 20 Apr 2017 15:47:01 -0400 MIME-Version: 1.0 In-Reply-To: <20170420122417.GB4769@kuha.fi.intel.com> References: <20170306131442.GC6999@kuha.fi.intel.com> <696552a7-c36a-1d73-9517-543907e9da39@gmail.com> <20170308135853.GH6999@kuha.fi.intel.com> <68817c44-d880-581a-e9f5-12845b9215eb@gmail.com> <20170419112323.GD24062@kuha.fi.intel.com> <20170419151401.GA14036@roeck-us.net> <20170420122417.GB4769@kuha.fi.intel.com> From: Badhri Jagan Sridharan Date: Thu, 20 Apr 2017 12:46:59 -0700 Message-ID: Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class To: Heikki Krogerus Cc: Guenter Roeck , Oliver Neukum , Mats Karrman , Greg KH , Felipe Balbi , LKML , USB Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5802 Lines: 154 Thanks for the responses :) So seems like we have a plan. In Type-C connector class the checks for TYPEC_PWR_MODE_PD and pd_revision for both the port and the partner will be removed in power_role_store and the data_role_store and will be delegated to the low level drivers. TCPM code will issue hard reset in tcpm_dr_set and tcpm_pr_set if current_role is not same as the preferred_role. I am going to make changes in my local kernel code base to start making the corresponding changes in userspace. Should I post-back the local kernel changes or Heikki and Geunter you are planning to upload them ? Thanks for the support !! Badhri. On Thu, Apr 20, 2017 at 5:24 AM, Heikki Krogerus wrote: > On Wed, Apr 19, 2017 at 10:22:47AM -0700, Badhri Jagan Sridharan wrote: >> On Wed, Apr 19, 2017 at 8:14 AM, Guenter Roeck wrote: >> > On Wed, Apr 19, 2017 at 07:45:00AM -0700, Badhri Jagan Sridharan wrote: >> >> On Wed, Apr 19, 2017 at 4:23 AM, Heikki Krogerus >> >> wrote: >> >> > Hi, >> >> > >> >> > On Tue, Apr 18, 2017 at 11:52:33AM -0700, Badhri Jagan Sridharan wrote: >> >> >> Hi Heikki, >> >> >> >> >> >> I have a question regarding the preferred_role node. >> >> >> >> >> >> +What: /sys/class/typec//preferred_role >> >> >> +Date: March 2017 >> >> >> +Contact: Heikki Krogerus >> >> >> +Description: >> >> >> + The user space can notify the driver about the preferred role. >> >> >> + It should be handled as enabling of Try.SRC or Try.SNK, as >> >> >> + defined in USB Type-C specification, in the port drivers. By >> >> >> + default the preferred role should come from the platform. >> >> >> + >> >> >> + Valid values: source, sink, none (to remove preference) >> >> >> >> >> >> What is the expected behavior when the userspace changes the >> >> >> preferred_role node when the port is in connected state ? >> >> >> >> >> >> 1. the state machine re-resolves the port roles right away based on >> >> >> the new state machine in place ? (or) >> >> > >> >> > No! There are separate attributes for sending role swap requests. >> >> >> >> Right. But, that might not be helpful in cases when PD is not implemented. >> >> and Implementing PD is not mandatory according the spec :/ >> >> >> >> FYI quoting from the Type-C specification release(page 24), >> >> role swaps are not limited to devices that only support PD. >> >> >> >> "Two independent set of mechanisms are defined to allow a USB Type-C >> >> DRP to functionally swap power and data roles. When USB PD is >> >> supported, power and data role swapping is performed as a subsequent >> >> step following the initial connection process. For non-PD implementations, >> >> power/data role swapping can optionally be dealt with as part of the initial >> >> connection process." >> >> >> >> But, the current interface definition actually prevents current/data role >> >> swaps for non-pd devices. >> >> >> >> > This is correct for the attribute definition, but it is not implemented >> > that way. Writing the attribute is only read-only for non-DRP ports. >> >> i.e. tcpm_dr_set/tcpm_pr_set at tcpm.c would return EINVAL when type >> is not TYPEC_PORT_DRP, is that what you are referring to ? >> >> if (port->typec_caps.type != TYPEC_PORT_DRP) { >> ret = -EINVAL; >> goto port_unlock; >> } >> >> I do agree that this is actually correct. I am referring to the case >> where port is >> dual-role-power and dual-role-data but NOT PD capable. >> >> > Given the standard, I would consider that to be intentional; it might >> > make sense to update the description accordingly. >> > >> > How about implementing a mechanism in the dr_set and pr_set code in tcpm >> > which would handle that situation ? Something along the line of >> > >> > if (!port->pd_capable && connected && current role != desired role) { >> > reset_port(); >> > goto done; >> > } >> >> By "desired role" you are referring to preferred_role right ? >> >> If so yes, That's a good idea as well and it might work as long as >> type-c connector >> class allows the call to reach tcpm code :) But the current connector >> class code does >> not allow that because the power_role and data_role nodes are defined that way. > > Well, the data_role does not limit the requests from reaching the low > level drivers, but.. > >> port->cap->pd_revision and the port->pwr_opmode check in the below code >> stub have to removed/refactored to make current_role/data_role writes to >> reach the tcpm code. >> >> +static ssize_t power_role_store(struct device *dev, >> + struct device_attribute *attr, >> + const char *buf, size_t size) >> +{ >> + struct typec_port *port = to_typec_port(dev); >> + int ret = size; >> + >> + if (!port->cap->pd_revision) { >> + dev_dbg(dev, "USB Power Delivery not supported\n"); >> + return -EOPNOTSUPP; >> + } >> + >> + if (!port->cap->pr_set) { >> + dev_dbg(dev, "power role swapping not supported\n"); >> + return -EOPNOTSUPP; >> + } >> + >> + if (port->pwr_opmode != TYPEC_PWR_MODE_PD) { >> + dev_dbg(dev, "partner unable to swap power role\n"); >> + return -EIO; >> + } >> + >> + ret = sysfs_match_string(typec_roles, buf); >> + if (ret < 0) >> + return ret; >> + >> + ret = port->cap->pr_set(port->cap, ret); >> + if (ret) >> + return ret; >> + >> + return size; >> +} > > .. yes. The power_role_store() does indeed need to be refactored. The > PD requirement should only be applied to Type-C spec versions < 1.2, > or removed completely. I would be happy to leave the checks to the low > level drivers. > > > Thanks, > > -- > heikki