Re: [PATCH] ath9k_hw: fix endian issues with CTLs on AR9003

["John W. Linville" <linville@tuxdriver.com>]

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@openwrt.org>
> >> 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.