From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A61FC43331 for ; Mon, 11 Nov 2019 10:27:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DF50E21655 for ; Mon, 11 Nov 2019 10:27:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726952AbfKKK1q (ORCPT ); Mon, 11 Nov 2019 05:27:46 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:50365 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726768AbfKKK1q (ORCPT ); Mon, 11 Nov 2019 05:27:46 -0500 Received: from mail-qk1-f176.google.com ([209.85.222.176]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1M5Q6n-1iUvjh2lxF-001RMz for ; Mon, 11 Nov 2019 11:27:44 +0100 Received: by mail-qk1-f176.google.com with SMTP id 71so10727831qkl.0 for ; Mon, 11 Nov 2019 02:27:44 -0800 (PST) X-Gm-Message-State: APjAAAVfU5+bRkeXaCs8gb9/sn8fAbWkboRAcDYHs+7tf0Bu9l3uGqQA Yy86vU1PuDAKcnS+/Gd4OChqSkXAGb4MTtLWfQ0= X-Google-Smtp-Source: APXvYqyGcZLqyAcsV/LYDmC4LmwcrdvTKQ+w9XPWbssEa676VSOvhgPE+TuvbqMkbxFWBQMzT6WHPBHBJZYF9AVQbpE= X-Received: by 2002:a37:4f0a:: with SMTP id d10mr9711437qkb.286.1573468063366; Mon, 11 Nov 2019 02:27:43 -0800 (PST) MIME-Version: 1.0 References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> <20191111101531.GA12294@lst.de> In-Reply-To: <20191111101531.GA12294@lst.de> From: Arnd Bergmann Date: Mon, 11 Nov 2019 11:27:27 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU To: Christoph Hellwig Cc: Guo Ren , Michal Simek , Greentime Hu , Vincent Chen , Guan Xuetao , "the arch/x86 maintainers" , alpha , "open list:SYNOPSYS ARC ARCHITECTURE" , Linux ARM , "open list:QUALCOMM HEXAGON..." , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, "moderated list:NIOS2 ARCHITECTURE" , openrisc@lists.librecores.org, Parisc List , linux-riscv@lists.infradead.org, linux-s390 , Linux-sh list , sparclinux , linux-xtensa@linux-xtensa.org, linux-mtd , linux-arch , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:ks9zRm0iU2bkGdM7msZVRWIVEmZ9bBnUW/dnHPDJQrO3C7wLQWP cpy3PtbAdhnnL7bIcpkftkDTZc4Y08IISrdpQPOlae3Whq/RDiAgF9T29KkPEkHjtEppY9M NVOUVMa6zAp76tzhm/UGRBkxyoEcW2h4u34XjeWUeLe95BhH2wkdh+UwrD7Qu4yOdPwl6Xh Hkfhz09RzjZSkKWroNBIA== X-UI-Out-Filterresults: notjunk:1;V03:K0:YMs5jHbQ3kA=:2KiOoIzuOQpC4Glydszibc hWmzuJ/SvYlCdw/OkoCxsDJYRRtZYQsWySLgpa0MyQGXJA9AjiHhZTMxT84G0Q156D/pQotgG nsCdFrqqVl3HPoBkSYJIwTvh2cEp8C/+/VUD71Jy8PhABtHi6Ftvy8bJNgrXD9zk88PwHLbkO ZhJSV+PopRMBJUuj1+CgBj0ODd/4x4kXUduUrlR3cumwBSZfMvtw0jmleyN1U8PZnFkmBBgml SJt5uprlenPNOEGFWydJiq1dENx97n/KPzw7ZUCVoKfphQa6nOfOqDr4TM3YdOqTxSWx98IqB fkvaZJApRid5HueeL77cUn0enI2KDbGbzoIWEoe/szlRzqBikbh+nGWHzoahlaVnk9GGIoOCo +RYvaqyTLprlRt3NFoXs9mhv4XWXHKeAw3TzOYeb4GfiuCFedybDOZca/py7lcVfKeNHtBvCZ 0Vg9N1ZKOkirvUOatobdGWydk7BIze3ru9Grc2xcoI8W2LbeoJDIJqbJFNtQbnyxzjfyPiIcO trw/UWz3/GWbhEOloUvKNp6pYt7WIR1mC3Jf4CWFtli+b2hd/1qFPEY895D9rlVB71hzHumoC hkAA52EvTiXCnzeYxBz4uqqrQf/LlmGoL8rU2f0yqxgfY/jJrx4NnpOkNzPpxwFOzPUD6b3t1 ut4pDAGNjyupjjGo5Ns1HoBOO3Nkd7bCSX2Nw5RJWHREAa9W6XrCjSscV+Dc+UEf04faOwNWj 77by6VEodytgCkVA3O63QV6Cw8OgEigCV8Bz9aypXChavMF/yXeJ5J6SdDCXaeyP4iFWuU/Ag nimBfV7JyNRxzil7ZqUUS6bAyqiMTUmyR/nEo5bSKP6WBH6jlgTeIx4j3sIHUjBm9W8xy13EO /eGp0waVxbm0Jt2ofnlg== Sender: linux-m68k-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org On Mon, Nov 11, 2019 at 11:15 AM Christoph Hellwig wrote: > > On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > > Maybe we could move the definition into the atyfb driver itself? > > > > As I understand it, the difference between ioremap()/ioremap_nocache() > > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > > anyway. > > That's not how I understood it. Based on the code and the UC- > explanation ioremap_uc always overrides the MTRR, which can still > be present on more modern x86 systems. As I understand, the point is that on PAT-enabled systems, the normal ioremap() *also* overrides the MTRR, citing from Documentation/x86/pat.rst: ==== ======= === ========================= ===================== MTRR Non-PAT PAT Linux ioremap value Effective memory type ==== ======= === ========================= ===================== PAT Non-PAT | PAT |PCD | ||PWT | ||| | WC 000 WB _PAGE_CACHE_MODE_WB WC | WC WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC WC 011 UC _PAGE_CACHE_MODE_UC UC | UC ==== ======= === ========================= ===================== > In fact I remember a patch > floating around very recently adding another ioremap_uc caller in > some Atom platform device driver that works around buggy MTRR > tables. Also this series actually adds a new override and a few > callers for ia64 platform code, which works very similar to x86 > based on the comments in the code. That being said I'm not sure > the callers in ia64 are really required, but it was the safest thing > to do as part of this cleanup. Ok, fair enough. Let's just go with your version for now, if only to not hold your series up more. I'd still suggest we change atyfb to only use ioremap_uc() on i386 and maybe ia64. I can send a patch for that. Arnd