* [PATCH V2 3/5] PCI: save and restore bus on parent bus reset
From: Sinan Kaya @ 2016-10-03 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8dbad89c-2646-773a-e114-42d21ce14cc7@codeaurora.org>
On 9/29/2016 7:50 PM, Sinan Kaya wrote:
> Hi Bjorn,
>
> On 9/29/2016 5:49 PM, Bjorn Helgaas wrote:
>>> + }
>> This pattern of "unlock, do something, relock" needs some
>> justification. In general it's unsafe because the lock is protecting
>> *something*, and you have to assume that something can change as soon
>> as you unlock. Maybe you know it's safe in this situation, and if so,
>> the explanation of why it's safe is what I'm looking for.
>
> Agreed.
>
> The problem is that save and restore routines obtain the lock again and
> they fails as the lock is already held.
>
> The alternative is to change the dev_locks in save and restore to try_lock
> so that it will work if locks were previously obtained or not.
>
>>
>> Also, you're now calling pci_reset_bridge_secondary_bus() with the dev
>> unlocked, where we called it with the dev locked before. Some (but
>> worryingly, not all) of the other pci_reset_bridge_secondary_bus()
>> callers also have the dev locked. I didn't look long enough to figure
>> out if there is a strategy there or if these inconsistencies are
>> latent bugs.
>>
>
> The goal of this routine is to reset the device not the bridge and the code
> will use FLR or others if available. Therefore, it makes perfect sense to
> obtain the device lock while doing this.
>
> The code tries to reset the bus if none of the other resets work. This is
> where the problem is. It destroys the context for other devices.
>
> I can fix get rid of this unlock, do something and then lock again business
> by rewriting the locks in save and restore.
>
> Sinan
>
I looked at the code a little bit more. I missed the fact pci_parent_bus_reset
will only work if there is only PCI device on the bus and that device is the
reset requesting device.
I'll drop this patch as well as the infiniband version for the same reason.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
From: Sinan Kaya @ 2016-10-03 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB2bhMbkQrGG55Bq-yrFk_DC3Pz2tF0CRrt4ccmrzTmrzQ@mail.gmail.com>
On 10/2/2016 7:40 AM, Jonathan Liu wrote:
> This series fixes one or more network adapters in VirtualBox not
> working with Linux 32-bit x86 guest if I have 4 network adapters
> enabled. The following message no longer appears in the kernel log:
> ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
>
> Tested-by: Jonathan Liu <net147@gmail.com>
Thanks for the test. I didn't realize that VirtualBox was broken too.
So far I got some random test results in the mail list that something
is broken. I hope to hear more that we close the issue for some time
now.
The IRQ stuff got broken three times already. Hopefully, this will be
the seal.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 1/2] remoteproc: Split driver and consumer dereferencing
From: Bjorn Andersson @ 2016-10-03 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In order to be able to lock a rproc driver implementations only when
used by a client, we must differ between the dereference operation of a
client and the implementation itself.
This patch brings no functional change.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Documentation/remoteproc.txt | 6 +++---
drivers/remoteproc/da8xx_remoteproc.c | 4 ++--
drivers/remoteproc/omap_remoteproc.c | 4 ++--
drivers/remoteproc/qcom_q6v5_pil.c | 4 ++--
drivers/remoteproc/qcom_wcnss.c | 4 ++--
drivers/remoteproc/remoteproc_core.c | 21 ++++++++++++++++++---
drivers/remoteproc/st_remoteproc.c | 4 ++--
drivers/remoteproc/ste_modem_rproc.c | 4 ++--
drivers/remoteproc/wkup_m3_rproc.c | 4 ++--
include/linux/remoteproc.h | 1 +
10 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index ef0219fa4bb4..f07597482351 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -101,9 +101,9 @@ int dummy_rproc_example(struct rproc *my_rproc)
On success, the new rproc is returned, and on failure, NULL.
Note: _never_ directly deallocate @rproc, even if it was not registered
- yet. Instead, when you need to unroll rproc_alloc(), use rproc_put().
+ yet. Instead, when you need to unroll rproc_alloc(), use rproc_free().
- void rproc_put(struct rproc *rproc)
+ void rproc_free(struct rproc *rproc)
- Free an rproc handle that was allocated by rproc_alloc.
This function essentially unrolls rproc_alloc(), by decrementing the
rproc's refcount. It doesn't directly free rproc; that would happen
@@ -131,7 +131,7 @@ int dummy_rproc_example(struct rproc *my_rproc)
has completed successfully.
After rproc_del() returns, @rproc is still valid, and its
- last refcount should be decremented by calling rproc_put().
+ last refcount should be decremented by calling rproc_free().
Returns 0 on success and -EINVAL if @rproc isn't valid.
diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c
index 12823d078e1e..1afac8f31be0 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -261,7 +261,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -290,7 +290,7 @@ static int da8xx_rproc_remove(struct platform_device *pdev)
disable_irq(drproc->irq);
rproc_del(rproc);
- rproc_put(rproc);
+ rproc_free(rproc);
return 0;
}
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 01e234cb9157..fa63bf2eb885 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -215,7 +215,7 @@ static int omap_rproc_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -224,7 +224,7 @@ static int omap_rproc_remove(struct platform_device *pdev)
struct rproc *rproc = platform_get_drvdata(pdev);
rproc_del(rproc);
- rproc_put(rproc);
+ rproc_free(rproc);
return 0;
}
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c b/drivers/remoteproc/qcom_q6v5_pil.c
index 05b04573e87d..2e0caaaa766a 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -875,7 +875,7 @@ static int q6v5_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -885,7 +885,7 @@ static int q6v5_remove(struct platform_device *pdev)
struct q6v5 *qproc = platform_get_drvdata(pdev);
rproc_del(qproc->rproc);
- rproc_put(qproc->rproc);
+ rproc_free(qproc->rproc);
return 0;
}
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index 1917de7db91c..f5cedeaafba1 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -585,7 +585,7 @@ static int wcnss_probe(struct platform_device *pdev)
return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -598,7 +598,7 @@ static int wcnss_remove(struct platform_device *pdev)
qcom_smem_state_put(wcnss->state);
rproc_del(wcnss->rproc);
- rproc_put(wcnss->rproc);
+ rproc_free(wcnss->rproc);
return 0;
}
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 3da566b0d437..ede3af14b9d0 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1307,7 +1307,7 @@ static struct device_type rproc_type = {
* On success the new rproc is returned, and on failure, NULL.
*
* Note: _never_ directly deallocate @rproc, even if it was not registered
- * yet. Instead, when you need to unroll rproc_alloc(), use rproc_put().
+ * yet. Instead, when you need to unroll rproc_alloc(), use rproc_free().
*/
struct rproc *rproc_alloc(struct device *dev, const char *name,
const struct rproc_ops *ops,
@@ -1386,7 +1386,22 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
EXPORT_SYMBOL(rproc_alloc);
/**
- * rproc_put() - unroll rproc_alloc()
+ * rproc_free() - unroll rproc_alloc()
+ * @rproc: the remote processor handle
+ *
+ * This function decrements the rproc dev refcount.
+ *
+ * If no one holds any reference to rproc anymore, then its refcount would
+ * now drop to zero, and it would be freed.
+ */
+void rproc_free(struct rproc *rproc)
+{
+ put_device(&rproc->dev);
+}
+EXPORT_SYMBOL(rproc_free);
+
+/**
+ * rproc_put() - release rproc reference
* @rproc: the remote processor handle
*
* This function decrements the rproc dev refcount.
@@ -1411,7 +1426,7 @@ EXPORT_SYMBOL(rproc_put);
*
* After rproc_del() returns, @rproc isn't freed yet, because
* of the outstanding reference created by rproc_alloc. To decrement that
- * one last refcount, one still needs to call rproc_put().
+ * one last refcount, one still needs to call rproc_free().
*
* Returns 0 on success and -EINVAL if @rproc isn't valid.
*/
diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
index 6f056caa8a56..ae8963fcc8c8 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -262,7 +262,7 @@ static int st_rproc_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -277,7 +277,7 @@ static int st_rproc_remove(struct platform_device *pdev)
of_reserved_mem_device_release(&pdev->dev);
- rproc_put(rproc);
+ rproc_free(rproc);
return 0;
}
diff --git a/drivers/remoteproc/ste_modem_rproc.c b/drivers/remoteproc/ste_modem_rproc.c
index 53dc17bdd54e..03d69a9a3c5b 100644
--- a/drivers/remoteproc/ste_modem_rproc.c
+++ b/drivers/remoteproc/ste_modem_rproc.c
@@ -257,7 +257,7 @@ static int sproc_drv_remove(struct platform_device *pdev)
rproc_del(sproc->rproc);
dma_free_coherent(sproc->rproc->dev.parent, SPROC_FW_SIZE,
sproc->fw_addr, sproc->fw_dma_addr);
- rproc_put(sproc->rproc);
+ rproc_free(sproc->rproc);
mdev->drv_data = NULL;
@@ -325,7 +325,7 @@ static int sproc_probe(struct platform_device *pdev)
free_rproc:
/* Reset device data upon error */
mdev->drv_data = NULL;
- rproc_put(rproc);
+ rproc_free(rproc);
return err;
}
diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
index 3811cb522af3..18175d0331fd 100644
--- a/drivers/remoteproc/wkup_m3_rproc.c
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -208,7 +208,7 @@ static int wkup_m3_rproc_probe(struct platform_device *pdev)
return 0;
err_put_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
err:
pm_runtime_put_noidle(dev);
pm_runtime_disable(dev);
@@ -220,7 +220,7 @@ static int wkup_m3_rproc_remove(struct platform_device *pdev)
struct rproc *rproc = platform_get_drvdata(pdev);
rproc_del(rproc);
- rproc_put(rproc);
+ rproc_free(rproc);
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index c321eab5054e..930023b7c825 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -493,6 +493,7 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
void rproc_put(struct rproc *rproc);
int rproc_add(struct rproc *rproc);
int rproc_del(struct rproc *rproc);
+void rproc_free(struct rproc *rproc);
int rproc_boot(struct rproc *rproc);
void rproc_shutdown(struct rproc *rproc);
--
2.5.0
^ permalink raw reply related
* [GIT PULL 1/3] ARM: soc: exynos: Drivers for v4.9
From: Olof Johansson @ 2016-10-03 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919155302.GA4447@kozik-book>
On Mon, Sep 19, 2016 at 8:53 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Sep 19, 2016 at 05:02:40PM +0200, Arnd Bergmann wrote:
>> On Sunday, September 18, 2016 6:39:46 PM CEST Krzysztof Kozlowski wrote:
>> > Samsung drivers/soc update for v4.9:
>> > 1. Allow compile testing of exynos-mct clocksource driver on ARM64.
>> > 2. Document Exynos5433 PMU compatible (already used by clkout driver and more
>> > will be coming soon).
>>
>> Pulled into next/drivers, thanks
>>
>> Just for my understanding: why do we need the exynos-mct driver on ARM64
>> but not the delay-timer portion of it?
>
> I think we want all of it but Doug's optimization 3252a646aa2c
> ("clocksource: exynos_mct: Only use 32-bits where possible") is not
> ARM64 friendly. One way of dealing with it would be to prepare two
> versions of exynos4_read_current_timer(). One reading only lower 32-bit
> value for ARMv7 and second (slow) reading lower and upper for ARMv8.
>
>>
>> Is there an advantage in using MCT over the architected timer on these
>> chips? If so, should we also have a way to use it as the delay timer?
>
> No, there is no real advantage... except that the SoC has some
> interesting "characteristics"... The timers are tightly coupled. Very
> tightly. I spent a lot of time and failed to boot my ARMv8 board without
> some MCT magic.
What kind of magic is that? I can understand that needing the MCT for
some system-level timer functionality might be true (wakeups, etc),
but for system timesource avoiding the MMIO timer and using the arch
ones is a substantial performance improvement for gettimeofday() and
friends.
There was extensive discussion last year over using arch timers on
5420/5422, and it fizzled out with vague comments about something not
working right between A15/A7 on b.L. hardware. I'm presuming whatever
implementation details of that SoC has since been fixed on later chips
(including v8). Any chance you can confirm? It'd be very nice to leave
MCT behind on v8 as a system time source.
-Olof
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Jon Masters @ 2016-10-02 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5869118.UilSPY9Sai@wuerfel>
On 09/14/2016 02:32 PM, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 10:50:44 PM CEST zhichang.yuan wrote:
>> And there are probably multiple child devices under LPC, the global arm64_extio_ops only can cover one PIO range. It is fortunate only ipmi driver can not support I/O
>> operation registering, serial driver has serial_in/serial_out to
>> be registered. So, only the PIO range for ipmi device is stored
>> in arm64_extio_ops and the indirect-IO
>> works well for ipmi device.
>
> You should not do that in the serial driver, please just use the
> normal 8250 driver that works fine once you handle the entire
> port range.
Just for the record, Arnd has the right idea. There is only one type of
UART permitted by SBSA (PL011). We carved out an exception for a design
that was already in flight and allowed it to be 16550. That other design
was then corrected in future generations to be PL011 as we required it
to be. Then there's the Hip06. I've given feedback elsewhere about the
need for there to be (at most) two types of UART in the wild. This "LPC"
stuff needs cleaning up (feedback given elsewhere already on that), but
we won't be adding a third serial driver into the mix in order to make
it work. There will be standard ARM servers. There will not be the
kinda-sorta-standard. Thanks.
Jon.
^ permalink raw reply
* [PATCH] bus: qcom-ebi2: depend on HAS_IOMEM
From: Linus Walleij @ 2016-10-02 21:53 UTC (permalink / raw)
To: linux-arm-kernel
After being asked to not depend on ARCH_QCOM* or similar,
unsurprisingly compilation fails on UM as it has no I/O
memory:
drivers/built-in.o: In function `qcom_ebi2_probe':
>> drivers/bus/qcom-ebi2.c:333: undefined reference to
`devm_ioremap_resource'
Fix this by letting the Kconfig atleast depend on HAS_IOMEM.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: linux-arm-msm at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC maintainers: please apply this directly on the offending
branch, or line it up for v4.9 fixes.
---
drivers/bus/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 5a2d47c71525..7010dcac9328 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -110,6 +110,7 @@ config OMAP_OCP2SCP
config QCOM_EBI2
bool "Qualcomm External Bus Interface 2 (EBI2)"
+ depends on HAS_IOMEM
help
Say y here to enable support for the Qualcomm External Bus
Interface 2, which can be used to connect things like NAND Flash,
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Marek Vasut @ 2016-10-02 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DwZYawBOiXWn0FMy9SgO4+-C=y-CFCQBPSO_mDYk-a6g@mail.gmail.com>
On 10/02/2016 07:43 PM, Fabio Estevam wrote:
> Hi Marek,
Hi!
> On Sun, Oct 2, 2016 at 1:44 PM, Marek Vasut <marex@denx.de> wrote:
>> The LCDIF interrupt should be triggered by the rising edge of the
>> IRQ line because we only want the interrupt to trigger once per each
>> frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
>> by software, so the previous behavior before this patch, where the
>> interrupt was triggered by level-high status of the IRQ line, caused
>> the interrupt to fire again immediatelly after it was handled, which
>> caused the system to lock up due to the high rate of interrupts.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Lucas Stach <l.stach@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> ---
>> arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
>> index 1a473e8..9526c38 100644
>> --- a/arch/arm/boot/dts/imx6sx.dtsi
>> +++ b/arch/arm/boot/dts/imx6sx.dtsi
>> @@ -1143,7 +1143,7 @@
>> lcdif1: lcdif at 02220000 {
>> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
>> reg = <0x02220000 0x4000>;
>> - interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
>
> What about mx6ul and mx6sl.dtsi? Shouldn't they be also updated?
Probably, but I don't have the hardware to test MXSFB DRM/KMS driver on
those. I can mail you the necessary patches if you want to try it out,
the latest version is not in the ML yet as there is some DRM
infrastructure work going on.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Fabio Estevam @ 2016-10-02 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161002164435.5812-1-marex@denx.de>
Hi Marek,
On Sun, Oct 2, 2016 at 1:44 PM, Marek Vasut <marex@denx.de> wrote:
> The LCDIF interrupt should be triggered by the rising edge of the
> IRQ line because we only want the interrupt to trigger once per each
> frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
> by software, so the previous behavior before this patch, where the
> interrupt was triggered by level-high status of the IRQ line, caused
> the interrupt to fire again immediatelly after it was handled, which
> caused the system to lock up due to the high rate of interrupts.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> ---
> arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 1a473e8..9526c38 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -1143,7 +1143,7 @@
> lcdif1: lcdif at 02220000 {
> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
> reg = <0x02220000 0x4000>;
> - interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
What about mx6ul and mx6sl.dtsi? Shouldn't they be also updated?
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Marek Vasut @ 2016-10-02 16:44 UTC (permalink / raw)
To: linux-arm-kernel
The LCDIF interrupt should be triggered by the rising edge of the
IRQ line because we only want the interrupt to trigger once per each
frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
by software, so the previous behavior before this patch, where the
interrupt was triggered by level-high status of the IRQ line, caused
the interrupt to fire again immediatelly after it was handled, which
caused the system to lock up due to the high rate of interrupts.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 1a473e8..9526c38 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -1143,7 +1143,7 @@
lcdif1: lcdif at 02220000 {
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
reg = <0x02220000 0x4000>;
- interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
@@ -1154,7 +1154,7 @@
lcdif2: lcdif at 02224000 {
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
reg = <0x02224000 0x4000>;
- interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>;
clocks = <&clks IMX6SX_CLK_LCDIF2_PIX>,
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
--
2.9.3
^ permalink raw reply related
* [PATCH] crypto: arm64/sha256 - add support for SHA256 using NEON instructions
From: Herbert Xu @ 2016-10-02 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_M+FcuDSaGsJYjD96=Q1iXyFDD3KWy=4vUbeLWRgrHJw@mail.gmail.com>
On Sat, Oct 01, 2016 at 07:58:56PM -0700, Ard Biesheuvel wrote:
>
> Please disregard this patch for now. I will follow up with a more
> elaborate series for SHA256 on arm64
Thanks for the heads up.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: sunxi-ss: mark sun4i_hash() static
From: Herbert Xu @ 2016-10-02 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474691326-15541-1-git-send-email-baoyou.xie@linaro.org>
On Sat, Sep 24, 2016 at 12:28:46PM +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/crypto/sunxi-ss/sun4i-ss-hash.c:168:5: warning: no previous prototype for 'sun4i_hash' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
This patch has already been applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts
From: Noralf Trønnes @ 2016-10-02 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1708178720.178936.b155d019-5320-4754-bbe2-4afc1ae71cd6.open-xchange@email.1und1.de>
Den 29.09.2016 07:37, skrev Stefan Wahren:
>> Noralf Tr?nnes <noralf@tronnes.org> hat am 29. September 2016 um 00:22
>> geschrieben:
>>
>>
>>
>> Den 29.09.2016 00:00, skrev Eric Anholt:
>>> Noralf Tr?nnes <noralf@tronnes.org> writes:
>>>
>>>> If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0),
>>>> the driver has no way to fill/drain the FIFO to stop the interrupts.
>>>> In this case the controller has to be disabled and the transfer
>>>> completed to avoid hang.
>>>>
>>>> (CLKT | ERR) and DONE interrupts are completed in their own paths, and
>>>> the controller is disabled in the transfer function after completion.
>>>> Unite the code paths and do disabling inside the interrupt routine.
>>>>
>>>> Clear interrupt status bits in the united completion path instead of
>>>> trying to do it on every interrupt which isn't necessary.
>>>> Only CLKT, ERR and DONE can be cleared that way.
>>>>
>>>> Add the status value to the error value in case of TXW/RXR errors to
>>>> distinguish them from the other S_LEN error.
>>> I was surprised that not writing the TXW/RXR bits on handling their
>>> interrupts was OK, given that we were doing so before, but it's a level
>>> interrupt and those bits are basically ignored on write.
>>>
>>> This patch and 3, 4, and 6 are:
>>>
>>> Reviewed-by: Eric Anholt <eric@anholt.net>
>>>
>>> Patch 5 is:
>>>
>>> Acked-by: Eric Anholt <eric@anholt.net>
>>>
>>> Note for future debug: The I2C_C_CLEAR on errors will take some time to
>>> resolve -- if you were in non-idle state and I2C_C_READ, it sets an
>>> abort_rx flag and runs through the state machine to send a NACK and a
>>> STOP, I think. Since we're setting CLEAR without I2CEN, that NACK will
>>> be hanging around queued up for next time we start the engine.
>> Maybe you're able to explain the issues I had with reset:
>> https://github.com/raspberrypi/linux/issues/1653
>>
>> Should we put your note into the commit message?
>> It will most likely be lost if it just stays in this email.
> I prefer to have this kind of information as a code comment.
Eric, does this look good to you as a code comment:
/*
* Note about I2C_C_CLEAR on error:
* The I2C_C_CLEAR on errors will take some time to resolve -- if you
were in
* non-idle state and I2C_C_READ, it sets an abort_rx flag and runs through
* the state machine to send a NACK and a STOP. Since we're setting CLEAR
* without I2CEN, that NACK will be hanging around queued up for next time
* we start the engine.
*/
If it is, I'll resend the series with this change and add all the ack's
and r-b's.
Noralf.
^ permalink raw reply
* [3/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Jonathan Liu @ 2016-10-02 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-3-git-send-email-okaya@codeaurora.org>
On 2 October 2016 at 04:46, Sinan Kaya <okaya@codeaurora.org> wrote:
> This reverts commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize
> function"). SCI penalty API was replaced by the runtime penalty calculation
> based on the value of acpi_gbl_FADT.sci_interrupt.
>
> acpi_gbl_FADT.sci_interrupt type does not get updated at the right time
> for some platforms and results in incorrect penalty assignment for PCI
> IRQs as irq_get_trigger_type returns the wrong type.
>
> Link: http://www.spinics.net/lists/linux-pci/msg54599.html
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 34 ++++++++++++++--------------------
> include/linux/acpi.h | 1 +
> 3 files changed, 16 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
> polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>
> mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> + acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>
> /*
> * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 06c2a11..6a2af19 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -495,27 +495,10 @@ static int acpi_irq_pci_sharing_penalty(int irq)
>
> static int acpi_irq_get_penalty(int irq)
> {
> - int penalty = 0;
> -
> - /*
> - * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> - * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> - * use for PCI IRQs.
> - */
> - if (irq == acpi_gbl_FADT.sci_interrupt) {
> - u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> - if (type != IRQ_TYPE_LEVEL_LOW)
> - penalty += PIRQ_PENALTY_ISA_ALWAYS;
> - else
> - penalty += PIRQ_PENALTY_PCI_USING;
> - }
> -
> - if (irq < ACPI_MAX_ISA_IRQS)
> - return penalty + acpi_irq_penalty[irq];
> + if (irq < ACPI_MAX_IRQS)
> + return acpi_irq_penalty[irq];
>
> - penalty += acpi_irq_pci_sharing_penalty(irq);
> - return penalty;
> + return acpi_irq_pci_sharing_penalty(irq);
> }
>
> int __init acpi_irq_penalty_init(void)
> @@ -886,6 +869,17 @@ bool acpi_isa_irq_available(int irq)
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> + if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty)) {
> + if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
> + polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
> + acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
> + else
> + acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
> + }
> +}
> +
> /*
> * Over-ride default table to reserve additional IRQs for use by ISA
> * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 4d8452c..85ac7d5 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -318,6 +318,7 @@ struct pci_dev;
> int acpi_pci_irq_enable (struct pci_dev *dev);
> void acpi_penalize_isa_irq(int irq, int active);
> bool acpi_isa_irq_available(int irq);
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
> void acpi_pci_irq_disable (struct pci_dev *dev);
>
> extern int ec_read(u8 addr, u8 *val);
This series fixes one or more network adapters in VirtualBox not
working with Linux 32-bit x86 guest if I have 4 network adapters
enabled. The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [2/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Jonathan Liu @ 2016-10-02 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-2-git-send-email-okaya@codeaurora.org>
On 2 October 2016 at 04:46, Sinan Kaya <okaya@codeaurora.org> wrote:
> The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed PCI_USING penalty from
> acpi_pci_link_allocate function as there is no longer a fixed size penalty
> array for both PCI and IRQ interrupts.
>
> We need to add the PCI_USING penalty for ISA interrupts too if the link is
> in use and matches our ISA IRQ number.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index f3792f4..06c2a11 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -620,6 +620,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link)
> acpi_device_bid(link->device));
> return -ENODEV;
> } else {
> + if (link->irq.active < ACPI_MAX_IRQS)
> + acpi_irq_penalty[link->irq.active] +=
> + PIRQ_PENALTY_PCI_USING;
> +
> printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
> acpi_device_name(link->device),
> acpi_device_bid(link->device), link->irq.active);
This series fixes one or more network adapters in VirtualBox not
working with Linux 32-bit x86 guest if I have 4 network adapters
enabled. The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
From: Jonathan Liu @ 2016-10-02 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-1-git-send-email-okaya@codeaurora.org>
On 2 October 2016 at 04:46, Sinan Kaya <okaya@codeaurora.org> wrote:
> This reverts commit 5c5087a55390 ("ACPI,PCI,IRQ: reduce static IRQ array
> size to 16").
>
> The code maintains a fixed size array for IRQ penalties. The array
> gets updated by external calls such as acpi_penalize_sci_irq,
> acpi_penalize_isa_irq to reflect the actual interrupt usage of the
> system. Since the IRQ distribution is platform specific, this is
> not known ahead of time. The IRQs get updated based on the SCI
> interrupt number BIOS has chosen or the ISA IRQs that were assigned
> to existing peripherals.
>
> By the time ACPI gets initialized, this code tries to determine an
> IRQ number based on penalty values in this array. It will try to locate
> the IRQ with the least penalty assignment so that interrupt sharing is
> avoided if possible.
>
> A couple of notes about the external APIs:
> 1. These API can be called before the ACPI is started. Therefore, one
> cannot assume that the PCI link objects are initialized for calculating
> penalties.
> 2. The polarity and trigger information passed via the
> acpi_penalize_sci_irq from the BIOS may not match what the IRQ subsystem
> is reporting as the call might have been placed before the IRQ is
> registered by the interrupt subsystem.
>
> The previous change was in the direction to remove these external API and
> try to calculate the penalties at runtime for the ISA path as well. This
> didn't work out well with the existing platforms.
>
> Restoring the old behavior for IRQ < 256 and the new behavior will remain
> effective for IRQ >= 256.
>
> Link: http://www.spinics.net/lists/linux-pci/msg54599.html
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 35 ++++++++++++++++++-----------------
> 1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..f3792f4 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -438,6 +438,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
> * enabled system.
> */
>
> +#define ACPI_MAX_IRQS 256
> #define ACPI_MAX_ISA_IRQS 16
>
> #define PIRQ_PENALTY_PCI_POSSIBLE (16*16)
> @@ -446,7 +447,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
> #define PIRQ_PENALTY_ISA_USED (16*16*16*16*16)
> #define PIRQ_PENALTY_ISA_ALWAYS (16*16*16*16*16*16)
>
> -static int acpi_isa_irq_penalty[ACPI_MAX_ISA_IRQS] = {
> +static int acpi_irq_penalty[ACPI_MAX_IRQS] = {
> PIRQ_PENALTY_ISA_ALWAYS, /* IRQ0 timer */
> PIRQ_PENALTY_ISA_ALWAYS, /* IRQ1 keyboard */
> PIRQ_PENALTY_ISA_ALWAYS, /* IRQ2 cascade */
> @@ -511,7 +512,7 @@ static int acpi_irq_get_penalty(int irq)
> }
>
> if (irq < ACPI_MAX_ISA_IRQS)
> - return penalty + acpi_isa_irq_penalty[irq];
> + return penalty + acpi_irq_penalty[irq];
>
> penalty += acpi_irq_pci_sharing_penalty(irq);
> return penalty;
> @@ -538,14 +539,14 @@ int __init acpi_irq_penalty_init(void)
>
> for (i = 0; i < link->irq.possible_count; i++) {
> if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
> - acpi_isa_irq_penalty[link->irq.
> + acpi_irq_penalty[link->irq.
> possible[i]] +=
> penalty;
> }
>
> } else if (link->irq.active &&
> - (link->irq.active < ACPI_MAX_ISA_IRQS)) {
> - acpi_isa_irq_penalty[link->irq.active] +=
> + (link->irq.active < ACPI_MAX_IRQS)) {
> + acpi_irq_penalty[link->irq.active] +=
> PIRQ_PENALTY_PCI_POSSIBLE;
> }
> }
> @@ -828,7 +829,7 @@ static void acpi_pci_link_remove(struct acpi_device *device)
> }
>
> /*
> - * modify acpi_isa_irq_penalty[] from cmdline
> + * modify acpi_irq_penalty[] from cmdline
> */
> static int __init acpi_irq_penalty_update(char *str, int used)
> {
> @@ -837,24 +838,24 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> for (i = 0; i < 16; i++) {
> int retval;
> int irq;
> - int new_penalty;
>
> retval = get_option(&str, &irq);
>
> if (!retval)
> break; /* no number found */
>
> - /* see if this is a ISA IRQ */
> - if ((irq < 0) || (irq >= ACPI_MAX_ISA_IRQS))
> + if (irq < 0)
> + continue;
> +
> + if (irq >= ARRAY_SIZE(acpi_irq_penalty))
> continue;
>
> if (used)
> - new_penalty = acpi_irq_get_penalty(irq) +
> - PIRQ_PENALTY_ISA_USED;
> + acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> + PIRQ_PENALTY_ISA_USED;
> else
> - new_penalty = 0;
> + acpi_irq_penalty[irq] = 0;
>
> - acpi_isa_irq_penalty[irq] = new_penalty;
> if (retval != 2) /* no next number */
> break;
> }
> @@ -870,14 +871,14 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> */
> void acpi_penalize_isa_irq(int irq, int active)
> {
> - if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
> - acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> - (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> + if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty))
> + acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> + (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> }
>
> bool acpi_isa_irq_available(int irq)
> {
> - return irq >= 0 && (irq >= ARRAY_SIZE(acpi_isa_irq_penalty) ||
> + return irq >= 0 && (irq >= ARRAY_SIZE(acpi_irq_penalty) ||
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
This series fixes one or more network adapters in VirtualBox not
working with Linux 32-bit x86 guest if I have 4 network adapters
enabled. The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [RFC 05/11] iommu/dma: iommu_dma_(un)map_mixed
From: Christoffer Dall @ 2016-10-02 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b1b30b3-4199-9e18-362c-b8bc9d45277d@arm.com>
On Fri, Sep 30, 2016 at 02:24:40PM +0100, Robin Murphy wrote:
> Hi Eric,
>
> On 27/09/16 21:48, Eric Auger wrote:
> > iommu_dma_map_mixed and iommu_dma_unmap_mixed operate on
> > IOMMU_DOMAIN_MIXED typed domains. On top of standard iommu_map/unmap
> > they reserve the IOVA window to prevent the iova allocator to
> > allocate in those areas.
> >
> > Signed-off-by: Eric Auger <eric.auger@redhat.com>
> > ---
> > drivers/iommu/dma-iommu.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/dma-iommu.h | 18 ++++++++++++++++++
> > 2 files changed, 66 insertions(+)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 04bbc85..db21143 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -759,3 +759,51 @@ int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
> > return 0;
> > }
> > EXPORT_SYMBOL(iommu_get_dma_msi_region_cookie);
> > +
> > +int iommu_dma_map_mixed(struct iommu_domain *domain, unsigned long iova,
> > + phys_addr_t paddr, size_t size, int prot)
> > +{
> > + struct iova_domain *iovad;
> > + unsigned long lo, hi;
> > + int ret;
> > +
> > + if (domain->type != IOMMU_DOMAIN_MIXED)
> > + return -EINVAL;
> > +
> > + if (!domain->iova_cookie)
> > + return -EINVAL;
> > +
> > + iovad = cookie_iovad(domain);
> > +
> > + lo = iova_pfn(iovad, iova);
> > + hi = iova_pfn(iovad, iova + size - 1);
> > + reserve_iova(iovad, lo, hi);
>
> This can't work reliably - reserve_iova() will (for good reason) merge
> any adjacent or overlapping entries, so any unmap is liable to free more
> IOVA space than actually gets unmapped, and things will get subtly out
> of sync and go wrong later.
>
> The more general issue with this whole approach, though, is that it
> effectively rules out userspace doing guest memory hotplug or similar,
> and I'm not we want to paint ourselves into that corner. Basically, as
> soon as a device is attached to a guest, the entirety of the unallocated
> IPA space becomes reserved, and userspace can never add anything further
> to it, because any given address *might* be in use for an MSI mapping.
Ah, we didn't think of that when discussing this design at KVM Forum,
because the idea was that the IOVA allocator was in charge of that
resource, and the IOVA was a separate concept from the IPA space.
I think what tripped us up, is that while the above is true for the MSI
configuration where we trap the bar and do the allocation at VFIO init
time, the guest device driver can program DMA to any address without
trapping, and therefore there's an inherent relationship between the
IOVA and the IPA space. Is that right?
>
> I think it still makes most sense to stick with the original approach of
> cooperating with userspace to reserve a bounded area - it's just that we
> can then let automatic mapping take care of itself within that area.
I was thinking that it's also possible to do it the other way around: To
let userspace say wherever memory may be hotplugged and do the
allocation within the remaining area, but I suppose that's pretty much
the same thing, and it should just depend on what's easiest to implement
and what userspace can best predict.
>
> Speaking of which, I've realised the same fundamental reservation
> problem already applies to PCI without ACS, regardless of MSIs. I just
> tried on my Juno with guest memory placed at 0x4000000000, (i.e.
> matching the host PA of the 64-bit PCI window), and sure enough when the
> guest kicks off some DMA on the passed-through NIC, the root complex
> interprets the guest IPA as (unsupported) peer-to-peer DMA to a BAR
> claimed by the video card, and it fails. I guess this doesn't get hit in
> practice on x86 because the guest memory map is unlikely to be much
> different from the host's.
>
> It seems like we basically need a general way of communicating fixed and
> movable host reservations to userspace :/
>
Yes, this makes sense to me. Do we have any existing way of
discovering this from userspace or can we think of something?
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Remove I2C3
From: Andrew Lunn @ 2016-10-02 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475371719-28736-1-git-send-email-andrew.smirnov@gmail.com>
On Sat, Oct 01, 2016 at 06:28:39PM -0700, Andrey Smirnov wrote:
> I2C3 bus was only brought out in revision A1 of the board and revision
> B1 only brings out 3 I2C busses (I2C0, I2C1 and I2C2).
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] crypto: arm64/sha256 - add support for SHA256 using NEON instructions
From: Ard Biesheuvel @ 2016-10-02 2:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8J9rHA2opKqHQr74GU6xxwMpaJak1mNpRVpOf=+BZ81w@mail.gmail.com>
On 29 September 2016 at 16:37, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 29 September 2016 at 15:51, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> This is a port to arm64 of the NEON implementation of SHA256 that lives
>> under arch/arm/crypto.
>>
>> Due to the fact that the AArch64 assembler dialect deviates from the
>> 32-bit ARM one in ways that makes sharing code problematic, and given
>> that this version only uses the NEON version whereas the original
>> implementation supports plain ALU assembler, NEON and Crypto Extensions,
>> this code is built from a version sha256-armv4.pl that has been
>> transliterated to the AArch64 NEON dialect.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> arch/arm64/crypto/Kconfig | 5 +
>> arch/arm64/crypto/Makefile | 11 +
>> arch/arm64/crypto/sha256-armv4.pl | 413 +++++++++
>> arch/arm64/crypto/sha256-core.S_shipped | 883 ++++++++++++++++++++
>> arch/arm64/crypto/sha256_neon_glue.c | 103 +++
>> 5 files changed, 1415 insertions(+)
>>
>> diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
>> index 2cf32e9887e1..d32371198474 100644
>> --- a/arch/arm64/crypto/Kconfig
>> +++ b/arch/arm64/crypto/Kconfig
>> @@ -18,6 +18,11 @@ config CRYPTO_SHA2_ARM64_CE
>> depends on ARM64 && KERNEL_MODE_NEON
>> select CRYPTO_HASH
>>
>> +config CRYPTO_SHA2_ARM64_NEON
>> + tristate "SHA-224/SHA-256 digest algorithm (ARMv8 NEON)"
>> + depends on ARM64 && KERNEL_MODE_NEON
>> + select CRYPTO_HASH
>> +
>> config CRYPTO_GHASH_ARM64_CE
>> tristate "GHASH (for GCM chaining mode) using ARMv8 Crypto Extensions"
>> depends on ARM64 && KERNEL_MODE_NEON
>> diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
>> index abb79b3cfcfe..5156ebee0488 100644
>> --- a/arch/arm64/crypto/Makefile
>> +++ b/arch/arm64/crypto/Makefile
>> @@ -29,6 +29,9 @@ aes-ce-blk-y := aes-glue-ce.o aes-ce.o
>> obj-$(CONFIG_CRYPTO_AES_ARM64_NEON_BLK) += aes-neon-blk.o
>> aes-neon-blk-y := aes-glue-neon.o aes-neon.o
>>
>> +obj-$(CONFIG_CRYPTO_SHA2_ARM64_NEON) := sha256-neon.o
>
> There is a typo here that I only spotted just now: this should be += not :=
>
> Herbert, if you're picking this up, could you please fix this at merge
> time? Or do you need me to resend?
>
Please disregard this patch for now. I will follow up with a more
elaborate series for SHA256 on arm64
^ permalink raw reply
* [PATCH] ARM: dts: vfxxx: Add node corresponding to OCOTP
From: Andrey Smirnov @ 2016-10-02 1:30 UTC (permalink / raw)
To: linux-arm-kernel
Add node corresponding to OCOTP IP block.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2c13ec6..75850c0 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,12 @@
status = "disabled";
};
+ ocotp: ocotp at 400a5000 {
+ compatible = "fsl,vf610-ocotp";
+ reg = <0x400a5000 0x1000>;
+ clocks = <&clks VF610_CLK_OCOTP>;
+ };
+
snvs0: snvs at 400a7000 {
compatible = "fsl,sec-v4.0-mon", "syscon", "simple-mfd";
reg = <0x400a7000 0x2000>;
--
2.5.5
^ permalink raw reply related
* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Remove I2C3
From: Andrey Smirnov @ 2016-10-02 1:28 UTC (permalink / raw)
To: linux-arm-kernel
I2C3 bus was only brought out in revision A1 of the board and revision
B1 only brings out 3 I2C busses (I2C0, I2C1 and I2C2).
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 5c1fcab..fa19cfd 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -499,13 +499,6 @@
};
};
-&i2c3 {
- clock-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c3>;
- status = "okay";
-};
-
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart0>;
@@ -663,13 +656,6 @@
>;
};
- pinctrl_i2c3: i2c3grp {
- fsl,pins = <
- VF610_PAD_PTA30__I2C3_SCL 0x37ff
- VF610_PAD_PTA31__I2C3_SDA 0x37ff
- >;
- };
-
pinctrl_leds_debug: pinctrl-leds-debug {
fsl,pins = <
VF610_PAD_PTD20__GPIO_74 0x31c2
--
2.5.5
^ permalink raw reply related
* [PATCH 00/15] improve function-level documentation
From: Julia Lawall @ 2016-10-01 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475353194.1996.3.camel@perches.com>
On Sat, 1 Oct 2016, Joe Perches wrote:
> On Sat, 2016-10-01 at 21:46 +0200, Julia Lawall wrote:
> > These patches fix cases where the documentation above a function definition
> > is not consistent with the function header. Issues are detected using the
> > semantic patch below (http://coccinelle.lip6.fr/). Basically, the semantic
> > patch parses a file to find comments, then matches each function header,
> > and checks that the name and parameter list in the function header are
> > compatible with the comment that preceeds it most closely.
>
> Hi Julia.
>
> Would it be possible for a semantic patch to scan for
> function definitions where the types do not have
> identifiers and update the definitions to match the
> declarations?
>
> For instance, given:
>
> <some.h>
> int foo(int);
>
> <some.c>
> int foo(int bar)
> {
> return baz;
> }
>
> Could coccinelle output:
>
> diff a/some.h b/some.h
> []
> -int foo(int);
> +int foo(int bar);
The following seems to work:
@r@
identifier f;
position p;
type T, t;
parameter list[n] ps;
@@
T f at p(ps,t,...);
@s@
identifier r.f,x;
type r.T, r.t;
parameter list[r.n] ps;
@@
T f(ps,t x,...) { ... }
@@
identifier r.f, s.x;
position r.p;
type r.T, r.t;
parameter list[r.n] ps;
@@
T f at p(ps,t
+ x
,...);
After letting it run for a few minutes without making any effort to
include .h files, I get over 2700 changed lines.
julia
^ permalink raw reply
* [PATCH 00/15] improve function-level documentation
From: Joe Perches @ 2016-10-01 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475351192-27079-1-git-send-email-Julia.Lawall@lip6.fr>
On Sat, 2016-10-01 at 21:46 +0200, Julia Lawall wrote:
> These patches fix cases where the documentation above a function definition
> is not consistent with the function header. Issues are detected using the
> semantic patch below (http://coccinelle.lip6.fr/). Basically, the semantic
> patch parses a file to find comments, then matches each function header,
> and checks that the name and parameter list in the function header are
> compatible with the comment that preceeds it most closely.
Hi Julia.
Would it be possible for a semantic patch to scan for
function definitions where the types do not have
identifiers and update the definitions to match the
declarations?
For instance, given:
<some.h>
int foo(int);
<some.c>
int foo(int bar)
{
return baz;
}
Could coccinelle output:
diff a/some.h b/some.h
[]
-int foo(int);
+int foo(int bar);
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066
From: Paweł Jarosz @ 2016-10-01 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6962779.A926KxJite@phil>
Hi,
main symptom is complete system freeze.
With CONFIG_MEMTEST enabled and with passed "memtest" to the kernel all
tests run ok.
But when i run command for example "memtester 800M" or simple "apt
update" freeze happening.
And when i reserve this region in dts, board is stable again.
Thanks,
Pawel
W dniu 01.10.2016 o 21:18, Heiko Stuebner pisze:
> Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
>> Hi,
>>
>> On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?=
> wrote:
>>> For some reason accessing memory region above 0xfe000000 freezes
>>> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
>>> solved same way.
>>>
>>> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
>>> ---
>>>
>>> arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/rk3066a.dtsi
>>> b/arch/arm/boot/dts/rk3066a.dtsi index 0d0dae3..44c8956 100644
>>> --- a/arch/arm/boot/dts/rk3066a.dtsi
>>> +++ b/arch/arm/boot/dts/rk3066a.dtsi
>>> @@ -93,6 +93,19 @@
>>>
>>> };
>>>
>>> };
>>>
>>> + reserved-memory {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> + /*
>>> + * The rk3066 cannot use the memory area above 0x9F000000
>>> + * for some unknown reason.
>>> + */
>>> + unusable at 9F000000 {
>>> + reg = <0x9F000000 0x1000000>;
>>> + };
>> I don't think this is a sane workaround, but it is at best difficult to
>> tell, given there's no reason given for why this memory is unusable.
>>
>> For instance, if bus accesses to this address hang, then this patch only
>> makes the hand less likely, since the kernel will still map the region (and
>> therefore the CPU can perform speculative accesses).
>>
>> Are issues with this memory consistently seen in practice?
>>
>> Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to determine
>> if the memory is returning erroneous values?
> just for the sake of completeness, on the rk3288 the issue was the dma not
> being able to access the specific memory region (interestingly also the last
> 16MB but of the 4GB area supported on the rk3288). So memory itself was ok,
> just dma access to it failed.
>
> We didn't find any other sane solution to limit the dma access in a general way
> at the time, so opted for just blocking the memory region (as it was similarly
> only
>
> In the patch above, the newly blocked area is in the middle of the two 1gb
> memory areas (0x60000000-0xa0000000-1, 0xa0000000-0xe0000000-1).
>
> Pavel, apart from Mark's CONFIG_MEMTEST request above could you also specifiy
> what type of error you see please?
>
>
> Thanks
> Heiko
^ permalink raw reply
* [PATCH 07/15] clk: sunxi: mod0: improve function-level documentation
From: Julia Lawall @ 2016-10-01 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475351192-27079-1-git-send-email-Julia.Lawall@lip6.fr>
Use the actual function name in the function documentation.
Issue detected using Coccinelle (http://coccinelle.lip6.fr/)
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/clk/sunxi/clk-mod0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi/clk-mod0.c b/drivers/clk/sunxi/clk-mod0.c
index e54266c..4417ae1 100644
--- a/drivers/clk/sunxi/clk-mod0.c
+++ b/drivers/clk/sunxi/clk-mod0.c
@@ -24,7 +24,7 @@
#include "clk-factors.h"
/**
- * sun4i_get_mod0_factors() - calculates m, n factors for MOD0-style clocks
+ * sun4i_a10_get_mod0_factors() - calculates m, n factors for MOD0-style clocks
* MOD0 rate is calculated as follows
* rate = (parent_rate >> p) / (m + 1);
*/
^ permalink raw reply related
* [PATCH 00/15] improve function-level documentation
From: Julia Lawall @ 2016-10-01 19:46 UTC (permalink / raw)
To: linux-arm-kernel
These patches fix cases where the documentation above a function definition
is not consistent with the function header. Issues are detected using the
semantic patch below (http://coccinelle.lip6.fr/). Basically, the semantic
patch parses a file to find comments, then matches each function header,
and checks that the name and parameter list in the function header are
compatible with the comment that preceeds it most closely.
// <smpl>
@initialize:ocaml@
@@
let tbl = ref []
let fnstart = ref []
let success = Hashtbl.create 101
let thefile = ref ""
let parsed = ref []
let nea = ref []
let parse file =
thefile := List.nth (Str.split (Str.regexp "linux-next/") file) 1;
let i = open_in file in
let startline = ref 0 in
let fn = ref "" in
let ids = ref [] in
let rec inside n =
let l = input_line i in
let n = n + 1 in
match Str.split_delim (Str.regexp_string "*/") l with
before::after::_ ->
(if not (!fn = "")
then tbl := (!startline,n,!fn,List.rev !ids)::!tbl);
startline := 0;
fn := "";
ids := [];
outside n
| _ ->
(match Str.split (Str.regexp "[ \t]+") l with
"*"::name::rest ->
let len = String.length name in
(if !fn = "" && len > 2 && String.sub name (len-2) 2 = "()"
then fn := String.sub name 0 (len-2)
else if !fn = "" && (not (rest = [])) && List.hd rest = "-"
then
if String.get name (len-1) = ':'
then fn := String.sub name 0 (len-1)
else fn := name
else if not(!fn = "") && len > 2 &&
String.get name 0 = '@' && String.get name (len-1) = ':'
then ids := (String.sub name 1 (len-2)) :: !ids);
| _ -> ());
inside n
and outside n =
let l = input_line i in
let n = n + 1 in
if String.length l > 2 && String.sub l 0 3 = "/**"
then
begin
startline := n;
inside n
end
else outside n in
try outside 0 with End_of_file -> ()
let hashadd tbl k v =
let cell =
try Hashtbl.find tbl k
with Not_found ->
let cell = ref [] in
Hashtbl.add tbl k cell;
cell in
cell := v :: !cell
@script:ocaml@
@@
tbl := [];
fnstart := [];
Hashtbl.clear success;
parsed := [];
nea := [];
parse (List.hd (Coccilib.files()))
@r@
identifier f;
position p;
@@
f at p(...) { ... }
@script:ocaml@
p << r.p;
f << r.f;
@@
parsed := f :: !parsed;
fnstart := (List.hd p).line :: !fnstart
@param@
identifier f;
type T;
identifier i;
parameter list[n] ps;
parameter list[n1] ps1;
position p;
@@
f@p(ps,T i,ps1) { ... }
@script:ocaml@
@@
tbl := List.rev (List.sort compare !tbl)
@script:ocaml@
p << param.p;
f << param.f;
@@
let myline = (List.hd p).line in
let prevline =
List.fold_left
(fun prev x ->
if x < myline
then max x prev
else prev)
0 !fnstart in
let _ =
List.exists
(function (st,fn,nm,ids) ->
if prevline < st && myline > st && prevline < fn && myline > fn
then
begin
(if not (String.lowercase f = String.lowercase nm)
then
Printf.printf "%s:%d %s doesn't match preceding comment: %s\n"
!thefile myline f nm);
true
end
else false)
!tbl in
()
@script:ocaml@
p << param.p;
n << param.n;
n1 << param.n1;
i << param.i;
f << param.f;
@@
let myline = (List.hd p).line in
let prevline =
List.fold_left
(fun prev x ->
if x < myline
then max x prev
else prev)
0 !fnstart in
let _ =
List.exists
(function (st,fn,nm,ids) ->
if prevline < st && myline > st && prevline < fn && myline > fn
then
begin
(if List.mem i ids then hashadd success (st,fn,nm) i);
(if ids = [] (* arg list seems not obligatory *)
then ()
else if not (List.mem i ids)
then
Printf.printf "%s:%d %s doesn't appear in ids: %s\n"
!thefile myline i (String.concat " " ids)
else if List.length ids <= n || List.length ids <= n1
then
(if not (List.mem f !nea)
then
begin
nea := f :: !nea;
Printf.printf "%s:%d %s not enough args\n" !thefile myline f;
end)
else
let foundid = List.nth ids n in
let efoundid = List.nth (List.rev ids) n1 in
if not(foundid = i || efoundid = i)
then
Printf.printf "%s:%d %s wrong arg in position %d: %s\n"
!thefile myline i n foundid);
true
end
else false)
!tbl in
()
@script:ocaml@
@@
List.iter
(function (st,fn,nm,ids) ->
if List.mem nm !parsed
then
let entry =
try !(Hashtbl.find success (st,fn,nm))
with Not_found -> [] in
List.iter
(fun id ->
if not (List.mem id entry) && not (id = "...")
then Printf.printf "%s:%d %s not used\n" !thefile st id)
ids)
!tbl
// </smpl>
---
drivers/clk/keystone/pll.c | 4 ++--
drivers/clk/sunxi/clk-mod0.c | 2 +-
drivers/clk/tegra/cvb.c | 10 +++++-----
drivers/dma-buf/sw_sync.c | 6 +++---
drivers/gpu/drm/gma500/intel_i2c.c | 3 +--
drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
drivers/irqchip/irq-metag-ext.c | 1 -
drivers/irqchip/irq-vic.c | 1 -
drivers/mfd/tc3589x.c | 4 ++--
drivers/power/supply/ab8500_fg.c | 8 ++++----
drivers/power/supply/abx500_chargalg.c | 1 +
drivers/power/supply/intel_mid_battery.c | 2 +-
drivers/power/supply/power_supply_core.c | 4 ++--
fs/crypto/crypto.c | 4 ++--
fs/crypto/fname.c | 4 ++--
fs/ubifs/file.c | 2 +-
fs/ubifs/gc.c | 2 +-
fs/ubifs/lprops.c | 2 +-
fs/ubifs/lpt_commit.c | 4 +---
fs/ubifs/replay.c | 2 +-
lib/kobject_uevent.c | 6 +++---
lib/lru_cache.c | 4 ++--
lib/nlattr.c | 2 +-
23 files changed, 39 insertions(+), 43 deletions(-)
^ 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