bcm4301: A mac80211 driver using V3 firmware

bcm4301: A mac80211 driver using V3 firmware

[Larry Finger]

John and Michael,

I have good news regarding the driver mentioned in the subject. It is now working on my BCM4311 with 
performance that is nearly as good as for the softmac driver.

My approach has been to take the PHY and radio parts of the softmac driver and use them with as much 
of the bcm43xx-mac80211 code as possible. It therefore uses the SSB driver as part of the front end.

My plan is to clean up the code, check it with my BCM4306 and BCM4318 devices, and then make it 
available as a patch against the mainline source for more general testing. At the same time, I will 
publish the results of my performance testing of all 3 models. Once it is shown to be reliable, a 
decision can be made regarding its inclusion in mainline and if it should support B and G devices, 
or be restricted to B-only devices. The A-PHY code has been stripped out.

Larry

Re: bcm4301: A mac80211 driver using V3 firmware

[John W. Linville]

On Thu, Jul 12, 2007 at 09:34:55AM -0500, Larry Finger wrote:

> My plan is to clean up the code, check it with my BCM4306 and BCM4318 
> devices, and then make it available as a patch against the mainline source 
> for more general testing. At the same time, I will publish the results of 
> my performance testing of all 3 models. Once it is shown to be reliable, a 
> decision can be made regarding its inclusion in mainline and if it should 
> support B and G devices, or be restricted to B-only devices. The A-PHY code 
> has been stripped out.

This sounds great.  Perhaps this can be the migration vehicle for
current bcm43xx users to come to mac80211?  Especially for those with
hardware not supported by the current bcm43xx-mac80211 driver.

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.

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"? :-)

Regarding hardware support, I have begun to lean towards having
the v3 driver continue to support all the hardware it does now.
I'm certainly prepared to hear the downside of that position. :-)
What exactly do we gain from using the v4 firmware?

Anyway, I'm glad to hear we are making progress on this front.
Good job, Larry!

John
-- 
John W. Linville
linville@tuxdriver.com

Re: bcm4301: A mac80211 driver using V3 firmware

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

On Thu, 2007-07-19 at 17:58 -0400, John W. Linville wrote:

> Regarding hardware support, I have begun to lean towards having
> the v3 driver continue to support all the hardware it does now.

I agree, until we can sort out the issues with that.

> What exactly do we gain from using the v4 firmware?

We get crypto hardware working, for example, and other things I might
not remember :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: bcm4301: A mac80211 driver using V3 firmware

[Stefano Brivio]

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.
 
> 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. 

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!


-- 
Ciao
Stefano

Re: bcm4301: A mac80211 driver using V3 firmware

[Larry Finger]

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

Re: bcm4301: A mac80211 driver using V3 firmware

[Stefano Brivio]

On Thu, 19 Jul 2007 20:38:17 -0500
Larry Finger <larry.finger@lwfinger.net> wrote:

> 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.

No, as long as we preserve the current firmware naming scheme. Some
distributions are already shipping both the softmac and the mac80211 based
drivers, with fwcutter installation scripts meant for dealing with this.
Some clear printk's in both drivers should do the rest.


-- 
Ciao
Stefano

Re: bcm4301: A mac80211 driver using V3 firmware

[Pavel Roskin]

Hello, Larry!

First of all, many thanks for porting the v3 driver to mac80211!

On Thu, 2007-07-19 at 20:38 -0500, Larry Finger wrote:

> 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.

Sounds good.

> 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.

I would prefer if the name stayed the same, but it shouldn't be a big
deal.

> 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.

Yes, that's what I mean, keep it "bcm43xx" unless renaming it is the
condition for acceptance.

> 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.

Actually, the common practice is that the new driver that doesn't
supplant the old driver immediately and for the whole range of hardware
gets a new name.  Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100.

Also, we could introduce a kernel option to enable support for new
devices in your driver.

> I think this is a path that always has a stable driver with at least moderate performance in 
> mainline throughout the entire transformation.

That's a very good goal.

I would also consider the option to use different names for v3 and v4
firmware.  I have a file /etc/modprobe.d/bcm43xx that reads

options bcm43xx fwpostfix=.3
options bcm43xx_mac80211 fwpostfix=.4

but we cannot expect every distro (let alone every user) to take care of
the naming conflict.  Users don't expect the need to rename firmware,
and we shouldn't create a problem for them.

-- 
Regards,
Pavel Roskin

Re: bcm4301: A mac80211 driver using V3 firmware

[David Woodhouse]

On Fri, 2007-07-20 at 00:43 -0400, Pavel Roskin wrote:
> 
> That's a very good goal.
> 
> I would also consider the option to use different names for v3 and v4
> firmware.  I have a file /etc/modprobe.d/bcm43xx that reads
> 
> options bcm43xx fwpostfix=.3
> options bcm43xx_mac80211 fwpostfix=.4
> 
> but we cannot expect every distro (let alone every user) to take care
> of the naming conflict.  Users don't expect the need to rename
> firmware, and we shouldn't create a problem for them.

Yes. Please use a suitable postfix for v3 and v4 firmware so that they
can coexist. You can always make each driver fall back to the old
filename if it doesn't find the firmware with the postfix.

We can make the fwcutter write out files with appropriate names too.

-- 
dwmw2

Re: bcm4301: A mac80211 driver using V3 firmware

[John W. Linville]

On Fri, Jul 20, 2007 at 12:43:16AM -0400, Pavel Roskin wrote:
> On Thu, 2007-07-19 at 20:38 -0500, Larry Finger wrote:

> > 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.
> 
> Actually, the common practice is that the new driver that doesn't
> supplant the old driver immediately and for the whole range of hardware
> gets a new name.  Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100.
 
Yes, this preserves stability for happy bcm43xx users.  Still taking
suggestions for the new name for bcm43xx-mac80211... :-)

> Also, we could introduce a kernel option to enable support for new
> devices in your driver.
 
Yes, this is probably worthwhile for those wishing to avoid PCI ID
conflicts between the drivers.  I have also been speculating that
perhaps we need an option for a secondary PCI ID table, so that a
driver could support a large range of PCI IDs but then gracefully
bow-out if another driver had a certain ID in its primary table.
Does that make any sense?  It would seem to be applicable to a number
of drivers in the kernel.

> I would also consider the option to use different names for v3 and v4
> firmware.  I have a file /etc/modprobe.d/bcm43xx that reads
> 
> options bcm43xx fwpostfix=.3
> options bcm43xx_mac80211 fwpostfix=.4
> 
> but we cannot expect every distro (let alone every user) to take care of
> the naming conflict.  Users don't expect the need to rename firmware,
> and we shouldn't create a problem for them.

Yes, we should probably start using a default value for fwpostfix.
As dwmw2 suggested, it would also be nice to fall back to an empty
fwpostfix if the firmware is not found w/ the default extension.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: bcm4301: A mac80211 driver using V3 firmware

[Pavel Roskin]

On Fri, 2007-07-20 at 09:44 -0400, John W. Linville wrote:
> On Fri, Jul 20, 2007 at 12:43:16AM -0400, Pavel Roskin wrote:
> > Actually, the common practice is that the new driver that doesn't
> > supplant the old driver immediately and for the whole range of hardware
> > gets a new name.  Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100.
>  
> Yes, this preserves stability for happy bcm43xx users.  Still taking
> suggestions for the new name for bcm43xx-mac80211... :-)

b43
bcm43
bcm4k3
bcmwifi
bcmwlan
bcm80211
brcm43xx
broadcom

I really like the minimalism of b43, which plays well with b44 and
p54 :)

> > Also, we could introduce a kernel option to enable support for new
> > devices in your driver.
>  
> Yes, this is probably worthwhile for those wishing to avoid PCI ID
> conflicts between the drivers.  I have also been speculating that
> perhaps we need an option for a secondary PCI ID table, so that a
> driver could support a large range of PCI IDs but then gracefully
> bow-out if another driver had a certain ID in its primary table.
> Does that make any sense?  It would seem to be applicable to a number
> of drivers in the kernel.

Yes, I used to hearing complains that orinoco steals IDs from hostap.
Then it became popular to blacklist orinoco modules.  Quite a disgrace
for the driver!  Having "weak" IDs for Prism based cards would have
avoided it.

But please realize that the problem goes far beyond PCI.  Perhaps you
have heard of CONFIG_USB_LIBUSUAL, which selects the best driver for USB
storage devices, either the slow but reliable ub, or the SCSI based
usb-storage, which it too fast for some cheap sticks.

It even has a parameter called "bias", which allows to control how
conservative the algorithm should be.  That would be hard to emulate
with "weak entries", but I hope that "bias" is an overkill.

> Yes, we should probably start using a default value for fwpostfix.
> As dwmw2 suggested, it would also be nice to fall back to an empty
> fwpostfix if the firmware is not found w/ the default extension.

Yes, that sounds good.

-- 
Regards,
Pavel Roskin

Re: bcm4301: A mac80211 driver using V3 firmware

[Ehud Gavron]

[-- Attachment #1: Type: text/plain, Size: 3968 bytes --]

Not a developer, just a tester, and not a very good one... but I am a 
_USER_ so here's my take.

The USERs don't want to know what card they have or what driver they 
need or PCI IDs.  That's all stuff that makes them say "Linux Bad, 
*****s good." (Yeah I know, there's the whole driver moreass there and 
PCI VENs too) but anyway...

The driver should have a name that reflects its use and capabilities.

For example, bcm43xx is a reasonable name.  I don't like it personally 
because the google links to the site (berlios.de) that tell me that's 
why I need took a while to find but that's just semantics.

bcm43xx_mac80211 is a less reasonable name.  With respect to the coders 
who have put time into making this usable on by 4306 and almost usable 
on my 4311 I can say that I appreciate the effort... but the name needs 
work.

If I was king of driver package naming, the driver that works with v3 
and v4 firmware and supports crypto functions would be... 
broadcom80211bg or bcm80211g
The driver that only works with v3 (aka bcm43xx) broadcomv3
The driver that only works with v4 (aka bcm43xx_mac80211) broadcomv4

As time advances and bcb43xx_mac80211/broadcomv4 is brought to spec so 
it works great... its code would be integrated into 
broadcom80211g/bcm80211g.

That's my thinking.  As a USER.  As a linux advocate and zealot.

I can tell you there are three things that are the #1 hindrance to 
massive Linux adoption
1. proprietary video cards
2. proprietary network cards
3. the various sundry and astonishingly in-the-way and annoying 
network-managers.

If you can solve #2... you've eliminated 33% of the problem and maybe 
even helped with #3.

Go Lewis Hamilton @ Nurbugring
Go Paul Tracy @ Edmonton

Ehud

Pavel Roskin wrote:
> On Fri, 2007-07-20 at 09:44 -0400, John W. Linville wrote:
>   
>> On Fri, Jul 20, 2007 at 12:43:16AM -0400, Pavel Roskin wrote:
>>     
>>> Actually, the common practice is that the new driver that doesn't
>>> supplant the old driver immediately and for the whole range of hardware
>>> gets a new name.  Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100.
>>>       
>>  
>> Yes, this preserves stability for happy bcm43xx users.  Still taking
>> suggestions for the new name for bcm43xx-mac80211... :-)
>>     
>
> b43
> bcm43
> bcm4k3
> bcmwifi
> bcmwlan
> bcm80211
> brcm43xx
> broadcom
>
> I really like the minimalism of b43, which plays well with b44 and
> p54 :)
>
>   
>>> Also, we could introduce a kernel option to enable support for new
>>> devices in your driver.
>>>       
>>  
>> Yes, this is probably worthwhile for those wishing to avoid PCI ID
>> conflicts between the drivers.  I have also been speculating that
>> perhaps we need an option for a secondary PCI ID table, so that a
>> driver could support a large range of PCI IDs but then gracefully
>> bow-out if another driver had a certain ID in its primary table.
>> Does that make any sense?  It would seem to be applicable to a number
>> of drivers in the kernel.
>>     
>
> Yes, I used to hearing complains that orinoco steals IDs from hostap.
> Then it became popular to blacklist orinoco modules.  Quite a disgrace
> for the driver!  Having "weak" IDs for Prism based cards would have
> avoided it.
>
> But please realize that the problem goes far beyond PCI.  Perhaps you
> have heard of CONFIG_USB_LIBUSUAL, which selects the best driver for USB
> storage devices, either the slow but reliable ub, or the SCSI based
> usb-storage, which it too fast for some cheap sticks.
>
> It even has a parameter called "bias", which allows to control how
> conservative the algorithm should be.  That would be hard to emulate
> with "weak entries", but I hope that "bias" is an overkill.
>
>   
>> Yes, we should probably start using a default value for fwpostfix.
>> As dwmw2 suggested, it would also be nice to fall back to an empty
>> fwpostfix if the firmware is not found w/ the default extension.
>>     
>
> Yes, that sounds good.
>
>   

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3283 bytes --]

Re: bcm4301: A mac80211 driver using V3 firmware

[Pavel Roskin]

Hello, Ehud!

On Fri, 2007-07-20 at 09:33 -0700, Ehud Gavron wrote:

> The USERs don't want to know what card they have or what driver they 
> need or PCI IDs.  That's all stuff that makes them say "Linux Bad, 
> *****s good." (Yeah I know, there's the whole driver moreass there and 
> PCI VENs too) but anyway...

Agreed.

> The driver should have a name that reflects its use and capabilities.

Not necessarily.  End users should be shielded from such details by
distributions.  Do you know the name of the Windows driver for your
network card?  Does it reflect "its use and capabilities"?

Now, if we are talking about power users, who can occasionally recompile
the kernel or install a program not from the distribution, they would be
helped by reasonable names of the drivers.

Also, distribution maintainers would feel better if the drivers are not
renamed, so that /etc/modprobe.d/ doesn't need to be scanned for the old
names on kernel upgrade.

> For example, bcm43xx is a reasonable name.  I don't like it personally 
> because the google links to the site (berlios.de) that tell me that's 
> why I need took a while to find but that's just semantics.

That's not a problem with the name.  If the first hit on Google was some
vomit inducing picture, then maybe.

> bcm43xx_mac80211 is a less reasonable name.  With respect to the coders 
> who have put time into making this usable on by 4306 and almost usable 
> on my 4311 I can say that I appreciate the effort... but the name needs 
> work.
> 
> If I was king of driver package naming, the driver that works with v3 
> and v4 firmware and supports crypto functions would be... 
> broadcom80211bg or bcm80211g
> The driver that only works with v3 (aka bcm43xx) broadcomv3
> The driver that only works with v4 (aka bcm43xx_mac80211) broadcomv4

You take just one aspect (firmware version) and put it into the name.
The original name was also taking just one aspect (802.11 stack).  I
fail to see why your approach it better.  I don't know any other Linux
(or _any_) driver that puts the firmware version into its name.

I believe you are implying that the firmware selection will be a
problem, so you prefer a name that would make it easy to solve that
problem.  But then you are not writing as a user, you are writing as
somebody who has been exposed to some internals.  Ask a random user if
the firmware version should be part of the driver name, and you'll get a
blank stare.

By the way, more information could be put into the module description,
which is shown by modinfo.

> As time advances and bcb43xx_mac80211/broadcomv4 is brought to spec so 
> it works great... its code would be integrated into 
> broadcom80211g/bcm80211g.

Now you put the name of the protocol into the driver, which is again
inconsistent with the existing naming and doesn't scale.  Suppose
802.11a support is fixed, would we need to rename the driver again?  And
that if the driver supports only 802.11b on some card?  Would not the
"80211g" part be misleading?

> That's my thinking.  As a USER.  As a linux advocate and zealot.

See above.  Users should not care about driver names.  If they do, we
have a bigger problem.

-- 
Regards,
Pavel Roskin

Re: bcm4301: A mac80211 driver using V3 firmware

[John W. Linville]

On Fri, Jul 20, 2007 at 01:57:48PM -0400, Pavel Roskin wrote:

> On Fri, 2007-07-20 at 09:33 -0700, Ehud Gavron wrote:

> > The driver should have a name that reflects its use and capabilities.
> 
> Not necessarily.  End users should be shielded from such details by
> distributions.  Do you know the name of the Windows driver for your
> network card?  Does it reflect "its use and capabilities"?
> 
> Now, if we are talking about power users, who can occasionally recompile
> the kernel or install a program not from the distribution, they would be
> helped by reasonable names of the drivers.
> 
> Also, distribution maintainers would feel better if the drivers are not
> renamed, so that /etc/modprobe.d/ doesn't need to be scanned for the old
> names on kernel upgrade.

ACK...fwiw, I like the "b43" name suggestion.  I wonder if that is
too prone to confusion w/ "b44"?  Probably no worse than "ixgb" vs
"cxgb3" or "e100" vs "e1000" I suppose.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: bcm4301: A mac80211 driver using V3 firmware

[Larry Finger]

John W. Linville wrote:
> 
> ACK...fwiw, I like the "b43" name suggestion.  I wonder if that is
> too prone to confusion w/ "b44"?  Probably no worse than "ixgb" vs
> "cxgb3" or "e100" vs "e1000" I suppose.

Today's discussion was very useful for me - I picked up two suggestions that I have or will be 
putting into the code.

1. The drivers that use V3 firmware will get a default fwpostfix value of ".fw3". If the resulting 
name fails, it will fallback to a blank value for fwpostfix. Of course, if a value is supplied, it 
will override the default.

2. Any b-only driver will contain an alternate PCI ID table that can be selected by using the 
appropriate module option (not yet named). If that option is selected, the driver will load a 
combined b/g table of ID's. This way, it will be easy to supply a work-around for any user that 
cannot get the default 802.11g driver to work. In addition, this fix will not require mucking with 
rc.local.

Larry

Re: bcm4301: A mac80211 driver using V3 firmware

[Michael Buesch]

On Friday 20 July 2007 22:41, Larry Finger wrote:
> John W. Linville wrote:
> > 
> > ACK...fwiw, I like the "b43" name suggestion.  I wonder if that is
> > too prone to confusion w/ "b44"?  Probably no worse than "ixgb" vs
> > "cxgb3" or "e100" vs "e1000" I suppose.
> 
> Today's discussion was very useful for me - I picked up two suggestions that I have or will be 
> putting into the code.
> 
> 1. The drivers that use V3 firmware will get a default fwpostfix value of ".fw3". If the resulting 
> name fails, it will fallback to a blank value for fwpostfix. Of course, if a value is supplied, it 
> will override the default.
> 
> 2. Any b-only driver will contain an alternate PCI ID table that can be selected by using the 
> appropriate module option (not yet named). If that option is selected, the driver will load a 
> combined b/g table of ID's. This way, it will be easy to supply a work-around for any user that 
> cannot get the default 802.11g driver to work. In addition, this fix will not require mucking with 
> rc.local.

No, don't go the way to make the PCI table selectable by a Kconfig
or even worse a dynamic module option.
That is _really_ confusing and I really hope everyone upstream
rejects such patches.
Either a driver does support some hardware, or it doesn't. There
is no step inbetween.
If bcm43xx-mac80211 for G is not ready for merge, yet, don't strip
the IDs from bcm43xx. If bcm43xx-mac80211 for G is ready for production,
remove them.