Daniel Lenski writes:
> On Tue, May 31, 2016 at 8:04 AM, Jes Sorensen wrote:
>> Given your follow-on discoveries, do you still want me to apply the poll
>> timeout patch, or should we wait until we nail down the reset code issue
>> first?
>
> No, I
On Tue, May 31, 2016 at 8:04 AM, Jes Sorensen wrote:
> Given your follow-on discoveries, do you still want me to apply the poll
> timeout patch, or should we wait until we nail down the reset code issue
> first?
No, I don't think the timeout patch is worth appying. I
Jes Sorensen writes:
> Dan Lenski writes:
>> Here is a patch to increase the polling timeout for rtl8xxxu firmware
>> startup.
>>
>> This patch now applies cleanly to Jes Sorensen's rtl8xxxu-devel tree
>> (86c89dd4782030c4f9e0c82424a8b92f9fdb35aa).
>>
On Mon, May 23, 2016 at 12:24 PM, Jes Sorensen wrote:
> Interesting, so if I understand you correctly, if you run
> rtl8xxxu_power_off() once, the driver comes up correctly?
Right. If rtl8xxxu_init_device() fails, I simply call
rtl8xxxu_power_off(), and then
Daniel Lenski writes:
> I tried various versions of running rtl8xxxu_init_device in a loop, with
> delays in between retries, and did not have any success.
>
> If the device doesn't want to start on the first load after boot, running
> various parts of init over and over just
Daniel Lenski wrote:
> - Hypothesis: since the rtl8xxxu driver does not explicitly power off the
> device before attempting to power it on, if it boots up in an unknown
> state, it will remain in this state until explicitly power-cycled.
I am now pretty sure that this is the true cause of
Daniel Lenski writes:
> On Fri, May 20, 2016 at 1:50 PM, Daniel Lenski wrote:
>> Am I understanding your idea correctly? To put a loop around the 8051
>> reset and the firmware polling loop, with a delay between failure and retry?
>
> That was some sloppy
On Fri, May 20, 2016 at 7:08 AM, Jes Sorensen wrote:
>
> Daniel Lenski writes:
> > Unfortunately, I ran into a case today where even 5000 loops was not
> > enough after a cold boot. 5000 loops meant about 1.5 second delay
> > between finishing the
On Fri, May 20, 2016 at 1:50 PM, Daniel Lenski wrote:
> Am I understanding your idea correctly? To put a loop around the 8051
> reset and the firmware polling loop, with a delay between failure and retry?
That was some sloppy pseudo-code by me... here's what I think you're
Jes Sorensen writes:
> > Unfortunately, I ran into a case today where even 5000 loops was not
> > enough after a cold boot. 5000 loops meant about 1.5 second delay
> > between finishing the firmware checksum poll, while waiting for the
> > firmware to start. It now
Daniel Lenski writes:
> You're welcome, and thanks for writing this great driver. It really
> makes a huge difference for stability of the Yoga 13 wifi!
You're welcome! It made a big difference for my own Yoga 13 and it's
been an exciting project. I learned a lot in the
You're welcome, and thanks for writing this great driver. It really
makes a huge difference for stability of the Yoga 13 wifi!
Unfortunately, I ran into a case today where even 5000 loops was not
enough after a cold boot. 5000 loops meant about 1.5 second delay
between finishing the firmware
Dan Lenski writes:
> Here is a patch to increase the polling timeout for rtl8xxxu firmware
> startup.
>
> This patch now applies cleanly to Jes Sorensen's rtl8xxxu-devel tree
> (86c89dd4782030c4f9e0c82424a8b92f9fdb35aa).
>
> The patch to make this a module parameter was
Here is a patch to increase the polling timeout for rtl8xxxu firmware
startup.
This patch now applies cleanly to Jes Sorensen's rtl8xxxu-devel tree
(86c89dd4782030c4f9e0c82424a8b92f9fdb35aa).
The patch to make this a module parameter was removed.
Dan Lenski (1):
rtl8xxxu: Increase default
14 matches
Mail list logo