Return-path: Received: from charlotte.tuxdriver.com ([70.61.120.58]:58396 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751251Ab0K2TwY (ORCPT ); Mon, 29 Nov 2010 14:52:24 -0500 Date: Mon, 29 Nov 2010 14:50:38 -0500 From: "John W. Linville" To: Felix Fietkau Cc: linux-wireless@vger.kernel.org, lrodriguez@atheros.com Subject: Re: [PATCH] ath9k_hw: fix endian issues with CTLs on AR9003 Message-ID: <20101129195038.GD8199@tuxdriver.com> References: <1290279018-29716-1-git-send-email-nbd@openwrt.org> <20101122201511.GG2117@tuxdriver.com> <4CEAD7FA.1060107@openwrt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <4CEAD7FA.1060107@openwrt.org> Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 > >> Cc: stable@kernel.org > > > > 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@kernel.org", I would prefer to avoid (or strongly limit) merging such patches that way. 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? Thanks! John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready.