Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
From: Christoph Hellwig Date: Mon, 10 Dec 2018 20:22:28 +0100 > On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote: >> From: Christoph Hellwig >> Date: Mon, 10 Dec 2018 17:32:56 +0100 >> >> > Dave, can you pick the series up through the sparc tree? I could also >> > merge it through the dma-mapping tree, but given that there is no >> > dependency on it the sparc tree seem like the better fit. >> >> I thought that some of this is a prerequisite for the DMA mapping >> work and overall consolidation you are doing. So I kinda assumed >> you wanted to merge it via your tree. >> >> I anticipate no conflicts at all, even until the next merge window, >> so it could very easily go through your tree. >> >> Let me know if you still want me to merge this. > > These patches are purely cleanups I found while auditing the DMA > mapping code, at least as of now there are no dependencies. > > That being said now that I looked into it a bit more they do however > depend on the ->mapping_error removal, so I'll take them through > the dma-mapping tree. Ok, thanks. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/10] arm64/iommu: don't remap contiguous allocations for coherent devices
On Mon, Dec 10, 2018 at 07:19:30PM +, Robin Murphy wrote:
> On 08/12/2018 17:36, Christoph Hellwig wrote:
>> There is no need to have an additional kernel mapping for a contiguous
>> allocation if the device already is DMA coherent, so skip it.
>
> FWIW, the "need" was that it kept the code in this path simple and the
> mapping behaviour consistent with the regular iommu_dma_alloc() case. One
> could quite easily retort that there is no need for the extra complexity of
> this patch, since vmalloc is cheap on a 64-bit architecture ;)
Heh. Well, without the remap we do less work, we prepare for a simple
implementation of DMA_ATTR_NON_CONSISTENT, and also prepapre the code
to be better reusable for architectures that don't do remapping of
DMA allocations at all.
>> if (addr) {
>> memset(addr, 0, size);
>> -if (!coherent)
>> -__dma_flush_area(page_to_virt(page), iosize);
>> +__dma_flush_area(page_to_virt(page), iosize);
>
> Oh poo - seems I missed it at the time but the existing logic here is
> wrong. Let me send a separate fix to flip those statements into the correct
> order...
Yes, flushing the remapped alias only after zeroing it looks odd.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote: > From: Christoph Hellwig > Date: Mon, 10 Dec 2018 17:32:56 +0100 > > > Dave, can you pick the series up through the sparc tree? I could also > > merge it through the dma-mapping tree, but given that there is no > > dependency on it the sparc tree seem like the better fit. > > I thought that some of this is a prerequisite for the DMA mapping > work and overall consolidation you are doing. So I kinda assumed > you wanted to merge it via your tree. > > I anticipate no conflicts at all, even until the next merge window, > so it could very easily go through your tree. > > Let me know if you still want me to merge this. These patches are purely cleanups I found while auditing the DMA mapping code, at least as of now there are no dependencies. That being said now that I looked into it a bit more they do however depend on the ->mapping_error removal, so I'll take them through the dma-mapping tree. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/10] arm64/iommu: don't remap contiguous allocations for coherent devices
On 08/12/2018 17:36, Christoph Hellwig wrote:
There is no need to have an additional kernel mapping for a contiguous
allocation if the device already is DMA coherent, so skip it.
FWIW, the "need" was that it kept the code in this path simple and the
mapping behaviour consistent with the regular iommu_dma_alloc() case.
One could quite easily retort that there is no need for the extra
complexity of this patch, since vmalloc is cheap on a 64-bit architecture ;)
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4c0f498069e8..d39b60113539 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -255,13 +255,18 @@ static void *__iommu_alloc_attrs(struct device *dev,
size_t size,
size >> PAGE_SHIFT);
return NULL;
}
+
+ if (coherent) {
+ memset(addr, 0, size);
+ return addr;
+ }
+
addr = dma_common_contiguous_remap(page, size, VM_USERMAP,
prot,
__builtin_return_address(0));
if (addr) {
memset(addr, 0, size);
- if (!coherent)
- __dma_flush_area(page_to_virt(page), iosize);
+ __dma_flush_area(page_to_virt(page), iosize);
Oh poo - seems I missed it at the time but the existing logic here is
wrong. Let me send a separate fix to flip those statements into the
correct order...
Robin.
} else {
iommu_dma_unmap_page(dev, *handle, iosize, 0, attrs);
dma_release_from_contiguous(dev, page,
@@ -309,7 +314,9 @@ static void __iommu_free_attrs(struct device *dev, size_t
size, void *cpu_addr,
iommu_dma_unmap_page(dev, handle, iosize, 0, attrs);
dma_release_from_contiguous(dev, page, size >> PAGE_SHIFT);
- dma_common_free_remap(cpu_addr, size, VM_USERMAP);
+
+ if (!dev_is_dma_coherent(dev))
+ dma_common_free_remap(cpu_addr, size, VM_USERMAP);
} else if (is_vmalloc_addr(cpu_addr)){
struct vm_struct *area = find_vm_area(cpu_addr);
@@ -336,11 +343,12 @@ static int __iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
return ret;
if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
- /*
-* DMA_ATTR_FORCE_CONTIGUOUS allocations are always remapped,
-* hence in the vmalloc space.
-*/
- unsigned long pfn = vmalloc_to_pfn(cpu_addr);
+ unsigned long pfn;
+
+ if (dev_is_dma_coherent(dev))
+ pfn = virt_to_pfn(cpu_addr);
+ else
+ pfn = vmalloc_to_pfn(cpu_addr);
return __swiotlb_mmap_pfn(vma, pfn, size);
}
@@ -359,11 +367,12 @@ static int __iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
struct vm_struct *area = find_vm_area(cpu_addr);
if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
- /*
-* DMA_ATTR_FORCE_CONTIGUOUS allocations are always remapped,
-* hence in the vmalloc space.
-*/
- struct page *page = vmalloc_to_page(cpu_addr);
+ struct page *page;
+
+ if (dev_is_dma_coherent(dev))
+ page = virt_to_page(cpu_addr);
+ else
+ page = vmalloc_to_page(cpu_addr);
return __swiotlb_get_sgtable_page(sgt, page, size);
}
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/10] arm: implement DMA_ATTR_NON_CONSISTENT
On Sat, Dec 08, 2018 at 07:52:04PM -0300, Ezequiel Garcia wrote:
> > #ifdef CONFIG_DMA_API_DEBUG
> > @@ -773,7 +791,7 @@ static void *__dma_alloc(struct device *dev, size_t
> > size, dma_addr_t *handle,
> >
> > if (cma)
> > buf->allocator = _allocator;
> > - else if (is_coherent)
> > + else if (is_coherent || (attrs & DMA_ATTR_NON_CONSISTENT))
> > buf->allocator = _allocator;
>
> Reading through your code I can't really see where the pgprot is changed
> for non-consistent requests. Namely, __get_dma_pgprot only
> returns writecombine or coherent memory.
We don't look at the pgprot at all for the simple allocator, and
don't look at prot for the DMA_ATTR_NON_CONSISTENT case in the
CMA allocator, so this should not be a problem. However we need to
take DMA_ATTR_NON_CONSISTENT into account for calculating the mmap
pgprot, with something like this as an incremental patch:
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index b3b66b41c450..6ac7e430a47c 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -873,7 +873,8 @@ int arm_dma_mmap(struct device *dev, struct vm_area_struct
*vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
- vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
+ if (!(attrs & DMA_ATTR_NON_CONSISTENT))
+ vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
return __arm_dma_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
}
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
From: Christoph Hellwig Date: Mon, 10 Dec 2018 17:32:56 +0100 > Dave, can you pick the series up through the sparc tree? I could also > merge it through the dma-mapping tree, but given that there is no > dependency on it the sparc tree seem like the better fit. I thought that some of this is a prerequisite for the DMA mapping work and overall consolidation you are doing. So I kinda assumed you wanted to merge it via your tree. I anticipate no conflicts at all, even until the next merge window, so it could very easily go through your tree. Let me know if you still want me to merge this. Thanks. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
Dave, can you pick the series up through the sparc tree? I could also merge it through the dma-mapping tree, but given that there is no dependency on it the sparc tree seem like the better fit. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [REPOST PATCH v6 0/4] kgdb: Fix kgdb_roundup_cpus()
Hi Doug, On Fri, Dec 07, 2018 at 10:40:24AM -0800, Doug Anderson wrote: > On Fri, Dec 7, 2018 at 9:42 AM Catalin Marinas > wrote: > > On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote: > > > Douglas Anderson (4): > > > kgdb: Remove irq flags from roundup > > > kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function() > > > kgdb: Don't round up a CPU that failed rounding up before > > > kdb: Don't back trace on a cpu that didn't round up > > > > FWIW, trying these on arm64 (ThunderX2) with CONFIG_KGDB_TESTS_ON_BOOT=y > > on top of 4.20-rc5 doesn't boot. It looks like they leave interrupts > > disabled when they shouldn't and it trips over the BUG at > > mm/vmalloc.c:1380 (called via do_fork -> copy_process). > > > > Now, I don't think these patches make things worse on arm64 since prior > > to them the kgdb boot tests on arm64 were stuck in a loop (RUN > > singlestep). > > Thanks for the report! ...actually, I'd never tried CONFIG_KGDB_TESTS > before. ...so I tried them now: > > A) chromeos-4.19 tree on qcom-sdm845 without this series: booted up OK > B) chromeos-4.19 tree on qcom-sdm845 with this series: booted up OK > C) v4.20-rc5-90-g30002dd008ed on rockchip-rk3399 (kevin) with this > series: booted up OK > > Example output from B) above: > > localhost ~ # dmesg | grep kgdbts > [2.139814] KGDB: Registered I/O driver kgdbts > [2.144582] kgdbts:RUN plant and detach test > [2.165333] kgdbts:RUN sw breakpoint test > [2.172990] kgdbts:RUN bad memory access test > [2.178640] kgdbts:RUN singlestep test 1000 iterations > [2.187765] kgdbts:RUN singlestep [0/1000] > [2.559596] kgdbts:RUN singlestep [100/1000] > [2.931419] kgdbts:RUN singlestep [200/1000] > [3.303474] kgdbts:RUN singlestep [300/1000] > [3.675121] kgdbts:RUN singlestep [400/1000] > [4.046867] kgdbts:RUN singlestep [500/1000] > [4.418920] kgdbts:RUN singlestep [600/1000] > [4.790824] kgdbts:RUN singlestep [700/1000] > [5.162479] kgdbts:RUN singlestep [800/1000] > [5.534103] kgdbts:RUN singlestep [900/1000] > [5.902299] kgdbts:RUN do_fork for 100 breakpoints > [8.463900] KGDB: Unregistered I/O driver kgdbts, debugger disabled > > ...so I guess I'm a little confused. Either I have a different config > than you do or something is special about your machine? I tried it now on a Juno board both as a host and a guest and boots fine. It must be something that only triggers ThunderX2. Ignore the report for now, if I find anything interesting I'll let you know. -- Catalin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Remove 0x prefix from unit-address of node names
Hi Rob,
On Mon, 2018-12-10 at 07:30 -0600, Rob Herring wrote:
> On Sat, Dec 8, 2018 at 1:01 AM Alexey Brodkin
> wrote:
> > Done automatically with help of:
> > --->8
> > sed -i 's/@0x/@/g' arch/arc/boot/dts/*.dts*
> > --->8
> >
> > Inspired by [1] and the like.
> >
> > [1]
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__kisskb.ellerman.id.au_kisskb_buildresult_13612017_=DwIBaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=zx_mJ5GzAMI32-iqcXZiL8Qzrg79Dz4cxNF72VYhQl0=JwbFcFmnJRECl_z7jQGl0687UpORq9395mgRbo1OwFE=
> >
> > Signed-off-by: Alexey Brodkin
> > Cc: Rob Herring
> >
> > Signed-off-by: Alexey Brodkin
> > ---
> > arch/arc/boot/dts/abilis_tb10x.dtsi | 4 ++--
> > arch/arc/boot/dts/axc001.dtsi | 6 +++---
> > arch/arc/boot/dts/axc003.dtsi | 14 +++---
> > arch/arc/boot/dts/axc003_idu.dtsi | 14 +++---
> > arch/arc/boot/dts/axs10x_mb.dtsi | 22 +++---
> > arch/arc/boot/dts/vdk_axc003.dtsi | 4 ++--
> > arch/arc/boot/dts/vdk_axc003_idu.dtsi | 4 ++--
> > arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 14 +++---
> > 8 files changed, 41 insertions(+), 41 deletions(-)
> >
> > diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi
> > b/arch/arc/boot/dts/abilis_tb10x.dtsi
> > index 3121536b25a3..77ac1368a65b 100644
> > --- a/arch/arc/boot/dts/abilis_tb10x.dtsi
> > +++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
> > @@ -178,7 +178,7 @@
> > clocks = <_clk>;
> > };
> >
> > - spi0: spi@0xFE01 {
> > + spi0: spi@FE01 {
>
> This should be lowercase too.
>
> > #address-cells = <1>;
> > #size-cells = <0>;
> > cell-index = <0>;
>
> [...]
>
> > @@ -119,7 +119,7 @@
> > * This node is intentionally put outside of MB above becase
> > * it maps areas outside of MB's 0xEz-0xFz.
> > */
> > - uio_ev: uio@0xD000 {
> > + uio_ev: uio@D000 {
>
> lowercase
>
> > compatible = "generic-uio";
> > reg = <0xD000 0x2000 0xD100 0x2000 0x9000
> > 0x1000 0xC000 0x1000>;
I guess real addresses should be lower-case too, right?
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Remove 0x prefix from unit-address of node names
On Sat, Dec 8, 2018 at 1:01 AM Alexey Brodkin
wrote:
>
> Done automatically with help of:
> --->8
> sed -i 's/@0x/@/g' arch/arc/boot/dts/*.dts*
> --->8
>
> Inspired by [1] and the like.
>
> [1] http://kisskb.ellerman.id.au/kisskb/buildresult/13612017/
>
> Signed-off-by: Alexey Brodkin
> Cc: Rob Herring
>
> Signed-off-by: Alexey Brodkin
> ---
> arch/arc/boot/dts/abilis_tb10x.dtsi | 4 ++--
> arch/arc/boot/dts/axc001.dtsi | 6 +++---
> arch/arc/boot/dts/axc003.dtsi | 14 +++---
> arch/arc/boot/dts/axc003_idu.dtsi | 14 +++---
> arch/arc/boot/dts/axs10x_mb.dtsi | 22 +++---
> arch/arc/boot/dts/vdk_axc003.dtsi | 4 ++--
> arch/arc/boot/dts/vdk_axc003_idu.dtsi | 4 ++--
> arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 14 +++---
> 8 files changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi
> b/arch/arc/boot/dts/abilis_tb10x.dtsi
> index 3121536b25a3..77ac1368a65b 100644
> --- a/arch/arc/boot/dts/abilis_tb10x.dtsi
> +++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
> @@ -178,7 +178,7 @@
> clocks = <_clk>;
> };
>
> - spi0: spi@0xFE01 {
> + spi0: spi@FE01 {
This should be lowercase too.
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
[...]
> @@ -119,7 +119,7 @@
> * This node is intentionally put outside of MB above becase
> * it maps areas outside of MB's 0xEz-0xFz.
> */
> - uio_ev: uio@0xD000 {
> + uio_ev: uio@D000 {
lowercase
> compatible = "generic-uio";
> reg = <0xD000 0x2000 0xD100 0x2000 0x9000
> 0x1000 0xC000 0x1000>;
> reg-names = "ev_gsa", "ev_ctrl", "ev_shared_mem",
> "ev_code_mem";
> --
> 2.16.2
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Patch "ARC: [zebu] Remove CONFIG_INITRAMFS_SOURCE from defconfigs" has been added to the 4.9-stable tree
This is a note to let you know that I've just added the patch titled ARC: [zebu] Remove CONFIG_INITRAMFS_SOURCE from defconfigs to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: arc-remove-config_initramfs_source-from-defconfigs.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From alexey.brod...@synopsys.com Mon Dec 10 10:51:40 2018 From: Alexey Brodkin Date: Mon, 10 Dec 2018 11:33:49 +0300 Subject: ARC: [zebu] Remove CONFIG_INITRAMFS_SOURCE from defconfigs To: sta...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org, linux-ker...@vger.kernel.org, Alexey Brodkin , Greg Kroah-Hartman , Kevin Hilman Message-ID: <20181210083349.35728-1-abrod...@synopsys.com> From: Alexey Brodkin Zebu boards were added in v4.9 and then renamed to "haps" in v4.10. Thus backporting commit 64234961c145 (ARC: configs: Remove CONFIG_INITRAMFS_SOURCE from defconfigs) we missed "zebu" defconfigs in v4.9. Note this is only applicable to "linux-4.9.y"! Spotted by KerneCI, see [1]. [1] https://storage.kernelci.org/stable/linux-4.9.y/v4.9.144/arc/zebu_hs_smp_defconfig/build.log Signed-off-by: Alexey Brodkin Cc: Kevin Hilman Signed-off-by: Greg Kroah-Hartman --- arch/arc/configs/zebu_hs_defconfig |1 - arch/arc/configs/zebu_hs_smp_defconfig |1 - 2 files changed, 2 deletions(-) --- a/arch/arc/configs/zebu_hs_defconfig +++ b/arch/arc/configs/zebu_hs_defconfig @@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y -CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/" CONFIG_EXPERT=y CONFIG_PERF_EVENTS=y # CONFIG_COMPAT_BRK is not set --- a/arch/arc/configs/zebu_hs_smp_defconfig +++ b/arch/arc/configs/zebu_hs_smp_defconfig @@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y -CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/" CONFIG_EMBEDDED=y CONFIG_PERF_EVENTS=y # CONFIG_VM_EVENT_COUNTERS is not set Patches currently in stable-queue which might be from alexey.brod...@synopsys.com are queue-4.9/arc-remove-config_initramfs_source-from-defconfigs.patch ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: stable/linux-4.9.y build: 193 builds: 2 failed, 191 passed, 122 warnings (v4.9.144)
Hi Kevin, On Sat, 2018-12-08 at 13:58 -0800, Kevin Hilman wrote: > FYI... we now have stable trees building all the ARCv2 defconfigs in > kernelCI.org, and there are couple build failures. Following the link > below, you'll be able to see full build logs. Thanks you so much for letting us know. The fix is posted here - http://lists.infradead.org/pipermail/linux-snps-arc/2018-December/004980.html -Alexey > Kevin > > "kernelci.org bot" writes: > > > stable/linux-4.9.y build: 193 builds: 2 failed, 191 passed, 122 warnings > > (v4.9.144) > > > > Full Build Summary: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__kernelci.org_build_stable_branch_linux-2D4.9.y_kernel_v4.9.144_=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=GTCIhFe7hRV-rHPHP8-OOfUx89kN1F5Ixpv-QC2ujXE=7dBpTvzdx5n8BZ1ugrRukgri4dwB-i3euqouGStsJmc= > > > > Tree: stable > > Branch: linux-4.9.y > > Git Describe: v4.9.144 > > Git Commit: 1aa861ff238ecd17a3095b0dbd2d20bdf7bfaf14 > > Git URL: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_pub_scm_linux_kernel_git_stable_linux-2Dstable.git=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=GTCIhFe7hRV-rHPHP8-OOfUx89kN1F5Ixpv-QC2ujXE=6ZR9nCoSZ3qViEk8-J81rZ1vw6439l8WbaP_b46uXqw= > > Built: 6 unique architectures > > > > Build Failures Detected: > > > > arc:gcc version 7.1.1 20170710 (ARCv2 ISA Linux uClibc toolchain > > 2017.09) > > > > zebu_hs_defconfig: FAIL > > zebu_hs_smp_defconfig: FAIL > > > > Warnings Detected: > > > > arc:gcc version 7.1.1 20170710 (ARCv2 ISA Linux uClibc toolchain > > 2017.09) > > > > allnoconfig: 5 warnings > > axs103_defconfig: 18 warnings > > axs103_smp_defconfig: 19 warnings > > nsim_hs_smp_defconfig: 6 warnings > > nsimosci_hs_defconfig: 8 warnings > > nsimosci_hs_smp_defconfig: 9 warnings > > tinyconfig: 6 warnings > > vdk_hs38_defconfig: 19 warnings > > vdk_hs38_smp_defconfig: 20 warnings > > zebu_hs_defconfig: 5 warnings > > zebu_hs_smp_defconfig: 6 warnings > > > > mips:gcc version 6.3.0 (GCC) > > > > decstation_defconfig: 1 warning > > > > > > Warnings summary: > > > > 36 fs/ext4/ext4_jbd2.h:430:1: warning: control reaches end of > > non-void function [-Wreturn-type] > > 12 arch/arc/include/asm/cmpxchg.h:95:29: warning: value computed is > > not used [-Wunused-value] > > 11 kernel/sched/core.c:3294:1: warning: control reaches end of > > non-void function [-Wreturn-type] > > 11 include/linux/kernel.h:740:16: warning: comparison of distinct > > pointer types lacks a cast > > 9net/ipv4/tcp_input.c:4325:49: warning: array subscript is above > > array bounds [-Warray-bounds] > > 9net/core/ethtool.c:300:1: warning: control reaches end of non-void > > function [-Wreturn-type] > > 9include/linux/sunrpc/svc_xprt.h:178:1: warning: control reaches > > end of non-void function [-Wreturn-type] > > 7warning: (ARC) selects HAVE_FUTEX_CMPXCHG which has unmet direct > > dependencies (FUTEX) > > 6fs/posix_acl.c:34:1: warning: control reaches end of non-void > > function [-Wreturn-type] > > 5lib/cpumask.c:211:1: warning: control reaches end of non-void > > function [-Wreturn-type] > > 4block/cfq-iosched.c:3840:1: warning: control reaches end of > > non-void function [-Wreturn-type] > > 2arch/arc/kernel/unwind.c:188:14: warning: 'unw_hdr_alloc' defined > > but not used [-Wunused-function] > > 1drivers/net/ethernet/amd/declance.c:1231:2: warning: 'desc' may be > > used uninitialized in this function [-Wmaybe-uninitialized] > > > > > > > > Detailed per-defconfig build reports: > > > > > > acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches > > > > > > acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section > > mismatches > > > > > > allnoconfig (i386) — PASS, 0 errors, 0 warnings, 0 section mismatches > > > > > > allnoconfig (x86_64) — PASS, 0 errors, 0 warnings, 0 section mismatches > > > > > > allnoconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches > > > > > > allnoconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches > > > > > > allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches > > > >
[PATCH] ARC: [zebu] Remove CONFIG_INITRAMFS_SOURCE from defconfigs
Zebu boards were added in v4.9 and then renamed to "haps" in v4.10. Thus backporting commit 64234961c145 (ARC: configs: Remove CONFIG_INITRAMFS_SOURCE from defconfigs) we missed "zebu" defconfigs in v4.9. Note this is only applicable to "linux-4.9.y"! Spotted by KerneCI, see [1]. [1] https://storage.kernelci.org/stable/linux-4.9.y/v4.9.144/arc/zebu_hs_smp_defconfig/build.log Signed-off-by: Alexey Brodkin Cc: Greg Kroah-Hartman Cc: Kevin Hilman --- arch/arc/configs/zebu_hs_defconfig | 1 - arch/arc/configs/zebu_hs_smp_defconfig | 1 - 2 files changed, 2 deletions(-) diff --git a/arch/arc/configs/zebu_hs_defconfig b/arch/arc/configs/zebu_hs_defconfig index 9f6166be7145..3346829b02bb 100644 --- a/arch/arc/configs/zebu_hs_defconfig +++ b/arch/arc/configs/zebu_hs_defconfig @@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y -CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/" CONFIG_EXPERT=y CONFIG_PERF_EVENTS=y # CONFIG_COMPAT_BRK is not set diff --git a/arch/arc/configs/zebu_hs_smp_defconfig b/arch/arc/configs/zebu_hs_smp_defconfig index 44e9693f4257..4471f9c37d7e 100644 --- a/arch/arc/configs/zebu_hs_smp_defconfig +++ b/arch/arc/configs/zebu_hs_smp_defconfig @@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y -CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/" CONFIG_EMBEDDED=y CONFIG_PERF_EVENTS=y # CONFIG_VM_EVENT_COUNTERS is not set -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
