linux-kernel - Re: Using TCPM for ports without Power Delivery support

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]

Date:   Wed, 17 Feb 2021 15:28:17 +0000
From:   <Cristian.Birsan@...rochip.com>
To:     <heikki.krogerus@...ux.intel.com>
CC:     <linux@...ck-us.net>, <gregkh@...uxfoundation.org>,
        <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: Using TCPM for ports without Power Delivery support

Hi Heikki,

On 2/16/21 11:12 AM, Heikki Krogerus wrote:
> 
> Hi Cristian,
> 
> On Mon, Feb 15, 2021 at 05:25:29PM +0000, Cristian.Birsan@...rochip.com wrote:
>> My name is Cristian and I'm working on bringing up a USB Type-C Port Controller
>> (TCPC) without Power Delivery support which is intended to work with USB 2.0
>> Host/Device.
>>
>> The IP is integrated into one of Microchip's SoCs, it is memory-mapped and it
>> was designed based on USB Type-C Cable and Connector specification revision 1.2.
>>
>> In brief, it has support for detecting the threshold voltages on CC1, CC2 lines,
>> control of the current source (Ip), and pull-down resistors (Rd). The management
>> of the controller is to be implemented in software (it is not autonomous).
>>
>> Having in mind that the controller uses proprietary registers, I chose to
>> implement it using TCPM directly and skip the TCPC Interface.
>>
>> For the beginning, I would like to enable simple use cases like the ones
>> described in Connection State Diagram: Source and Connection State Diagram: Sink
>> from USB Type-C Cable and Connector Specification.
>>
>> Some of the problems that I encountered until now are:
>>
>> 1. tcpm_register_port() fails if set_pd_rx(), pd_transmit() or set_vconn()
>> functions are missing.
>>
>> 2. the port capabilities are specified in the connector DT bindings only through
>> PDOs, even though PDOs are specific to PD mode.
>>
>> 3. once I was able to start the TCPM state machine, it called pd_transmit() in
>> the process to negotiate the capabilities. For my case I used a dummy function
>> just to be able to register the port.
>>
>> Please let me know what you think and if you have any advice. Am I going in the
>> right direction or is there a better way to implement this?
> 
> Don't bother with tcpm if you don't have PD support. Just register
> your port(s) and the partners directly with the connector class:
> https://www.kernel.org/doc/html/latest/driver-api/usb/typec.html
> 
> You can use the driver for the TI HD3SS3220 controller as an example
> how to do that (drivers/usb/typec/hd3ss3220.c). That thing is also
> just USB Type-C PHY without PD support just like your port controller.
> 

Thank you for the suggestion. I had a look at the driver you mentioned and also
other drivers from the same folder. The chips have logic embedded into
them to handle CC lines and VBUS while the controller on which I'm working
provides basic access to CC lines and it is up to the software to drive it.
VBUS is to be detected/enabled through a standard GPIO.

The reason for which I tried to use TCPM is that I need to implement in software
the Sink/Source Connection State Diagrams, CC debounce, and VBUS management.
I tried to avoid code duplication but on the other hand, my use case does not
involve PD.

If there are better chances to upstream the driver using just the connector
class, I'll move forward with this direction. I just wanted to make sure I
explained correctly may use case before implementing it.

Cristian

> 
> Br,
> 
> --
> heikki
>