[PATCH 00/20] staging: brcm80211: 7th reaction for mainline patch #2

[Rafał Miłecki]

2011/9/20 Johannes Berg <johannes at sipsolutions.net>:
> 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ł