Skip to contentSkip to conversation

Staging: batman-adv: fixed comments to maintain 80 char limit

PATCH In review Mark 4 participants 5 messages Apr 27, 2010 – Apr 28, 2010 Staging

lore
Share & tools
lore

Mark

author
#0 lore raw

PATCH 1/1 Staging: batman-adv: fixed comments to maintain 80 char limit

This patches types.h to make sure the comments adhere to the 80 char limit and make checkpatch.pl happy

Signed-off-by Mark Rankilor <[email protected]>
---
 drivers/staging/batman-adv/types.h |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)
drivers/staging/batman-adv/types.h +11 -6
index dec1b54..7d4768a 100644
@@ -46,7 +46,7 @@ struct batman_if {
 
 };
 
-struct orig_node {               /* structure for orig_list maintaining nodes of mesh */
+struct orig_node { /* structure for orig_list maintaining nodes of mesh */
 	uint8_t orig[ETH_ALEN];
 	struct neigh_node *router;
 	struct batman_if *batman_if;

@@ -54,15 +54,18 @@ struct orig_node {               /* structure for orig_list maintaining nodes of
 	uint8_t *bcast_own_sum;
 	uint8_t tq_own;
 	int tq_asym_penalty;
-	unsigned long last_valid;        /* when last packet from this node was received */
-/*	uint8_t  gwflags;      * flags related to gateway functions: gateway class */
+	unsigned long last_valid; /* when last packet from this node was
+				   * received */
+/*	uint8_t  gwflags;  * flags related to gateway functions:
+			   * gateway class */
 	uint8_t  flags;    		/* for now only VIS_SERVER flag. */
 	unsigned char *hna_buff;
 	int16_t  hna_buff_len;
 	uint16_t last_real_seqno;   /* last and best known squence number */
 	uint8_t last_ttl;         /* ttl of last received packet */
 	TYPE_OF_WORD bcast_bits[NUM_WORDS];
-	uint16_t last_bcast_seqno;  /* last broadcast sequence number received by this host */
+	uint16_t last_bcast_seqno;  /* last broadcast sequence number received
+				     * by this host */
 	struct list_head neigh_list;
 };
 

@@ -74,7 +77,8 @@ struct neigh_node {
 	uint8_t tq_index;
 	uint8_t tq_avg;
 	uint8_t last_ttl;
-	unsigned long last_valid;            /* when last packet via this neighbor was received */
+	unsigned long last_valid; /* when last packet via this neighbor was
+				   * received */
 	TYPE_OF_WORD real_bits[NUM_WORDS];
 	struct orig_node *orig_node;
 	struct batman_if *if_incoming;

@@ -108,7 +112,8 @@ struct hna_global_entry {
 	struct orig_node *orig_node;
 };
 
-struct forw_packet {               /* structure for forw_list maintaining packets to be send/forwarded */
+struct forw_packet { /* structure for forw_list maintaining packets to be
+		      * send/forwarded */
 	struct hlist_node list;
 	unsigned long send_time;
 	uint8_t own;
Signature · 1 line
1.7.0.5
author
#2 lore raw
Quoted 2 lines · Sven Eckelmann

Your patch doesn't apply anymore. See [email protected] and follow ups [1].

I had a look at the follow ups and saw this one:

https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-April/002483.html

So would it be best if I were to submit patches against the linux-next tree? Or is it necessary to work against the batman maint or master trees?

I'd much prefer if I could work against linux-next since if I wanted to do some work on another staging driver, then I wouldn't have to go and check out their repository.

Regards,
Mark

#3 lore raw
Quoted 8 lines · Mark Rankilor
Quoted 2 lines · Sven Eckelmann

Your patch doesn't apply anymore. See [email protected] and follow ups [1].

I had a look at the follow ups and saw this one:

https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-April/002483.html

Quoted 7 lines

So would it be best if I were to submit patches against the linux-next tree? Or is it necessary to work against the batman maint or master trees?

I'd much prefer if I could work against linux-next since if I wanted to do some work on another staging driver, then I wouldn't have to go and check out their repository.

Please work against linux-next, it is up to the batman developers to also work against linux-next as well. That levels the playing field for everyone involved.

thanks,

greg k-h

#4 lore raw
In reply to Mark Rankilor
Quoted 10 lines · Mark Rankilor
Quoted 2 lines · Sven Eckelmann

Your patch doesn't apply anymore. See [email protected] and follow ups [1].

I had a look at the follow ups and saw this one:

https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-April/002483.html

So would it be best if I were to submit patches against the linux-next tree?

Hi Mark

I agree with Greg here. Patches against linux-next are no problem.

I'm responsible for merging changes in linux-next back into the batman repo.

Having said that, before deciding to work on something, it probably is worth looking at the batman repo. There is no point you reproducing work we have already done, but is just queued up waiting to be sent to Greg, or is in Gregs backlog of patches to apply.

Basically, i would not bother doing plain checkpatch patches. We are mostly on top of that and any in linux-next are probably already fixed in the batman repo.

However if you want to do some work with more meat on it, look for security problems, memory leaks, race conditions, lockdep etc, such patches would greatly be appreciated, independent of which repo they are against.

Andrew