From: Lennert Buytenhek <buytenh@wantstofly.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Dan Williams <dcbw@redhat.com>,
linux-wireless@vger.kernel.org,
"John W. Linville" <linville@tuxdriver.com>
Subject: Re: [PATCH] mwl8k: split driver by chipset
Date: Mon, 23 Nov 2009 12:29:16 +0100 [thread overview]
Message-ID: <20091123112916.GT20214@mail.wantstofly.org> (raw)
In-Reply-To: <1258974789.7094.162.camel@johannes.local>
On Mon, Nov 23, 2009 at 12:13:09PM +0100, Johannes Berg wrote:
> > I was wondering if we should really make the support for each chip a
> > different kernel module as you did in your patch, but then I figured
> > that this might be a good way to let the user choose whether to load
> > AP or STA firmware if we have both available, which was still one of
> > the unsolved problems. I.e., make mwl8366_ap and mwl8366_sta, and
> > then let the user choose which one to load. Or is there a better way
> > of doing this?
>
> Try to load both at probe() time (via the async firmware loading
> interface that I fixed up recently [1], that patch will be in .33), and
> hang on to the firmware images [2]. Register the wiphy with appropriate
> bits depending on which firmware files you found (and fail + unbind if
> you didn't find any, cf. my ar9170 patch [3]). Then you can upload the
> right firmware depending on the type of interface the user is adding.
This has the problem that e.g. if someone creates a STA interface first,
and we load the STA firmware image in response to that, and then creates
an additional AP interface, we'd have reload the chip while there's
still an active interface (the original STA one), which seems somewhat
involved. Just rejecting the second add_interface() seems undesirable,
as then the outcome of two add_interface() calls will depend on their
order.
(AP firmware supports both AP and STA interfaces, but e.g. it doesn't
do STA power save and such.)
It'll also have some consequences if there are monitor interfaces, as
e.g. STA firmware allows fine-grained control over the receive filter,
while the AP firmware does not.
next prev parent reply other threads:[~2009-11-23 11:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-22 23:05 [PATCH] mwl8k: split driver by chipset Dan Williams
2009-11-23 5:42 ` Julian Calaby
2009-11-23 11:02 ` Lennert Buytenhek
2009-11-23 11:13 ` Johannes Berg
2009-11-23 11:29 ` Lennert Buytenhek [this message]
2009-11-23 11:34 ` Johannes Berg
2009-11-26 3:25 ` Dan Williams
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=20091123112916.GT20214@mail.wantstofly.org \
--to=buytenh@wantstofly.org \
--cc=dcbw@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox