From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932126AbcEYLbG (ORCPT ); Wed, 25 May 2016 07:31:06 -0400 Received: from mga04.intel.com ([192.55.52.120]:58001 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751043AbcEYLbE (ORCPT ); Wed, 25 May 2016 07:31:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,364,1459839600"; d="scan'208";a="110197854" Date: Wed, 25 May 2016 14:30:58 +0300 From: Heikki Krogerus To: Guenter Roeck Cc: Greg KH , Mathias Nyman , Felipe Balbi , Oliver Neukum , Rajaram R , Andy Shevchenko , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class Message-ID: <20160525113058.GC27570@kuha.fi.intel.com> References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <57445A31.9060304@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57445A31.9060304@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 Hi, On Tue, May 24, 2016 at 06:42:09AM -0700, Guenter Roeck wrote: > > +struct typec_capability { > > + enum typec_data_role role; > > + unsigned int usb_pd:1; > > + struct typec_altmode *alt_modes; > > + unsigned int audio_accessory:1; > > + unsigned int debug_accessory:1; > > + > > + int (*fix_role)(struct typec_port *, > > + enum typec_data_role); > > + > > + int (*dr_swap)(struct typec_port *); > > + int (*pr_swap)(struct typec_port *); > > + int (*vconn_swap)(struct typec_port *); > > + > > The function parameter in those calls is all but useless to the caller. > It needs to store the typec_port returned from typec_register(), create a > list of ports, and then search through this list each time one of the > functions is called. This is quite expensive for no good reason. > > Previously, with typec_port exported, the called code could use the stored > caps pointer to map to its internal data structures. This is no longer > possible. True, the API now is in practice broken. > I think it would be useful to provide a better means for the called function > to identify its context. Maybe provide a pointer to the private data in > the registration function and use it as parameter in the callback functions ? Sounds reasonable. Thanks, -- heikki