From: pawel.moll@arm.com (Pawel Moll)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] leds: Add generic support for memory mapped LEDs
Date: Mon, 05 Nov 2012 12:55:59 +0000 [thread overview]
Message-ID: <1352120159.10947.3.camel@hornet> (raw)
In-Reply-To: <1352108387.3212.12.camel@linaro1.home>
On Mon, 2012-11-05 at 09:39 +0000, Jon Medhurst (Tixy) wrote:
> > +static void mmio_led_brightness_set(struct led_classdev *cdev,
> > + enum led_brightness brightness)
> > +{
> > + struct mmio_led *led = container_of(cdev, struct mmio_led, cdev);
> > + unsigned long uninitialized_var(flags);
>
> uninitialized_var seems to be a bit contentious, Linus Torvalds had a
> recent complaint about it which prompted Ingo to post a patch proposing
> to removing it: https://patchwork.kernel.org/patch/1655621/ So perhaps
> best to avoid using it ;-).
>
> In this case, you could possibly keep gcc quite with something like:
>
> spinlock_t *lock = led->lock;
>
> and then use the local variable 'lock' everywhere instead of led->lock.
> Or just keep it simple an initialise flags to 0 instead.
Yeah, = 0 will do...
> > + if (!pdata)
> > + return -EINVAL;
> > +
> > + if (pdata->reg_size != 8 && pdata->reg_size != 16 &&
> > + pdata->reg_size != 32)
> > + return -EFAULT;
>
> Is EFAULT appropriate here? Why not EINVAL?
Hm. To distinguish it from !pdata case I guess (and a 13 bit wide
transaction sounds like a fault to me ;-), but I can be persuaded
otherwise without much effort...
Thanks!
Pawe?
next prev parent reply other threads:[~2012-11-05 12:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-01 17:58 [PATCH 1/2] leds: Add generic support for memory mapped LEDs Pawel Moll
2012-11-01 17:58 ` [PATCH 2/2] mfd: vexpress-sysreg: Use MMIO driver for platform LEDs Pawel Moll
2012-11-05 9:39 ` [PATCH 1/2] leds: Add generic support for memory mapped LEDs Jon Medhurst (Tixy)
2012-11-05 12:55 ` Pawel Moll [this message]
2012-11-05 13:52 ` Jon Medhurst (Tixy)
2012-11-08 15:35 ` Pawel Moll
2012-11-19 11:44 ` Pawel Moll
2012-11-26 15:25 ` Pawel Moll
2012-11-26 15:37 ` Vasily Khoruzhick
2012-11-26 16:10 ` Pawel Moll
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=1352120159.10947.3.camel@hornet \
--to=pawel.moll@arm.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;
as well as URLs for NNTP newsgroup(s).