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

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

[Mark]

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 <reodge@gmail.com>
---
 drivers/staging/batman-adv/types.h |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/batman-adv/types.h b/drivers/staging/batman-adv/types.h
index dec1b54..7d4768a 100644
--- a/drivers/staging/batman-adv/types.h
+++ b/drivers/staging/batman-adv/types.h
@@ -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;
-- 
1.7.0.5

Re: [PATCH] Staging: batman-adv: fixed comments to maintain 80 char limit

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 340 bytes --]

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

Your patch doesn't apply anymore. See
1270341625-28764-1-git-send-email-luisbg@ubuntu.com and follow ups [1].

Best regards,
	Sven Eckelmann

[1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-April/002476.html

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] Staging: batman-adv: fixed comments to maintain 80 char limit

[Mark Rankilor]

On 27 April 2010 17:53, Sven Eckelmann <sven.eckelmann@gmx.de> wrote:
> Your patch doesn't apply anymore. See
> 1270341625-28764-1-git-send-email-luisbg@ubuntu.com 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

Re: [PATCH] Staging: batman-adv: fixed comments to maintain 80 char limit

[Greg KH]

On Wed, Apr 28, 2010 at 09:33:40PM +0800, Mark Rankilor wrote:
> On 27 April 2010 17:53, Sven Eckelmann <sven.eckelmann@gmx.de> wrote:
> > Your patch doesn't apply anymore. See
> > 1270341625-28764-1-git-send-email-luisbg@ubuntu.com 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.

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

Re: [PATCH] Staging: batman-adv: fixed comments to maintain 80 char limit

[Andrew Lunn]

On Wed, Apr 28, 2010 at 09:33:40PM +0800, Mark Rankilor wrote:
> On 27 April 2010 17:53, Sven Eckelmann <sven.eckelmann@gmx.de> wrote:
> > Your patch doesn't apply anymore. See
> > 1270341625-28764-1-git-send-email-luisbg@ubuntu.com 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