Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
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 [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
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 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
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 [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
Greg KH wrote: > > Bug fixes, not new features, it's pretty simple :) Just bug fixes, or does it have to be a regression? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
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 <[EMAIL PROTECTED]> > > > Cc: Stable <[EMAIL PROTECTED]>[2.6.26], [2.6.25] > > > > Reviewed-by: Michael Buesch <[EMAIL PROTECTED]> > > > > > --- > > > > > > 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. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
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 <[EMAIL PROTECTED]> > Cc: Stable <[EMAIL PROTECTED]>[2.6.26], [2.6.25] Reviewed-by: Michael Buesch <[EMAIL PROTECTED]> > --- > > 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. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
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 <[EMAIL PROTECTED]> Cc: Stable <[EMAIL PROTECTED]> [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); ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
