From: Larry Finger <larry.finger@lwfinger.net>
To: Stefano Brivio <stefano.brivio@polimi.it>
Cc: "John W. Linville" <linville@tuxdriver.com>,
Michael Buesch <mb@bu3sch.de>,
Broadcom Linux <bcm43xx-dev@lists.berlios.de>,
wireless <linux-wireless@vger.kernel.org>
Subject: Re: bcm4301: A mac80211 driver using V3 firmware
Date: Thu, 19 Jul 2007 20:38:17 -0500 [thread overview]
Message-ID: <46A01209.4030200@lwfinger.net> (raw)
In-Reply-To: <20070720012714.0dc0298a@morte>
Stefano Brivio wrote:
> On Thu, 19 Jul 2007 17:58:01 -0400
> "John W. Linville" <linville@tuxdriver.com> wrote:
>
>> Are you proposing to add a third driver and deprecate the softmac
>> driver? Or can we treat this as a port of the existing driver
>> to mac80211? I think that might be better for users and distros,
>> and might let us get rid of the softmac component that much sooner.
>
> I agree. Let's treat this as a port, as soon as it's stable. By the way, I
> hope I'll be able to contribute again starting on July, 25.
For the initial tests, it will be a third driver called bcm4301; however, it is a port and should be
presented as such.
>> As for the name, if we treat this as a port of the current driver to
>> mac80211 then perhaps we should just continue using the "bcm43xx" name?
>> If so, we need a new name for the v4-based driver -- "bcm43xxtoo"? :-)
>
> Should the ported driver support 802.11g devices as well, it should be
> called bcm43xx, IMHO. Else, IIRC, we already discussed that and it should
> be called bcm4301. bcm43xx-mac80211 could be renamed to "bcm43xx-v4", it
> would be more meaningful than "bcm43xtoo", maybe.
>
>> Regarding hardware support, I have begun to lean towards having
>> the v3 driver continue to support all the hardware it does now.
>
> I agree. But I would wait a little more time, I mean, when the ported driver
> is stable, then let's consider the status of "bcm43xx-v4". Michael is
> actually making some progress, even if - sadly - he's alone right now.
I wish I could be of more help, but I've gotten all that I can from the specs.
> The final plan should be something like this:
> 1) bcm43xx gets stable and merged;
> 2) bcm43xx-mac80211 is renamed to bcm43xx-v4 and doesn't get merged;
> 3) when bcm43xx-v4 gets stable, the PCI IDs list of bcm43xx gets stripped
> down and it is renamed to bcm4301, while bcm43xx-v4 is renamed to bcm43xx.
>
> This could lead to some troubles. The other possible plan:
> 1) bcm43xx-mac80211 gets stable and merged, while bcm43xx is renamed to
> bcm4301 and its PCI IDs list stripped down;
> would sound a lot simpler. Even if the first plan could be better for users
> and distributions. So I'd say, let's have a stable driver at least, before
> to take a decision.
>
>> What exactly do we gain from using the v4 firmware?
>
> Other than crypto hardware, support for 802.11n devices, and maybe 802.11a
> devices too (I started working on that but I'm not doing that right now).
>
>> Anyway, I'm glad to hear we are making progress on this front.
>> Good job, Larry!
>
> Me too! Good job!
Thanks guys for your comments and compliments.
My preferred plan is as follows:
1. For more general testing, I'll distribute my driver as a patch to be applied to wireless-dev as
it needs ssb, which is not yet in mainline. If we are still in testing when ssb is merged, I'll
change to making patches against mainline.
2. Once the problems have been cleared and ssb is in -mm, it gets sent there as a port from softmac
to mac80211 for the current bcm43xx. An additional consideration is that a port from softmac to
mac80211 will be more easily merged than if it looks like a new driver.
3. If the port of softmac to mac80211 is merged before Michael's driver, it will be known as bcm43xx
with bcm43xx-mac80211 remaining in wireless-dev.
4. Once bcm43xx-mac80211 gets merged to mainline, then Michael's driver should become bcm43xx and my
driver gets its PCI IDs stripped to the 802.11b-only devices and once again becomes bcm4301. This
name change for Michael's driver would cause some disruption for current users as their firmware
would have the wrong name/version. That might be too much of a problem.
I think this is a path that always has a stable driver with at least moderate performance in
mainline throughout the entire transformation. When either driver gets merged, that will be one more
nail in softmac's coffin!
Larry
next prev parent reply other threads:[~2007-07-20 1:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-12 14:34 bcm4301: A mac80211 driver using V3 firmware Larry Finger
2007-07-19 21:58 ` John W. Linville
2007-07-19 22:26 ` Johannes Berg
2007-07-19 23:27 ` Stefano Brivio
2007-07-20 1:38 ` Larry Finger [this message]
2007-07-20 3:09 ` Stefano Brivio
2007-07-20 4:43 ` Pavel Roskin
2007-07-20 12:12 ` David Woodhouse
2007-07-20 13:44 ` John W. Linville
2007-07-20 16:05 ` Pavel Roskin
2007-07-20 16:33 ` Ehud Gavron
2007-07-20 17:57 ` Pavel Roskin
2007-07-20 18:05 ` John W. Linville
2007-07-20 20:41 ` Larry Finger
2007-07-21 12:50 ` Michael Buesch
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=46A01209.4030200@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=bcm43xx-dev@lists.berlios.de \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mb@bu3sch.de \
--cc=stefano.brivio@polimi.it \
/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;
as well as URLs for NNTP newsgroup(s).