Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751635AbdHNS57 (ORCPT ); Mon, 14 Aug 2017 14:57:59 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:34395 "EHLO mail-oi0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751000AbdHNS55 (ORCPT ); Mon, 14 Aug 2017 14:57:57 -0400 MIME-Version: 1.0 From: Badhri Jagan Sridharan Date: Mon, 14 Aug 2017 11:57:15 -0700 Message-ID: Subject: Sometimes supports_usb_power_delivery reports incorrect value. To: Heikki Krogerus , Guenter Roeck Cc: USB , LKML 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: 965 Lines: 20 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. Thanks & Regards, Badhri.