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 20:34:41 -0700	[thread overview]
Message-ID: <AANLkTi=-JhwMmQK5ivX-FpSOV5_Pc3RfoswkFLFdGoFo@mail.gmail.com> (raw)
In-Reply-To: <c9d7238e26d9e276d9c9ef9792f7c7f8@localhost>

On Thu, Sep 9, 2010 at 1:58 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Thu, 9 Sep 2010 12:13:52 -0700, Steve deRosier <steve@cozybit.com>
>> 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?
>
> Certainly. I just wanted to point it out. This wasn't meant as
> a comment that should stop merging of these patches.
>
>> 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.
>
> Yeah, I tried to do it in libertas_tf at some point last year and
> failed miserably :-)
>
>> 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?
>
> Makes sense to me.
>

In light of the above, and Julian's comments, I'm going to rework the
libertas_tf patch set a little.  I'll make the following two changes:
1. Restrict building to module-only for now.  This avoids building it
into the kernel which we know will break.  Latter when I have time
I'll happily do what's necessary to make the fix Johannes wants, but
as it's not trivial I want to get a base down.
2. I'll change a few things around as Julian's advised so the patch
set makes a bit more sense. I'll be also killing some inadvertent
white-space changes that were mistakes.

I think my mac80211 patch "mac80211: Fix dangling pointer in
ieee80211_xmit" stands 100% alone and fixes a clear bug.  I don't see
any need to delay that one.

It might be a few days before I get these in.

Thanks,
- Steve

  reply	other threads:[~2010-09-10  3:34 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
2010-09-09 20:58       ` Johannes Berg
2010-09-10  3:34         ` Steve deRosier [this message]
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=-JhwMmQK5ivX-FpSOV5_Pc3RfoswkFLFdGoFo@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.