All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20100530052114.GF4720@trinity.fluff.org>

diff --git a/a/1.txt b/N1/1.txt
index 5805424..c92c493 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -4,10 +4,10 @@ On Sun, May 30, 2010 at 02:04:39PM +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;
+> >> >> + ? ? 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 ?
@@ -17,7 +17,7 @@ On Sun, May 30, 2010 at 02:04:39PM +0900, Jassi Brar wrote:
 > > 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.
+> > 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.
diff --git a/a/content_digest b/N1/content_digest
index 9d9617f..f1606a4 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -3,18 +3,10 @@
  "ref\0AANLkTilt_-UAZGZepwtIYM7HRuPsX7gsW_ppLZD1_bZq@mail.gmail.com\0"
  "ref\020100530045151.GE4720@trinity.fluff.org\0"
  "ref\0AANLkTimJyc8E_D_-95eeVFwOVXwJKM5xKCCW-7gkNWrU@mail.gmail.com\0"
- "From\0Ben Dooks <ben-linux@fluff.org>\0"
- "Subject\0Re: [PATCH v2 1/5] ARM: SAMSUNG: Add keypad device support\0"
+ "From\0ben-linux@fluff.org (Ben Dooks)\0"
+ "Subject\0[PATCH v2 1/5] ARM: SAMSUNG: Add keypad device support\0"
  "Date\0Sun, 30 May 2010 06:21:14 +0100\0"
- "To\0Jassi Brar <jassisinghbrar@gmail.com>\0"
- "Cc\0Ben 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\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Sun, May 30, 2010 at 02:04:39PM +0900, Jassi Brar wrote:\n"
@@ -23,10 +15,10 @@
  "> >> On Sun, May 30, 2010 at 12:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:\n"
  "> >> > Dne Ne 30. kv??tna 2010 05:06:20 Joonyoung Shim napsal(a):\n"
  "> >> >> +struct samsung_kp_platdata {\n"
- "> >> >> + \302\240 \302\240 const struct matrix_keymap_data *keymap_data;\n"
- "> >> >> + \302\240 \302\240 unsigned int \302\240 \302\240 \302\240 \302\240 \302\240 \302\240rows;\n"
- "> >> >> + \302\240 \302\240 unsigned int \302\240 \302\240 \302\240 \302\240 \302\240 \302\240cols;\n"
- "> >> >> + \302\240 \302\240 unsigned int \302\240 \302\240 \302\240 \302\240 \302\240 \302\240rep;\n"
+ "> >> >> + ? ? const struct matrix_keymap_data *keymap_data;\n"
+ "> >> >> + ? ? unsigned int ? ? ? ? ? ?rows;\n"
+ "> >> >> + ? ? unsigned int ? ? ? ? ? ?cols;\n"
+ "> >> >> + ? ? unsigned int ? ? ? ? ? ?rep;\n"
  "> >> >\n"
  "> >> > I don't know, maybe using uint32_t here? On ARM, it doesn't matter so far as int\n"
  "> >> > will be always 32bit, but maybe we should just type the variables well ?\n"
@@ -36,7 +28,7 @@
  "> > No, the C standard doesn't make any guarantees about the size of types,\n"
  "> > it is up to the implementation of the compiler. If I rember correctly\n"
  "> > the only guarantee in the lanugage definition is that char->short->int->long\n"
- "> > be that the next up the line be at-least as a \302\240big as the one before.\n"
+ "> > be that the next up the line be at-least as a ?big as the one before.\n"
  "> I believe on most implementations, if not all, sizeof char, short and\n"
  "> int are resp\n"
  "> 1, 2 and 4 bytes. whereas long denotes the native capacity of the arch.\n"
@@ -50,4 +42,4 @@
  "Q:      What's a light-year?\n"
  A:      One-third less calories than a regular year.
 
-b9fc1b68299ef9bc2e2292fd92941584f8f426aecdde7ce187c47616587bd4c4
+aa18b9a9d34f063ead2c4706009e5e102cadc27b32ee5965d88247a6d861699c

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.