From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752365AbbE0G77 (ORCPT ); Wed, 27 May 2015 02:59:59 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:56818 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751194AbbE0G75 (ORCPT ); Wed, 27 May 2015 02:59:57 -0400 X-AuditID: cbfec7f4-f79c56d0000012ee-ab-55656b6aa96a Message-id: <55656B61.1000708@samsung.com> Date: Wed, 27 May 2015 08:59:45 +0200 From: Robert Baldyga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-version: 1.0 To: balbi@ti.com Cc: gregkh@linuxfoundation.org, m.szyprowski@samsung.com, andrzej.p@samsung.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/5] usb: gadget: Fix gadget deactivaton feature References: <1430744115-22096-1-git-send-email-r.baldyga@samsung.com> <20150526170810.GR26599@saruman.tx.rr.com> In-reply-to: <20150526170810.GR26599@saruman.tx.rr.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsVy+t/xK7pZ2amhBo3LFCxmvWxnsTh4v96i efF6NovLu+awWSxa1spssfbIXXYHNo/9c9ewe/RtWcXocfzGdiaPz5vkAliiuGxSUnMyy1KL 9O0SuDIOv7rDWHBYrOJZ1wy2BsaDQl2MnBwSAiYSv+aeYYGwxSQu3FvP1sXIxSEksJRRYtnP jWwgCSGBZ4wSf//XdzFycPAKaEnce8YCYrIIqErM2pQKUsEmoCOx5fsERpCwqECERPeJSpAw r4CgxI/J98CmiwgISKx/cYkdZDqzQBejxJnZV8GmCwu4S/xf3MIOsalIou3FP0YQm1PAXOLm jLVgM5kF9CTuX9QCCTMLyEtsXvOWeQKjwCwkK2YhVM1CUrWAkXkVo2hqaXJBcVJ6rqFecWJu cWleul5yfu4mRkgYf9nBuPiY1SFGAQ5GJR7eA9KpoUKsiWXFlbmHGCU4mJVEeGd4AYV4UxIr q1KL8uOLSnNSiw8xSnOwKInzzt31PkRIID2xJDU7NbUgtQgmy8TBKdXA6JGU+bBfQ/OC7LfN 2/n27X/05gbr0ySl/B8rT87urFjoUvrVUTaMzWLJh0uzzs+avZ/1sQGHfUG1oepUqb3mmXzb N1j8Ua7vPfcy9Or6Ses+GP7MlJd5u3dGEWPPjYdvzMq2TX2ll7WIa/qlDMblmcdkb6R/Pcy8 V/W8wC+7k5+PTN87f3uLgKUSS3FGoqEWc1FxIgD6lJ0tXwIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Felipe, On 05/26/2015 07:08 PM, Felipe Balbi wrote: > On Mon, May 04, 2015 at 02:55:10PM +0200, Robert Baldyga wrote: >> Hi, >> >> This patch set introduces two functions usb_gadget_deactivate() and >> usb_gadget_activate(), designed to prevent udc-core from showing binded >> gadget to host until it will be ready to work. It also makes >> usb_function_deactivate()/activate() using these functions. >> >> So far gadget deactivation was made by calling usb_gadget_disconnect(), >> but since we have usb_gadget_connect() called after gadget->bind() >> (in udc_bind_to_driver()) this method doesn't provide expected result. >> Calling function usb_gadget_disconnect() before gadget connection doesn't >> prevent udc-core from connecting gadget to driver - usb_gadget_disconnect() >> call is ignored and gadget is connected regardless to it. This usually >> results with errors, for example because we binded gadget with 0 >> configurations. >> >> This patch set fixes this problem adding functions allowing to perform >> effective gadget deactivation from gadget->bind(). >> >> According to Felipe's suggestion, in v2 there is one new patch adding >> 'bind_deactivated' flag, which should be used by functions which want >> to be binded as deactivated (for example because they need to wait for >> userspace daemon). Functions using this flag have to call >> usb_function_activate() to tell composite core they are ready to work. >> I have also converted functions which are using deactivation feature >> to make them using 'bind_deactivated' flag. Patches are also attached >> to this patch set. >> >> I was considering removing usb_function_deactivate() function since we >> have this flag, but I see that some of USB functions use it not only >> in bind() but also e.g. when userspace daemon disconnects. This is also >> the reason why I haven't named this flag 'controls_pullup', because this >> name doesn't describe precisely what does it mean. >> >> We also need to consider what to do when deactivation fails (which can >> happen if our UDC driver doesn't support the pullup callback). So far, >> when usb_function_deactivate() was called in bind(), we have had ability >> to decide what to do, when it fails. Now we preform function deactivation >> before its bind(), and when deactivation fails we fail to add the function >> to gadget. Maybe we should to allow it to continue despite deactivation >> failure and inform function (somehow) about this situation. If only it >> makes any sense, because in this form it looks more complicated that >> it was, and moreover it actually doesn't add any new features. > > I'll defer this series for v4.3 merge window because I'm still not > entirely convinced we need this new reference counter. Sorry about that. > What reference counter did you mean? Thanks, Robert