From: joe@perches.com (Joe Perches)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] drivers: create a pinmux subsystem
Date: Mon, 02 May 2011 12:37:57 -0700 [thread overview]
Message-ID: <1304365077.7792.40.camel@Joe-Laptop> (raw)
In-Reply-To: <1304363786-30376-1-git-send-email-linus.walleij@stericsson.com>
On Mon, 2011-05-02 at 21:16 +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
> diff --git a/drivers/pinmux/core.c b/drivers/pinmux/core.c
Trivial comments follow
[]
> +static ssize_t pinmux_name_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct pinmux_dev *pmxdev = dev_get_drvdata(dev);
> +
> + return sprintf(buf, "%s\n", pmxdev_get_name(pmxdev));
> +}
Unsized buffer, maybe snprintf?
> +static int pin_request(int pin, const char *function, bool gpio)
> +{
> + struct pin_desc *desc;
> + struct pinmux_dev *pmxdev;
> + struct pinmux_ops *ops;
> + int status = -EINVAL;
> + unsigned long flags;
> +
> + pr_debug("pin_request: request pin %d for %s\n", pin, function);
pr_debug("%s: request pin...", __func__?
> + pr_err("pin_request: pin is invalid\n");
same here, etc...
> + if (!pmxdev) {
> + pr_warning("pin_warning: no pinmux device is handling %d!\n",
You use both pr_warning and pr_warn. Please just use pr_warn.
Why use "pin_warning: "?
Maybe it'd be better to add
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
or
#define pr_fmt(fmt) KBUILD_MODNAME ":%s: " fmt, __func__
if you really want __func__.
I suggest that __func__ isn't useful.
> + spin_unlock_irqrestore(&pin_desc_lock, flags);
> + if (status)
> + pr_err("pinmux pin_request: pin-%d (%s) status %d\n",
> + pin, function ? : "?", status);
"pinmux_pin_request: "?
> +static int pinmux_devices_show(struct seq_file *s, void *what)
> +{
> + struct pinmux_dev *pmxdev;
> +
> + seq_printf(s, "Available pinmux settings per pinmux device:\n");
> + list_for_each_entry(pmxdev, &pinmuxdev_list, node) {
> + struct pinmux_ops *ops = pmxdev->desc->ops;
const struct pinmux_ops?
> + unsigned selector = 0;
> +
> + seq_printf(s, "\nDevice %s:\n", pmxdev->desc->name);
I think the initial newline isn't necessary.
> + while (ops->list_functions(pmxdev, selector) >= 0) {
> + unsigned *pins;
> + unsigned num_pins;
> + const char *func = ops->get_function_name(pmxdev,
> + selector);
> + int ret;
> + int i;
> +
> + ret = ops->get_function_pins(pmxdev, selector,
> + &pins, &num_pins);
> +
> + if (ret)
> + seq_printf(s, "%s [ERROR GETTING PINS]\n",
> + func);
> +
> + else {
> + seq_printf(s, "function: %s, pins = [ ", func);
> + for (i = 0; i < num_pins; i++)
> + seq_printf(s, "%d ", pins[i]);
> + seq_printf(s, "]\n");
seq_printf used without additional arguments could be seq_puts
> + pr_warn("pinmux: failed to create debugfs directory\n");
[]
> + (void) debugfs_create_file("devices", S_IFREG | S_IRUGO,
> + debugfs_root, NULL, &pinmux_devices_ops);
> + (void) debugfs_create_file("maps", S_IFREG | S_IRUGO,
> + debugfs_root, NULL, &pinmux_maps_ops);
> + (void) debugfs_create_file("pins", S_IFREG | S_IRUGO,
> + debugfs_root, NULL, &pinmux_pins_ops);
Unnecessary casts to (void)?
> +static int __init pinmux_init(void)
> +{
> + int ret;
> +
> + ret = class_register(&pinmux_class);
> + pr_info("pinmux framwork: handle up to %d pins\n", MACH_NR_PINS);
framework?
> diff --git a/include/linux/pinmux.h b/include/linux/pinmux.h
[]
> +/*
> + * Valid pin numbers are nonnegative and < MACH_NR_PINS. Invalid numbers can
> + * be used to indicate no-such-pin.
> + */
> +static inline int pin_is_valid(int pin)
> +{
> + return ((unsigned)pin) < MACH_NR_PINS;
> +}
Couldn't pin just be declared unsigned or maybe u32?
next prev parent reply other threads:[~2011-05-02 19:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-02 19:16 [PATCH 1/4] drivers: create a pinmux subsystem Linus Walleij
2011-05-02 19:37 ` Joe Perches [this message]
2011-05-10 22:18 ` Linus Walleij
2011-05-10 22:37 ` Joe Perches
2011-05-10 22:52 ` Linus Walleij
2011-05-10 22:40 ` Mark Brown
2011-05-02 20:52 ` Stephen Warren
2011-05-02 21:30 ` Colin Cross
2011-05-04 9:22 ` Tony Lindgren
2011-05-07 19:06 ` Mike Rapoport
2011-05-09 15:25 ` Tony Lindgren
2011-05-03 1:45 ` Ben Nizette
2011-05-10 22:46 ` Linus Walleij
2011-05-03 1:47 ` Ben Nizette
2011-05-04 9:16 ` Tony Lindgren
2011-05-07 19:10 ` Mike Rapoport
2011-05-09 15:46 ` Tony Lindgren
2011-05-04 22:48 ` Rohit Vaswani
2011-05-05 18:16 ` Rohit Vaswani
2011-05-07 20:09 ` Greg KH
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=1304365077.7792.40.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