All of lore.kernel.org
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Arend van Spriel <arend@broadcom.com>
Cc: "John W. Linville" <linville@tuxdriver.com>,
	Kay Sievers <kay.sievers@vrfy.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Tom Gundersen <teg@jklm.no>, Andy Whitcroft <apw@canonical.com>,
	Johannes Berg <johannes@sipsolutions.net>
Subject: Re: calling request_firmware() from module init will not work with recent/future udev versions
Date: Sat, 14 Jan 2012 14:13:02 -0600	[thread overview]
Message-ID: <4F11E1CE.2050008@lwfinger.net> (raw)
In-Reply-To: <4F11DEB8.7010708@broadcom.com>

On 01/14/2012 01:59 PM, Arend van Spriel wrote:
> On 01/14/2012 07:20 PM, Larry Finger wrote:
>> On 01/14/2012 11:58 AM, John W. Linville wrote:
>>> Kay, thanks for the reports.  Drivers should definitely be loading
>>> firmware at IFF_UP time.
>>
>> As the maintainer for several drivers with this problem, I need to make some
>> changes. What call from mac80211 corresponds to IFF_UP?
>
> Hi, Larry
>
> The mac80211 start callback describes following:
>
>   * @start: Called before the first netdevice attached to the hardware
>   *	is enabled. This should turn on the hardware and must turn on
>   *	frame reception (for possibly enabled monitor interfaces.)
>   *	Returns negative error codes, these may be seen in userspace,
>   *	or zero.
>   *	When the device is started it should not have a MAC address
>   *	to avoid acknowledging frames before a non-monitor device
>   *	is added.
>   *	Must be implemented and can sleep.
>
> Seems to me a good place to do the firmware loading although it is not
> really IFF_UP.
>
>> I have looked into using asynchronous firmware loading, but I have not yet found
>> a good implementation.
>>
>> Larry
>
> In brcmsmac we request the firmware in the probe function so not in
> module_init, but I guess upon driver registration in the module_init the
> probe is called.

Thanks.

The rtlwifi drivers also load the firmware in the probe function, but do so 
synchronously, which is where they get in trouble with the new udev.

I'm planning on converting to asynchronous firmware loading with a check in the 
start routine.

Larry


WARNING: multiple messages have this Message-ID (diff)
From: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
To: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Cc: "John W. Linville"
	<linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
	Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>,
	"netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Tom Gundersen <teg-B22kvLQNl6c@public.gmane.org>,
	Andy Whitcroft <apw-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Subject: Re: calling request_firmware() from module init will not work with recent/future udev versions
Date: Sat, 14 Jan 2012 14:13:02 -0600	[thread overview]
Message-ID: <4F11E1CE.2050008@lwfinger.net> (raw)
In-Reply-To: <4F11DEB8.7010708-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>

On 01/14/2012 01:59 PM, Arend van Spriel wrote:
> On 01/14/2012 07:20 PM, Larry Finger wrote:
>> On 01/14/2012 11:58 AM, John W. Linville wrote:
>>> Kay, thanks for the reports.  Drivers should definitely be loading
>>> firmware at IFF_UP time.
>>
>> As the maintainer for several drivers with this problem, I need to make some
>> changes. What call from mac80211 corresponds to IFF_UP?
>
> Hi, Larry
>
> The mac80211 start callback describes following:
>
>   * @start: Called before the first netdevice attached to the hardware
>   *	is enabled. This should turn on the hardware and must turn on
>   *	frame reception (for possibly enabled monitor interfaces.)
>   *	Returns negative error codes, these may be seen in userspace,
>   *	or zero.
>   *	When the device is started it should not have a MAC address
>   *	to avoid acknowledging frames before a non-monitor device
>   *	is added.
>   *	Must be implemented and can sleep.
>
> Seems to me a good place to do the firmware loading although it is not
> really IFF_UP.
>
>> I have looked into using asynchronous firmware loading, but I have not yet found
>> a good implementation.
>>
>> Larry
>
> In brcmsmac we request the firmware in the probe function so not in
> module_init, but I guess upon driver registration in the module_init the
> probe is called.

Thanks.

The rtlwifi drivers also load the firmware in the probe function, but do so 
synchronously, which is where they get in trouble with the new udev.

I'm planning on converting to asynchronous firmware loading with a check in the 
start routine.

Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-01-14 20:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-14 15:25 calling request_firmware() from module init will not work with recent/future udev versions Kay Sievers
2012-01-14 17:58 ` John W. Linville
2012-01-14 18:20   ` Larry Finger
2012-01-14 19:59     ` Arend van Spriel
2012-01-14 19:59       ` Arend van Spriel
2012-01-14 20:13       ` Larry Finger [this message]
2012-01-14 20:13         ` Larry Finger
2012-01-14 20:15         ` Emmanuel Grumbach
2012-01-14 20:15           ` Emmanuel Grumbach
2012-01-14 18:45 ` Larry Finger
2012-01-14 19:26   ` Tom Gundersen
2012-01-15 10:02 ` Johannes Berg
2012-01-15 15:33   ` Kay Sievers
2012-01-15 15:33     ` Kay Sievers
2012-01-16  8:57     ` Johannes Berg
2012-01-16 12:05       ` Kay Sievers
2012-01-16 12:16         ` Johannes Berg
2012-07-19 10:46           ` Kay Sievers
2012-07-24 14:16             ` Johannes Berg
2012-07-24 14:32               ` Tom Gundersen
2012-07-24 17:50                 ` Kay Sievers
2012-02-16 12:04       ` Arend van Spriel
2012-02-16 12:04         ` Arend van Spriel
2012-02-16 12:38         ` Johannes Berg
2012-02-16 13:09           ` Arend van Spriel
2012-02-16 13:09             ` Arend van Spriel
2012-02-16 14:39             ` Johannes Berg
2012-02-16 14:39               ` Johannes Berg
2012-02-20 17:43 ` Arend van Spriel
2012-02-20 17:43   ` Arend van Spriel

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=4F11E1CE.2050008@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=apw@canonical.com \
    --cc=arend@broadcom.com \
    --cc=johannes@sipsolutions.net \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=teg@jklm.no \
    /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.