netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Kalle Valo <kvalo@codeaurora.org>, Adam Ford <aford173@gmail.com>
Cc: Linux-OMAP <linux-omap@vger.kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	linux-wireless@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: Long Delay on startup of wl18xx Wireless chip
Date: Wed, 6 Nov 2019 11:38:24 +0100	[thread overview]
Message-ID: <7BC95BF7-0E1D-4863-AB71-37BB6E8E297E@goldelico.com> (raw)
In-Reply-To: <87sgn1z467.fsf@codeaurora.org>


> Am 06.11.2019 um 11:32 schrieb Kalle Valo <kvalo@codeaurora.org>:
> 
> Adam Ford <aford173@gmail.com> writes:
> 
>> On Tue, Nov 5, 2019 at 12:25 PM Adam Ford <aford173@gmail.com> wrote:
>>> 
>>> I am seeing a really long delay at startup of the wl18xx using the 5.4 kernel.
>>> 
>> 
>> Sorry I had to resend.  I forgot to do plaintext.  Google switched
>> settings on me and neglected to inform me.
>> 
>> 
>>> [ 7.895551] wl18xx_driver wl18xx.2.auto: Direct firmware load for
>>> ti-connectivity/wl18xx-conf.bin failed with error -2
>>> [ 7.906416] wl18xx_driver wl18xx.2.auto: Falling back to sysfs
>>> fallback for: ti-connectivity/wl18xx-conf.bin
>>> 
>>> At this point in the sequence, I can login to Linux, but the WL18xx is unavailable.
>>> 
>>> [   35.032382] vwl1837: disabling
>>> [ 69.594874] wlcore: ERROR could not get configuration binary
>>> ti-connectivity/wl18xx-conf.bin: -11
>>> [   69.604013] wlcore: WARNING falling back to default config
>>> [   70.174821] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
>>> [ 70.189003] wlcore: WARNING Detected unconfigured mac address in
>>> nvs, derive from fuse instead.
>>> [   70.197851] wlcore: WARNING This default nvs file can be removed from the file system
>>> [   70.218816] wlcore: loaded
>>> 
>>> It is now at this point when the wl18xx is available.
>>> 
>>> I have the wl18xx and wlcore setup as a module so it should load
>>> after the filesystem is mounted. I am not using a wl18xx-conf.bin,
>>> but I never needed to use this before.
>>> 
>>> It seems to me unreasonable to wait 60+ seconds after everything is
>>> mounted for the wireless chip to become available. Before I attempt
>>> to bisect this, I was hoping someone might have seen this. I am also
>>> trying to avoid duplicating someone else's efforts.
>>> 
>>> I know the 4.19 doesn't behave like this.
> 
> Try disabling CONFIG_FW_LOADER_USER_HELPER, that usually causes a 60
> second delay if the user space is not setup to handle the request. (Or
> something like that.)

I can confirm that I have it disabled in our config which seems to work.

BR,
Nikolaus


  reply	other threads:[~2019-11-06 10:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAHCN7xJiJKBgkiRm-MF9NpgQqfV4=zSVRShc5Sb5Lya2TAxU0g@mail.gmail.com>
2019-11-05 18:55 ` Long Delay on startup of wl18xx Wireless chip Adam Ford
2019-11-05 19:24   ` H. Nikolaus Schaller
2019-11-06 10:32   ` Kalle Valo
2019-11-06 10:38     ` H. Nikolaus Schaller [this message]
2019-11-06 12:46       ` Adam Ford

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=7BC95BF7-0E1D-4863-AB71-37BB6E8E297E@goldelico.com \
    --to=hns@goldelico.com \
    --cc=aford173@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).