Return-path: Received: from mail-iy0-f174.google.com ([209.85.210.174]:60434 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755431Ab2BMXvN (ORCPT ); Mon, 13 Feb 2012 18:51:13 -0500 Received: by mail-iy0-f174.google.com with SMTP id b35so5196388iac.19 for ; Mon, 13 Feb 2012 15:51:13 -0800 (PST) Message-ID: <4F39A1E9.7070702@lwfinger.net> (sfid-20120214_005117_327575_89442836) Date: Mon, 13 Feb 2012 17:51:05 -0600 From: Larry Finger MIME-Version: 1.0 To: Julian Calaby 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 References: <1329161826-11135-1-git-send-email-Larry.Finger@lwfinger.net> <1329161826-11135-3-git-send-email-Larry.Finger@lwfinger.net> <4F399C96.3090701@lwfinger.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 02/13/2012 05:41 PM, Julian Calaby wrote: > Hi Larry, > > On Tue, Feb 14, 2012 at 10:28, Larry Finger wrote: >> On 02/13/2012 05:06 PM, Julian Calaby wrote: >>> >>> Hi Larry, >>> >>> On Tue, Feb 14, 2012 at 06:37, Larry Finger >>> 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 >>>> --- >>>> 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