From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1425897AbcBRLSg (ORCPT ); Thu, 18 Feb 2016 06:18:36 -0500 Received: from mx2.suse.de ([195.135.220.15]:38893 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425274AbcBRLSb (ORCPT ); Thu, 18 Feb 2016 06:18:31 -0500 Message-ID: <1455794154.1384.35.camel@suse.com> Subject: Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI From: Oliver Neukum To: Heikki Krogerus Cc: Rajaram R , Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, "linux-usb@vger.kernel.org" Date: Thu, 18 Feb 2016 12:15:54 +0100 In-Reply-To: <20160218110543.GE1859@kuha.fi.intel.com> References: <1455037283-106479-1-git-send-email-heikki.krogerus@linux.intel.com> <20160218110543.GE1859@kuha.fi.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-02-18 at 13:05 +0200, Heikki Krogerus wrote: > > Since we have capability details of ports in user space, I believe > > cable capability is also necessary for policy decision(power, alt > > mode). Is that something we are cautiously leaving out ? pls explain > > Adding the cable control to this interface will make it more complex > from users perspective. However, nothing forces the user to control > also the cable. But we would like to indicate to the user that we cannot run an alternate mode because the cable is incapable as opposed to the device. Regards Oliver