On Wed, 2013-07-17 at 03:10 +, WangChen wrote:
> Sorry, I think existing code should already handle retry for blcoking case.
> My idea to retry anyway @line328 is just intention to make the code looks
> better
> and handle the return of -EAGAIN in one place which is handled by retry
> logi
this :)
> From: unicorn_w...@outlook.com
> To: oneu...@suse.de
> CC: linux-usb@vger.kernel.org
> Subject: RE: question on skel_read func of usb_skeleton.c
> Date: Wed, 17 Jul 2013 03:02:49 +
>
> Oliver,
> For the func skel_read(
able to handle all the
other stuff such as nonblockking IO in one place.
> From: unicorn_w...@outlook.com
> To: oneu...@suse.de
> CC: linux-usb@vger.kernel.org
> Subject: RE: question on skel_read func of usb_skeleton.c
> Date: Sun, 14 Ju
.
> From: oneu...@suse.de
> To: unicorn_w...@outlook.com
> CC: linux-usb@vger.kernel.org
> Subject: Re: question on skel_read func of usb_skeleton.c
> Date: Fri, 12 Jul 2013 15:38:04 +0200
>
> On Friday 12 July 2013 13:09:23 WangChen wrote:
>> Oliver, my understanding is th
On Friday 12 July 2013 13:09:23 WangChen wrote:
> Oliver, my understanding is the limit_sem will only cause write() to sleep
> and wait for other IOs to finish when there are alreay WRITES_IN_FLIGHT URBs
> are on going. I see code line 509: sema_init(&dev->limit_sem,
> WRITES_IN_FLIGHT)
On Friday 12 July 2013 13:09:23 WangChen wrote:
> Oliver, my understanding is the limit_sem will only cause write() to sleep
> and wait for other IOs to finish when there are alreay WRITES_IN_FLIGHT URBs
> are on going. I see code line 509: sema_init(&dev->limit_sem,
> WRITES_IN_FLIGHT)
...@suse.de
> CC: linux-usb@vger.kernel.org
> Subject: RE: question on skel_read func of usb_skeleton.c
> Date: Fri, 12 Jul 2013 13:09:23 +
>
> Oliver, my understanding is the limit_sem will only cause write() to sleep
> and wait for other IOs to finish when there are alreay
k every write() when corresponding
URBs is not finished, am I right?
> From: oneu...@suse.de
> To: unicorn_w...@outlook.com
> CC: linux-usb@vger.kernel.org
> Subject: Re: question on skel_read func of usb_skeleton.c
> Date: Fri, 12 Jul 2013
On Friday 12 July 2013 04:49:54 WangChen wrote:
> Hi, Oliver,
> Regarding skel_write, I see your current desgin only refuse its execution
> when> WRITES_IN_FLIGHT are on the fly, but this is not blocking IO due to
> write() will not wait before callback returns, right? Do you think it's
> unnec
g
> To: unicorn_w...@outlook.com
> CC: oneu...@suse.de; linux-usb@vger.kernel.org
> Subject: Re: question on skel_read func of usb_skeleton.c
>
> On Fri, Jul 12, 2013 at 05:51:04AM +, WangChen wrote:
>> I'm writing a driver for OSRFX2 learning board to test bulkloop
On Fri, Jul 12, 2013 at 05:51:04AM +, WangChen wrote:
> I'm writing a driver for OSRFX2 learning board to test bulkloop
> read/write.
What's wrong with the existing usb-serial driver that can easily do
this?
> I think non-blocking write is good for such device due to
> the FX2 chipset has dua
their application? Looks like this is not a tech question
...
> Date: Thu, 11 Jul 2013 21:56:39 -0700
> From: gre...@linuxfoundation.org
> To: unicorn_w...@outlook.com
> CC: oneu...@suse.de; linux-usb@vger.kernel.org
> Subject: Re: question
On Fri, Jul 12, 2013 at 04:49:54AM +, WangChen wrote:
> Hi, Oliver,
> Regarding skel_write, I see your current desgin only refuse its
> execution when> WRITES_IN_FLIGHT are on the fly, but this is not
> blocking IO due to write() will not wait before callback returns,
> right? Do you think it'
special reason else?
> From: unicorn_w...@outlook.com
> To: oneu...@suse.de
> CC: linux-usb@vger.kernel.org
> Subject: RE: question on skel_read func of usb_skeleton.c
> Date: Thu, 11 Jul 2013 09:07:22 +
>
> Thank you, Oliver. I'
Thank you, Oliver. I'm getting to understand your code :)
> From: oneu...@suse.de
> To: unicorn_w...@outlook.com
> CC: linux-usb@vger.kernel.org
> Subject: Re: question on skel_read func of usb_skeleton.c
> Date: Tue, 9 Jul 2013 1
On Tuesday 09 July 2013 09:32:35 WangChen wrote:
> Plus, regarding the reset case, urb-status will be non-zero, won't it?
Only at the first call to read()
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to ma
On Tuesday 09 July 2013 09:29:50 WangChen wrote:
Hi,
> Sorry, I still have not understood why we need to get the var - available by
> "dev->bulk_in_filled - dev->bulk_in_copied". dev->bulk_in_copied is always
> reset as zero in skel_do_read_io, right?
Well, no. If skel_do_read_io() runs, it is
Adding CC
Sorry, I still have one more quesiton embedded.
> From: oneu...@suse.de
> To: unicorn_w...@outlook.com
> Subject: Re: question on skel_read func of usb_skeleton.c
> Date: Tue, 9 Jul 2013 08:42:19 +0200
>
> On Tuesday 09 July 2013 01:25:00 汪辰 wrote:
>> Thank
Plus, regarding the reset case, urb-status will be non-zero, won't it?
> From: unicorn_w...@outlook.com
> To: oneu...@suse.de
> CC: linux-usb@vger.kernel.org
> Subject: RE: question on skel_read func of usb_skeleton.c
> Date: Tue, 9 Jul
On Monday 08 July 2013 13:09:05 汪辰 wrote:
> hi,
> I'm reading latest usb_skeleton.c sample and compared with that with ldd3
> book.
> Looks like the skel_read changed a lot against previous version. Why we now
> not use usb_bulk_msg, just due to we want to get chance to cancel the urb if
> any u
hi,
I'm reading latest usb_skeleton.c sample and compared with that with ldd3 book.
Looks like the skel_read changed a lot against previous version. Why we now not
use usb_bulk_msg, just due to we want to get chance to cancel the urb if any
unexpected exit?
Also in current skel_read function, I
21 matches
Mail list logo
