All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve deRosier <steve@cozybit.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com,
	javier@cozybit.com
Subject: Re: [PATCH 5/9] libertas_tf: Moved firmware loading to probe in order to fetch MAC address
Date: Thu, 9 Sep 2010 12:13:52 -0700	[thread overview]
Message-ID: <AANLkTi=r_RdEG-2=gzV7uFNJt1Nynp3qNC-38SQkzhO2@mail.gmail.com> (raw)
In-Reply-To: <e23a1b600a18f179fa72d2cadf724d17@localhost>

On Thu, Sep 9, 2010 at 9:38 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Wed,  8 Sep 2010 16:25:25 -0700, Steve deRosier <steve@cozybit.com>
> wrote:
>> mac80211 requires that the MAC address be known and set before calling
>> ieee80211_register_hw().  If this isn't done, we see bad MAC addresses
>> in our packet headers.  In order to make this happen, I had to
> restructure
>> to have if_sdio_probe load the firmware and get the hardware specs.
>>
>> I had to add a if_sdio_update_hw_spec function as if_sdio can't use the
>> standard
>> command as several required variables aren't setup yet.
>> if_sdio_update_hw_spec essentially uses polled io to get the hw spec
>> command response from the card.
>
> You should probably keep this for development purposes, but it will break
> if your code is built into the kernel. The working model we've adopted to
> solve this is to use request_firmware_nowait() in probe, and then only
> continue doing work when the firmware loading returns (and then register
> with mac80211 etc)
>

Johannes,

Before doing any of this stuff (back in patch 1), my driver goes
through and loads the firmware using the request_firmware() calls
anyway. In other words, I haven't changed that part.  Is the problem
specifically with my "get the MAC from the hardware before setting up
mac80211" change, or with waiting on firmware loading?

For fun, I just tried compiling the driver into the kernel.  Mixed
results: with two cards on the system, the first card found failed on
the call to request_firmware() with a -ENOENT, while the second card
came up just fine.  When done as modules, both work fine.  So there's
clearly something to what you're saying. Is it that the filesystem is
not up and available yet when we try to load the firmware for the
first card?

>From looking through the drivers, iwl and ar9170_usb are the only ones
to use the request_firmware_nowait().  I don't know if those are the
only mac80211 cards with firmware or not everyone's following the
model.

Do you have specific pointers of which code I should look at as a
model, or a better way to solve the problem?

In the short term, can we limit libertas_tf to build as module only
via Kconfig, and I can add the request_firmware_nowait() as a new
feature later with a new patch?  Looking at the examples, it looks
like the changes for this would be fairly involved and I would prefer
to break such a change out separately.  I'd like to get
libertas_tf_sdio accepted as a base so I can then do smaller change
sets going forward. Is that a reasonable plan or just plain silly?

BTW, thanks for pointing out this problem.  I hadn't tried this built
into the kernel and it never occurred to me that this would be an
issue.

Thanks,
- Steve

  reply	other threads:[~2010-09-09 19:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-08 23:25 [PATCH 0/9] libertas_tf: Add libertas_tf_sdio to libertas_tf Steve deRosier
2010-09-08 23:25 ` [PATCH 1/9] libertas_tf: Add a sdio driver " Steve deRosier
2010-09-08 23:25 ` [PATCH 2/9] libertas_tf: deb_defs.h: Fix include guard Steve deRosier
2010-09-08 23:25 ` [PATCH 3/9] libertas_tf: Added fullmac mode support so firmware supports libertas driver Steve deRosier
2010-09-08 23:25 ` [PATCH 4/9] libertas_tf: Add firmware reset to sdio driver and attempt firmware reload Steve deRosier
2010-09-09  1:44   ` Julian Calaby
2010-09-09  5:49     ` Steve deRosier
2010-09-08 23:25 ` [PATCH 5/9] libertas_tf: Moved firmware loading to probe in order to fetch MAC address Steve deRosier
2010-09-09  2:06   ` Julian Calaby
2010-09-09  5:49     ` Steve deRosier
2010-09-09  6:41       ` Julian Calaby
2010-09-09 16:38   ` Johannes Berg
2010-09-09 19:13     ` Steve deRosier [this message]
2010-09-09 20:58       ` Johannes Berg
2010-09-10  3:34         ` Steve deRosier
2010-09-10 16:12           ` Johannes Berg
2010-09-28 15:24           ` John W. Linville
2010-09-28 15:36             ` John W. Linville
2010-09-28 16:24             ` Steve deRosier
2010-09-08 23:25 ` [PATCH 6/9] libertas_tf: Fix to enable interrupts even when firmware has already started Steve deRosier
2010-09-09  2:07   ` Julian Calaby
2010-09-08 23:25 ` [PATCH 7/9] libertas_tf: Add tx feedback to libertas_tf_sdio Steve deRosier
2010-09-09  2:16   ` Julian Calaby
2010-09-09  5:49     ` Steve deRosier
2010-09-09  6:43       ` Julian Calaby
2010-09-08 23:25 ` [PATCH 8/9] libertas_tf: updated with beacon code Steve deRosier
2010-09-09  2:21   ` Julian Calaby
2010-09-09  5:53     ` Steve deRosier
2010-09-09  6:46       ` Julian Calaby
2010-09-08 23:25 ` [PATCH 9/9] libertas_tf: Allow tx up to full chip buffers Steve deRosier

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='AANLkTi=r_RdEG-2=gzV7uFNJt1Nynp3qNC-38SQkzhO2@mail.gmail.com' \
    --to=steve@cozybit.com \
    --cc=javier@cozybit.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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.