From: "Rafał Miłecki" <zajec5@gmail.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Greg KH <greg@kroah.com>, Franky Lin <frankyl@broadcom.com>,
gregkh@suse.de, devel@linuxdriverproject.org,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH 00/20] staging: brcm80211: 7th reaction for mainline patch #2
Date: Tue, 20 Sep 2011 15:45:19 +0200 [thread overview]
Message-ID: <CACna6rxujsije__xcsy_w1pDCwttTDW9pT6YiUKDPhKyk22opA@mail.gmail.com> (raw)
In-Reply-To: <20110920133628.GC7800@tuxdriver.com>
2011/9/20 John W. Linville <linville@tuxdriver.com>:
> On Tue, Sep 20, 2011 at 03:21:14PM +0200, Johannes Berg wrote:
>
>> 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.
>
> It would be nice to see some of this. I don't think anything is
> stopping either Broadcom _or_ the b43 team from posting such patches.
>
>> 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.
>
> I'm inclined to agree. Despite recent heroic efforts, b43 remains
> behind in it's support for current features of Broadcom hardware.
> As developers find other gainful interests, that gap is sure to widen
> -- it certainly was quite wide just a few months ago.
And brcmsmac stays behind b43 if you count feature different than
performance. Monitor, RFKILL, Ad-hoc, AP, hw crypt, supported PHYs,
etc.
And what if Broadcom decides to abound their brcm80211 project?
I vote for working together, I can not see a better solution.
> As Johannes implies, it seems likely that newer Broadcom hardware will
> need to be supported by a different/new driver anyway. Is there
> some reason why that new driver needs to have a b43 pedigree?
> If we want/expect Broadcom to support that new driver, is it so
> unreasonable to allow them to start from the codebase they prefer?
> I don't think it is.
We still don't have any clue, when is that going to happen.
> Broadcom has come a long way in the wireless arena. I think we would
> be better served by bringing them into the fold than by continuing
> to demand what they don't feel able to provide.
That's why I asked so many times already to discuss future with them.
--
Rafał
next prev parent reply other threads:[~2011-09-20 13:45 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-19 21:25 [PATCH 00/20] staging: brcm80211: 7th reaction for mainline patch #2 Franky Lin
2011-09-19 21:25 ` [PATCH 01/20] staging: brcm80211: sparse endianness warnings on dongle events Franky Lin
2011-09-19 21:25 ` [PATCH 02/20] staging: brcm80211: various fulmac sparse endianness fixes Franky Lin
2011-09-19 21:25 ` [PATCH 03/20] staging: brcm80211: sparse endianness warnings for struct brcmf_proto_cdc_ioctl Franky Lin
2011-09-19 21:25 ` [PATCH 04/20] staging: brcm80211: sparse endianness warnings for struct sdpcm_shared Franky Lin
2011-09-19 21:25 ` [PATCH 05/20] staging: brcm80211: more fullmac sparse endianness scan related changes Franky Lin
2011-09-19 21:25 ` [PATCH 06/20] staging: brcm80211: remove unconditional code blocks from brcmfmac Franky Lin
2011-09-19 21:25 ` [PATCH 07/20] staging: brcm80211: remove event handler thread from fullmac Franky Lin
2011-09-19 21:25 ` [PATCH 08/20] staging: brcm80211: remove fullmac module_param brcmf_dongle_memsize Franky Lin
2011-09-19 21:25 ` [PATCH 09/20] staging: brcm80211: remove fullmac module_param brcmf_sdiod_drive_strength Franky Lin
2011-09-19 21:25 ` [PATCH 10/20] staging: brcm80211: remove fullmac module_param for watchdog Franky Lin
2011-09-19 21:25 ` [PATCH 11/20] staging: brcm80211: remove fullmac module_param brcmf_idletime Franky Lin
2011-09-19 21:26 ` [PATCH 12/20] staging: brcm80211: remove global variables for data frame boundary Franky Lin
2011-09-19 21:26 ` [PATCH 13/20] staging: brcm80211: removed two fullmac sparse spinlock warnings Franky Lin
2011-09-19 21:26 ` [PATCH 14/20] staging: brcm80211: added endianness check flag to fullmac Makefile Franky Lin
2011-09-19 21:26 ` [PATCH 15/20] staging: brcm80211: removed likely/unlikely calls Franky Lin
2011-09-19 21:26 ` [PATCH 16/20] staging: brcm80211: removed log after kzalloc()/kmalloc() failure Franky Lin
2011-09-19 21:26 ` [PATCH 17/20] staging: brcm80211: clarified fullmac io and event codes Franky Lin
2011-09-19 21:26 ` [PATCH 18/20] staging: brcm80211: consistent naming of struct net_device *ndev Franky Lin
2011-09-19 21:26 ` [PATCH 19/20] staging: brcm80211: simplified internal ioctl function once more Franky Lin
2011-09-19 21:26 ` [PATCH 20/20] staging: brcm80211: reduced checkpatch warnings to zero Franky Lin
2011-09-20 0:04 ` Joe Perches
2011-09-20 0:59 ` Joe Perches
2011-09-20 1:12 ` Franky Lin
2011-09-20 1:04 ` Franky Lin
2011-09-20 13:03 ` [PATCH 00/20] staging: brcm80211: 7th reaction for mainline patch #2 Greg KH
2011-09-20 13:21 ` Johannes Berg
2011-09-20 13:36 ` John W. Linville
2011-09-20 13:45 ` Rafał Miłecki [this message]
2011-09-20 13:40 ` Rafał Miłecki
2011-09-20 13:50 ` Rafał Miłecki
2011-09-20 20:56 ` Rafał Miłecki
2011-09-20 21:12 ` Alex Deucher
2011-09-20 21:23 ` Rafał Miłecki
2011-09-21 23:26 ` Luis R. Rodriguez
2011-09-21 13:40 ` John W. Linville
2011-09-21 13:52 ` Rafał Miłecki
2011-09-21 13:55 ` Rafał Miłecki
2011-09-21 14:39 ` Larry Finger
2011-09-20 13:22 ` John W. Linville
2011-09-20 14:00 ` Greg KH
2011-09-21 18:33 ` Brett Rudley
2011-09-21 20:01 ` Rafał Miłecki
2011-09-21 22:12 ` Brett Rudley
2011-09-21 22:35 ` Michael Büsch
2011-09-21 23:15 ` Brett Rudley
2011-09-21 23:28 ` Michael Büsch
2011-09-22 2:07 ` Brett Rudley
2011-09-22 6:36 ` Rafał Miłecki
2011-09-22 8:53 ` Arend Van Spriel
2011-09-22 8:57 ` Rafał Miłecki
2011-09-22 9:10 ` Arend Van Spriel
2011-09-22 9:12 ` Rafał Miłecki
2011-09-22 10:07 ` Jonas Gorski
2011-09-22 13:39 ` Arend Van Spriel
2011-09-22 9:44 ` Johannes Berg
2011-09-22 10:29 ` Michael Büsch
2011-09-22 6:47 ` Hauke Mehrtens
2011-09-22 9:04 ` Arend Van Spriel
2011-09-22 9:08 ` Rafał Miłecki
2011-09-22 10:38 ` Michael Büsch
2011-09-22 6:54 ` Rafał Miłecki
2011-09-22 7:24 ` Rafał Miłecki
2011-09-22 7:28 ` Rafał Miłecki
2011-09-22 14:31 ` Christoph Hellwig
2011-09-22 18:37 ` Arend Van Spriel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACna6rxujsije__xcsy_w1pDCwttTDW9pT6YiUKDPhKyk22opA@mail.gmail.com \
--to=zajec5@gmail.com \
--cc=devel@linuxdriverproject.org \
--cc=frankyl@broadcom.com \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.