public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: joe@perches.com (Joe Perches)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] drivers: create a pinmux subsystem v2
Date: Tue, 10 May 2011 17:15:14 -0700	[thread overview]
Message-ID: <1305072914.19586.166.camel@Joe-Laptop> (raw)
In-Reply-To: <1305070783-23193-1-git-send-email-linus.walleij@linaro.org>

On Wed, 2011-05-11 at 01:39 +0200, Linus Walleij wrote:
> This creates a subsystem for handling of pinmux devices.
[]
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[]

Nice work and yes, more trivia...

> diff --git a/drivers/pinmux/core.c b/drivers/pinmux/core.c
[]
> +struct pin_desc {
> +	struct pinmux_dev *pmxdev;
> +	bool	requested;
> +	char	function[16];

Magic number 16 used here and a couple other places.

I also think function is a poor variable name for a descriptor.
Might ever this need the size increased or the use changed
to const char* func_desc (with kstrdup or equivalent)

> +	if (status) {
> +		pr_err("->request on device %s failed "
> +		       "for pin %d (offset %d)\n",

I think prefacing with "->" doesn't add anything and
I think it's better to ignore 80 column line lengths for
formats.  Maybe:

		pr_err("device %s: request for pin %d/offset %d failed\n",

> +	strncpy(desc->function, function, 16);
> +	desc->function[15] = '\0';

Here's that magic number again.  Maybe:
	strlcpy(desc->function, function, sizeof(desc->function));
or maybe:
	kstrdup(desc->func_name, function, GFP_KERNEL);

> +
> +out:
> +	spin_unlock_irqrestore(&pin_desc_lock, flags);
> +	if (status)
> +		pr_err("pin-%d (%s) status %d\n",
> +		       pin, function ? : "?", status);

Why test function for non-null only here?

> +int pinmux_register_mappings(struct pinmux_map const *maps, unsigned num_maps)

const struct pinmux_map *maps?
Normal kernel style uses const before struct.

> +void pinmux_put(struct pinmux *pmx)
[]
> +		pr_warn("pinmux: releasing pinmux with active users!\n");

I think you don't need the prefix anymore.

cheers, Joe

  parent reply	other threads:[~2011-05-11  0:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-10 23:39 [PATCH] drivers: create a pinmux subsystem v2 Linus Walleij
2011-05-10 23:58 ` Jamie Iles
2011-05-16  0:09   ` Linus Walleij
2011-05-16  9:36     ` Jamie Iles
2011-05-18  5:31       ` Linus Walleij
2011-05-11  0:15 ` Joe Perches [this message]
2011-05-13 21:29 ` Stephen Warren
2011-05-16  0:36   ` Linus Walleij
2011-05-17 21:48     ` Stephen Warren
2011-05-18  5:47       ` Linus Walleij
2011-05-19 17:42         ` Stephen Warren
2011-05-17 22:01 ` Stephen Warren
2011-05-18  5:56   ` Linus Walleij
2011-05-19 17:19     ` Stephen Warren
2011-05-19 17:38       ` Linus Walleij

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=1305072914.19586.166.camel@Joe-Laptop \
    --to=joe@perches.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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