[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=zDJLHUa2ogTeEkmdsbkhvGJCsEw@mail.gmail.com>
Date: Wed, 11 May 2011 00:52:20 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Joe Perches <joe@...ches.com>
Cc: Grant Likely <grant.likely@...retlab.ca>,
Martin Persson <martin.persson@...ricsson.com>,
Lee Jones <lee.jones@...aro.org>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/4] drivers: create a pinmux subsystem
2011/5/11 Joe Perches <joe@...ches.com>:
> On Wed, 2011-05-11 at 00:18 +0200, Linus Walleij wrote:
>> 2011/5/2 Joe Perches <joe@...ches.com>:
>> > On Mon, 2011-05-02 at 21:16 +0200, Linus Walleij wrote:
>> >> From: Linus Walleij <linus.walleij@...aro.org>
>> >> diff --git a/drivers/pinmux/core.c b/drivers/pinmux/core.c
>> > Trivial comments follow
>> >> +static inline int pin_is_valid(int pin)
>> >> +{
>> >> + return ((unsigned)pin) < MACH_NR_PINS;
>> >> +}
>> > Couldn't pin just be declared unsigned or maybe u32?
>> No, because like in the GPIO subsystem you *may* want to send in invalid
>> pins, and those are identified by negative numbers.
>
> Then I think this is clearer and the compiler
> should produce the same code.
>
> static inline bool pin_is_valid(int pin)
> {
> return pin >= 0 && pin < MACH_NR_PINS;
> }
Yes indeed, I'll fix. Can you propose a patch to the same pattern
found in include/asm-generic/gpio.h? It would bring equal
clarity there I believe.
Thanks!
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists