Re: [PATCH] b43: Fix QoS defaults
Hi everybody, I worked with the QoS parameters trying to understand why, checking them within the firmware, they don't seems to have the correct values even if they were set correctly by the driver. I think that there could be an error in the b43.h file: /* SHM offsets to the QOS data structures for the 4 different queues. */ #define B43_QOS_PARAMS(queue) (B43_SHM_SH_EDCFQ + \ (B43_NR_QOSPARAMS * sizeof(u16) * (queue))) #define B43_QOS_BACKGROUND B43_QOS_PARAMS(0) #define B43_QOS_BESTEFFORT B43_QOS_PARAMS(1) #define B43_QOS_VIDEO B43_QOS_PARAMS(2) #define B43_QOS_VOICE B43_QOS_PARAMS(3) /* QOS parameter hardware data structure offsets. */ #define B43_NR_QOSPARAMS22 Each EDCF parameters set take up 32 byte (in the firmware the offset between 2 EDCFQ is 0x010 that is equivalent to 0x020 if the offset was expressed in byte). This means that the B43_NR_QOSPARAMS must be set to 16. With the value equal to 16 I can access correctly the aifs, cwcur, cwmax, etc within the firmware. What do you think about that? regards. Lorenzo. ___ 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
