From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752090AbcGESrb (ORCPT ); Tue, 5 Jul 2016 14:47:31 -0400 Received: from mga14.intel.com ([192.55.52.115]:2489 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750962AbcGESr2 (ORCPT ); Tue, 5 Jul 2016 14:47:28 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,580,1464678000"; d="scan'208";a="841080392" Date: Tue, 5 Jul 2016 21:47:23 +0300 From: Heikki Krogerus To: Guenter Roeck Cc: Greg KH , Oliver Neukum , Felipe Balbi , Roger Quadros , Rajaram R , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCHv4 1/2] usb: USB Type-C connector class Message-ID: <20160705184723.GA6976@kuha.fi.intel.com> 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> <577AA09E.3030909@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577AA09E.3030909@roeck-us.net> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 04, 2016 at 10:45:02AM -0700, Guenter Roeck wrote: > 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). That is unfortunate. I added a commit where I remove the lock completely (at least for now) to my github. Cheers, -- heikki