linux-kernel - Re: [PATCH v17 2/3] usb: USB Type-C connector class

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: <CAPTae5+O83bJm6KL2zWNhYv-SiZ2E490CLt02BbK4hG1xKXraw@mail.gmail.com>
Date:   Tue, 18 Apr 2017 11:52:33 -0700
From:   Badhri Jagan Sridharan <badhri@...gle.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Mats Karrman <mats.dev.list@...il.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Oliver Neukum <oneukum@...e.com>,
        LKML <linux-kernel@...r.kernel.org>,
        USB <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi Heikki,

I have a question regarding the preferred_role node.

+What:          /sys/class/typec/<port>/preferred_role
+Date:          March 2017
+Contact:       Heikki Krogerus <heikki.krogerus@...ux.intel.com>
+Description:
+               The user space can notify the driver about the preferred role.
+               It should be handled as enabling of Try.SRC or Try.SNK, as
+               defined in USB Type-C specification, in the port drivers. By
+               default the preferred role should come from the platform.
+
+               Valid values: source, sink, none (to remove preference)

What is the expected behavior when the userspace changes the
preferred_role node when the port is in connected state ?

1.  the state machine re-resolves the port roles right away based on
the new state machine in place ? (or)
2. Wait till the subsequent connect for resolving port roles based on the
new state machine.

For #1 to happen the policy_engine layer would have to reset the port
to resolve the port roles based on the (Try.SRC /Try.SNK/ Default)
new state machine preference.

Say for example when two non-PD devices following none (default state
machine) are connected, the port role resolution is going to be random.
But, if the userspace in one of the devices later changes the
preferred_role to source, then that device is most likely to become source
if the Try.SRC state-machine is re-run.

Does the above question fall under a policy decision ? If so, should there
be another node to say if the port roles have to re-resolved  based on the
new state machine right away ?

Thanks !!

On Fri, Mar 10, 2017 at 3:41 PM, Guenter Roeck <linux@...ck-us.net> wrote:
> On 03/10/2017 02:22 PM, Mats Karrman wrote:
>>
>> On 2017-03-08 14:58, Heikki Krogerus wrote:
>>
>>> On Tue, Mar 07, 2017 at 11:30:54PM +0100, Mats Karrman wrote:
>>>>
>>>> If I read Heikki's original suggestion I understand it like the DP
>>>> driver would be
>>>> responsible for AM specific USB PD/VDM communication. But wouldn't that
>>>> lead
>>>> to a lot of code duplication since the AM protocol is the same for all
>>>> drivers of
>>>> a kind?
>>>
>>> No that's not what I mean. I'm still mixing your PD controller with
>>> something else above, sorry about that. Your PD controller driver
>>> should not ideally even need to be aware of Type-C connector, right?
>>> It definitely does not need to do any USB PD communication.
>>
>>
>> Right.
>>
>>> I would imagine you have on top of the DP controller, a mux (which
>>> could be a DP/USB3 PHY like on Rockchip RK3399, discrete mux like
>>> Pericom PI3USB30532, or something else), and a USB Type-C PHY or USB
>>> PD controller. The bus would be tying the mux to the Type-C port (PHY
>>> or PD controller) and its partner (note that it does not tie the mux
>>> to the DP controller). Please correct me if I'm wrong about your
>>> hardware.
>>
>>
>> No, you're correct, a discrete mux and a fusb302.
>>
>>> Assuming that is how your board roughly looks like, the driver for the
>>> mux would be the driver for the DP altmode devices. That driver would
>>> be the one converting things like the Attention messages notifying
>>> about HPD into toggling of GPIOs, or what ever is needed on your
>>> board, etc.
>>
>>
>> OK.
>>
>>> The actual PD communication with VDMs should be considered as just the
>>> protocol, so we probable should have "protocol drivers". For example
>>> DP alternate mode VDMs and communication will always be the same
>>> despite of the hardware. The DP alternate mode "protocol driver" would
>>> then be tied to the alternate mode device for the partner, and that
>>> driver could have its own hooks for what ever is needed, like HPD
>>> signal handling, configuration changes, whatever. In any case,
>>> hopefully making things easy and straightforward for the "mux driver",
>>> _so that it does not need to care about the actual PD communication_.
>>
>>
>> I'm digesting your and Guenter's replies and patches.
>> I will try getting something up and running too soon and hopefully the
>> foggy parts will
>> dissolve. As for now I find it a lot easier to grok Guenter's drivers than
>> to see the
>> advantages and/or disadvantages of an altmode bus :-)
>>
>> @Guenter: There _is_ interest for your fusb302 driver, thank you
>>
>
> Ok, I'll see what I need to do to publish it.
>
> Guenter
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html