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.