Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
- Subject: Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU
- From: Arnd Bergmann <arnd@xxxxxxxx>
- Date: Mon, 11 Nov 2019 11:31:05 +0100
- Cc: Palmer Dabbelt <palmer@xxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxx>, "linux-ia64@xxxxxxxxxxxxxxx" <linux-ia64@xxxxxxxxxxxxxxx>, Linux-sh list <linux-sh@xxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Guo Ren <guoren@xxxxxxxxxx>, sparclinux <sparclinux@xxxxxxxxxxxxxxx>, linux-riscv@xxxxxxxxxxxxxxxxxxx, Vincent Chen <deanbo422@xxxxxxxxx>, Linux-Arch <linux-arch@xxxxxxxxxxxxxxx>, linux-s390 <linux-s390@xxxxxxxxxxxxxxx>, "open list:QUALCOMM HEXAGON..." <linux-hexagon@xxxxxxxxxxxxxxx>, "the arch/x86 maintainers" <x86@xxxxxxxxxx>, arcml <linux-snps-arc@xxxxxxxxxxxxxxxxxxx>, linux-xtensa@xxxxxxxxxxxxxxxx, linux-m68k <linux-m68k@xxxxxxxxxxxxxxx>, Openrisc <openrisc@xxxxxxxxxxxxxxxxxxxx>, Greentime Hu <green.hu@xxxxxxxxx>, MTD Maling List <linux-mtd@xxxxxxxxxxxxxxxxxxx>, Guan Xuetao <gxt@xxxxxxxxxx>, Linux ARM <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>, Michal Simek <monstr@xxxxxxxxx>, Parisc List <linux-parisc@xxxxxxxxxxxxxxx>, linux-mips@xxxxxxxxxxxxxxx, alpha <linux-alpha@xxxxxxxxxxxxxxx>, "moderated list:NIOS2 ARCHITECTURE" <nios2-dev@xxxxxxxxxxxxxxxxxxxxxx>
- In-reply-to: <CAMuHMdVuDp_8UDeWv8tdPAH5JS84=-yfwZjOk-YQcoYKM9za+w@mail.gmail.com>
- References: <20191029064834.23438-12-hch@lst.de> <mhng-33ea9141-2440-4a2d-8133-62094486fc48@palmer-si-x1c4> <CAMuHMdVuDp_8UDeWv8tdPAH5JS84=-yfwZjOk-YQcoYKM9za+w@mail.gmail.com>
On Wed, Nov 6, 2019 at 7:16 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>
> Hi Palmer,
>
> On Wed, Nov 6, 2019 at 7:11 PM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote:
> > It looks like the difference in prototype between the architectures is between
> >
> > void __iomem *ioremap(resource_size_t, size_t)
> > void __iomem *ioremap(phys_addr_t, size_t)
> > void __iomem *ioremap(phys_addr_t, unsigned long)
> > void __iomem *ioremap(unsigned long, unsigned long)
> >
> > shouldn't they all just be that first one? In other words, wouldn't it be
> > better to always provide the generic ioremap prototype and unify the ports
> > instead?
>
> Agreed. But I'd go for the second one.
Right, phys_addr_t is the correct type here, resource_size_t is just a generic
type that is at least as long as any resource, and usually the same as
phys_addr_t, which is supposed to be used for physical addresses.
Arnd
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]