linux-kernel - Sometimes supports_usb_power_delivery reports incorrect value.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 14 Aug 2017 11:57:15 -0700
From:   Badhri Jagan Sridharan <badhri@...gle.com>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Guenter Roeck <groeck@...gle.com>
Cc:     USB <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Sometimes supports_usb_power_delivery reports incorrect value.

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.