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]

Date:   Tue, 7 Mar 2017 17:53:21 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Peter Chen <peter.chen@....com>
Cc:     Peter Chen <hzpeterchen@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Oliver Neukum <oneukum@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        Roger Quadros <rogerq@...com>, Jun Li <jun.li@....com>
Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class

On 03/07/2017 12:57 AM, Heikki Krogerus wrote:
> On Tue, Mar 07, 2017 at 01:36:29AM +0000, Peter Chen wrote:
>>> On Mon, Mar 06, 2017 at 09:15:51AM +0800, Peter Chen wrote:
>>>>>> What interface you use when you receive this event to handle
>>>>>> dual-role switch? I am wonder if a common dual-role class is
>>>>>> needed, then we can have a common user utility.
>>>>>>
>>>>>> Eg, if "data_role" has changed, the udev can echo "data_role" to
>>>>>> /sys/class/usb-dual-role/role
>>>>>
>>>>> No. If the partner executes successfully for example DR_Swap
>>>>> message, the kernel has to take care everything that is needed for
>>>>> the role to be what ever was negotiated on its own. User space can't
>>>>> be involved with that.
>>>>>
>>>>
>>>> Would you give me an example how kernel handle this? How type-C event
>>>> triggers role switch?
>>>
>>> On our boards, the firmware or EC (or ACPI) configures the hardware as needed
>>> and also notifies the components using ACPI if needed. It's often not even possible to
>>> directly configure the components/hardware for a particular role.
>>>
>>
>> You mean type-C trigger an ACPI event, and this ACPI event can notify related
>> USB controller driver doing role switch?
>
> No (firmware programs the dual-role hw/registers), but never mind.
> That could be the case.
>
>> If it is correct, there is a notifier between type-C
>> and USB controller driver, how to define this notifier for non-ACPI platform?
>
> Once there is a platform with Type-C like that, the problem needs to
> be solved. However..
>
>>> I'm not commenting on Roger's dual role patch series, but I don't really think it should
>>> be mixed with Type-C. USB Type-C and USB Power Delivery define their own ways
>>> of handling the roles, and they are not limited to the data role only. Things like OTG
>>> for example will, and actually can not be supported. With Type-C we will have
>>> competing state machines compared to OTG. The dual-role framework may be
>>> useful on systems that provide more traditional connectors, which possibly have the
>>> ID-pin like micro-AB, and possibly also support OTG. It can also be something that
>>> exist in parallel with the Type-C class, but there just can not be any dependencies
>>> between the two.
>>>
>>
>> Yes, there are two independent things. But if the kernel doesn't have a notifier between
>> type-C message sender (type-c class) and message receiver (like USB controller driver
>> for role switch or other drivers for alternate mode message), we had to find some ways at
>> userspace.
>
> ..what ever the solution is, it really can't rely on user space.
>

... and, at least for our application, using extcon for the necessary notifications
works just fine.

Guenter