From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756625AbcEFCrA (ORCPT ); Thu, 5 May 2016 22:47:00 -0400 Received: from mga11.intel.com ([192.55.52.93]:50702 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754684AbcEFCq6 convert rfc822-to-8bit (ORCPT ); Thu, 5 May 2016 22:46:58 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,585,1455004800"; d="scan'208";a="969801904" From: "Du, Changbin" To: Krzysztof Opasiak , "balbi@kernel.org" CC: "gregkh@linuxfoundation.org" , "corbet@lwn.net" , "linux-usb@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Du, Changbin" , "Du@vger.kernel.org" Subject: RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC Thread-Topic: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC Thread-Index: AQHRpOom8e6AyvrFmk66g4aCEXJfQ5+n6hkAgAG3o5D//86fgIABxUXw Date: Fri, 6 May 2016 02:46:54 +0000 Message-ID: <0C18FE92A7765D4EB9EE5D38D86A563A05D2D2BA@SHSMSX103.ccr.corp.intel.com> References: <1462244665-27681-1-git-send-email-changbin.du@intel.com> <1462244665-27681-2-git-send-email-changbin.du@intel.com> <5729AF76.7080508@samsung.com> <0C18FE92A7765D4EB9EE5D38D86A563A05D2CE79@SHSMSX103.ccr.corp.intel.com> <572AF6D5.9090406@samsung.com> In-Reply-To: <572AF6D5.9090406@samsung.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2UyY2M2YzctOWRmNS00YjU5LTkzNmItMWRjZWU3NzkzODY1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Im94a3BDbG5RdVhrS2xoTVljUGh5TDhZRXJqZHhmallubnlYejIxa0JpblU9In0= x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > >>> On most platforms, there is only one device controller available. > >>> In this case, we desn't care the UDC's name. So let's ignore the > >>> name by setting 'UDC' to 'any'. > >> > >> Hmm libubsgx allows to do this for a very long time. You simply pass > >> NULL instead of pointer to usbg_udc. > >> > >> It is also possible to do this from command line, just simply: > >> > >> $ echo `ls -1 /sys/class/udc | head -n 1` > UDC > >> > >> So if we can easily do this from user space what's the benefit of adding > >> this special "any" keyword to kernel? > >> > > Well, it is just for *easy to use*. Looking up /sys/class/udc mostly > > can be skipped. The UDC core support this convenience behavior, > > so why don't we export it with a little change? > > > > Well, I'm not sure if any configfs interface has been proposed as easy > to use from cmd line. I think they all has been proposed as *usable* > from cmd line but not necessarily *easy to use*. > > That's why most of configfs clients has some support in userspace. For > example for target there is a taget-cli and for usb gadget we have > libusbg/libusbgx. > Glade to know this tool, it is much more easy to use than interact with sysfs. I'd like use it. Just see you are the main contributor of this project. :) > So the functionality which you proposed here is not only already > implemented in libusbgx but also can be easily achieved from cmd line > like I showed above. > > In addition this patch will break existing userspace tools (at least > libusbgx for sure) as it assumes that: > > cat UDC > > should return an empty string or an valid UDC name which can be found > inside /sys/class/udc. If so, this is not good. > >> is really a problem. Personally I'm quite used to situation in which I > >> have to turn the light off before turning it on once again;) > >> > > That is not a problem. But just avoid pseudo 'busy'. If gadget is not > > bind, it is free to reconfigure it. So seem no need block re-configuration. > > > > What do you mean pseudo 'busy'? If we do: > > echo > UDC > Sorry, please ignore this. I find if no UDC available, the config will be queued to a list, and will bind it when a UDC module install. So it is really busy. > then gadget should be really bound to some udc and potentially really busy. > > > In a word, this patch is just an improvement, not to fix any issues or > > add new function. > > So it doesn't add any new functionality and breaks existing user space > tools. > Ok, regarding there is a better tool, this change doesn't make much sense. So just abandon it. > Cheers, > -- > Krzysztof Opasiak > Samsung R&D Institute Poland > Samsung Electronics Best Regards, Du, Changbin