linux-kernel - Re: [v3 PATCH 3/5] phy: Add USB Type-C PHY driver for rk3399

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: <CABXOdTdH-jNVx1b3R+=Z712Zcs8c6q3Hq1iwt_i7foe3K3SAVw@mail.gmail.com>
Date:	Thu, 23 Jun 2016 19:10:04 -0700
From:	Guenter Roeck <groeck@...gle.com>
To:	Chris Zhong <zyw@...k-chips.com>
Cc:	Douglas Anderson <dianders@...omium.org>,
	Tomasz Figa <tfiga@...omium.org>,
	Heiko Stübner <heiko@...ech.de>,
	姚智情 <yzq@...k-chips.com>,
	Guenter Roeck <groeck@...omium.org>, myungjoo.ham@...sung.com,
	cw00.choi@...sung.com,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	Kever Yang <kever.yang@...k-chips.com>,
	Kishon Vijay Abraham I <kishon@...com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [v3 PATCH 3/5] phy: Add USB Type-C PHY driver for rk3399

Hi Chris,

On Thu, Jun 23, 2016 at 5:34 PM, Chris Zhong <zyw@...k-chips.com> wrote:
> Hi Guenter
>
>
> On 06/24/2016 05:47 AM, Guenter Roeck wrote:
>>
>> Hi Chris,
>>
>> On Thu, Jun 23, 2016 at 5:51 AM, Chris Zhong <zyw@...k-chips.com> wrote:
>>>
>>> Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
>>> Type-C PHY is designed to support the USB3 and DP applications. The
>>> PHY basically has two main components: USB3 and DisplyPort. USB3
>>> operates in SuperSpeed mode and the DP can operate at RBR, HBR and
>>> HBR2 data rates.
>>>
>>> Signed-off-by: Chris Zhong <zyw@...k-chips.com>
>>> Signed-off-by: Kever Yang <kever.yang@...k-chips.com>
>>>
>> [ ... ]
>>
>>> +
>>> +static void tcphy_get_state(struct rockchip_typec_phy *tcphy,
>>> +                           struct extcon_dev *edev)
>>> +{
>>> +       int mode;
>>> +       bool plugged, flip, pin_assign, dfp, ufp, dp;
>>> +
>>> +       ufp = extcon_get_cable_state_(edev, EXTCON_USB);
>>> +       dfp = extcon_get_cable_state_(edev, EXTCON_USB_HOST);
>>> +       dp = extcon_get_cable_state_(edev, EXTCON_DISP_DP);
>>> +       flip = extcon_get_cable_state_(edev, EXTCON_TYPEC_POLARITY);
>>> +       pin_assign = extcon_get_cable_state_(edev,
>>> EXTCON_TYPEC_PIN_ASSIGN);
>>> +
>>> +       plugged = ufp | dfp | dp;
>>> +       tcphy->flip = flip;
>>> +
>>> +       if (plugged) {
>>> +               if (ufp) {
>>> +                       mode = MODE_UFP_USB;
>>> +               } else if (dfp && !dp) {
>>> +                       mode = MODE_DFP_USB;
>>> +               } else if (dfp && dp) {
>>> +                       mode = MODE_DFP_USB | MODE_DFP_DP;
>>> +                       tcphy->pin_assign = pin_assign ? PIN_MAP_D :
>>> PIN_MAP_B;
>>> +               } else {
>>> +                       mode = MODE_DFP_DP;
>>> +                       tcphy->pin_assign = pin_assign ? PIN_MAP_C :
>>> PIN_MAP_A;
>>
>> I am having trouble extracting pin_assign from our code. What
>> determines if map A or C should be selected ?
>>
>> Thanks,
>> Guenter
>
> Oh, forgot rename the macro:
>
> PIN_MAP_ should be PIN_ASSIGN_
>
>
>  IF EXTCON_TYPEC_PIN_ASSIGN is attached, Type-C get
>  Pin_Assignment_C(for DP only mode) or Pin_Assignment_D(for DP alt mode),
>   if detached, it get the default Assignment: A(for DP only mode) or B(for
> DP alt mode),.
>

So we are really talking about DP only vs. DP Alt mode ? If so, do we
even need PIN_ASSIGN ? Why not just use EXTCON_DISP_DP_ALT directly ?

Also, I'll have to get a better understanding what "DP only mode" and
"DP Alt mode" actually means. DisplayPort is already a Type-C
alternate mode, so the terminology is a bit confusing. Do you happen
to have a description somewhere, by any chance ?

Thanks,
Guenter

> I am going to add a comment for describe which PIN_ASSIGN_ should be
> selected
> in next version, if no one disagrees the usage of cable
>
>
>>
>>
>
>