All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1492005119.7236.62.camel@kernel.crashing.org>

diff --git a/a/1.txt b/N1/1.txt
index aaf62a2..a79598f 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,37 +1,28 @@
-On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
-> default implementation should fail if it's not supportable on all
-> architectures.  However, when we have existing drivers using an
-> interface that doesn't provide the semantics they already require,
-> then it makes no sense to effectively break these drivers on a range
-> of existing architectures.
-> 
-> The question really is - what's the best way to solve the problem
-> with
-> existing drivers without breaking them.  I suspect that, sadly, the
-> only realistic way forward here is via the litter-drivers-with-ifdefs
-> approach since you don't like providing a default implementation that
-> is compatible with what these drivers are already doing.
-
-Then make ioremap_nopost return NULL when the arch doesn't have 
-the right semantic.
-
-The driver than can *chose* to either silently fallback to ioremap,
-which has served us well for a long time despite being theorically in
-violation of the spec, or do funny things like read back some register
-after every config write to ensure ordering etc...
-
-I much prefer that approach than having some generic ioremap function
-that exposes a semantic that silently provides a weaker one on some
-architecture.
-
-At least we make the failure explicit, and the driver can take
-alternate (possibly sub-optimal) action if it chooses to do so.
-
-Cheers,
-Ben.
-
-
-_______________________________________________
-linux-arm-kernel mailing list
-linux-arm-kernel@lists.infradead.org
-http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
+T24gV2VkLCAyMDE3LTA0LTEyIGF0IDEyOjMxICswMTAwLCBSdXNzZWxsIEtpbmcgLSBBUk0gTGlu
+dXggd3JvdGU6Cj4gZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZmFpbCBpZiBpdCdzIG5v
+dCBzdXBwb3J0YWJsZSBvbiBhbGwKPiBhcmNoaXRlY3R1cmVzLsKgIEhvd2V2ZXIsIHdoZW4gd2Ug
+aGF2ZSBleGlzdGluZyBkcml2ZXJzIHVzaW5nIGFuCj4gaW50ZXJmYWNlIHRoYXQgZG9lc24ndCBw
+cm92aWRlIHRoZSBzZW1hbnRpY3MgdGhleSBhbHJlYWR5IHJlcXVpcmUsCj4gdGhlbiBpdCBtYWtl
+cyBubyBzZW5zZSB0byBlZmZlY3RpdmVseSBicmVhayB0aGVzZSBkcml2ZXJzIG9uIGEgcmFuZ2UK
+PiBvZiBleGlzdGluZyBhcmNoaXRlY3R1cmVzLgo+IAo+IFRoZSBxdWVzdGlvbiByZWFsbHkgaXMg
+LSB3aGF0J3MgdGhlIGJlc3Qgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtCj4gd2l0aAo+IGV4aXN0
+aW5nIGRyaXZlcnMgd2l0aG91dCBicmVha2luZyB0aGVtLsKgIEkgc3VzcGVjdCB0aGF0LCBzYWRs
+eSwgdGhlCj4gb25seSByZWFsaXN0aWMgd2F5IGZvcndhcmQgaGVyZSBpcyB2aWEgdGhlIGxpdHRl
+ci1kcml2ZXJzLXdpdGgtaWZkZWZzCj4gYXBwcm9hY2ggc2luY2UgeW91IGRvbid0IGxpa2UgcHJv
+dmlkaW5nIGEgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiB0aGF0Cj4gaXMgY29tcGF0aWJsZSB3aXRo
+IHdoYXQgdGhlc2UgZHJpdmVycyBhcmUgYWxyZWFkeSBkb2luZy4KClRoZW4gbWFrZSBpb3JlbWFw
+X25vcG9zdCByZXR1cm4gTlVMTCB3aGVuIHRoZSBhcmNoIGRvZXNuJ3QgaGF2ZSAKdGhlIHJpZ2h0
+IHNlbWFudGljLgoKVGhlIGRyaXZlciB0aGFuIGNhbiAqY2hvc2UqIHRvIGVpdGhlciBzaWxlbnRs
+eSBmYWxsYmFjayB0byBpb3JlbWFwLAp3aGljaCBoYXMgc2VydmVkIHVzIHdlbGwgZm9yIGEgbG9u
+ZyB0aW1lIGRlc3BpdGUgYmVpbmcgdGhlb3JpY2FsbHkgaW4KdmlvbGF0aW9uIG9mIHRoZSBzcGVj
+LCBvciBkbyBmdW5ueSB0aGluZ3MgbGlrZSByZWFkIGJhY2sgc29tZSByZWdpc3RlcgphZnRlciBl
+dmVyeSBjb25maWcgd3JpdGUgdG8gZW5zdXJlIG9yZGVyaW5nIGV0Yy4uLgoKSSBtdWNoIHByZWZl
+ciB0aGF0IGFwcHJvYWNoIHRoYW4gaGF2aW5nIHNvbWUgZ2VuZXJpYyBpb3JlbWFwIGZ1bmN0aW9u
+CnRoYXQgZXhwb3NlcyBhIHNlbWFudGljIHRoYXQgc2lsZW50bHkgcHJvdmlkZXMgYSB3ZWFrZXIg
+b25lIG9uIHNvbWUKYXJjaGl0ZWN0dXJlLgoKQXQgbGVhc3Qgd2UgbWFrZSB0aGUgZmFpbHVyZSBl
+eHBsaWNpdCwgYW5kIHRoZSBkcml2ZXIgY2FuIHRha2UKYWx0ZXJuYXRlIChwb3NzaWJseSBzdWIt
+b3B0aW1hbCkgYWN0aW9uIGlmIGl0IGNob29zZXMgdG8gZG8gc28uCgpDaGVlcnMsCkJlbi4KCgpf
+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0t
+a2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcK
+aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2Vy
+bmVsCg==
diff --git a/a/content_digest b/N1/content_digest
index c9a12cc..6652409 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -30,45 +30,59 @@
   Catalin Marinas <catalin.marinas@arm.com>
   Matt Turner <mattst88@gmail.com>
   Haavard Skinnemoen <hskinnemoen@gmail.com>
- " Fenghua Yu <fenghua.yu>\0"
+  Fenghua Yu <fenghua.yu@intel.com>
+  James Hogan <james.hogan@imgtec.com>
+  Chris Metcalf <cmetcalf@mellanox.com>
+  Arnd Bergmann <arnd@arndb.de>
+  Heiko Carstens <heiko.carstens@de.ibm.com>
+  Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+  Mikael Starvik <starvik@axis.com>
+  Ivan Kokshaysky <ink@jurassic.park.msu.ru>
+  Bjorn Helgaas <bhelgaas@google.com>
+  Stafford Horne <shorne@gmail.com>
+  linux-arm-kernel@lists.infradead.org
+  Richard Henderson <rth@twiddle.net>
+  Chris Zankel <chris@zankel.net>
+  Michal Simek <monstr@monstr.eu>
+  Tony Luck <tony.luck@intel.com>
+  Vineet Gupta <vgupta@synopsys.com>
+  linux-kernel@vger.kernel.org
+  Ralf Baechle <ralf@linux-mips.org>
+  Richard Kuo <rkuo@codeaurora.org>
+  Niklas Cassel <nks@flawful.org>
+  Luis R. Rodriguez <mcgrof@kernel.org>
+  Martin Schwidefsky <schwidefsky@de.ibm.com>
+  Ley Foon Tan <lftan@altera.com>
+ " David S. Miller <davem@davemloft.net>\0"
  "\00:1\0"
  "b\0"
- "On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:\n"
- "> default implementation should fail if it's not supportable on all\n"
- "> architectures.\302\240 However, when we have existing drivers using an\n"
- "> interface that doesn't provide the semantics they already require,\n"
- "> then it makes no sense to effectively break these drivers on a range\n"
- "> of existing architectures.\n"
- "> \n"
- "> The question really is - what's the best way to solve the problem\n"
- "> with\n"
- "> existing drivers without breaking them.\302\240 I suspect that, sadly, the\n"
- "> only realistic way forward here is via the litter-drivers-with-ifdefs\n"
- "> approach since you don't like providing a default implementation that\n"
- "> is compatible with what these drivers are already doing.\n"
- "\n"
- "Then make ioremap_nopost return NULL when the arch doesn't have \n"
- "the right semantic.\n"
- "\n"
- "The driver than can *chose* to either silently fallback to ioremap,\n"
- "which has served us well for a long time despite being theorically in\n"
- "violation of the spec, or do funny things like read back some register\n"
- "after every config write to ensure ordering etc...\n"
- "\n"
- "I much prefer that approach than having some generic ioremap function\n"
- "that exposes a semantic that silently provides a weaker one on some\n"
- "architecture.\n"
- "\n"
- "At least we make the failure explicit, and the driver can take\n"
- "alternate (possibly sub-optimal) action if it chooses to do so.\n"
- "\n"
- "Cheers,\n"
- "Ben.\n"
- "\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
+ "T24gV2VkLCAyMDE3LTA0LTEyIGF0IDEyOjMxICswMTAwLCBSdXNzZWxsIEtpbmcgLSBBUk0gTGlu\n"
+ "dXggd3JvdGU6Cj4gZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZmFpbCBpZiBpdCdzIG5v\n"
+ "dCBzdXBwb3J0YWJsZSBvbiBhbGwKPiBhcmNoaXRlY3R1cmVzLsKgIEhvd2V2ZXIsIHdoZW4gd2Ug\n"
+ "aGF2ZSBleGlzdGluZyBkcml2ZXJzIHVzaW5nIGFuCj4gaW50ZXJmYWNlIHRoYXQgZG9lc24ndCBw\n"
+ "cm92aWRlIHRoZSBzZW1hbnRpY3MgdGhleSBhbHJlYWR5IHJlcXVpcmUsCj4gdGhlbiBpdCBtYWtl\n"
+ "cyBubyBzZW5zZSB0byBlZmZlY3RpdmVseSBicmVhayB0aGVzZSBkcml2ZXJzIG9uIGEgcmFuZ2UK\n"
+ "PiBvZiBleGlzdGluZyBhcmNoaXRlY3R1cmVzLgo+IAo+IFRoZSBxdWVzdGlvbiByZWFsbHkgaXMg\n"
+ "LSB3aGF0J3MgdGhlIGJlc3Qgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtCj4gd2l0aAo+IGV4aXN0\n"
+ "aW5nIGRyaXZlcnMgd2l0aG91dCBicmVha2luZyB0aGVtLsKgIEkgc3VzcGVjdCB0aGF0LCBzYWRs\n"
+ "eSwgdGhlCj4gb25seSByZWFsaXN0aWMgd2F5IGZvcndhcmQgaGVyZSBpcyB2aWEgdGhlIGxpdHRl\n"
+ "ci1kcml2ZXJzLXdpdGgtaWZkZWZzCj4gYXBwcm9hY2ggc2luY2UgeW91IGRvbid0IGxpa2UgcHJv\n"
+ "dmlkaW5nIGEgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiB0aGF0Cj4gaXMgY29tcGF0aWJsZSB3aXRo\n"
+ "IHdoYXQgdGhlc2UgZHJpdmVycyBhcmUgYWxyZWFkeSBkb2luZy4KClRoZW4gbWFrZSBpb3JlbWFw\n"
+ "X25vcG9zdCByZXR1cm4gTlVMTCB3aGVuIHRoZSBhcmNoIGRvZXNuJ3QgaGF2ZSAKdGhlIHJpZ2h0\n"
+ "IHNlbWFudGljLgoKVGhlIGRyaXZlciB0aGFuIGNhbiAqY2hvc2UqIHRvIGVpdGhlciBzaWxlbnRs\n"
+ "eSBmYWxsYmFjayB0byBpb3JlbWFwLAp3aGljaCBoYXMgc2VydmVkIHVzIHdlbGwgZm9yIGEgbG9u\n"
+ "ZyB0aW1lIGRlc3BpdGUgYmVpbmcgdGhlb3JpY2FsbHkgaW4KdmlvbGF0aW9uIG9mIHRoZSBzcGVj\n"
+ "LCBvciBkbyBmdW5ueSB0aGluZ3MgbGlrZSByZWFkIGJhY2sgc29tZSByZWdpc3RlcgphZnRlciBl\n"
+ "dmVyeSBjb25maWcgd3JpdGUgdG8gZW5zdXJlIG9yZGVyaW5nIGV0Yy4uLgoKSSBtdWNoIHByZWZl\n"
+ "ciB0aGF0IGFwcHJvYWNoIHRoYW4gaGF2aW5nIHNvbWUgZ2VuZXJpYyBpb3JlbWFwIGZ1bmN0aW9u\n"
+ "CnRoYXQgZXhwb3NlcyBhIHNlbWFudGljIHRoYXQgc2lsZW50bHkgcHJvdmlkZXMgYSB3ZWFrZXIg\n"
+ "b25lIG9uIHNvbWUKYXJjaGl0ZWN0dXJlLgoKQXQgbGVhc3Qgd2UgbWFrZSB0aGUgZmFpbHVyZSBl\n"
+ "eHBsaWNpdCwgYW5kIHRoZSBkcml2ZXIgY2FuIHRha2UKYWx0ZXJuYXRlIChwb3NzaWJseSBzdWIt\n"
+ "b3B0aW1hbCkgYWN0aW9uIGlmIGl0IGNob29zZXMgdG8gZG8gc28uCgpDaGVlcnMsCkJlbi4KCgpf\n"
+ "X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0t\n"
+ "a2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcK\n"
+ "aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2Vy\n"
+ bmVsCg==
 
-b04edaf58a924edac0833da6861de0c7e9ed343b99371fcd7c3ebf2d76251653
+e2d71e53c63578fff6b13a0f826a3928ad7a2930118ccf84079cecc08a448e89

diff --git a/a/1.txt b/N2/1.txt
index aaf62a2..cc0473a 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -1,13 +1,13 @@
 On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:
 > default implementation should fail if it's not supportable on all
-> architectures.  However, when we have existing drivers using an
+> architectures.? However, when we have existing drivers using an
 > interface that doesn't provide the semantics they already require,
 > then it makes no sense to effectively break these drivers on a range
 > of existing architectures.
 > 
 > The question really is - what's the best way to solve the problem
 > with
-> existing drivers without breaking them.  I suspect that, sadly, the
+> existing drivers without breaking them.? I suspect that, sadly, the
 > only realistic way forward here is via the litter-drivers-with-ifdefs
 > approach since you don't like providing a default implementation that
 > is compatible with what these drivers are already doing.
@@ -29,9 +29,3 @@ alternate (possibly sub-optimal) action if it chooses to do so.
 
 Cheers,
 Ben.
-
-
-_______________________________________________
-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/N2/content_digest
index c9a12cc..7c7cd07 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -3,46 +3,22 @@
  "ref\020170411140857.GA6821@red-moon\0"
  "ref\01491952371.7236.22.camel@kernel.crashing.org\0"
  "ref\020170412113124.GZ17774@n2100.armlinux.org.uk\0"
- "From\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0"
- "Subject\0Re: [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings\0"
+ "From\0benh@kernel.crashing.org (Benjamin Herrenschmidt)\0"
+ "Subject\0[PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings\0"
  "Date\0Wed, 12 Apr 2017 23:51:59 +1000\0"
- "To\0Russell King - ARM Linux <linux@armlinux.org.uk>\0"
- "Cc\0Jonas Bonn <jonas@southpole.se>"
-  Rich Felker <dalias@libc.org>
-  linux-pci@vger.kernel.org
-  Will Deacon <will.deacon@arm.com>
-  David Howells <dhowells@redhat.com>
-  Max Filippov <jcmvbkbc@gmail.com>
-  Paul Mackerras <paulus@samba.org>
-  Huacai Chen <chenhc@lemote.com>
-  Guan Xuetao <gxt@mprc.pku.edu.cn>
-  Thomas Gleixner <tglx@linutronix.de>
-  Hans-Christian Egtvedt <egtvedt@samfundet.no>
-  linux-arch@vger.kernel.org
-  Jesper Nilsson <jesper.nilsson@axis.com>
-  Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-  Yoshinori Sato <ysato@users.sourceforge.jp>
-  Michael Ellerman <mpe@ellerman.id.au>
-  Helge Deller <deller@gmx.de>
-  James E.J. Bottomley <jejb@parisc-linux.org>
-  Ingo Molnar <mingo@redhat.com>
-  Geert Uytterhoeven <geert@linux-m68k.org>
-  Catalin Marinas <catalin.marinas@arm.com>
-  Matt Turner <mattst88@gmail.com>
-  Haavard Skinnemoen <hskinnemoen@gmail.com>
- " Fenghua Yu <fenghua.yu>\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Wed, 2017-04-12 at 12:31 +0100, Russell King - ARM Linux wrote:\n"
  "> default implementation should fail if it's not supportable on all\n"
- "> architectures.\302\240 However, when we have existing drivers using an\n"
+ "> architectures.? However, when we have existing drivers using an\n"
  "> interface that doesn't provide the semantics they already require,\n"
  "> then it makes no sense to effectively break these drivers on a range\n"
  "> of existing architectures.\n"
  "> \n"
  "> The question really is - what's the best way to solve the problem\n"
  "> with\n"
- "> existing drivers without breaking them.\302\240 I suspect that, sadly, the\n"
+ "> existing drivers without breaking them.? I suspect that, sadly, the\n"
  "> only realistic way forward here is via the litter-drivers-with-ifdefs\n"
  "> approach since you don't like providing a default implementation that\n"
  "> is compatible with what these drivers are already doing.\n"
@@ -63,12 +39,6 @@
  "alternate (possibly sub-optimal) action if it chooses to do so.\n"
  "\n"
  "Cheers,\n"
- "Ben.\n"
- "\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
+ Ben.
 
-b04edaf58a924edac0833da6861de0c7e9ed343b99371fcd7c3ebf2d76251653
+c181503534352e61b352630043fd3eb5cb8608e7c29442da65ae876707f0d693

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.