[{"id":1768229,"web_url":"http://patchwork.ozlabs.org/comment/1768229/","msgid":"<20170914002810.38a35cd3@windsurf>","list_archive_url":null,"date":"2017-09-13T22:28:10","subject":"Re: [U-Boot] I/O accessors on SuperH and endianness","submitter":{"id":2230,"url":"http://patchwork.ozlabs.org/api/people/2230/","name":"Thomas Petazzoni","email":"thomas.petazzoni@free-electrons.com"},"content":"Hello,\n\nHas anyone any comments/suggestions on the below questions? How is this\nproblem solved on other architectures?\n\nThanks,\n\nThomas\n\nOn Mon, 28 Aug 2017 14:32:49 +0200, Thomas Petazzoni wrote:\n> Hello,\n> \n> As you've noticed, I'm porting U-Boot to a SH4 board running\n> big-endian. The big-endian choice cannot be changed, because it's\n> selected by the HW design: moving to little endian would require a\n> modification of the board.\n> \n> The serial_sh driver was working fine in big endian, with no change.\n> However, the sh_eth driver was not working in big endian mode. After\n> investigation, I realized that:\n> \n> - sh_serial is using the read/write (readb, writeb, readw, writew,\n> etc.) macros to access I/O registers\n> \n> - sh_eth is using the in/out macros to access I/O registers\n> \n> The in/out macros assume the device registers are little endian, so\n> when the CPU is running big endian, they do an endianness conversion.\n> However, on SuperH, when the CPU runs big endian, the device registers\n> are also big endian, so there should be no endianness conversion.\n> \n> On the other hand, read/write, when __mem_pci is not defined, do not do\n> any endianness conversion. And this is why sh_serial was working out of\n> the box. Changing sh_eth to use read/write instead of in/out also made\n> it work in big endian mode.\n> \n> However, if for some reason I enable PCI on this platform, __mem_pci\n> will be defined, and read/write will perform endianness conversion,\n> breaking support for the platform.\n> \n> So what is the appropriate solution here? Use read/write like sh_serial\n> is doing today, and ignore the potential problem? Use __raw_*()\n> variants everywhere? What if a driver is shared with another\n> platform/architecture where the devices remain little endian even if\n> the CPU is running big endian?\n> \n> Best regards,\n> \n> Thomas\n> \n> For the record, here is the current patch I have on sh_eth (a few other\n> changes are needed, but not directly related) :\n> \n> diff --git a/drivers/net/sh_eth.h b/drivers/net/sh_eth.h\n> index a09a6d7..0e65f97 100644\n> --- a/drivers/net/sh_eth.h\n> +++ b/drivers/net/sh_eth.h\n> @@ -675,11 +675,11 @@ static inline unsigned long sh_eth_reg_addr(struct sh_eth_dev *eth,\n> static inline void sh_eth_write(struct sh_eth_dev *eth, unsigned long data,\n> int enum_index)\n> {\n> - outl(data, sh_eth_reg_addr(eth, enum_index));\n> + writel(data, sh_eth_reg_addr(eth, enum_index));\n> }\n> \n> static inline unsigned long sh_eth_read(struct sh_eth_dev *eth,\n> int enum_index)\n> {\n> - return inl(sh_eth_reg_addr(eth, enum_index));\n> + return readl(sh_eth_reg_addr(eth, enum_index));\n> }\n> \n> \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xsxCB08Ltz9sxR\n\tfor ;\n\tThu, 14 Sep 2017 08:28:37 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid D45F9C21FD4; Wed, 13 Sep 2017 22:28:32 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id E1995C21D58;\n\tWed, 13 Sep 2017 22:28:29 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 83A84C21F88; Wed, 13 Sep 2017 22:28:16 +0000 (UTC)","from mail.free-electrons.com (mail.free-electrons.com [62.4.15.54])\n\tby lists.denx.de (Postfix) with ESMTP id B464EC22061\n\tfor ; Wed, 13 Sep 2017 22:28:16 +0000 (UTC)","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 7E26320997; Thu, 14 Sep 2017 00:28:16 +0200 (CEST)","from windsurf (unknown [12.145.98.253])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 969AA20982;\n\tThu, 14 Sep 2017 00:28:15 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=0.0 required=5.0 tests=none autolearn=unavailable\n\tautolearn_force=no version=3.4.0","Date":"Thu, 14 Sep 2017 00:28:10 +0200","From":"Thomas Petazzoni ","To":"Nobuhiro Iwamatsu ,\n\tVladimir Zapolskiy ","Message-ID":"<20170914002810.38a35cd3@windsurf>","In-Reply-To":"<20170828143249.4c0791df@windsurf>","References":"<20170828143249.4c0791df@windsurf>","Organization":"Free Electrons","X-Mailer":"Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)","MIME-Version":"1.0","Cc":"u-boot@lists.denx.de","Subject":"Re: [U-Boot] I/O accessors on SuperH and endianness","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}}]