[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1474748954.23838.21.camel@perches.com>
Date: Sat, 24 Sep 2016 13:29:14 -0700
From: Joe Perches <joe@...ches.com>
To: Larry Finger <Larry.Finger@...inger.net>,
Jean Delvare <jdelvare@...e.de>,
Jes Sorensen <Jes.Sorensen@...hat.com>
Cc: Chaoming Li <chaoming_li@...lsil.com.cn>,
Kalle Valo <kvalo@...eaurora.org>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] realtek: Add switch variable to 'switch case not
processed' messages
On Sat, 2016-09-24 at 14:06 -0500, Larry Finger wrote:
> On 09/24/2016 12:32 PM, Joe Perches wrote:
[]
> o Reindent all the switch/case blocks to a more normal
> kernel style (git diff -w would show no changes here)
> That sounds like busy work to me, but if you want to do it, go ahead.
It's really just to make the comparison case block reductions
easier to verify for later steps done
> > o cast, spacing and parenthesis reductions
> > Lots of odd and somewhat unique styles in various
> > drivers, looks like too many individual authors without
> > a style guide / code enforcer using slightly different
> > personalized code. Glancing at the code, it looks to be
> > similar logic, just written in different styles.
> Same comment.
Same rationale
> > o Logic changes like
> > from:
> > if (foo) func(..., bar, ...); else func(..., baz, ...);
> > to:
> > func(..., foo ? bar : baz, ...);
> > to make the case statement code blocks more consistent
> > and emit somewhat smaller object code.
> I find if .. else constructs much easier to read than the cond ? xxxx : yyyy
> form. I would reject any such patches.
<shrug> I think object code reduction generally a good thing
but then again, I'm not a maintainer here.
> > o Consolidation of equivalent function spanning drivers
> > With the style only changes minimized, where possible
> > make the drivers use common ops/callback functions.
> The is no question that there are similar routines in different drivers. I would
> like to place as much as possible into common routines, but I never seem to find
> the time. There are too many bugs in other things I support to consider these
> niceties.
Consolidation generally reduces defects and improves ease of
updating.
>
Powered by blists - more mailing lists