All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: Daniel Lenski <dlenski@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] Make firmware startup polling timeout configurable, and increase default
Date: Wed, 18 May 2016 10:57:00 -0400	[thread overview]
Message-ID: <wrfj37pf1kjn.fsf@redhat.com> (raw)
In-Reply-To: <CAOw_LSEvU3OKm3MDe4FfHicd709548=S5Qm+wV=5mBOFV4TrKg@mail.gmail.com> (Daniel Lenski's message of "Tue, 17 May 2016 21:01:22 -0700")

Daniel Lenski <dlenski@gmail.com> writes:
> Jes Sorensen <Jes.Sorensen@redhat.com> writes:
>>
>> Dan Lenski <dlenski@gmail.com> writes:
>> >
>> > This issue seems to occur because RTL8XXXU_FIRMWARE_POLL_MAX (1000) is
>> > too short, and the MCU fails to start up as quickly as expected.
>> >
>> > With a longer value (5000), the driver starts up consistently and
>> > successfully after cold-boot.
>>
>> I am not against increasing the maximum value here, however I would like
>> more details about the system where you see these problems. I have used
>> this driver extensively for a long time with my Lenovo Yoga 13 laptop
>> and not seen this issue.
>
> Mine is also a Yoga 13.

Interesting, I thought it might have been an ARM board and it could be
something else that wasn't happening correctly. So far I only know of
the Yogas and certain ARM boards that have the 8723au.

>> Second, I really don't think this warrants a module parameter. Bumping
>> the value should suffice.
>
> Okay. Adding a module parameter was useful for me in debugging, and I
> thought it might be a useful backup option for other end-users who may
> find that the default value doesn't suffice.
>
> It seems plausible to me that the delay is due to waiting for some
> kind of analog circuit to stabilize (PLL, maybe?) and that there could
> be a large variation among devices.

I am surprised your system is that different from mine, but I am fine
with bumping it. I don't really like to clutter the module parameters
unnecessarily, and if we bump this to 5000, I think it is unlikely
anyone else will hit this problem. If they do, I think there are other
issues at play.

>> Note that the patch should at least be relative to
>> wireless-drivers-next, or preferably my rtl8xxxu-devel tree. In both of
>> these trees, the rtl8xxxu driver has been split into multiple files and
>> your patch will not apply.
>>
>> Last, neither of the links you included for external bug reports work.
>
> Are you still unable to follow them in the second version of the patches that
> I submitted? (It appears that they were mangled by Gmane the first
> time I posted them.)
>
> Here they are again:
>
> http://ubuntuforums.org/showthread.php?t=2321756
>
> That is, thread #2321756 at ubuntuforums.org
>
> https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg4942468.html
>
> That is, Ubuntu bug #1574622

I found them from your second post.

Cheers,
Jes

      reply	other threads:[~2016-05-18 14:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17 22:48 [PATCH] increase rtl8xxxu polling timeout for firmware startup Dan Lenski
2016-05-17 22:48 ` [PATCH] Make firmware startup polling timeout configurable, and increase default Dan Lenski
2016-05-18  0:58   ` Julian Calaby
2016-05-18  3:33   ` Jes Sorensen
2016-05-18  4:01     ` Daniel Lenski
2016-05-18 14:57       ` Jes Sorensen [this message]

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=wrfj37pf1kjn.fsf@redhat.com \
    --to=jes.sorensen@redhat.com \
    --cc=dlenski@gmail.com \
    --cc=linux-wireless@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.