eed to check it and remove the iommu parameter everywhere.
Yes, that's much better than exposing the iommu ops to a place that
should not care about them:
Acked-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infrad
> Thanks for your patch, which is now commit 322dbe898f82fd8a
> ("ARM: dma-mapping: split out arch_dma_mark_clean() helper") in
> esmil/jh7100-dmapool.
Well, something is wrong with that branch then, and this series still
needs more work, and should eventually be merged through the dma-mapping
On Tue, May 30, 2023 at 05:25:01PM +0800, Baoquan He wrote:
> On 05/16/23 at 11:31pm, Christoph Hellwig wrote:
> > > +#define ioremap ioremap
> > > +#define ioremap_prot ioremap_prot
> > > +#define iounmap iounmap
> >
> > Nit: I think it's
> +#define ioremap ioremap
> +#define ioremap_prot ioremap_prot
> +#define iounmap iounmap
Nit: I think it's cleaner to have these #defines right next to the
function declaration.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
___
l
> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
> {
> + dma_cache_wback(paddr, size);
> +}
>
> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
> +{
> + dma_cache_inv(paddr, size);
> }
> +static inline void
Thanks, this is long overdue!
Acked-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Fri, Jun 24, 2022 at 10:50:33AM +0530, Anshuman Khandual wrote:
> > On most architectures this should be const now, only very few ever
> > modify it.
>
> Will make it a 'static const pgprot_t protection_map[16] __ro_after_init'
> on platforms that do not change the protection_map[] even during
On Fri, Jun 24, 2022 at 10:13:13AM +0530, Anshuman Khandual wrote:
> vm_get_page_prot(), in order for it to be reused on platforms that do not
> require custom implementation. Finally, ARCH_HAS_VM_GET_PAGE_PROT can just
> be dropped, as all platforms now define and export vm_get_page_prot(), via
>
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Fri, Jun 24, 2022 at 10:13:15AM +0530, Anshuman Khandual wrote:
> This just converts the generic vm_get_page_prot() implementation into a new
> macro i.e DECLARE_VM_GET_PAGE_PROT which later can be used across platforms
> when enabling them with ARCH_HAS_VM_GET_PAGE_PROT. This does not create
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
s/maining/remaining/ ?
Or maybe rather:
uaccess: remove CONFIG_SET_FS
because it is all gone now.
> With CONFIG_SET_FS gone, so drop all remaining references to
> set_fs()/get_fs(), mm_segment_t and uaccess_kernel().
And this sentence does not parse.
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Wed, Feb 16, 2022 at 02:13:28PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> test_kernel_ptr() uses access_ok() to figure out if a given address
> points to user space instead of kernel space. However on architectures
> that set CONFIG_ALTERNATE_USER_ADDRESS_SPACE, a pointer can be
> +#include
Instead of the asm-generic games, shouldn't we just define access_ok in
if not already defined by the architecture?
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
t up put_user() along the same lines as __get_user()/get_user()
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
he normal access_ok()
> though, because on x86 that contains a WARN_ON_IN_IRQ() check that cannot
> be used inside of NMI context while tracing.
>
> Suggested-by: Al Viro
> Suggested-by: Christoph Hellwig
> Link: https://lore.kernel.org/lkml/ygsukcxgr7r4n...@zeniv-ca.linux.org.uk/
an extraneous
> check in __get_user(), but lost the check it needs in
> __put_user().
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Tue, Feb 15, 2022 at 12:37:41AM +, Al Viro wrote:
> Perhaps simply wrap that sucker into #ifdef CONFIG_CPU_HAS_ADDRESS_SPACES
> (and trim the comment down to "coldfire and 68000 will pick generic
> variant")?
I wonder if we should invert CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE,
On Mon, Feb 14, 2022 at 08:45:52PM +0100, Arnd Bergmann wrote:
> As Al pointed out, they turned out to be necessary on sparc64, but the only
> definitions are on sparc64 and x86, so it's possible that they serve a similar
> purpose here, in which case changing the limit from TASK_SIZE to
>
> void prom_world(int enter)
> {
> - if (!enter)
> - set_fs(get_fs());
> -
> __asm__ __volatile__("flushw");
> }
The enter argument is now unused.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
On Mon, Feb 14, 2022 at 05:34:48PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> On almost all architectures, there are no remaining callers
> of set_fs(), so CONFIG_SET_FS can be disabled, along with
> removing the thread_info field and any references to it.
>
> This turns access_ok()
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Mon, Feb 14, 2022 at 05:34:42PM +0100, Arnd Bergmann wrote:
> +#define __range_not_ok(addr, size, limit)(!__access_ok(addr, size))
> +#define __chk_range_not_ok(addr, size, limit)(!__access_ok((void
> __user *)addr, size))
Can we just kill these off insted of letting themm
On Mon, Feb 14, 2022 at 05:34:41PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The get_user()/put_user() functions are meant to check for
> access_ok(), while the __get_user()/__put_user() functions
> don't.
>
> This broke in 4.19 for nds32, when it gained an extraneous
> check in
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Tue, Feb 01, 2022 at 05:55:36PM +0300, Sergey Matyukevich wrote:
> From: Sergey Matyukevich
>
> Use BUILD_BUG for compile-time check of invalid sizes passed
> to get_user/put_user functions.
Looks good:
Reviewed-by: Christoph Hellwig
_
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Tue, Feb 01, 2022 at 05:55:37PM +0300, Sergey Matyukevich wrote:
> From: Sergey Matyukevich
>
> Implement the non-faulting kernel access helpers directly
> instead of using uaccess routines under set_fs(KERNEL_DS).
>
> Signed-off-by: Sergey Matyukevich
> ---
>
Hi all,
you are in this list because your architecture still implements and
uses address space overrides using set_fs(), which are deprecated and
have been removed from all mainstream architecture ports. To help
cleanup the core kernel it would be great to make progress on removing
set_fs
On Thu, Jul 22, 2021 at 02:48:13PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> As these are now in asm-generic, it's no longer necessary to
> declare them in the architecture.
Looks good,
Reviewed-by: Christoph Hellwig
___
li
how far to take this series.
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
ces the potential for subtle bugs.
>
> Reviewed-by: Geert Uytterhoeven
> Acked-by: Geert Uytterhoeven
> Signed-off-by: Arnd Bergmann
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.or
or aligned data, and it lacks a checks
> for user_addr_max().
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
lacks a checks for
> user_addr_max().
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
and its checks for user_addr_max()
> differ from the generic code.
>
> Signed-off-by: Arnd Bergmann
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
pparently lacks a check
> for user_addr_max().
>
> Signed-off-by: Arnd Bergmann
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu, Jul 22, 2021 at 02:48:07PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This function is never called because h8300 uses the asm-generic
> inline function version.
>
> Signed-off-by: Arnd Bergmann
Looks good,
Reviewed-by:
Looks good,
Reviewed-by: Christoph Hellwig
Note that the uml version has a minor conflict with my pending set_fs()
removal for uml, but that should be easy to resolve.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http
On Sat, May 15, 2021 at 12:18:01PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most per-architecture versions of these functions are broken
> in some form, and they are almost certainly slower than the
> generic code as well.
>
> This version is fairly slow because it always does byte
On Sat, May 15, 2021 at 12:18:00PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most per-architecture versions of these functions are broken in some form,
> and they are almost certainly slower than the generic code as well.
>
> Remove the ones for hexagon and instead use the generic
I generall like this consolidation, but for the patches that remote
the arch / asm-generic versions, can you please elaborate a little
more why the lib version is preferable? The current commit logs are
not very informative.
___
linux-snps-arc mailing
On Wed, Dec 02, 2020 at 10:46:28AM +0200, Mike Rapoport wrote:
> On Wed, Dec 02, 2020 at 08:43:26AM +0000, Christoph Hellwig wrote:
> > On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote:
> > > > That's a lot of typos in that patch... I wonder wh
On Wed, Dec 02, 2020 at 09:45:24AM +0100, John Paul Adrian Glaubitz wrote:
> > I've never got results. Which is annoying, as debian doesn't ship an
> > ia64 cross toolchain either, and I can't find any pre-built one that
> > works for me.
>
> The ia64 toolchain available from kernel.org works
On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote:
> > That's a lot of typos in that patch... I wonder why the buildbot hasn't
> > complained about this. Thanks for fixing this up! I'm going to fold this
> > into the original to avoid the breakage.
>
> Does l...@intel.com do ia64
On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
> This is achieved by:
...
>
> - Consolidating all kmap atomic implementations in generic code
...
> Though I wanted to share the current state of affairs before investigating
> that further. If there is consensus in going
> +# ifndef ARCH_NEEDS_KMAP_HIGH_GET
> +static inline void *arch_kmap_temporary_high_get(struct page *page)
> +{
> + return NULL;
> +}
> +# endif
Turn this into a macro and use #ifndef on the symbol name?
> +static inline void __kunmap_atomic(void *addr)
> +{
> +
On Sat, Sep 19, 2020 at 11:17:52AM +0200, Thomas Gleixner wrote:
> Nothing in modules can use that.
>
> Signed-off-by: Thomas Gleixner
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infr
e kmap_prot either as a
> define or exported symbol.
>
> Signed-off-by: Ira Weiny
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
gt;
> Signed-off-by: Ira Weiny
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Sun, May 03, 2020 at 06:09:09PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> We want to support kmap_atomic_prot() on all architectures and it makes
> sense to define kmap_atomic() to use the default kmap_prot.
>
> So we ensure all arch's have a globally available kmap_prot either
tomic(). Lift this code into the
> kunmap_atomic() macro.
>
> While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
> be consistent.
>
> Signed-off-by: Ira Weiny
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc maili
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
truct page *page, pgprot_t prot);
> +extern void *kmap_atomic_high_prot(struct page *page, pgprot_t prot);
> +void *kmap_atomic_prot(struct page *page, pgprot_t prot)
Shouldn't this be marked inline?
The rest looks fine:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
In addition to the work already it the series, it seems like
LAST_PKMAP_MASK, PKMAP_ADDR and PKMAP_NR can also be consolidated
to common code.
Also kmap_atomic_high_prot / kmap_atomic_pfn could move into common
code, maybe keyed off a symbol selected by the actual users that
need it. It also
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
change the name to
> kmap_atomic_high_prot() to match.
>
> Then define kmap_atomic_prot() as a core function which calls
> kmap_atomic_high_prot() when needed.
>
> Finally, redefine kmap_atomic() as a wrapper of kmap_atomic_prot() with
> the default kmap_prot exported by the architectures.
t; rather than a hard coded value which was equal.
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
> --- a/arch/sparc/mm/highmem.c
> +++ b/arch/sparc/mm/highmem.c
> @@ -33,6 +33,7 @@
> #include
>
> pgprot_t kmap_prot;
> +EXPORT_SYMBOL(kmap_prot);
Btw, I don't see why sparc needs this as a variable, as there is just
a single assignment to it.
If sparc is sorted out we can always make it a
tomic(). Lift this code into the
> kunmap_atomic() macro.
>
> While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
> be consistent.
>
> Signed-off-by: Ira Weiny
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc maili
lls the arch specific kmap_atomic_high() when the page is high memory.
>
> Signed-off-by: Ira Weiny
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
nmap() on a number of
> architectures to be an inline call rather than an actual function.
>
> Signed-off-by: Ira Weiny
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.inf
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
> + BUILD_BUG_ON(PKMAP_BASE <
> + TLBTEMP_BASE_1 + TLBTEMP_SIZE);
This can fit on a single line. Otherwise looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http
ns such that they can be made generic in subsequent
> patches.
>
> Reviewed-by: Dan Williams
> Signed-off-by: Ira Weiny
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lis
On Wed, Apr 29, 2020 at 03:11:22PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The commit f47ac088c406 ("mm: memmap_init: iterate over memblock regions
> rather that check each PFN") made early_pfn_in_nid() obsolete and since
> CONFIG_NODES_SPAN_OTHER_NODES is only used to pick a stub
On Sun, Apr 26, 2020 at 06:16:30PM -0700, Ira Weiny wrote:
> > That might require to support
> > kmap_atomic_prot everywhere first, which sounds like a really good
> > idea anyway, and would avoid the need for strange workaround in drm.
>
> Having a kmap_atomic_prot() seems like a good idea. But
> diff --git a/arch/arc/mm/highmem.c b/arch/arc/mm/highmem.c
> index 4db13a6b9f3b..1cae4b911a33 100644
> --- a/arch/arc/mm/highmem.c
> +++ b/arch/arc/mm/highmem.c
> @@ -53,11 +53,10 @@ void *kmap_atomic(struct page *page)
> {
> int idx, cpu_idx;
> unsigned long vaddr;
> + void
On Sat, Apr 25, 2020 at 10:54:03PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap code for all the architectures is almost 100% identical.
>
> Lift the common code to the core. Use ARCH_HAS_KMAP to indicate if an
> arch needs a special kmap.
Can you add a kmap_flush_tlb hook
On Mon, Nov 11, 2019 at 11:27:27AM +0100, Arnd Bergmann wrote:
> 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.
I don't think we
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
On Fri, Nov 08, 2019 at 03:52:48PM +1100, Stephen Rothwell wrote:
> Hi Christoph,
>
> On Fri, 8 Nov 2019 13:20:00 +1100 Stephen Rothwell
> wrote:
> >
> > On Thu, 7 Nov 2019 21:47:43 +0100 Christoph Hellwig wrote:
> > >
> > > can you add the
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
Hi folks,
can I get a few more reviews? Especially for the actual generic
ioremap implementation and the asm-generic bits? I'd love to be able
to queue this up for linux-next some time this week.
___
linux-snps-arc mailing list
On Mon, Oct 21, 2019 at 03:58:28PM +0800, Guo Ren wrote:
> Acked-by: Guo Ren
Can you also take a look at the next patch and give me a review?
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
Use the generic ioremap_prot and iounmap helpers.
Signed-off-by: Christoph Hellwig
---
arch/csky/Kconfig | 1 +
arch/csky/include/asm/io.h | 8 +++---
arch/csky/include/asm/pgtable.h | 4 +++
arch/csky/mm/ioremap.c | 45 -
4 files
No driver that can be used on csky uses ioremap_cache, and this
interface has been deprecated in favor of memremap.
Signed-off-by: Christoph Hellwig
Acked-by: Guo Ren
---
arch/csky/include/asm/io.h | 2 --
arch/csky/mm/ioremap.c | 7 ---
2 files changed, 9 deletions(-)
diff --git
Use the generic ioremap_prot and iounmap helpers.
Note that the io.h include in pgtable.h had to be removed to not create
an include loop. As far as I can tell there was no need for it to
start with.
Signed-off-by: Christoph Hellwig
---
arch/nds32/Kconfig | 1 +
arch/nds32
Use the generic ioremap code instead of providing a local version.
Note that this relies on the asm-generic no-op definition of
pgprot_noncached.
Signed-off-by: Christoph Hellwig
Reviewed-by: Paul Walmsley
Tested-by: Paul Walmsley # rv32, rv64 boot
Acked-by: Paul Walmsley # arch/riscv
A lot of architectures reuse the same simple ioremap implementation, so
start lifting the most simple variant to lib/ioremap.c. It provides
ioremap_prot and iounmap, plus a default ioremap that uses prot_noncached,
although that can be overridden by asm/io.h.
Signed-off-by: Christoph Hellwig
No need to indirect iounmap for sh.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/io.h | 9 ++---
arch/sh/mm/ioremap.c | 4 ++--
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index ac0561960c52..1495489225ac
No need to indirect iounmap for nios2.
Signed-off-by: Christoph Hellwig
---
arch/nios2/include/asm/io.h | 7 +--
arch/nios2/mm/ioremap.c | 6 +++---
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/nios2/include/asm/io.h b/arch/nios2/include/asm/io.h
index
No need to indirect iounmap for hexagon.
Signed-off-by: Christoph Hellwig
---
arch/hexagon/include/asm/io.h | 7 +--
arch/hexagon/kernel/hexagon_ksyms.c | 2 +-
arch/hexagon/mm/ioremap.c | 2 +-
3 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/hexagon
m68k uses __iounmap as the name for an internal helper that is only
used for some CPU types. Mark it static, give it a better name
and move it around a bit to avoid a forward declaration.
Signed-off-by: Christoph Hellwig
---
arch/m68k/include/asm/kmap.h | 1 -
arch/m68k/mm/kmap.c
* defintions needs to be changed to purely cpp
macros instea of inlines to cover for architectures like openrisc
that only define ioremap after including .
Signed-off-by: Christoph Hellwig
---
arch/arc/include/asm/io.h| 4
arch/arm/include/asm/io.h| 1 -
arch/arm64/include/asm
__ioremap is always called with the _PAGE_NO_CACHE, so fold the whole
thing and rename it to ioremap. This also allows to remove the special
EISA quirk to force _PAGE_NO_CACHE.
Signed-off-by: Christoph Hellwig
---
arch/parisc/include/asm/io.h | 11 +--
arch/parisc/mm/ioremap.c | 10
Use ioremap as the main implemented function, and defined
ioremap_nocache to it as a deprecated alias.
Signed-off-by: Christoph Hellwig
---
arch/xtensa/include/asm/io.h | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/xtensa/include/asm/io.h b/arch/xtensa
ioremap_uc is atyfb which probably doesn't show up on nommu
devices.
Signed-off-by: Christoph Hellwig
---
include/asm-generic/io.h | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index
Use ioremap() as the main implemented function, and defines
ioremap_nocache() as a deprecated alias of ioremap() in
preparation of removing ioremap_nocache() entirely.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/io.h | 8 ++--
arch/x86/mm/ioremap.c | 8
arch/x86
No need for the additional namespace pollution.
Signed-off-by: Christoph Hellwig
---
arch/alpha/include/asm/io.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index af2c0063dc75..1989b946a28d 100644
--- a/arch/alpha/include
Use ioremap as the main implemented function, and defined
ioremap_nocache to it as a deprecated alias.
Signed-off-by: Christoph Hellwig
---
arch/hexagon/include/asm/io.h | 11 ++-
arch/hexagon/kernel/hexagon_ksyms.c | 2 +-
arch/hexagon/mm/ioremap.c | 2 +-
3 files
implements ioremap_uc in a similar way as the ia64
version of ioremap_nocache, in that it ignores the firmware tables.
Switch ia64 to override ioremap_uc instead.
Signed-off-by: Christoph Hellwig
---
arch/ia64/include/asm/io.h | 6 +++---
arch/ia64/mm/ioremap.c | 4 ++--
2 files changed, 5 insertions
1 - 100 of 455 matches
Mail list logo
