linux-kernel - Re: [NEW DRIVER V2 5/7] DA9058 GPIO driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACRpkdZ9Jw_yMG6FxF=kQ0zm+8+p3uBp5gGAXVVXWT=W=ET5og@mail.gmail.com>
Date:	Wed, 15 Aug 2012 17:01:17 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	"Opensource [Anthony Olech]" <anthony.olech.opensource@...semi.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	LKML <linux-kernel@...r.kernel.org>,
	David Dajun Chen <david.chen@...semi.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>
Subject: Re: [NEW DRIVER V2 5/7] DA9058 GPIO driver

On Wed, Aug 15, 2012 at 12:08 PM, Opensource [Anthony Olech]
<anthony.olech.opensource@...semi.com> wrote:
> [Me]

>> > +       if (offset > 1)
>> > +               return -EINVAL;
>> So there are two GPIO pins, 0 and 1? That seems odd, but OK.
>
> That is a feature of the hardware. I believe that calling them "0" and
> "1" is the correct thing to do. Correct me if they should have been
> called "1" and "2", or something else.

It's correct, what I thought was odd was the fact that there were only
two GPIO pins on this device. But some have only one even, just wanted
to verify...

> HANDLING NIBBLES
> ================
>
> The handling of nibbles within a byte follows the rule that constants
> for the nibble NOT being operated on have those bits set to zero,
> and thus only bits being operated on may be non-zero. Thus to set,
> for example, the value 0xB into the MSH the operation is:
>         byte &= ~0xF0
>         byte |= 0xB0
> it being obvious that it is the upper nibble being operated on.
> It seems that you are following a different rule for handling nibbles,
> and I can't find any standard for doing so in the kernel, so could
> you send me your reference documents?

In this case as stated elsewhere, I'm happy that you do things
this way, if  you #define the magic values you're using
in your bytes and nibbles, because else it's just hard to read.

#define FOO_MASK 0xF0
#define BAR_FEATURE 0xB0

byte &= ~FOO_MASK;
byte |= BAR_FEATURE;

It's more readble.

Yours,
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/