* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Russell King - ARM Linux @ 2016-11-20 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.20.1611201131300.1814@knanqh.ubzr>
On Sun, Nov 20, 2016 at 12:03:50PM -0500, Nicolas Pitre wrote:
> On Sun, 20 Nov 2016, Russell King - ARM Linux wrote:
>
> > On Sun, Nov 20, 2016 at 01:56:16PM +0100, Tobias Jakobi wrote:
> > > Hey Russell,
> > >
> > > thanks for the quick reply and looking into this!
> > >
> > > Added Nicolas Pitre to Cc since the ksym trim stuff came from him.
> >
> > Arnd's patch "kbuild: provide include/asm/asm-prototypes.h for ARM" fixes
> > it, but I think it's a mixture of fixes, and partially dependent on some
> > other patches. I don't know what the status of his patch is, but my
> > feeling is that it consists of more than a single fix, and needs
> > splitting. Certainly the asm-prototypes.h is not relevant to this
> > problem, but the rest of it seems to be.
>
> Well... the problem for the current breakage was identified a while ago:
>
> https://lkml.org/lkml/2016/2/10/686
>
> I'm surprised that Al didn't fold my patch into his. Now that this has
> hit mainline, CONFIG_TRIM_UNUSED_KSYMS is now broken on ARM.
>
> And I don't see how the asm-prototypes.h is going to fix it either (if
> anything, at the moment it looks like it might be another source of
> breakage).
>
> So I think the folowing patch should go into mainline:
... which looks the same as Arnd's patch with the following changes:
- no asm-prototypes.h
- adding asm/export.h to each file using EXPORT_SYMBOL() instead of
bitops.h
- not touching:
arch/arm/lib/csumpartialcopy.S
arch/arm/lib/csumpartialcopygeneric.S
arch/arm/lib/csumpartialcopyuser.S
other than that, it's doing the same thing.
I think Arnd's changes to the csumpartial code are unnecessary, and
yours is, although larger, puts the asm/export.h include in the right
place. So please drop yours into the patch system so we can move
forward fixing some of the problems created during the last merge
window.
> ----- >8
> >From 3225f625c116a350c54f361df491bf3e1c6d32b3 Mon Sep 17 00:00:00 2001
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
> Date: Wed, 10 Feb 2016 17:40:04 -0500
> Subject: [PATCH] ARM: don't use assembler macro arguments with EXPORT_SYMBOL()
>
> Committ 4dd1837d75 ("arm: move exports to definitions") added
> EXPORT_SYMBOL(\name) to bitops.h. Here \name is an assembler macro
> argument which is not subject to preprocessor substitutions. And the
> assembler doesn't handle preprocessor macros either. That has the effect
> of breaking CONFIG_TRIM_UNUSED_KSYMS=y.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
> index df06638b32..7d807cfd8e 100644
> --- a/arch/arm/lib/bitops.h
> +++ b/arch/arm/lib/bitops.h
> @@ -1,6 +1,5 @@
> #include <asm/assembler.h>
> #include <asm/unwind.h>
> -#include <asm/export.h>
>
> #if __LINUX_ARM_ARCH__ >= 6
> .macro bitop, name, instr
> @@ -26,7 +25,6 @@ UNWIND( .fnstart )
> bx lr
> UNWIND( .fnend )
> ENDPROC(\name )
> -EXPORT_SYMBOL(\name )
> .endm
>
> .macro testop, name, instr, store
> @@ -57,7 +55,6 @@ UNWIND( .fnstart )
> 2: bx lr
> UNWIND( .fnend )
> ENDPROC(\name )
> -EXPORT_SYMBOL(\name )
> .endm
> #else
> .macro bitop, name, instr
> @@ -77,7 +74,6 @@ UNWIND( .fnstart )
> ret lr
> UNWIND( .fnend )
> ENDPROC(\name )
> -EXPORT_SYMBOL(\name )
> .endm
>
> /**
> @@ -106,6 +102,5 @@ UNWIND( .fnstart )
> ret lr
> UNWIND( .fnend )
> ENDPROC(\name )
> -EXPORT_SYMBOL(\name )
> .endm
> #endif
> diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
> index f402786217..1cfdb138d2 100644
> --- a/arch/arm/lib/changebit.S
> +++ b/arch/arm/lib/changebit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> bitop _change_bit, eor
> +
> +EXPORT_SYMBOL(_change_bit)
> diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
> index f6b75fb64d..e901ca5af0 100644
> --- a/arch/arm/lib/clearbit.S
> +++ b/arch/arm/lib/clearbit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> bitop _clear_bit, bic
> +
> +EXPORT_SYMBOL(_clear_bit)
> diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
> index 618fedae4b..3c8b11240f 100644
> --- a/arch/arm/lib/setbit.S
> +++ b/arch/arm/lib/setbit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> bitop _set_bit, orr
> +
> +EXPORT_SYMBOL(_set_bit)
> diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
> index 4becdc3a59..e3d19b87fb 100644
> --- a/arch/arm/lib/testchangebit.S
> +++ b/arch/arm/lib/testchangebit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> testop _test_and_change_bit, eor, str
> +
> +EXPORT_SYMBOL(_test_and_change_bit)
> diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
> index 918841dcce..d247e6f70f 100644
> --- a/arch/arm/lib/testclearbit.S
> +++ b/arch/arm/lib/testclearbit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> testop _test_and_clear_bit, bicne, strne
> +
> +EXPORT_SYMBOL(_test_and_clear_bit)
> diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
> index 8d1b2fe9e4..76800ff601 100644
> --- a/arch/arm/lib/testsetbit.S
> +++ b/arch/arm/lib/testsetbit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> testop _test_and_set_bit, orreq, streq
> +
> +EXPORT_SYMBOL(_test_and_set_bit)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Ard Biesheuvel @ 2016-11-20 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117151805.GJ2151@rric.localdomain>
On 17 November 2016 at 15:18, Robert Richter <robert.richter@cavium.com> wrote:
> Thanks for your answer.
>
> On 17.11.16 14:25:29, Will Deacon wrote:
>> On Wed, Nov 09, 2016 at 08:51:32PM +0100, Robert Richter wrote:
>> > Thus, I don't see where my patch breaks code. Even acpi_os_ioremap()
>> > keeps the same behaviour as before since it still uses memblock_is_
>> > memory(). Could you more describe your concerns why do you think this
>> > patch breaks the kernel and moves the problem somewhere else? I
>> > believe it fixes the problem at all.
>>
>> acpi_os_ioremap always ends up in __ioremap_caller, regardless of
>> memblock_is_memory(). __ioremap_caller then fails if pfn_valid is true.
>
> But that's the reason my patch changed the code to use memblock_is_
> map_memory() instead. I was looking into the users of pfn_valid() esp.
> in arm64 code and changed it where required.
>
> This week I looked into the kernel again for code that might break by
> a pfn_valid() change. I found try_ram_remap() in memremap.c that has
> changed behaviour now, but this is explicit for MEMREMAP_WB, so it
> should be fine.
>
> Maybe it might be better to use page_is_ram() in addition to
> pfn_valid() where necessary. This should work now after commit:
>
> e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
>
> I still think pfn_valid() is not the correct use to determine the mem
> attributes for mappings, there are further checks required.
>
> The risk of breaking something with my patch is small and limited only
> to the mapping of efi reserved regions (which is the state of 4.4). If
> something breaks anyway it can easily be fixed by adding more checks
> to pfn_valid() as suggested above.
>
As I noted before, it looks to me like setting CONFIG_HOLES_IN_ZONE is
the correct way to address this. However, doing that does uncover a
bug in move_freepages() where the VM_BUG_ON_PAGE() dereferences struct
page fields before the pfn_valid_within() check, so it seems those
need to be switched around.
Robert, you mentioned that CONFIG_HOLES_IN_ZONE seems inappropriate
for sparsemem. Care to elaborate why?
^ permalink raw reply
* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Nicolas Pitre @ 2016-11-20 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120132502.GV1041@n2100.armlinux.org.uk>
On Sun, 20 Nov 2016, Russell King - ARM Linux wrote:
> On Sun, Nov 20, 2016 at 01:56:16PM +0100, Tobias Jakobi wrote:
> > Hey Russell,
> >
> > thanks for the quick reply and looking into this!
> >
> > Added Nicolas Pitre to Cc since the ksym trim stuff came from him.
>
> Arnd's patch "kbuild: provide include/asm/asm-prototypes.h for ARM" fixes
> it, but I think it's a mixture of fixes, and partially dependent on some
> other patches. I don't know what the status of his patch is, but my
> feeling is that it consists of more than a single fix, and needs
> splitting. Certainly the asm-prototypes.h is not relevant to this
> problem, but the rest of it seems to be.
Well... the problem for the current breakage was identified a while ago:
https://lkml.org/lkml/2016/2/10/686
I'm surprised that Al didn't fold my patch into his. Now that this has
hit mainline, CONFIG_TRIM_UNUSED_KSYMS is now broken on ARM.
And I don't see how the asm-prototypes.h is going to fix it either (if
anything, at the moment it looks like it might be another source of
breakage).
So I think the folowing patch should go into mainline:
----- >8
>From 3225f625c116a350c54f361df491bf3e1c6d32b3 Mon Sep 17 00:00:00 2001
From: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Wed, 10 Feb 2016 17:40:04 -0500
Subject: [PATCH] ARM: don't use assembler macro arguments with EXPORT_SYMBOL()
Committ 4dd1837d75 ("arm: move exports to definitions") added
EXPORT_SYMBOL(\name) to bitops.h. Here \name is an assembler macro
argument which is not subject to preprocessor substitutions. And the
assembler doesn't handle preprocessor macros either. That has the effect
of breaking CONFIG_TRIM_UNUSED_KSYMS=y.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index df06638b32..7d807cfd8e 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -1,6 +1,5 @@
#include <asm/assembler.h>
#include <asm/unwind.h>
-#include <asm/export.h>
#if __LINUX_ARM_ARCH__ >= 6
.macro bitop, name, instr
@@ -26,7 +25,6 @@ UNWIND( .fnstart )
bx lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
.macro testop, name, instr, store
@@ -57,7 +55,6 @@ UNWIND( .fnstart )
2: bx lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
#else
.macro bitop, name, instr
@@ -77,7 +74,6 @@ UNWIND( .fnstart )
ret lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
/**
@@ -106,6 +102,5 @@ UNWIND( .fnstart )
ret lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
#endif
diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
index f402786217..1cfdb138d2 100644
--- a/arch/arm/lib/changebit.S
+++ b/arch/arm/lib/changebit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
bitop _change_bit, eor
+
+EXPORT_SYMBOL(_change_bit)
diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
index f6b75fb64d..e901ca5af0 100644
--- a/arch/arm/lib/clearbit.S
+++ b/arch/arm/lib/clearbit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
bitop _clear_bit, bic
+
+EXPORT_SYMBOL(_clear_bit)
diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
index 618fedae4b..3c8b11240f 100644
--- a/arch/arm/lib/setbit.S
+++ b/arch/arm/lib/setbit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
bitop _set_bit, orr
+
+EXPORT_SYMBOL(_set_bit)
diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
index 4becdc3a59..e3d19b87fb 100644
--- a/arch/arm/lib/testchangebit.S
+++ b/arch/arm/lib/testchangebit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
testop _test_and_change_bit, eor, str
+
+EXPORT_SYMBOL(_test_and_change_bit)
diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
index 918841dcce..d247e6f70f 100644
--- a/arch/arm/lib/testclearbit.S
+++ b/arch/arm/lib/testclearbit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
testop _test_and_clear_bit, bicne, strne
+
+EXPORT_SYMBOL(_test_and_clear_bit)
diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
index 8d1b2fe9e4..76800ff601 100644
--- a/arch/arm/lib/testsetbit.S
+++ b/arch/arm/lib/testsetbit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
testop _test_and_set_bit, orreq, streq
+
+EXPORT_SYMBOL(_test_and_set_bit)
^ permalink raw reply related
* [PATCH] spi: davinci: Allow device tree devices to use DMA
From: David Lechner @ 2016-11-20 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79f186b5-ac71-189f-c19f-977670395043@ti.com>
On 11/20/2016 06:59 AM, Sekhar Nori wrote:
> On Saturday 19 November 2016 10:11 AM, David Lechner wrote:
>> This makes SPI devices specified in a device tree use DMA when the master
>> controller has DMA configured.
>>
>> Since device tree is supposed to only describe the hardware, adding a
>> configuration option to device tree to enable DMA per-device would not be
>> acceptable. So, this is the best we can do for now to get SPI devices
>> working with DMA when using device tree.
>>
>> Unfortunately, this excludes the possibility of using one SPI device with
>> DMA and one without on the same master.
>>
>> I have tested this on LEGO MINDSTORMS EV3 using the NOR flash. Reading the
>> flash memory would fail with -EIO when DMA is not enabled for the device.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>> drivers/spi/spi-davinci.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
>> index d36c11b..c6cf73a 100644
>> --- a/drivers/spi/spi-davinci.c
>> +++ b/drivers/spi/spi-davinci.c
>> @@ -388,6 +388,7 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
>> static int davinci_spi_of_setup(struct spi_device *spi)
>> {
>> struct davinci_spi_config *spicfg = spi->controller_data;
>> + struct davinci_spi *dspi = spi_master_get_devdata(spi->master);
>> struct device_node *np = spi->dev.of_node;
>> u32 prop;
>>
>> @@ -400,6 +401,9 @@ static int davinci_spi_of_setup(struct spi_device *spi)
>> if (!of_property_read_u32(np, "ti,spi-wdelay", &prop))
>> spicfg->wdelay = (u8)prop;
>> spi->controller_data = spicfg;
>> + /* Use DMA for device if master supports it */
>> + if (dspi->dma_rx)
>
> This should be
>
> if (!(IS_ERR(dpsi->dma_rx) || IS_ERR(dspi->dma_tx))
There is the following code in davinci_spi_probe():
ret = davinci_spi_request_dma(dspi);
if (ret == -EPROBE_DEFER) {
goto free_clk;
} else if (ret) {
dev_info(&pdev->dev, "DMA is not supported (%d)\n", ret);
dspi->dma_rx = NULL;
dspi->dma_tx = NULL;
}
So, I does not look like it is possible to get anything other than NULL
or a valid pointer for dpsi->dma_rx and that checking dpsi->dma_tx is
not necessary.
So, I think if (dspi->dma_rx) is sufficient. In fact the same check is
used during unwinding if the probe function fails.
>
>> + spicfg->io_type = SPI_IO_TYPE_DMA;
>
> Otherwise looks good to me.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Stefan Wahren @ 2016-11-20 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479652929.2841.1.camel@embedded.rocks>
> J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016 um 15:42
> geschrieben:
>
>
> Hi Stefan,
>
> On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> > Hi J?rg,
> >
> > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016
> > > um 13:27
> > > geschrieben:
> > >
> > >
> > > Hi,
> > >
> > > I started the discussion on this mailing list in another thread
> > > [1],
> > > but I'd like to move it to a new thread, because it might be mmc
> > > specific.
> > >
> > > The issue is that I am noticed low wifi network throughput on an
> > > i.MX28
> > > board with the mainline kernel (v4.7.10, about 6 Mbps) compared to
> > > the
> > > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The wifi chip
> > > is
> > > attached using the SDIO interface.
> > >
> > > I started investigation where the bottleneck in the mainline
> > > kernel?might come from. Therefore I checked that the configs and
> > > settings for the interfaces and drivers are the same. They are.
> >
> > so you're not using the mxs_defconfig settings anymore?
>
> No, I changed the settings.
>
What happens to performance to if you change the following settings to the same
like in mxs_defconfig?
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_DEFAULT_IOSCHED="noop"
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-11-20 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9f36244f-62d4-08e3-d64a-2b04ad4dc2e0@arm.com>
Hi Robin,
>Hi Robin,
>
>>Hi Robin,
>>
>>>On 04/11/16 15:16, Sricharan wrote:
>>>> Hi Robin,
>>>>
>>>>>>> Yikes, on second look, that definitely shouldn't be happening.
>>>>>>> Everything below is probably the resulting fallout.
>>>>>>
>>>>>> [ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>>>>>
>>>>>> I think the above print which says "failed to setup iommu_ops"
>>>>>> because the call ops->add_device failed in of_pci_iommu_configure
>>>>>> is the reason for the failure, in my case i simply do not get this even with
>>>>>> your scripts. ops->add_device succeeds in the rebind as well. So still
>>>>>> checking what could be happening in your case.
>>>>>
>>>>> I was looking at your code base from [1].The ops->add_device
>>>>> callback from of_pci_iommu_configure on the rebind is the
>>>>> one which is causing the failure. But not able to spot out
>>>>>from code which point is causing the failure. It would be very helpful
>>>>> if i can know which is the return value from the add_device callback
>>>>> or point inside add_device callback which fails in your setup.
>>>>>
>>>>>
>>>>> [1] git://linux-arm.org/linux-rm iommu/misc
>>>>
>>>> With little more try, i saw an issue where i had an failure
>>>> similar to what you reported. The issue happens when multiple
>>>> devices fall in to same group due to matching sids. I ended up
>>>> doing a fix like below and it would be nice to verify if it is the same
>>>> that we are seeing in your setup and if the fix makes a difference ?
>>>>
>>>> From: Sricharan R <sricharan@codeaurora.org>
>>>> Date: Fri, 4 Nov 2016 20:28:49 +0530
>>>> Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
>>>>
>>>> iommu_group_get_for_dev which gets called in the add_device
>>>> callback, increases the reference count of the iommu_group,
>>>> so we do an iommu_group_put after that. iommu_group_get_for_dev
>>>> inturn calls device_group callback and in the case of arm-smmu
>>>> we call generic_device_group/pci_device_group which takes
>>>> care of increasing the group's reference. But when we return
>>>> an already existing group(when multiple devices have same group)
>>>> the reference is not incremented, resulting in issues when the
>>>> remove_device callback for the devices is invoked.
>>>> Fixing the same here.
>>>
>>>Bah, yes, this does look like my fault - after flip-flopping between
>>>about 3 different ways to keep refcounts for the S2CR entries, none of
>>>which would quite work, I ripped it all out but apparently still got
>>>things wrong, oh well. Thanks for figuring it out.
>> >
>>>On the probe-deferral angle, whilst it's useful to have uncovered this
>>>bug, I don't think we should actually be calling remove_device() from
>>>DMA teardown. I think it's preferable from a user perspective if group
>>>numbering remains stable, rather than changing depending on the order in
>>>which they unbind/rebind VFIO drivers. I'm really keen to try and get
>>>this in shape for 4.10, so I've taken the liberty of hacking up my own
>>>branch (iommu/defer) based on v3 - would you mind taking a look at the
>>>two "iommu/of:" commits to see what you think? (Ignore the PCI changes
>>>to your later patches - that was an experiment which didn't really work out)
>>
>>Ok, will take a look at this now and respond more on this.
>>
>Sorry for the delayed response on this. I was OOO for the last few days.
>So i tested this branch and it worked fine. I tested it with a pci device
>for both normal and deferred probe cases. The of/iommu patches
>are the cleanup/preparation patches and it looks fine. One thing is without
>calling the remove_device callback, the resources like (smes for exmaple)
>and the group association of the device all remain allocated. That does not
>feel correct, given that the associated device does not exist. So to
>understand that, what happens with VFIO in this case which makes the
>group renumbering/rebinding a problem ?
>
Would it be ok if i post a V4 based on your branch above ?
Regards,
Sricharan
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Jörg Krause @ 2016-11-20 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <585759233.283839.1cb53b4d-2805-48ea-aef1-dd282306d108.open-xchange@email.1und1.de>
Hi Stefan,
On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> Hi J?rg,
>
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016
> > um 13:27
> > geschrieben:
> >
> >
> > Hi,
> >
> > I started the discussion on this mailing list in another thread
> > [1],
> > but I'd like to move it to a new thread, because it might be mmc
> > specific.
> >
> > The issue is that I am noticed low wifi network throughput on an
> > i.MX28
> > board with the mainline kernel (v4.7.10, about 6 Mbps) compared to
> > the
> > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The wifi chip
> > is
> > attached using the SDIO interface.
> >
> > I started investigation where the bottleneck in the mainline
> > kernel?might come from. Therefore I checked that the configs and
> > settings for the interfaces and drivers are the same. They are.
>
> so you're not using the mxs_defconfig settings anymore?
No, I changed the settings.
> Better provide your settings because there are differences between
> the vendor defconfig and mainline defconfig.
The configs I have for the vendor and mainline kernel are pretty much
the same for the parts you showed as an example:
Vendor kernel config:
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_HZ=100
CONFIG_DEFAULT_IOSCHED="cfq"
Mainline kernel config:
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_HZ=100
CONFIG_DEFAULT_IOSCHED="cfq"
J?rg
^ permalink raw reply
* [GIT PULL 4/4] DaVinci defconfig updates for v4.10 (part 2)
From: Sekhar Nori @ 2016-11-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120134038.14998-1-nsekhar@ti.com>
The following changes since commit 6e9be8608771192851a3adf59f0ba9240e3f802c:
ARM: davinci_all_defconfig: enable LED default-on trigger (2016-11-01 11:42:54 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git davinci-for-v4.10/defconfig-2
for you to fetch changes up to a652baa06413a4beacc09425883e518c5f1ed100:
ARM: davinci_all_defconfig: add missing options for systemd (2016-11-15 15:44:52 +0530)
----------------------------------------------------------------
Enables newly introduced DDR controller and
master priority setting drivers in kernel.
Also, update defconfig to boot latest systemd
based filesystems on DA850.
----------------------------------------------------------------
Bartosz Golaszewski (1):
ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
Sekhar Nori (1):
ARM: davinci_all_defconfig: add missing options for systemd
arch/arm/configs/davinci_all_defconfig | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
^ permalink raw reply
* [GIT PULL 3/4] DaVinci DT updates for v4.10 (part 2)
From: Sekhar Nori @ 2016-11-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120134038.14998-1-nsekhar@ti.com>
The following changes since commit 1b499f255589204466d8f8ab26e6b577d7b5c88f:
ARM: dts: da850: Add cfgchip syscon node (2016-11-01 15:11:10 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git davinci-for-v4.10/dt-2
for you to fetch changes up to 83de086cc89410a8d4e0b6345e8a1116797ea703:
ARM: dts: da850-lcdk: Enable the usb otg device node (2016-11-20 17:02:18 +0530)
----------------------------------------------------------------
Adds device tree nodes enabling DDR controller
and bus master priority settings needed for
stable LCDC operation on DA850.
Also adds support for MUSB device on DA850
providing USB OTG support.
----------------------------------------------------------------
Alexandre Bailon (2):
ARM: dts: da850: Add the usb otg device node
ARM: dts: da850-lcdk: Enable the usb otg device node
Bartosz Golaszewski (1):
ARM: dts: da850: add the mstpri and ddrctl nodes
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
arch/arm/boot/dts/da850.dtsi | 18 ++++++++++++++++++
2 files changed, 26 insertions(+)
^ permalink raw reply
* [GIT PULL 2/4] DaVinci SoC updates for v4.10 (part 2)
From: Sekhar Nori @ 2016-11-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120134038.14998-1-nsekhar@ti.com>
The following changes since commit ced95ac0815501f47a6041548d70d8900400912d:
ARM: davinci: da8xx: register USB PHY clocks in the DT file (2016-11-01 15:24:24 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git davinci-for-v4.10/soc-2
for you to fetch changes up to 7e431af8fa0b9ed9d74378c99514856211cb9db8:
ARM: davinci: PM: support da8xx DT platforms (2016-11-16 14:45:07 +0530)
----------------------------------------------------------------
Adds suspend-to-RAM support for DT boot mode
on DA850.
----------------------------------------------------------------
Kevin Hilman (1):
ARM: davinci: PM: support da8xx DT platforms
arch/arm/mach-davinci/da8xx-dt.c | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [GIT PULL 1/4] DaVinci cleanups for v4.10 (part 2)
From: Sekhar Nori @ 2016-11-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 766763dbdc1dca11deabdb00077a1c19e2803f0a:
ARM: davinci: da8xx: Remove duplicated defines (2016-10-31 16:51:56 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git davinci-for-v4.10/cleanup-2
for you to fetch changes up to f7715b299954b1f1644253682e50f38282eee611:
ARM: davinci: PM: fix build when da850 not compiled in (2016-11-20 16:52:00 +0530)
----------------------------------------------------------------
mach-davinci cleanup to make it easy to add PM support
for DT-boot.
----------------------------------------------------------------
Kevin Hilman (3):
ARM: davinci: PM: rework init, remove platform device
ARM: davinci: PM: cleanup: remove references to pdata
ARM: davinci: PM: fix build when da850 not compiled in
arch/arm/mach-davinci/Makefile | 4 +-
arch/arm/mach-davinci/board-da850-evm.c | 17 +----
arch/arm/mach-davinci/board-mityomapl138.c | 16 +----
arch/arm/mach-davinci/common.c | 1 -
arch/arm/mach-davinci/da850.c | 38 -----------
arch/arm/mach-davinci/include/mach/da8xx.h | 1 -
arch/arm/mach-davinci/pm.c | 102 ++++++++++++++++-------------
7 files changed, 62 insertions(+), 117 deletions(-)
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Stefan Wahren @ 2016-11-20 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479644869.2653.3.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016 um 13:27
> geschrieben:
>
>
> Hi,
>
> I started the discussion on this mailing list in another thread [1],
> but I'd like to move it to a new thread, because it might be mmc
> specific.
>
> The issue is that I am noticed low wifi network throughput on an i.MX28
> board with the mainline kernel (v4.7.10, about 6 Mbps) compared to the
> vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The wifi chip is
> attached using the SDIO interface.
>
> I started investigation where the bottleneck in the mainline
> kernel?might come from. Therefore I checked that the configs and
> settings for the interfaces and drivers are the same. They are.
so you're not using the mxs_defconfig settings anymore? Better provide your
settings because there are differences between the vendor defconfig and mainline
defconfig.
Examples:
Vendor updater defconfig (2.6.35) - [1]
CONFIG_PREEMPTY_NONE=y
CONFIG_DEFAULT_IOSCHED="noop"
Vendor defconfig (2.6.35) - [2]
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_DEFAULT_IOSCHED="cfq"
Mainline defconfig (4.8) - [3]
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_DEFAULT_IOSCHED="noop"
[1] -
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/configs/imx28evk_updater_defconfig?h=imx_2.6.35_maintain
[2] -
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/configs/imx28evk_defconfig?h=imx_2.6.35_maintain
[3] - http://lxr.free-electrons.com/source/arch/arm/configs/mxs_defconfig?v=4.8
^ permalink raw reply
* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Russell King - ARM Linux @ 2016-11-20 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58319D70.7030106@math.uni-bielefeld.de>
On Sun, Nov 20, 2016 at 01:56:16PM +0100, Tobias Jakobi wrote:
> Hey Russell,
>
> thanks for the quick reply and looking into this!
>
> Added Nicolas Pitre to Cc since the ksym trim stuff came from him.
Arnd's patch "kbuild: provide include/asm/asm-prototypes.h for ARM" fixes
it, but I think it's a mixture of fixes, and partially dependent on some
other patches. I don't know what the status of his patch is, but my
feeling is that it consists of more than a single fix, and needs
splitting. Certainly the asm-prototypes.h is not relevant to this
problem, but the rest of it seems to be.
> Russell King - ARM Linux wrote:
> > On Sun, Nov 20, 2016 at 12:43:38PM +0100, Tobias Jakobi wrote:
> >> Hello Russell,
> >>
> >> Russell King - ARM Linux wrote:
> >>> None of the autobuilders are finding this problem, and they build a
> >>> wide range of configurations. Maybe it's something specific to how
> >>> you're building the kernel - can you give step by step instructions
> >>> how to reproduce this please?
> >> Just using plain make here, no cross-compiler or anything involved. gcc
> >> is version 4.9.4.
> >
> > Hmm. The commit you mention was merged during the merge window, so
> > anyone building 4.9-rc1 or later should be seeing this problem, but
> > they aren't. I've built many kernels post -rc1, and I'm not seeing
> > the problem with my 4.7.4 cross compiler.
> >
> >> Build platform is a Exynos4412 based ODROID-X2.
> >>
> >>
> >> The complete log from the 'build modules' step:
> >>> Building modules, stage 2.
> >>> Kernel: arch/arm/boot/Image is ready
> >>> MODPOST 52 modules
> >>> XZKERN arch/arm/boot/compressed/piggy_data
> >>> SHIPPED arch/arm/boot/compressed/lib1funcs.S
> >>> SHIPPED arch/arm/boot/compressed/ashldi3.S
> >>> SHIPPED arch/arm/boot/compressed/bswapsdi2.S
> >>> AS arch/arm/boot/compressed/lib1funcs.o
> >>> AS arch/arm/boot/compressed/ashldi3.o
> >>> AS arch/arm/boot/compressed/bswapsdi2.o
> >>> ERROR: "_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
> >>> ERROR: "_clear_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
> >>> ERROR: "_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
> >>> ERROR: "_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [sound/core/seq/snd-seq.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [sound/core/seq/snd-seq.ko] undefined!
> >>> ERROR: "_set_bit" [net/bridge/bridge.ko] undefined!
> >>> ERROR: "_clear_bit" [net/bridge/bridge.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [net/bluetooth/hidp/hidp.ko] undefined!
> >>> ERROR: "_set_bit" [net/bluetooth/hidp/hidp.ko] undefined!
> >>> ERROR: "_clear_bit" [net/bluetooth/hidp/hidp.ko] undefined!
> >>> ERROR: "_set_bit" [net/bluetooth/bnep/bnep.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [net/bluetooth/bnep/bnep.ko] undefined!
> >>> ERROR: "_clear_bit" [net/bluetooth/bnep/bnep.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [fs/fuse/fuse.ko] undefined!
> >>> ERROR: "_set_bit" [fs/fuse/fuse.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [fs/fuse/fuse.ko] undefined!
> >>> ERROR: "_clear_bit" [fs/fuse/fuse.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [fs/cifs/cifs.ko] undefined!
> >>> ERROR: "_set_bit" [fs/cifs/cifs.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [fs/cifs/cifs.ko] undefined!
> >>> ERROR: "_clear_bit" [fs/cifs/cifs.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [fs/btrfs/btrfs.ko] undefined!
> >>> ERROR: "_set_bit" [fs/btrfs/btrfs.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [fs/btrfs/btrfs.ko] undefined!
> >>> ERROR: "_clear_bit" [fs/btrfs/btrfs.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [drivers/usb/storage/usb-storage.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/usb/storage/usb-storage.ko] undefined!
> >>> ERROR: "_clear_bit" [drivers/usb/storage/usb-storage.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/usb/gadget/libcomposite.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/usb/gadget/function/usb_f_rndis.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> >>> ERROR: "_clear_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> >>> ERROR: "_clear_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> >>> ERROR: "_clear_bit" [drivers/md/dm-crypt.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/md/dm-crypt.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined!
> >>> ERROR: "_clear_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined!
> >>> ERROR: "_test_and_clear_bit" [drivers/bluetooth/btusb.ko] undefined!
> >>> ERROR: "_test_and_set_bit" [drivers/bluetooth/btusb.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/bluetooth/btusb.ko] undefined!
> >>> ERROR: "_clear_bit" [drivers/bluetooth/btusb.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/bluetooth/btintel.ko] undefined!
> >>> ERROR: "_set_bit" [drivers/bluetooth/btbcm.ko] undefined!
> >>> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> >>> make[1]: *** [__modpost] Error 1
> >>> Makefile:1191: recipe for target 'modules' failed
> >>> make: *** [modules] Error 2
> >>
> >>
> >> This is the config I'm using for the build:
> >> https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.9-debug.conf
> >
> > You have CONFIG_TRIM_UNUSED_KSYMS enabled - I wonder if that's the
> > issue. I've just enabled that here, and building I see:
> Thanks, I had this enabled on purpose since I don't need any out-of-tree
> drivers for this board.
>
> I'll check if disabling TRIM_UNUSED_KSYMS also does the trick for me.
>
>
> With best wishes,
> Tobias
>
>
> > EXPORTS lib/lib-ksyms.o
> > LD lib/built-in.o
> > CHK include/generated/autoksyms.h
> > KSYMS symbols: before=0, after=2413, changed=2413
> > UPD include/generated/autoksyms.h
> >
> > and then the build seems to restart from the very beginning, which seems
> > rather fishy - it doubles the build time of the kernel. The second
> > build doesn't even hit any ccache entries from the first build. Then we
> > get through the rebuild, and I get:
> >
> > EXPORTS lib/lib-ksyms.o
> > LD lib/built-in.o
> > CHK include/generated/autoksyms.h
> > LD vmlinux.o
> > ...
> > LD vmlinux
> > SORTEX vmlinux
> > SYSMAP System.map
> > Building modules, stage 2.
> > OBJCOPY arch/arm/boot/Image
> > Kernel: arch/arm/boot/Image is ready
> > AS arch/arm/boot/compressed/head.o
> > LZO arch/arm/boot/compressed/piggy_data
> > MODPOST 465 modules
> > ERROR: CC arch/arm/boot/compressed/misc.o
> > "_clear_bit" [net/sched/sch_teql.ko] undefined!
> > ERROR: "_set_bit" [net/sched/sch_teql.ko] undefined!
> > ERROR: "_set_bit" [net/sched/cls_u32.ko] undefined!
> > ERROR: "_test_and_set_bit" [net/netfilter/nfnetlink_acct.ko] undefined!
> > ERROR: "_clear_bit" [net/netfilter/nfnetlink_acct.ko] undefined!
> > ERROR: "_test_and_clear_bit" [net/mac80211/mac80211.ko] undefined!
> > ERROR: "_set_bit" [net/mac80211/mac80211.ko] undefined!
> > ERROR: "_test_and_set_bit" [net/mac80211/mac80211.ko] undefined!
> > ERROR: "_clear_bit" [net/mac80211/mac80211.ko] undefined!
> >
> > So yes, it's caused by this ksyms trimming.
> >
> > Now, the thing is that include/generated/autoksyms.h contains:
> >
> > #define __KSYM__change_bit 1
> > #define __KSYM__clear_bit 1
> > #define __KSYM__set_bit 1
> > #define __KSYM__test_and_change_bit 1
> > #define __KSYM__test_and_clear_bit 1
> > #define __KSYM__test_and_set_bit 1
> >
> > amongst many other stuff - presumably this is a list of ksyms which
> > should be included, rather than a list of what should be excluded.
> >
> > I'm afraid that I never saw the patches which changed the way the ksyms
> > stuff worked for the assembly files, and these patches have caused
> > several problems for ARM. I'm not aware of what the changes were, or
> > how the damn exports now work, so I'm currently at a loss what to
> > suggest at the moment, other than to disable CONFIG_TRIM_UNUSED_KSYMS in
> > your configuration until someone can work out wtf is going on.
> >
> > I guess I'm going to have to work out how this stuff now works - don't
> > expect a solution quickly, especially as building with this option
> > enabled is soo time consuming (like, half an hour per build.)
> >
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v8 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Christoffer Dall @ 2016-11-20 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6uxU8nC+gayWAxf_BX7JrZ9twsFr4YfMr64bNUSneqZow@mail.gmail.com>
On Sat, Nov 19, 2016 at 12:18:53AM +0530, Vijay Kilari wrote:
> On Thu, Nov 17, 2016 at 9:39 PM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Thu, Nov 17, 2016 at 09:25:59PM +0530, Vijay Kilari wrote:
> >> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
> >> <christoffer.dall@linaro.org> wrote:
> >> > On Fri, Nov 04, 2016 at 04:43:32PM +0530, vijay.kilari at gmail.com wrote:
> >> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> >>
> >> >> VGICv3 CPU interface registers are accessed using
> >> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
> >> >> as 64-bit. The cpu MPIDR value is passed along with register id.
> >> >> is used to identify the cpu for registers access.
> >> >>
> >> >> The version of VGIC v3 specification is define here
> >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
> >> >>
> >> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
> >> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> >> ---
> >> >> arch/arm64/include/uapi/asm/kvm.h | 3 +
> >> >> arch/arm64/kvm/Makefile | 1 +
> >> >> include/kvm/arm_vgic.h | 9 +
> >> >> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 +++
> >> >> virt/kvm/arm/vgic/vgic-mmio-v3.c | 19 +++
> >> >> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
> >> >> virt/kvm/arm/vgic/vgic-v3.c | 8 +
> >> >> virt/kvm/arm/vgic/vgic.h | 4 +
> >> >> 8 files changed, 395 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> >> >> index 56dc08d..91c7137 100644
> >> >> --- a/arch/arm64/include/uapi/asm/kvm.h
> >> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
> >> >> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
> >> >> (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
> >> >> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
> >> >> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> >> >> +#define KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
> >> >> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
> >> >> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> >> >> #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
> >> >> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS 6
> >> >> +
> >> >> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
> >> >>
> >> >> /* Device Control API on vcpu fd */
> >> >> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> >> >> index d50a82a..1a14e29 100644
> >> >> --- a/arch/arm64/kvm/Makefile
> >> >> +++ b/arch/arm64/kvm/Makefile
> >> >> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
> >> >> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
> >> >
> >> > Thi is making me wonder: Are we properly handling GICv3 save/restore
> >> > for AArch32 now that we have GICv3 support for AArch32? By properly I
> >> > mean that either it is clearly only supported on AArch64 systems or it's
> >> > supported on both AArch64 and AArch32, but it shouldn't break randomly
> >> > on AArch32.
> >>
> >> It supports both AArch64 and AArch64 in handling of system registers
> >> save/restore.
> >> All system registers that we save/restore are 32-bit for both aarch64
> >> and aarch32.
> >> Though opcode op0 should be zero for aarch32, the remaining Op and CRn codes
> >> are same. However the codes sent by qemu is matched and register
> >> are handled properly irrespective of AArch32 or AArch64.
> >>
> >> I don't have platform which support AArch32 guests to verify.
> >
> > Actually this is not about the guest, it's about an ARMv8 AArch32 host
> > that has a GICv3.
> >
> > I just tried to do a v7 compile with your patches, and it results in an
> > epic failure, so there's something for you to look at.
> >
>
> Could you please share you config file?. I tried with multi_v7 defconfig with
> CONFIG KVM and CONFIG_KVM_ARM_HOST enabled. it compiled for me.
I think this has to do with which branch you apply your patches to.
When applied to kvmarm/next, it fails.
Here's the integration I did:
https://git.linaro.org/people/christoffer.dall/linux-kvm-arm.git tmp-gicv3-migrate-v8
Here's the config:
https://transfer.sh/xkAxp/.config
Here's the compile output:
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.c:26:22: fatal error: sys_regs.h: No such file or directory
#include "sys_regs.h"
^
compilation terminated.
make[2]: *** [arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_parse_attr?:
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:438:29: error: ?KVM_DEV_ARM_VGIC_V3_MPIDR_MASK? undeclared (first use in this function)
vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:438:29: note: each undeclared identifier is reported only once for each function it appears in
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:439:9: error: ?KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT? undeclared (first use in this function)
KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:441:2: error: implicit declaration of function ?MPIDR_LEVEL_SHIFT? [-Werror=implicit-function-declaration]
mpidr_reg = VGIC_TO_MPIDR(vgic_mpidr);
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_attr_regs_access?:
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:497:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:505:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:508:25: error: ?KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK? undeclared (first use in this function)
regid = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:513:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:516:24: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK? undeclared (first use in this function)
info = (attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:517:4: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT? undeclared (first use in this function)
KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT;
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:518:15: error: ?VGIC_LEVEL_INFO_LINE_LEVEL? undeclared (first use in this function)
if (info == VGIC_LEVEL_INFO_LINE_LEVEL) {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:522:5: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK? undeclared (first use in this function)
KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK;
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_set_attr?:
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:554:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS: {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:565:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:574:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_get_attr?:
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:600:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS: {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:611:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:620:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_has_attr?:
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:647:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:648:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_CPU_SYSREGS:
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:652:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:653:22: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK? undeclared (first use in this function)
if (((attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:654:9: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT? undeclared (first use in this function)
KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT) ==
^
/home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:655:9: error: ?VGIC_LEVEL_INFO_LINE_LEVEL? undeclared (first use in this function)
VGIC_LEVEL_INFO_LINE_LEVEL)
^
cc1: some warnings being treated as errors
make[2]: *** [arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.o] Error 1
make[1]: *** [arch/arm/kvm] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [sub-make] Error 2
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v5 0/2] platform: Add DT support for DA8xx
From: Sekhar Nori @ 2016-11-20 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479294456-7942-1-git-send-email-abailon@baylibre.com>
On Wednesday 16 November 2016 04:37 PM, Alexandre Bailon wrote:
> This add and enable the usb otg for da850 and da850-lcdk.
> This series depends on "driver: dd DT support for DA8xx" patch set.
I see that Bin has already applied this.
> If this series is applied before the "usb: musb: da8xx: Fix few issues" patch
> set then the usb driver will always retrun -ENODEV.
And this seems to be applied too. So I am going ahead and applying this
series.
For future, please add some information on which device you are
referring to in the subject line. Reading the subject line for the
cover-letter, there is no way to know what exactly is being worked on here.
Thanks,
Sekhar
^ permalink raw reply
* i.MX6UL: feature state of linux-fslc 4.1.x vs mainline
From: Fabio Estevam @ 2016-11-20 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKP5S=2WAdCfONGQEAup7yUGXp615QUZ83oAYmyJ6kjGhAG_YQ@mail.gmail.com>
Hi Nicolae,
On Thu, Nov 17, 2016 at 10:56 AM, Nicolae Rosia
<nicolae.rosia.oss@gmail.com> wrote:
> Hello,
>
> I'm wondering if there is a table of missing features that are present
> in Linux freescale 4.1.x [0] and are not present in latest mainline
> kernel with regards to NXP i.MX6UL SoC.
I don't think there is such table available.
> Is there a reason why I should go with linux-fslc for this SoC ?
You can use mainline kernel with mx6ul.
>From the top of my head it still misses PXP and camera support though.
^ permalink raw reply
* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Corentin Labbe @ 2016-11-20 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120123422.GT1041@n2100.armlinux.org.uk>
On Sun, Nov 20, 2016 at 12:34:22PM +0000, Russell King - ARM Linux wrote:
> On Sun, Nov 20, 2016 at 12:43:38PM +0100, Tobias Jakobi wrote:
> > Hello Russell,
> >
> > Russell King - ARM Linux wrote:
> > > None of the autobuilders are finding this problem, and they build a
> > > wide range of configurations. Maybe it's something specific to how
> > > you're building the kernel - can you give step by step instructions
> > > how to reproduce this please?
> > Just using plain make here, no cross-compiler or anything involved. gcc
> > is version 4.9.4.
>
> Hmm. The commit you mention was merged during the merge window, so
> anyone building 4.9-rc1 or later should be seeing this problem, but
> they aren't. I've built many kernels post -rc1, and I'm not seeing
> the problem with my 4.7.4 cross compiler.
>
I have the same issue here on all my Allwinner ARM device.
I have not reported this issue since I believed to see some report of it.
I cross compile with armv7a-hardfloat-linux-gnueabi-4.9.3.
With CONFIG_UNUSED_SYMBOLS set, the issue disapear
Regards
^ permalink raw reply
* [PATCH] spi: davinci: Allow device tree devices to use DMA
From: Sekhar Nori @ 2016-11-20 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479530464-12538-1-git-send-email-david@lechnology.com>
On Saturday 19 November 2016 10:11 AM, David Lechner wrote:
> This makes SPI devices specified in a device tree use DMA when the master
> controller has DMA configured.
>
> Since device tree is supposed to only describe the hardware, adding a
> configuration option to device tree to enable DMA per-device would not be
> acceptable. So, this is the best we can do for now to get SPI devices
> working with DMA when using device tree.
>
> Unfortunately, this excludes the possibility of using one SPI device with
> DMA and one without on the same master.
>
> I have tested this on LEGO MINDSTORMS EV3 using the NOR flash. Reading the
> flash memory would fail with -EIO when DMA is not enabled for the device.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> drivers/spi/spi-davinci.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
> index d36c11b..c6cf73a 100644
> --- a/drivers/spi/spi-davinci.c
> +++ b/drivers/spi/spi-davinci.c
> @@ -388,6 +388,7 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
> static int davinci_spi_of_setup(struct spi_device *spi)
> {
> struct davinci_spi_config *spicfg = spi->controller_data;
> + struct davinci_spi *dspi = spi_master_get_devdata(spi->master);
> struct device_node *np = spi->dev.of_node;
> u32 prop;
>
> @@ -400,6 +401,9 @@ static int davinci_spi_of_setup(struct spi_device *spi)
> if (!of_property_read_u32(np, "ti,spi-wdelay", &prop))
> spicfg->wdelay = (u8)prop;
> spi->controller_data = spicfg;
> + /* Use DMA for device if master supports it */
> + if (dspi->dma_rx)
This should be
if (!(IS_ERR(dpsi->dma_rx) || IS_ERR(dspi->dma_tx))
> + spicfg->io_type = SPI_IO_TYPE_DMA;
Otherwise looks good to me.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] mfd: twl-core: make driver DT only
From: Nicolae Rosia @ 2016-11-20 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118190115.GB23246@dell.home>
Hi,
On Fri, Nov 18, 2016 at 9:01 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Sat, 12 Nov 2016, Nicolae Rosia wrote:
>
>> All users are DT-only and it makes no sense to keep
>> unused code
>>
>> Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
>> ---
>> drivers/mfd/Kconfig | 1 +
>> drivers/mfd/twl-core.c | 395 ++-----------------------------------------------
>> 2 files changed, 10 insertions(+), 386 deletions(-)
>
> I think it would be courteous to add some of the serious contributors
> to the review list.
>
> There may still be some out of tree users who might wish for a
> heads-up that this change is about to be merged.
Thanks, sure, I will do that in v2.
^ permalink raw reply
* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Tobias Jakobi @ 2016-11-20 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120123422.GT1041@n2100.armlinux.org.uk>
Hey Russell,
thanks for the quick reply and looking into this!
Added Nicolas Pitre to Cc since the ksym trim stuff came from him.
Russell King - ARM Linux wrote:
> On Sun, Nov 20, 2016 at 12:43:38PM +0100, Tobias Jakobi wrote:
>> Hello Russell,
>>
>> Russell King - ARM Linux wrote:
>>> None of the autobuilders are finding this problem, and they build a
>>> wide range of configurations. Maybe it's something specific to how
>>> you're building the kernel - can you give step by step instructions
>>> how to reproduce this please?
>> Just using plain make here, no cross-compiler or anything involved. gcc
>> is version 4.9.4.
>
> Hmm. The commit you mention was merged during the merge window, so
> anyone building 4.9-rc1 or later should be seeing this problem, but
> they aren't. I've built many kernels post -rc1, and I'm not seeing
> the problem with my 4.7.4 cross compiler.
>
>> Build platform is a Exynos4412 based ODROID-X2.
>>
>>
>> The complete log from the 'build modules' step:
>>> Building modules, stage 2.
>>> Kernel: arch/arm/boot/Image is ready
>>> MODPOST 52 modules
>>> XZKERN arch/arm/boot/compressed/piggy_data
>>> SHIPPED arch/arm/boot/compressed/lib1funcs.S
>>> SHIPPED arch/arm/boot/compressed/ashldi3.S
>>> SHIPPED arch/arm/boot/compressed/bswapsdi2.S
>>> AS arch/arm/boot/compressed/lib1funcs.o
>>> AS arch/arm/boot/compressed/ashldi3.o
>>> AS arch/arm/boot/compressed/bswapsdi2.o
>>> ERROR: "_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
>>> ERROR: "_test_and_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
>>> ERROR: "_clear_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
>>> ERROR: "_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
>>> ERROR: "_test_and_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
>>> ERROR: "_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [sound/core/seq/snd-seq.ko] undefined!
>>> ERROR: "_test_and_set_bit" [sound/core/seq/snd-seq.ko] undefined!
>>> ERROR: "_set_bit" [net/bridge/bridge.ko] undefined!
>>> ERROR: "_clear_bit" [net/bridge/bridge.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [net/bluetooth/hidp/hidp.ko] undefined!
>>> ERROR: "_set_bit" [net/bluetooth/hidp/hidp.ko] undefined!
>>> ERROR: "_clear_bit" [net/bluetooth/hidp/hidp.ko] undefined!
>>> ERROR: "_set_bit" [net/bluetooth/bnep/bnep.ko] undefined!
>>> ERROR: "_test_and_set_bit" [net/bluetooth/bnep/bnep.ko] undefined!
>>> ERROR: "_clear_bit" [net/bluetooth/bnep/bnep.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [fs/fuse/fuse.ko] undefined!
>>> ERROR: "_set_bit" [fs/fuse/fuse.ko] undefined!
>>> ERROR: "_test_and_set_bit" [fs/fuse/fuse.ko] undefined!
>>> ERROR: "_clear_bit" [fs/fuse/fuse.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [fs/cifs/cifs.ko] undefined!
>>> ERROR: "_set_bit" [fs/cifs/cifs.ko] undefined!
>>> ERROR: "_test_and_set_bit" [fs/cifs/cifs.ko] undefined!
>>> ERROR: "_clear_bit" [fs/cifs/cifs.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [fs/btrfs/btrfs.ko] undefined!
>>> ERROR: "_set_bit" [fs/btrfs/btrfs.ko] undefined!
>>> ERROR: "_test_and_set_bit" [fs/btrfs/btrfs.ko] undefined!
>>> ERROR: "_clear_bit" [fs/btrfs/btrfs.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [drivers/usb/storage/usb-storage.ko] undefined!
>>> ERROR: "_set_bit" [drivers/usb/storage/usb-storage.ko] undefined!
>>> ERROR: "_clear_bit" [drivers/usb/storage/usb-storage.ko] undefined!
>>> ERROR: "_set_bit" [drivers/usb/gadget/libcomposite.ko] undefined!
>>> ERROR: "_set_bit" [drivers/usb/gadget/function/usb_f_rndis.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
>>> ERROR: "_test_and_set_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
>>> ERROR: "_clear_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
>>> ERROR: "_set_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
>>> ERROR: "_set_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
>>> ERROR: "_test_and_set_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
>>> ERROR: "_clear_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
>>> ERROR: "_clear_bit" [drivers/md/dm-crypt.ko] undefined!
>>> ERROR: "_set_bit" [drivers/md/dm-crypt.ko] undefined!
>>> ERROR: "_set_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined!
>>> ERROR: "_clear_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [drivers/bluetooth/btusb.ko] undefined!
>>> ERROR: "_test_and_set_bit" [drivers/bluetooth/btusb.ko] undefined!
>>> ERROR: "_set_bit" [drivers/bluetooth/btusb.ko] undefined!
>>> ERROR: "_clear_bit" [drivers/bluetooth/btusb.ko] undefined!
>>> ERROR: "_set_bit" [drivers/bluetooth/btintel.ko] undefined!
>>> ERROR: "_set_bit" [drivers/bluetooth/btbcm.ko] undefined!
>>> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>>> make[1]: *** [__modpost] Error 1
>>> Makefile:1191: recipe for target 'modules' failed
>>> make: *** [modules] Error 2
>>
>>
>> This is the config I'm using for the build:
>> https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.9-debug.conf
>
> You have CONFIG_TRIM_UNUSED_KSYMS enabled - I wonder if that's the
> issue. I've just enabled that here, and building I see:
Thanks, I had this enabled on purpose since I don't need any out-of-tree
drivers for this board.
I'll check if disabling TRIM_UNUSED_KSYMS also does the trick for me.
With best wishes,
Tobias
> EXPORTS lib/lib-ksyms.o
> LD lib/built-in.o
> CHK include/generated/autoksyms.h
> KSYMS symbols: before=0, after=2413, changed=2413
> UPD include/generated/autoksyms.h
>
> and then the build seems to restart from the very beginning, which seems
> rather fishy - it doubles the build time of the kernel. The second
> build doesn't even hit any ccache entries from the first build. Then we
> get through the rebuild, and I get:
>
> EXPORTS lib/lib-ksyms.o
> LD lib/built-in.o
> CHK include/generated/autoksyms.h
> LD vmlinux.o
> ...
> LD vmlinux
> SORTEX vmlinux
> SYSMAP System.map
> Building modules, stage 2.
> OBJCOPY arch/arm/boot/Image
> Kernel: arch/arm/boot/Image is ready
> AS arch/arm/boot/compressed/head.o
> LZO arch/arm/boot/compressed/piggy_data
> MODPOST 465 modules
> ERROR: CC arch/arm/boot/compressed/misc.o
> "_clear_bit" [net/sched/sch_teql.ko] undefined!
> ERROR: "_set_bit" [net/sched/sch_teql.ko] undefined!
> ERROR: "_set_bit" [net/sched/cls_u32.ko] undefined!
> ERROR: "_test_and_set_bit" [net/netfilter/nfnetlink_acct.ko] undefined!
> ERROR: "_clear_bit" [net/netfilter/nfnetlink_acct.ko] undefined!
> ERROR: "_test_and_clear_bit" [net/mac80211/mac80211.ko] undefined!
> ERROR: "_set_bit" [net/mac80211/mac80211.ko] undefined!
> ERROR: "_test_and_set_bit" [net/mac80211/mac80211.ko] undefined!
> ERROR: "_clear_bit" [net/mac80211/mac80211.ko] undefined!
>
> So yes, it's caused by this ksyms trimming.
>
> Now, the thing is that include/generated/autoksyms.h contains:
>
> #define __KSYM__change_bit 1
> #define __KSYM__clear_bit 1
> #define __KSYM__set_bit 1
> #define __KSYM__test_and_change_bit 1
> #define __KSYM__test_and_clear_bit 1
> #define __KSYM__test_and_set_bit 1
>
> amongst many other stuff - presumably this is a list of ksyms which
> should be included, rather than a list of what should be excluded.
>
> I'm afraid that I never saw the patches which changed the way the ksyms
> stuff worked for the assembly files, and these patches have caused
> several problems for ARM. I'm not aware of what the changes were, or
> how the damn exports now work, so I'm currently at a loss what to
> suggest at the moment, other than to disable CONFIG_TRIM_UNUSED_KSYMS in
> your configuration until someone can work out wtf is going on.
>
> I guess I'm going to have to work out how this stuff now works - don't
> expect a solution quickly, especially as building with this option
> enabled is soo time consuming (like, half an hour per build.)
>
^ permalink raw reply
* [PATCH] mfd: twl-core: export twl_get_regmap
From: Nicolae Rosia @ 2016-11-20 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118185548.GA23246@dell.home>
On Fri, Nov 18, 2016 at 8:55 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Sat, 12 Nov 2016, Nicolae Rosia wrote:
>
>> We want to get rid of global twl_i2c_{write/read}.
>> As a first step, allow clients to get the regmap and write directly
>
> What's stopping you from passing it through device data?
>
Could you elaborate a bit?
The regmaps are stored in struct twl_client [0], stored in struct
twl_private [1], both structs are defined in the source file, not in
header.
I could however just fix the problem by reworking the struct, exposing
it and use mfd_add_device as real mfd drivers do.
[0] http://lxr.free-electrons.com/source/drivers/mfd/twl-core.c#L152
[1] http://lxr.free-electrons.com/source/drivers/mfd/twl-core.c#L163
^ permalink raw reply
* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Russell King - ARM Linux @ 2016-11-20 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58318C6A.50104@math.uni-bielefeld.de>
On Sun, Nov 20, 2016 at 12:43:38PM +0100, Tobias Jakobi wrote:
> Hello Russell,
>
> Russell King - ARM Linux wrote:
> > None of the autobuilders are finding this problem, and they build a
> > wide range of configurations. Maybe it's something specific to how
> > you're building the kernel - can you give step by step instructions
> > how to reproduce this please?
> Just using plain make here, no cross-compiler or anything involved. gcc
> is version 4.9.4.
Hmm. The commit you mention was merged during the merge window, so
anyone building 4.9-rc1 or later should be seeing this problem, but
they aren't. I've built many kernels post -rc1, and I'm not seeing
the problem with my 4.7.4 cross compiler.
> Build platform is a Exynos4412 based ODROID-X2.
>
>
> The complete log from the 'build modules' step:
> > Building modules, stage 2.
> > Kernel: arch/arm/boot/Image is ready
> > MODPOST 52 modules
> > XZKERN arch/arm/boot/compressed/piggy_data
> > SHIPPED arch/arm/boot/compressed/lib1funcs.S
> > SHIPPED arch/arm/boot/compressed/ashldi3.S
> > SHIPPED arch/arm/boot/compressed/bswapsdi2.S
> > AS arch/arm/boot/compressed/lib1funcs.o
> > AS arch/arm/boot/compressed/ashldi3.o
> > AS arch/arm/boot/compressed/bswapsdi2.o
> > ERROR: "_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
> > ERROR: "_test_and_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
> > ERROR: "_clear_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
> > ERROR: "_test_and_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
> > ERROR: "_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
> > ERROR: "_test_and_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
> > ERROR: "_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
> > ERROR: "_test_and_clear_bit" [sound/core/seq/snd-seq.ko] undefined!
> > ERROR: "_test_and_set_bit" [sound/core/seq/snd-seq.ko] undefined!
> > ERROR: "_set_bit" [net/bridge/bridge.ko] undefined!
> > ERROR: "_clear_bit" [net/bridge/bridge.ko] undefined!
> > ERROR: "_test_and_clear_bit" [net/bluetooth/hidp/hidp.ko] undefined!
> > ERROR: "_set_bit" [net/bluetooth/hidp/hidp.ko] undefined!
> > ERROR: "_clear_bit" [net/bluetooth/hidp/hidp.ko] undefined!
> > ERROR: "_set_bit" [net/bluetooth/bnep/bnep.ko] undefined!
> > ERROR: "_test_and_set_bit" [net/bluetooth/bnep/bnep.ko] undefined!
> > ERROR: "_clear_bit" [net/bluetooth/bnep/bnep.ko] undefined!
> > ERROR: "_test_and_clear_bit" [fs/fuse/fuse.ko] undefined!
> > ERROR: "_set_bit" [fs/fuse/fuse.ko] undefined!
> > ERROR: "_test_and_set_bit" [fs/fuse/fuse.ko] undefined!
> > ERROR: "_clear_bit" [fs/fuse/fuse.ko] undefined!
> > ERROR: "_test_and_clear_bit" [fs/cifs/cifs.ko] undefined!
> > ERROR: "_set_bit" [fs/cifs/cifs.ko] undefined!
> > ERROR: "_test_and_set_bit" [fs/cifs/cifs.ko] undefined!
> > ERROR: "_clear_bit" [fs/cifs/cifs.ko] undefined!
> > ERROR: "_test_and_clear_bit" [fs/btrfs/btrfs.ko] undefined!
> > ERROR: "_set_bit" [fs/btrfs/btrfs.ko] undefined!
> > ERROR: "_test_and_set_bit" [fs/btrfs/btrfs.ko] undefined!
> > ERROR: "_clear_bit" [fs/btrfs/btrfs.ko] undefined!
> > ERROR: "_test_and_clear_bit" [drivers/usb/storage/usb-storage.ko] undefined!
> > ERROR: "_set_bit" [drivers/usb/storage/usb-storage.ko] undefined!
> > ERROR: "_clear_bit" [drivers/usb/storage/usb-storage.ko] undefined!
> > ERROR: "_set_bit" [drivers/usb/gadget/libcomposite.ko] undefined!
> > ERROR: "_set_bit" [drivers/usb/gadget/function/usb_f_rndis.ko] undefined!
> > ERROR: "_test_and_clear_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> > ERROR: "_test_and_set_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> > ERROR: "_clear_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> > ERROR: "_set_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> > ERROR: "_test_and_clear_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> > ERROR: "_set_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> > ERROR: "_test_and_set_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> > ERROR: "_clear_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> > ERROR: "_clear_bit" [drivers/md/dm-crypt.ko] undefined!
> > ERROR: "_set_bit" [drivers/md/dm-crypt.ko] undefined!
> > ERROR: "_set_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined!
> > ERROR: "_clear_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined!
> > ERROR: "_test_and_clear_bit" [drivers/bluetooth/btusb.ko] undefined!
> > ERROR: "_test_and_set_bit" [drivers/bluetooth/btusb.ko] undefined!
> > ERROR: "_set_bit" [drivers/bluetooth/btusb.ko] undefined!
> > ERROR: "_clear_bit" [drivers/bluetooth/btusb.ko] undefined!
> > ERROR: "_set_bit" [drivers/bluetooth/btintel.ko] undefined!
> > ERROR: "_set_bit" [drivers/bluetooth/btbcm.ko] undefined!
> > scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> > make[1]: *** [__modpost] Error 1
> > Makefile:1191: recipe for target 'modules' failed
> > make: *** [modules] Error 2
>
>
> This is the config I'm using for the build:
> https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.9-debug.conf
You have CONFIG_TRIM_UNUSED_KSYMS enabled - I wonder if that's the
issue. I've just enabled that here, and building I see:
EXPORTS lib/lib-ksyms.o
LD lib/built-in.o
CHK include/generated/autoksyms.h
KSYMS symbols: before=0, after=2413, changed=2413
UPD include/generated/autoksyms.h
and then the build seems to restart from the very beginning, which seems
rather fishy - it doubles the build time of the kernel. The second
build doesn't even hit any ccache entries from the first build. Then we
get through the rebuild, and I get:
EXPORTS lib/lib-ksyms.o
LD lib/built-in.o
CHK include/generated/autoksyms.h
LD vmlinux.o
...
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
Building modules, stage 2.
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
LZO arch/arm/boot/compressed/piggy_data
MODPOST 465 modules
ERROR: CC arch/arm/boot/compressed/misc.o
"_clear_bit" [net/sched/sch_teql.ko] undefined!
ERROR: "_set_bit" [net/sched/sch_teql.ko] undefined!
ERROR: "_set_bit" [net/sched/cls_u32.ko] undefined!
ERROR: "_test_and_set_bit" [net/netfilter/nfnetlink_acct.ko] undefined!
ERROR: "_clear_bit" [net/netfilter/nfnetlink_acct.ko] undefined!
ERROR: "_test_and_clear_bit" [net/mac80211/mac80211.ko] undefined!
ERROR: "_set_bit" [net/mac80211/mac80211.ko] undefined!
ERROR: "_test_and_set_bit" [net/mac80211/mac80211.ko] undefined!
ERROR: "_clear_bit" [net/mac80211/mac80211.ko] undefined!
So yes, it's caused by this ksyms trimming.
Now, the thing is that include/generated/autoksyms.h contains:
#define __KSYM__change_bit 1
#define __KSYM__clear_bit 1
#define __KSYM__set_bit 1
#define __KSYM__test_and_change_bit 1
#define __KSYM__test_and_clear_bit 1
#define __KSYM__test_and_set_bit 1
amongst many other stuff - presumably this is a list of ksyms which
should be included, rather than a list of what should be excluded.
I'm afraid that I never saw the patches which changed the way the ksyms
stuff worked for the assembly files, and these patches have caused
several problems for ARM. I'm not aware of what the changes were, or
how the damn exports now work, so I'm currently at a loss what to
suggest at the moment, other than to disable CONFIG_TRIM_UNUSED_KSYMS in
your configuration until someone can work out wtf is going on.
I guess I'm going to have to work out how this stuff now works - don't
expect a solution quickly, especially as building with this option
enabled is soo time consuming (like, half an hour per build.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Jörg Krause @ 2016-11-20 12:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I started the discussion on this mailing list in another thread [1],
but I'd like to move it to a new thread, because it might be mmc
specific.
The issue is that I am noticed low wifi network throughput on an i.MX28
board with the mainline kernel (v4.7.10, about 6 Mbps) compared to the
vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The wifi chip is
attached using the SDIO interface.
I started investigation where the bottleneck in the mainline
kernel?might come from. Therefore I checked that the configs and
settings for the interfaces and drivers are the same. They are.
For comparing both kernel version I measured the latency for the
different parts in the code flow by adding some GPIOs to toggle and
useing an osci.
It turns out, that the time needed do pass a mmc request from the wifi
driver to the dma and waiting for the response of the dma is almost the
same for both kernel versions. So the path from the wifi driver to the
dma driver is not the issue.
However, the major difference was the time needed to signal the
completion of the request back to the mmc core driver.
For mainline, the time elapsed?from calling complete() in
mmc_wait_done() [2] in the mmc core driver until actually receiving the
completion signal in mmc_wait_for_req_done() [3] is about 120 us.
Whereas, for the vendor kernel,?the elapsed time for this notifcation
is about 100 us less!
I wonder why the notification takes so much longer in the mainline
kernel than in the vendor kernel? Where should I start looking at to
eliminate this bottleneck? Is it a scheduling issue?
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/
461137.html
[2] http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L386
[3] http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L492
Best regards,
J?rg Krause
^ permalink raw reply
* [PATCH v4] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Ard Biesheuvel @ 2016-11-20 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479642121-17912-1-git-send-email-ard.biesheuvel@linaro.org>
On 20 November 2016 at 11:42, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>
> Relative performance compared to the respective generic C versions:
>
> | SHA256-scalar | SHA256-NEON* | SHA512 |
> ------------+-----------------+--------------+----------+
> Cortex-A53 | 1.63x | 1.63x | 2.34x |
> Cortex-A57 | 1.43x | 1.59x | 1.95x |
> Cortex-A73 | 1.26x | 1.56x | ? |
>
> The core crypto code was authored by Andy Polyakov of the OpenSSL
> project, in collaboration with whom the upstream code was adapted so
> that this module can be built from the same version of sha512-armv8.pl.
>
> The version in this patch was taken from OpenSSL commit 32bbb62ea634
> ("sha/asm/sha512-armv8.pl: fix big-endian support in __KERNEL__ case.")
>
> * The core SHA algorithm is fundamentally sequential, but there is a
> secondary transformation involved, called the schedule update, which
> can be performed independently. The NEON version of SHA-224/SHA-256
> only implements this part of the algorithm using NEON instructions,
> the sequential part is always done using scalar instructions.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
Missing changelog:
v4: fixed the big-endian build; this required an upstream change (even
though upstream was not actually broken, since it explicitly defines
__ARMEB__ on AArch64 big-endian builds), so this patch is now based
on a more recent upstream OpenSSL commit (the __ILP32__ #ifdefs are
still present but never active)
v3: at Will's request, the generated assembly files are now included
as .S_shipped files, for which generic build rules are defined
already.
Note that sizeable patches like this one have caused issues in the past with
patchwork, so for Herbert's convenience, the patch can be pulled from
http://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git, branch
arm64-sha256 (based on today's cryptodev)
^ permalink raw reply
* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Tobias Jakobi @ 2016-11-20 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120113007.GS1041@n2100.armlinux.org.uk>
Hello Russell,
Russell King - ARM Linux wrote:
> None of the autobuilders are finding this problem, and they build a
> wide range of configurations. Maybe it's something specific to how
> you're building the kernel - can you give step by step instructions
> how to reproduce this please?
Just using plain make here, no cross-compiler or anything involved. gcc
is version 4.9.4.
Build platform is a Exynos4412 based ODROID-X2.
The complete log from the 'build modules' step:
> Building modules, stage 2.
> Kernel: arch/arm/boot/Image is ready
> MODPOST 52 modules
> XZKERN arch/arm/boot/compressed/piggy_data
> SHIPPED arch/arm/boot/compressed/lib1funcs.S
> SHIPPED arch/arm/boot/compressed/ashldi3.S
> SHIPPED arch/arm/boot/compressed/bswapsdi2.S
> AS arch/arm/boot/compressed/lib1funcs.o
> AS arch/arm/boot/compressed/ashldi3.o
> AS arch/arm/boot/compressed/bswapsdi2.o
> ERROR: "_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
> ERROR: "_test_and_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
> ERROR: "_clear_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
> ERROR: "_test_and_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
> ERROR: "_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
> ERROR: "_test_and_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
> ERROR: "_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
> ERROR: "_test_and_clear_bit" [sound/core/seq/snd-seq.ko] undefined!
> ERROR: "_test_and_set_bit" [sound/core/seq/snd-seq.ko] undefined!
> ERROR: "_set_bit" [net/bridge/bridge.ko] undefined!
> ERROR: "_clear_bit" [net/bridge/bridge.ko] undefined!
> ERROR: "_test_and_clear_bit" [net/bluetooth/hidp/hidp.ko] undefined!
> ERROR: "_set_bit" [net/bluetooth/hidp/hidp.ko] undefined!
> ERROR: "_clear_bit" [net/bluetooth/hidp/hidp.ko] undefined!
> ERROR: "_set_bit" [net/bluetooth/bnep/bnep.ko] undefined!
> ERROR: "_test_and_set_bit" [net/bluetooth/bnep/bnep.ko] undefined!
> ERROR: "_clear_bit" [net/bluetooth/bnep/bnep.ko] undefined!
> ERROR: "_test_and_clear_bit" [fs/fuse/fuse.ko] undefined!
> ERROR: "_set_bit" [fs/fuse/fuse.ko] undefined!
> ERROR: "_test_and_set_bit" [fs/fuse/fuse.ko] undefined!
> ERROR: "_clear_bit" [fs/fuse/fuse.ko] undefined!
> ERROR: "_test_and_clear_bit" [fs/cifs/cifs.ko] undefined!
> ERROR: "_set_bit" [fs/cifs/cifs.ko] undefined!
> ERROR: "_test_and_set_bit" [fs/cifs/cifs.ko] undefined!
> ERROR: "_clear_bit" [fs/cifs/cifs.ko] undefined!
> ERROR: "_test_and_clear_bit" [fs/btrfs/btrfs.ko] undefined!
> ERROR: "_set_bit" [fs/btrfs/btrfs.ko] undefined!
> ERROR: "_test_and_set_bit" [fs/btrfs/btrfs.ko] undefined!
> ERROR: "_clear_bit" [fs/btrfs/btrfs.ko] undefined!
> ERROR: "_test_and_clear_bit" [drivers/usb/storage/usb-storage.ko] undefined!
> ERROR: "_set_bit" [drivers/usb/storage/usb-storage.ko] undefined!
> ERROR: "_clear_bit" [drivers/usb/storage/usb-storage.ko] undefined!
> ERROR: "_set_bit" [drivers/usb/gadget/libcomposite.ko] undefined!
> ERROR: "_set_bit" [drivers/usb/gadget/function/usb_f_rndis.ko] undefined!
> ERROR: "_test_and_clear_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> ERROR: "_test_and_set_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> ERROR: "_clear_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> ERROR: "_set_bit" [drivers/usb/gadget/function/u_ether.ko] undefined!
> ERROR: "_test_and_clear_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> ERROR: "_set_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> ERROR: "_test_and_set_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> ERROR: "_clear_bit" [drivers/media/platform/s5p-mfc/s5p-mfc.ko] undefined!
> ERROR: "_clear_bit" [drivers/md/dm-crypt.ko] undefined!
> ERROR: "_set_bit" [drivers/md/dm-crypt.ko] undefined!
> ERROR: "_set_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined!
> ERROR: "_clear_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined!
> ERROR: "_test_and_clear_bit" [drivers/bluetooth/btusb.ko] undefined!
> ERROR: "_test_and_set_bit" [drivers/bluetooth/btusb.ko] undefined!
> ERROR: "_set_bit" [drivers/bluetooth/btusb.ko] undefined!
> ERROR: "_clear_bit" [drivers/bluetooth/btusb.ko] undefined!
> ERROR: "_set_bit" [drivers/bluetooth/btintel.ko] undefined!
> ERROR: "_set_bit" [drivers/bluetooth/btbcm.ko] undefined!
> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> make[1]: *** [__modpost] Error 1
> Makefile:1191: recipe for target 'modules' failed
> make: *** [modules] Error 2
This is the config I'm using for the build:
https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.9-debug.conf
Let me know which additional information you need.
With best wishes,
Tobias
> On Sun, Nov 20, 2016 at 03:47:34AM +0100, Tobias Jakobi wrote:
>> Hello,
>>
>> this is a resend of my initial mail, see below, to Al Viro (which sadly
>> was ignored).
>>
>> It's rc5 now, and this issue still remains. Putting some more lists on
>> the Cc now.
>>
>> Reverting the commit still works for me.
>>
>>
>> With best wishes,
>> Tobias
>>
>> ----------------
>>
>>
>> Hello Al,
>>
>> compiled a kernel on armv7 with torvalds/master today and getting some
>> errors during the modpost phase.
>>
>>> ERROR: "_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
>>> ERROR: "_test_and_set_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
>>> ERROR: "_clear_bit" [sound/usb/snd-usbmidi-lib.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
>>> ERROR: "_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
>>> ERROR: "_test_and_set_bit" [sound/usb/snd-usb-audio.ko] undefined!
>>> ERROR: "_clear_bit" [sound/usb/snd-usb-audio.ko] undefined!
>>> ERROR: "_test_and_clear_bit" [sound/core/seq/snd-seq.ko] undefined!
>> <snip>
>>
>> It seems like the commit 'arm: move exports to definitions' introduces
>> this issue.
>>
>> I quickly went over the commit and I noticed that while it removes the
>> EXPORT_SYMBOL()s for the bitops from armksyms.c, it doesn't move them
>> anywhere.
>>
>> Maybe you can take a look at this?
>>
>> With best wishes,
>> Tobias
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox