All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Roberto Medina <robertoxmed@gmail.com>, gregkh@linuxfoundation.org
Cc: josh@joshtripplet.org, ebru.akagunduz@gmail.com,
	aaro.koskinen@iki.fi, ebiederm@xmission.com,
	devel@driverdev.osuosl.org, linux-next@vger.kernel.org
Subject: Re: [PATCH] Staging: octeon: ethernet-tx: fixed coding style warnings, missing blank lines
Date: Wed, 8 Oct 2014 14:46:16 -0400	[thread overview]
Message-ID: <54358678.8050307@windriver.com> (raw)
In-Reply-To: <1412790687-15731-1-git-send-email-robertoxmed@gmail.com>

On 14-10-08 01:51 PM, Roberto Medina wrote:
> From: Roberto Medina <robertoxmed@gmail.com>
> 
> Fixed coding style warnings due to missing blank lines.

Seems some dubious additions -- annotated below....

> 
> Signed-off-by: Roberto Medina <robertoxmed@gmail.com>
> 
> ---
>  drivers/staging/octeon/ethernet-tx.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/staging/octeon/ethernet-tx.c b/drivers/staging/octeon/ethernet-tx.c
> index 4e54d85..f2a41f0 100644
> --- a/drivers/staging/octeon/ethernet-tx.c
> +++ b/drivers/staging/octeon/ethernet-tx.c
> @@ -77,6 +77,7 @@ static DECLARE_TASKLET(cvm_oct_tx_cleanup_tasklet, cvm_oct_tx_do_cleanup, 0);
>  static inline int32_t cvm_oct_adjust_skb_to_free(int32_t skb_to_free, int fau)
>  {
>  	int32_t undo;
> +
>  	undo = skb_to_free > 0 ? MAX_SKB_TO_FREE : skb_to_free +
>  						   MAX_SKB_TO_FREE;
>  	if (undo > 0)
> @@ -89,6 +90,7 @@ static inline int32_t cvm_oct_adjust_skb_to_free(int32_t skb_to_free, int fau)
>  static void cvm_oct_kick_tx_poll_watchdog(void)
>  {
>  	union cvmx_ciu_timx ciu_timx;
> +
>  	ciu_timx.u64 = 0;
>  	ciu_timx.s.one_shot = 1;
>  	ciu_timx.s.len = cvm_oct_tx_poll_interval;
> @@ -118,9 +120,11 @@ static void cvm_oct_free_tx_skbs(struct net_device *dev)
>  		total_freed += skb_to_free;
>  		if (skb_to_free > 0) {
>  			struct sk_buff *to_free_list = NULL;
> +
>  			spin_lock_irqsave(&priv->tx_free_list[qos].lock, flags);
>  			while (skb_to_free > 0) {
>  				struct sk_buff *t;
> +
>  				t = __skb_dequeue(&priv->tx_free_list[qos]);
>  				t->next = to_free_list;
>  				to_free_list = t;
> @@ -131,6 +135,7 @@ static void cvm_oct_free_tx_skbs(struct net_device *dev)
>  			/* Do the actual freeing outside of the lock. */
>  			while (to_free_list) {
>  				struct sk_buff *t = to_free_list;
> +
>  				to_free_list = to_free_list->next;
>  				dev_kfree_skb_any(t);
>  			}
> @@ -256,8 +261,10 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device *dev)
>  			/* We only need to pad packet in half duplex mode */
>  			gmx_prt_cfg.u64 =
>  			    cvmx_read_csr(CVMX_GMXX_PRTX_CFG(index, interface));
> +

Why would checkpatch want a newline here?

>  			if (gmx_prt_cfg.s.duplex == 0) {
>  				int add_bytes = 64 - skb->len;
> +
>  				if ((skb_tail_pointer(skb) + add_bytes) <=
>  				    skb_end_pointer(skb))
>  					memset(__skb_put(skb, add_bytes), 0,
> @@ -287,8 +294,10 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device *dev)
>  		hw_buffer.s.pool = 0;
>  		hw_buffer.s.size = skb_headlen(skb);
>  		CVM_OCT_SKB_CB(skb)[0] = hw_buffer.u64;
> +

...or here?

>  		for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>  			struct skb_frag_struct *fs = skb_shinfo(skb)->frags + i;
> +
>  			hw_buffer.s.addr = XKPHYS_TO_PHYS(
>  				(u64)(page_address(fs->page.p) +
>  				fs->page_offset));
> @@ -495,6 +504,7 @@ skip_xmit:
>  
>  	while (skb_to_free > 0) {
>  		struct sk_buff *t = __skb_dequeue(&priv->tx_free_list[qos]);
> +
>  		t->next = to_free_list;
>  		to_free_list = t;
>  		skb_to_free--;
> @@ -505,6 +515,7 @@ skip_xmit:
>  	/* Do the actual freeing outside of the lock. */
>  	while (to_free_list) {
>  		struct sk_buff *t = to_free_list;
> +
>  		to_free_list = to_free_list->next;
>  		dev_kfree_skb_any(t);
>  	}
> @@ -550,6 +561,7 @@ int cvm_oct_xmit_pow(struct sk_buff *skb, struct net_device *dev)
>  
>  	/* Get a work queue entry */
>  	cvmx_wqe_t *work = cvmx_fpa_alloc(CVMX_FPA_WQE_POOL);
> +

...or here?  Seems broken if you ask me.

P.
--

>  	if (unlikely(work == NULL)) {
>  		printk_ratelimited("%s: Failed to allocate a work queue entry\n",
>  				   dev->name);
> @@ -713,6 +725,7 @@ static void cvm_oct_tx_do_cleanup(unsigned long arg)
>  	for (port = 0; port < TOTAL_NUMBER_OF_PORTS; port++) {
>  		if (cvm_oct_device[port]) {
>  			struct net_device *dev = cvm_oct_device[port];
> +
>  			cvm_oct_free_tx_skbs(dev);
>  		}
>  	}
> 

      reply	other threads:[~2014-10-08 18:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08 17:51 [PATCH] Staging: octeon: ethernet-tx: fixed coding style warnings, missing blank lines Roberto Medina
2014-10-08 18:46 ` Paul Gortmaker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54358678.8050307@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=devel@driverdev.osuosl.org \
    --cc=ebiederm@xmission.com \
    --cc=ebru.akagunduz@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=josh@joshtripplet.org \
    --cc=linux-next@vger.kernel.org \
    --cc=robertoxmed@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.