Netdev List
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: "Sebastian Pöhn" <sebastian.belden@googlemail.com>
Cc: "Linux Netdev" <netdev@vger.kernel.org>,
	"Sebastian Pöhn" <sebastian.poehn@belden.com>
Subject: Re: [PATCH] gianfar v4: implement nfc
Date: Fri, 17 Jun 2011 08:33:41 -0700	[thread overview]
Message-ID: <1308324821.16582.31.camel@Joe-Laptop> (raw)
In-Reply-To: <1308304412.15482.8.camel@DENEC1DT0191>

On Fri, 2011-06-17 at 11:53 +0200, Sebastian Pöhn wrote:
> This patch adds all missing functionalities for nfc except GRXFH.

Just some trivial comments.

> diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
[]
> +static void gfar_swap(void *a, void *b, int size)
> +{
> +	u32 t1 = *(u32 *) a;
> +	u32 t2 = *(u32 *) (a + 4);
> +	u32 t3 = *(u32 *) (a + 8);
> +	u32 t4 = *(u32 *) (a + 12);
> +	*(u32 *) a = *(u32 *) b;
> +	*(u32 *) (a + 4) = *(u32 *) (b + 4);
> +	*(u32 *) (a + 8) = *(u32 *) (b + 8);
> +	*(u32 *) (a + 12) = *(u32 *) (b + 12);
> +	*(u32 *) b = t1;
> +	*(u32 *) (b + 4) = t2;
> +	*(u32 *) (b + 8) = t3;
> +	*(u32 *) (b + 12) = t4;
> +}

Doesn't this read better by casting a and b
to temporary pointers and using swap?

static void gfar_swap(void *a, void *b, int size)
{
	u32 *_a = a;
	u32 *_b = b;

	swap(_a[0], _b[0]);
	swap(_a[1], _b[1]);
	swap(_a[2], _b[2]);
	swap(_a[3], _b[3]);
}

[]

> +	mask_table = kzalloc(
> +			sizeof(struct gfar_mask_entry) * (MAX_FILER_CACHE_IDX
> +					/ 2 + 1), GFP_KERNEL);

	mask_table = kcalloc(MAX_FILER_CACHE_IDX / 2 + 1,
			     sizeof(struct gfar_mask_entry), GFP_KERNEL)

[]

> +			netdev_err(priv->ndev,
> +				"Adding this rule is not possible,"
> +				" because this flow-type is not supported"
> +				" by hardware!\n");

Could you review your logging messages for grammar
and spacing please.

For all these logging messages, you really should
ignore what is now an arbitrary 80 column limit and
not break the format string up on multiple lines.

It makes grep harder and when you write them, you don't
quite read them back to yourself normally.  You wouldn't
generally use a comma between possible and because.

			netdev_err(priv->ndev,
				   "Adding this rule is not possible because this flow-type is not supported by hardware!\n");

or maybe:

			netdev_err(priv->ndev,
				   "Rule not added.  Flow-type not supported by hardware!\n");

Maybe it should be:

	"Flow-type (%(some type)) not supported by hardware!\n",
	flow->some_type

> +				netdev_err(priv->ndev,
> +				"There is already an element on ID %d\n",
> +				flow->location);

I think it nicer to not align any function params
on indent level but where possible on open paren.

				netdev_err(priv->ndev,
					   "There is already an element on ID %d\n",
					   flow->location);

Aligning on indent level is confusing.
If you really need or want to to this, it's
better to change the indent level inwards
for extra long lines.

			netdev_err(priv->ndev,
"Adding this rule is not possible because this flow-type is not supported by hardware!\n");

That way you can see if the line is too long for
a message logging form and should be shortened
somehow.



      reply	other threads:[~2011-06-17 15:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-17  9:53 [PATCH] gianfar v4: implement nfc Sebastian Pöhn
2011-06-17 15:33 ` Joe Perches [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=1308324821.16582.31.camel@Joe-Laptop \
    --to=joe@perches.com \
    --cc=netdev@vger.kernel.org \
    --cc=sebastian.belden@googlemail.com \
    --cc=sebastian.poehn@belden.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox