All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20151126103020.GA3136@ares>

diff --git a/a/1.txt b/N1/1.txt
index f9f9f7c..de1cc27 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,7 +1,7 @@
 On Thu, Nov 26, 2015 at 12:34:33AM +0000, Ben Hutchings wrote:
 > On Wed, 2015-11-25 at 23:05 +0000, Luis Henriques wrote:
 > > On Tue, Nov 24, 2015 at 10:33:59PM +0000, Ben Hutchings wrote:
-> > > 3.2.74-rc1 review patch.  If anyone has any objections, please let me know.
+> > > 3.2.74-rc1 review patch.��If anyone has any objections, please let me know.
 > > > 
 > > > ------------------
 > > > 
@@ -10,23 +10,23 @@ On Thu, Nov 26, 2015 at 12:34:33AM +0000, Ben Hutchings wrote:
 > > > commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.
 > > > 
 > > > We've had many reports that some Creative sound cards with CA0132
-> > > don't work well.  Some reported that it starts working after reloading
+> > > don't work well.��Some reported that it starts working after reloading
 > > > the module, while some reported it starts working when a 32bit kernel
-> > > is used.  All these facts seem implying that the chip fails to
+> > > is used.��All these facts seem implying that the chip fails to
 > > > communicate when the buffer is located in 64bit address.
 > > > 
 > > > This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
-> > > flag to the corresponding PCI entries.  I casually had a chance to
+> > > flag to the corresponding PCI entries.��I casually had a chance to
 > > > test an SB Recon3D board, and indeed this seems helping.
 > > > 
 > > > Although this hasn't been tested on all Creative devices, it's safer
-> > > to assume that this restriction applies to the rest of them, too.  So
+> > > to assume that this restriction applies to the rest of them, too.��So
 > > > the flag is applied to all Creative entries.
 > > > 
 > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
 > > > [bwh: Backported to 3.2: drop the change to AZX_DCAPS_PRESET_CTHDA]
 > > 
-> > Is there a reason for dropping this change?  Adding the
+> > Is there a reason for dropping this change?��Adding the
 > > AZX_DCAPS_NO_64BIT flag to the AZX_DCAPS_PRESET_CTHDA definition does
 > > seem to make sense.
 > [...]
@@ -39,7 +39,7 @@ the noise.
 
 Cheers,
 --
-Luís
+Lu�s
 
 
 > Ben.
diff --git a/a/content_digest b/N1/content_digest
index 93e5cff..a4cfa2d 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -15,7 +15,7 @@
  "On Thu, Nov 26, 2015 at 12:34:33AM +0000, Ben Hutchings wrote:\n"
  "> On Wed, 2015-11-25 at 23:05 +0000, Luis Henriques wrote:\n"
  "> > On Tue, Nov 24, 2015 at 10:33:59PM +0000, Ben Hutchings wrote:\n"
- "> > > 3.2.74-rc1 review patch.\302\240\302\240If anyone has any objections, please let me know.\n"
+ "> > > 3.2.74-rc1 review patch.\303\257\302\277\302\275\303\257\302\277\302\275If anyone has any objections, please let me know.\n"
  "> > > \n"
  "> > > ------------------\n"
  "> > > \n"
@@ -24,23 +24,23 @@
  "> > > commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.\n"
  "> > > \n"
  "> > > We've had many reports that some Creative sound cards with CA0132\n"
- "> > > don't work well.\302\240\302\240Some reported that it starts working after reloading\n"
+ "> > > don't work well.\303\257\302\277\302\275\303\257\302\277\302\275Some reported that it starts working after reloading\n"
  "> > > the module, while some reported it starts working when a 32bit kernel\n"
- "> > > is used.\302\240\302\240All these facts seem implying that the chip fails to\n"
+ "> > > is used.\303\257\302\277\302\275\303\257\302\277\302\275All these facts seem implying that the chip fails to\n"
  "> > > communicate when the buffer is located in 64bit address.\n"
  "> > > \n"
  "> > > This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT\n"
- "> > > flag to the corresponding PCI entries.\302\240\302\240I casually had a chance to\n"
+ "> > > flag to the corresponding PCI entries.\303\257\302\277\302\275\303\257\302\277\302\275I casually had a chance to\n"
  "> > > test an SB Recon3D board, and indeed this seems helping.\n"
  "> > > \n"
  "> > > Although this hasn't been tested on all Creative devices, it's safer\n"
- "> > > to assume that this restriction applies to the rest of them, too.\302\240\302\240So\n"
+ "> > > to assume that this restriction applies to the rest of them, too.\303\257\302\277\302\275\303\257\302\277\302\275So\n"
  "> > > the flag is applied to all Creative entries.\n"
  "> > > \n"
  "> > > Signed-off-by: Takashi Iwai <tiwai@suse.de>\n"
  "> > > [bwh: Backported to 3.2: drop the change to AZX_DCAPS_PRESET_CTHDA]\n"
  "> > \n"
- "> > Is there a reason for dropping this change?\302\240\302\240Adding the\n"
+ "> > Is there a reason for dropping this change?\303\257\302\277\302\275\303\257\302\277\302\275Adding the\n"
  "> > AZX_DCAPS_NO_64BIT flag to the AZX_DCAPS_PRESET_CTHDA definition does\n"
  "> > seem to make sense.\n"
  "> [...]\n"
@@ -53,7 +53,7 @@
  "\n"
  "Cheers,\n"
  "--\n"
- "Lu\303\255s\n"
+ "Lu\303\257\302\277\302\275s\n"
  "\n"
  "\n"
  "> Ben.\n"
@@ -63,4 +63,4 @@
  "> Unix is many things to many people,\n"
  > but it's never been everything to anybody.
 
-edf8e97cfef276049afed1235de1b1fcd3dcf19be219bd6a0b9e3e77ed21453e
+a9717f014c41f53539b43efe51482123cd873d07d628feeb06a5869a4bb41de0

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.