From: Stanislaw Gruszka <sgruszka@redhat.com>
To: "Jakub Kiciński" <moorray3@wp.pl>
Cc: Richard Genoud <richard.genoud@gmail.com>,
Ivo van Doorn <IvDoorn@gmail.com>,
Gertjan van Wingerde <gwingerde@gmail.com>,
Helmut Schaa <helmut.schaa@googlemail.com>,
"John W. Linville" <linville@tuxdriver.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rt2x00: BUG: remove double loop on REGISTER_BUSY_COUNT
Date: Fri, 4 Apr 2014 16:06:15 +0200 [thread overview]
Message-ID: <20140404140614.GA2147@redhat.com> (raw)
In-Reply-To: <20140404110106.6d249615@north>
On Fri, Apr 04, 2014 at 11:01:06AM +0200, Jakub Kiciński wrote:
> On Fri, 4 Apr 2014 10:19:09 +0200, Stanislaw Gruszka wrote:
> > On Thu, Apr 03, 2014 at 05:37:01PM +0200, Jakub Kiciński wrote:
> > > On Thu, 3 Apr 2014 16:12:07 +0200, Richard Genoud wrote:
> > > > rt2x00usb_register_read_lock() calls rt2x00usb_vendor_req_buff_lock()
> > > > that calls rt2x00usb_vendor_request() which is already looping up to
> > > > REGISTER_BUSY_COUNT times.
> > > >
> > > > So this loop is not needed.
> > >
> > > Not true. rt2x00usb_vendor_request() busy-waits for usb_control_msg()
> > > to succeed, rt2x00usb_register_read_lock() busy-waits for the register
> > > field itself to become 0.
> >
> > Yeah, but still we are looping REGISTER_BUSY_COUNT*REGISTER_BUSY_COUNT
> > what seems to be far too long.
>
> Yes, the busy waiting itself takes roughly 1s (100*100*100us) and then
> there are transfer times, so it might be too long indeed. Vendor driver
> waits only 10 * 5ms in RTUSB_VendorRequest() so
We use "timeout" argument which is set to 500ms , so perhaps that
could be the reason why Richard sees "infinite" loop i.e.
100*100*(500ms + 100us)
> rt2x00usb_vendor_request() seems like a better place to cut down the
> number of loops.
>
> Alternatively we could make rt2x00usb_regbusy_read() check the retval
> from rt2x00usb_vendor_request() and exit early?
Make sense, but I think we should review the area and make some more
changes to fine tune the timeout of USB reg reading functions.
Stanislaw
next prev parent reply other threads:[~2014-04-04 14:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-03 14:12 [PATCH] rt2x00: BUG: remove double loop on REGISTER_BUSY_COUNT Richard Genoud
2014-04-03 15:37 ` Jakub Kiciński
2014-04-03 15:46 ` Richard Genoud
2014-04-04 8:19 ` Stanislaw Gruszka
2014-04-04 9:01 ` Jakub Kiciński
2014-04-04 14:06 ` Stanislaw Gruszka [this message]
2014-04-04 14:17 ` Richard Genoud
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=20140404140614.GA2147@redhat.com \
--to=sgruszka@redhat.com \
--cc=IvDoorn@gmail.com \
--cc=gwingerde@gmail.com \
--cc=helmut.schaa@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=moorray3@wp.pl \
--cc=richard.genoud@gmail.com \
/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.