From: Ben Dooks <ben-linux@fluff.org>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Marek Vasut <marek.vasut@gmail.com>,
Joonyoung Shim <jy0922.shim@samsung.com>,
ben-linux@fluff.org, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-input@vger.kernel.org,
kyungmin.park@samsung.com, dmitry.torokhov@gmail.com
Subject: Re: [PATCH v2 1/5] ARM: SAMSUNG: Add keypad device support
Date: Sun, 30 May 2010 05:51:51 +0100 [thread overview]
Message-ID: <20100530045151.GE4720@trinity.fluff.org> (raw)
In-Reply-To: <AANLkTilt_-UAZGZepwtIYM7HRuPsX7gsW_ppLZD1_bZq@mail.gmail.com>
On Sun, May 30, 2010 at 01:46:03PM +0900, Jassi Brar wrote:
> On Sun, May 30, 2010 at 12:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Dne Ne 30. kv??tna 2010 05:06:20 Joonyoung Shim napsal(a):
> >> +struct samsung_kp_platdata {
> >> + const struct matrix_keymap_data *keymap_data;
> >> + unsigned int rows;
> >> + unsigned int cols;
> >> + unsigned int rep;
> >
> > I don't know, maybe using uint32_t here? On ARM, it doesn't matter so far as int
> > will be always 32bit, but maybe we should just type the variables well ?
>
> I thought int was 32bits on all archs
No, the C standard doesn't make any guarantees about the size of types,
it is up to the implementation of the compiler. If I rember correctly
the only guarantee in the lanugage definition is that char->short->int->long
be that the next up the line be at-least as a big as the one before.
For this, unsigned int should be fine. unsigned short would probably be
fine too. I'm not going to worry too much about this.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
WARNING: multiple messages have this Message-ID (diff)
From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/5] ARM: SAMSUNG: Add keypad device support
Date: Sun, 30 May 2010 05:51:51 +0100 [thread overview]
Message-ID: <20100530045151.GE4720@trinity.fluff.org> (raw)
In-Reply-To: <AANLkTilt_-UAZGZepwtIYM7HRuPsX7gsW_ppLZD1_bZq@mail.gmail.com>
On Sun, May 30, 2010 at 01:46:03PM +0900, Jassi Brar wrote:
> On Sun, May 30, 2010 at 12:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Dne Ne 30. kv??tna 2010 05:06:20 Joonyoung Shim napsal(a):
> >> +struct samsung_kp_platdata {
> >> + ? ? const struct matrix_keymap_data *keymap_data;
> >> + ? ? unsigned int ? ? ? ? ? ?rows;
> >> + ? ? unsigned int ? ? ? ? ? ?cols;
> >> + ? ? unsigned int ? ? ? ? ? ?rep;
> >
> > I don't know, maybe using uint32_t here? On ARM, it doesn't matter so far as int
> > will be always 32bit, but maybe we should just type the variables well ?
>
> I thought int was 32bits on all archs
No, the C standard doesn't make any guarantees about the size of types,
it is up to the implementation of the compiler. If I rember correctly
the only guarantee in the lanugage definition is that char->short->int->long
be that the next up the line be at-least as a big as the one before.
For this, unsigned int should be fine. unsigned short would probably be
fine too. I'm not going to worry too much about this.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
next prev parent reply other threads:[~2010-05-30 4:51 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-30 3:06 [PATCH v2 1/5] ARM: SAMSUNG: Add keypad device support Joonyoung Shim
2010-05-30 3:06 ` Joonyoung Shim
2010-05-30 3:06 ` [PATCH v2 2/5] ARM: S5PV210: Add keypad device helpers Joonyoung Shim
2010-05-30 3:06 ` Joonyoung Shim
2010-05-30 3:06 ` [PATCH v2 3/5] ARM: S5PV210: Add keypad device to the GONI board Joonyoung Shim
2010-05-30 3:06 ` Joonyoung Shim
2010-05-30 3:06 ` [PATCH v2 4/5] ARM: S5PV210: Add keypad device to the Aquila board Joonyoung Shim
2010-05-30 3:06 ` Joonyoung Shim
2010-05-30 3:06 ` [PATCH v2 5/5] input: samsung-keypad - Add samsung keypad driver Joonyoung Shim
2010-05-30 3:06 ` Joonyoung Shim
2010-05-30 3:39 ` Marek Vasut
2010-05-30 3:39 ` Marek Vasut
2010-05-30 3:44 ` Ben Dooks
2010-05-30 3:44 ` Ben Dooks
2010-05-30 3:42 ` Joonyoung Shim
2010-05-30 3:42 ` Joonyoung Shim
2010-05-30 3:42 ` Ben Dooks
2010-05-30 3:42 ` Ben Dooks
2010-05-30 4:35 ` Joonyoung Shim
2010-05-30 4:35 ` Joonyoung Shim
2010-06-03 1:00 ` Ben Dooks
2010-06-03 1:00 ` Ben Dooks
2010-06-03 4:47 ` Joonyoung Shim
2010-06-03 4:47 ` Joonyoung Shim
2010-06-07 7:30 ` Marek Szyprowski
2010-06-07 7:30 ` Marek Szyprowski
2010-05-30 3:42 ` [PATCH v2 1/5] ARM: SAMSUNG: Add keypad device support Marek Vasut
2010-05-30 3:42 ` Marek Vasut
2010-05-30 4:46 ` Jassi Brar
2010-05-30 4:46 ` Jassi Brar
2010-05-30 4:51 ` Ben Dooks [this message]
2010-05-30 4:51 ` Ben Dooks
2010-05-30 5:04 ` Jassi Brar
2010-05-30 5:04 ` Jassi Brar
2010-05-30 5:21 ` Ben Dooks
2010-05-30 5:21 ` Ben Dooks
2010-05-31 9:44 ` Mark Brown
2010-05-31 9:44 ` Mark Brown
2010-05-30 8:52 ` Dmitry Torokhov
2010-05-30 8:52 ` Dmitry Torokhov
2010-05-31 1:14 ` Joonyoung Shim
2010-05-31 1:14 ` Joonyoung Shim
2010-05-31 0:06 ` Kukjin Kim
2010-05-31 0:06 ` Kukjin Kim
2010-05-31 0:15 ` Marek Vasut
2010-05-31 0:15 ` Marek Vasut
2010-05-31 1:09 ` Joonyoung Shim
2010-05-31 1:09 ` Joonyoung Shim
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=20100530045151.GE4720@trinity.fluff.org \
--to=ben-linux@fluff.org \
--cc=dmitry.torokhov@gmail.com \
--cc=jassisinghbrar@gmail.com \
--cc=jy0922.shim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=marek.vasut@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.