RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Du, Changbin]

Thanks, Machek, This patch has already been dropped.

> On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote:
> > From: "Du, Changbin" 
> >
> > 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'. And also we can change UDC name
> > at any time if it is not binded (no need set to "" first).
> 
> making "any" special does not look like a good idea. What if it really
> is "any"?
> 
> Return nothing instead, not even \n?
> 
> > Signed-off-by: Du, Changbin 
> > Signed-off-by: Du, Changbin 
> 
> I don't think this is how you should sign it off.
> 
> Best regards,
> 
>   Pavel
> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Du, Changbin]

Thanks, Machek, This patch has already been dropped.

> On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote:
> > From: "Du, Changbin" 
> >
> > 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'. And also we can change UDC name
> > at any time if it is not binded (no need set to "" first).
> 
> making "any" special does not look like a good idea. What if it really
> is "any"?
> 
> Return nothing instead, not even \n?
> 
> > Signed-off-by: Du, Changbin 
> > Signed-off-by: Du, Changbin 
> 
> I don't think this is how you should sign it off.
> 
> Best regards,
> 
>   Pavel
> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Pavel Machek]

On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote:
> From: "Du, Changbin" 
> 
> 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'. And also we can change UDC name
> at any time if it is not binded (no need set to "" first).

making "any" special does not look like a good idea. What if it really
is "any"?

Return nothing instead, not even \n?

> Signed-off-by: Du, Changbin 
> Signed-off-by: Du, Changbin 

I don't think this is how you should sign it off.

Best regards,

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Pavel Machek]

On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote:
> From: "Du, Changbin" 
> 
> 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'. And also we can change UDC name
> at any time if it is not binded (no need set to "" first).

making "any" special does not look like a good idea. What if it really
is "any"?

Return nothing instead, not even \n?

> Signed-off-by: Du, Changbin 
> Signed-off-by: Du, Changbin 

I don't think this is how you should sign it off.

Best regards,

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Krzysztof Opasiak]

On 05/06/2016 04:46 AM, Du, Changbin wrote:
(...)
>> 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. :)
> 

That's true;) personally I would recommend you using libusbgx[1] instead
of libusbg[2] as it is far more recent and usable (292 commits vs 128;) )

(...)

>>
>> 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.
>>

Yes, currently it's true but it's a bug which I have fixed yesterday[3]

Footnotes:
1 - https://github.com/libusbgx/libusbgx
2 - https://github.com/libusbg/libusbg
3 - http://marc.info/?l=linux-usb=146243801207458=2

Cheers,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Krzysztof Opasiak]

On 05/06/2016 04:46 AM, Du, Changbin wrote:
(...)
>> 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. :)
> 

That's true;) personally I would recommend you using libusbgx[1] instead
of libusbg[2] as it is far more recent and usable (292 commits vs 128;) )

(...)

>>
>> 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.
>>

Yes, currently it's true but it's a bug which I have fixed yesterday[3]

Footnotes:
1 - https://github.com/libusbgx/libusbgx
2 - https://github.com/libusbg/libusbg
3 - http://marc.info/?l=linux-usb=146243801207458=2

Cheers,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Du, Changbin]

> >>> 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 Institute Poland
> Samsung Electronics

Best Regards,
Du, Changbin

RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Du, Changbin]

> >>> 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 Institute Poland
> Samsung Electronics

Best Regards,
Du, Changbin

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Krzysztof Opasiak]

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

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 Institute Poland
Samsung Electronics

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Krzysztof Opasiak]

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

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 Institute Poland
Samsung Electronics

RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Du, Changbin]

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?

> > 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.

In a word, this patch is just an improvement, not to fix any issues or
add new function.

> Cheers,
> --
> Krzysztof Opasiak
> Samsung R Institute Poland
> Samsung Electronics

Thanks,
Du, Changbin

RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Du, Changbin]

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?

> > 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.

In a word, this patch is just an improvement, not to fix any issues or
add new function.

> Cheers,
> --
> Krzysztof Opasiak
> Samsung R Institute Poland
> Samsung Electronics

Thanks,
Du, Changbin

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Krzysztof Opasiak]

On 05/03/2016 05:04 AM, changbin...@intel.com wrote:
> From: "Du, Changbin" 
> 
> 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?

> 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;)

Cheers,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Krzysztof Opasiak]

On 05/03/2016 05:04 AM, changbin...@intel.com wrote:
> From: "Du, Changbin" 
> 
> 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?

> 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;)

Cheers,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics