From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756558AbcIGPGy (ORCPT ); Wed, 7 Sep 2016 11:06:54 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:65234 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754912AbcIGPGq (ORCPT ); Wed, 7 Sep 2016 11:06:46 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Zhichang Yuan , linuxarm@huawei.com, linux-kernel@vger.kernel.org, lorenzo.pieralisi@arm.com, minyard@acm.org, benh@kernel.crashing.org, gabriele.paoloni@huawei.com, john.garry@huawei.com, liviu.dudau@arm.com, zhichang.yuan02@gmail.com, zourongrong@gmail.com Subject: Re: [PATCH V2 1/4] ARM64 LPC: Indirect ISA port IO introduced Date: Wed, 07 Sep 2016 17:06:04 +0200 Message-ID: <3419224.SdRtVQMJCi@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <1473255233-154297-2-git-send-email-yuanzhichang@hisilicon.com> References: <1473255233-154297-1-git-send-email-yuanzhichang@hisilicon.com> <1473255233-154297-2-git-send-email-yuanzhichang@hisilicon.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:qqfwDpPzORi3rkmJXDiMJgtimVvbWHv054j6Id98vRwzEm+3t0A a6H5k00hAw8R38QjMnCSvQaUlacPIlVSyn452VXRAbZSpBMYL/3AVqCicjrAaeCrQQpcwOR sHmx96FRq8QjLjIdNAvYuIHJr3w3Jw4yhQ0MD539jw/CxVFOZEktnRv5l3wIQRpgJb22OEY uhPeFqFMxO9EtJq0leMFw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FTdcTv7/Wm8=:ps8dwZwC7RTbkpvWlOiPBu KfO8Wb9dWTI08PThh9o1CgQkeBK2YJU+wW4AEjo876zewcbrRzFQzRgHfR8HKQOiO/kSrgcjl GpHi+6xZN84tS29Y/6pp5MhCo8J6w136m3QmSVEj7CkF/0k+ilIvha/OR2psoVvvZGSgQpeQw fHRtOy1irxpDovX4yt1fopCkz0Jxjk9WyIdEMvQrlG6zPTWT6MK9U93zUycQg/8K0E0Vr9/+W 92jlrZardagvz2LKJQS1DG3q2VKPHhdBZeLg5WSUkf6jA/22OIdE4EIOrWF/jTa4G2DdpYMyX KlBBajgRt0cvxnsK8sB5BLQ5WDhRor/tJLZJfj51Xsh/docHe+faHUAzzV0cmu4P97r1b9DGV gtWpY49ySOFHpOAGyPx6WPtE6ebLMZLDf1Ze+hFAm16EmpggX3RjHdwasJirRWjUSdEtfQ320 +f9GAZMVjtvjTWGEHUnCZPjgGYRAf9ooMOhqtplwFmre3fKsvMjKyLVSnHdHqcdZdcUql6nr/ q2UPfA8jLKsJiggQ2S0ofdfy0M0cBr5yE8I5mJMoKwVQP7WO+M5iC8/gbYtpIsDPjQ+TwGLCK ev46Gpo2qyBBzMs71cKac/6PZLTIi3nz0njVO8E71+6nsL/wrT8i5a0SWsjYhyoQdgB9/iMOF gETKSqS4ANC++O/L16xDogudE07wlWVIid03utB/X31QK7xpA0rKTep/XCmDMZgBECTHdEz6E IEDv6uHL7EMGQUZV Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, September 7, 2016 9:33:50 PM CEST Zhichang Yuan wrote: > +#ifdef CONFIG_ARM64_INDIRECT_PIO > + > +typedef u64 (*inhook)(void *devobj, unsigned long ptaddr, void *inbuf, > + size_t dlen, unsigned int count); > +typedef void (*outhook)(void *devobj, unsigned long ptaddr, > + const void *outbuf, size_t dlen, > + unsigned int count); > + > +struct extio_ops { > + inhook pfin; > + outhook pfout; > + void *devpara; > +}; > + > +extern struct extio_ops *arm64_simops __refdata; > + > +/*Up to now, only applied to Hip06 LPC. Define as static here.*/ > +static inline void arm64_set_simops(struct extio_ops *ops) > +{ > + if (ops) > + WRITE_ONCE(arm64_simops, ops); > +} > + > + > +#define BUILDIO(bw, type) \ > +static inline type in##bw(unsigned long addr) \ > +{ \ > + if (addr >= PCIBIOS_MIN_IO) \ > + return read##bw(PCI_IOBASE + addr); \ > + return (arm64_simops && arm64_simops->pfin) ? \ > + arm64_simops->pfin(arm64_simops->devpara, addr, NULL, \ > + sizeof(type), 1) : -1; \ > +} \ > Hmm, the way this is done, enabling CONFIG_ARM64_INDIRECT_PIO at compile time means that only the dynamically registered PIO support is possible for I/O port ranges 0-0xfff. I think the runtime check should better test if simops was defined first and fall back to normal PIO otherwise, in order to allow LPC implementations on a PCI-LPC bridge. How about allowing an I/O port range to be defined along with the operations and check against that? u8 intb(unsigned long port) { if (arm64_simops && (port >= arm64_simops->min) && (port <= arm64_simops->max)) return arm64_simops->pfin(arm64_simops, port, 1); else return readb(PCI_IOBASE + addr); } The other advantage of that is that you can dynamically register a translation for the LPC port range into the Linux I/O port range like PCI hosts do. We may also want to move the inb/outb definitions into a .c file as they are getting rather big. Arnd