Re: bcm43xx regression in 2.6.24 (with patch)

From: Michael Buesch
Date: Mon Feb 25 2008 - 05:39:23 EST


On Monday 25 February 2008 11:23:02 Alexey Zaytsev wrote:
> On Mon, Feb 25, 2008 at 9:49 AM, Greg KH <greg@xxxxxxxxx> wrote:
> >
> > On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote:
> > > Hi Michael,
> > >
> > > On Sun, 24 Feb 2008, Michael Buesch wrote:
> > > > > The ony way I see this was possible, you manually changed the
> > > > > module loading order, so that the b43xx module was loaded prior
> > > > > to the ssb and b44 modules. Right?
> > > >
> > > > Right. So "so I'm left with either no wifi or no ethenet" being wrong.
> > >
> > > Lets make this simple: it used to work before and now it doesn't.
> > > Therefore it's a regression that must be addressed. Period.
> >
> > Isn't the resolution Michael is suggesting is, "use the different driver"?
> >
>
> The b43 driver from 2.6.24 does not work with my hardware. The one from
> 2.6.25 seems to work, but 2.6.25 is far from being ready yet.
>
> The only way you can get the old driver working in 2.6.24 is to
> compile certain (completely unrelated for an outsider) drivers as
> modules and play with the module loading order. I think this is a
> bug, and it should be fixed in -stable.

It must first go into the 2.6.25 tree and then into -stable.
And the patch must be considered to do The Right Thing (tm).

> And for 2.6.25, I think the patch should also be included, as the
> bcm43xx driver is still there.
>
> Btw, what are we discussing? The real bcm43xx maintainer
> (Larry Finger) reviewed the patch and agreet it should go
> into 2.6.24-stable and 2.6.25 . Now we only have to wait for
> John Linville and Jeff Garzik to pick it up, right? If someone
> still thinks the patch should not go in, he should at least
> add them to the CC list. ;)

Heh, wait. Larry is neither the bcm43xx maintainer [1], nor does this
code touch bcm43xx code. It does touch ssb and b43 code, which I
am the maintainer of.
Though, as I said, if somebody else is familiar with the code does really
understand the patch and does ACK it (which Larry did), I'm probably
OK with applying it. As long as I'm not bothered with any followup
regressions caused by this. So if the one signing off the patch will
handle all this, I'm fine with it.

[1] bcm43xx is unmaintained. Larry used to be the maintainer until
he dropped it a few months ago.

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