From: Larry Finger <Larry.Finger@lwfinger.net>
To: Julian Calaby <julian.calaby@gmail.com>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org, zajec5@gmail.com
Subject: Re: [RFC/RFT 2/5] b43: Load firmware from a work queue and not from the probe routine
Date: Mon, 13 Feb 2012 17:51:05 -0600 [thread overview]
Message-ID: <4F39A1E9.7070702@lwfinger.net> (raw)
In-Reply-To: <CAGRGNgV7c34ofqCy+9CDcXSz3o48KtUYsa+nr4cVb0inj8yLrA@mail.gmail.com>
On 02/13/2012 05:41 PM, Julian Calaby wrote:
> Hi Larry,
>
> On Tue, Feb 14, 2012 at 10:28, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>> On 02/13/2012 05:06 PM, Julian Calaby wrote:
>>>
>>> Hi Larry,
>>>
>>> On Tue, Feb 14, 2012 at 06:37, Larry Finger<Larry.Finger@lwfinger.net>
>>> wrote:
>>>>
>>>> Recent changes in udev are causing problems for drivers that load
>>>> firmware
>>>> from the probe routine. As b43 has such a structure, it must be changed.
>>>> As this driver loads more than 1 firmware file, changing to the
>>>> asynchronous routine
>>>> request_firmware_nowait() would be complicated. In this implementation,
>>>> the probe
>>>> routine starts a delayed_work queue that calls the firmware loading
>>>> routines when
>>>> the delay (1 sec) expires..
>>>>
>>>> Signed-off-by: Larry Finger<Larry.Finger@lwfinger.net>
>>>> ---
>>>> diff --git a/drivers/net/wireless/b43/b43.h
>>>> b/drivers/net/wireless/b43/b43.h
>>>> index 835462d..532ba79 100644
>>>> --- a/drivers/net/wireless/b43/b43.h
>>>> +++ b/drivers/net/wireless/b43/b43.h
>>>> @@ -932,6 +932,9 @@ struct b43_wl {
>>>> /* Flag that implement the queues stopping. */
>>>> bool tx_queue_stopped[B43_QOS_QUEUE_NUM];
>>>>
>>>> + /* delayed firmware loading */
>>>> + struct delayed_work firmware_load;
>>>> +
>>>> /* The device LEDs. */
>>>> struct b43_leds leds;
>>>>
>>>> diff --git a/drivers/net/wireless/b43/main.c
>>>> b/drivers/net/wireless/b43/main.c
>>>> index 1b540d2..903e1ea 100644
>>>> --- a/drivers/net/wireless/b43/main.c
>>>> +++ b/drivers/net/wireless/b43/main.c
>>>> @@ -2427,9 +2433,17 @@ static int b43_request_firmware(struct b43_wldev
>>>> *dev)
>>>> b43_print_fw_helptext(dev->wl, 1);
>>>> err = -ENOENT;
>>>
>>>
>>> Should something be done here rather than immediately going to
>>> register the card with ieee80211?
>>
>>
>> I don't think so. When firmware is loaded from the probe routine, it
>> registers the card as the next step. I did miss the step that registers the
>> leds - that has now been added.
>
> My point here is that in the original flow, the -ENOENT would have
> been returned to b43_chip_init() and the hardware would never have
> been registered with mac80211. After this patch, it appears that if
> the firmware cannot be found, it still registers the hardware with
> mac80211.
I see what you mean. The statement before the start_ieee80211 label should be
'goto out' rather than falling through.
Larry
next prev parent reply other threads:[~2012-02-13 23:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 19:37 [RFC/RFT 0/5] Firmware load change for various wireless drivers Larry Finger
2012-02-13 19:37 ` [RFC/RFT 1/5] b43legacy: Load firmware from work queue instead of from probe routine Larry Finger
2012-02-13 19:37 ` [RFC/RFT 2/5] b43: Load firmware from a work queue and not from the " Larry Finger
2012-02-13 23:06 ` Julian Calaby
2012-02-13 23:28 ` Larry Finger
2012-02-13 23:41 ` Julian Calaby
2012-02-13 23:51 ` Larry Finger [this message]
2012-02-13 19:37 ` [RFC/RFT 3/5] p54usb: Load firmware from work queue and not from " Larry Finger
2012-02-13 19:37 ` [PATCH 4/5] p54pci: " Larry Finger
2012-02-29 15:59 ` Larry Finger
2012-02-29 17:43 ` Christian Lamparter
2012-02-29 18:15 ` Larry Finger
2012-02-29 18:27 ` Christian Lamparter
2012-02-13 19:37 ` [RFC/RFT 5/5] p54spi: " Larry Finger
2012-02-13 21:57 ` Michael Büsch
2012-02-29 16:00 ` Larry Finger
2012-02-29 19:54 ` Max Filippov
2012-02-29 20:01 ` Larry Finger
2012-02-14 10:56 ` [RFC/RFT 0/5] Firmware load change for various wireless drivers Johannes Berg
2012-02-14 16:34 ` Larry Finger
2012-02-14 16:37 ` Johannes Berg
2012-02-14 16:57 ` Larry Finger
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=4F39A1E9.7070702@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=julian.calaby@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=zajec5@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.