From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752018AbdHONnC (ORCPT ); Tue, 15 Aug 2017 09:43:02 -0400 Received: from mga14.intel.com ([192.55.52.115]:20247 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751148AbdHONnB (ORCPT ); Tue, 15 Aug 2017 09:43:01 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,377,1498546800"; d="scan'208";a="890122193" Date: Tue, 15 Aug 2017 16:36:26 +0300 From: Heikki Krogerus To: Badhri Jagan Sridharan Cc: Guenter Roeck , USB , LKML Subject: Re: Sometimes supports_usb_power_delivery reports incorrect value. Message-ID: <20170815133626.GA30718@kuha.fi.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Aug 14, 2017 at 11:57:15AM -0700, Badhri Jagan Sridharan wrote: > Hi Heikki, > > While testing with different type-c phones available in the market, > With some phones, I noticed that supports_usb_power_delivery > reports "no" eventhough an explicit pd contract has been > established. After spending sometime debugging, I noticed that > the root cause of this is that the partner device(acting as source) > takes too long to send the SRC_CAP message. This makes the > underlying TCPM code to report usb_pd set to 0 while initially > calling typec_register_partner. However,since there is no > provision in the type-c sysfs interface to update > supports_usb_power_delivery once the contract is established, > supports_usb_power_delivery is left to report "no" even if the partner > source device is at present performing Type-C PD. > Is it OK to add a api to enable updating supports_usb_power_delivery > node in the typec sysfs code after typec_register_partner has been > called ? Or do you have other suggestions ? Please advice. supports_usb_power_delivery will be updated if typec_set_pwr_opmode() is called with value TYPEC_PWR_MODE_PD, and it should be called, also in tcpm.c, always when USB PD contract has been established. I did not check the latest tcpm.c code, but I assume it does that. If it doesn't, it needs to be fixed of course. Are you sure you really have the contract established? Thanks, -- heikki