Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1594224

RE: [PATCH v17 2/3] usb: USB Type-C connector class

From Peter Chen <peter.chen@nxp.com>
Newsgroups linux.kernel
Subject RE: [PATCH v17 2/3] usb: USB Type-C connector class
Date 2017-03-07 14:10 +0100
Message-ID <tikQO-6fF-15@gated-at.bofh.it> (permalink)
References (1 earlier) <tdjC2-3LX-25@gated-at.bofh.it> <tgOzD-5ms-7@gated-at.bofh.it> <tgWGT-2zu-33@gated-at.bofh.it> <thPtE-oe-3@gated-at.bofh.it> <ti0S6-lW-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


 
>
>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? If it is correct, there is a notifier between type-C
and USB controller driver, how to define this notifier for non-ACPI platform? 

>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.

Peter

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v17 2/3] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-03-03 15:50 +0100
  Re: [PATCH v17 2/3] usb: USB Type-C connector class Peter Chen <hzpeterchen@gmail.com> - 2017-03-06 02:20 +0100
    Re: [PATCH v17 2/3] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-03-06 14:30 +0100
      Re: [PATCH v17 2/3] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-03-07 11:50 +0100
        Re: [PATCH v17 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2017-03-08 05:10 +0100
          RE: [PATCH v17 2/3] usb: USB Type-C connector class Peter Chen <peter.chen@nxp.com> - 2017-03-08 08:00 +0100
            Re: [PATCH v17 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2017-03-08 15:50 +0100
              Re: [PATCH v17 2/3] usb: USB Type-C connector class Peter Chen <hzpeterchen@gmail.com> - 2017-03-09 03:10 +0100
      RE: [PATCH v17 2/3] usb: USB Type-C connector class Peter Chen <peter.chen@nxp.com> - 2017-03-07 14:10 +0100

csiph-web