From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06 To: Arnd Bergmann , "will.deacon@arm.com" , "liviu.dudau@arm.com" , bhelgaas@google.com References: <1473855354-150093-1-git-send-email-yuanzhichang@hisilicon.com> <9178320.n4yHmfyPA3@wuerfel> <57E40665.8080005@gmail.com> <1760643.vMTR5o5E9g@wuerfel> From: zhichang Message-ID: <378cda2d-e8fb-af10-01ff-c555def3d639@gmail.com> Date: Sat, 24 Sep 2016 16:00:37 +0800 MIME-Version: 1.0 In-Reply-To: <1760643.vMTR5o5E9g@wuerfel> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "devicetree@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "benh@kernel.crashing.org" , Gabriele Paoloni , "minyard@acm.org" , "linux-pci@vger.kernel.org" , John Garry , "linux-kernel@vger.kernel.org" , Yuanzhichang , Linuxarm , "xuwei \(O\)" , "linux-serial@vger.kernel.org" , "gregkh@linuxfoundation.org" , "zourongrong@gmail.com" , "kantyzc@163.com" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="utf-8" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+bjorn=helgaas.com@lists.infradead.org List-ID: SGksIEFybmQsCgoKT24gMjAxNuW5tDA55pyIMjPml6UgMTc6NTEsIEFybmQgQmVyZ21hbm4gd3Jv dGU6Cj4gT24gRnJpZGF5LCBTZXB0ZW1iZXIgMjMsIDIwMTYgMTI6Mjc6MTcgQU0gQ0VTVCB6aGlj aGFuZy55dWFuIHdyb3RlOgo+PiBGb3IgdGhpcyBwYXRjaCBza2V0Y2gsIEkgaGF2ZSBhIHF1ZXN0 aW9uLgo+PiBEbyB3ZSBjYWxsIHBjaV9hZGRyZXNzX3RvX3BpbyBpbiBhcmNoX29mX2FkZHJlc3Nf dG9fcGlvIHRvIGdldCB0aGUgCj4+IGNvcnJlc3BvbmRpbmcgbG9naWNhbCBJTyBwb3J0Cj4+IGZv ciBMUEM/Pwo+IAo+IAo+IE5vLCBvZiBjb3Vyc2Ugbm90LCB0aGF0IHdvdWxkIGJlIHNpbGx5Ogo+ IAo+IFRoZSBhcmd1bWVudCB0byBwY2lfYWRkcmVzc190b19waW8oKSBpcyBhIHBoeXNfYWRkcl90 LCBhbmQgd2Ugd2UgZG9uJ3QKPiBoYXZlIG9uZSBiZWNhdXNlIHRoZXJlIGlzIG5vIGFkZHJlc3Mg YXNzb2NpYXRlZCB3aXRoIHlvdXIgUElPLCB0aGF0Cj4gaXMgdGhlIGVudGlyZSBwb2ludCBvZiB5 b3VyIGRyaXZlciEKPiAKb2suIEkgdGhpbmsgSSBrbm93IHlvdSBwb2ludHMuIFRoZSBwaHlzaWNh bCBhZGRyZXNzZXMgb2YgTFBDIGFyZSBvbmx5IHRoZSBMUEMKZG9tYWluIGFkZHJlc3Nlcywgbm90 IHRoZSByZWFsbHkgQ1BVIHBoeXNpY2FsIGFkZHJlc3Nlcy4gVGhhdCBpcyBqdXN0IHdoeSB5b3UK ZG9uJ3Qgc3VwcG9ydCB0aGUgcmFuZ2VzIHByb3BlcnR5IHVzYWdlIGluIHBhdGNoIFYzLiBDb25z ZXF1ZW50bHksIEl0IGlzIG5vdCBzbwpyZWFzb25hYmxlIHRvIGNhbGwgcGNpX2FkZHJlc3NfdG9f cGlvKCkgd2l0aCBMUEMgYWRkcmVzcyBiZWNhdXNlIHRoYXQgZnVuY3Rpb24KaXMgb25seSBzdWl0 YWJsZSBmb3IgY3B1IHBoeXNpY2FsIGFkZHJlc3MuCgpCdXQganVzdCBhcyB5b3Ugc2FpZCBpbiB0 aGUgbmV4dCBlbWFpbCByZXBseSB0byBHYWJyaWVsZSwgIkFueSBJT1JFU09VUkNFX0lPCmFkZHJl c3MgYWx3YXlzIHJlZmVycyB0byB0aGUgbG9naWNhbCBJL08gcG9ydCByYW5nZSBpbiBMaW51eCwg bm90IHRoZSBwaHlzaWNhbAphZGRyZXNzIHRoYXQgaXMgdXNlZCBvbiBhIGJ1cy4iLCBBbnkgZGV2 aWNlcyB3aGljaCBzdXBwb3J0IElPIGFjY2Vzc2VzIHNob3VsZApoYXZlIHRoZWlyIG93biB1bmlx dWUgbG9naWNhbCBJTyByYW5nZSB0byBkcml2ZSB0aGUgY29ycmVzcG9uZGluZyBoYXJkd2FyZS4g SXQKbWVhbnMgdGhhdCB0aGUgZHJpdmVycyBzaG91bGQga25vdyB0aGUgbWFwcGluZyBiZXR3ZWVu IHBoeXNpY2FsIHBvcnQvbWVtb3J5CmFkZHJlc3MgYW5kIGxvZ2ljYWwgSU8gZGVwZW5kIG9uIHRo ZSBkZXZpY2Ugc3BlY2lmaWMgSS9PIG1vZGUuIEF0IHRoaXMgbW9tZW50LApvbmx5IFBDSSBob3N0 IGJyaWRnZSBzZXR1cCBhIGxvZ2ljYWwgSU8gcmFuZ2UgYWxsb2NhdGlvbiBtZWNoYW5pc20gdG8g bWFuaXB1bGF0ZQp0aGlzIGxvZ2ljYWwgSU8gcmFuZ2UsIGFuZCB0aGlzIHdheSBhcHBsaWVzIGNw dSBwaHlzaWNhbCBhZGRyZXNzKG1lbW9yeSkgYXMgdGhlCmlucHV0LiBOb3csIG91ciBMUEMgYWxz byBuZWVkIHN1YnJhbmdlIGZyb20gdGhpcyBjb21tb24gbG9naWNhbCBJTyByYW5nZSwgYnV0Cndp dGggbGVnYWN5IEkvTyBwb3J0IHJhdGhlciB0aGFuIENQVSBtZW1vcnkgYWRkcmVzcy4gT2ssIGl0 IGJyZWFrIHRoZQpwcmVjb25kaXRpb24gb2YgcGNpX3JlZ2lzdGVyX2lvX3JhbmdlL3BjaV9waW9f dG9fYWRkcmVzcywgd2Ugc2hvdWxkIG5vdCB1c2UgdGhlbQpkaXJlY3RseSBmb3IgTFBDIGFsdGhv dWdoIHRoZSBjYWxsaW5nIG9mIHBjaV9waW9fdG9fYWRkcmVzcyBpcyBzaW1wbGUgYW5kIGxlc3MK Y2hhbmdlIG9uIHRoZSByZWxldmFudCBjb2RlLiBXZSBoYWQgZG9uZSBsaWtlIHRoYXQgaW4gVjMu Li4KClNvLCB0aGUga2V5IGlzc3VlIGlzIGhvdyB0byBnZXQgYSBsb2dpY2FsIElPIHN1YnJhbmdl IHdoaWNoIGlzIG5vdCBjb25mbGljdGVkCndpdGggb3RoZXJzLCBzdWNoIGFzIHBjaSBob3N0IGJy aWRnZXM/PwoKSSBsaXN0IHNldmVyYWwgaWRlYXMgZm9yIGRpc2N1c3Npb246CgoxLiByZXNlcnZl IGEgc3BlY2lmaWMgbG9naWNhbCBJTyBzdWJyYW5nZSBmb3IgTFBDCgpJIGRlc2NyaWJlIHRoaXMg aW4gIk5vdGUgMSIgYmVsb3cuIFBsZWFzZSBjaGVjayBpdC4KVGhpcyB3YXkgc2VlbXMgc2ltcGxl IHdpdGhvdXQgbXVjaCBjaGFuZ2VzLCBidXQgaXQgaXMgbm90IGdlbmVyaWMuCgoyLiBzZXR1cCBh IHNlcGFyYXRlIGxvZ2ljYWwgSU8gc3VicmFuZ2UgYWxsb2NhdGlvbiBtZWNoYW5pc20gc3BlY2lm aWMgZm9yIExQQy9JU0EKCkp1c3QgYXMgeW91ciBzdWdnZXN0aW9uIGJlZm9yZSwgYWRkIHRoZSBh cmNoX29mX2FkZHJlc3NfdG9fcGlvKCkgZm9yIHRoZSBkZXZpY2VzCndoaWNoIG9wZXJhdGUgSS9P IHdpdGggbGVnYWN5IEkvTyBwb3J0IGFkZHJlc3MgcmF0aGVyIHRoYW4gbWVtb3J5IGFkZHJlc3Mg aW4KTU1JTyBtb2RlLiBUaGF0IGFyY2hfb2ZfYWRkcmVzc190b19waW8oKSB3aWxsIHJldHVybiBu b24tY29uZmxpY3QgbG9naWNhbCBJTwp3aXRoIFBDSSBob3N0IGJyaWRnZSBhdCBsYXN0LiBCdXQg dGhlIGxvZ2ljYWwgSU8gcmFuZ2UgaXMgZ2xvYmFsLCB0aG9zZQpmdW5jdGlvbnMgZm9yIExQQy9J U0Egc3BlY2lmaWMgbG9naWNhbCBJTyBzdWJyYW5nZSBhbGxvY2F0aW9uIG11c3QgYmUKc3luY2hy b25pemVkIHdpdGggcGNpX3JlZ2lzdGVyX2lvX3JhbmdlL3BjaV9waW9fdG9fYWRkcmVzcyB0byBr bm93IHdoYXQgbG9naWNhbApyYW5nZXMgaGFkIGJlZW4gcG9wdWxhdGVkLiBJdCBpcyBub3QgZ29v ZCBmb3IgdGhlIGltcGxlbWVudCBkaXNwZXJzaW9uIG9uIHNhbWUKaXNzdWUuCgozLiBzZXR1cCBh IG5ldyB1bmRlcmx5aW5nIG1ldGhvZCB0byBjb250cm9sIHRoZSBsb2dpY2FsIElPIHJhbmdlIG1h bmFnZW1lbnQKCkJhc2VkIG9uIHRoZSBleGlzdGluZyByZXNvdXJjZSBtYW5hZ2VtZW50LCBhZGQg YSBzaW1wbGlmaWVkIGxvZ2ljYWwgSU8gcmFuZ2UKbWFuYWdlbWVudCBzdXBwb3J0IHdoaWNoIG9u bHkgcmVxdWVzdCB0aGUgbG9naWNhbCBJTyByYW5nZXMgYWNjb3JkaW5nIHRoZSBJTwpyYW5nZSBz aXplICggc2ltaWxhciB0byBJT1JFU09VUkNFX1NJWkVBTElHTiBtb2RlICksIG5vIG1hdHRlciB3 aGF0IHR5cGUgdGhlCnBoeXNpY2FsIGFkZHJlc3MgaXMuIFRoZW4gcmV2aXNlIHRoZSBjdXJyZW50 IHBjaV9yZWdpc3Rlcl9pb19yYW5nZSB0byBhZG9wdCB0aGlzCm5ldyBtZXRob2QuIE9mLWNvdXJz ZSwgTFBDL0lTQSByZXF1ZXN0IHRoZSBsb2dpY2FsIElPIHdpdGggdGhpcyBuZXcgbWV0aG9kIHRv by4KClRoaXMgaXMganVzdCBhIHByb3Bvc2l0aW9uLiBJdCBpcyBtb3JlIHdvcmtsb2FkIGNvbXBh cmVkIHdpdGggb3RoZXIgc29sdXRpb25zLgoKV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhlc2U/ IEFueSBtb3JlIGlkZWFzPwoKCj4gQWxzbywgd2UgYWxyZWFkeSBrbm93IHRoZSBtYXBwaW5nIGJl Y2F1c2UgdGhpcyBpcyB3aGF0IHRoZSBpbmIvb3V0Ygo+IHdvcmthcm91bmQgaXMgbG9va2luZyBh dCwgc28gdGhlcmUgaXMgYWJzb2x1dGVseSBubyByZWFzb24gdG8gY2FsbCBpdAo+IGVpdGhlci4K PiAKPj4gSWYgd2UgZG9uJ3QsIGl0IHNlZW1zIHRoZSBMUEMgc3BlY2lmaWMgSU8gYWRkcmVzcyB3 aWxsIGNvbmZsaWN0IHdpdGggUENJIAo+PiBob3N0IGJyaWRnZXMnIGxvZ2ljYWwgSU8uCj4+Cj4+ IFN1cHBvc2VkIG91ciBMUEMgcG9wdWxhdGVkIHRoZSBJTyByYW5nZSBmcm9tIDB4MTAwIHRvIDB4 M0ZGKCB0aGlzIGlzIAo+PiBub3JtYWwgZm9yIElTQSBzaW1pbGFyCj4+IGRldmljZXMpLCBhZnRl ciBhcmNoX29mX2FkZHJlc3NfdG9fcGlvKCksIHRoZSByLT5zdGFydCB3aWxsIGJlIHNldCBhcyAK Pj4gMHgxMDAsIHItPmVuZCB3aWxsIGJlIHNldCBhcwo+PiAweDNGRi4gIEFuZCBpZiB0aGVyZSBp cyBvbmUgUENJIGhvc3QgYnJpZGdlIHdobyByZXF1ZXN0IGEgSU8gd2luZG93IHNpemUgCj4+IG92 ZXIgMHg0MDAgYXQgdGhlIHNhbWUKPj4gdGltZSwgdGhlICBjb3JyZXNwb25kaW5nIHItPnN0YXJ0 IGFuZCByLT5lbmQgd2lsbCBiZSBzZXQgYXMgMHgwLCAweDNGRiAKPj4gYWZ0ZXIgb2ZfYWRkcmVz c190b19yZXNvdXJjZQo+PiBmb3IgdGhpcyBob3N0IGJyaWRnZS4gIFRoZW4gdGhlIElPIGNvbmZs aWN0IGhhcHBlbnMuCj4gCj4gWW91IHdvdWxkIHN0aWxsIG5lZWQgdG8gcmVzZXJ2ZSBzb21lIHNw YWNlIGluIHRoZSBpb19yYW5nZV9saXN0Cj4gdG8gYXZvaWQgcG9zc2libGUgY29uZmxpY3RzLCB3 aGljaCBpcyBhIGJpdCB1Z2x5IHdpdGggdGhlIGN1cnJlbnQKPiBkZWZpbml0aW9uIG9mIHBjaV9y ZWdpc3Rlcl9pb19yYW5nZSwgYnV0IEknbSBzdXJlIGNhbiBiZSBkb25lLgo+IAoKTm90ZSAxKSBE byB5b3UgcmVtZW1iZXIgcGF0Y2ggVjI/IFRoZXJlLCBJIG1vZGlmaWVkIHRoZSBwY2kuYyBsaWtl IHRoYXQgdG8KcmVzZXJ2ZSAwIC0gUENJQklPU19NSU5fSU8gKGl0IGlzIDB4MTAwMCkgOgoKZGlm ZiAtLWdpdCBhL2RyaXZlcnMvcGNpL3BjaS5jIGIvZHJpdmVycy9wY2kvcGNpLmMKaW5kZXggYWFi OWQ1MS4uYWMyZTU2OSAxMDA2NDQKLS0tIGEvZHJpdmVycy9wY2kvcGNpLmMKKysrIGIvZHJpdmVy cy9wY2kvcGNpLmMKQEAgLTMyMjEsNyArMzIyMSw3IEBAIGludCBfX3dlYWsgcGNpX3JlZ2lzdGVy X2lvX3JhbmdlKHBoeXNfYWRkcl90IGFkZHIsIHJlc291cmMKCiAjaWZkZWYgUENJX0lPQkFTRQog ICAgICAgIHN0cnVjdCBpb19yYW5nZSAqcmFuZ2U7Ci0gICAgICAgcmVzb3VyY2Vfc2l6ZV90IGFs bG9jYXRlZF9zaXplID0gMDsKKyAgICAgICByZXNvdXJjZV9zaXplX3QgYWxsb2NhdGVkX3NpemUg PSBQQ0lCSU9TX01JTl9JTzsKCiAgICAgICAgLyogY2hlY2sgaWYgdGhlIHJhbmdlIGhhc24ndCBi ZWVuIHByZXZpb3VzbHkgcmVjb3JkZWQgKi8KICAgICAgICBzcGluX2xvY2soJmlvX3JhbmdlX2xv Y2spOwpAQCAtMzI3MCw3ICszMjcwLDcgQEAgcGh5c19hZGRyX3QgcGNpX3Bpb190b19hZGRyZXNz KHVuc2lnbmVkIGxvbmcgcGlvKQoKICNpZmRlZiBQQ0lfSU9CQVNFCiAgICAgICAgc3RydWN0IGlv X3JhbmdlICpyYW5nZTsKLSAgICAgICByZXNvdXJjZV9zaXplX3QgYWxsb2NhdGVkX3NpemUgPSAw OworICAgICAgIHJlc291cmNlX3NpemVfdCBhbGxvY2F0ZWRfc2l6ZSA9IFBDSUJJT1NfTUlOX0lP OwoKICAgICAgICBpZiAocGlvID4gSU9fU1BBQ0VfTElNSVQpCiAgICAgICAgICAgICAgICByZXR1 cm4gYWRkcmVzczsKQEAgLTMyOTMsNyArMzI5Myw3IEBAIHVuc2lnbmVkIGxvbmcgX193ZWFrIHBj aV9hZGRyZXNzX3RvX3BpbyhwaHlzX2FkZHJfdCBhZGRyZXMKIHsKICNpZmRlZiBQQ0lfSU9CQVNF CiAgICAgICAgc3RydWN0IGlvX3JhbmdlICpyZXM7Ci0gICAgICAgcmVzb3VyY2Vfc2l6ZV90IG9m ZnNldCA9IDA7CisgICAgICAgcmVzb3VyY2Vfc2l6ZV90IG9mZnNldCA9IFBDSUJJT1NfTUlOX0lP OwogICAgICAgIHVuc2lnbmVkIGxvbmcgYWRkciA9IC0xOwoKICAgICAgICBzcGluX2xvY2soJmlv X3JhbmdlX2xvY2spOwoKQmFzZWQgb24gdGhpcywgYSBleGNsdXNpdmUgbG9naWNhbCBJTyBzdWJy YW5nZSBpcyBmb3IgTFBDIG5vdy4gVGhlbiB3ZSBjZXJ0YWlubHkKY2FuIGFkZCBzb21lIHNwZWNp YWwgaGFuZGxpbmcgaW4gX19vZl9hZGRyZXNzX3RvX3Jlc291cmNlIG9yCl9fb2ZfdHJhbnNsYXRl X2FkZHJlc3MgLS0+IG9mX3RyYW5zbGF0ZV9vbmUgdG8gcmV0dXJuIHRoZSB1bnRyYW5zbGF0ZWQg TFBDL0lTQQpJTyBhZGRyZXNzLiBCdXQgdG8gYmUgaG9uZXN0LCBJIHRoaW5rIHdlIGRvbid0IG5l ZWQgdGhpcyBzcGVjaWFsIGhhbmRsaW5nIGluCmFkZHJlc3MuYyBhbnltb3JlLiBXZSBoYWQga25v d24gdGhlIExQQy9JU0EgSU8gaXMgMToxIHRvIGxvZ2ljYWwgSU8sIGp1c3QgdGhpbmsKYW55IGxv Z2ljYWwgSU8gcG9ydCBhbW9uZyAwIC0gMHgxMDAwIHNob3VsZCBjYWxsIHRoZSBMUEMgcmVnaXN0 ZXJlZCBJL08gaG9va3MgaW4KdGhlIG5ldyBpbi9vdXQoKS4KCkZ1cnRoZXJtb3JlLCB3ZSBjYW4g bWFrZSB0aGUgcmVzZXJ2YXRpb24gaXMgbm90IGZpeGVkIGFzIFBDSUJJT1NfTUlOX0lPLiBJZiB0 aGUKTFBDL0lTQSBwcm9iaW5nIGlzIHJ1biBiZWZvcmUgUENJIGhvc3QgYnJpZGdlIHByb2Jpbmcs IHdlIGNhbiByZXNlcnZlIGEKbm9uLWZpeGVkIGxvZ2NpYWwgSU8gc3VicmFuZ2Ugd2hhdCBMUEMv SVNBIGFzayBmb3IuCgpUaGlzIHNvbHV0aW9uIGlzIGJhc2VkIG9uIGFuIGFzc3VtcHRpb24gdGhh dCBubyBhbnkgb3RoZXIgZGV2aWNlcyBoYXZlIHRvCnJlcXVlc3QgdGhlIHNwZWNpZmljIGxvZ2lj YWwgSU8gc3VicmFuZ2UgZm9yIExQQy9JU0EuIFByb2JhYmx5IHRoaXMgYXNzdW1wdGlvbgppcyBv ayBvbiBhcm02NCwgeW91IGtub3duLCB0aGVyZSBpcyBubyByZWFsIElPIHNwYWNlIGFzIFg4Ni4g QnV0IGFueXdheSwgdGhpcwpyZXNlcnZhdGlvbiBpcyBub3Qgc28gZ2VuZXJpYywgZGVwZW5kZWQg b24gc29tZSBzcGVjaWFsIGhhbmRsaW5nLgoKRG9lcyB0aGlzIGlkZWEgbWF0Y2ggeW91ciBjb21t ZW50cz8/CgoKPiBPbmUgd2F5IEkgY2FuIHRoaW5rIG9mIHdvdWxkIGJlIHRvIGNoYW5nZSBwY2lf cmVnaXN0ZXJfaW9fcmFuZ2UoKQo+IHRvIGp1c3QgcmV0dXJuIHRoZSBsb2dpY2FsIHBvcnQgbnVt YmVyIGRpcmVjdGx5IChpdCBhbHJlYWR5Cj4ga25vd3MgaXQhKSwgYW5kIHBhc3MgYW4gaW52YWxp ZCBwaHlzaWNhbCBhZGRyZXNzIChlLmcuIAo+ICNkZWZpbmUgSVNBX1dPUktBUk9VTkRfSU9fUE9S VF9XSU5ET1cgLTB4MTAwMDApIGludG8gaXQgZm9yCj4gaW52YWxpZCB0cmFuc2xhdGlvbnMuCj4g CgpJIGFtIG5vdCBzbyBjbGVhciBrbm93IHlvdXIgaWRlYSBoZXJlLiAgRG8geW91IHdhbnQgdG8g c2VsZWN0IGFuIHVucG9wdWxhdGVkIENQVQphZGRyZXNzIGFzIHRoZSBwYXJlbnQgYWRkcmVzcyBp biByYW5nZSBwcm9wZXJ0eT8/IG9yIGFueXRoaW5nIGVsc2U/Pz8KCgo+IEFub3RoZXIgYWx0ZXJu YXRpdmUgdGhhdCBqdXN0IG9jY3VycmVkIHRvIG1lIHdvdWxkIGJlIHRvIG1vdmUKPiB0aGUgcGNp X2FkZHJlc3NfdG9fcGlvKCkgY2FsbCBmcm9tIF9fb2ZfYWRkcmVzc190b19yZXNvdXJjZSgpCj4g aW50byBvZl9idXNfcGNpX3RyYW5zbGF0ZSgpIGFuZCB0aGVuIGRvIHRoZSBzcGVjaWFsIGhhbmRs aW5nCj4gZm9yIHRoZSBJU0EvTFBDIGJ1cyBpbiBvZl9idXNfaXNhX3RyYW5zbGF0ZSgpLgoKQXMg Zm9yIHRoaXMgaWRlYSwgZG8geW91IG1lYW4gdGhhdCBvZl90cmFuc2xhdGVfYWRkcmVzcyB3aWxs IGRpcmVjdGx5IHJldHVybiB0aGUKZmluYWwgbG9naWNhbCBJTyBzdGFydCBhZGRyZXNzPz8gSXQg c2VlbXMgdG8gZXh0ZW5kIHRoZSBkZWZpbml0aW9uIG9mCm9mX3RyYW5zbGF0ZV9hZGRyZXNzLgoK ClRoYW5rcywKWmhpY2hhbmcKCj4gCj4gCUFybmQKPiAKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0Cmxp bnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: zhichang Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06 Date: Sat, 24 Sep 2016 16:00:37 +0800 Message-ID: <378cda2d-e8fb-af10-01ff-c555def3d639@gmail.com> References: <1473855354-150093-1-git-send-email-yuanzhichang@hisilicon.com> <9178320.n4yHmfyPA3@wuerfel> <57E40665.8080005@gmail.com> <1760643.vMTR5o5E9g@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <1760643.vMTR5o5E9g@wuerfel> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Arnd Bergmann , "will.deacon-5wv7dgnIgG8@public.gmane.org" , "liviu.dudau-5wv7dgnIgG8@public.gmane.org" , bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org Cc: Gabriele Paoloni , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org" , "minyard-HInyCGIudOg@public.gmane.org" , "linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org" , John Garry , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Yuanzhichang , Linuxarm , "xuwei (O)" , "linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org" , "zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" List-Id: linux-serial@vger.kernel.org Hi, Arnd, On 2016年09月23日 17:51, Arnd Bergmann wrote: > On Friday, September 23, 2016 12:27:17 AM CEST zhichang.yuan wrote: >> For this patch sketch, I have a question. >> Do we call pci_address_to_pio in arch_of_address_to_pio to get the >> corresponding logical IO port >> for LPC?? > > > No, of course not, that would be silly: > > The argument to pci_address_to_pio() is a phys_addr_t, and we we don't > have one because there is no address associated with your PIO, that > is the entire point of your driver! > ok. I think I know you points. The physical addresses of LPC are only the LPC domain addresses, not the really CPU physical addresses. That is just why you don't support the ranges property usage in patch V3. Consequently, It is not so reasonable to call pci_address_to_pio() with LPC address because that function is only suitable for cpu physical address. But just as you said in the next email reply to Gabriele, "Any IORESOURCE_IO address always refers to the logical I/O port range in Linux, not the physical address that is used on a bus.", Any devices which support IO accesses should have their own unique logical IO range to drive the corresponding hardware. It means that the drivers should know the mapping between physical port/memory address and logical IO depend on the device specific I/O mode. At this moment, only PCI host bridge setup a logical IO range allocation mechanism to manipulate this logical IO range, and this way applies cpu physical address(memory) as the input. Now, our LPC also need subrange from this common logical IO range, but with legacy I/O port rather than CPU memory address. Ok, it break the precondition of pci_register_io_range/pci_pio_to_address, we should not use them directly for LPC although the calling of pci_pio_to_address is simple and less change on the relevant code. We had done like that in V3... So, the key issue is how to get a logical IO subrange which is not conflicted with others, such as pci host bridges?? I list several ideas for discussion: 1. reserve a specific logical IO subrange for LPC I describe this in "Note 1" below. Please check it. This way seems simple without much changes, but it is not generic. 2. setup a separate logical IO subrange allocation mechanism specific for LPC/ISA Just as your suggestion before, add the arch_of_address_to_pio() for the devices which operate I/O with legacy I/O port address rather than memory address in MMIO mode. That arch_of_address_to_pio() will return non-conflict logical IO with PCI host bridge at last. But the logical IO range is global, those functions for LPC/ISA specific logical IO subrange allocation must be synchronized with pci_register_io_range/pci_pio_to_address to know what logical ranges had been populated. It is not good for the implement dispersion on same issue. 3. setup a new underlying method to control the logical IO range management Based on the existing resource management, add a simplified logical IO range management support which only request the logical IO ranges according the IO range size ( similar to IORESOURCE_SIZEALIGN mode ), no matter what type the physical address is. Then revise the current pci_register_io_range to adopt this new method. Of-course, LPC/ISA request the logical IO with this new method too. This is just a proposition. It is more workload compared with other solutions. What do you think about these? Any more ideas? > Also, we already know the mapping because this is what the inb/outb > workaround is looking at, so there is absolutely no reason to call it > either. > >> If we don't, it seems the LPC specific IO address will conflict with PCI >> host bridges' logical IO. >> >> Supposed our LPC populated the IO range from 0x100 to 0x3FF( this is >> normal for ISA similar >> devices), after arch_of_address_to_pio(), the r->start will be set as >> 0x100, r->end will be set as >> 0x3FF. And if there is one PCI host bridge who request a IO window size >> over 0x400 at the same >> time, the corresponding r->start and r->end will be set as 0x0, 0x3FF >> after of_address_to_resource >> for this host bridge. Then the IO conflict happens. > > You would still need to reserve some space in the io_range_list > to avoid possible conflicts, which is a bit ugly with the current > definition of pci_register_io_range, but I'm sure can be done. > Note 1) Do you remember patch V2? There, I modified the pci.c like that to reserve 0 - PCIBIOS_MIN_IO (it is 0x1000) : diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index aab9d51..ac2e569 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3221,7 +3221,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resourc #ifdef PCI_IOBASE struct io_range *range; - resource_size_t allocated_size = 0; + resource_size_t allocated_size = PCIBIOS_MIN_IO; /* check if the range hasn't been previously recorded */ spin_lock(&io_range_lock); @@ -3270,7 +3270,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio) #ifdef PCI_IOBASE struct io_range *range; - resource_size_t allocated_size = 0; + resource_size_t allocated_size = PCIBIOS_MIN_IO; if (pio > IO_SPACE_LIMIT) return address; @@ -3293,7 +3293,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t addres { #ifdef PCI_IOBASE struct io_range *res; - resource_size_t offset = 0; + resource_size_t offset = PCIBIOS_MIN_IO; unsigned long addr = -1; spin_lock(&io_range_lock); Based on this, a exclusive logical IO subrange is for LPC now. Then we certainly can add some special handling in __of_address_to_resource or __of_translate_address --> of_translate_one to return the untranslated LPC/ISA IO address. But to be honest, I think we don't need this special handling in address.c anymore. We had known the LPC/ISA IO is 1:1 to logical IO, just think any logical IO port among 0 - 0x1000 should call the LPC registered I/O hooks in the new in/out(). Furthermore, we can make the reservation is not fixed as PCIBIOS_MIN_IO. If the LPC/ISA probing is run before PCI host bridge probing, we can reserve a non-fixed logcial IO subrange what LPC/ISA ask for. This solution is based on an assumption that no any other devices have to request the specific logical IO subrange for LPC/ISA. Probably this assumption is ok on arm64, you known, there is no real IO space as X86. But anyway, this reservation is not so generic, depended on some special handling. Does this idea match your comments?? > One way I can think of would be to change pci_register_io_range() > to just return the logical port number directly (it already > knows it!), and pass an invalid physical address (e.g. > #define ISA_WORKAROUND_IO_PORT_WINDOW -0x10000) into it for > invalid translations. > I am not so clear know your idea here. Do you want to select an unpopulated CPU address as the parent address in range property?? or anything else??? > Another alternative that just occurred to me would be to move > the pci_address_to_pio() call from __of_address_to_resource() > into of_bus_pci_translate() and then do the special handling > for the ISA/LPC bus in of_bus_isa_translate(). As for this idea, do you mean that of_translate_address will directly return the final logical IO start address?? It seems to extend the definition of of_translate_address. Thanks, Zhichang > > Arnd > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: zhichang.yuan02@gmail.com (zhichang) Date: Sat, 24 Sep 2016 16:00:37 +0800 Subject: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06 In-Reply-To: <1760643.vMTR5o5E9g@wuerfel> References: <1473855354-150093-1-git-send-email-yuanzhichang@hisilicon.com> <9178320.n4yHmfyPA3@wuerfel> <57E40665.8080005@gmail.com> <1760643.vMTR5o5E9g@wuerfel> Message-ID: <378cda2d-e8fb-af10-01ff-c555def3d639@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Arnd, On 2016?09?23? 17:51, Arnd Bergmann wrote: > On Friday, September 23, 2016 12:27:17 AM CEST zhichang.yuan wrote: >> For this patch sketch, I have a question. >> Do we call pci_address_to_pio in arch_of_address_to_pio to get the >> corresponding logical IO port >> for LPC?? > > > No, of course not, that would be silly: > > The argument to pci_address_to_pio() is a phys_addr_t, and we we don't > have one because there is no address associated with your PIO, that > is the entire point of your driver! > ok. I think I know you points. The physical addresses of LPC are only the LPC domain addresses, not the really CPU physical addresses. That is just why you don't support the ranges property usage in patch V3. Consequently, It is not so reasonable to call pci_address_to_pio() with LPC address because that function is only suitable for cpu physical address. But just as you said in the next email reply to Gabriele, "Any IORESOURCE_IO address always refers to the logical I/O port range in Linux, not the physical address that is used on a bus.", Any devices which support IO accesses should have their own unique logical IO range to drive the corresponding hardware. It means that the drivers should know the mapping between physical port/memory address and logical IO depend on the device specific I/O mode. At this moment, only PCI host bridge setup a logical IO range allocation mechanism to manipulate this logical IO range, and this way applies cpu physical address(memory) as the input. Now, our LPC also need subrange from this common logical IO range, but with legacy I/O port rather than CPU memory address. Ok, it break the precondition of pci_register_io_range/pci_pio_to_address, we should not use them directly for LPC although the calling of pci_pio_to_address is simple and less change on the relevant code. We had done like that in V3... So, the key issue is how to get a logical IO subrange which is not conflicted with others, such as pci host bridges?? I list several ideas for discussion: 1. reserve a specific logical IO subrange for LPC I describe this in "Note 1" below. Please check it. This way seems simple without much changes, but it is not generic. 2. setup a separate logical IO subrange allocation mechanism specific for LPC/ISA Just as your suggestion before, add the arch_of_address_to_pio() for the devices which operate I/O with legacy I/O port address rather than memory address in MMIO mode. That arch_of_address_to_pio() will return non-conflict logical IO with PCI host bridge at last. But the logical IO range is global, those functions for LPC/ISA specific logical IO subrange allocation must be synchronized with pci_register_io_range/pci_pio_to_address to know what logical ranges had been populated. It is not good for the implement dispersion on same issue. 3. setup a new underlying method to control the logical IO range management Based on the existing resource management, add a simplified logical IO range management support which only request the logical IO ranges according the IO range size ( similar to IORESOURCE_SIZEALIGN mode ), no matter what type the physical address is. Then revise the current pci_register_io_range to adopt this new method. Of-course, LPC/ISA request the logical IO with this new method too. This is just a proposition. It is more workload compared with other solutions. What do you think about these? Any more ideas? > Also, we already know the mapping because this is what the inb/outb > workaround is looking at, so there is absolutely no reason to call it > either. > >> If we don't, it seems the LPC specific IO address will conflict with PCI >> host bridges' logical IO. >> >> Supposed our LPC populated the IO range from 0x100 to 0x3FF( this is >> normal for ISA similar >> devices), after arch_of_address_to_pio(), the r->start will be set as >> 0x100, r->end will be set as >> 0x3FF. And if there is one PCI host bridge who request a IO window size >> over 0x400 at the same >> time, the corresponding r->start and r->end will be set as 0x0, 0x3FF >> after of_address_to_resource >> for this host bridge. Then the IO conflict happens. > > You would still need to reserve some space in the io_range_list > to avoid possible conflicts, which is a bit ugly with the current > definition of pci_register_io_range, but I'm sure can be done. > Note 1) Do you remember patch V2? There, I modified the pci.c like that to reserve 0 - PCIBIOS_MIN_IO (it is 0x1000) : diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index aab9d51..ac2e569 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3221,7 +3221,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resourc #ifdef PCI_IOBASE struct io_range *range; - resource_size_t allocated_size = 0; + resource_size_t allocated_size = PCIBIOS_MIN_IO; /* check if the range hasn't been previously recorded */ spin_lock(&io_range_lock); @@ -3270,7 +3270,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio) #ifdef PCI_IOBASE struct io_range *range; - resource_size_t allocated_size = 0; + resource_size_t allocated_size = PCIBIOS_MIN_IO; if (pio > IO_SPACE_LIMIT) return address; @@ -3293,7 +3293,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t addres { #ifdef PCI_IOBASE struct io_range *res; - resource_size_t offset = 0; + resource_size_t offset = PCIBIOS_MIN_IO; unsigned long addr = -1; spin_lock(&io_range_lock); Based on this, a exclusive logical IO subrange is for LPC now. Then we certainly can add some special handling in __of_address_to_resource or __of_translate_address --> of_translate_one to return the untranslated LPC/ISA IO address. But to be honest, I think we don't need this special handling in address.c anymore. We had known the LPC/ISA IO is 1:1 to logical IO, just think any logical IO port among 0 - 0x1000 should call the LPC registered I/O hooks in the new in/out(). Furthermore, we can make the reservation is not fixed as PCIBIOS_MIN_IO. If the LPC/ISA probing is run before PCI host bridge probing, we can reserve a non-fixed logcial IO subrange what LPC/ISA ask for. This solution is based on an assumption that no any other devices have to request the specific logical IO subrange for LPC/ISA. Probably this assumption is ok on arm64, you known, there is no real IO space as X86. But anyway, this reservation is not so generic, depended on some special handling. Does this idea match your comments?? > One way I can think of would be to change pci_register_io_range() > to just return the logical port number directly (it already > knows it!), and pass an invalid physical address (e.g. > #define ISA_WORKAROUND_IO_PORT_WINDOW -0x10000) into it for > invalid translations. > I am not so clear know your idea here. Do you want to select an unpopulated CPU address as the parent address in range property?? or anything else??? > Another alternative that just occurred to me would be to move > the pci_address_to_pio() call from __of_address_to_resource() > into of_bus_pci_translate() and then do the special handling > for the ISA/LPC bus in of_bus_isa_translate(). As for this idea, do you mean that of_translate_address will directly return the final logical IO start address?? It seems to extend the definition of of_translate_address. Thanks, Zhichang > > Arnd > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761434AbcIXH74 (ORCPT ); Sat, 24 Sep 2016 03:59:56 -0400 Received: from mail-pa0-f68.google.com ([209.85.220.68]:35654 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752017AbcIXH7v (ORCPT ); Sat, 24 Sep 2016 03:59:51 -0400 Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06 To: Arnd Bergmann , "will.deacon@arm.com" , "liviu.dudau@arm.com" , bhelgaas@google.com References: <1473855354-150093-1-git-send-email-yuanzhichang@hisilicon.com> <9178320.n4yHmfyPA3@wuerfel> <57E40665.8080005@gmail.com> <1760643.vMTR5o5E9g@wuerfel> Cc: Gabriele Paoloni , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "minyard@acm.org" , "linux-pci@vger.kernel.org" , "gregkh@linuxfoundation.org" , John Garry , "linux-kernel@vger.kernel.org" , Yuanzhichang , Linuxarm , "xuwei (O)" , "linux-serial@vger.kernel.org" , "benh@kernel.crashing.org" , "zourongrong@gmail.com" , "kantyzc@163.com" From: zhichang X-Enigmail-Draft-Status: N1110 Message-ID: <378cda2d-e8fb-af10-01ff-c555def3d639@gmail.com> Date: Sat, 24 Sep 2016 16:00:37 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1760643.vMTR5o5E9g@wuerfel> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Arnd, On 2016年09月23日 17:51, Arnd Bergmann wrote: > On Friday, September 23, 2016 12:27:17 AM CEST zhichang.yuan wrote: >> For this patch sketch, I have a question. >> Do we call pci_address_to_pio in arch_of_address_to_pio to get the >> corresponding logical IO port >> for LPC?? > > > No, of course not, that would be silly: > > The argument to pci_address_to_pio() is a phys_addr_t, and we we don't > have one because there is no address associated with your PIO, that > is the entire point of your driver! > ok. I think I know you points. The physical addresses of LPC are only the LPC domain addresses, not the really CPU physical addresses. That is just why you don't support the ranges property usage in patch V3. Consequently, It is not so reasonable to call pci_address_to_pio() with LPC address because that function is only suitable for cpu physical address. But just as you said in the next email reply to Gabriele, "Any IORESOURCE_IO address always refers to the logical I/O port range in Linux, not the physical address that is used on a bus.", Any devices which support IO accesses should have their own unique logical IO range to drive the corresponding hardware. It means that the drivers should know the mapping between physical port/memory address and logical IO depend on the device specific I/O mode. At this moment, only PCI host bridge setup a logical IO range allocation mechanism to manipulate this logical IO range, and this way applies cpu physical address(memory) as the input. Now, our LPC also need subrange from this common logical IO range, but with legacy I/O port rather than CPU memory address. Ok, it break the precondition of pci_register_io_range/pci_pio_to_address, we should not use them directly for LPC although the calling of pci_pio_to_address is simple and less change on the relevant code. We had done like that in V3... So, the key issue is how to get a logical IO subrange which is not conflicted with others, such as pci host bridges?? I list several ideas for discussion: 1. reserve a specific logical IO subrange for LPC I describe this in "Note 1" below. Please check it. This way seems simple without much changes, but it is not generic. 2. setup a separate logical IO subrange allocation mechanism specific for LPC/ISA Just as your suggestion before, add the arch_of_address_to_pio() for the devices which operate I/O with legacy I/O port address rather than memory address in MMIO mode. That arch_of_address_to_pio() will return non-conflict logical IO with PCI host bridge at last. But the logical IO range is global, those functions for LPC/ISA specific logical IO subrange allocation must be synchronized with pci_register_io_range/pci_pio_to_address to know what logical ranges had been populated. It is not good for the implement dispersion on same issue. 3. setup a new underlying method to control the logical IO range management Based on the existing resource management, add a simplified logical IO range management support which only request the logical IO ranges according the IO range size ( similar to IORESOURCE_SIZEALIGN mode ), no matter what type the physical address is. Then revise the current pci_register_io_range to adopt this new method. Of-course, LPC/ISA request the logical IO with this new method too. This is just a proposition. It is more workload compared with other solutions. What do you think about these? Any more ideas? > Also, we already know the mapping because this is what the inb/outb > workaround is looking at, so there is absolutely no reason to call it > either. > >> If we don't, it seems the LPC specific IO address will conflict with PCI >> host bridges' logical IO. >> >> Supposed our LPC populated the IO range from 0x100 to 0x3FF( this is >> normal for ISA similar >> devices), after arch_of_address_to_pio(), the r->start will be set as >> 0x100, r->end will be set as >> 0x3FF. And if there is one PCI host bridge who request a IO window size >> over 0x400 at the same >> time, the corresponding r->start and r->end will be set as 0x0, 0x3FF >> after of_address_to_resource >> for this host bridge. Then the IO conflict happens. > > You would still need to reserve some space in the io_range_list > to avoid possible conflicts, which is a bit ugly with the current > definition of pci_register_io_range, but I'm sure can be done. > Note 1) Do you remember patch V2? There, I modified the pci.c like that to reserve 0 - PCIBIOS_MIN_IO (it is 0x1000) : diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index aab9d51..ac2e569 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3221,7 +3221,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resourc #ifdef PCI_IOBASE struct io_range *range; - resource_size_t allocated_size = 0; + resource_size_t allocated_size = PCIBIOS_MIN_IO; /* check if the range hasn't been previously recorded */ spin_lock(&io_range_lock); @@ -3270,7 +3270,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio) #ifdef PCI_IOBASE struct io_range *range; - resource_size_t allocated_size = 0; + resource_size_t allocated_size = PCIBIOS_MIN_IO; if (pio > IO_SPACE_LIMIT) return address; @@ -3293,7 +3293,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t addres { #ifdef PCI_IOBASE struct io_range *res; - resource_size_t offset = 0; + resource_size_t offset = PCIBIOS_MIN_IO; unsigned long addr = -1; spin_lock(&io_range_lock); Based on this, a exclusive logical IO subrange is for LPC now. Then we certainly can add some special handling in __of_address_to_resource or __of_translate_address --> of_translate_one to return the untranslated LPC/ISA IO address. But to be honest, I think we don't need this special handling in address.c anymore. We had known the LPC/ISA IO is 1:1 to logical IO, just think any logical IO port among 0 - 0x1000 should call the LPC registered I/O hooks in the new in/out(). Furthermore, we can make the reservation is not fixed as PCIBIOS_MIN_IO. If the LPC/ISA probing is run before PCI host bridge probing, we can reserve a non-fixed logcial IO subrange what LPC/ISA ask for. This solution is based on an assumption that no any other devices have to request the specific logical IO subrange for LPC/ISA. Probably this assumption is ok on arm64, you known, there is no real IO space as X86. But anyway, this reservation is not so generic, depended on some special handling. Does this idea match your comments?? > One way I can think of would be to change pci_register_io_range() > to just return the logical port number directly (it already > knows it!), and pass an invalid physical address (e.g. > #define ISA_WORKAROUND_IO_PORT_WINDOW -0x10000) into it for > invalid translations. > I am not so clear know your idea here. Do you want to select an unpopulated CPU address as the parent address in range property?? or anything else??? > Another alternative that just occurred to me would be to move > the pci_address_to_pio() call from __of_address_to_resource() > into of_bus_pci_translate() and then do the special handling > for the ISA/LPC bus in of_bus_isa_translate(). As for this idea, do you mean that of_translate_address will directly return the final logical IO start address?? It seems to extend the definition of of_translate_address. Thanks, Zhichang > > Arnd >