From: Baoquan He <bhe@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Arnd Bergmann <arnd@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iomem: remove __weak ioremap_cache helper
Date: Thu, 27 Jul 2023 18:21:24 +0800 [thread overview]
Message-ID: <ZMJFJIZrf5tRANLm@MiWiFi-R3L-srv> (raw)
In-Reply-To: <95ce8aa7-46fc-405c-acec-e94e8f93d186@app.fastmail.com>
On 07/27/23 at 10:18am, Arnd Bergmann wrote:
> On Thu, Jul 27, 2023, at 02:21, Baoquan He wrote:
> > On 07/26/23 at 04:54pm, Arnd Bergmann wrote:
> >> From: Arnd Bergmann <arnd@arndb.de>
> >>
> >> No portable code calls into this function any more, and on
> >> architectures that don't use or define their own, it causes
> >> a warning:
> >>
> >> kernel/iomem.c:10:22: warning: no previous prototype for 'ioremap_cache' [-Wmissing-prototypes]
> >> 10 | __weak void __iomem *ioremap_cache(resource_size_t offset, unsigned long size)
> >>
> >> Fold it into the only caller that uses it on architectures
> >> without the #define.
> >>
> >> Note that the fallback to ioremap is probably still wrong on
> >> those architectures, but this is what it's always done there.
> >
> > Do we need to add a definition of ioremap_cache in asm-generic/io.h like
> > ioremap_wc|wt?
> >
> > #ifndef ioremap_cache
> > #define ioremap_cahce ioremap
> > #endif
>
> No, we really want to eliminate ioremap_cache() from the API,
> not make it more visible.
Got it now, thanks a lot for explanation.
>
> > Unless it's for sure that drivers calling ioremap_cache are only built in
> > on those architecures defining it. Or we just want to see the breakage
> > on those ARCH-es so that they will add their own definition.
>
> Right now, it's only possible to call ioremap_cache() on the couple
> of architectures that explicitly declare this in their asm/io.h header
> (arm, arm64, ia64, loongarch, mips, powerpc, sh, x86, and xtensa).
>
> I think we could also go ahead and remove it from sh and xtensa.
Agree, if no actual need of ioremap_cache() on sh and xtensa.
>
> > Not sure if I missed anything when understanding this.
> >
> > drivers/acpi/apei/bert.c: boot_error_region =
> > ioremap_cache(bert_tab->address, region_len);
> > drivers/acpi/apei/einj.c: trigger_tab =
> > ioremap_cache(trigger_paddr, sizeof(*trigger_tab));
> > drivers/acpi/apei/einj.c: trigger_tab =
> > ioremap_cache(trigger_paddr, table_size);
> > drivers/acpi/apei/erst.c: erst_erange.vaddr =
> > ioremap_cache(erst_erange.base,
> > include/acpi/acpi_io.h: return ioremap_cache(phys, size);
>
> acpi is used on x86, arm64 ia64, and loongarch
>
> > drivers/firmware/meson/meson_sm.c: return
> > ioremap_cache(sm_phy_base, size);
>
> arm/arm64 specific
>
> > 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,
>
> All guardeded with an x86 check
>
> > 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/video/fbdev/hyperv_fb.c: fb_virt =
> > ioremap_cache(par->mem->start, screen_fb_size);
>
> x86 and arm64 specific
>
> > 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);
>
> arm/arm64 specific.
>
> There is also one more caller in mips that gets used by dmi:
>
> arch/mips/include/asm/dmi.h:#define dmi_early_remap(x, l) ioremap_cache(x, l)
> arch/mips/include/asm/dmi.h:#define dmi_remap(x, l) ioremap_cache(x, l)
>
> Arnd
>
next prev parent reply other threads:[~2023-07-27 10:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 14:54 [PATCH] iomem: remove __weak ioremap_cache helper Arnd Bergmann
2023-07-27 0:21 ` Baoquan He
2023-07-27 8:18 ` Arnd Bergmann
2023-07-27 10:21 ` Baoquan He [this message]
2023-07-27 10:22 ` Baoquan He
2023-08-01 11:08 ` Christoph Hellwig
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=ZMJFJIZrf5tRANLm@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.