Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1431561AbdDYOLD (ORCPT ); Tue, 25 Apr 2017 10:11:03 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:57445 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1429597AbdDYOKx (ORCPT ); Tue, 25 Apr 2017 10:10:53 -0400 Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class To: Rajaram R , Badhri Jagan Sridharan References: <68817c44-d880-581a-e9f5-12845b9215eb@gmail.com> <20170419112323.GD24062@kuha.fi.intel.com> <20170419151401.GA14036@roeck-us.net> <20170420122417.GB4769@kuha.fi.intel.com> <20170421164323.GA31344@roeck-us.net> Cc: Heikki Krogerus , Oliver Neukum , Mats Karrman , Greg KH , Felipe Balbi , LKML , USB From: Guenter Roeck Message-ID: <9485c5e8-6b79-0b93-d0e9-e7880aea9741@roeck-us.net> Date: Tue, 25 Apr 2017 07:10:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@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: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@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 Content-Length: 3122 Lines: 73 On 04/25/2017 01:26 AM, Rajaram R wrote: > On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan > wrote: >> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R wrote: >>> On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck wrote: >>>> On Fri, Apr 21, 2017 at 07:57:52PM +0530, Rajaram R wrote: >>>>> On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan >>>>> wrote: >>>>>> 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. >>>>> >>>>> It is important to remember what USB Type-C provide is mechanisms for >>>>> "TRYing" to become a particular role and not guaranteeing. >>>>> >>>>> With what device combination do you fore see we could get the desired >>>>> role with this change ? >>>>> >>>> >>>> If the partner is not PD capable, if a preferred role is specified, >>>> if the current cole does not match the preferred role, and if the request >>>> is to set the role to match the preferred role, I think it is reasonable >>>> to expect that re-establishing the connection would accomplish that if the >>>> partner supports it. >>>> >>> In this context I believe we have two different inputs as follows: >>> >>> /sys/class/typec//supported_power_roles >>> /sys/class/typec//preferred_role >>> >>> The need of preferred role is required when DRP is set in >>> supported_power_roles option. >>> Ideally a battery powered device will TRY to be SNK and a a/c plugged >>> device will TRY to be SRC >>> >>> We need to understand which non-PD device will set to DRP? In the >> >> Android Phones (actually it could be any phone which has a type-c port) >> since it can act as usb gadget (when connected to PC) or Usb host >> when connected to peripherals such as thumb drives, keyboard etc. >> Phones with smaller form factors might be thermally limited to charge >> above 15W, therefore supporting PD might be an overkill for them. >> >>> current ecosystem all legacy devices >>> will sit behind adapters which either present an Rp or Rd. >>> >>> If it is a power adapter in 5V range can either present Rp or DRP with >>> TRY.SRC and there is no role swap requirement. >>> >>> If it is a laptop port or similar with non-PD (??) DRP there is no >>> guaranteed role swap in a non-PD mode. >> >> This is true, but following a Try.SRC or Try.SNK state machine can >> increase the chances of landing in the desired role/preferred role. > > Agree and as indicated it increases only chances. > FWIW, this is pretty much the same as requesting a role change using PD. Based on my experience with various devices, the chance for that to succeed isn't really that high either. I am not really sure I understand your problem with using Try.{SRC,SNK} to trigger (or attempt to trigger) a role change. Can we take a step back, and can you explain ? Thanks, Guenter