2011/9/20 Johannes Berg <johannes@xxxxxxxxxxxxxxxx>: > On Tue, 2011-09-20 at 06:03 -0700, Greg KH wrote: > >> And while code is great and nice, I still haven't seen any real answers >> to all of the questions that were asked of the Broadcom driver team >> during that review by the linux-wireless developers about how things >> will be handled properly due to the overlap in functionality with the >> existing "real" driver in the tree. > > Let's qualify this to "some developers". > > One thing I'd like to point out is that the Broadcom's firmware API has > always undergone changes over time. I'm actually surprised that b43 > works as well as it does (which, tbh, isn't very well at all, at least > for me with some 11n PHY). I also don't think that Broadcom are going to > maintain compatibility and/or maintain new firmware features for old > devices, that just doesn't make any sense. It's hard to talk about API compatibility breakage, until it really happens. So far we support all firmwares, I don't have much more to say about that. We can decide about some driver splitting, when API breakage really happens. Now I think that are just thoeritical talks. > As a consequence, I don't think there's any sense in saying b43 should > be the driver that Broadcom must support upstream. Even we, back then, > split b43 into b43 and b43legacy when it wasn't really possible any more > to test and maintain a single driver for different devices. Rafal has > shown that it is possible today (to some extent) to do that for the > newer chips and the older 11g only chips that b43 still supports, but > I'm not convinced that with new features like P2P this will be true in > the future. That's what we try to discuss with Broadcom. If they really see a requirement to split driver into 2, they have to explain that and discuss it with us. I'm flexible, I've accepted Michaels' view on SSB & BCMA. We just need to make Broadcom talk with us. > And this is just discussing the technical side -- the support side is an > entirely different question. > > Now, don't get me wrong -- I don't think the duplication is a good > thing. A lot of the PHY code could be shared. However, I think it will > probably not be possible for much longer to share the higher level MAC > code that programs the SHM etc. > > So I don't claim to know what the solution is, but I think simply > rejecting the Broadcom effort like most people seem to imply is a good > solution at all. It will leave all of us in a bad spot by creating a > driver that has to support too many different devices. Having Broadcom ignoring all out questions and just sending more&more patches is not good as well. How differently we can make them talk? I've requested for discussion several times. -- Rafał _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
