All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1209657089.20889.46.camel@linux.site>

diff --git a/a/1.txt b/N1/1.txt
index 342918f..b27ba72 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,38 +1,40 @@
 On Thu, 2008-05-01 at 10:04 +0200, Jean Delvare wrote:
 > On Mon, 28 Apr 2008 18:16:17 +0200, Kay Sievers wrote:
 > > On Mon, 2008-04-28 at 17:40 +0200, Jean Delvare wrote:
-> > > Why would i2c device modaliases ever contain multiple strings? A device
+> > > Why would i2c device modaliases ever contain multiple strings? A devi=
+ce
 > > > can't have multiple names, can it?
-> > 
+> >=20
 > > Like ACPI/PNP devices, which can have several compat id's, which means
 > > that a single device can have "multiple names":
 > >   $ cat /sys/bus/pnp/devices/00:09/id
 > >   IBM0057
 > >   PNP0f13
-> 
+>=20
 > Ah, I didn't know about this. Now I'm curious how it can work. Does it
-> mean that several drivers attempt to bind to this device? 
+> mean that several drivers attempt to bind to this device?=20
 
-They are usually all id's for the same type of device, and don't describe
+=EF=BB=BFThey are usually all id's for the same type of device, and don't d=
+escribe
 multiple functions at the same time. In most cases the vendor id's, like
 "IBM0057" here, do not match anything.
 
 > > > Can't we just stop handle_moddevtable() from adding a tailing "*"
 > > > automatically, and just let the device types which need it, add it on
 > > > their own?
-> > 
+> >=20
 > > For a lot subsystems it's fine to have it appended, as there is a
 > > defined list of identifiers, which must appear in the same order, and
 > > new identifiers are appended to the end. So the "*" still matches
 > > modules with possibly extended modalias strings.
-> 
+>=20
 > I understand the logic, however I am skeptical how useful it is in
 > practice. If we add an identifier to the device aliases, then we also
 > update the corresponding modalias, so no in-tree driver can break. The
 > only case where it makes a difference, as far as I can see, is for
 > out-of-tree drivers. Am I correct?
 
-That sounds correct, yes.
+=EF=BB=BFThat sounds correct, yes.
 
 > On top of that, I doubt that we
 > actually add new identifiers that frequently, do we?
@@ -41,17 +43,17 @@ Not that I know.
 
 > > We would also need to review all buses which export modalias, if they
 > > need the "*" or not, and add them by hand, if needed.
-> > 
+> >=20
 > > I guess, it's easier to introduce an additional parameter to
 > > file2alias::do_table() and suppress the trailing "*" for i2c?
-> 
+>=20
 > That's one possibility, but I had a slightly different approach, which
 > is to just let the type-specific handlers add the trailing "*" by
 > themselves if they need it. This allows for optimization in a few
 > cases.
-> 
+>=20
 > Subject: modpost: i2c aliases need no trailing wildcard
-> 
+>=20
 > Not all device type aliases need a trailing wildcard, in particular
 > the i2c aliases don't. Don't add a wildcard by default in do_table(),
 > instead let each device type handler add it if needed.
@@ -72,9 +74,3 @@ looks correct after the patch, this should go in, I think.
 
 Thanks,
 Kay
-
-
-_______________________________________________
-i2c mailing list
-i2c@lm-sensors.org
-http://lists.lm-sensors.org/mailman/listinfo/i2c
diff --git a/a/content_digest b/N1/content_digest
index 89fb8ca..9ecf176 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -4,52 +4,53 @@
  "ref\020080428174010.5a40c2c0@hyperion.delvare\0"
  "ref\01209399377.3666.30.camel@linux.site\0"
  "ref\020080501100409.1b04fdb7@hyperion.delvare\0"
- "ref\020080501100409.1b04fdb7-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org\0"
- "From\0Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>\0"
+ "From\0Kay Sievers <kay.sievers@vrfy.org>\0"
  "Subject\0Re: [PATCH 1/2] i2c: Add support for device alias names\0"
  "Date\0Thu, 01 May 2008 17:51:29 +0200\0"
- "To\0Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>\0"
- "Cc\0linuxppc-dev list <linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>"
-  Paul Mundt <lethal-M7jkjyW5wf5g9hUCZPvPmw@public.gmane.org>
-  Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
- " Linux I2C <i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org>\0"
+ "To\0Jean Delvare <khali@linux-fr.org>\0"
+ "Cc\0linuxppc-dev list <linuxppc-dev@ozlabs.org>"
+  Paul Mundt <lethal@linux-sh.org>
+  Scott Wood <scottwood@freescale.com>
+ " Linux I2C <i2c@lm-sensors.org>\0"
  "\00:1\0"
  "b\0"
  "On Thu, 2008-05-01 at 10:04 +0200, Jean Delvare wrote:\n"
  "> On Mon, 28 Apr 2008 18:16:17 +0200, Kay Sievers wrote:\n"
  "> > On Mon, 2008-04-28 at 17:40 +0200, Jean Delvare wrote:\n"
- "> > > Why would i2c device modaliases ever contain multiple strings? A device\n"
+ "> > > Why would i2c device modaliases ever contain multiple strings? A devi=\n"
+ "ce\n"
  "> > > can't have multiple names, can it?\n"
- "> > \n"
+ "> >=20\n"
  "> > Like ACPI/PNP devices, which can have several compat id's, which means\n"
  "> > that a single device can have \"multiple names\":\n"
  "> >   $ cat /sys/bus/pnp/devices/00:09/id\n"
  "> >   IBM0057\n"
  "> >   PNP0f13\n"
- "> \n"
+ ">=20\n"
  "> Ah, I didn't know about this. Now I'm curious how it can work. Does it\n"
- "> mean that several drivers attempt to bind to this device? \n"
+ "> mean that several drivers attempt to bind to this device?=20\n"
  "\n"
- "\357\273\277They are usually all id's for the same type of device, and don't describe\n"
+ "=EF=BB=BFThey are usually all id's for the same type of device, and don't d=\n"
+ "escribe\n"
  "multiple functions at the same time. In most cases the vendor id's, like\n"
  "\"IBM0057\" here, do not match anything.\n"
  "\n"
  "> > > Can't we just stop handle_moddevtable() from adding a tailing \"*\"\n"
  "> > > automatically, and just let the device types which need it, add it on\n"
  "> > > their own?\n"
- "> > \n"
+ "> >=20\n"
  "> > For a lot subsystems it's fine to have it appended, as there is a\n"
  "> > defined list of identifiers, which must appear in the same order, and\n"
  "> > new identifiers are appended to the end. So the \"*\" still matches\n"
  "> > modules with possibly extended modalias strings.\n"
- "> \n"
+ ">=20\n"
  "> I understand the logic, however I am skeptical how useful it is in\n"
  "> practice. If we add an identifier to the device aliases, then we also\n"
  "> update the corresponding modalias, so no in-tree driver can break. The\n"
  "> only case where it makes a difference, as far as I can see, is for\n"
  "> out-of-tree drivers. Am I correct?\n"
  "\n"
- "\357\273\277That sounds correct, yes.\n"
+ "=EF=BB=BFThat sounds correct, yes.\n"
  "\n"
  "> On top of that, I doubt that we\n"
  "> actually add new identifiers that frequently, do we?\n"
@@ -58,17 +59,17 @@
  "\n"
  "> > We would also need to review all buses which export modalias, if they\n"
  "> > need the \"*\" or not, and add them by hand, if needed.\n"
- "> > \n"
+ "> >=20\n"
  "> > I guess, it's easier to introduce an additional parameter to\n"
  "> > file2alias::do_table() and suppress the trailing \"*\" for i2c?\n"
- "> \n"
+ ">=20\n"
  "> That's one possibility, but I had a slightly different approach, which\n"
  "> is to just let the type-specific handlers add the trailing \"*\" by\n"
  "> themselves if they need it. This allows for optimization in a few\n"
  "> cases.\n"
- "> \n"
+ ">=20\n"
  "> Subject: modpost: i2c aliases need no trailing wildcard\n"
- "> \n"
+ ">=20\n"
  "> Not all device type aliases need a trailing wildcard, in particular\n"
  "> the i2c aliases don't. Don't add a wildcard by default in do_table(),\n"
  "> instead let each device type handler add it if needed.\n"
@@ -88,12 +89,6 @@
  "looks correct after the patch, this should go in, I think.\n"
  "\n"
  "Thanks,\n"
- "Kay\n"
- "\n"
- "\n"
- "_______________________________________________\n"
- "i2c mailing list\n"
- "i2c@lm-sensors.org\n"
- http://lists.lm-sensors.org/mailman/listinfo/i2c
+ Kay
 
-bd7c8c7e8ecd804e0ea9501c42ec3f6a6435442d41d76acc5819900c442fcfdf
+252449ef52703bbb8a65997ad3599c554cf0510f7dc0e9e00397dd751c1bee55

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.