linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: Larry Finger <larry.finger@lwfinger.net>,
	wireless <linux-wireless@vger.kernel.org>,
	Michael Buesch <mb@bu3sch.de>,
	Stefano Brivio <stefano.brivio@polimi.it>,
	Broadcom Linux <bcm43xx-dev@lists.berlios.de>
Subject: Re: bcm4301: A mac80211 driver using V3 firmware
Date: Fri, 20 Jul 2007 12:05:21 -0400	[thread overview]
Message-ID: <1184947521.1962.15.camel@dv> (raw)
In-Reply-To: <20070720134425.GC7428@tuxdriver.com>

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


  reply	other threads:[~2007-07-20 16:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-12 14:34 bcm4301: A mac80211 driver using V3 firmware Larry Finger
2007-07-19 21:58 ` John W. Linville
2007-07-19 22:26   ` Johannes Berg
2007-07-19 23:27   ` Stefano Brivio
2007-07-20  1:38     ` Larry Finger
2007-07-20  3:09       ` Stefano Brivio
2007-07-20  4:43       ` Pavel Roskin
2007-07-20 12:12         ` David Woodhouse
2007-07-20 13:44         ` John W. Linville
2007-07-20 16:05           ` Pavel Roskin [this message]
2007-07-20 16:33             ` Ehud Gavron
2007-07-20 17:57               ` Pavel Roskin
2007-07-20 18:05                 ` John W. Linville
2007-07-20 20:41                   ` Larry Finger
2007-07-21 12:50                     ` Michael Buesch

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=1184947521.1962.15.camel@dv \
    --to=proski@gnu.org \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=larry.finger@lwfinger.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mb@bu3sch.de \
    --cc=stefano.brivio@polimi.it \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).