From: Krzysztof Opasiak <k.opasiak@samsung.com>
To: "Du, Changbin" <changbin.du@intel.com>,
"balbi@kernel.org" <balbi@kernel.org>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"corbet@lwn.net" <corbet@lwn.net>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Du, Changbin" <changbin.du@gmail.com>,
"Du@vger.kernel.org" <Du@vger.kernel.org>
Subject: Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC
Date: Thu, 05 May 2016 09:31:33 +0200 [thread overview]
Message-ID: <572AF6D5.9090406@samsung.com> (raw)
In-Reply-To: <0C18FE92A7765D4EB9EE5D38D86A563A05D2CE79@SHSMSX103.ccr.corp.intel.com>
Hi,
On 05/05/2016 07:46 AM, Du, Changbin wrote:
> Hi,
>>> 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.
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.
After this patch the kernel can return some kind of magic string "any"
which obviously will cannot be found in udc dir.
>>> And also we can change UDC name
>>> at any time if it is not binded (no need set to "" first).
>>>
>>
>> Not sure if:
>>
>> $ echo "" > UDC
>>
>> 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-name> > UDC
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.
Cheers,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
next prev parent reply other threads:[~2016-05-05 7:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-03 3:04 [PATCH 0/2] Add binding rule *any* support for USB Gadget Configfs changbin.du
2016-05-03 3:04 ` [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC changbin.du
2016-05-04 8:14 ` Krzysztof Opasiak
2016-05-05 5:46 ` Du, Changbin
2016-05-05 7:31 ` Krzysztof Opasiak [this message]
2016-05-06 2:46 ` Du, Changbin
2016-05-06 5:49 ` Krzysztof Opasiak
2016-06-04 20:56 ` Pavel Machek
2016-06-06 2:21 ` Du, Changbin
2016-05-03 3:04 ` [PATCH 2/2] Documentation: gadget_configfs: update UDC binding changbin.du
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=572AF6D5.9090406@samsung.com \
--to=k.opasiak@samsung.com \
--cc=Du@vger.kernel.org \
--cc=balbi@kernel.org \
--cc=changbin.du@gmail.com \
--cc=changbin.du@intel.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.