From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753745AbcGDRpJ (ORCPT ); Mon, 4 Jul 2016 13:45:09 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:54178 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753058AbcGDRpG (ORCPT ); Mon, 4 Jul 2016 13:45:06 -0400 Subject: Re: [PATCHv4 1/2] usb: USB Type-C connector class To: Heikki Krogerus References: <1467207518-55953-1-git-send-email-heikki.krogerus@linux.intel.com> <1467207518-55953-2-git-send-email-heikki.krogerus@linux.intel.com> <20160630220220.GA3707@roeck-us.net> <20160701071348.GA21901@kuha.fi.intel.com> <20160701120535.GA7673@kuha.fi.intel.com> <20160701143312.GA14350@roeck-us.net> <20160703193828.GA30987@kuha.fi.intel.com> <5779838C.9050008@roeck-us.net> <20160704171153.GA26797@kuha.fi.intel.com> Cc: Greg KH , Oliver Neukum , Felipe Balbi , Roger Quadros , Rajaram R , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org From: Guenter Roeck Message-ID: <577AA09E.3030909@roeck-us.net> Date: Mon, 4 Jul 2016 10:45:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160704171153.GA26797@kuha.fi.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/04/2016 10:11 AM, Heikki Krogerus wrote: [ ... ] >>> We should not forget also that the userspace can never rely on those >>> details because of the fact that they simply will not always be >>> available. >>> >> On the other side, not being able to rely on a well defined ABI makes the >> ABI much less useful. > > What do we do about this? > I'll have to think about it. Unfortunately, I'll have to put this on the back-burner for the time being. My primary problem is that I need a functional driver _now_ (ie by the end of this week), to meet an upcoming deadline. Due to to the locking problem, I can not rely on the typec infrastructure ... meaning I have to take two steps back and get my code working with the Android infrastructure (which, coincidentally, does not require locking and thus doesn't have all the resulting limitations and complexities). Guenter