Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp7002960ybf; Fri, 6 Mar 2020 08:30:33 -0800 (PST) X-Google-Smtp-Source: ADFU+vvqB9RTUTHNlvi/AyeZgKc2d+4w84FHeYVc6OibPcHinQ536Rne1Cb2bdcwpZtTa/vOE0ye X-Received: by 2002:a54:410e:: with SMTP id l14mr3161802oic.42.1583512232935; Fri, 06 Mar 2020 08:30:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583512232; cv=none; d=google.com; s=arc-20160816; b=OX4wHoJgdehbF216udtJtKNHCLkm5hignIlGdSoR/cQu9qWG3YLFZu6TFtpaGLLZCX QgrQvyDK1Egj2s/CJQB7MqwPZRiwHhBbJrasrCCgodgrdYgP/NlImq9jf8j+mLh+QZgX Y1g9JYK0CopVTbgSmjJo5tQEJKoGcEVQTGoLhSJaRHPlPXTE4fDX4DzWSNH0CQFroZli yNeN3I2m3ZKisUrtmRlsCZr75A0zIzoA6jGGOOOVmR0QXil59JsApsaRpuO4cBr0F2qG rLujXUBc1A20CO4RVVx7tZX1K9DuHiwGM8tDBlfB0w6Jwf6GGj/70haB+2TndC8DwcIv zRFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=M0hTtJNg1/1WTWDIkcqRo/t6Zt7o+G3A5U0m237+a4I=; b=0bK/pmPmoipjoe+2QdFwQqWtqslCobocPLivaYE1S5W7lWM76UFdsdIpDPtIoGpl7V P2IBwq3DreLnj4Mf/phhZ3qFK9jF2+nhbko7gDj+PlfUwYYTCkeos49e6F1H4UAi1p82 nKAcNwSCmgfPEkcl6pChUXLjWnPF6cJSGEyUN12MwfuGgAi0uaBVFkl2GUVBW53XB2uW VjMeX3SpipPIjXmnq3v49cOBgvhWd8cnjaxSR9XDi+oTTjqGaMrpBh0+pQdwcf8uzvJH XDIz8baaZ7zt50cRtnALrP+ecmUM6paxpqAvfhrWQosN63vLzJWGC2FNZ0WGkJO4dHWN pDQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v10si1575650oth.136.2020.03.06.08.30.20; Fri, 06 Mar 2020 08:30:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726875AbgCFQ3q (ORCPT + 99 others); Fri, 6 Mar 2020 11:29:46 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:37703 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726269AbgCFQ3q (ORCPT ); Fri, 6 Mar 2020 11:29:46 -0500 Received: from mail-qk1-f169.google.com ([209.85.222.169]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1N9Mh8-1jOZjg0o4q-015LyN; Fri, 06 Mar 2020 17:29:44 +0100 Received: by mail-qk1-f169.google.com with SMTP id y126so2855061qke.4; Fri, 06 Mar 2020 08:29:43 -0800 (PST) X-Gm-Message-State: ANhLgQ0N/ZaQ4t2ckk3wFHp+PDheCnUZQmJiZRcGRP8ZzsfF0SCy+o88 DTADuhc04YL7i4WmREFGG3IUKhf3LsdJvUEs+xc= X-Received: by 2002:a37:4f8d:: with SMTP id d135mr3716874qkb.394.1583512182964; Fri, 06 Mar 2020 08:29:42 -0800 (PST) MIME-Version: 1.0 References: <2e80d7bc-32a0-cc40-00a9-8a383a1966c2@huawei.com> <8207cd51-5b94-2f15-de9f-d85c9c385bca@huawei.com> <6115fa56-a471-1e9f-edbb-e643fa4e7e11@kernel.org> <7c955142-1fcb-d99e-69e4-1e0d3d9eb8c3@huawei.com> <90af535f-00ef-c1e3-ec20-aae2bd2a0d88@kernel.org> <182a37c2-7437-b1bd-8b86-5c9ce2e29f00@huawei.com> In-Reply-To: <182a37c2-7437-b1bd-8b86-5c9ce2e29f00@huawei.com> From: Arnd Bergmann Date: Fri, 6 Mar 2020 17:29:26 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: About commit "io: change inX() to have their own IO barrier overrides" To: John Garry Cc: Sinan Kaya , "xuwei (O)" , Bjorn Helgaas , "linux-kernel@vger.kernel.org" , Jiaxun Yang , linux-arch , Linux ARM , Will Deacon , Catalin Marinas Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:HxNrfgizwilzuaEfId2WyjkjMWUD7n9oZHcRz0+eo6fPGukg5XV 0bdNkylKcnXn0RUfLEWfjMJZcU4NSkX8OXweksi6R5dvw1nD4MXaNbYH1fSeDMVuT2fjQd3 6w7hV0NcbSAl0yX77/DcYUSdMgmFc4qZjYsfILewSs+SYsVk00/lwyeH7tWWzhRQ4AgmseQ c3P1/2mNEB8q1h71kUCEw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:g0hqxFEAWIE=:0eeRMHbAnBqjB1y4GK5K/I lkNuuzv8mkRHdGNQo052dgFIBLRkrws1nZSEJv7XJPUz60OnH1l8KLT/NtV7ViKlaBZUyjr3/ Va/rscPkp1N2kbbxBc+eA1XVM8MQ0FDbKYcG15UX2hjwYkqJMLt/UH3zuq11qALOBnJuo4i4U WjdY4hxZCogkr0p1+8SBbcbhBIE3enjtal2YwQ9Bl3LmWU3XalM0OvwOoAFIrtbHiAE2d8+3F ArWztBBBJKa6TiFcYJrdHI0DDl0305SZ318hCOi6TTcrsN/rv3BOuyMobj36CMguAR9FuJqrS hhhDyzpFa6X7vSEu3oxClgLIrvs7pJaOCf7SgKu1xZ8xIjUTkORym7QSLT3g36iF6tlv7FnGg tdC8pMozA69iOGh6jn4e9/xAO3R2B4kOzYQ1ree6VmH2NPiAkE0JKhcKxHytmcwfzHmMis7PP g6+3Q8IV0eZx2eVQq1cHWzS2MltYxwuZvUZ0rN0QWqFqjktcycdGgwiBvCONEiQLF0vQ2Zuol OKttx7vK2mBDsexo8cVg2pXxs7qg97ybGB/zVmbvksMz9IWsPhP3bWFVo1BYV58+gs/H29w7e gKKH4yf9QX+fySDaSTwuc6vpG5COjexi2e1m0YRftyyPTOTBDevUxVKkW+MGBx4Sq9ANgYNU1 VPSTpai41awUGcn4m8euXKFblbMkndq5V2fcZM5WwnTLHHv3RoJ9L1Wmx6B56e76Jx+oX+OhG aIPnrepWITqcPtA1SOXB8qXEEVqy86lWKmiJBLAJ3LMYkRNMXRSa2xK4uZlN67fq3p3go2csT bTX2a5Jmqvb+tTOV3e0iOlrsd88q2jBlUlpDw1x+lStYzaxCnA= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 6, 2020 at 5:18 PM John Garry wrote: > On 06/03/2020 15:16, Arnd Bergmann wrote: > > On Fri, Mar 6, 2020 at 11:40 AM John Garry wrote: > >> On 06/03/2020 07:54, Arnd Bergmann wrote: > >>> On Fri, Mar 6, 2020 at 4:44 AM Sinan Kaya wrote: > >> -- a/lib/logic_pio.c > >> +++ b/lib/logic_pio.c > >> @@ -229,13 +229,21 @@ unsigned long > >> logic_pio_trans_cpuaddr(resource_size_t addr) > >> } > >> > >> #if defined(CONFIG_INDIRECT_PIO) && defined(PCI_IOBASE) > >> + > >> +#define logic_in_to_cpu_b(x) (x) > >> +#define logic_in_to_cpu_w(x) __le16_to_cpu(x) > >> +#define logic_in_to_cpu_l(x) __le32_to_cpu(x) > >> + > >> #define BUILD_LOGIC_IO(bw, type) \ > > Note: The "bw" argument name could be improved to "bwl", since this > macro is used for building inl() also. > > >> type logic_in##bw(unsigned long addr) \ > >> { \ > >> type ret = (type)~0; \ > >> \ > >> if (addr < MMIO_UPPER_LIMIT) { \ > >> - ret = read##bw(PCI_IOBASE + addr); \ > >> + void __iomem *_addr = PCI_IOBASE + addr; \ > >> + __io_pbr(); \ > >> + ret = logic_in_to_cpu_##bw(__raw_read##bw(_addr)); \ > >> + __io_par(ret); \ > >> } else if (addr >= MMIO_UPPER_LIMIT && addr < IO_SPACE_LIMIT) {\ > >> struct logic_pio_hwaddr *entry = find_io_rang > >> > >> We could prob combine the le_to_cpu and __raw_read into a single macro. > > > > What is the purpose of splitting out the byteswap rather than leaving the > > open-coded rather than __le16_to_cpu(__raw_readw(PCI_IOBASE + addr))? > > I'm just copying what is in asm-generic io.h, which uses the 16b and 32b > byteswaps in the w and l variants, respectively. Sure, but I don't think that needs another macro. > > The idea is good, but it would be nice if we just somehow use a common > asm-generic io.h definition directly in logic_pio.c, like: > > asm-generic io.h: > > #ifndef __raw_inw // name? > #define __raw_inw __raw_inw > static inline u16 __raw_inw(unsigned long addr) > { > u16 val; > > __io_pbr(); > val = __le16_to_cpu(__raw_readw(addr)); > __io_par(val); > return val; > } > #endif > > #include > > #ifndef inw > #define inw __raw_inw > #endif Yes, makes sense. Maybe __arch_inw() then? Not great either, but I think that's better than __raw_inw() because __raw_* would sound like it mirrors __raw_readl() that lacks the barriers and byteswaps. Arnd