diff for duplicates of <3538381.vOsx75UXVU@wuerfel>

diff --git a/a/1.txt b/N1/1.txt
index 9784ade..d220714 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,84 +1,112 @@
-T24gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTYgNDoyMDo1NSBQTSBDRVNUIEdhYnJpZWxl
-IFBhb2xvbmkgd3JvdGU6Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gRnJvbTog
-emhpY2hhbmcgW21haWx0bzp6aGljaGFuZy55dWFuMDJAZ21haWwuY29tXQo+ID4gT24gMjAxNuW5
-tDA55pyIMTXml6UgMjA6MjQsIEFybmQgQmVyZ21hbm4gd3JvdGU6Cj4gPiA+IE9uIFRodXJzZGF5
-LCBTZXB0ZW1iZXIgMTUsIDIwMTYgMTI6MDU6NTEgUE0gQ0VTVCBHYWJyaWVsZSBQYW9sb25pCj4g
-PiB3cm90ZToKPiA+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gPj4+IE9uIFRo
-dXJzZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTYgODowMjoyNyBBTSBDRVNUIEdhYnJpZWxlIFBhb2xv
-bmkKPiA+IHdyb3RlOgo+ID4gPj4gSSB0aGluayB0aGF0IG1heWJlIGhhdmluZyB0aGUgMToxIHJh
-bmdlIG1hcHBpbmcgZG9lc24ndAo+ID4gPj4gcmVmbGVjdCB3ZWxsIHRoZSByZWFsaXR5IGJ1dCBp
-dCBpcyB0aGUgbGVzcyBwYWluZnVsCj4gPiA+PiBzb2x1dGlvbi4uLgo+ID4gPj4KPiA+ID4+IFdo
-YXQncyB5b3VyIHZpZXc/Cj4gPiA+Cj4gPiA+IFdlIGNhbiBjaGVjayB0aGUgJ2knIGJpdCBmb3Ig
-SS9PIHNwYWNlIGluIG9mX2J1c19pc2FfZ2V0X2ZsYWdzLAo+ID4gPiBhbmQgdGhhdCBzaG91bGQg
-YmUgZW5vdWdoIHRvIHRyYW5zbGF0ZSB0aGUgSS9PIHBvcnQgbnVtYmVyLgo+ID4gPgo+ID4gPiBU
-aGUgb25seSBwYXJ0IHdlIG5lZWQgdG8gY2hhbmdlIGhlcmUgaXMgdG8gbm90IGdvIHRocm91Z2gK
-PiA+ID4gdGhlIGNyYXp5IGNvbnZlcnNpb24gYWxsIHRoZSB3YXkgZnJvbSBQQ0kgSS9PIHNwYWNl
-IHRvIGEKPiA+ID4gcGh5c2ljYWwgYWRkcmVzcyBhbmQgYmFjayB0byBhIChsb2dpY2FsKSBwb3J0
-IG51bWJlcgo+ID4gPiB0aGF0IHdlIGRvIHRvZGF5IHdpdGggb2ZfdHJhbnNsYXRlX2FkZHJlc3Mv
-cGNpX2FkZHJlc3NfdG9fcGlvLgo+ID4gPgo+ID4gU29ycnkgZm9yIHRoZSBsYXRlIHJlc3BvbnNl
-ISBTZXZlcmFsIGRheXMnIGxlYXZlLi4uLgo+ID4gRG8geW91IHdhbnQgdG8gYnlwYXNzIG9mX3Ry
-YW5zbGF0ZV9hZGRyZXNzIGFuZCBwY2lfYWRkcmVzc190b19waW8gZm9yCj4gPiB0aGUgcmVnaXN0
-ZXJlZCBzcGVjaWZpYyBQSU8/Cj4gPiBJIHRoaW5rIHRoZSBieXBhc3MgZm9yIG9mX3RyYW5zbGF0
-ZV9hZGRyZXNzIGlzIG9rLCBidXQgd29ycnkgc29tZSBuZXcKPiA+IGlzc3VlcyB3aWxsIGVtZXJn
-ZSB3aXRob3V0IHRoZQo+ID4gY29udmVyc2lvbiBiZXR3ZWVuIHBoeXNpY2FsIGFkZHJlc3MgYW5k
-IGxvZ2ljYWwvbGludXggcG9ydCBudW1iZXIuCgpUaGUgc2FtZSBmdW5jdGlvbiB0aGF0IGhhbmRs
-ZXMgdGhlIG5vbi10cmFuc2xhdGVkIHJlZ2lvbiB3b3VsZApkbyB0aGF0IGNvbnZlcnNpb24uCgo+
-ID4gV2hlbiBQQ0kgaG9zdCBicmlkZ2Ugd2hpY2ggc3VwcG9ydCBJTyBvcGVyYXRpb25zIGlzIGNv
-bmZpZ3VyZWQgYW5kCj4gPiBlbmFibGVkLCB0aGUgcGNpX2FkZHJlc3NfdG9fcGlvIHdpbGwKPiA+
-IHBvcHVsYXRlIHRoZSBsb2dpY2FsIElPIHJhbmdlIGZyb20gWkVSTyBmb3IgdGhlIGZpcnN0IGhv
-c3QgYnJpZGdlLiBPdXIKPiA+IExQQyB3aWxsIGFsc28gdXNlIHBhcnQgb2YgdGhlIElPIHJhbmdl
-Cj4gPiBzdGFydGVkIGZyb20gWkVSTy4gSXQgd2lsbCBtYWtlIGluL291dCBlbnRlciB0aGUgd3Jv
-bmcgYnJhbmNoIHBvc3NpYmx5Lgo+ID4gCj4gPiBJbiBWMiwgdGhlIDAgLSAweDEwMDAgbG9naWNh
-bCBJTyByYW5nZSBpcyByZXNlcnZlZCBmb3IgTFBDIHVzZSBvbmx5Lgo+ID4gQnV0IGl0IHNlZW1z
-IG5vdCBzbyBnb29kLiBJbiB0aGlzIHdheSwKPiA+IFBDSSBoYXMgbm8gY2hhbmNlIHRvIHVzZSBs
-b3cgNEsgSU8gcmFuZ2UobG9naWNhbCkuCj4gPiAKPiA+IFNvLCBpbiBWMywgYXBwbHlpbmcgdGhl
-IGNvbnZlcnNpb24gZnJvbSBwaHlzaWNhbC9jcHUgYWRkcmVzcyB0bwo+ID4gbG9naWNhbC9saW51
-eCBJTyBwb3J0IGZvciBhbnkgSU8gcmFuZ2VzLAo+ID4gaW5jbHVkaW5nIHRoZSBMUEMsIGJ1dCBy
-ZWNvcmRlZCB0aGUgbG9naWNhbCBJTyByYW5nZSBmb3IgTFBDLiBXaGVuCj4gPiBjYWxsaW5nIGlu
-L291dCB3aXRoIGEgbG9naWNhbCBwb3J0IGFkZHJlc3MsCj4gPiB3ZSBjYW4gY2hlY2sgdGhpcyBw
-b3J0IGZhbGwgaW50byBMUEMgbG9naWNhbCBJTyByYW5nZSBhbmQgZ2V0IGJhY2sgdGhlCj4gPiBy
-ZWFsIElPLgoKUmlnaHQsIGFuZCB0aGUgc2FtZSB0cmFuc2xhdGlvbiBjYW4gYmUgdXNlZCBpbiBf
-X29mX2FkZHJlc3NfdG9fcmVzb3VyY2UoKQpnb2luZyB0aGUgb3Bwb3NpdGUgd2F5LgoKPiA+IERv
-IHlvdSBoYXZlIGZ1cnRoZXIgY29tbWVudHMgYWJvdXQgdGhpcz8/Cj4gCj4gSSB0aGluayB0aGVy
-ZSBhcmUgdHdvIHNlcGFyYXRlIGlzc3VlcyB0byBiZSBkaXNjdXNzZWQ6Cj4gCj4gVGhlIGZpcnN0
-IGlzc3VlIGlzIGFib3V0IGhhdmluZyBvZl90cmFuc2xhdGVfYWRkcmVzcyBmYWlsaW5nIGR1ZSB0
-bwo+ICJyYW5nZSIgbWlzc2luZy4gQWJvdXQgdGhpcyBBcm5kIHN1Z2dlc3RlZCB0aGF0IGl0IGlz
-IG5vdCBhcHByb3ByaWF0ZQo+IHRvIGhhdmUgYSByYW5nZSBkZXNjcmliaW5nIGEgYnJpZGdlIDE6
-MSBtYXBwaW5nIGFuZCB0aGlzIHdhcyBkaXNjdXNzZWQKPiBiZWZvcmUgaW4gdGhpcyB0aHJlYWQu
-IEFybmQgaGFkIGEgc3VnZ2VzdGlvbiBhYm91dCB0aGlzIChzZWUgYmVsb3cpIAo+IGhvd2V2ZXIg
-KGxvb2tpbmcgdHdpY2UgYXQgdGhlIGNvZGUpIGl0IHNlZW1zIHRvIG1lIHRoYXQgc3VjaCBzb2x1
-dGlvbiAKPiB3b3VsZCBsZWFkIHRvIHF1aXRlIHNvbWUgZHVwbGljYXRpb24gZnJvbSBfX29mX3Ry
-YW5zbGF0ZV9hZGRyZXNzKCkKPiBpbiBvcmRlciB0byByZXRyaWV2ZSB0aGUgYWN0dWFsIGFkZHIg
-ZnJvbSBkdC4uLgoKSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGR1cGxpY2F0ZSBtdWNoLCB3ZSBj
-YW4gcHJvYmFibHkgc2FmZWx5CmFzc3VtZSB0aGF0IHRoZXJlIGFyZSBubyBub250cml2aWFsIHJh
-bmdlcyBpbiBkZXZpY2VzIGJlbG93IHRoZSBMUEMKbm9kZSwgc28gd2UganVzdCB3YWxrIHVwIHRo
-ZSBidXMgdG8gc2VlIGlmIHRoZSBub2RlIGlzIGEgY2hpbGQKKG9yIHBvc3NpYmx5IGdyYW5kY2hp
-bGQgZXRjKSBvZiB0aGUgTFBDIGJ1cywgYW5kIHRyZWF0IGFueSBJTyBwb3J0Cm51bWJlciB1bmRl
-ciB0aGVyZSBhcyBhIHBoeXNpY2FsIHBvcnQgbnVtYmVyLCB3aGljaCBoYXMgYSBrbm93bgpvZmZz
-ZXQgZnJvbSB0aGUgTGludXggSS9PIHBvcnQgbnVtYmVyLgoKPiBJIHRoaW5rIGV4dGVuZGluZyBv
-Zl9lbXB0eV9yYW5nZXNfcXVpcmsoKSBtYXkgYmUgYSByZWFzb25hYmxlIHNvbHV0aW9uLgo+IFdo
-YXQgZG8geW91IHRoaW5rIEFybmQ/CgpJIGRvbid0IHJlYWxseSBsaWtlIHRoYXQgaWRlYSwgdGhh
-dCBxdWlyayBpcyBtZWFudCB0byB3b3JrIGFyb3VuZApicm9rZW4gRFRzLCBidXQgd2UgY2FuIGp1
-c3QgbWFrZSB0aGUgRFQgdmFsaWQgYW5kIGltcGxlbWVudCB0aGUKY29kZSBwcm9wZXJseS4KCj4g
-VGhlIHNlY29uZCBpc3N1ZSBpcyBhIGNvbmZsaWN0IGJldHdlZW4gY3B1IGFkZHJlc3NlcyB1c2Vk
-IGJ5IHRoZSBMUEMKPiBjb250cm9sbGVyIGFuZCBpL28gdG9rZW5zIGZyb20gcGNpIGVuZHBvaW50
-cy4KPiAKPiBBYm91dCB0aGlzIHdoYXQgaWYgd2UgbW9kaWZ5IGFybW42NF9leHRpb19vcHMgdG8g
-aGF2ZSBhIGxpc3Qgb2YgcmFuZ2VzCj4gcmF0aGVyIHRoYW4gb25seSBvbmUgcmFuZ2UgKG5vdyB3
-ZSBoYXZlIGp1c3Qgc3RhcnQvZW5kKTsgdGhlbiBpbiB0aGUKPiBMUEMgZHJpdmVyIHdlIGNhbiBz
-Y2FuIHRoZSBMUEMgY2hpbGQgZGV2aWNlcyBhbmQgCj4gMSkgcG9wdWxhdGUgc3VjaCBsaXN0IG9m
-IHJhbmdlcwo+IDIpIGNhbGwgcGNpX3JlZ2lzdGVyX2lvX3JhbmdlIGZvciBzdWNoIHJhbmdlcwoK
-U2Nhbm5pbmcgdGhlIGNoaWxkIGRldmljZXMgc291bmRzIHJlYWxseSB3cm9uZywgcGxlYXNlIHJl
-Z2lzdGVyIGp1c3QKb25lIHJhbmdlIHRoYXQgY292ZXJzIHRoZSBidXMgdG8ga2VlcCB0aGUgd29y
-a2Fyb3VuZCBhcyBzaW1wbGUKYXMgcG9zc2libGUuCgo+IFRoZW4gd2hlbiBjYWxsaW5nIF9fb2Zf
-YWRkcmVzc190b19yZXNvdXJjZSB3ZSByZXRyaWV2ZSBJL08gdG9rZW5zIAo+IGZvciB0aGUgZGV2
-aWNlcyBvbiB0b3Agb2YgdGhlIExQQyBkcml2ZXIgYW5kIGluIHRoZSBJL08gYWNjZXNzb3JzCj4g
-d2UgY2FsbCBwY2lfcGlvX3RvX2FkZHJlc3MgdG8gZmlndXJlIG91dCB0aGUgY3B1IGFkZHJlc3Mg
-YW5kIGNvbXBhcmUKPiBpdCB0byB0aGUgbGlzdCBvZiByYW5nZXMgaW4gYXJtbjY0X2V4dGlvX29w
-cy4KPiAgIAo+IFdoYXQgYWJvdXQgdGhpcz8KClRoYXQgc2VlbXMgcmVhbGx5IGNvbXBsZXggZm9y
-IHNvbWV0aGluZyB0aGF0IGNhbiBiZSBxdWl0ZSBzaW1wbGUuClRoZSBvbmx5IHRoaW5nIHdlIG5l
-ZWQgdG8gd29ycnkgYWJvdXQgaXMgdGhhdCB0aGUgaW9fcmFuZ2VfbGlzdApjb250YWlucyBhbiBl
-bnRyeSBmb3IgdGhlIExQQyBidXMgc28gd2UgZG9uJ3QgY29uZmxpY3Qgd2l0aCB0aGUKUENJIGJ1
-c2VzLgoKCUFybmQKCglBcm5kCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
-X19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVs
-QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9s
-aXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==
+On Wednesday, September 21, 2016 4:20:55 PM CEST Gabriele Paoloni wrote:
+> > -----Original Message-----
+> > From: zhichang [mailto:zhichang.yuan02@gmail.com]
+> > On 2016年09月15日 20:24, Arnd Bergmann wrote:
+> > > On Thursday, September 15, 2016 12:05:51 PM CEST Gabriele Paoloni
+> > wrote:
+> > >>> -----Original Message-----
+> > >>> On Thursday, September 15, 2016 8:02:27 AM CEST Gabriele Paoloni
+> > wrote:
+> > >> I think that maybe having the 1:1 range mapping doesn't
+> > >> reflect well the reality but it is the less painful
+> > >> solution...
+> > >>
+> > >> What's your view?
+> > >
+> > > We can check the 'i' bit for I/O space in of_bus_isa_get_flags,
+> > > and that should be enough to translate the I/O port number.
+> > >
+> > > The only part we need to change here is to not go through
+> > > the crazy conversion all the way from PCI I/O space to a
+> > > physical address and back to a (logical) port number
+> > > that we do today with of_translate_address/pci_address_to_pio.
+> > >
+> > Sorry for the late response! Several days' leave....
+> > Do you want to bypass of_translate_address and pci_address_to_pio for
+> > the registered specific PIO?
+> > I think the bypass for of_translate_address is ok, but worry some new
+> > issues will emerge without the
+> > conversion between physical address and logical/linux port number.
+
+The same function that handles the non-translated region would
+do that conversion.
+
+> > When PCI host bridge which support IO operations is configured and
+> > enabled, the pci_address_to_pio will
+> > populate the logical IO range from ZERO for the first host bridge. Our
+> > LPC will also use part of the IO range
+> > started from ZERO. It will make in/out enter the wrong branch possibly.
+> > 
+> > In V2, the 0 - 0x1000 logical IO range is reserved for LPC use only.
+> > But it seems not so good. In this way,
+> > PCI has no chance to use low 4K IO range(logical).
+> > 
+> > So, in V3, applying the conversion from physical/cpu address to
+> > logical/linux IO port for any IO ranges,
+> > including the LPC, but recorded the logical IO range for LPC. When
+> > calling in/out with a logical port address,
+> > we can check this port fall into LPC logical IO range and get back the
+> > real IO.
+
+Right, and the same translation can be used in __of_address_to_resource()
+going the opposite way.
+
+> > Do you have further comments about this??
+> 
+> I think there are two separate issues to be discussed:
+> 
+> The first issue is about having of_translate_address failing due to
+> "range" missing. About this Arnd suggested that it is not appropriate
+> to have a range describing a bridge 1:1 mapping and this was discussed
+> before in this thread. Arnd had a suggestion about this (see below) 
+> however (looking twice at the code) it seems to me that such solution 
+> would lead to quite some duplication from __of_translate_address()
+> in order to retrieve the actual addr from dt...
+
+I don't think we need to duplicate much, we can probably safely
+assume that there are no nontrivial ranges in devices below the LPC
+node, so we just walk up the bus to see if the node is a child
+(or possibly grandchild etc) of the LPC bus, and treat any IO port
+number under there as a physical port number, which has a known
+offset from the Linux I/O port number.
+
+> I think extending of_empty_ranges_quirk() may be a reasonable solution.
+> What do you think Arnd?
+
+I don't really like that idea, that quirk is meant to work around
+broken DTs, but we can just make the DT valid and implement the
+code properly.
+
+> The second issue is a conflict between cpu addresses used by the LPC
+> controller and i/o tokens from pci endpoints.
+> 
+> About this what if we modify armn64_extio_ops to have a list of ranges
+> rather than only one range (now we have just start/end); then in the
+> LPC driver we can scan the LPC child devices and 
+> 1) populate such list of ranges
+> 2) call pci_register_io_range for such ranges
+
+Scanning the child devices sounds really wrong, please register just
+one range that covers the bus to keep the workaround as simple
+as possible.
+
+> Then when calling __of_address_to_resource we retrieve I/O tokens 
+> for the devices on top of the LPC driver and in the I/O accessors
+> we call pci_pio_to_address to figure out the cpu address and compare
+> it to the list of ranges in armn64_extio_ops.
+>   
+> What about this?
+
+That seems really complex for something that can be quite simple.
+The only thing we need to worry about is that the io_range_list
+contains an entry for the LPC bus so we don't conflict with the
+PCI buses.
+
+	Arnd
+
+	Arnd
+
+_______________________________________________
+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 0a85208..a9329be 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -16,98 +16,126 @@
   linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
   Yuanzhichang <yuanzhichang@hisilicon.com>
   Linuxarm <linuxarm@huawei.com>
- " xuwei \\(O\\) <xuwei5@hisilicon.com>"
+  xuwei (O) <xuwei5@hisilicon.com>
   linux-serial@vger.kernel.org <linux-serial@vger.kernel.org>
   zhichang <zhichang.yuan02@gmail.com>
   zourongrong@gmail.com <zourongrong@gmail.com>
   liviu.dudau@arm.com <liviu.dudau@arm.com>
   kantyzc@163.com <kantyzc@163.com>
- " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0"
+ " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infr>\0"
  "\00:1\0"
  "b\0"
- "T24gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTYgNDoyMDo1NSBQTSBDRVNUIEdhYnJpZWxl\n"
- "IFBhb2xvbmkgd3JvdGU6Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gRnJvbTog\n"
- "emhpY2hhbmcgW21haWx0bzp6aGljaGFuZy55dWFuMDJAZ21haWwuY29tXQo+ID4gT24gMjAxNuW5\n"
- "tDA55pyIMTXml6UgMjA6MjQsIEFybmQgQmVyZ21hbm4gd3JvdGU6Cj4gPiA+IE9uIFRodXJzZGF5\n"
- "LCBTZXB0ZW1iZXIgMTUsIDIwMTYgMTI6MDU6NTEgUE0gQ0VTVCBHYWJyaWVsZSBQYW9sb25pCj4g\n"
- "PiB3cm90ZToKPiA+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gPj4+IE9uIFRo\n"
- "dXJzZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTYgODowMjoyNyBBTSBDRVNUIEdhYnJpZWxlIFBhb2xv\n"
- "bmkKPiA+IHdyb3RlOgo+ID4gPj4gSSB0aGluayB0aGF0IG1heWJlIGhhdmluZyB0aGUgMToxIHJh\n"
- "bmdlIG1hcHBpbmcgZG9lc24ndAo+ID4gPj4gcmVmbGVjdCB3ZWxsIHRoZSByZWFsaXR5IGJ1dCBp\n"
- "dCBpcyB0aGUgbGVzcyBwYWluZnVsCj4gPiA+PiBzb2x1dGlvbi4uLgo+ID4gPj4KPiA+ID4+IFdo\n"
- "YXQncyB5b3VyIHZpZXc/Cj4gPiA+Cj4gPiA+IFdlIGNhbiBjaGVjayB0aGUgJ2knIGJpdCBmb3Ig\n"
- "SS9PIHNwYWNlIGluIG9mX2J1c19pc2FfZ2V0X2ZsYWdzLAo+ID4gPiBhbmQgdGhhdCBzaG91bGQg\n"
- "YmUgZW5vdWdoIHRvIHRyYW5zbGF0ZSB0aGUgSS9PIHBvcnQgbnVtYmVyLgo+ID4gPgo+ID4gPiBU\n"
- "aGUgb25seSBwYXJ0IHdlIG5lZWQgdG8gY2hhbmdlIGhlcmUgaXMgdG8gbm90IGdvIHRocm91Z2gK\n"
- "PiA+ID4gdGhlIGNyYXp5IGNvbnZlcnNpb24gYWxsIHRoZSB3YXkgZnJvbSBQQ0kgSS9PIHNwYWNl\n"
- "IHRvIGEKPiA+ID4gcGh5c2ljYWwgYWRkcmVzcyBhbmQgYmFjayB0byBhIChsb2dpY2FsKSBwb3J0\n"
- "IG51bWJlcgo+ID4gPiB0aGF0IHdlIGRvIHRvZGF5IHdpdGggb2ZfdHJhbnNsYXRlX2FkZHJlc3Mv\n"
- "cGNpX2FkZHJlc3NfdG9fcGlvLgo+ID4gPgo+ID4gU29ycnkgZm9yIHRoZSBsYXRlIHJlc3BvbnNl\n"
- "ISBTZXZlcmFsIGRheXMnIGxlYXZlLi4uLgo+ID4gRG8geW91IHdhbnQgdG8gYnlwYXNzIG9mX3Ry\n"
- "YW5zbGF0ZV9hZGRyZXNzIGFuZCBwY2lfYWRkcmVzc190b19waW8gZm9yCj4gPiB0aGUgcmVnaXN0\n"
- "ZXJlZCBzcGVjaWZpYyBQSU8/Cj4gPiBJIHRoaW5rIHRoZSBieXBhc3MgZm9yIG9mX3RyYW5zbGF0\n"
- "ZV9hZGRyZXNzIGlzIG9rLCBidXQgd29ycnkgc29tZSBuZXcKPiA+IGlzc3VlcyB3aWxsIGVtZXJn\n"
- "ZSB3aXRob3V0IHRoZQo+ID4gY29udmVyc2lvbiBiZXR3ZWVuIHBoeXNpY2FsIGFkZHJlc3MgYW5k\n"
- "IGxvZ2ljYWwvbGludXggcG9ydCBudW1iZXIuCgpUaGUgc2FtZSBmdW5jdGlvbiB0aGF0IGhhbmRs\n"
- "ZXMgdGhlIG5vbi10cmFuc2xhdGVkIHJlZ2lvbiB3b3VsZApkbyB0aGF0IGNvbnZlcnNpb24uCgo+\n"
- "ID4gV2hlbiBQQ0kgaG9zdCBicmlkZ2Ugd2hpY2ggc3VwcG9ydCBJTyBvcGVyYXRpb25zIGlzIGNv\n"
- "bmZpZ3VyZWQgYW5kCj4gPiBlbmFibGVkLCB0aGUgcGNpX2FkZHJlc3NfdG9fcGlvIHdpbGwKPiA+\n"
- "IHBvcHVsYXRlIHRoZSBsb2dpY2FsIElPIHJhbmdlIGZyb20gWkVSTyBmb3IgdGhlIGZpcnN0IGhv\n"
- "c3QgYnJpZGdlLiBPdXIKPiA+IExQQyB3aWxsIGFsc28gdXNlIHBhcnQgb2YgdGhlIElPIHJhbmdl\n"
- "Cj4gPiBzdGFydGVkIGZyb20gWkVSTy4gSXQgd2lsbCBtYWtlIGluL291dCBlbnRlciB0aGUgd3Jv\n"
- "bmcgYnJhbmNoIHBvc3NpYmx5Lgo+ID4gCj4gPiBJbiBWMiwgdGhlIDAgLSAweDEwMDAgbG9naWNh\n"
- "bCBJTyByYW5nZSBpcyByZXNlcnZlZCBmb3IgTFBDIHVzZSBvbmx5Lgo+ID4gQnV0IGl0IHNlZW1z\n"
- "IG5vdCBzbyBnb29kLiBJbiB0aGlzIHdheSwKPiA+IFBDSSBoYXMgbm8gY2hhbmNlIHRvIHVzZSBs\n"
- "b3cgNEsgSU8gcmFuZ2UobG9naWNhbCkuCj4gPiAKPiA+IFNvLCBpbiBWMywgYXBwbHlpbmcgdGhl\n"
- "IGNvbnZlcnNpb24gZnJvbSBwaHlzaWNhbC9jcHUgYWRkcmVzcyB0bwo+ID4gbG9naWNhbC9saW51\n"
- "eCBJTyBwb3J0IGZvciBhbnkgSU8gcmFuZ2VzLAo+ID4gaW5jbHVkaW5nIHRoZSBMUEMsIGJ1dCBy\n"
- "ZWNvcmRlZCB0aGUgbG9naWNhbCBJTyByYW5nZSBmb3IgTFBDLiBXaGVuCj4gPiBjYWxsaW5nIGlu\n"
- "L291dCB3aXRoIGEgbG9naWNhbCBwb3J0IGFkZHJlc3MsCj4gPiB3ZSBjYW4gY2hlY2sgdGhpcyBw\n"
- "b3J0IGZhbGwgaW50byBMUEMgbG9naWNhbCBJTyByYW5nZSBhbmQgZ2V0IGJhY2sgdGhlCj4gPiBy\n"
- "ZWFsIElPLgoKUmlnaHQsIGFuZCB0aGUgc2FtZSB0cmFuc2xhdGlvbiBjYW4gYmUgdXNlZCBpbiBf\n"
- "X29mX2FkZHJlc3NfdG9fcmVzb3VyY2UoKQpnb2luZyB0aGUgb3Bwb3NpdGUgd2F5LgoKPiA+IERv\n"
- "IHlvdSBoYXZlIGZ1cnRoZXIgY29tbWVudHMgYWJvdXQgdGhpcz8/Cj4gCj4gSSB0aGluayB0aGVy\n"
- "ZSBhcmUgdHdvIHNlcGFyYXRlIGlzc3VlcyB0byBiZSBkaXNjdXNzZWQ6Cj4gCj4gVGhlIGZpcnN0\n"
- "IGlzc3VlIGlzIGFib3V0IGhhdmluZyBvZl90cmFuc2xhdGVfYWRkcmVzcyBmYWlsaW5nIGR1ZSB0\n"
- "bwo+ICJyYW5nZSIgbWlzc2luZy4gQWJvdXQgdGhpcyBBcm5kIHN1Z2dlc3RlZCB0aGF0IGl0IGlz\n"
- "IG5vdCBhcHByb3ByaWF0ZQo+IHRvIGhhdmUgYSByYW5nZSBkZXNjcmliaW5nIGEgYnJpZGdlIDE6\n"
- "MSBtYXBwaW5nIGFuZCB0aGlzIHdhcyBkaXNjdXNzZWQKPiBiZWZvcmUgaW4gdGhpcyB0aHJlYWQu\n"
- "IEFybmQgaGFkIGEgc3VnZ2VzdGlvbiBhYm91dCB0aGlzIChzZWUgYmVsb3cpIAo+IGhvd2V2ZXIg\n"
- "KGxvb2tpbmcgdHdpY2UgYXQgdGhlIGNvZGUpIGl0IHNlZW1zIHRvIG1lIHRoYXQgc3VjaCBzb2x1\n"
- "dGlvbiAKPiB3b3VsZCBsZWFkIHRvIHF1aXRlIHNvbWUgZHVwbGljYXRpb24gZnJvbSBfX29mX3Ry\n"
- "YW5zbGF0ZV9hZGRyZXNzKCkKPiBpbiBvcmRlciB0byByZXRyaWV2ZSB0aGUgYWN0dWFsIGFkZHIg\n"
- "ZnJvbSBkdC4uLgoKSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGR1cGxpY2F0ZSBtdWNoLCB3ZSBj\n"
- "YW4gcHJvYmFibHkgc2FmZWx5CmFzc3VtZSB0aGF0IHRoZXJlIGFyZSBubyBub250cml2aWFsIHJh\n"
- "bmdlcyBpbiBkZXZpY2VzIGJlbG93IHRoZSBMUEMKbm9kZSwgc28gd2UganVzdCB3YWxrIHVwIHRo\n"
- "ZSBidXMgdG8gc2VlIGlmIHRoZSBub2RlIGlzIGEgY2hpbGQKKG9yIHBvc3NpYmx5IGdyYW5kY2hp\n"
- "bGQgZXRjKSBvZiB0aGUgTFBDIGJ1cywgYW5kIHRyZWF0IGFueSBJTyBwb3J0Cm51bWJlciB1bmRl\n"
- "ciB0aGVyZSBhcyBhIHBoeXNpY2FsIHBvcnQgbnVtYmVyLCB3aGljaCBoYXMgYSBrbm93bgpvZmZz\n"
- "ZXQgZnJvbSB0aGUgTGludXggSS9PIHBvcnQgbnVtYmVyLgoKPiBJIHRoaW5rIGV4dGVuZGluZyBv\n"
- "Zl9lbXB0eV9yYW5nZXNfcXVpcmsoKSBtYXkgYmUgYSByZWFzb25hYmxlIHNvbHV0aW9uLgo+IFdo\n"
- "YXQgZG8geW91IHRoaW5rIEFybmQ/CgpJIGRvbid0IHJlYWxseSBsaWtlIHRoYXQgaWRlYSwgdGhh\n"
- "dCBxdWlyayBpcyBtZWFudCB0byB3b3JrIGFyb3VuZApicm9rZW4gRFRzLCBidXQgd2UgY2FuIGp1\n"
- "c3QgbWFrZSB0aGUgRFQgdmFsaWQgYW5kIGltcGxlbWVudCB0aGUKY29kZSBwcm9wZXJseS4KCj4g\n"
- "VGhlIHNlY29uZCBpc3N1ZSBpcyBhIGNvbmZsaWN0IGJldHdlZW4gY3B1IGFkZHJlc3NlcyB1c2Vk\n"
- "IGJ5IHRoZSBMUEMKPiBjb250cm9sbGVyIGFuZCBpL28gdG9rZW5zIGZyb20gcGNpIGVuZHBvaW50\n"
- "cy4KPiAKPiBBYm91dCB0aGlzIHdoYXQgaWYgd2UgbW9kaWZ5IGFybW42NF9leHRpb19vcHMgdG8g\n"
- "aGF2ZSBhIGxpc3Qgb2YgcmFuZ2VzCj4gcmF0aGVyIHRoYW4gb25seSBvbmUgcmFuZ2UgKG5vdyB3\n"
- "ZSBoYXZlIGp1c3Qgc3RhcnQvZW5kKTsgdGhlbiBpbiB0aGUKPiBMUEMgZHJpdmVyIHdlIGNhbiBz\n"
- "Y2FuIHRoZSBMUEMgY2hpbGQgZGV2aWNlcyBhbmQgCj4gMSkgcG9wdWxhdGUgc3VjaCBsaXN0IG9m\n"
- "IHJhbmdlcwo+IDIpIGNhbGwgcGNpX3JlZ2lzdGVyX2lvX3JhbmdlIGZvciBzdWNoIHJhbmdlcwoK\n"
- "U2Nhbm5pbmcgdGhlIGNoaWxkIGRldmljZXMgc291bmRzIHJlYWxseSB3cm9uZywgcGxlYXNlIHJl\n"
- "Z2lzdGVyIGp1c3QKb25lIHJhbmdlIHRoYXQgY292ZXJzIHRoZSBidXMgdG8ga2VlcCB0aGUgd29y\n"
- "a2Fyb3VuZCBhcyBzaW1wbGUKYXMgcG9zc2libGUuCgo+IFRoZW4gd2hlbiBjYWxsaW5nIF9fb2Zf\n"
- "YWRkcmVzc190b19yZXNvdXJjZSB3ZSByZXRyaWV2ZSBJL08gdG9rZW5zIAo+IGZvciB0aGUgZGV2\n"
- "aWNlcyBvbiB0b3Agb2YgdGhlIExQQyBkcml2ZXIgYW5kIGluIHRoZSBJL08gYWNjZXNzb3JzCj4g\n"
- "d2UgY2FsbCBwY2lfcGlvX3RvX2FkZHJlc3MgdG8gZmlndXJlIG91dCB0aGUgY3B1IGFkZHJlc3Mg\n"
- "YW5kIGNvbXBhcmUKPiBpdCB0byB0aGUgbGlzdCBvZiByYW5nZXMgaW4gYXJtbjY0X2V4dGlvX29w\n"
- "cy4KPiAgIAo+IFdoYXQgYWJvdXQgdGhpcz8KClRoYXQgc2VlbXMgcmVhbGx5IGNvbXBsZXggZm9y\n"
- "IHNvbWV0aGluZyB0aGF0IGNhbiBiZSBxdWl0ZSBzaW1wbGUuClRoZSBvbmx5IHRoaW5nIHdlIG5l\n"
- "ZWQgdG8gd29ycnkgYWJvdXQgaXMgdGhhdCB0aGUgaW9fcmFuZ2VfbGlzdApjb250YWlucyBhbiBl\n"
- "bnRyeSBmb3IgdGhlIExQQyBidXMgc28gd2UgZG9uJ3QgY29uZmxpY3Qgd2l0aCB0aGUKUENJIGJ1\n"
- "c2VzLgoKCUFybmQKCglBcm5kCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f\n"
- "X19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVs\n"
- "QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9s\n"
- aXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==
+ "On Wednesday, September 21, 2016 4:20:55 PM CEST Gabriele Paoloni wrote:\n"
+ "> > -----Original Message-----\n"
+ "> > From: zhichang [mailto:zhichang.yuan02@gmail.com]\n"
+ "> > On 2016\345\271\26409\346\234\21015\346\227\245 20:24, Arnd Bergmann wrote:\n"
+ "> > > On Thursday, September 15, 2016 12:05:51 PM CEST Gabriele Paoloni\n"
+ "> > wrote:\n"
+ "> > >>> -----Original Message-----\n"
+ "> > >>> On Thursday, September 15, 2016 8:02:27 AM CEST Gabriele Paoloni\n"
+ "> > wrote:\n"
+ "> > >> I think that maybe having the 1:1 range mapping doesn't\n"
+ "> > >> reflect well the reality but it is the less painful\n"
+ "> > >> solution...\n"
+ "> > >>\n"
+ "> > >> What's your view?\n"
+ "> > >\n"
+ "> > > We can check the 'i' bit for I/O space in of_bus_isa_get_flags,\n"
+ "> > > and that should be enough to translate the I/O port number.\n"
+ "> > >\n"
+ "> > > The only part we need to change here is to not go through\n"
+ "> > > the crazy conversion all the way from PCI I/O space to a\n"
+ "> > > physical address and back to a (logical) port number\n"
+ "> > > that we do today with of_translate_address/pci_address_to_pio.\n"
+ "> > >\n"
+ "> > Sorry for the late response! Several days' leave....\n"
+ "> > Do you want to bypass of_translate_address and pci_address_to_pio for\n"
+ "> > the registered specific PIO?\n"
+ "> > I think the bypass for of_translate_address is ok, but worry some new\n"
+ "> > issues will emerge without the\n"
+ "> > conversion between physical address and logical/linux port number.\n"
+ "\n"
+ "The same function that handles the non-translated region would\n"
+ "do that conversion.\n"
+ "\n"
+ "> > When PCI host bridge which support IO operations is configured and\n"
+ "> > enabled, the pci_address_to_pio will\n"
+ "> > populate the logical IO range from ZERO for the first host bridge. Our\n"
+ "> > LPC will also use part of the IO range\n"
+ "> > started from ZERO. It will make in/out enter the wrong branch possibly.\n"
+ "> > \n"
+ "> > In V2, the 0 - 0x1000 logical IO range is reserved for LPC use only.\n"
+ "> > But it seems not so good. In this way,\n"
+ "> > PCI has no chance to use low 4K IO range(logical).\n"
+ "> > \n"
+ "> > So, in V3, applying the conversion from physical/cpu address to\n"
+ "> > logical/linux IO port for any IO ranges,\n"
+ "> > including the LPC, but recorded the logical IO range for LPC. When\n"
+ "> > calling in/out with a logical port address,\n"
+ "> > we can check this port fall into LPC logical IO range and get back the\n"
+ "> > real IO.\n"
+ "\n"
+ "Right, and the same translation can be used in __of_address_to_resource()\n"
+ "going the opposite way.\n"
+ "\n"
+ "> > Do you have further comments about this??\n"
+ "> \n"
+ "> I think there are two separate issues to be discussed:\n"
+ "> \n"
+ "> The first issue is about having of_translate_address failing due to\n"
+ "> \"range\" missing. About this Arnd suggested that it is not appropriate\n"
+ "> to have a range describing a bridge 1:1 mapping and this was discussed\n"
+ "> before in this thread. Arnd had a suggestion about this (see below) \n"
+ "> however (looking twice at the code) it seems to me that such solution \n"
+ "> would lead to quite some duplication from __of_translate_address()\n"
+ "> in order to retrieve the actual addr from dt...\n"
+ "\n"
+ "I don't think we need to duplicate much, we can probably safely\n"
+ "assume that there are no nontrivial ranges in devices below the LPC\n"
+ "node, so we just walk up the bus to see if the node is a child\n"
+ "(or possibly grandchild etc) of the LPC bus, and treat any IO port\n"
+ "number under there as a physical port number, which has a known\n"
+ "offset from the Linux I/O port number.\n"
+ "\n"
+ "> I think extending of_empty_ranges_quirk() may be a reasonable solution.\n"
+ "> What do you think Arnd?\n"
+ "\n"
+ "I don't really like that idea, that quirk is meant to work around\n"
+ "broken DTs, but we can just make the DT valid and implement the\n"
+ "code properly.\n"
+ "\n"
+ "> The second issue is a conflict between cpu addresses used by the LPC\n"
+ "> controller and i/o tokens from pci endpoints.\n"
+ "> \n"
+ "> About this what if we modify armn64_extio_ops to have a list of ranges\n"
+ "> rather than only one range (now we have just start/end); then in the\n"
+ "> LPC driver we can scan the LPC child devices and \n"
+ "> 1) populate such list of ranges\n"
+ "> 2) call pci_register_io_range for such ranges\n"
+ "\n"
+ "Scanning the child devices sounds really wrong, please register just\n"
+ "one range that covers the bus to keep the workaround as simple\n"
+ "as possible.\n"
+ "\n"
+ "> Then when calling __of_address_to_resource we retrieve I/O tokens \n"
+ "> for the devices on top of the LPC driver and in the I/O accessors\n"
+ "> we call pci_pio_to_address to figure out the cpu address and compare\n"
+ "> it to the list of ranges in armn64_extio_ops.\n"
+ ">   \n"
+ "> What about this?\n"
+ "\n"
+ "That seems really complex for something that can be quite simple.\n"
+ "The only thing we need to worry about is that the io_range_list\n"
+ "contains an entry for the LPC bus so we don't conflict with the\n"
+ "PCI buses.\n"
+ "\n"
+ "\tArnd\n"
+ "\n"
+ "\tArnd\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
 
-fe0301ef41d538c28c4a34dc4e1c1955381f6081e6d0f99510448b268d734f3f
+a4f586c8a8d2bb37ebe233d767e9f7680c8ed3fcee8bcdacb0deae08db460dcc
