From: "Arnd Bergmann" <arnd@arndb.de>
To: "Yunhui Cui" <cuiyunhui@bytedance.com>
Cc: "Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Anshuman Khandual" <anshuman.khandual@arm.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Ingo Molnar" <mingo@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Ryan Roberts" <ryan.roberts@arm.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"Nam Cao" <namcao@linutronix.de>,
"Björn Töpel" <bjorn@rivosinc.com>,
"Stuart Menefy" <stuart.menefy@codasip.com>,
"Xu Lu" <luxu.kernel@bytedance.com>,
"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
"Samuel Holland" <samuel.holland@sifive.com>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Dawei Li" <dawei.li@shingroup.cn>,
"Mike Rapoport" <rppt@kernel.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [External] Re: [PATCH] riscv: introduce the ioremap_prot() function
Date: Mon, 24 Mar 2025 09:42:35 +0100 [thread overview]
Message-ID: <68644786-ed4b-49b1-9a4c-3318a8fc0c7d@app.fastmail.com> (raw)
In-Reply-To: <CAEEQ3wk95SMxbKQqD08ACaErG9bvUNQ9QOK6KsZSc5xGHRj+pQ@mail.gmail.com>
On Mon, Mar 24, 2025, at 02:30, yunhui cui wrote:
> On Thu, Mar 20, 2025 at 5:22 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h
>> > index a0e51840b9db..736c5557bd06 100644
>> > --- a/arch/riscv/include/asm/io.h
>> > +++ b/arch/riscv/include/asm/io.h
>> > @@ -133,6 +133,8 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw())
>> > #define outsq(addr, buffer, count) __outsq(PCI_IOBASE + (addr), buffer, count)
>> > #endif
>> >
>> > +#define ioremap_prot ioremap_prot
>> > +
>> > #include <asm-generic/io.h>
>> >
>> > #ifdef CONFIG_MMU
>>
>> This feels slightly wrong to me, the "#define foo foo" method
>> is normally used to override a declaration or inline function with
>> another one, but this one only overrides the implementation, not
>> the declaration.
>>
>> I see the same is done on arc, arm64, parisc, powerpc, s390,
>> sh and xtensa, so we can keep this one as well, but it would be
>> nice to change all of these to a less surprising approach.
>>
>> Maybe we should just remove these macros from asm/io.h and
>> the trivial wrapper from mm/ioremap.c, and instead change the
>> other architectures that have GENERIC_IOREMAP to use
>>
>> #define ioremap_prot generic_ioremap_prot
>>
>> It seems this would be only csky, hexagon, (some) loongarch
>> and openrisc.
>
> It seems that we can't simply use #define ioremap_prot
> generic_ioremap_prot because some architectures have certain special
> behaviors before calling generic_ioremap_prot(). For example, there's
> the ioremap_prot_hook() logic on ARM64 and the CONFIG_EISA logic on
> PA-RISC, among others.
I meant only the four that I have listed above should do
the "#define ioremap_prot generic_ioremap_prot", while the
ones that have some special case would continue to provide
their own implementation.
> Regarding the check of whether the address is a memory address, I
> think we can directly incorporate pfn_valid() into
> generic_ioremap_prot. This probably won't affect architectures that
> directly use generic_ioremap_prot(), such as C-SKY, Hexagon, and
> LoongArch.
>
> So, my next plan is to add pfn_valid() to generic_ioremap_prot().
Ah right, I see now that x86 does not use CONFIG_GENERIC_IOREMAP,
so it would still be able to have its memremap() fall back to
ioremap_cache().
You should probably still go through the list of drivers
calling ioremap_cache() or ioremap_wt() to see if any of them
might be used on an architecture that defines those two functions
through ioremap_prot(), as that would be broken when they
get called on normal memory:
arch/loongarch/kernel/acpi.c: return ioremap_cache(phys, size);
arch/mips/include/asm/dmi.h:#define dmi_remap(x, l) ioremap_cache(x, l)
arch/powerpc/kernel/crash_dump.c: vaddr = ioremap_cache(paddr, PAGE_SIZE);
arch/powerpc/platforms/pasemi/dma_lib.c: dma_status = ioremap_cache(res.start, resource_size(&res));
arch/powerpc/platforms/powernv/vas-window.c: map = ioremap_cache(start, len);
arch/x86/hyperv/hv_init.c: ghcb_va = (void *)ioremap_cache(ghcb_gpa, HV_HYP_PAGE_SIZE);
arch/x86/kernel/acpi/boot.c: return ioremap_cache(phys, size);
arch/x86/platform/efi/efi_32.c: va = ioremap_cache(md->phys_addr, size);
drivers/acpi/apei/bert.c: boot_error_region = ioremap_cache(bert_tab->address, region_len);
drivers/acpi/apei/einj-core.c: trigger_tab = ioremap_cache(trigger_paddr, sizeof(*trigger_tab));
drivers/acpi/apei/einj-core.c: trigger_tab = ioremap_cache(trigger_paddr, table_size);
drivers/acpi/apei/erst.c: erst_erange.vaddr = ioremap_cache(erst_erange.base,
drivers/firmware/meson/meson_sm.c: return ioremap_cache(sm_phy_base, size);
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: adev->mman.aper_base_kaddr = ioremap_cache(adev->gmc.aper_base,
drivers/gpu/drm/hyperv/hyperv_drm_drv.c: hv->vram = ioremap_cache(hv->mem->start, hv->fb_size);
drivers/gpu/drm/ttm/ttm_bo_util.c: map->virtual = ioremap_cache(res, size);
drivers/gpu/drm/ttm/ttm_bo_util.c: vaddr_iomem = ioremap_cache(mem->bus.offset,
drivers/hv/hv.c: /* Mask out vTOM bit. ioremap_cache() maps decrypted */
drivers/hv/hv.c: (void *)ioremap_cache(base, HV_HYP_PAGE_SIZE);
drivers/hv/hv.c: /* Mask out vTOM bit. ioremap_cache() maps decrypted */
drivers/hv/hv.c: (void *)ioremap_cache(base, HV_HYP_PAGE_SIZE);
drivers/mtd/devices/bcm47xxsflash.c: b47s->window = ioremap_cache(res->start, resource_size(res));
drivers/mtd/maps/pxa2xx-flash.c: info->map.cached = ioremap_cache(info->map.phys, info->map.size);
drivers/soc/fsl/qbman/qman_ccsr.c: void __iomem *tmpp = ioremap_cache(addr, sz);
drivers/video/fbdev/hyperv_fb.c: fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
include/acpi/acpi_io.h: return ioremap_cache(phys, size);
drivers/block/z2ram.c: vaddr = (unsigned long)ioremap_wt(paddr, size);
drivers/video/fbdev/amifb.c: videomemory = (u_long)ioremap_wt(info->fix.smem_start,
drivers/video/fbdev/atafb.c: external_screen_base = ioremap_wt(external_addr, external_len);
drivers/video/fbdev/controlfb.c: p->frame_buffer = ioremap_wt(p->frame_buffer_phys, 0x800000);
drivers/video/fbdev/hpfb.c: fb_start = (unsigned long)ioremap_wt(fb_info.fix.smem_start,
drivers/video/fbdev/platinumfb.c: pinfo->frame_buffer = ioremap_wt(pinfo->rsrc_fb.start, 0x400000);
drivers/video/fbdev/valkyriefb.c: p->frame_buffer = ioremap_wt(frame_buffer_phys, p->total_vram);
Similar, any architecture that doesn't have arch_memremap_wb()
falls back to ioremap_cache() or ioremap(), which then have that
check.
Arnd
next prev parent reply other threads:[~2025-03-24 8:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 8:44 Yunhui Cui
2025-03-20 9:21 ` Arnd Bergmann
2025-03-24 1:30 ` [External] " yunhui cui
2025-03-24 8:42 ` Arnd Bergmann [this message]
2025-03-20 15:41 ` Christoph Hellwig
2025-03-24 1:34 ` [External] " yunhui cui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=68644786-ed4b-49b1-9a4c-3318a8fc0c7d@app.fastmail.com \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=anshuman.khandual@arm.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn@rivosinc.com \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=cuiyunhui@bytedance.com \
--cc=dawei.li@shingroup.cn \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luxu.kernel@bytedance.com \
--cc=mingo@kernel.org \
--cc=namcao@linutronix.de \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=samuel.holland@sifive.com \
--cc=stuart.menefy@codasip.com \
--cc=vincenzo.frascino@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®