linux-kernel - Re: bcm43xx regression in 2.6.24 (with patch)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200802270012.04335.mb@bu3sch.de>
Date:	Wed, 27 Feb 2008 00:12:03 +0100
From:	Michael Buesch <mb@...sch.de>
To:	"John W. Linville" <linville@...driver.com>
Cc:	Alexey Zaytsev <alexey.zaytsev@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Alexey Zaytsev <zaytsev.a@...tei.ru>, Greg KH <greg@...ah.com>,
	linux-kernel@...r.kernel.org
Subject: Re: bcm43xx regression in 2.6.24 (with patch)

On Tuesday 26 February 2008 23:47:57 John W. Linville wrote:
> On Wed, Feb 27, 2008 at 01:12:32AM +0300, Alexey Zaytsev wrote:
> > On Wed, Feb 27, 2008 at 1:04 AM, Michael Buesch <mb@...sch.de> wrote:
> 
> > >  Besides that the bcm43xx driver is not broken. That's the whole reason
> > >  this damn thread started at all. So it can't be broken.
> > >
> > Can't agree here. The bcm43xx driver used to work with 2.6.23 without requiring
> > any module magic.
> 
> At the risk of prolonging things... :-(
> 
> Isn't the fundamental problem here that the ssb driver claims the same
> PCI IDs as the bcm43xx driver?  He have hit this same issue a number
> of times: 8139too vs.  8139cp, eepro vs. e100, sk98lin vs. skge,
> and I'm sure there are more.  I admit that this situation is a bit
> more confusing, since the user is less likely to predict a conflict
> between bcm43xx and the ssb driver.  This is especially true since
> the user isn't even selecting ssb directly, but is instead selecting
> the apparently unrelated b44.
> 
> Still, the bcm43xx driver is not fundamentally damaged.  This is
> fundamentally a "two drivers claiming the same PCI ID" issue, not a
> "you broke my driver" one.

You got the point exactly right John. :)
The special "problem" about this is that the b44 driver, which _seems_
to have nothing to do with b43, registers the b43 PCI IDs.
(This is just for convenience. See the comment in the header of
b43_pci_bridge.c for details).
So if you use the b44 driver, but also want to use the bcm43xx driver,
you have to load the bcm43xx driver first to make it probe before
b44 registers the b43 PCI IDs.

The bcm43xx driver is not broken _at_ _all_. In fact, its code did not
even slightly change since ages.

I do see the issue, but I don't feel like changing the complicated SSB
KConfig stuff (it has lots of weird dependencies) to fix this bug
that is actually trivial to work around. Besides that, how many people
do we have, which do have a b44 card plus a bcm4311 rev 1 (there are _LOTS_
of revisions of the 43xx hardware)?

So I'd rather fix b43 to work on the card. See the patch I just sent.

-- 
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/