All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben-linux@fluff.org>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Ben Dooks <ben-linux@fluff.org>,
	Marek Vasut <marek.vasut@gmail.com>,
	Joonyoung Shim <jy0922.shim@samsung.com>,
	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 06:21:14 +0100	[thread overview]
Message-ID: <20100530052114.GF4720@trinity.fluff.org> (raw)
In-Reply-To: <AANLkTimJyc8E_D_-95eeVFwOVXwJKM5xKCCW-7gkNWrU@mail.gmail.com>

On Sun, May 30, 2010 at 02:04:39PM +0900, Jassi Brar wrote:
> On Sun, May 30, 2010 at 1:51 PM, Ben Dooks <ben-linux@fluff.org> wrote:
> > 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.
> I believe on most implementations, if not all, sizeof char, short and
> int are resp
> 1, 2 and 4 bytes. whereas long denotes the native capacity of the arch.

Mostly, but that is up to the compiler/arch combination, not defined by
the main C standard. It may be defned by the arch C standard.
 
-- 
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 06:21:14 +0100	[thread overview]
Message-ID: <20100530052114.GF4720@trinity.fluff.org> (raw)
In-Reply-To: <AANLkTimJyc8E_D_-95eeVFwOVXwJKM5xKCCW-7gkNWrU@mail.gmail.com>

On Sun, May 30, 2010 at 02:04:39PM +0900, Jassi Brar wrote:
> On Sun, May 30, 2010 at 1:51 PM, Ben Dooks <ben-linux@fluff.org> wrote:
> > 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.
> I believe on most implementations, if not all, sizeof char, short and
> int are resp
> 1, 2 and 4 bytes. whereas long denotes the native capacity of the arch.

Mostly, but that is up to the compiler/arch combination, not defined by
the main C standard. It may be defned by the arch C standard.
 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

  reply	other threads:[~2010-05-30  5:21 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
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 [this message]
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=20100530052114.GF4720@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.