diff for duplicates of <1477405332.2482.87.camel@baylibre.com>

diff --git a/a/1.txt b/N1/1.txt
index ab08b0d..7b5829c 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -54,7 +54,7 @@ On Tue, 2016-10-25 at 14:38 +0100, Marc Zyngier wrote:
 > > The calculation is question here is meant to get the appropriate
 > > hwirq
 > > number from a particular gpio (and deal with the gpios that can't
-> > provide an irq at all).?
+> > provide an irq at all). 
 > > 
 > > If I look at other gpio drivers, many are doing exactly this kind
 > > of
@@ -70,7 +70,7 @@ On Tue, 2016-10-25 at 14:38 +0100, Marc Zyngier wrote:
 > > here. We
 > > have only 8 upstream irqs for 130+ pins, so only 8 mappings
 > > possible at
-> > a time.?
+> > a time. 
 > > 
 > > My understanding is that irqdomain provide a way to map hwirq to
 > > linux
@@ -86,7 +86,7 @@ On Tue, 2016-10-25 at 14:38 +0100, Marc Zyngier wrote:
 There is a few problems to guarantee that gpio == hwirq.
 1. We have 2 instances of pinctrl, to guarantee that the linux gpio
 number == hwirq, we would have to guarantee the order in which they are
-probed. At least this my understanding?
+probed. At least this my understanding 
 2. Inside each instance, we may have banks that can't have irq. We even
 have a bank on meson8b which has a mixed state (the last pins don't
 have irqs, while the first ones do). those banks/pins are still valid
@@ -123,7 +123,7 @@ That's why I create the mapping in the .to_irq callback.
 > > with this hardware.
 > > We are looking for a way to implement support for
 > > IRQ_TYPE_EDGE_BOTH
-> > (needed for things like gpio-keys or mmc card detect).?
+> > (needed for things like gpio-keys or mmc card detect). 
 > > The controller can do each edge but not both at the same time.
 > > I'm thinking that implementing another irqdomain at the gpio level
 > > would allow to properly check the pad level in the EOI callback
@@ -139,14 +139,14 @@ That's why I create the mapping in the .to_irq callback.
 > same.
 > I fail to see what the benefit is.
 
-The separate piece of hw is the gpio itself.?
+The separate piece of hw is the gpio itself. 
 The irq-controller (in irqchip) can't read the gpio state because it is
 simply another device.
 
-The domain I'm thinking about wouldn't do much, I reckon.?
+The domain I'm thinking about wouldn't do much, I reckon. 
 It would just register an irqchip which would only implement eoi.
 For everything else, it would rely the parent controller.
->From your explanation, I understood this is the purpose of hierarchy
+From your explanation, I understood this is the purpose of hierarchy
 domains, For each hw in the chain to handle only what it can, and rely
 on its parent for the rest.
 
@@ -162,8 +162,8 @@ on its parent for the rest.
 > lost at least *two* interrupts (the falling edge and the following
 > rising edge).
 
-If a 'usual' controller support?IRQ_TYPE_EDGE_BOTH and the line goes
-low between latching?rising edge and handling the interrupt, wouldn't
+If a 'usual' controller support IRQ_TYPE_EDGE_BOTH and the line goes
+low between latching rising edge and handling the interrupt, wouldn't
 you miss the falling edge anyway ? The signal is just going too fast
 the HW to handle everything.
 
@@ -175,3 +175,8 @@ for another rising edge.
 > Thanks,
 > 
 > 	M.
+
+_______________________________________________
+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 1bfc391..64064fb 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,10 +6,24 @@
  "ref\0ec7c6cc5-cf9a-9c75-4b07-e337064c7d6e@arm.com\0"
  "ref\01477400900.2482.51.camel@baylibre.com\0"
  "ref\0dee26f0b-e175-f8a0-2b73-08e8e324841c@arm.com\0"
- "From\0jbrunet@baylibre.com (Jerome Brunet)\0"
- "Subject\0[PATCH 4/9] pinctrl: meson: allow gpio to request irq\0"
+ "From\0Jerome Brunet <jbrunet@baylibre.com>\0"
+ "Subject\0Re: [PATCH 4/9] pinctrl: meson: allow gpio to request irq\0"
  "Date\0Tue, 25 Oct 2016 16:22:12 +0200\0"
- "To\0linus-amlogic@lists.infradead.org\0"
+ "To\0Marc Zyngier <marc.zyngier@arm.com>"
+ " Linus Walleij <linus.walleij@linaro.org>\0"
+ "Cc\0devicetree@vger.kernel.org <devicetree@vger.kernel.org>"
+  Jason Cooper <jason@lakedaemon.net>
+  Kevin Hilman <khilman@baylibre.com>
+  Will Deacon <will.deacon@arm.com>
+  linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
+  Russell King <linux@armlinux.org.uk>
+  linux-gpio@vger.kernel.org <linux-gpio@vger.kernel.org>
+  Rob Herring <robh+dt@kernel.org>
+  Catalin Marinas <catalin.marinas@arm.com>
+  Carlo Caione <carlo@caione.org>
+  open list:ARM/Amlogic Meson... <linux-amlogic@lists.infradead.org>
+  Thomas Gleixner <tglx@linutronix.de>
+ " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0"
  "\00:1\0"
  "b\0"
  "On Tue, 2016-10-25 at 14:38 +0100, Marc Zyngier wrote:\n"
@@ -68,7 +82,7 @@
  "> > The calculation is question here is meant to get the appropriate\n"
  "> > hwirq\n"
  "> > number from a particular gpio (and deal with the gpios that can't\n"
- "> > provide an irq at all).?\n"
+ "> > provide an irq at all).\302\240\n"
  "> > \n"
  "> > If I look at other gpio drivers, many are doing exactly this kind\n"
  "> > of\n"
@@ -84,7 +98,7 @@
  "> > here. We\n"
  "> > have only 8 upstream irqs for 130+ pins, so only 8 mappings\n"
  "> > possible at\n"
- "> > a time.?\n"
+ "> > a time.\302\240\n"
  "> > \n"
  "> > My understanding is that irqdomain provide a way to map hwirq to\n"
  "> > linux\n"
@@ -100,7 +114,7 @@
  "There is a few problems to guarantee that gpio == hwirq.\n"
  "1. We have 2 instances of pinctrl, to guarantee that the linux gpio\n"
  "number == hwirq, we would have to guarantee the order in which they are\n"
- "probed. At least this my understanding?\n"
+ "probed. At least this my understanding\302\240\n"
  "2. Inside each instance, we may have banks that can't have irq. We even\n"
  "have a bank on meson8b which has a mixed state (the last pins don't\n"
  "have irqs, while the first ones do). those banks/pins are still valid\n"
@@ -137,7 +151,7 @@
  "> > with this hardware.\n"
  "> > We are looking for a way to implement support for\n"
  "> > IRQ_TYPE_EDGE_BOTH\n"
- "> > (needed for things like gpio-keys or mmc card detect).?\n"
+ "> > (needed for things like gpio-keys or mmc card detect).\302\240\n"
  "> > The controller can do each edge but not both at the same time.\n"
  "> > I'm thinking that implementing another irqdomain at the gpio level\n"
  "> > would allow to properly check the pad level in the EOI callback\n"
@@ -153,14 +167,14 @@
  "> same.\n"
  "> I fail to see what the benefit is.\n"
  "\n"
- "The separate piece of hw is the gpio itself.?\n"
+ "The separate piece of hw is the gpio itself.\302\240\n"
  "The irq-controller (in irqchip) can't read the gpio state because it is\n"
  "simply another device.\n"
  "\n"
- "The domain I'm thinking about wouldn't do much, I reckon.?\n"
+ "The domain I'm thinking about wouldn't do much, I reckon.\302\240\n"
  "It would just register an irqchip which would only implement eoi.\n"
  "For everything else, it would rely the parent controller.\n"
- ">From your explanation, I understood this is the purpose of hierarchy\n"
+ "From your explanation, I understood this is the purpose of hierarchy\n"
  "domains, For each hw in the chain to handle only what it can, and rely\n"
  "on its parent for the rest.\n"
  "\n"
@@ -176,8 +190,8 @@
  "> lost at least *two* interrupts (the falling edge and the following\n"
  "> rising edge).\n"
  "\n"
- "If a 'usual' controller support?IRQ_TYPE_EDGE_BOTH and the line goes\n"
- "low between latching?rising edge and handling the interrupt, wouldn't\n"
+ "If a 'usual' controller support\302\240IRQ_TYPE_EDGE_BOTH and the line goes\n"
+ "low between latching\302\240rising edge and handling the interrupt, wouldn't\n"
  "you miss the falling edge anyway ? The signal is just going too fast\n"
  "the HW to handle everything.\n"
  "\n"
@@ -188,6 +202,11 @@
  "> \n"
  "> Thanks,\n"
  "> \n"
- "> \tM."
+ "> \tM.\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
 
-e79d7d1bbf8ca92785bd97febd60bdbe8b25284239edf0d2b734a724db4703c5
+c4303e0f3bc2ef0587b42c93cc864ffc1c6657fa94b5b2d8a656d2fc94a8d617
