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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux