On Mon, 2011-08-29 at 21:28 -0700, Greg KH wrote: > > We understand the level of effort that it's taken for b43 to get as far as it > > has, and was implemented without access to proprietary information, and it has > > been impossible to support advanced chip features. We appreciate the difficulty > > of your task and respect your accomplishments tremendously! > > Then why not try to help out here? > > All other wireless companies have realized that this is the best way > forward over time. Remember, b43 was here first, you need to play nice > with those developers. Well, truth be told, b43 was there first for older chipsets, and I played a major role in it existing back then. For the latest generation chips that are supported by the staging driver, that driver was there earlier and reverse engineering was ongoing even though code existed and could have been used. That code may not have been as clean, but the algorithms etc. are probably more tweaked & tuned to the chips. > You really need to work with the b43 developers here. I definitely agree with this. However, given the architectural differences in the device/ucode combination, I don't think support can be added to b43 easily. > Why can't you just do the small changes needed to the b43 driver to add > the missing functionality based on the fact that you know how the > hardware works? I don't think it would be small changes. Let me explain. What we can hope for is sharing of PHY/Radio code between b43 and brcmsmac. I'm sure this can be done in some way -- the PHY/Radio code should be taken from Broadcom's driver most likely, the code in b43 isn't maintained by anyone with access to Si documentation & testing. Some form of abstraction layer exists in both drivers, but they're obviously not compatible at this point -- I believe this could be solved. However, on a higher level (MAC level) I believe that the drivers are quite different. There are a bunch of MAC features like multi-MAC support and probably soon P2P that b43 cannot support across the board due to the version of the uCode it is tied to, especially on older devices where such uCode never existed. New features, like P2P, will likely only be supported by new uCode on new devices -- I don't see Broadcom backporting & testing their new uCode, in most cases it probably won't even be possible due to device restrictions (*). As a result, I believe that attempting to share the MAC level code between b43 and brcmsmac will lead to a maintenance disaster, b43 would essentially be fragmented into lots of little code paths that depend on the uCode API in use. I don't think that's worth it -- we split b43/b43legacy for precisely that reason before. I'm not saying we should merge brcmsmac as is, but I do think attempting to push everything into b43 is bound to lead to lots of issues that we all don't want to see. Code sharing should be possible on some level, but at other levels it is fairly likely that code sharing would just lead to bigger problems down the road. johannes (*) keep in mind that older devices only support 4k ucode instructions and very little memory! _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
