From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933651AbbBISGK (ORCPT ); Mon, 9 Feb 2015 13:06:10 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:9165 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933175AbbBISGI (ORCPT ); Mon, 9 Feb 2015 13:06:08 -0500 X-AuditID: cbfec7f4-b7f126d000001e9a-eb-54d8f67ba947 From: Krzysztof Opasiak To: "'Alan Stern'" , "'Ruslan Bilovol'" , "'Peter Chen'" Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, "'Balbi, Felipe'" , gregkh@linuxfoundation.org, Andrzej Pietrasiewicz References: In-reply-to: Subject: RE: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers Date: Mon, 09 Feb 2015 19:06:02 +0100 Message-id: <100e01d04493$11a2fd40$34e8f7c0$%opasiak@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AdBEhorgtXa59ivnTkmvPJf6JNMh7gABQxZw Content-language: pl X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsVy+t/xK7rV326EGGx9wGox62U7i8XB+/UW zYvXs1lc3jWHzWLRslZmi2Oz/zJZ9Ow8wWgx4fcFNgcOj3+H+5k8ds66y+6xf+4ado/Zd38w evRtWcXocfzGdiaPz5vkAtijuGxSUnMyy1KL9O0SuDKev7nGWLBKuOLu0VnsDYxf+boYOTgk BEwkFsyP6mLkBDLFJC7cW8/WxcjFISSwlFHi8+prUE4Dk8Sv1VeYQRrYBPQl5u0SBYmLCLQx Slz9184O4jALrGGUeP1mHTNExzRGiXvXX7KDzOUU8JNonvWFCcQWFsiQ6O7/BGazCKhKNH19 yAZi8wo4Suy/tR/KFpT4MfkeC4jNLKAlsX7ncSYIW15i85q3zBBnq0s8+qsLYooIGEkc+CEJ USEicbfhOesERqFZSAbNQjJoFpJBs5C0LGBkWcUomlqaXFCclJ5rqFecmFtcmpeul5yfu4kR EklfdjAuPmZ1iFGAg1GJh/fClRshQqyJZcWVuYcYJTiYlUR4f5wBCvGmJFZWpRblxxeV5qQW H2Jk4uCUamBU3ioy+b3HxG33RVs+iPUcZ96+YQXH4fP/Jnza7X7cfeW3TtaZu+RvOf12vi/h 93lhXqR12lLJA4sn//x0w9GWLzOAz1vGsHhi5R/f9DVekQz5181X+pr57nbnlVy31UZ3etjN hNUqkybPXPysdOVGV7+4fS0XF+u2CP5j7ud9YxyxMmvyJhZ2JZbijERDLeai4kQA9z97U4IC AAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, (... snip ...) > > > > You don't need all this stuff. What's the point of keeping > track of > > > names? If there are any unbound gadget drivers pending, a > newly > > > registered UDC should bind to the first one available. > > > > It's because gadget driver may be bound to usb_gadget in two > ways: > > - standard way - in this case any available udc will be picked > up > > - by name of udc, in this case only matching udc will be picked > up > > Where did this "by name" feature come from? You did not mention it > in > the patch description. > > Why bother matching by name? Why not simply take the first > available > UDC? Because you may have more than one udc. This would allow to pick one by name just like using configfs interface. > > > Main feature of my path is not only deferred binding of gadget > driver, > > but also possibility to register/unregister udc at any time. > > This is useful for user who can load, for example, udc module > > if needed and unload it safely, not touching gadget driver. > > We can already do that with the existing code. There's no need for > a > patch. > > Also, it's not clear that the existing gadget drivers will work > properly if they are unbound from one UDC and then bound again to > another one. They were not written with that sort of thing in > mind. > What you have described is one of basics configfs features. You should be able to bind and unbind your gadget whenever you want and it should work properly after doing: ## create gadget $ echo "udc.0" > UDC $ echo "" > UDC $ echo "udc.1" > UDC Function shouldn't care which udc it has been bound previously. Only current one is important and on each unbind each function should cleanup its state and prepare to be bound to another udc. Configfs interface doesn't prohibit this and I haven't seen any info about such restriction. If some function is not working in such situation there is a bug in that function and it should be fixed. I have tried to test this on my odroid with dwc2 and dummy_hcd. Most of functions seems to be working but for example ecm isn't. After some digging with Robert we found that it's always reusing endpoints received in first bind(). Once again in my opinion it's a bug which should be fixed and not treated as general assumption. -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics k.opasiak@samsung.com