From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162019AbdAIQ7s (ORCPT ); Mon, 9 Jan 2017 11:59:48 -0500 Received: from bh-25.webhostbox.net ([208.91.199.152]:57323 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762630AbdAIQ7h (ORCPT ); Mon, 9 Jan 2017 11:59:37 -0500 Date: Mon, 9 Jan 2017 08:59:32 -0800 From: Guenter Roeck To: Heikki Krogerus Cc: Greg KH , Oliver Neukum , Mika Westerberg , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCHv14 2/3] usb: USB Type-C connector class Message-ID: <20170109165932.GA16253@roeck-us.net> References: <20170105110119.87401-1-heikki.krogerus@linux.intel.com> <20170105110119.87401-3-heikki.krogerus@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170105110119.87401-3-heikki.krogerus@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Authenticated_sender: guenter@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: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@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 Hello Heikki, On Thu, Jan 05, 2017 at 02:01:18PM +0300, Heikki Krogerus wrote: > The purpose of USB Type-C connector class is to provide > unified interface for the user space to get the status and > basic information about USB Type-C connectors on a system, > control over data role swapping, and when the port supports > USB Power Delivery, also control over power role swapping > and Alternate Modes. > > Signed-off-by: Heikki Krogerus > --- [ ... ] > + > +/** > + * typec_register_partner - Register a USB Type-C Partner > + * @port: The USB Type-C Port the partner is connected to > + * @desc: Description of the partner > + * > + * Registers a device for USB Type-C Partner described in @desc. > + * > + * Returns handle to the partner on success or NULL on failure. > + */ > +struct typec_partner *typec_register_partner(struct typec_port *port, > + struct typec_partner_desc *desc) > +{ With the changes to hide the actual partner structure, this looks at first glance like a minor API change, but it is substantial. Reason is that the vdo as required by typec_partner_desc is provided by a VDM command reply, which is completely orthogonal to the PD registration process. So far I was able to set the vdo later, after registering the connection, and after (and if) the vdo was received. Since the partner may not even respond to the DISCOVER_IDENT message, or not support PD at all, this means that I would have to disconnect partner registration from the PD protocol itself and tie it to the VDO message exchange, with appropriate timeouts to register anyway even if the identity was not received after some period of time or if the partner does not support PD. This in turn means that I'll have to re-implement and possibly re-architect a substantial amount of code. What is the reason for this change ? If I spend that time, I would like to understand why it is necessary (compared to setting/updating the vdo if/when it is available). Thanks, Guenter