On Wed, Nov 6, 2019 at 7:16 PM Geert Uytterhoeven wrote:
>
> Hi Palmer,
>
> On Wed, Nov 6, 2019 at 7:11 PM Palmer Dabbelt wrote:
> > It looks like the difference in prototype between the architectures is
> > between
> >
> > void __iomem *ioremap(resource_size_t, size_t)
> > void __iomem
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig wrote:
>
> All MMU-enabled ports have a non-trivial ioremap and should thus provide
> the prototype for their implementation instead of providing a generic
> one unless a different symbol is not defined. Note that this only
> affects sparc32 nds32
On Wed, Nov 06, 2019 at 07:16:38PM +0100, Geert Uytterhoeven wrote:
> > 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.
Eventually we s
Hi Palmer,
On Wed, Nov 6, 2019 at 7:11 PM Palmer Dabbelt 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, unsigne
On Mon, 28 Oct 2019 23:48:24 PDT (-0700), Christoph Hellwig wrote:
All MMU-enabled ports have a non-trivial ioremap and should thus provide
the prototype for their implementation instead of providing a generic
one unless a different symbol is not defined. Note that this only
affects sparc32 nds3
