[PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[Larry Finger]

A coding error present since b43legacy was incorporated into the
kernel has prevented the driver from using the rate-setting mechanism
of mac80211. The driver has been forced to remain at a 1 Mb/s rate.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@kernel.org>		[2.6.26], [2.6.25]
---

John,

This is a bug, not a regression. I guess under the new rules that it
is 2.6.28 material.

Thanks,

Larry
---

Index: wireless-testing/drivers/net/wireless/b43legacy/xmit.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43legacy/xmit.c
+++ wireless-testing/drivers/net/wireless/b43legacy/xmit.c
@@ -624,7 +624,7 @@ void b43legacy_handle_hwtxstatus(struct
 	tmp = hw->count;
 	status.frame_count = (tmp >> 4);
 	status.rts_count = (tmp & 0x0F);
-	tmp = hw->flags;
+	tmp = hw->flags << 1;
 	status.supp_reason = ((tmp & 0x1C) >> 2);
 	status.pm_indicated = !!(tmp & 0x80);
 	status.intermediate = !!(tmp & 0x40);

Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[Michael Buesch]

On Saturday 06 September 2008 23:51:22 Larry Finger wrote:
> A coding error present since b43legacy was incorporated into the
> kernel has prevented the driver from using the rate-setting mechanism
> of mac80211. The driver has been forced to remain at a 1 Mb/s rate.
> 
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@kernel.org>		[2.6.26], [2.6.25]

Reviewed-by: Michael Buesch <mb@bu3sch.de>

> ---
> 
> John,
> 
> This is a bug, not a regression. I guess under the new rules that it
> is 2.6.28 material.

I wonder what the -stable rules are.
It seems really screwed to me to avoid applying the fix to 2.6.27,
but still apply it to 2.6.25/26-stable.

I'd like to see this patch in .25, .26 and .27, however I'm not sure
what the rules are.

For reference:
Three people agree on the correctness of the patch, it's a oneliner
and it's tested to fix the bug. However it is not a regression. The
bug is in there since day-0 of b43legacy. But this fix improves
TX rates a lot.

> Index: wireless-testing/drivers/net/wireless/b43legacy/xmit.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/b43legacy/xmit.c
> +++ wireless-testing/drivers/net/wireless/b43legacy/xmit.c
> @@ -624,7 +624,7 @@ void b43legacy_handle_hwtxstatus(struct
>  	tmp = hw->count;
>  	status.frame_count = (tmp >> 4);
>  	status.rts_count = (tmp & 0x0F);
> -	tmp = hw->flags;
> +	tmp = hw->flags << 1;
>  	status.supp_reason = ((tmp & 0x1C) >> 2);
>  	status.pm_indicated = !!(tmp & 0x80);
>  	status.intermediate = !!(tmp & 0x40);

-- 
Greetings Michael.

Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[Greg KH]

On Sun, Sep 07, 2008 at 12:40:04AM +0200, Michael Buesch wrote:
> On Saturday 06 September 2008 23:51:22 Larry Finger wrote:
> > A coding error present since b43legacy was incorporated into the
> > kernel has prevented the driver from using the rate-setting mechanism
> > of mac80211. The driver has been forced to remain at a 1 Mb/s rate.
> > 
> > Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> > Cc: Stable <stable@kernel.org>		[2.6.26], [2.6.25]
> 
> Reviewed-by: Michael Buesch <mb@bu3sch.de>
> 
> > ---
> > 
> > John,
> > 
> > This is a bug, not a regression. I guess under the new rules that it
> > is 2.6.28 material.
> 
> I wonder what the -stable rules are.

Bug fixes, not new features, it's pretty simple :)

> It seems really screwed to me to avoid applying the fix to 2.6.27,
> but still apply it to 2.6.25/26-stable.

I have to wait until it is in upstream before adding it to the -stable
tree, so this will not happen.

> I'd like to see this patch in .25, .26 and .27, however I'm not sure
> what the rules are.
> 
> For reference:
> Three people agree on the correctness of the patch, it's a oneliner
> and it's tested to fix the bug. However it is not a regression. The
> bug is in there since day-0 of b43legacy. But this fix improves
> TX rates a lot.

If it goes into .27, please forward it on to stable@kernel.org so we can
include it in older releases.

thanks,

greg k-h

Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[Michael Buesch]

On Monday 08 September 2008 07:31:55 Greg KH wrote:
> On Sun, Sep 07, 2008 at 12:40:04AM +0200, Michael Buesch wrote:
> > On Saturday 06 September 2008 23:51:22 Larry Finger wrote:
> > > A coding error present since b43legacy was incorporated into the
> > > kernel has prevented the driver from using the rate-setting mechanism
> > > of mac80211. The driver has been forced to remain at a 1 Mb/s rate.
> > > 
> > > Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> > > Cc: Stable <stable@kernel.org>		[2.6.26], [2.6.25]
> > 
> > Reviewed-by: Michael Buesch <mb@bu3sch.de>
> > 
> > > ---
> > > 
> > > John,
> > > 
> > > This is a bug, not a regression. I guess under the new rules that it
> > > is 2.6.28 material.
> > 
> > I wonder what the -stable rules are.
> 
> Bug fixes, not new features, it's pretty simple :)

Yeah, well. My concern was:
- We put it into .25-stable and .26-stable, because it's a bugfix.
  That's perfectly fine.
- We do _not_ put it into .27 mainline, because it is just a simple
  bug, but not a regression. Instead we wait for .27-stable.

Doesn't make a lot sense to me. :)

So I'd like to see it in .27, too, despite the strict regressions-only
rule. A general regressions-only rule simply doesn't always make sense, IMO.

-- 
Greetings Michael.

Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[Larry Finger]

Greg KH wrote:
> 
> Bug fixes, not new features, it's pretty simple :)

Just bug fixes, or does it have to be a regression?

Larry

Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[John W. Linville]

On Mon, Sep 08, 2008 at 11:22:43AM -0500, Larry Finger wrote:
> Greg KH wrote:
>>
>> Bug fixes, not new features, it's pretty simple :)
>
> Just bug fixes, or does it have to be a regression?

As I understand it, the rule is more like "bug fixes that are committed
in the linux-2.6 tree".  Since Linus has become more strict about
requiring "regressions only" after the merge window, that effectively
enforces the "regressions only" rule on the -stable trees as well.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[Greg KH]

On Mon, Sep 08, 2008 at 11:22:43AM -0500, Larry Finger wrote:
> Greg KH wrote:
>> Bug fixes, not new features, it's pretty simple :)
>
> Just bug fixes, or does it have to be a regression?

See the detailed rules in Documentation/stable_kernel_rules.txt

thanks,

greg k-h

Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[Otto Solares]

On Mon, Sep 08, 2008 at 04:54:59PM -0400, John W. Linville wrote:
> On Mon, Sep 08, 2008 at 11:22:43AM -0500, Larry Finger wrote:
> > Greg KH wrote:
> >>
> >> Bug fixes, not new features, it's pretty simple :)
> >
> > Just bug fixes, or does it have to be a regression?
> 
> As I understand it, the rule is more like "bug fixes that are committed
> in the linux-2.6 tree".  Since Linus has become more strict about
> requiring "regressions only" after the merge window, that effectively
> enforces the "regressions only" rule on the -stable trees as well.

In this case that rule is harming, is not idiotic to not accept bug
fixes early or later?

-otto

Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism

[John W. Linville]

On Wed, Sep 10, 2008 at 12:40:44AM -0600, Otto Solares wrote:
> On Mon, Sep 08, 2008 at 04:54:59PM -0400, John W. Linville wrote:
> > On Mon, Sep 08, 2008 at 11:22:43AM -0500, Larry Finger wrote:
> > > Greg KH wrote:
> > >>
> > >> Bug fixes, not new features, it's pretty simple :)
> > >
> > > Just bug fixes, or does it have to be a regression?
> > 
> > As I understand it, the rule is more like "bug fixes that are committed
> > in the linux-2.6 tree".  Since Linus has become more strict about
> > requiring "regressions only" after the merge window, that effectively
> > enforces the "regressions only" rule on the -stable trees as well.
> 
> In this case that rule is harming, is not idiotic to not accept bug
> fixes early or later?

I'm just the messenger...FWIW the argument is that even a "fix"
can introduce a new "bug" somewhere else, often quite unexpectedly.

John
-- 
John W. Linville
linville@tuxdriver.com