[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120301.221643.881299898523907213.davem@davemloft.net>
Date: Thu, 01 Mar 2012 22:16:43 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: gustavo@...ovan.org
Cc: johan.hedberg@...il.com, linville@...driver.com,
netdev@...r.kernel.org
Subject: Re: pull request: bluetooth-next 2012-03-01
From: Gustavo Padovan <gustavo@...ovan.org>
Date: Thu, 1 Mar 2012 23:55:55 -0300
> - I'm pulling directly to you because due to the coding style issues that
> happened some days ago. We decided, after talk to John, to pull directly to
> you, so you can take a look before pull. I personally looked to the whole
> diff of this pull request and couldn't spot anything that doesn't seem
> specified in CodingStyle.
For the members of "struct inquiry_cache" the tabbing has been all
messed up by commit 561aafbcb2e3f8fee11d3781f866c7b4c4f93a28.
Instead of all of the member names being nicely aligned using tabs it now
looks like (after all the commits it's now called "struct discovery_state"):
int type;
enum {
DISCOVERY_STOPPED,
DISCOVERY_STARTING,
DISCOVERY_FINDING,
DISCOVERY_RESOLVING,
DISCOVERY_STOPPING,
} state;
struct list_head all; /* All devices found during inquiry */
struct list_head unknown; /* Name state not known */
struct list_head resolve; /* Name needs to be resolved */
__u32 timestamp;
instead of something more reasonable like:
int type;
enum {
DISCOVERY_STOPPED,
DISCOVERY_STARTING,
DISCOVERY_FINDING,
DISCOVERY_RESOLVING,
DISCOVERY_STOPPING,
} state;
struct list_head all; /* All devices found during inquiry */
struct list_head unknown; /* Name state not known */
struct list_head resolve; /* Name needs to be resolved */
__u32 timestamp;
The person editing this had to go out of their way to make things like this
way.
This was only three commits into your tree, therefore I'm not very
optimistic to be honest with you.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists