Re: bcm4301: A mac80211 driver using V3 firmware
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. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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. Renaming a driver always creates madness. For example, even now people and projects (e.g. Kismet) refer to madwifi-ng, but there is no madwifi-ng anymore, because this beast has been renamed to madwifi. If possible, use names that can stay. Peoples grey cells, projects, and webpages don't then suffer from bitrott. 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. A gread, even more renames :-( ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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 [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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. smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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 [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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 signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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 [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
On Thu, 19 Jul 2007 17:58:01 -0400 John W. Linville [EMAIL PROTECTED] 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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
Stefano Brivio wrote: On Thu, 19 Jul 2007 17:58:01 -0400 John W. Linville [EMAIL PROTECTED] 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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
On Thu, 19 Jul 2007 20:38:17 -0500 Larry Finger [EMAIL PROTECTED] 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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
bcm4301: A mac80211 driver using V3 firmware
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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
