From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932742AbcKVKvS (ORCPT <rfc822;w@1wt.eu>);
        Tue, 22 Nov 2016 05:51:18 -0500
Received: from mga01.intel.com ([192.55.52.88]:36224 "EHLO mga01.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932263AbcKVKvQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 22 Nov 2016 05:51:16 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.31,680,1473145200"; 
   d="scan'208";a="194401678"
Date: Tue, 22 Nov 2016 12:51:11 +0200
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
        Badhri Jagan Sridharan <badhri@google.com>,
        Oliver Neukum <oneukum@suse.com>, linux-kernel@vger.kernel.org,
        linux-usb@vger.kernel.org
Subject: Re: [PATCHv11 2/3] usb: USB Type-C connector class
Message-ID: <20161122105111.GF18501@kuha.fi.intel.com>
References: <20161117105036.133406-1-heikki.krogerus@linux.intel.com>
 <20161117105036.133406-3-heikki.krogerus@linux.intel.com>
 <20161121103528.GB2233@kroah.com>
 <20161121131103.GA18501@kuha.fi.intel.com>
 <20161121144506.GA28410@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161121144506.GA28410@kroah.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Greg,

On Mon, Nov 21, 2016 at 03:45:06PM +0100, Greg KH wrote:
> > We could allocate an extra structure for the partner when
> > typec_connect() is called, but we would do that just for the sake of
> > having something to free in the release hook. It would not be useful
> > for anything. It would not help us increase/decrease the reference
> > count of the device, and the port driver would still have to provide
> > details about the partner capabilities the moment it tells us the
> > partner was connected.
> 
> Again, free the device for which this release function is being called
> for, that is why it is there.

The struct device is now member of struct typec_partner. This is what
a typical port driver would have (I hope it's readable):

struct my_port {
        /* This structure is provided by the class */
        struct typec_port *port;

        /*
         * Don't forget, there can only be one partner at a time
         */
        struct typec_partner partner; /* NOTE: this is not a pointer */
};

int my_interrupt(...)
{
        ...
        /*
         * Connection happened (I'm skipping the typec_connection
         * wrapper in this example)
         */
        my_port->partner.usb_pd = ...
        ...
        ret = typec_connect(my_port->port, &my_port->partner);
        ...
        /*
         * Disconnect
         */
        typec_disconnect(my_port->port);
        memset(&my_port->partner, 0, sizeof(struct typec_partner));
        ...
}

int my_probe(...)
{
        struct my_port *my_port;
        ...
        my_port = devm_kzalloc(...
        ...
        my_port->port = typec_register_port(...
        ...
}

To have something to free when the partner device's reference counter
goes to zero and release is called (this happens after all the
alternate modes, so the children, and the device are unregistered), we
will need an extra structure, just for the fun of having something to
free in release.

struct internal_partner_structure {
        struct device dev;
        struct typec_partner *partner_capabilities; /* port driver provides */
};

Why is this necessary in this case? It is just something extra we have
to do, just so we can allocate that when connection happens and the
partner device is generated, and so we can then free that thing when
release gets called? It does not give us anything. It does not affect
anything.


Thanks,

-- 
heikki