diff for duplicates of <1532423214.32306.1.camel@pengutronix.de>

diff --git a/a/1.txt b/N1/1.txt
index a499767..28d731e 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -49,8 +49,8 @@ your way.
 > > Also, given that those functions are not really shortening the code in
 > > the user they may also be removed completely IMHO.
 > 
-> Wrong assumption..??I use this functions for tracing. It is just to easy
-> to add two trace points...??From technical perspective I don't see any
+> Wrong assumption..  I use this functions for tracing. It is just to easy
+> to add two trace points...  From technical perspective I don't see any
 > advantage or disadvantage of having this functions.
 > If it is my personal preference, then I decide to keep it.
 
@@ -66,14 +66,14 @@ comment. :)
 > > > 
 > > > +
 > > > > > > > > +	cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, "imx_mu_chan[%i]",
-> > > > > > > > +				??????cp->idx);
+> > > > > > > > +				      cp->idx);
 > > > > > > > > +	if (!cp->irq_desc)
 > > > > +		return -ENOMEM;
 > > > 
 > > > +
 > > > > +	ret = devm_request_irq(priv->dev, cp->irq, imx_mu_isr,
 > > > 
-> > > +			???????IRQF_SHARED, cp->irq_desc, chan);
+> > > +			       IRQF_SHARED, cp->irq_desc, chan);
 > > 
 > > Using the devm_ variants of those functions doesn't make sense when the
 > > resources aren't tied to the device lifetime. As you are tearing them
@@ -89,3 +89,8 @@ kind of an API abuse to me.
 
 Regards,
 Lucas
+
+_______________________________________________
+linux-arm-kernel mailing list
+linux-arm-kernel@lists.infradead.org
+http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/a/content_digest b/N1/content_digest
index 7866e2d..5b3e1fe 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,10 +2,20 @@
  "ref\020180722063923.30222-6-o.rempel@pengutronix.de\0"
  "ref\01532366380.3163.109.camel@pengutronix.de\0"
  "ref\0eebba930-b3d7-3670-3d96-35cc6c2a6bcb@pengutronix.de\0"
- "From\0l.stach@pengutronix.de (Lucas Stach)\0"
- "Subject\0[PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit\0"
+ "From\0Lucas Stach <l.stach@pengutronix.de>\0"
+ "Subject\0Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit\0"
  "Date\0Tue, 24 Jul 2018 11:06:54 +0200\0"
- "To\0linux-arm-kernel@lists.infradead.org\0"
+ "To\0Oleksij Rempel <o.rempel@pengutronix.de>"
+  Shawn Guo <shawnguo@kernel.org>
+  Fabio Estevam <fabio.estevam@nxp.com>
+  Rob Herring <robh+dt@kernel.org>
+  Mark Rutland <mark.rutland@arm.com>
+  A.s. Dong <aisheng.dong@nxp.com>
+ " Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>\0"
+ "Cc\0kernel@pengutronix.de"
+  devicetree@vger.kernel.org
+  dl-linux-imx <linux-imx@nxp.com>
+ " linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "Am Dienstag, den 24.07.2018, 07:14 +0200 schrieb Oleksij Rempel:\n"
@@ -59,8 +69,8 @@
  "> > Also, given that those functions are not really shortening the code in\n"
  "> > the user they may also be removed completely IMHO.\n"
  "> \n"
- "> Wrong assumption..??I use this functions for tracing. It is just to easy\n"
- "> to add two trace points...??From technical perspective I don't see any\n"
+ "> Wrong assumption..\302\240\302\240I use this functions for tracing. It is just to easy\n"
+ "> to add two trace points...\302\240\302\240From technical perspective I don't see any\n"
  "> advantage or disadvantage of having this functions.\n"
  "> If it is my personal preference, then I decide to keep it.\n"
  "\n"
@@ -76,14 +86,14 @@
  "> > > \n"
  "> > > +\n"
  "> > > > > > > > +\tcp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, \"imx_mu_chan[%i]\",\n"
- "> > > > > > > > +\t\t\t\t??????cp->idx);\n"
+ "> > > > > > > > +\t\t\t\t\302\240\302\240\302\240\302\240\302\240\302\240cp->idx);\n"
  "> > > > > > > > +\tif (!cp->irq_desc)\n"
  "> > > > +\t\treturn -ENOMEM;\n"
  "> > > \n"
  "> > > +\n"
  "> > > > +\tret = devm_request_irq(priv->dev, cp->irq, imx_mu_isr,\n"
  "> > > \n"
- "> > > +\t\t\t???????IRQF_SHARED, cp->irq_desc, chan);\n"
+ "> > > +\t\t\t\302\240\302\240\302\240\302\240\302\240\302\240\302\240IRQF_SHARED, cp->irq_desc, chan);\n"
  "> > \n"
  "> > Using the devm_ variants of those functions doesn't make sense when the\n"
  "> > resources aren't tied to the device lifetime. As you are tearing them\n"
@@ -98,6 +108,11 @@
  "kind of an API abuse to me.\n"
  "\n"
  "Regards,\n"
- Lucas
+ "Lucas\n"
+ "\n"
+ "_______________________________________________\n"
+ "linux-arm-kernel mailing list\n"
+ "linux-arm-kernel@lists.infradead.org\n"
+ http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
-8378ef5aae8b3f8541de4338287d1e406576c51efb6b8cc4ce9e2fa517fab82a
+e82226948281058b2e05f2bfe461aad6f7b6ed1cd26426b4a13959ff5378a8c0
