From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756385AbcK2Hx2 (ORCPT ); Tue, 29 Nov 2016 02:53:28 -0500 Received: from mx2.suse.de ([195.135.220.15]:37976 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756285AbcK2HxU (ORCPT ); Tue, 29 Nov 2016 02:53:20 -0500 Message-ID: <1480405251.22547.36.camel@suse.com> Subject: Re: [PATCHv12 2/3] usb: USB Type-C connector class From: Oliver Neukum To: Guenter Roeck Cc: Heikki Krogerus , Badhri Jagan Sridharan , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org In-Reply-To: <20161128201143.GB10709@roeck-us.net> References: <20161122141147.21977-1-heikki.krogerus@linux.intel.com> <20161122141147.21977-3-heikki.krogerus@linux.intel.com> <20161124095755.GB17492@kuha.fi.intel.com> <1480328372.22547.8.camel@suse.com> <20161128142323.GA32668@kuha.fi.intel.com> <20161128201143.GB10709@roeck-us.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 29 Nov 2016 08:40:51 +0100 Mime-Version: 1.0 X-Mailer: Evolution 3.12.11 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2016-11-28 at 12:11 -0800, Guenter Roeck wrote: > On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote: > > On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote: > The Type-C specification states (in 4.5.2.2.11): > > "Note: if both Try.SRC and Try.SNK mechanisms are implemented, only one shall be > enabled by the port at any given time. Deciding which of these two mechanisms > is enabled is product design-specific." > > I read into this: > - The class code can not assume that either of those mechanisms are implemented. Total agreement > - "product-design specific" means that the product designer determines which of > the two mechanisms (if any) is enabled. While not explicitly stated, I would > assume this to be set either by hardware or via devicetree / ACPI, and not > from user space. I read this as spec-speak for "not our problem" > I don't mind to have user space control; all I am asking for is to have the > means for lower level code (which is the most likely entity to know about > product design) to be able to inform higher layers about its initial > preferences. We have this now, so I am happy. So am I. > Personally I don't really care about a module parameter; as mentioned above, > I would expect the preference, if it needs to be selectable, to be configured > with devicetree or ACPI properties (or by a platform driver which sets a device > property). Well, as a distro for generic desktops and servers you will face an XHCI on PCI and UCSI telling you that your ports can express preferences. Now deal with it. And it must be said that such distros have over a decade of experience in acting as a master. The slave capability is less well developed. We'd like to be master. And if possible we'd like to avoid a later switch of roles, so the choice should be easily made in initrd. Regards Oliver