Re: [PATCH V2 11/11] drm: Remove drm specific kmap_atomic code
On Mon, May 4, 2020 at 3:09 AM wrote:
>
> From: Ira Weiny
>
> kmap_atomic_prot() is now exported by all architectures. Use this
> function rather than open coding a driver specific kmap_atomic.
>
> Reviewed-by: Christian König
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Ira Weiny
I'm assuming this lands through some other tree or a topic branch or whatever.
Acked-by: Daniel Vetter
Cheers, Daniel
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c| 56 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 16
> include/drm/ttm/ttm_bo_api.h | 4 --
> 3 files changed, 12 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 52d2b71f1588..f09b096ba4fd 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -257,54 +257,6 @@ static int ttm_copy_io_page(void *dst, void *src,
> unsigned long page)
> return 0;
> }
>
> -#ifdef CONFIG_X86
> -#define __ttm_kmap_atomic_prot(__page, __prot) kmap_atomic_prot(__page,
> __prot)
> -#define __ttm_kunmap_atomic(__addr) kunmap_atomic(__addr)
> -#else
> -#define __ttm_kmap_atomic_prot(__page, __prot) vmap(&__page, 1, 0, __prot)
> -#define __ttm_kunmap_atomic(__addr) vunmap(__addr)
> -#endif
> -
> -
> -/**
> - * ttm_kmap_atomic_prot - Efficient kernel map of a single page with
> - * specified page protection.
> - *
> - * @page: The page to map.
> - * @prot: The page protection.
> - *
> - * This function maps a TTM page using the kmap_atomic api if available,
> - * otherwise falls back to vmap. The user must make sure that the
> - * specified page does not have an aliased mapping with a different caching
> - * policy unless the architecture explicitly allows it. Also mapping and
> - * unmapping using this api must be correctly nested. Unmapping should
> - * occur in the reverse order of mapping.
> - */
> -void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot)
> -{
> - if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
> - return kmap_atomic(page);
> - else
> - return __ttm_kmap_atomic_prot(page, prot);
> -}
> -EXPORT_SYMBOL(ttm_kmap_atomic_prot);
> -
> -/**
> - * ttm_kunmap_atomic_prot - Unmap a page that was mapped using
> - * ttm_kmap_atomic_prot.
> - *
> - * @addr: The virtual address from the map.
> - * @prot: The page protection.
> - */
> -void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot)
> -{
> - if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
> - kunmap_atomic(addr);
> - else
> - __ttm_kunmap_atomic(addr);
> -}
> -EXPORT_SYMBOL(ttm_kunmap_atomic_prot);
> -
> static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src,
> unsigned long page,
> pgprot_t prot)
> @@ -316,13 +268,13 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm,
> void *src,
> return -ENOMEM;
>
> src = (void *)((unsigned long)src + (page << PAGE_SHIFT));
> - dst = ttm_kmap_atomic_prot(d, prot);
> + dst = kmap_atomic_prot(d, prot);
> if (!dst)
> return -ENOMEM;
>
> memcpy_fromio(dst, src, PAGE_SIZE);
>
> - ttm_kunmap_atomic_prot(dst, prot);
> + kunmap_atomic(dst);
>
> return 0;
> }
> @@ -338,13 +290,13 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm,
> void *dst,
> return -ENOMEM;
>
> dst = (void *)((unsigned long)dst + (page << PAGE_SHIFT));
> - src = ttm_kmap_atomic_prot(s, prot);
> + src = kmap_atomic_prot(s, prot);
> if (!src)
> return -ENOMEM;
>
> memcpy_toio(dst, src, PAGE_SIZE);
>
> - ttm_kunmap_atomic_prot(src, prot);
> + kunmap_atomic(src);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> index bb46ca0c458f..94d456a1d1a9 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> @@ -374,12 +374,12 @@ static int vmw_bo_cpu_blit_line(struct
> vmw_bo_blit_line_data *d,
> copy_size = min_t(u32, copy_size, PAGE_SIZE -
> src_page_offset);
>
> if (unmap_src) {
> - ttm_kunmap_atomic_prot(d->src_addr, d->src_prot);
> + kunmap_atomic(d->src_addr);
> d->src_addr = NULL;
> }
>
> if (unmap_dst) {
> - ttm_kunmap_atomic_prot(d->dst_addr, d->dst_prot);
> + kunmap_atomic(d->dst_addr);
> d->dst_addr = NULL;
> }
>
> @@ -388,8 +388,8 @@ static int vmw_bo_cpu_blit_line(struct
> vmw_bo_blit_line_data *d,
> return -EINVAL;
>
> d->dst_addr =
> - ttm_kmap_atomic_prot(d->dst_pages[dst_page],
> -
Re: [PATCH v2 17/20] mm: free_area_init: allow defining max_zone_pfn in descending order
On Sun, May 03, 2020 at 11:43:00AM -0700, Guenter Roeck wrote:
> On Sun, May 03, 2020 at 10:41:38AM -0700, Guenter Roeck wrote:
> > Hi,
> >
> > On Wed, Apr 29, 2020 at 03:11:23PM +0300, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the
> > > ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is
> > > sorted in descending order allows using free_area_init() on such
> > > architectures.
> > >
> > > Add top -> down traversal of max_zone_pfn array in free_area_init() and
> > > use
> > > the latter in ARC node/zone initialization.
> > >
> > > Signed-off-by: Mike Rapoport
> >
> > This patch causes my microblazeel qemu boot test in linux-next to fail.
> > Reverting it fixes the problem.
> >
> The same problem is seen with s390 emulations.
Yeah, this patch breaks some others as well :(
My assumption that max_zone_pfn defines architectural limit for maximal
PFN that can belong to a zone was over-optimistic. Several arches
actually do that, but others do
max_zone_pfn[ZONE_DMA] = MAX_DMA_PFN;
max_zone_pfn[ZONE_NORMAL] = max_pfn;
where MAX_DMA_PFN is build-time constrain and max_pfn is run time limit
for the current system.
So, when max_pfn is lower than MAX_DMA_PFN, the free_init_area() will
consider max_zone_pfn as descending and will wrongly calculate zone
extents.
That said, instead of trying to create a generic way to special case
ARC, I suggest to simply use the below patch instead.
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index 41eb9be1653c..386959bac3d2 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -77,6 +77,11 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
base, TO_MB(size), !in_use ? "Not used":"");
}
+bool arch_has_descending_max_zone_pfns(void)
+{
+ return true;
+}
+
/*
* First memory setup routine called from setup_arch()
* 1. setup swapper's mm @init_mm
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b990e9734474..114f0e027144 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7307,6 +7307,15 @@ static void check_for_memory(pg_data_t *pgdat, int nid)
}
}
+/*
+ * Some architecturs, e.g. ARC may have ZONE_HIGHMEM below ZONE_NORMAL. For
+ * such cases we allow max_zone_pfn sorted in the descending order
+ */
+bool __weak arch_has_descending_max_zone_pfns(void)
+{
+ return false;
+}
+
/**
* free_area_init - Initialise all pg_data_t and zone data
* @max_zone_pfn: an array of max PFNs for each zone
@@ -7324,7 +7333,7 @@ void __init free_area_init(unsigned long *max_zone_pfn)
{
unsigned long start_pfn, end_pfn;
int i, nid, zone;
- bool descending = false;
+ bool descending;
/* Record where the zone boundaries are */
memset(arch_zone_lowest_possible_pfn, 0,
@@ -7333,14 +7342,7 @@ void __init free_area_init(unsigned long *max_zone_pfn)
sizeof(arch_zone_highest_possible_pfn));
start_pfn = find_min_pfn_with_active_regions();
-
- /*
-* Some architecturs, e.g. ARC may have ZONE_HIGHMEM below
-* ZONE_NORMAL. For such cases we allow max_zone_pfn sorted in the
-* descending order
-*/
- if (MAX_NR_ZONES > 1 && max_zone_pfn[0] > max_zone_pfn[1])
- descending = true;
+ descending = arch_has_descending_max_zone_pfns();
for (i = 0; i < MAX_NR_ZONES; i++) {
if (descending)
> Guenter
>
> > qemu command line:
> >
> > qemu-system-microblazeel -M petalogix-ml605 -m 256 \
> > -kernel arch/microblaze/boot/linux.bin -no-reboot \
> > -initrd rootfs.cpio \
> > -append 'panic=-1 slub_debug=FZPUA rdinit=/sbin/init
> > console=ttyS0,115200' \
> > -monitor none -serial stdio -nographic
> >
> > initrd:
> >
> > https://github.com/groeck/linux-build-test/blob/master/rootfs/microblazeel/rootfs.cpio.gz
> > configuration:
> >
> > https://github.com/groeck/linux-build-test/blob/master/rootfs/microblazeel/qemu_microblazeel_ml605_defconfig
> >
> > Bisect log is below.
> >
> > Guenter
> >
> > ---
> > # bad: [fb9d670f57e3f6478602328bbbf71138be06ca4f] Add linux-next specific
> > files for 20200501
> > # good: [6a8b55ed4056ea5559ebe4f6a4b247f627870d4c] Linux 5.7-rc3
> > git bisect start 'HEAD' 'v5.7-rc3'
> > # good: [068b80b68a670f0b17288c8a3d1ee751f35162ab] Merge remote-tracking
> > branch 'drm/drm-next'
> > git bisect good 068b80b68a670f0b17288c8a3d1ee751f35162ab
> > # good: [46c70fc6a3ac35cd72ddad248dcbe4eee716d2a5] Merge remote-tracking
> > branch 'drivers-x86/for-next'
> > git bisect good 46c70fc6a3ac35cd72ddad248dcbe4eee716d2a5
> > # good: [f39c4ad479a2f005f972a2b941b40efa6b9c9349] Merge remote-tracking
> > branch 'rpmsg/for-next'
> > git bisect good f39c4ad479a2f005f972a2b941b40efa6b9c9349
> > # bad: [165d3ee0162fe28efc2c8180176633e33515df15]
> > ipc-convert-ipcs_idr-to-xarray-update
> > git bisect ba
Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code
On Mon, May 04, 2020 at 06:33:57AM +0100, Al Viro wrote:
> On Sun, May 03, 2020 at 10:04:47PM -0700, Ira Weiny wrote:
>
> > Grepping for 'asm/highmem.h' and investigations don't reveal any issues...
> > But
> > you do have me worried. That said 0-day has been crunching on multiple
> > versions of this series without issues such as this (save the mips issue
> > above).
> >
> > I have to say it would be nice if the relation between linux/highmem.h and
> > asm/highmem.h was more straightforward.
>
> IIRC, the headache was due to asm/pgtable.h on several architectures and
> asm/cacheflush.h on parisc.
>
>
>
> || IOW, there's one in linux/highmem.h (conditional on
> !CONFIG_HIGHMEM,
> || !ARCH_HAS_KMAP) and several per-architecture variants, usually declared in
> || their asm/highmem.h. In three of those (microblaze, parisc and powerpc)
> these
> || are inlines (parisc one identical to linux/highmem.h, lives in
> asm/cacheflush.h,
> || powerpc and microblaze ones calling kmap_atomic_prot() which is defined in
> || arch/$ARCH/mm/highmem.c).
> ||
> || parisc case is weird - essentially, they want to call
> || flush_kernel_dcache_page_addr() at the places where kunmap/kunmap_atomic
> || is done. And they do so despite not selecting HIGHMEM, with definitions
> || in usual place. They do have ARCH_HAS_KMAP defined, which prevents
> || getting buggered in linux/highmem.h. ARCH_HAS_KMAP is parisc-unique,
> || BTW, and checked only in linux/highmem.h.
> ||
> || All genuine arch-specific variants are defined in (or call
> functions
> || defined in) translation units that are only included CONFIG_HIGHMEM builds.
I agree with this statement. But IMO additional confusion is caused by the
fact that some arch's condition the declarations on CONFIG_HIGHMEM within
asm/highmem.h (arc, arm, nds32) while others depend on linux/highmem.h (and
elsewhere) to do so (csky, microblaze, mips, powerpc, sparc, x86, xtensa).
Why?
I think (perhaps naive) over time asm/highmem.h needs to be isolated to being
included in linux/highmem.h. But as you point out below that is not so easy.
I think that this series helps toward that goal.
> ||
> || It would be tempting to consolidate those, e.g. by adding
> __kmap_atomic()
> || and __kmap_atomic_prot() without that boilerplate, with universal
> kmap_atomic()
> || and kmap_atomic_prot() in linux/highmem.h. Potential problem with that
> would
> || be something that pulls ash/highmem.h (or asm/cacheflush.h in case of
> parisc)
> || directly and uses kmap_atomic/kmap_atomic_prot. There's not a lot places
> || pulling asm/highmem.h, and many of them are not even in includes:
> ||
> || arch/arm/include/asm/efi.h:13:#include
> || arch/arm/mm/dma-mapping.c:31:#include
> || arch/arm/mm/flush.c:14:#include
> || arch/arm/mm/mmu.c:27:#include
> || arch/mips/include/asm/pgtable-32.h:22:#include
> || arch/mips/mm/cache.c:19:#include
> || arch/mips/mm/fault.c:28:#include /* For
> VMALLOC_END */
> || arch/nds32/include/asm/pgtable.h:60:#include
> || arch/x86/kernel/setup_percpu.c:20:#include
> || include/linux/highmem.h:35:#include
> ||
> || Users of asm/cacheflush.h are rather more numerous; however, anything
> || outside of parisc-specific code has to pull linux/highmem.h, or it won't
> see
> || the definitions of kmap_atomic/kmap_atomic_prot at all. arch/parisc itself
> || has no callers of those.
> ||
> || Outside of arch/* there is a plenty of callers. However, the following is
> || true: all instances of kmap_atomic or kmap_atomic_prot outside of arch/*
> || are either inside the linux/highmem.h or are preceded by include of
> || linux/highmem.h on any build that sees them (there is a common include
> || chain that is conditional upon CONFIG_BLOCK, but it's only needed in
> || drivers that are BLOCK-dependent). It was not fun to verify, to put
> || it mildly...
> ||
> || So for parisc we have no problem - leaving
> __kmap_atomic()/__kmap_atomic_prot()
> || in asm/cachefile.h and adding universal wrappers in linux/highmem.h will be
> || fine. For other architectures the things might be trickier.
And the follow up series removes kmap_* from asm/cachefile.h in parisc which
should be cleaner going forward.
> ||
> || * arc: all users in arch/arc/ are within arch/arc/mm/{cache,highmem}.c;
> || both pull linux/highmem.h. We are fine.
Still fine.
> ||
> || * arm: much, much worse. We have several files that pull linux/highmem.h:
> || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c,
> || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, arch/arm/mm/flush.c,
> || arch/arm/mm/highmem.c, arch/arm/probes/uprobes/core.c,
> || arch/arm/include/asm/kvm_mmu.h (kmap_atomic_pfn()).
> || Those are fine, but we also have this:
> || arch/arm/include/asm/pgtable.h:200:#define __pte_map(pmd)
> (pte_t *)kmap_atomic(pmd_page(*(pmd)))
> || arch/arm/include/asm/pgtable.h:208:#define pte_offset_map(p
Re: [PATCH V2 11/11] drm: Remove drm specific kmap_atomic code
On Mon, May 04, 2020 at 01:18:51PM +0200, Daniel Vetter wrote:
> On Mon, May 4, 2020 at 3:09 AM wrote:
> >
> > From: Ira Weiny
> >
> > kmap_atomic_prot() is now exported by all architectures. Use this
> > function rather than open coding a driver specific kmap_atomic.
> >
> > Reviewed-by: Christian König
> > Reviewed-by: Christoph Hellwig
> > Signed-off-by: Ira Weiny
>
> I'm assuming this lands through some other tree or a topic branch or whatever.
Yes I think Andrew queued this up before and so I hope he will continue to do
so with the subsequent versions.
Andrew, LMK if this is an issue.
Thanks,
Ira
>
> Acked-by: Daniel Vetter
>
> Cheers, Daniel
>
> > ---
> > drivers/gpu/drm/ttm/ttm_bo_util.c| 56 ++--
> > drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 16
> > include/drm/ttm/ttm_bo_api.h | 4 --
> > 3 files changed, 12 insertions(+), 64 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > index 52d2b71f1588..f09b096ba4fd 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > @@ -257,54 +257,6 @@ static int ttm_copy_io_page(void *dst, void *src,
> > unsigned long page)
> > return 0;
> > }
> >
> > -#ifdef CONFIG_X86
> > -#define __ttm_kmap_atomic_prot(__page, __prot) kmap_atomic_prot(__page,
> > __prot)
> > -#define __ttm_kunmap_atomic(__addr) kunmap_atomic(__addr)
> > -#else
> > -#define __ttm_kmap_atomic_prot(__page, __prot) vmap(&__page, 1, 0, __prot)
> > -#define __ttm_kunmap_atomic(__addr) vunmap(__addr)
> > -#endif
> > -
> > -
> > -/**
> > - * ttm_kmap_atomic_prot - Efficient kernel map of a single page with
> > - * specified page protection.
> > - *
> > - * @page: The page to map.
> > - * @prot: The page protection.
> > - *
> > - * This function maps a TTM page using the kmap_atomic api if available,
> > - * otherwise falls back to vmap. The user must make sure that the
> > - * specified page does not have an aliased mapping with a different caching
> > - * policy unless the architecture explicitly allows it. Also mapping and
> > - * unmapping using this api must be correctly nested. Unmapping should
> > - * occur in the reverse order of mapping.
> > - */
> > -void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot)
> > -{
> > - if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
> > - return kmap_atomic(page);
> > - else
> > - return __ttm_kmap_atomic_prot(page, prot);
> > -}
> > -EXPORT_SYMBOL(ttm_kmap_atomic_prot);
> > -
> > -/**
> > - * ttm_kunmap_atomic_prot - Unmap a page that was mapped using
> > - * ttm_kmap_atomic_prot.
> > - *
> > - * @addr: The virtual address from the map.
> > - * @prot: The page protection.
> > - */
> > -void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot)
> > -{
> > - if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
> > - kunmap_atomic(addr);
> > - else
> > - __ttm_kunmap_atomic(addr);
> > -}
> > -EXPORT_SYMBOL(ttm_kunmap_atomic_prot);
> > -
> > static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src,
> > unsigned long page,
> > pgprot_t prot)
> > @@ -316,13 +268,13 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm,
> > void *src,
> > return -ENOMEM;
> >
> > src = (void *)((unsigned long)src + (page << PAGE_SHIFT));
> > - dst = ttm_kmap_atomic_prot(d, prot);
> > + dst = kmap_atomic_prot(d, prot);
> > if (!dst)
> > return -ENOMEM;
> >
> > memcpy_fromio(dst, src, PAGE_SIZE);
> >
> > - ttm_kunmap_atomic_prot(dst, prot);
> > + kunmap_atomic(dst);
> >
> > return 0;
> > }
> > @@ -338,13 +290,13 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm,
> > void *dst,
> > return -ENOMEM;
> >
> > dst = (void *)((unsigned long)dst + (page << PAGE_SHIFT));
> > - src = ttm_kmap_atomic_prot(s, prot);
> > + src = kmap_atomic_prot(s, prot);
> > if (!src)
> > return -ENOMEM;
> >
> > memcpy_toio(dst, src, PAGE_SIZE);
> >
> > - ttm_kunmap_atomic_prot(src, prot);
> > + kunmap_atomic(src);
> >
> > return 0;
> > }
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> > index bb46ca0c458f..94d456a1d1a9 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> > @@ -374,12 +374,12 @@ static int vmw_bo_cpu_blit_line(struct
> > vmw_bo_blit_line_data *d,
> > copy_size = min_t(u32, copy_size, PAGE_SIZE -
> > src_page_offset);
> >
> > if (unmap_src) {
> > - ttm_kunmap_atomic_prot(d->src_addr, d->src_prot);
> > + kunmap_atomic(d->src_addr);
> > d->src_addr = NULL;
> > }
> >
> > if
[arc:topic-zol-remove 9/24] arch/arc/include/asm/delay.h:44: Error: opcode 'dbnz' not supported for target arc700
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git
topic-zol-remove
head: e70f916e79921587cb83b492fd52da527c5c5d62
commit: cc82dbffac97abe79cb1184be605445519560f86 [9/24] ARC: delay elide ZOL
config: arc-randconfig-a001-20200505 (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout cc82dbffac97abe79cb1184be605445519560f86
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
arch/arc/include/asm/delay.h: Assembler messages:
>> arch/arc/include/asm/delay.h:44: Error: opcode 'dbnz' not supported for
>> target arc700
>> arch/arc/include/asm/delay.h:44: Error: opcode 'dbnz' not supported for
>> target arc700
--
arch/arc/include/asm/delay.h: Assembler messages:
>> arch/arc/include/asm/delay.h:44: Error: opcode 'dbnz' not supported for
>> target arc700
--
arch/arc/include/asm/bitops.h: Assembler messages:
arch/arc/include/asm/bitops.h:235: Error: junk at end of line, first
unrecognized character is `0'
>> arch/arc/include/asm/delay.h:44: Error: opcode 'dbnz' not supported for
>> target arc700
--
In file included from sound/pci/echoaudio/darla24.c:96:
sound/pci/echoaudio/echoaudio.c: In function 'snd_echo_free':
sound/pci/echoaudio/echoaudio.c:1824:14: warning: passing argument 1 of
'iounmap' discards 'volatile' qualifier from pointer target type
[-Wdiscarded-qualifiers]
1824 | iounmap(chip->dsp_registers);
| ^~~
In file included from include/linux/io.h:13,
from include/linux/irq.h:20,
from include/asm-generic/hardirq.h:13,
from ./arch/arc/include/generated/asm/hardirq.h:1,
from include/linux/hardirq.h:9,
from include/linux/interrupt.h:11,
from sound/pci/echoaudio/darla24.c:33:
arch/arc/include/asm/io.h:35:41: note: expected 'const void *' but argument
is of type 'volatile u32 *' {aka 'volatile unsigned int *'}
35 | extern void iounmap(const void __iomem *addr);
| ^~~~
arch/arc/include/asm/delay.h: Assembler messages:
>> arch/arc/include/asm/delay.h:44: Error: opcode 'dbnz' not supported for
>> target arc700
--
arch/arc/include/asm/delay.h: Assembler messages:
>> arch/arc/include/asm/delay.h:44: Error: opcode 'dbnz' not supported for
>> target arc700
arch/arc/include/asm/bitops.h:235: Error: junk at end of line, first
unrecognized character is `0'
vim +/dbnz +44 arch/arc/include/asm/delay.h
37
38 static inline void __delay(unsigned long loops)
39 {
40 /* TBD: insn per loop now vs. 1 + implied branch */
41
42 __asm__ __volatile__(
43 " add %0, %0, 1 \n"
> 44 "1: nop \n"
45 " dbnz %0, 1b \n"
46 : "+r"(loops));
47 }
48
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code
On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote: > > || * arm: much, much worse. We have several files that pull > > linux/highmem.h: > > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c, > > || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, arch/arm/mm/flush.c, > > || arch/arm/mm/highmem.c, arch/arm/probes/uprobes/core.c, > > || arch/arm/include/asm/kvm_mmu.h (kmap_atomic_pfn()). > > || Those are fine, but we also have this: > > || arch/arm/include/asm/pgtable.h:200:#define __pte_map(pmd) > > (pte_t *)kmap_atomic(pmd_page(*(pmd))) > > || arch/arm/include/asm/pgtable.h:208:#define pte_offset_map(pmd,addr) > > (__pte_map(pmd) + pte_index(addr)) > > || and sure as hell, asm/pgtable.h does *NOT* pull linux/highmem.h. > > It does not pull asm/highmem.h either... No, but the users of those macros need to be considered. > > || #define pte_offset_map(dir, addr) \ > > || ((pte_t *) kmap_atomic(pmd_page(*(dir))) + pte_index(addr)) > > || One pte_offset_map user in arch/microblaze: > > || arch/microblaze/kernel/signal.c:207:ptep = pte_offset_map(pmdp, > > address); > > || Messy, but doesn't require any changes (we have asm/pgalloc.h included > > || there, and that pull linux/highmem.h). > > AFAICS asm/pgtable.h does not include asm/highmem.h here... > > So looks like arch/microblaze/kernel/signal.c will need linux/highmem.h See above - line 39 in there is #include and line 14 in arch/microblaze/include/asm/pgalloc.h is #include It's conditional upon CONFIG_MMU in there, but so's the use of pte_offset_map() in arch/microblaze/kernel/signal.c So it shouldn't be a problem. > > || * xtensa: users in arch/xtensa/kernel/pci-dma.c, > > arch/xtensa/mm/highmem.c, > > || arch/xtensa/mm/cache.c and arch/xtensa/platforms/iss/simdisk.c (all pull > > || linux/highmem.h). > > Actually > > arch/xtensa/mm/cache.c gets linux/highmem.h from linux/pagemap.h > > arch/xtensa/platforms/iss/simdisk.c may have an issue? > linux/blkdev.h -> CONFIG_BLOCK -> linux/pagemap.h -> linux/highmem.h > But simdisk.c requires BLK_DEV_SIMDISK -> CONFIG_BLOCK... > Yep - see above re major chain of indirect includes conditional upon CONFIG_BLOCK and its uses in places that only build with such configs. There's a plenty of similar considerations outside of arch/*, unfortunately... ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 00/13] glibc port to ARC processors
On 4/22/20 6:41 PM, Vineet Gupta wrote: > Hi, > > This patchset implements glibc port to ARC HS48x processor from Synopsys. ping ! > > This still needs a couple of inflight 64-time, offset patches. > > g...@github.com:foss-for-synopsys-dwc-arc-processors/glibc.git upstream-v6 > > v6: >* Dropped 11/14: merged upstream >* _FPU_SETS() inline asm reworked >* Introduce fixup-asm-unistd.h to elide 32-bit time, offset syscalls and > regenerate arch-syscall.h >* Fix snafu in updating build-many-glibcs for ARC >* More code sytle fixes flagged by Joseph > v5: >* Big Endian formally supported as multi-ABI >* Removed code for ARC700 processors >* Hard-float code updates: fegetmode, fesetround, feupdateenv >* socket-constant.h update for 64-bit ABI spun off as standalone patch >* __syscall_error made glibc_private >* math ulps regen >* gmp-mparam.h removed >* lint fixes as flagged by Joseph > v4: >* Dropped 1/17: Merged upstream >* Dropped 17/17: >- 64-bit time/offset code chunked up into respective patches >* sysctl removed >* Updated README for arc gnu triplet >* Updated install files for ARC gcc/binutils requirements >* Updated NEWS with brief ISA/ABI info > > v3: >* Support for Hardware Floating Point >* 64-bit time and offsets ABI (although all such changes are confined > to a single patch) > > v5: https://sourceware.org/pipermail/libc-alpha/2020-April/112657.html > v4: https://sourceware.org/pipermail/libc-alpha/2020-March/111855.html > v3: https://sourceware.org/legacy-ml/libc-alpha/2020-03/msg00167.html > v2: https://sourceware.org/legacy-ml/libc-alpha/2019-01/msg00681.html > v1: https://sourceware.org/legacy-ml/libc-alpha/2018-12/msg00678.html > > Documentation: > -- > > (a) ABI doc: > https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/wiki/files/ARCv2_ABI.pdf > > (b) Programmer's Reference Manual (PRM) : needs a download request to be > filled > https://www.synopsys.com/dw/ipdir.php?ds=arc-hs44-hs46-hs48 > https://www.synopsys.com/dw/doc.php/ds/cc/programmers-reference-manual-ARC-HS.pdf > > Test Results: > -- > (a) build-many-glibcs.py > > | Summary of test results: > | 1251 PASS > | 15 XFAIL > > > (b) Full testsuite ran in a cross compile setup using buildroot on HSDK > development > platform. Bulk of failures come from cross testing setup and I > intend to improve things with native testing going forward. > > | Summary of test results: > | 30 FAIL (-3) > | > | FAIL: csu/test-as-const-tcb-offsets > + FAIL: elf/tst-audit14 > + FAIL: elf/tst-audit15 > + FAIL: elf/tst-audit16 > | FAIL: elf/tst-ldconfig-ld_so_conf-update # not true: dlopen > | FAIL: iconv/test-iconvconfig# Needs gconv installed > - FAIL: iconv/tst-gconv-init-failure > | FAIL: io/ftwtest# Requires execution by non-root > - FAIL: io/tst-futimesat > | FAIL: io/tst-lockf > | FAIL: libio/tst-wfile-sync > | FAIL: locale/tst-C-locale > | FAIL: locale/tst-duplocale > | FAIL: locale/tst-locale-locpath > | FAIL: locale/tst-locname > | FAIL: localedata/sort-test > | FAIL: nptl/test-cond-printers # needs Python3 and target GDB > on target > | FAIL: nptl/test-condattr-printers #ditto > | FAIL: nptl/test-mutex-printers #ditto > | FAIL: nptl/test-mutexattr-printers #ditto > | FAIL: nptl/test-rwlock-printers #ditto > | FAIL: nptl/test-rwlockattr-printers #ditto > | FAIL: nptl/tst-umask1 # passes if run natively on > target (NFS ACLv3 support needed) > | FAIL: nss/bug-erange > | FAIL: nss/tst-nss-files-hosts-getent# Timed out > | FAIL: nss/tst-nss-files-hosts-multi # Timed out > | FAIL: posix/bug-ga2 # DNS issue: google DNS vs. SNPS > | FAIL: posix/globtest# require same user on target > and host > | FAIL: posix/tst-getaddrinfo5# passes outside corporate > network > - FAIL: resolv/tst-resolv-basic > - FAIL: resolv/tst-resolv-edns > - FAIL: resolv/tst-resolv-rotate > - FAIL: resolv/tst-resolv-search > | FAIL: stdio-common/bug22# Needs more RAM: 2 GB memory > | FAIL: sunrpc/bug20790 # missing cpp on target > | FAIL: timezone/tst-tzset# passes outside corporate network > > > kindly review. > > Thx, > -Vineet > > Vineet Gupta (13): > ARC: ABI Implementation > ARC: startup and dynamic linking code > ARC: Thread Local Storage support > ARC: Atomics and Locking primitives > ARC: math soft float support > ARC: hardware floating point support > ARC: Linux Syscall Interface > ARC: Linux ABI > ARC: Linux Startup and Dynamic Loading > ARC: ABI lists > ARC: Build Infrastructure > build-many-glibcs.py: Enable ARC builds > Documentation for ARC port > > NEWS |9 + > README
Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code
On Mon, May 04, 2020 at 10:02:25PM +0100, Al Viro wrote: > On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote: > > > > || * arm: much, much worse. We have several files that pull > > > linux/highmem.h: > > > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c, > > > || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, > > > arch/arm/mm/flush.c, > > > || arch/arm/mm/highmem.c, arch/arm/probes/uprobes/core.c, > > > || arch/arm/include/asm/kvm_mmu.h (kmap_atomic_pfn()). > > > || Those are fine, but we also have this: > > > || arch/arm/include/asm/pgtable.h:200:#define __pte_map(pmd) > > > (pte_t *)kmap_atomic(pmd_page(*(pmd))) > > > || arch/arm/include/asm/pgtable.h:208:#define pte_offset_map(pmd,addr) > > > (__pte_map(pmd) + pte_index(addr)) > > > || and sure as hell, asm/pgtable.h does *NOT* pull linux/highmem.h. > > > > It does not pull asm/highmem.h either... > > No, but the users of those macros need to be considered. Agreed, I was trying to point out that highmem.h was being pulled from somewhere else prior to my series, sorry. > > > > || #define pte_offset_map(dir, addr) \ > > > || ((pte_t *) kmap_atomic(pmd_page(*(dir))) + pte_index(addr)) > > > || One pte_offset_map user in arch/microblaze: > > > || arch/microblaze/kernel/signal.c:207:ptep = pte_offset_map(pmdp, > > > address); > > > || Messy, but doesn't require any changes (we have asm/pgalloc.h included > > > || there, and that pull linux/highmem.h). > > > > AFAICS asm/pgtable.h does not include asm/highmem.h here... > > > > So looks like arch/microblaze/kernel/signal.c will need linux/highmem.h > > See above - line 39 in there is > #include > and line 14 in arch/microblaze/include/asm/pgalloc.h is > #include > It's conditional upon CONFIG_MMU in there, but so's the use of > pte_offset_map() in arch/microblaze/kernel/signal.c > > So it shouldn't be a problem. Ah ok, I did not see that one. Ok I'll drop that change and this series should be good. I was setting up to submit another version with 3 more patches you have suggested: kmap: Remove kmap_atomic_to_page() parisc/kmap: Remove duplicate kmap code sparc: Remove unnecessary includes Would you like to see those folded in? I submitted 2 of the above as a separate series already. > > > > || * xtensa: users in arch/xtensa/kernel/pci-dma.c, > > > arch/xtensa/mm/highmem.c, > > > || arch/xtensa/mm/cache.c and arch/xtensa/platforms/iss/simdisk.c (all > > > pull > > > || linux/highmem.h). > > > > Actually > > > > arch/xtensa/mm/cache.c gets linux/highmem.h from linux/pagemap.h > > > > arch/xtensa/platforms/iss/simdisk.c may have an issue? > > linux/blkdev.h -> CONFIG_BLOCK -> linux/pagemap.h -> linux/highmem.h > > But simdisk.c requires BLK_DEV_SIMDISK -> CONFIG_BLOCK... > > > > Yep - see above re major chain of indirect includes conditional upon > CONFIG_BLOCK > and its uses in places that only build with such configs. There's a plenty of > similar considerations outside of arch/*, unfortunately... Indeed. FWIW the last 2 versions of this series have had no build failures with 0-day. This series in particular just finished 164 configs without issue. Would you like me to submit a new series? With your additional patches? Ira ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
