From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753634AbdCFNZt (ORCPT ); Mon, 6 Mar 2017 08:25:49 -0500 Received: from mga05.intel.com ([192.55.52.43]:42465 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752950AbdCFNXw (ORCPT ); Mon, 6 Mar 2017 08:23:52 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,253,1484035200"; d="scan'208";a="941103593" Date: Mon, 6 Mar 2017 15:16:19 +0200 From: Heikki Krogerus To: Peter Chen Cc: Greg KH , Guenter Roeck , Felipe Balbi , Oliver Neukum , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, Roger Quadros , Jun Li Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class Message-ID: <20170306131619.GD6999@kuha.fi.intel.com> References: <20170221142405.76299-1-heikki.krogerus@linux.intel.com> <20170221142405.76299-3-heikki.krogerus@linux.intel.com> <20170303033529.GA18650@b29397-desktop> <20170303143133.GB6999@kuha.fi.intel.com> <20170306011551.GA23305@b29397-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170306011551.GA23305@b29397-desktop> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, 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. 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. Thanks, -- heikki