On Mon, Nov 29, 2010 at 11:50 AM, John W. Linville <linville@xxxxxxxxxxxxx> wrote: > On Mon, Nov 22, 2010 at 09:52:10PM +0100, Felix Fietkau wrote: >> On 2010-11-22 9:15 PM, John W. Linville wrote: >> > On Sat, Nov 20, 2010 at 07:50:18PM +0100, Felix Fietkau wrote: >> >> Parsing data using bitfields is messy, because it makes endian handling >> >> much harder. AR9002 and earlier got it right, AR9003 got it wrong. >> >> Fix it by getting rid of the CTL related bitfields entirely and use >> >> masks instead. >> >> >> >> Signed-off-by: Felix Fietkau <nbd@xxxxxxxxxxx> >> >> Cc: stable@xxxxxxxxxx >> > >> > Why does this merit stable consideration? >> It's a simple fix and I would like it to make it to stable releases, >> because this bug might possibly cause the tx power to be too high in >> some instances (when running on big-endian systems), violating >> regulatory limits. > > After being chided for having an excessive number of patches in -next > with "Cc: stable@xxxxxxxxxx", I would prefer to avoid (or strongly > limit) merging such patches that way. Is this a bad thing? > Patches intended for stable are supposed to be fixes. ÂFixes are > supposed to go to the current release, even if that means that patches > need to be refactored to separate real fixes from other bits. > > Now, what constitutes a fix is that part that can sometimes be subject > to debate. ÂFixes should be small and obvious if possible, and they > should address significant bug and/or a regression, and be documented > with bug reports, tested by users, etc. ÂThe later in the release, > the stricter we must adhere to such definitions. > > So...I guess what I am asking is if this is a fix, can you document > the effects of the bug? ÂCan you retarget the patch against 2.6.37? > > Otherwise, can we omit the Cc? I just wanted to point out that last thing I heard on this topic was I suggested I'd just take the patch and apply it to compat-wireless on the linux-next-pending/ directory if some of these sort of patches do not get merged as stable. After that Greg said he's be just happy taking them, so this is what pushed us to just go ahead and send these more grey-area fixes as stable fixes. Come to think of it we didn't get OTP patches in for 2.6.36 so I am not considering we should just disable AR9003 from the PCI ID list for ath9k as all cards sold should have it so in that case this patch would just need to go to 2.6.37 and not 2.6.36. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
