, so add that to the generic version.
Signed-off-by: Christoph Hellwig
---
include/asm-generic/memory_model.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/asm-generic/memory_model.h
b/include/asm-generic/memory_model.h
index a73a140cbecd..6d1fb6162ac1 100644
--- a
with this patch powerpc loses the CONFIG_DEBUG_VIRTUAL pfn_valid
check. It will be added back in a generic version later.
Signed-off-by: Christoph Hellwig
---
arch/alpha/include/asm/io.h | 1 -
arch/arc/include/asm/io.h | 3 ---
arch/arm/include/asm/memory.h | 6 --
page_to_phys is duplicated by all architectures, and from some strange
reason placed in where it doesn't fit at all.
phys_to_page is only provided by a few architectures despite having a lot
of open coded users.
Provide generic versions in to make these
helpers more easily usable.
Changes s
o add that to the generic version.
Signed-off-by: Christoph Hellwig
---
include/asm-generic/memory_model.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/asm-generic/memory_model.h
b/include/asm-generic/memory_model.h
index a73a140cbecdd7..6d1fb6162ac1a6 100644
--- a/in
with this patch powerpc loses the CONFIG_DEBUG_VIRTUAL pfn_valid
check. It will be added back in a generic version later.
Signed-off-by: Christoph Hellwig
---
arch/alpha/include/asm/io.h | 1 -
arch/arc/include/asm/io.h | 3 ---
arch/arm/include/asm/memory.h | 6 --
page_to_phys is duplicated by all architectures, and from some strange
reason placed in where it doesn't fit at all.
phys_to_page is only provided by a few architectures despite having a lot
of open coded users.
Provide generic versions in to make these
helpers more easily usable.
Changes s
On Sun, Oct 13, 2024 at 11:43:41AM +0300, Mike Rapoport wrote:
> > But why? That's pretty different from our normal style of arch hooks,
> > and introduces an indirect call in a security sensitive area.
>
> Will change to __weak hook.
Isn't the callback required when using the large ROX page?
On Thu, Oct 10, 2024 at 03:57:33PM +0300, Mike Rapoport wrote:
> On Wed, Oct 09, 2024 at 11:58:33PM -0700, Christoph Hellwig wrote:
> > On Wed, Oct 09, 2024 at 09:08:15PM +0300, Mike Rapoport wrote:
> > > /**
> > > * struct execmem_info - architecture para
struct module *mod);
Please drop all the pointless externs while you're at it.
Otherwise 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, Oct 10, 2024 at 09:03:42AM +0200, Christoph Hellwig wrote:
> > I think we should try to have a little fewer nested macros
> > to evaluate here, right now this ends up expanding
> > __pfn_to_phys, PFN_PHYS, PAGE_SHIFT, CONFIG_PAGE_SHIFT,
> > page_to_pfn and __page_to
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, Oct 09, 2024 at 02:06:27PM +, Arnd Bergmann wrote:
> This is clearly a good idea, and I'm happy to take that through
> the asm-generic tree if there are no complaints.
>
> Do you have any other patches that depend on it?
Well, I have new code that would benefit from these helpers, but
On Wed, Oct 09, 2024 at 09:08:15PM +0300, Mike Rapoport wrote:
> /**
> * struct execmem_info - architecture parameters for code allocations
> + * @fill_trapping_insns: set memory to contain instructions that will trap
> * @ranges: array of parameter sets defining architecture specific
> * pa
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
amed text-patching.h and add an empty
> header in asm-generic for architectures that do not support text patching.
Looks good:
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.
uct vm_struct *vm);
> +extern __init void vm_area_register_early(struct vm_struct *vm, size_t
> align);
Please drop the externs while you're at it. (one more down below)
Otherwise looks good:
Reviewed-by: Christoph Hellwig
___
li
d-off-by: Christoph Hellwig
---
arch/alpha/include/asm/io.h | 1 -
arch/arc/include/asm/io.h | 3 ---
arch/arm/include/asm/memory.h | 6 --
arch/arm64/include/asm/memory.h | 6 --
arch/csky/include/asm/page.h| 3 ---
arch/hexagon/include/asm/p
page_to_phys is duplicated by all architectures, and from some strange
reason placed in where it doesn't fit at all.
phys_to_page is only provided by a few architectures despite having a lot
of open coded users.
Provide generic versions in to make these
helpers more easily usable.
Diffstat:
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.i
> 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
tre
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 c
> +#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
> +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 arch_dma_cache_wback_inv(phys_
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
On Fri, Jun 24, 2022 at 10:13:29AM +0530, Anshuman Khandual wrote:
index d466ec670e1f..f976580500b1 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -288,6 +288,26 @@ static pmd_t __maybe_unused early_dtb_pmd[PTRS_PER_PMD]
> __initdata __aligned(PAG
> #define early_pg_dir
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 an
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 va
> +#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
http://lists.infradead.org/mailman/listinfo/linux-snps-a
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
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
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/
d 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,
select
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
> TASK_SIZ
> 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
http://lists.i
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() i
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 obsfucat
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 __ge
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
> ---
> arch/arc/include/asm/uaccess.h
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 entirel
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
_
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
ed 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
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
arently 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:02PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Consolidate the asm-generic implementation with the library version
> that is used everywhere else.
>
> These are the three versions for NOMMU kernels,
I don't get the three versions part?
> + select G
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 ve
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 l
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 wond
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 for
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 forwa
> +# 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)
> +{
> + kumap_atomic_indexed(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
ilable 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
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 seem
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
nge 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
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
p() 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
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 o
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 *add
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 e
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
1 - 100 of 509 matches
Mail list logo
