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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170815133626.GA30718@kuha.fi.intel.com>
Date:   Tue, 15 Aug 2017 16:36:26 +0300
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Badhri Jagan Sridharan <badhri@...gle.com>
Cc:     Guenter Roeck <groeck@...gle.com>, USB <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Sometimes supports_usb_power_delivery reports incorrect value.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ