linux-kernel - Re: [Bug ?] usb :typec :tcpm :fusb302

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: <e05b6c1f-5e00-c000-23b9-1683230fd9f7@roeck-us.net>
Date:   Mon, 20 Jan 2020 06:21:19 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Markus Reichl <m.reichl@...etechno.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Linux USB Mailing List <linux-usb@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        linux-rockchip@...ts.infradead.org
Subject: Re: [Bug ?] usb :typec :tcpm :fusb302

On 1/20/20 3:58 AM, Heikki Krogerus wrote:
> Hi Markus,
> 
> On Thu, Jan 09, 2020 at 05:29:07PM +0100, Markus Reichl wrote:
>> Hi,
>>
>> I'm working with a ROC-RK3399-PC arm64 board from firefly, circuit sheet [1].
>> The board is powered from an USB-C type connector via an FUSB302 PD controller.
>> With measured 15W+ power consumption it should use higher voltage PD modes than
>> the standard 5V USB-C mode.
>>
>> When I add the related connector node in DTS [2] the FUSB302 initializes
>> the right PD mode (e.g. 15V/3A).
>>
>> But during initialisation the PD is switched off shortly and the board has a blackout.
>> When I inject a backup supply voltage behind the FUSB302 (e.g. at SYS_12V line) during boot
>> I can remove the backup after succesfull setting up the PD and the board will run fine.
>>
>> Is it possible to change the behaviour of the fusb302 driver to not power down the PD supply
>> during init?
> 
> I guess it's also possible that the problem is with tcpm.c instead of
> fusb302.c. tcpm.c provides the USB PD state matchines. Guenter! Can
> you take a look at this?
> 

There was always a problem with handoff from the bootloader. tcpm_init() calls
tcpm_reset_port() which turns vbus and vconn off, which I imagine can
trigger the situation.

Unfortunately I was never able to solve the puzzle. The Type-C protocol does
not support any kind of "hand-off" from one component in the system to another.
If the state machine doesn't start from a clean state, there is pretty
much no guarantee that it ever synchronizes.

Maybe someone can find a better solution, but when I wrote the code I just
could not get it to work reliably without resetting everything during
registration.

Note that v4.4 did not include the upstream tcpm code, suggesting the
code in the vendor kernel was possibly using a different or backported
state machine. Impossible to say what was done there without access
to the code.

Guenter

> Both tcpm.c and fusb302.c create debugfs entries that have a more
> detailed log about things that are happening. Can you check what you
> have in those (when you boot with the mains cable plugged it)?
> 
>          % mount debugfs -t debugfs /sys/kernel/debug
>          % cat /sys/kernel/debug/tcpm*
>          % cat /sys/kernel/debug/fusb302/*
> 
> Which kernel are you running by the way?
> 
>> In vendor kernel (4.4) this is done somehow but the sources are too different for me to find
>> out how.
>>
>> Gruß,
>> -- 
>> Markus Reichl
>>
>> [1]
>> http://download.t-firefly.com/product/RK3399/Docs/Hardware/%E5%8E%9F%E7%90%86%E5%9B%BE%E5%92%8C%E8%B4%B4%E7%89%87%E5%9B%BE/ROC-RK3399-PC/ROC-3399-PC-V10-A-20180804_%E5%8E%9F%E7%90%86%E5%9B%BE.pdf
>>
>> [2]
>> https://lkml.org/lkml/2019/12/10/517
>